今回は事例から考えるプロジェクトマネージメントのお話です！
今回は10年くらい前に公開された、スクウェアエニックスの元CTO「橋本善久氏」が公開していた資料の面白そうな部分をちょっと摘まんで記事にしてみました！
橋本氏は、初代FF14の酷い状況の立て直しに貢献し、成功に導いた事で有名な元スクエニのCTOです。
この資料は10年前に公開されていた資料とは言え、今でも十分通用する内容だったりします。
色々を事を経験した今でも、改めて見てみると共感できる事も多く、とても面白いと思ったので記事にしてみました！
もちろん抜粋する箇所、文章などはよっしーTECH流でお届けします！
普段、プロジェクトマネージメントに関わらない方でも、出来るだけ面白く読めるよう書きますので・・
是非読んでいただければと思います！
プロジェクトってなんで失敗やすいの？
導入とか開発でひどい目にあったエンジニアの方はすごく多いと思います。
なぜプロジェクトは失敗しやすいのでしょう？
大まかに言うとこんな問題が常に発生して、当初の想定がだんだん破綻してくるからなんです。
- 作業範囲の問題
- 品質の問題
- コストの問題
- 時間の問題
- リソースの問題
- ビジネスの問題
最初の計画との誤差はどれくらい？
では、どれくらの誤差が生まれるのでしょう？
2倍～３倍の誤差？橋本氏が実際に調べた内容はそんなレベルじゃないそうです。
まず、計画が変動しやすい要因を挙げてみます。
- 作業範囲が大きくなった
┗仕様の追加・変更 - タスク分解のエラー
┗タスク洗い出しの漏れがあった - 見積もりのエラー
┗タスクの完了の時間の見積を誤った - 一日あたりの作業時間見込みエラー
┗会議などで思ったよりも作業時間が取れない - 人員計画のエラー
┗人数を増やせない
┗思ったより能力がない
┗退職者・故障者の続出 - 品質マネジメントのエラー
┗品質が上がらないので作り直し - 技術面のエラー
┗実現が困難な事が解り、作り直しになった - その他たくさんの問題
そして橋本氏は実務をもとに、この要因で計画からどれくらい誤差が出ていたか数値化してみたそうです。
- 仕様追加：1.5倍
- タスク分解のエラー：1.4倍
- 見積もりのエラー：１.3倍
┗日あたりの作業時間見込みエラー
┗作業時間 －20％＝１.25倍 - 人員計画のエラー
┗思ったように増員できなかった -20％＝×1.25倍
┗思ったような能力が無かった -30％＝×1.5倍 - 品質マネジメントのエラー：1.3倍
- 技術マネジメントのエラー：1.3倍
これらを合計してみましょう。
1.5×1.4×1.3×1.25×1.25×1.4×1.3×1.3
≒10倍
えぇ！？ 10倍も誤差が出てたの！？
ちなみにこの話は多くのプロジェクトに起きている事で、蓋をあけてみると当初の計画よりこれくらいの誤差は普通に発生してるんです。
じゃあ10倍の誤差を埋めるには？
走り出したプロジェクトは止められないので、PMは10倍という数字を埋めるために考えます。
これで1.54倍分の誤差を解消！
人数を増やす事は、確実な削減にはならないが、目安として1.6倍の誤差を解消！
更に1.5倍の誤差を解消！
更に1.43倍の誤差を解消！
いったんここまで計算してみましょう。さて、どれくらい解消したかな？
1.54×1.6×1.5×1.43 ≒5倍
10倍の誤差はまだまだ解消しないどうしよう・・・これじゃリリースは無理です。
よしこうなったら奥の手だ！
これで1.8倍の誤差が解消されました。
1.54×1.6×1.5×1.43×1.8 ≒10倍
よし！調整できたのであとは頑張るのみ！これでリリースが出来る！
本当にこれ喜んで良いのでしょうか？調整した項目を確認してみましょう。
- 仕様を35％削減
- 人員を60％追加投入
- 期間を50％延長
- 品質を30％妥協する
- 労働時間を80％増やす
改めて見ると品質や想定した仕様を妥協している上に、メンバーの労働時間も大幅アップしてます。
この数値を見る限りエンジニアもきっと疲弊しているでしょう。倒れてる人もいるんじゃないでしょうか。
ここまで調整できるPMは有能です。でもいつの間にかデスマーチになってんじゃねーか！・・みたいな状態ですね。
結局この中で解決したのは「リリース出来た」というビジネスの問題だけ。
作業範囲の問題品質の問題コストの問題時間の問題リソース（人員）の問題- ビジネスの問題
結果的に予定通りにいかず、品質も落とし、チームも疲弊しているのでこれは・・
残念ながら失敗プロジェクトです
これはPMとかメンバーが無能とかそういう話ではなく、一般的な傾向です。
プロジェクトで巨大な計画の誤差が発生するのは当然の事。
この誤差を何とかするために、途方もない苦労を全力で対処し、不満足な状態で無理やり着地させている案件はかなり多いのです。
どうすれば良かったのか？
ここまで読むとプロジェクトの予想なんて出来っこないって結論なんですが、どうすれば良いのでしょう？
こんなときは逆に考えるんだ！
プロジェクトは不確実なものであるという事実を受け入れます。
問題が大きくなってから対応するのではなく、以下の対策を徹底的に行う事！
「用意周到な事前対処」と「積極的な事後対処」
まずは、プロジェクトの誤差の対策として有効な後者の「積極的な事後処理」からお話をしていきます。
積極的な事後処理
有効な事後処理とは以下２点！
- 変化や問題発生にすばやく気づく
- 変化や問題にすばやく対応する
ではどうやってこれを実現すればよいでしょうか？
一言でいうと、PDCAサイクルが有効な手段になるのですが、PDCAでこれについて説明をすると、違和感があったり解りずらかったりするので、この考え方で説明します。
Plan（計画や対策を考える）Do（実行する）振り返る（Chaeck）
要はすごく細かくこれを繰り返す事が対策。視覚化して例を挙げます。
※表現が難しいので、ここからは実際の資料と同じ絵をそのまま使う事にしました。何かあったら引っ込めて自作します・・。
余談ですが、上層部だけ非現実的な話で盛り上がり計画はたくさん立つが、現場がスルーし続けてる「PPPPPP・・」みたいなケースもよく見かけました。
・・・とここまでが失敗しやすいサイクルのパターンですが、一番推奨できるのはこれ！
この方法を使うと、問題やリスクが早い段階で見つかり対応できるので、安定してプロジェクトが進むのです。
このように細かくサイクルを回して、繰り返す事をイテレーションといいます。
この短いサイクルの話について、解りやすい例を橋本氏が書いてくれてるので、こちらも共有します。
例えばターゲットにミサイルを飛ばして命中させたいとします。
ミサイルは風で弾道がずれてしまうから、10秒に1回リモートで弾道を制御します。
しかしこれでは、軌道修正する間隔が長すぎてうまくゴールにたどりつけません。
でも軌道修正を短い間隔で繰り返すとゴールにたどり着ける可能性がグンとあがります！
短いイテレーションだけではダメ
PDCサイクルを短くする事で、このように細かい軌道修正ができるのですが、これだけではダメなんです。
サイクルを何も考えず細かく回すだけでは失敗します。
ではもし、イテレーションだけを行った場合どうなるでしょう？
この解りやすい例を橋本氏は書いてくれているので、こちらも共有します。
①イテレーションを繰り返し少しづつゴールを目指し進んでいきます
②順調に進んでいましたが、ゴール直前で手詰まりになって破綻しました。
※油断するとこれに似たような事、私もたまにやらかすときあります。
暗闇をただ歩くんじゃなくて、地図も持っておくべきでした・・
イテレーションは、足元の石ころを警戒しながら暗闇を進んでるのといっしょの事。
地図（調査・戦略・設計・計画）がないとゴール直前の想定外にやられます。
この地図にあたるのが「用意周到な事前対処」
用意周到な事前対処
事前対処とは、調査・戦略・設計・計画。不確実性を最初のうちに徹底的に潰した上で計画を立てる事。
例えばこんな感じですかね。
- グレーな部分の調査や検証をしっかりと行う
- 作業のフィードバックをかけて予測精度を向上
- 設計をなるべく詳細に行う
- リスクの高い要素を極力減らす
- 不確実を前提で考える
┗リスクの高い要素が無くても成立する設計
事前準備を綿密に行い計画する事が、プロジェクトの「地図」になります。これでロングレンジが予測できます。
さらに設計図を書いて視覚化すれば、道をどう進んでいけばよいか？のショートレンジが予測できるのです。
「設計」はプロジェクトの「双眼鏡」となる訳です。
この地図と双眼鏡を使って、ロングレンジとショートレンジの状況を可能な限り予測しましょう！
ここらでまとめます！
プロジェクは不確実性とうまく付き合う必要があります。
イテレーション（PDCサイクル）を細かく実施して、不確実性から生まれる問題の早期発見と早期解決を繰り返しましょう。
そしてドキュメント化して、１つでも多くの情報を視覚化しましょう！
調査・戦略・設計・計画にも積極的に向き合い、不確実性を下げて行こう！
え
この２点を徹底してゴールへの視界を良好にしましょう！
- 用意周到な事前対処
┗グレーな部分の調査や検証をしっかりと行う
┗作業のフィードバックをかけて予測精度を向上
┗設計をできるだけ詳細に行う
┗リスクの高い要素を極力減らす
┗不確実を前提で考える
┗リスクの高い要素が無くても成立する設計
- 積極的な事後対処
┗変化や問題発生にすばやく気づく
┗変化や問題にすばやく対応する
最後に
これは橋本氏も言っていましたが「本にこう書いてあったから」「あの人が言っていたから」をそのままやっても通用しません。
得た情報に対して、「なぜ」「どうやって」を深く考察して、自分なりのメソッド（方式）を作る事が大事だと私は思っています。
そしてこのメソッドを失敗覚悟で実験し、調整を繰り返していくことも大事なんです。
すべての情報を全力で肯定し、すべての情報を全力で否定し、情報に対して「なぜそうなのか」を貴方なりに導き出して下さい。
先人の知恵はとても大事ですが、情報があふれている今の時代に、先人の知恵はそっくりそのまま利用できません。
だからこそ、この先人の知恵にあなたの知見をミックスしたアレンジが必要なのです！
自分のメソッドを開発することは、やってみるとめっちゃ面白いのでお勧めです！
今回の記事でプロジェクトマネージメントに興味が出たらこんな本を読んでみて下さい！
