Design It! プログラマのためのアーキテクティング入門

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として書けるものではない。ステークホルダーとの必要なアクティビティを通して形作られていく。あるいは、それらのアクティビティそのものが創発的な合意形成であり、アーキテクチャだとも言えるだろう。 アーキテクチャとビジネス文脈 大切なことは、最良のアーキテクチャは、その文脈によって変わるということだ。文脈なしにアーキテクチャは成立しない。このことを強く思い出させる印象的なエピソードを1つ紹介しよう。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! プログラマのためのアーキテクティング入門"

Scrum Interaction 2019 keynote by Jeff Sutherland

Scrum Inc. Japan主催のはじめてのカンファレンス、Scrum Interaction 2019が11/8東京で開催されました。当日はぼくが総合司会を勤め、300人のスクラム実践者が参加され、スクラムの父、Jeff Sutherland とスクラムの祖父、野中郁次郎先生が一つの場に会する場は熱気でいっぱいでした。 このブログでは3回に渡って内容をご紹介したいと思います。第1回目は Jeff Sutherland の基調講演です。 Jeff Sutherland の基調講演 産業のディスラプション DXによって産業がソフトウェアによってディスラプトされている現状の例。Amazonの縦産業相次ぐ参入は、ホントすごいですね。 金融: Amazon がドイツで金融に参入。3,300のスクラムチーム 運輸: Amazon が中国船をリース購入、航空機も購入して参入。NYでUberがFedExを凌駕 電力(Utility): 風力・太陽光が安価になり、家庭自家発電が広まる(彼自身の家では、自分の作った電力を近所に売買、教会に寄付。それも携帯のアプリで!) Agile BS(だめだめアジャイル) ところが、米国でもだめだめアジャイル(Agile BS = Agile Bullshit)がはびこっているらしい。例えば米国防省(DoD)では「ほとんどのプロジェクトがアジャイル開発をしていると宣言しているが、本当はそうなっていない!(Fake Agileだ)」という議論(ここに発見。redditで炎上してたらしい)があり、「Agile BSチェックリスト」が作られた。 ここまでの議論では、 DXがおこり、成功企業の多くの企業がスクラムを採用している。 米国ではアジャイルがソフトウェア開発はデフォルト(政府調達でも)。 ただし、名前だけのアジャイルにやっているとろこは失敗している。 さまざまな企業がスクラムを「組織改革手法として」導入しはじめている。 アジャイルをやるにしても、こんな形でやっていないか? さあ、失敗しないために組織的にアジャイルを取り入れないといけない。 そこで、Scrum@Scaleですよ。 Scrum@ScaleはScrum同様、薄いフレームワーク。スクラムを階層的に組むのだが、「スクラムマスターの階層」と「プロダクトオーナーの階層」の両方があり、組織がフラクタルに形成されるのが特徴でしょう。フラクタルであるということが、生命的ですね。さらに、これが組織に「実装」されたときの具体形はそれぞれに違うという点も面白い。創発的、自己組織化的というか、生身の人間のチームがその場で考えて成長・進化していく過程が構造に現れています。   だから、変化に強く、仮にこの構造を任意の場所で2つに切ったとしても生きられる構造を作ることができる、そう生命組織ににているんです。自立分散が集まって、一つの目的を満たそうとしている形なんです。

Read more "Scrum Interaction 2019 keynote by Jeff Sutherland"

SPI Japan 2016 で基調講演しました

