「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい

倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。
新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。
以下はラフなメモ書き。

【研修資料】

プロエンジニアになるための「アジャイル開発」再入門 from Yoshihito Kuranuki

【参考】
アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!

アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!

ドキュメントをなくしてもうまくいく？ ? 人に依存するリスクへの対処とは | Social Change!

【1】「ソフトウェア開発をチームで行う内容をよく知らない新入社員に、アジャイル開発をどのように説明すればよいか？」という問題に対し、上記の資料はその解決にとても役立つ。

倉貫さんのBlogや資料がとても読みやすく優れているなあ、と思う点は、ITをよく知らない人、アジャイル開発を知らない人に対して、普段着の言葉でその本質を上手く的確に表現している点だろうと思う。

既にアジャイル開発を知っている人ならば、上記の資料はとても当たり前の内容だろう。
しかし、その当たり前に思っている感覚を、新入社員やITに詳しくない経営者に説明して納得させるのは、とても難しい。
自分がこれだけ、今後のソフトウェア開発はアジャイル開発になるべきだ、と確信していても、普通の人には伝わらない。

一番分かりやすい説明方法の一つは、対比させることだろう。
たとえば、上記資料では、「これまでの開発は、ノンビリしていたな」「でも、これからの開発は、Software is eating the World」のように、従来と今後の開発スタイルを的確に表現している。

また、アジャイル開発の特徴である「最初に決めた機能を全部作らない」「最大限の構想よりも最小限の完成品を作る」「何を作るのか、ではなく、何を作らないか」「タスクをバラし、見積もりし、優先順位を決める」などを分かりやすく説明してくれている。

【2】日本人がアジャイル開発を理解しにくい理由は、日本人が製造業の成功体験に縛られていて、品質の考え方をアジャイル開発へ置き換えられない事が、最大の原因ではないか、とずっと思っている。

【2-1】上記資料では、その点について「“Point of Sales”から“Point of Use”へ」で明確に記されている。
製造業では、一度作った製品はその後で変更できないのが普通なので、出荷時に最高品質を保証できるように頑張る。

一方、ソフトウェアは一度リリースしたとしても、それから利用し始めて初めて、ユーザにとって、ありがたみを感じることになる。
つまり、本番リリース後の保守フェーズで品質を上げていく発想が重要だ。
この点は何度強調しても強調しきれない。

すなわち、ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!の記事の通り、「ソフトウェアは完成だけしても意味はない。むしろ負債である」という事を意味している。

【2-2】経営者ならば、損益分岐点分析は必ず知っているが、それをソフトウェアに適用すると、まさに初回リリース時点では、まだ利用していないのだから、初期投資した分だけ赤字だ。
そこからシステムを利用して、実際に回収して、初めて、損益分岐点を上回れば、元を取った、という事になる。
それまでは、システムはずっと負債であり、利益を得るまで回収する責任や義務が発生するわけだ。

僕も、経験上、ソフトウェア投資は資産なのか負債なのか、と暗黙的に疑問に感じてきたが、上記資料では、明確に、「ソフトウェアは負債だ」と明確に説明してくれているので、改めて腑に落ちている。

【2-3】では、この発想を受け入れると、どんな影響が出てくるか？

結論は、ソフトウェア開発の目的が品質重視から、価値重視へと変換されることだろう。
それはどんな意味を持つのか？

従来の製造業の発想では、マーケティング1.0の供給者重視からマーケティング2.0の顧客重視へ変わった。
さらに、上記の発想では、マーケティング2.0の顧客重視だけでなく、顧客に届ける価値を重視する発想、つまり、持続可能な社会を実現するマーケティング3.0へ発展するだろう、と考える。

なぜなら、顧客が利用し続けて、高額な初期投資を回収できて利益が得られるならば、いかに早く回収するか、という方向へ発展して、最終的には、では、顧客が使い続けてくれるにはどこに価値を感じてくれるのか、という方向へ考えるようになるだろうからだ。

すなわち、顧客の企業だけが儲かれば良い、という発想ではなく、持続的に成長して会社を半永久的に維持していくには、顧客の企業を取り巻くステークホルダー、たとえば、従業員や取引先、地域の人々、との関係性を重視して、エコシステムを作っていく、という流れに変わっていかざるを得ないからだ。
そうでなければ、顧客の価値を実現したとは言えないと思う。

つまり、アジャイル開発で「価値重視」と呼ばれる所以は、そういう背景がある、と考える。

【2-4】すると、ソフトウェアの品質にすごく影響してくる。
初回リリース前のテストでいくら頑張ったとしても、本番リリース後にユーザが価値を感じて利用してくれなければ、システムはただのゴミ箱に過ぎない。
また、利用中に機能追加していくうちに、使いづらくなった、と感じて、利用が減ると、ソフトウェアの価値はどんどん減ってしまう。

つまり、保守フェーズでの品質維持、さらには利用頻度向上が大事になるので、機能性や信頼性よりも、保守性や移植性という品質特性が重視されるようになるだろう。
ソフトウェアはそのまま放置しておくと、エントロピーが増大して、その複雑性が手に負えなくなっていくからだ。

そのために、リファクタリング、テスト駆動、継続的デプロイ、DevOpsなどの開発技術が研究され、今も技術革新されているわけだ。
そして「アジャイル開発では全部作らない」という発想へつながっていく。

【3】さらに、プログラマに求められる価値は、製造業のワーカーのように、技術標準や作業標準を起点としてPDCA（つまりSDCA）サイクルを回す方法ではなく、クリエイティブな発想を大切にしながらそれを実現していく方法へ変わっていく。
この辺りの内容は、数多くの手法が提唱されていて、どれかに理論として一つに統一されている感覚は受けない。
つまり、まさに色んな人達が、汎用的な手法を試行錯誤している所だろう、と思う。

おそらく、プログラマのいるソフトウェア開発の会社は、従来の病院や会計事務所、法律事務所などのような「プロフェッショナル官僚制」へと発展していくのかな、と思ったりもする。
なぜなら、倉貫さんが提唱する顧問プログラマは、顧問弁護士、顧問税理士にたとえられるので、プログラマの人数が増えれば、そういう方向へ進化するのではないか、と想像できるから。

H. ミンツバーグ経営論 : 戸崎将宏の行政経営百夜百冊

官僚制と管理システム

「H.ミンツバーグ経営論 第8章「組織設計:流行を追うか、適合性を選ぶか」」のオーディオブック - audiobook.jp

しかし、一方で、「ティール組織」のように、個人のパフォーマンス重視の組織へ進化するアイデアも提唱されている。
実際、倉貫さんが提唱するホラクラシーは、「ティール組織」が提唱する最終型の組織にぴったりだ。

「ティール組織」の本を読んでみて、アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノートの内容がまさに当てはまる、と感じた。

つまり、「ティール組織」が提唱する最終型の組織は、従来の我々が知っている組織文化や価値観と全く違うのだ。
そういう事実を理解しなければ、「ティール組織」は大変読みにくい本だろう、と思う。

「ティール組織」の感想はまた後で書く。