「アジャイル開発とスクラム」の感想

平鍋さんの著作アジャイル開発とスクラムを読んだ。
なるほどと思った部分を中心に感想をラフなメモ書き。

【1】第1～3部に分かれていて、第1部はアジャイル開発とスクラムの解説。
第2部はアジャイル開発の日本における実践例。
第3部は、サザーランドさんと野中先生のインタビュー、野中先生の原論文との比較。

個人的には、第1部はアジャイル開発では既に知られている内容だったし、第2部の実践例も何となく聞いていたし、第3部が一番興味深かった。
やはり、サザーランドさん本人の考え方、野中先生の原論文に込められた内容が、アジャイル開発やスクラムにどれだけ影響を及ぼしていたのか、を考えるととても奥深い。

【2】サザーランドさんのインタビューで、マイクロファイナンスにソフトウェア開発の問題を解決するヒントを考えた後、どんなきっかけでソフトウェア開発を変えたいと思うようになったのか、と平鍋さんが聞いている箇所がある。
開発チームはオブジェクト指向なソフトウェアだったので、チーム自身もオブジェクト指向に似た組織構造だったが、ソフトウェア開発の組織全体では、コマンドコントロールが効いていて、マネジメントも階層的だったため、Conwayの法則によって、ミスマッチが生じていたのだ、と。
つまり、ソフトウェアの構造はソフトウェア開発組織の構造に従う、というConwayの法則に逆らうように開発チームが動いていたため、緊張関係があったのだ、と。

アジャイル開発の底辺には必ずオブジェクト指向プログラミングが関わってくるが、それは単なるプログラミングの一技法ではなく、自己組織化という観点も含んでいる。

そして、チームワークと生産性に関わる論文を探していた時に、野中・竹中の原論文「The New New Product Development Game」に出会い、チーム構成とマネジメントの考え方がここにあると気づいた、と。
つまり、チームは階層的な組織構造ではなく自己組織化されていていること、逐一指示されるマイクロマネジメントは開発の生産性を落とすため、スポーツのような自己組織化するチームをモデルとして採用した、と。

更に、Coplienの論文「組織プロセスパターン」を元に、デイリースクラム(朝会)を取り入れたらうまくいった、と。

組織パターン トップ10 - James Coplien - Digital Romanticism

サザーランドさんが、Scrumを生み出していく過程で、野中先生の論文やCoplienのパターン言語を参考にしつつ、アイデアを固めていった経緯がとても面白かった。
色んな人のアイデアを参考にしてScrumは作られているんだな、と。

【3】野中・竹中の原論文「The New New Product Development Game」とアジャイル開発の比較検証も書かれている。
一部の内容は平鍋さんのBlogに少しだけ書かれている。

スクラムの原典を読み解く(1)：An Agile Way：ITmedia オルタナティブ・ブログ

スクラムの原典を読み解く(2)：An Agile Way：ITmedia オルタナティブ・ブログ

原論文にあるTypeC(アジャイルな開発チームに近い)の特徴を下記6つとしている。

・不安定な状態を保つ
・プロジェクトチームは自ら組織化する
・開発フェーズを重複させる
・「マルチ学習」
・柔らかなマネジメント
・学びを組織で共有する

【4】最も興味を引くのは「不安定な状態を保つ」。
新製品開発では、開発チームが簡単にできそうもないチャレンジングな課題が与えられ、明確なコンセプトや計画書が与えられるわけではない。
計画通りの作業で進められるわけではないから、チームには自由裁量が与えられると同時に極端に困難なゴールがスタートになる。

故意に「不安定な状態を保つ」点が大切。
元々分かっているような開発ならば、計画をきちんと決めて指示に従って作ればいいが、そうではない。
逆に不安定な状態だからこそ、その変化を利用する。
アジャイルソフトウェア開発では、仕様も要件も変わるし、スコープを意図的に変える事でプロジェクトをコントロールしようとする。
XPが提唱した「4つの変数」「スコープという唯一制御可能な変数」を思い出させる。

また、「プロジェクトチームは自ら組織化する」では、不安定な状況が自己組織化を促すのだ、という逆説的な説明もある。
指示がなければ動けない人は、そんな不安定な状況では作業できないからだ。
「柔らかなマネジメント」では、コマンドコントロールのようなマネジメントではなく、メンバーが自発的に行動しながらも、課題にぶつかったら支援するスクラムマスターのようなサーバーントリーダーが要求される。

そこから「開発フェーズを重複させる」ように、開発と製造も一体化し、情報は文書ではなく人が運ぶ。

【5】スクラムには、チーム、スクラムマスター、プロダクトオーナーの3つの役割がある。
そして、スクラムでは、この3つの役割は厳密に定義されている。

