アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

著者 : 平鍋健児 野中郁次郎 及部敬雄

• 翔泳社 (2021年4月7日発売)

作品紹介・あらすじ

アジャイル、スクラムの第一人者が
企業のリーダー層に送る必読書、8年ぶりに大改訂！

ソフトウェア開発手法「アジャイル」と、
その手法の1つである「スクラム」の体系的な解説書が
初版刊行から8年の時を経て、装い新たに新登場です。

第2版となる本書では、
ビジネスで広く存在感を示すようになったアジャイルの
新しい知見を盛り込み、内容をアップデート。

アジャイルとスクラムの全体像や、
野中郁次郎の知識創造モデルとの関係など、
初版での核心部分はそのままに、
アジャイルを組織内で大規模化するためのスケールフレームワークなど、
新たな観点から、解説を追加しています。

また、国内有名企業による実践をまとめた、
事例記事＆インタビューも一新。
KDDI、ANA、IMAGICA.Lab、NTTの最新事例を収録し、
国内企業ならではの取り組みを紹介しています。

日本におけるアジャイル開発の第一人者、平鍋健児氏、
アジャイル開発実践者の筆頭である、及部敬雄氏、
そして世界的な経営学者でありスクラムの提唱者、野中郁次郎氏
これら国内を代表する著者陣による提言は、
ITエンジニアはもちろん、
あらゆる業界・企業のリーダー層に受け取ってほしい内容です。

感想・レビュー・書評

[daipresentsさんの感想 · 2021年4月3日]

読み終わったばかりなので寝てからレビュー書こう

[morizo1000さんの感想 · 2022年4月3日]

2022/4/3
アジャイルは原則でありそれに沿った具体的な手法としてスクラムやエクストリームプログラミング、カンバンなどがある。ドキュメントより対話、仕様書より動くソフトウェア、交渉より協調、予定より変更を重視するのがアジャイルの原則。リリースをスプリントという単位で分割し高速でデリバリーするための各種プラクティスを定義した方法論がスクラム
野中氏のオリジナルの新製品開発についてのスクラム論とアジャイルスクラムの共通点は不確かな状況の中で大胆な目標を達成するために①柔らかなマネジメントによる自律的チーム、②学習、③フェーズを横断してプロダクトオーナーが責任を持つ人による伝達。
ウォーターフォールには学習を経ていない洞察のない計画、変更への柔軟性がなく、下流工程が情報処理要員となりモチベーションが下がるという問題がある。
身体的な暗黙知と言語化された形式知を行き来してスパイラル上に知的生産をするseciモデル。形式化された知識は内面化されないといけないし、内面化された知識はまずF2Fで共有され、それが言語化されて、議論や交流を経て洗練される。スクラムでの朝会、ペアプログラミング、レトロプロスペクティブ
暗黙知と形式知だけでなく、それらを統合して実際の文脈に合わせて何をすべきかを共通善に沿って判断する実践知が必要。
継続的なイノベーションのためには、ビジョンと学習、各ファンクション、各スキルを一通り持った小さな相似形のチームが集まって全体を構成するフラクタルな組織が必要。

[匿名希望さんの感想 · 2021年11月15日]

アジャイル開発とスクラム

企業内でもアジャイル開発が広まって来たと思う一方で、まだまだウォータフォール開発がなくならない現実。
アジャイル開発を知識創造型と呼びますが、人との繋がりによって臨機応変に動くことで、より良い、より市場に特化した製品やサービスを生み出す。
私達と顧客と見ることで、一体感を生み出す。

ソフト開発に限らず、ビジネスやマーケティングなどでもスクラムは取り入れられてきた。アメリカの海兵隊の陸海空が連動して動くシステムもまた、然りとのこと。

よりコミュニケーションを必要とすると考えれば、必ずしも万人に、良いものとは思えない。コミュニケーション高荷になりかねないのでは。
それでも、情が先にくるかっての日本企業が当時、この方法を取り入れることができたら、日本の歴史も少しは変わっていたかもしれませんね。

[japapizzaさんの感想 · 2023年7月2日]

■従来手法の何が問題なのか？
・人の創造性を奪ってしまう
・文書によるコミュニケーションには限界がある
・悪いタイミング
・未来を読む水晶玉はない
・仕事が楽しくない
・部分最適化

■アジャイルを大規模化するフレームワーク
【共通する点】
１．既にうまくいったチームが２つ以上あること
２．大規模化する必要があること

