【感想】アジャイル開発とスクラム 第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つの共通理解が生み出される。この過程をみんなで踏みなさい」続きを読む

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

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

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

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

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

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