スクラムマスターはサーバーントリーダーだ。
スクラムマスターは、スクラムチーム(プロダクトオーナー、チーム、スクラムマスターを含むチーム全体)を見渡すマネジメントの役割を持つが、管理する役割ではなく、相互の対話を引き出すようなファシリテーターのような役割を持つ。
進捗管理などのマイクロマネジメントにタッチするわけではなく、チームのメンバー自身が動き出せるようにフォローするようなサーバーントの役割。

そして、スクラムマスターはスクラムというプロセスの責任者でもある。
認定スクラムマスター研修では、スクラムマスター照合表というチェックリストをもらったが、そこでは、プロダクトオーナーやチーム、組織がスクラムのそれぞれの役割を果たしているか、チェックする役割をスクラムマスターが責任を負うようなことで書かれていた。
さらに、スクラムマスターは、スプリントないしプロジェクトの教訓をまとめ、組織に資産として残す仕事も含まれている。

【6】第2部の実践例では楽天の藤原さんの事例がとても興味深い。
CIツールから導入して、最終的にはスクラムの全社導入まで、彼がアジャイルに取り組んだ流れが鳥瞰して読める。
個人的には、一つの物語のように、挫折や葛藤なども踏まえたお話が別の本になると面白いかなと思ったりする。

最後の一節で藤原さんが、エンジニア上がりのリーダーがプログラミングが分からなくなったと言い出したら開発チームのボトルネックになってしまう。若い人達がどんどん新しいアイデアを持って来ているのに、それをマネージャーが止めてしまうような事があれば、スピード重視の会社では致命的な損失になるから、という話があった。

最近は、プロジェクトリーダーやプロマネがソフトウェア開発のボトルネックになりやすい気がしている。
今の時代は技術の流れが速い。
昔、Javaなどの業務系Webシステム開発で腕を鳴らしていたとしても、2010年代の現在はスマートフォンやタブレットのアプリ開発、そしてAWSを中心としたWebインフラのクラウド化などのように、IT技術はどんどんシフトしていて、今の技術は初心者だろう。
昔のオブジェクト指向の考え方は今も通用するだろうが、開発現場で使われる言語は変わってきているから、過去の経験知による判断が有効でない場面が多くなってきている。

新しいトレンドの技術を理解できる管理職層にならなければ、新しいアイデアを判断できないし、逆にストップをかけてしまう既得権益層になってしまうだろう。

【7】アジャイル開発とスクラムを一通り読んで、IT以外の業界の経営者向けにアジャイル開発を知ってもらうのにとても良い本と印象を持った。
にも関わらず、Scrumを生み出した野中・竹中の論文のようなアイデアを日本人は生かせなかったのか、何故アジャイル開発は日本で育たなかったのか、という疑問が残る。

野中先生の言うSECIモデルでは、最初のSである共同化をとても重視する。
暗黙知と形式知をやり取りするモデルとして、なるほどと思うけれど、古き良き時代の日本の考え方のような気もする。
今の日本は、昔の追いつき追い越せから成果主義が主流であり、集団で何かアウトプットを出そうとする時、成果主義が別の副作用を生み出している。
昔のように、皆で合宿してアウトプットを出すぞ、という集団志向のやり方が、コンプライアンスや成果主義や個人主義など色んな阻害要因でうまくいっていない気がする。
SECIモデルを今の日本企業に当てはめても、WF型開発を前提にする会社には有効に働かないような気がするのだ。

野中先生も、90年代の日本の製造業は、分析過多、計画過多・コンプライアンス過多で今まで強みとして持っていた実践知リーダーシップを忘れてしまったと嘆いている。
だが、それをソフトウェアという新たなものづくりで復活させようとする平鍋さんの取り組みに感動しているとも言っている。

アジャイル開発に惚れ込んで活動していた僕にとっては当たり前の事実は、IT以外の業界では、野中先生を初めとして全く知られていなかった事実の方が驚異だった。
下記の記事でも、似たようなことが書かれている。

日本のＩＴ産業における「失われた２０年」の実相｜TransNetCreation

(引用開始)
製造業においては、「米国発の概念・手法を日本企業が発展させて躍進した」のに対して、　ソフトウエア産業においては、「日本発の概念・手法を米国企業が発展させて躍進した」　という歴史的対称性です。
(引用終了)

そんなことを思うと、日本はアジャイル開発のアイデアを持っていたにもかかわらず、ソフトウェア産業ではウォーターフォール型開発に囚われ過ぎて、アジャイル開発を発展させる可能性を見出せなかったのではないかと思ったりする。

今は、「モチベーション3.0」では、成果主義のモチベーション2.0から内発的動機のモチベーション3.0へ変わるべきだ、と書かれているが、その方向性に解決法があるように直感している。
モチベーション3.0の例として、オープンソース運動やクリエイティブコモンズなどがあげられる。
つまり、自己組織化を生み出すためには内発的動機を重視する雰囲気が開発チームにあり、だからこそ、アジャイル開発がスムーズに行われるのではないか、と。
先日デブサミが行われたけれど、そのようなオープンな場でつながったエネルギーが変革の鍵を握ると直感している。