富山で開催された SPI Japan 2016  にて、基調講演をさせていただきました。お声がけいただいたSRAの林好一さんはじめ、運営のみなさんに感謝です。林さんはAutomotive SPICEなどに造詣が深い、この界隈の有名人です。 SPIはSoftware Process Improvementの略で、ソフトウェアプロセス改善。林さんからいただいたお題は、現場ではエンジアリングに主眼が置かれるが、プロセス屋さん(という言い方されていた)は外側から見ていて、ともすると現場と衝突する。エンジニアリング側とプロセス側は衝突するものなのか、と。アジャイルはどちら?あるいは、そもそも両者は目的が同じですよね?という問いかけでした。 基調講演 それで、私なりに考えて、アジャイルと、特に「プロジェクトファシリテーション」の話をして、それらとエンジニアリングは「水」と「油」ではなくて「醤油」のように一体化されたものではないか、というストーリーを作って話をしました。先に結論を言うと、、、 アジャイルはプロセスではない。しかし、現場には必ず(今動いている)プロセスはある。 すべてうまくいくプロセスはなく、環境、働く人々、お客様、製品などの特性によってそれぞれである。 誰かが決めるプロセスではなく、現場改善こそが、具体プロセスを作っていく。(抽象プロセス、もしくは参照プロセスというものはあるかもしれないが) その仕組みをプロセス自身に入れるべき。 そして、その活動自体も、現場で行うべき。 この場のみなさんにとっては、、、、当たり前のことですよね! それでね、懇親会で、「結局、水と油ではない醤油とはなんなんでしょう」という疑問に答えられていないことがわかりました。それで、このブログで付け足したいと思います。 アジャイルはなんといっても西海岸文化が強い。つまり青い空の下でスタートアップがたくさんうまれ、そこで育ち、イグジットした人たちが投資家に周り、スクラップ&ビルドが急速に起こっている世界。イノベーションの真っ只中です。日本は、より長期的な視点や勝ち負けではない文化を持っています。例えば品質に対して強くこだわったり、人材教育を社内で手厚く行ったり、ある程度長い雇用の中で、エンジニアと技術を育てていこう、という文化です。ですから短期的でなく、人でつないでいく「持続的イノベーション」が日本には必要だし、それが日本にあった、イノベーションの形ではないでしょうか。 以下は、野中郁次郎先生がIPAのアジャイルの海外普及調査を行ったときに寄せてくれた、日本のアジャイルへの応援文です。野中郁次郎先生はもちろん、竹内弘高先生とともにScrumという名称を新製品開発の文脈ではじめて使った論文の共著者です。 “新製品開発としてのスクラムの源流は80年代の日本の製造業にあり、それがソフトウェア開発の文脈で欧米から再発見されたものがアジャイルと理解しています。現在の欧米型企業経営が、必ずしも国民生活の質の向上に寄与していないことを鑑みると、私たち日本人が、過去の知恵と若者の活力の両方を活かす形で、新しい日本の持続的イノベーションのやり方をつむぎ出す必要があります。その力の源泉は、高い志を持った経営と、いきいきと働くことができる現場環境にあるのではないでしょうか。日本に適したアジャイル、スクラムの形を、描き出そうではありませんか。そのためにはまず、経営、ミドルマネジメント、現場が話す場を作り、お互いに共感することから始めなくてはなりません。” 平成24年4月16日 一橋大学名誉教授 野中郁次郎 これをもって「醤油」のぼくなりの結論にしたいと思います。 その他の発表 富士通の和田さんと永和の羽根田さんの企画による、アジャイル行動展示が行われています。永和から、岡島さんや村上さんが参加してGAS(GoogleApp Script)で簡単なシステムを、人通りの多いギャラリー内で開発します(旭川動物園の行動展示のように)。2時間イテレーションでかなり難しそうですが、昨日の講演終了後にはたくさんの人が訪れてくれました。 他にも永和から、天野さんの、ふりかえり、についてのセッションがあり、岡島さんが、パネルディスカッションで語りました。 他にも、アジャイル関係のセッション多数です。ISO26262機能安全やAutomotiveSPICE、CMMI言った重厚感あるプロセス信奉者が元々多い界隈ですが、着実にアジャイルが広まっているのを感じます。 個人的ベストプレゼン アジャイルの全体を導入するのではなく、技術的なプラクティスの肝である、ユニットテストをどう導入したか、という岡本さんのプレゼンが、個人的なベストプレゼンです。リーダーとしての役割のなかで、できることを、周りに説明しながら、やった、そしてその効果を語るというもの。大上段にふりかぶらず、できることから始める。これがぼくが思う改善の、あるいはアジャイルのはじまりだと思うからです。 最後に 懇親会では、富山の食事とカラオケまで行き、永田さんとアジャイルと品質の話をまた再燃させました。林さんはじめ、実行委員のみなさん、八木さん(お久しぶり)、小松澤さん(お久しぶりにお会いできて嬉しかったです)、武田さん、水田さん(懇親会での自己紹介は感動的でした)、河野さん、清水さん、中山さん(これまたお久しぶり)、実行委員長の千田さん、本当にありがとうございました。

Read more "SPI Japan 2016 で基調講演しました"

