なぜアジャイルを認めてくれないのか ~プロジェクトマネジメント型組織における変革の処方箋~

はじめに

この記事では、従来型の組織にアジャイル開発を導入しようとして引っかかる、よくある「障害」とその解消のための方法について話します。

最近シニアエンジニアとして、新しい開発チームの立ち上げに関わる機会が増えてきました。 自分も含めて周囲のエンジニアやマネジャーが「アジャイル」を導入しようとして、うまくいくケースとうまくいかないケースがあります。上位のマネジャーの理解が得られなかったり、逆に現場エンジニアたちの理解が得られなかったり理由は様々ですが、一言で言うなら「組織」に理解がされないということです。自らの失敗を分析したり周囲の話を聞いていると、アジャイルの導入に失敗するケースは往々にして「組織」が何を求めているのか適切に理解して運用できていないケースが多いように思います。つまり組織が「アジャイル」を認めていないわけではなくて、適切にアジャイルな開発が運用できていないから組織の期待に答えられていないだけなのではないか、ということです。

そもそもアジャイルは開発手法なのか

よくある誤解として「アジャイル」＝「開発手法」と見てしまうことです。 アジャイルとは特定の方法論や開発手法を指しているものではなく、一種の理想です。それは、よく引用されるアジャイルマニフェストからも明らかです。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を -- アジャイルソフトウェア開発宣言

昨今のソフトウェア産業で働いている人はみな、これらの事項が大切なことは肌身で感じているのではないでしょうか。これらの理想に真っ向から No を言う人はそう多くないのではないかと思います。

一番大切なことは「アジャイルになる」ことであって手段ではありません。特定の開発手法を取り入れようとしてやきもきする前に、自分の置かれた状況に最もフィットする「アジャイル」な開発はどうやったらできるかを考えてみることが大事だと思います。 極端な話ガントチャートを使っていようが、個人との対話と動くソフトウェアを重視し、顧客と強調しながら変化に柔軟にプロジェクトを推進することだってできるはずです。

自分の組織を知る

「彼を知り己を知れば百戦危うからず」とはよく引用されることわざですが、アジャイル変革を目指すにあたって自分の所属する組織を知ることは重要です。ここではエンジニアリング組織論への招待で紹介されているプロジェクトマネジメントとプロダクトマネジメントの考え方が役に立ちます。

• プロジェクトマネジメント型の組織
  • はじまりと終わりが決まっている
  • 計画を正しく実行する
• プロダクトマネジメント型の組織
  • 終わりが決まっていない (終わらないことが目的)
  • チームの生産性(スループット)を最大化する

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

よくある失敗の１つ目が、プロジェクトマネジメント型の組織においてプロダクトマネジメント型のやり方を強行してしまうことです。長期的な見積もりは「やっても無駄」と一蹴し、短期的な計画にのみフォーカスする。成果に直結しない見積もりや計画のオーバーヘッドを最小化することができるため、デベロッパー視点ではとても生産性の高い開発方法のように思えます。一方、上位のマネジメントからしてみると、一向に具体的な見積もりや計画がでてこない、いつになったらモノがでてくるのか分からないという不安に晒されることになります。また、自己の成果物に依存する他のチームがプロジェクトマネジメント型であった場合、まともに計画が立てられないといった困った状況が起こります。

つぎによくある失敗が、いっきにプロダクトマネジメント型の組織に変革をしようとすることです。これは主に「プロジェクトマネジメント型の組織ではアジャイル開発ができない」といった誤解に基づくものです。無論、プロダクトマネジメント型組織に変革できるのであれば良いことです。ただし組織全体のやり方を変えるにはとても大きなエネルギーが必要になります。

アジャイルな見積もり

アジャイルとプロジェクトマネジメント型組織は相反するものなのかというと、そうではないというのが自分の意見です。 一般に誤解されがちですが、アジャイル開発手法の代表格のスクラムでは「見積もり」と「計画」を重視します。しかも、計画は立てっぱなしではなく精度を上げるべく頻繁に更新されていきます。

アジャイルな見積もりが違うのは初期にざっくり見積もってそれが日を増すごとに正確になっていくことです。