・Nexus：最も純粋なスクラムの複数チーム拡張。あくまでソフトウェアのプロダクト開発に焦点がある。チーム間の依存関係を調整しながら、同期的に全体スプリントを回し、動くソフトウェアをデリバリーする。
・Scrum@Scale：単にソフトウェア開発手法としてのスクラムを拡張したものではなく、スクラムによる組織運営を主眼としたフレームワーク。会社全体がすばやい意思決定と顧客指向の組織に変わること、そして、優れたプロダクトやサービスを市場に出していくことの両方を指向している。また、マーケティングチームや人事チームなど、これまでアジャイルが対象としてこなかったチームにも、スクラムを適用する。よって、導入には会社の方針が必要となる。EATを採用するには、エグゼクティブレベルの意思決定が必要になる。
・SAFe：プロダクト開発の方法論に留まらず組織運営や文化形成までを対象にしたフレームワーク。プロダクトを作る部分はもちろん、そこに至るまでの判断やワークフロー、チームを支える組織を対象とすることで、部分最適ではなく全体最適を目指している。
　また、SAFeは大規模アジャイルフレームワークの中でもトップのシェアを誇っていて、世界中の多くの企業による導入事例がある。ScaledAgile,Inc.によって事業として運営されていることもあり、トレーニングや認定制度導入支援をしている企業や団体も多い。
　SAFeの全体像を見ると複雑で難しく感じるかもしれないが、導入レベルに合わせた4つの構成、ロードマップ導入事例導入支援を受けられるという点が高いシェアにつながっている。
・LeSS：シンプルにスクラムを大規模開発に適応させたフレームワーク。チームを中心に、大規模に適応させるために必要なものだけを追加している。そのため、ある程度スクラムに慣れたチームや組織にとっては、すんなりと受け入れることができるであろう。
　一方で、用意されたプロセスやルールを使って一気に導入したい場合には向かないかもしれない。プロダクトやプロダクトグループの成長に合わせて学習を繰り返し、フレームワークも成長させていく姿勢が求められる。
　Nexusと共通点は多いが、詳細では違うところもある。スクラムの共同開発者の1人であるケン・シュエーバーが開発したNexusとは違うルートで、開発現場の大規模開発へのニーズに適応していったスクラムの形だといえる。
・Disciplined Agile：エンタープライズ対応に重きを置き、これまでアジャイルに含まれていなかった、「ガバナンス」「文書標準」「レビュー」「エスカレーション」「教育」「運用」「予算」「人事評価」などという言葉が出てくる。リアルな大企業でよく聞く言葉群だ。例えば、契約方法やリソースの戦略が「方向付け」フェーズの「予算確保」というゴールに登場する。
　また、これまでチームベースのアジャイルがわざと避けてきた大域構造を示す言葉群、「アーキテクチャ」「フェーズ」を積極的に入れている。スコット・アンブラーの過去の仕事から、ラショナル・ユニファイド・プロセス(RUP)、アジャイル・モデリング(AM)、アジャイル・データ(AD)などの視点もしっかり入っており、集大成的なアジャイル百科事典ともいえるだろう。
　PMIがこの手法を取得したことで、今後PMBOKと相乗した普及活動が活発になるだろう。

■事例：NTTコムウェア
【社内プロセスの変革】
　そこで、これらの既存プロセスが抱える課題感例えばNTTコムウェアとしてウォーターフォール開発で積み上げてきた、統計データに基づく品質評価が、
・案件ごとに完成の定義が異なり、試験工程をまとめて取らないスクラムに適さない
・意思決定の会議体に必要となる、資料作成や事務処理、事前説明等が煩雑である
といった課題に対し、冒頭で出てきたアジャイル推進組織とともに、カイゼンに取り組んだ。
　このプロセス改革においては、アジャイル開発の実践と同様、守破離のマインドで取り組んだ。実際にスクラムを行う中で、社内プロセスに対し理想論を押し付けず、既存のプロセスで取り組み、結果として見えた既存制度の課題点を、他組織を巻き込むことで社内プロセスの変革につなげたのである。
　例えば品質評価のプロセスにおいては先述の通り、統計データに基づいたテスト消化曲線やパ発生曲線の収束を目指す従来型の評価方法が主流であった。しかし、開発の中で試験を同時に実施する私たちのチームでは時系列曲線を描くことができない上、「バグ」の定義も困難であった。
　こういった課題に対し、定性的な評価として「プロダクトオーナーによる評価レポート」や、「品質コントロールのために行った施策の透明化」を用い、定量的な評価として「循環的複雑度」や「長期的に見たモジュールごとのコミット数」(コミット数が多い=リファクタリング頻度が高いモジュールは要注意)を用いる等、新たな品質評価の可能性を品質管理部門と連携して模索した。これら新たな指標値の出力に自動化を組み合わせることで意思決定プロセスの短縮化に挑戦した。