永和システムマネジメントの社長に就任しました

先週金曜(2015/10/23)付けで、株式会社永和システムマネジメントの社長を拝命しました(公式発表)。すこしこれまでの経緯や、ぼくの思いを書いてみようと思います。 永和システムマネジメントへの入社 ぼくは大学を卒業後、最初に東京で日本鋼管(現JFE)に就職、NK-EXA(現エクサ)に出向しました。3次元CAD開発の仕事で、曲線・曲面を扱う数学やグラフィックスを得意な分野としていましたが、30歳で最初の子供ができたことから、福井(福井県大野市がぼくの自宅です)への転職を決め、永和システムマネジメントに1995年に入社しました。 入社20年たった今年、社長という役割を頂けたことは運命的な意味を感じています。 永和とアジャイル もしかしたら、このブログの読者の方は永和システムマネジメントというと、Rubyやアジャイルを連想する方が多いと思います。実はそれは最近のことで、東京支社を2002年に作って、天野勝や角谷信太郎、木下史彦、伊藤浩一、、、(卒業多数含む)、、といったRubyとアジャイルを愛するエンジニアが東京の永和にたくさん集っていったことに端を発しています。今では「アジャイル事業部」というそのものの名前をもった事業部ができ、事業として大きく成長しました。仲間に出会えたことに感謝しています。 金融と医療、アジャイルと組込み 実際には、永和システムマネジメントには「金融の永和」、「医療の永和」という顔があります。むしろそちらが先に(30年前から)しっかりした事業体を作っていますし、現在でも、永和と言えば基幹系金融システムの開発/情報系の開発、医療システムの開発、福井での地域医療機関サポート、といった分野の信頼が、大きな資産になっています。「永和さんに頼んでよかったね」という言葉を聞くことがぼくたちの仕事なのです。 金融・医療に続く3本目の柱として「オープンシステム」を目指して、UNIXカーネルの開発に端を発するチームができたころ、ぼくが入社しました(1995年)。ぼくの最初の仕事は、永和をインターネットにつなぐこと(esm.co.jp のドメイン名もぼく発案)。その後、『オブジェクト倶楽部』(現オブラブ)活動開始、東京事務所の設立、JUDE(現 astah)の開発開始、などの活動をしていく中で、前述の人たちとの出会いがあり、アジャイルのチームが東京にできる展開になりました。そして、最近では自動車の車載ソフトウェア開発基盤を含む、組込み技術センターも発足し、AUTOSAR技術などを得意に、技術発信しています(1分で分かる社史はこちら)。 面白いのは、これだけ違った分野で仕事をしていても、変わらないことは、チームで仕事をすることそして、「永和さんに頼んでよかったね」という言葉を聞くことが仕事だ、という価値観で、これは小山公一郎社長、西村輝雄社長、と引き継がれてきた永和の文化なんだと思います。社是には、「会社の繁栄と社員全員の幸福の一致」があります。また、働きやすい環境づくり、を社員参加で取組んでいます。 エンジニアが日本で活躍できる環境 ずっとぼくが考えてきた、というより悩んできたのは、エンジニアが誇りをもって社会で活躍できる環境をどうつくるか。自分自身が受託開発の中でとても苦労した経験から、その答えの1つが「アジャイル開発」の実践だと考えています。受託開発や新しい契約形態で日本でのアジャイル開発に取組むこと。そして、もう一つの答えは、自社プロダクトやサービスを持つこと。それが株式会社チェンジビジョンで「astah*」として開発しているモデリングツールです。 チェンジビジョンと永和 2006年、永和の中でずっとフリーソフトウェアとして作ってきた astah (旧名: JUDE)事業化し、チェンジビジョンという会社を創立しました。進化したソフトウェア設計エディタ astah は UML/ERD/DFD/SysML/D-Case などの汎用モデリングツールとして成長しています。永和はチェンジビジョンの親会社です。 今後、チェンジビジョンは代表取締役を共同設立者の熊谷さんにもお願いし、ぼくもそのまま代表取締役社長として残って国内、世界へのモデリングツールの発信を続けて行きます。 両社とも、中途採用を継続的に募集していますので、志をともにできる方の応募もお待ちしています。 正式な社長ご挨拶メッセージは、こちらです。http://www.esm.co.jp/corporate/

Read more "永和システムマネジメントの社長に就任しました"