上に示したのは、リリースバーンダウンと呼ばれるグラフです。まずプロジェクトの初期に必要な機能を一通り上げていき、すべての機能を「ざっくり」見積もります。この「ざっくり」というのがコツで以下の要領で見積もりをしていきます。

• 一通りの機能を箇条書きで洗い出していく
• 一番標準的で小さな機能を基準に選ぶ
• それぞれの機能について「基準の機能」の何倍難しそうか (ストーリーポイント) を見積もっていく
• この時点で分からないことは分からないなりに見積もる。不安であれば若干悲観的に見積もっても良い

この機能の一覧を「プロダクトバックログ」といいます。そして、ストーリーポイントの合計がプロダクト完成までに必要な工数となります。例えばグラフの例で行くと初期のプロダクトバックログには 300 ポイント分の機能が詰まっていることになります。 これを各反復 (スプリント) で消化していくわけです。例えば最初のスプリントで 42 ポイント消化できたとします。すると、同一の生産性を保った場合、およそ 300/42≒7 スプリントほどですべての機能が実装できると見積もることができます。

ここでポイントになるのは「実績」に基づいて最終的な時間の見積もりをしていることです。この実績は回を追うごとに更新されていきます。例えば上のグラフで言うと 2 回目のスプリントでは 36 ポイントしか消化できていません。この場合初期に立てた 7 スプリントという見積もりが少し悲観的になります。このままでは当初の計画を達成できないかもしれない。そうと分かればプロダクトバックログの機能の中からいらない要件を落としたり、要件のレベルを下げたりといったアクションを取り計画を修正することができます。

また、初期に「分からないなりに見積もった機能」も回を追うごとにより正確な見積もりにすることができます。データベースが決まり、アプリケーションの基本設計が決まり、一部の機能開発が終わったあとでは初期に見積もったものよりも「より多くをわかった状態」で見積もりをすることができます。定期的にプロダクトバックログの見積もりを更新していくのです。その結果、プロダクトバックログのストーリポイントが増えたり減ったりすることもあります。こうしてスプリントを重ねるごとに見積もりがどんどん正確になっていくのです。

この見積もり手法は「やってみないと分からない」ことを前提においた上で計画をする方法です。元 Microsoft のプログラマである中島聡さんが「ロケットスタート時間術」でこんなことを述べています。

最初の２割の期間を「見積もり期間」としてもらい、実際には、仕事量の８割を終える。最初の期間で８割のしごとができなかったら、期間を伸ばしてもらう。

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

最初に実際にやってみてから本命の見積もりを出すことによって、より精度の高い見積もりを出すことができるというわけです。この仕組みがわかっていると何故「ストーリーポイント」という数値を見積もりに使っているのか理解できると思います。ストーリポイントを使うことによって最初に「ざっくりした見積もり」をすばやく出し、その後も頻繁に修正することができるからです。

特に現場エンジニアからストーリーポイントの意味や利点がわからないという不満を耳にします。こうしたチームの話を聞いていると、直近の開発だけの見積もりをしている場合や、すべての要件や詳細を明らかにしてから見積もりを開始している場合が多いです。初期にざっくり見積もってそれが日を増すごとに正確になっていくという見積もり方を知ることによって、なぜポイントという間接的な値を用いるのか理由がわかってくると思います。

プロジェクトマネジメント型の組織でうまくやるために

プロジェクトマネジメント型の組織でうまくアジャイル開発手法、とりわけスクラムを導入するにはきちんと見積もりと計画づくりをして、それをレポートすることです。リリースバーンダウンをスプリントごとに更新してレポートすることでマネジメントが安心感を得てくれればしめたものです。仮に、リリースバーンダウンによるレポートを受け付けてもらえなくとも対応のしようがあります。プロダクトバックログとリリースバーンダウンがあれば、それらをもとにガントチャートに落とすことができます。ここで大事なのは、その線は「実績」によって裏付けられた線であり、日増しに精度を高めていくことができるということです。

組織のやり方を根底からひっくり返そうとするのではなく、組織にフィットする形で導入する。そうした過程で成功事例を重ねていけば自然に組織が変わっていく。 これこそ、アジャイル開発手法のアジャイルな導入方法と言えるのではないでしょうか。