■「合宿をしなさい」
「形式的な会議で決めることはできない。いろんな背景を持った人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話をする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話をするようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、1つの共通理解が生み出される。この過程をみんなで踏みなさい」

[ふじけら@復職直後さんの感想 · 2023年3月1日]

アジャイル・サムライを読んだ後だったので、「ふーん」という感じだった。

開発現場に深く入ってない人が「アジャイルってどんなもんじゃい？」というときに読むと非常にいいかも。

[necomeisterさんの感想 · 2023年2月18日]

スクラムというタイトルが付いているけど、この本を読んだからスクラムが出来るという訳ではない。
スクラムが対象としている根っこの課題は何なのかを語ろうとしている本。
なので、1部にスクラムの表面的な話が載っているが、知らない人向けだろうし、知っている人からすると退屈。
後半の対談とかは面白いが、これも示唆くらいな話なので、そこから自分で考える事が必要だろう。

[Naruki Chigiraさんの感想 · 2022年10月3日]

たしかにスクラムの概要や導入のための具体的な手法を求めて読むには物足りない内容かも知れないが、スクラムのスケーリングのための手法 LeSS, SAFe, Nexus, Scrum@Scale の各手法の解説は、スクラムの全社的な展開の選択肢を広げる際の参考になる。関連して、終盤の自己相似的な組織の拡大の話も新鮮で刺激になった。

[masakazukanekoさんの感想 · 2022年8月5日]

スクラムをフレームワークとしてだけではなくて、人々の活動と捉えているところに著者たちの熱い気持ちを感じました。

[dattsuさんの感想 · 2022年3月28日]

ウォーターフォール型の開発は敵対関係を生み出しやすく、面白くない→個人的に刺さった

【感想】
　スクラムを中心に、アジャイル開発の技法、企業への導入エピソードが紹介されている。アジャイル開発は大きく技術的手法、組織的手法に分けられる。本書は、組織的手法である「スクラム」の記述に焦点をあてていて、技術的手法の詳細には立ち入っていない。リファクタリングやTDD、CI等については紹介程度の記述がある。実際の開発で生かすには、別の本を読む必要があるだろう。
　とかく、情報が分散していて、章ごとのつながりを捉えるのが難しく、咀嚼が難しいと感じた。おそらく、この本の目的は「アジャイル開発手法とスクラムについて色々な観点で紹介する」ことなのだろう。フレームワーク・プラクティスがかなり多く登場するし、ケーススタディの登場企業も多い（覚えて使いこなすことが難しい）。
　企業４社ごとのアジャイル導入経験も記述されているのが、各企業群をまとめて抽象化していないので、頭に叩き込むのが難しい。研究書ではないので、当然ではあるのだが。そして、読んでも、弊社で実施している４，5カ月程度のシステム導入プロジェクトを、アジャイル方式にするイメージが余り湧かなかった。なんといっても、顧客にとって、アジャイル型を選択するメリットがイマイチ分からなった。基本設計までして、顧客から承認を得る必要があるとする。そのとき、請負型ではなく、準委任型で、なぜユーザー企業が発注してくれるのだろうか。準委任型で、開発発注するにしても、「何を開発するか」は決まっていないといけないわけだから、基本設計は顧客と行っておく必要があるように思えるのだが。基本設計まで終わっている機能を、準委任型で開発依頼してくれるためには、スケジュールと予算が潤沢にあるような企業じゃないと、無理なのかな、と思った。もしくは、要件がふわっとしていて、基本設計自体が無理で、開発して、その成果物をみないと要件が固まらないような内容なのだろうか。そうなると、それはもはやPOCのようでもあるのだろうか。
　「スクラムの源流は野中＆竹内のナレッジマネジメント論文である」という章の取り扱いも難しい。興味深くはあるが、スクラムの関連情報、アカデミックな組織分析である。スクラムの素養が日本企業にはあるよ、という意味では分かるのだが...。既に情報過多なので、ここで新しいアカデミックな話を入れてくるのであれば、事前のケーススタディに対する汎化、抽象化の章にしてほしかった。「野中さんと、点と点がつながる面白い話ができた！スクラムの関連情報だし、伝えたい」という意志を感じる。
　個人的に一番刺さったのは、ウォーターフォール型の仕事自体が楽しくない、と書いていること。今私が仕事で感じている辛みが簡潔な文章で表されていて、なるほどな、と思わされた。この文章と出会えただけで、★４つ。自分の生業、仕事内容を見直し、システム開発に携わるなら、アジャイル的な職場に移るように準備、努力をし始めようと思った。

