コロナ時代において、リモートワーク、リモート開発、リモートマーケティングのスタイルがどんどん変わっていますね。 アジャイルスタジオは、当初、福井でのお客さまとの共創・共育拠点として立ち上げましたが、これを期に、東京ー福井ー沖縄の永和メンバーを結び、東京のアジャイルコンサルメンバーも入り、リモートでのアジャイルコーチングや開発支援を提供しています。 リモート受託開発ももちろんですが、リモートコーチング、内製化支援、リモートでのアジャイルチームの立ち上げ支援、展開支援もサービス提供します。 本当は、福井にみにきて！といいたいのですが、今は「リモート見学」が可能です。会社単位で応募いただければセッションを企画しますのでぜひ！
Read more "Agile Studio は福井から日本全国へ"9/12(土) Management 3.0 創設者の Jurgen Appeloさんと、Work Together Anywhere の著者、Lisette Sutherland さんのダブル基調講演で開催されるようです。 http://management30.jp/m30jpcon/ ”Work Together Anywhere” は日本語訳が出ています。 TED にも出てたLisetteさんの話を聞いてみたいなぁ。リセットサザランドさんの、Work Together Anywhere. TED talk. はこちらです。 速いインターネット ヘッドセット などの基本に加え、「カメラだけ常時onパターン」、「音声だけ常にonパターン」、「バーチャルオフィス」の3パターンが面白かった。特に、「ミーティングをスケジュールするより、ドアノック」というのが会話パターンとして必要だというのは強く納得する。 「テレプレゼンス」はまだやったことないなぁ。確かに首振り、だけでもだいぶ違うかも。Management 3.0 Japan カンファレンスで、講演聞けるそうです。 http://management30.jp/m30jpcon/ 9/12(土) 。申込はもう始まっています。
Read more "Management 3.0 Japan カンファレンスと、『リモートワーク―チームが結束する次世代型メソッド』"昨日オンライン開催された、Essence セミナーの平鍋からのレポートです。冒頭、Ivar Jacobson からもらったビデオを、ぼくが解説しながら流しました。 基調講演 より詳しくはこちら。スライド(PDF)もこちらから。https://essence.ivarjacobson.com/videos/tokyo-keynote-july-21-modern-software-engineering-essence ソフトウェアはビジネス的に大きな成功をおさめているが、それをささえるソフトウェアの工学は未熟なままだ。 これまで発見されているベストプラクティスを、「方法論」の呪縛から開放し、みんなで議論し改良し、使えるようにしたい。 3つのペルソナ＝スポンサー、テッククリード、チーム、それぞれの課題は、 スポンサー：2,500万人ものソフトウェアエンジニアがいるのに、工学というより工芸のようだ。毎回新しい方法論や技術が現れ、投資が無駄になる。名の通った Guru の手法（方法論セールスマン）に依存している。チーム間で手法が流通しない。 テックリード：方法論争から開放され、必要なプラクティスを自由に利用したいのだ。それぞれの方法論のいいところをミックスしたい。また、手法ごとに語彙が違う。違う手法を使うと学ぶのがたいへん。 チーム：成功しているアジャイルチームは、自分たちで仕事の仕方を選べるのだ。アジャイルフレームワークに沿って仕事をさせられるのではなく、自分たちでプラクティスを選びたい。バックログをひたすらこなすのではなく、スマートに仕事がしたい。 エッセンスは大学でも教えられている。400年後にエッセンスを見ると、それは、ニュートンやガリレオが400年前にやったことと同じように見えるだろう。 Essence はどの方法論とも競合しない。例えば、Jeff Sutherland の Scrum と協調している。“Better Scrum with Essence” with Jeff Sutherland and Ivar Jacobson) 講演は、「一緒に未来を創っていこう」というメッセージで締め括られました。 角さん（翻訳者）の Essence 解説 とても分かりやすい解説でした。キーコンセプトである、７つのアルファや、例としてのペアプログラミングの記述、カードの説明などなど。本を読んでも難しそうだったコンセプトが明確になったと思います。 鷲崎先生のお話 これまでのソフトウェア工学が、「テーゼ」と「アンチテーゼ」の上下に触れながら、止揚されていく様子を Boehmの資料をもとに解説があり、ポストアジャイルとしての Essence の位置どりが話されました。また、小林さんの Essence を利用した事例も紹介されました。 パネルディスカッション 富士通の宮田さんから、日本のSI、そこで働くSEのあり方を変えていきたい、という力のこもったメッセージがありました。ある意味日本のSE論、とそこになかったものの反省から、知識を蓄えて、これからの創造的なSEのあり方を模索せねば、という危機感というか気迫を感じるお話でした。 富士通クオリティラボの島田さんから、品質保証の立場から、どうやってアジャイルに関与していくか、という戸惑いと思いをお聞きしました。やっぱり「参加していく」ことが重要だと話されていて、品質は「最後のゲート」ではなく、共に作る、ものだと再認識しました。 小林さんは現場視点から、Essence の事例をいくつか見せていただきました。使ってみるとなかなか面白い発見があるものですね。「匠メソッド」のマッピングも面白かった。 ぼくの方は、これまでのソフトウェア工学の Guru たちがこぞってアジャイル側に加担していること、でも、残していくものを残していく器（うつわ）として Essence の役割を話したつもりです。アジャイルの成功は「チーム」の成功、「ビジネスの成功」を基本としていて、それを直結しています。でも、チーム横断、企業横断、さらに産業横断でその体験を蓄積する仕組みがないのです。これはおそらくわざとで、動く実装があってはじめて機能する、というインターネット創生にはじまり、ソフトウェア現場、クラフトマンシップの学びから、まずはチームでビジネスの成功をつくらないと始まらない。企業で知識を蓄えるしくみは、たとえば、野中郁次郎のスクラムには、最初から書かれている(Multi-Learning)。ただ、問題は、いまの大企業のソフトウェア開発が、この「知識トップダウン」になっていること。知識が急激にアップデートされるのに、過去の成功・失敗から取り出された「守るべきこと」の集積になっている。知識のトップダウンを避け、さきに動くチームがなければならないので、順序としてはこれでいいい。次にぼくらがやらなければならないのは、知識を集める仕組みで、企業ワイド、産業ワイドにできるようになるといい。知識のボトムアップ。こここそが、Essence の生きる道、ソフトウェア工学の道ではないか、そして、アカデミアの役割もそこにあるのでは、と思っています。 また、「ソフトウェア工学は工学になりきれていない」という話は、土木工学がもともとエンピリカルであり、そこから、エンジニアリングの力で安定したという話の引用です。Mary Shaw […]
Read more "Modern Software engineering with Essence Japan Seminar"参加してきました！ぼくは今回はオブラブ枠からの参加です。 スクラムネイティブの方々には、知らない方も多いかと思うので、ちょっと紹介。 ということで、今回の平鍋のトークは、アナログについて話したいと思いながら、デジタルの中でアナログがどこまでできるか、という話をしました。特に、「アジャイル基地をつくるパタン言語」を中心に、そして、そのあとで起こったコロナ禍での場づくりについて。以下スライドです。 たくさんの方に聞いていただき、ありがとうございました。 ぼくは、キーノートを聞いてオンライン飲みに突入し、西原さんと映画談義で沈没した1日目、早起きして2日目はほぼオブラブの部屋を中心にいろいろなチャネルを回って、最後のクロージングを聞きました。印象に残ったことなど、、、 基調講演の永瀬さんのアナログな(??) – デジタルだけど手数とハートのある、zoom トーク。テーマもいいけど、伏線としかけにあっと驚いた。 Agile Japan の discord 上のディスカッションで、彩菜さんの司会力と小林さんの「リアルワールド」、組織との戦いが熱かった。 最後のクロージング、おさらいでの開原さんの変顔タイマー。場づくり力さすがです。 岩切さんのまとめトークのアナログ感と中継感が zoom の中ですごく映えた！地方テレビ局のおうち訪問っぽい。やっぱりアナログ最高。 栃木チームの「餃子後光」。何故か大阪のフェスに行って餃子が食べたくなる。 オブラブ木下さんのアジャイルクイズ「アタック25」は、アジャイルトリビアの連続。(例：2001年、Agile Manifesto の合宿でホテルの予約をしたのは誰?) 天野さんのオンラインでできるふりかえりツール Continuous KPTA お披露目。 参加はできなかったが、伝わりくる「三河の熱量」。 行けなかった XP 祭り枠(;_;) オブラブでも、永和から橋本さんの業務SEからアジャイルへの転身、「アジャイルが降りてきた」話。豊嶋さんの3分ぴったりまとめトーク。様子をうまくまとめてくれた。 実行委員のみなさん、よい会をありがとうございました！ discord と zoom という組み合わせで、ここまでたくさんのチャンネルを一体化できるんだ、という気づきがありました。mural, remo, miro といった他のツールを使ったセッションも多く、デジタルでありながら、「手触り」のある会にできるヒントをもらいました。 デジタルな「いま・ここ」性(digital here-now-ness) が、自分の中でさらに加速しました。 (※追記 訪れてくれる人の客足はななかなか少なく、チャンネルがたくさんある分、人気セッションに人が偏った感じがしました。物理的な部屋なら人数が入らなかったら他に流れると思うのだけど、オンラインだとさらに偏重傾向が加速するのだろうか)
Read more "ありがとう、Scrum Fest Osaka 2020"I am a lifetime math fan, and I found a wonderful education video for Linear Algebra. One day, I was looking around several math lectures in the internet, and I incidentally encountered this Prof. Gilbert Strang’s lecture. I was so drawn in to the course as well as the way he talks, that I watched […]
Read more "Prof. Gilbert Strang’s Linear Algebra and T-shirt"日本で「アジャイル基地（アジャイルラボ、アジャイルルーム）」を企画・設計・運営している方々が集まって、これまでの設計のコツや共通の気づきを書いて共有してみよう、という活動をしてきました。 #agilebasepatterns Stay Home が続き、働き方が変わるかもしれませんが、緊急事態宣言が解けた今日をめがけて、これまでの成果を公開します。 もともと、Agile Japan 2020 にサブミットした（そしてリジェクトされた）コンテンツですが、そのままコロナ禍に突入しアジャイル基地自体の意味も変わってくるかもしれません。ですが、今回意地になって書き上げました！これからアジャイル基地やアジャイル部屋を作りたいと思っている方、すでにアジャイル基地を作った方などのフィードバックもお待ちします。 #agilebasepatterns (ハッシュタグ) https://github.com/kenjihiranabe/agile-base-patterns/ 中身をチラ見。。。。。 これは11番の「靴を脱げるリラックススペース」というパタンです。 NTT Communications の Lean Agile Base にある「サバンナ」をアイディアの元にしていますが、永和システムマネジメントにも「和ジャ」と呼ばれるスペースが歴史的に作られてきました。 これは１つの例ですが、複数の場所、組織で繰り返し現れているパタンを収集し、その文脈や解こうとしている課題、周りの他の構造との関連なども含めて文書化しました。全体構造の中での意味が分かって、なかなか面白いパタン言語になったのではないかと思います。 著者（今回のライターズワークショップ参加者）のみなさんです。 アジャイル基地パタンライターズグループ 平鍋 健児(@hiranabe), 永和システムマネジメント – Agile Studio Fuku 岡島 幸男(@okajima_yukio), 永和システムマネジメント – Agile Studio Fukui 岩瀬 義昌(@iwashi86), NTT Communications – Lean Agile Base 水嶋 彬貴(@mizuman_), NTT Communications – Lean Agile Base 蜂須賀 […]
Read more "アジャイル基地をつくるパタン言語"IPAからプレス発表がありました。 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開 https://www.ipa.go.jp/about/press/20200331.html ざっと見た内容をお伝えします。この特徴や意味についてです。 スクラム用語に統一 アジャイルはもちろんスクラムに限った話ではありません。でも、今回の成果物に出てくる用語と基本となるプロセスフレームワークはスクラムです。ソフトウェア開発の技術的詳細に立ち入らず、プロセスの枠のみを提示しているスクラムが、こういった契約などの問題を扱う際にはちょうどよい語彙なのだと思います。もちろんスクラムはXPと共存もできるので、プロセス面の用語としては、スクラムの定義を持ってくるのが分かりやすでしょう。 さらに、現実的にはスクラムが一番普及している、ということもあると思います。そして、これからアジャイルを組織的にスケールさせる場合も、スクラムを由来とするフレームワークを用いることが多いと思いますので、この選択はとても分かりやすかったと思います。 日本の産業構造への適合 「ユーザ企業」、「ベンダ企業」、「発注」という言葉が出てきます。これは日本で非常に強く残っているSIの形で、ユーザ企業側にIT人材がほとんどおらず「ITは発注されいている」という状況を構造として表しています。現在、Web系の企業や2000年以降に起業した企業はこの形を取っているところは少なくなっているでしょう。また、ユーザ企業でもソフトウェアの内製化が進んでいます。 とはいえ、この構造の中でどうするのか、という考えがないと話が進まないのです。ここを見捨てて、それは古いよ、これからは内製だよ、と言ってしまうと、日本の現在ソフトウェアエンジニアの6-7割を見捨ててしまうことになると思います（ぼくも出自がそこだから逃げ出さずになんとかしたい）。なので、この形での「契約と取引」に踏み込んだことは、とても意味のあることだと思うのです。 チーム体制、特にPO その中で、POが発注側の役割だ、としたのが特によいと思います。こうでないと、「丸投げ」から脱却できないのです。少なくとも要件の変化が激しく市場変化に対応したい、というのが目的であれば。 準委任契約 契約は２社間のものなので、どんな形でも本来よいのですが、日本には2大類型として「請負契約」と「準委任契約」があります。ユーザ企業の調達部門はこの２つに分けて考えています。ので、この中で準委任契約が本筋だ、という割り切りにも大きな意味があったと思います。また、その場合でも「指示命令系統」や「現場責任者」という話が出てきます。それらについての解釈もこの中で触れられているという踏み込みがとてもいいと思いました。 回顧 最後に、2011年にIPAから出された「非ウォーターフォール型開発 WG 活動報告書」では私も参加して、日本のアジャイル開発への提言をまとめました。その時はこの名前からも分かるようにアジャイルは非主流でした（非ウォーターフォールって何？）。そしてモデル契約にも取り組みました。でもそれはほとんど使われなかったようです。 日は流れ、メンバーも刷新して、この取引・契約モデルを作成したワーキンググループには永和システムマネジメント・アジャイル事業部の木下さんが参加しています。 今回の発表に関して、木下さんが考え、提案し、議論した記録がここにありましたので、ぜひこちらもどうぞ！そして、WGのみなさん、おつかれさまでした！ IPA の アジャイル開発版「情報システム・モデル取引・契約書」
Read more "IPAからアジャイル版「情報システム・モデル取引・契約書」でたよ！"アジャイルスタジオ福井(ASF) にて培ってきた、アジャイルでリモート開発、WFH(Work From Home)する場合のノウハウ（コツ）集をまとめました。PDF で以下からダウンロードできます。 中身ですが、典型的なフォーメーションでグループ化しています。 読んでいただければ分かりますが、フォーメーションに関わらず使えるパターンも多く含まれます。 リモートエンジニア 全員常時オンライン、グループチャット、雑談、リモート飲み会 リモート拠点 傍らに写真、リーダーから無礼講、たまには会う、とにかく画面共有、チームマップ 全員リモート 通信環境にこだわる、顔写真アイコン、リモートホワイトボード、サブディスプレイ、デジタル化アナログツール ノウハウ出しにあたっては、ASFのメンバーからアイディアを集め、岡島さんが編集しています。ぜひ、ダウンロードしてご一読ください。
Read more "リモートアジャイル開発のノウハウ集を公開！"astah* ファミリーの新エディション、astah* System Safety をリリースしました(→製品サイト) 。久しぶりの新製品にチェンジビジョンのメンバーもドキドキわくわくしています！ これは何か? 今回は、これまでの astah のような汎用的なモデリングツールではなく、製造業とくに安全性を By-Design で確立する分野、例えば自動車のシステム開発向けに提供されるバージョンです。 チェンジビジョンは、これまでもモデリングを中心とする製品をUMLからはじまり、マインドマップ, SysML, GSN, そしてER図やフローチャートを含めた professional と対象を広げてリリースしてきました。現在、モデリングが扱える範囲は、ソフトウェアからシステム全体、そしてSoS(System of Systems)に、さらに構造や振る舞いだけでなく、要求、安全設計やセキュリティ設計、さらには認証(ISO26262やSOTIF)のための論証、へと広がっています。 これまでの astah がUMLが中心で、単発的に SysML, GSN と出してきたものを（青いモデリング領域）、今回、安全設計を中心にして、システム開発向けに繋げて提供しているのが(赤いモデリング領域)、今回の astah、すなわちastah* System Safety です。 なぜ作ったか? 製造業は日本の重要な産業であり、その分野にMBSE(Model Based Systems Engineering)の適用が進み、モデリング手法が大きなパワーになる、と考えています。自動車、航空宇宙、ロボット、原子力、医療機器など、複雑化と、セイフティ・セキュリティの両面が問われる分野です。 機能安全コンセプトの設計では、うまく品質要求レベルを割り振ることで開発のコストと安全性を調和させることが求められます。また、安全性説明の表現として、セーフティケースも求められます。 さらに、自動運転への期待とその安全設計、検証の難しさが大きなトピックになっています。これまで、FTAやFMEAなどの分析手法が用いられてきました。しかし、自動運転のように複数の部品間および人間の認識にまでまたがって、はじめて実現される機能を扱う場合、個々の部品は非故障であっても、想定される機能が実現されないケースを分析する必要が出てきます。 あるいは、組み合わせの爆発とAIの登場により、網羅的なテストを行うことが難しい領域において、シナリオベースト・テストが注目されています(参考： Sakura Project のSenario)。そこでは、オントロジーと機能ツリーを用いた効果的なシナリオ作成が必要となります。欧州で先行して Pegasus プロジェクトにて社会受容性（事故を社会としてどこまで受容できるか、また、どのようにフィードバックするか）が議論され、さらに機能が意図通りに動いた上で、ミスユースや性能限界などによって生じるリスクに対する安全性の標準化がSOTIF(ISO/PAS 21448)として進んできました。 このような、現代的な安全設計のためのツールを提供し、製造業のこれからの品質をささえる現場のモデリングツールとして、それらの手法が一体で繋がるものを提供したかった、というのが開発の動機です。 何ができるの? ぜひ、製品サイトをみてください。無償試用期間もありますので、ここまでの話やキーワードにピンと来る方は、現場のみなさんで実際に使ってみてください！ 技術的に楽しいこと あまり機能には関係ありませんが、長年作ってきた astah は、独自の Java コードによる UML メタモデルと、データ保存には […]
Read more "新製品 astah* system safety をリリースしました"Design It! 読みましたか？（よい本ですよ！） Design It! ―プログラマーのためのアーキテクティング入門 ”設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。” ソフトウェア開発のアジャイル化が進み、ソフトウェアは生き物としてますます頻繁な変更にさらされるようになった。 アジャイルとアーキテクチャの民主化 アジャイル開発のアーキテクチャに対する基本スタンスは、最初に先読みをしすぎた設計(BDUF = Big Design Up Front)をしないということだ。設計に大きな先行投資をせず、動くソフトウェアを維持しながら進化させていく。アーキテクチャはこの繰り返しによって立ち現れてくるもの、実験と実装とユーザフィードバックの結果として「収穫」されるものである。中心となるユーザ価値から作りはじめ、イテレーションを繰り返しながら全体設計が現れてくる、というのだ。これは、これまでの大きな先行設計がかえってシステムを複雑にし、結局作らなくても良い汎用構造や複雑なメカニズムを作ってしまうというリスクを下げている。さらに、アーキテクトと呼ばれる神様が実装をせずに机上で架空のかっこよい構造を作り出してしまうことも避ける。アーキテクトとプログラマという構造ではなく、アーキテクチャを民主化した。ソフトウェアの機能は実装して動くとを確認しつつ、追加や変更を受け入れながら、リファクタリングによって内部の重複部分を取り除いていき、コードベースの成長にしたがって必要だった抽象構造が現れてくる、、、はずだ。 しかし、本当にそうだろうか？アジャイルとアーキテクチャ論は何度も議論になることがあった。特にリファクタリングの繰り返しによってのみ、アーキテクチャは本当に現れるのだろうか。それは現在意図している機能だけから作られるものだろうか。リアクタリングで扱い切れないような大きな変更はどう扱うのだろう。アーキテクチャは現在作ろうとしているソフトウェアの機能や非機能だけでなく、過去の経験や知見からもヒントが得られるのではないか。アーキテクチャは選択する、ものでもあるはずだ。BDUF は良くないとしても、NDUF(No Design Up Front)はあまりにもリスクが高い。私たちには、ENUF(Enough Design Upfront)をを作る活動、そしてそれを共有、維持、変更する活動が必要だ。 アーキテクチャとソフトウェア工学、パターン 本書は、この議論について現実的な視点で、アーキテクチャを作り出すための指針について書かれている。参考文献のリストやSEI/IEEEが定義するアーキテクチャへの言及を見れば、筆者が過去のソフトウェアエンジニアリングの要所を押さえていること、かつ、アジャイル方法論の発展の経緯や歴史についても造詣が深いことがうかがわれる。 本書の中で私が特に気に入っているのは、過去に特定され、名前が付けられているアーキテクチャーパターンが紹介されていること(7章)だ。アーキテクチャパターンを知っておくことは、最初の入り口を選ぶ時に大きな道しるべとなる。これらに縛られることは危険だが、発想の種を多く持つことはアーキテクトとして重要だ。そしてもう一つ、具体的になアクティビティが目的とともに紹介されていること(パート3全体)。このパートだけでも本書の価値がある。人の活動としてアーキテクチャづくりにアプローチしており、アーキテクトの道具箱として活動が具体的に紹介されている。アーキテクチャづくりはHow-Toとして書けるものではない。ステークホルダーとの必要なアクティビティを通して形作られていく。あるいは、それらのアクティビティそのものが創発的な合意形成であり、アーキテクチャだとも言えるだろう。 アーキテクチャとビジネス文脈 大切なことは、最良のアーキテクチャは、その文脈によって変わるということだ。文脈なしにアーキテクチャは成立しない。このことを強く思い出させる印象的なエピソードを１つ紹介しよう。Twitter は最初 Ruby on Rails で開発されたが、2009年ころからJVM(Java VM)ベースのアーキテクチャに移行し、レスポンスとスケーラビリティを改善した（O’Reilly OSCON Java 2011: Raffi Krikorian, “Twitter: From Ruby on Rails to the JVM”）。これは、大きくアーキテクチャを変更した商用アプリケーションの例だ。これは、最初のRuby On Railsの選択が間違っていたということではない。スタートアップでは、ビジネスとしてプロダクトが軌道に乗らない限り、資金は集まらない。twitter が最初からJVMを採用したとしたら、現在の成功はなかっただろう。スタートアップの段階では、Ruby on Rails の選択が素早いアプリケーションの構築とユーザーフィードバックに必要だったのだ。 アーキテクチャとコミュニティ（人） さらに、このアーキテクチャ変更に影響を及ぼしたのは、スケーラビリティなどの非機能要件だけではない。JVM 移行理由には、「より幅広いコミュニティからエンジニアを集められる」という「人」や「チーム」の観点も含まれていた。現在JVM上で動く言語が多くなっているため、様々な現代的言語が使えるようになり、このテクノロジをベースに使うことでコミュニティに発信し、それらが得意なより多くのエンジニアを参加できるようにするという狙いもあったのだ。アーキテクチャの設計もしくは選択には、こういった多様な視点の「文脈」が影響を及ぼす。スタートアップとして開発するのか、最初から多くのユーザーベースを扱うことが分かっているのか、では話が全く違ってくるし、実際に開発するエンジニアにはどのようなコミュニティに属するのか、にも影響される例だ。 […]
Read more "Design It! プログラマのためのアーキテクティング入門"
an Agile Way 