>>p47「工程を追って順に仕事を進めるやり方は、仕事を渡す側と受ける側の間に敵対関係を生み出す傾向にある。「仕事に書かれていないことをやってほしいと言うのです」「簡単に気を変えないでほしい」「自分にコントロールできないことに対して、私は責任が持てません」などなど。ウォーターフォールの開発を観察すると別の発見がある。そう、仕事が楽しくないのだ。ウォータフォールの開発モデルは、製品作りに携わる人々のモチベーションをそぐ原因になる。そして、その結果できた製品は、作った現場開発者の創造性、スキル、そして情熱を表現するものにはならなにのだ。人はロボットではない。だから、人にロボットのように働くことを求めるプロセスは、介在する人々を不幸にする結果になる。」

【本書を読みながら気になったコト】
■アジャイル開発では、期間を短く区切って優先度の高い機能から実装することを繰り返すことで、最後にならないと動くものが見えないリスクを軽減する。ユーザーからフィードバックを取り入れながら開発する

■ウォーターフォール手法の問題点
・創造性を奪う。変更を拒み、部分最適な機能が出来上がる
・文書による完璧なコミュニケーションなど不可能
・完璧な計画を立てることはできず、必ず不確実なことが起きる
・工程を追って順に仕事を進めるので、ステークホルダー間で敵対関係ができて、仕事が面白くない

■インクリメント…スプリントにおける成果物、製品の機能。

■リファイアメント…プロダクトバックログの内容を更新する。優先順位の変更、機能詳細の追加、工数見積もりの変更を行う

■アジャイル開発という開発手法が存在するわけではい。アジャイル開発宣言の価値観を反映した開発の手法の1つがスクラムである


■こまめに完成物を見せて、フィードバックをもらう、という考え方自体はウォータフォール型の開発でも活かせる。その前提で工数、費用を見積もりする

■各種企業での実践例が記述されているが、何故多くのユーザー企業は、請負型ではなく、準委任型（アジャイル開発）でのプロジェクト推進を許したのか？
　→完成物責任が無い状態で、発注する（最終的な予算がいくらになるか見えてこない）以上、ユーザー企業としては、アジャイル開発を好みそうにないと思えたのだが
　・BtoBでリリースはどうやっている？細かくフィードバックをもらえないと、リリースはできない
　→なぜそんなにも、ユーザー企業は開発やスプリントレビューに付き合ってくれる？どうしてそんなにユーザー企業がアジャイル開発に理解があり、つきあってくれるのか？
　
■2020年3月にIPAからアジャイル開発版「システム・モデル取引・契約書」が公開された
　→準委任契約を前提とする
　→プロダクトオーナーはユーザー企業から選出する

■人生もウォーターフォールより、アジャイルに。変化を前提に。一定の期間、目標を決めて、実践しながら、時折振り返りを実践する
　

[a-shinoさんの感想 · 2022年3月15日]

Scrum;
適応型ソリューション(adaptive solutions)をチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。
1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載された。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum」として紹介した。
スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられており、スクラムの改良に伴ってこのガイドも更新されている。(Wikipedia)

Agile;
アジャイルソフトウェア開発宣言(Manifesto for Agile Software Development)は「アジャイルソフトウェア開発」という概念を提唱した文書である。
2001年に、軽量ソフトウェア開発手法（と当時呼ばれてた）分野で名声のある17人がアメリカ合衆国のユタ州のスノーバードというスキーリゾートに会し、彼らがそれぞれ別個に提唱していた開発手法が共有する価値観を議論した。彼らはその結果を 「アジャイルソフトウェア開発宣言」という文書にまとめた。アジャイルソフトウェア開発宣言はアジャイルソフトウェア開発とその諸原則を公式に定義した文書であると、広く認められている。
この宣言は以下の4つの価値観を示し、これらの価値観を有するソフトウェア開発を「アジャイルソフトウェア開発」と名付けた。
・プロセスやツールよりも個人と対話を
　　Individuals and interactions over processes and tools
・包括的なドキュメントよりも動くソフトウェアを
　　Working software over comprehensive documentation
・契約交渉よりも顧客との協調を
　　Customer collaboration over contract negotiation
・計画に従うことよりも変化への対応を
　Responding to change over following a plan
(Wikipedia)

著者プロフィール

平鍋 健児：（株）永和システムマネジメント 代表取締役社長

「2023年 『世界標準MIT教科書 ストラング：教養の線形代数』 で使われていた紹介文から引用しています。」