ソフトウェア開発におけるプロジェクトマネジメント手法を工学的にアプローチするメモを流しておこう。ちなみに、この記事には「モチベーション」という言葉は出てこないし「スーパープログラマ」も「カリスママネージャー」も出てこない。あくまで工学/自然科学的なアプローチで解決をしようという話である。ある意味「働き方改革」も出てこない。
前提条件
「プロジェクト」とは何かというところからスタートするほどでもないが、この手法には前提条件がある。
- WBS/チケット/タスクが全て消化されれば、プロジェクトが終了する
という条件が必要になる。一見当たり前のように見えるけど、研究プロジェクトや目的達成型のプロジェクトの場合にはこのマネジメント手法では無理がある。研究プロジェクトは数々の試行錯誤が必要なので、チケットに対する時間効果が判別つかない。また一定の目的を達成する（製品販売数とかユーザー数目標とか）プロジェクトの場合も、達成するまでにいろいろな試行錯誤が出てくるので、形式的なプロジェクトマネジメント手法は向かない。この場合は、（おそらく）イノベーションマネジメントになると思う。こっちの方はまた別の機会に書くことにする。
WBSあるいはチケットあるいはタスクは、何らかの仕事の「粒」となる粒度ともいう。面倒なので以後「チケット」で用語を統一するが、それぞれの違いは
- PMBOK的にトップダウンで仕事を出す場合は「WBS」
- ボトムアップ的に仕事を出す場合は「タスク」
- チケット駆動の場合は「チケット」
ということになるが、ひとまとめにして「チケット」と呼ぶ。
このチケットの数や大きさ（作業期間や外注金額など）などは、プロジェクト開始以降から変化してもよいものとする。PMBOKの場合は事前にWBSを出し切る要請があったりするが、ここでは後からWBSを追加可能とする。タスクの場合も同じ。あとから追加要望とか見落としとかでタスクが増える場合も考えられる。
主に受託案件を考える
適用範囲は主に受託案件を考える。社内製品開発でもよいのだが、社内の場合はもう少し制約が緩い場合が多いので、厳しいほうで試してみるのがよいだろう。受託案件の場合、顧客から予算と期間が区切られることが多く、単純なアジャイル開発による「交渉」機能がうまく働かないことが場合が多い。大幅に機能が増加されていれば予算枠を増やす交渉をすることも可能なのだが、ちょっとした機能追加とか受託側の都合による機能追加/見落としなどでの「仕事」の追加では追加予算が出ないのが普通だ。よって、
「チケット」が増えたにも関わらず、「予算」や「納期」が動かないことが多い。
むしろこちら側であるはずの「営業サイド」から値下げ要求や期間短縮、コストダウンなどを要求される場合が多いというのが受託開発でのソフトウェア開発での特徴だ。
この場合「マネージャー」もあちら側に回ることもできるのだが、今回はこちら側に回ることにする。あちら側にまわるやり方は色々出ているので試してみるといい。お勧めはしないが。
これにより、受託開発で案件を受けるときの条件として
- 開発期間、納期が決まっている。
→ よって、無理なスケジュールを強制されたときは、最初から拒否する。
- 予算の上限がある。
→ よって、無理な予算を強制されたときは、最初から拒否する。
- 開発すべき機能が決まっている。
→ よって、無理な機能追加/拡張が要求されたときは、最初から拒否する。
ということにする。「無理な」というのは、あきらかに開発期間が短かったり、低予算すぎたり、夢のような機能がてんこもり、という場合のことだ。最初から失敗するプロジェクトから逃げるというのは有能なマネージャやリーダーの鉄則だ。もちろん、あちら側に回ればそういう案件を受けることも可能であるのだが、それは（以下略
さて、達成できそうな受託案件が目の前にできたとしよう。「達成できそうな受託案件」というのは、ほどよく顧客からの要望がでてきて、QCD（機能、コスト、納期）の概算ができたときに限るという訳だ。ここで問題になるところだが、これは2つの問題を内包している。
- 受託開発案件における妥当なQCDをどうやって出すのか？
- 妥当なQCDの開発プロジェクトを「成功」させるためには、どうしたらよいのか？
まるで、鶏と卵の問題のようだが、この2つは同時に解決する。というか同時に解決しないといけない。
計画と工程管理を一度に検証する
具体的な手順を示そう。
１．初期の条件として「無理のない」QCD を考える。ここは初期値なので、勘で適当に決めて良い。あるいは、顧客の状態を考えて、ざっくりと予算と納期（開発期間）を決めてしまうのがよい。よく営業さんが言う「ざっくりと」で良い。
２．社内で開発するチームの「チケット」の消費スピードを決める。理想は１チケット２，３時間程度なのだが、１チケットが１日でもよい。１日以上のチケットを考えるとプロジェクト実行時に誤差が多くなるので、１日以内におさめたほうがよい。
例えば、１日３チケット、期間が半年、メンバが５人と考えれば、
３ｘ２０ｘ６ｘ５＝１８００チケット
ということになる。
３．総チケットのうち、20%から30%ぐらいが「予備」のチケットとなる。予備というのは不確定要素を吸収するためのチケットで、プロジェクトを進行したときの変更要求とか機能が膨らんだときの仕事を吸収するためのチケットである。20%から30%ってのは経験上のもので、これはよく言われる「プロジェクトの予算を1.2倍から1.5倍するとよい」と同じことになる。いわゆる逆数だ。0.2/1.2 ≒ 17%、0.5/1.5 ≒ 33% となる。
残りの仕事のためのチケットを使って１で見積もったときの機能実装などを割り振る。WBS的にトップダウンで割り振ってもよいし、ボトムアップ的にタスクとして割り振ってもよい。それぞれの期間が揃っているほうがいいのだが、あまり気にしなくてもよい。重要なのは最初から割り振られているチケットの数になる。最初から割り振るチケットは「必ずやらなければいけない仕事」なので、優先度が高い。
ここでチケットが足りなくなったり、予備チケットを使い始めたらダメだ。最初の１の「ざっくり開発期間」が間違っていることになる。ざっくりの部分をざっくりと直して、２のチケット数を増やしていく。
逆に、すべての仕事チケットを埋める必要はない。概算の概算として設計工程/実装工程/試験工程で3つの山に分けてしまって、設計工程のチケットだけ書いてみるという方法でもよい。空白チケットがあってもよい。
計画段階ではこれでおしまい。ここで、おおむねチケット駆動のシミュレーションがおわってる。
- トータルのチケット数（予備を含む）
- 開発期間
- 人数
が分かったので、１日（あるいは１週間）で消化するチケット数が計算できる。これが「生産量」になる。
４．プロジェクトが進行している間は順次チケットを消化する。チケット駆動のツールを使ってもよいし、ひとりプロジェクトならば Excel だけでもよい。
仕事チケットを日々消化すると同時に、予期しない仕事があれば予備チケットを使う。顧客からの要望が増えれば予備チケットを使う。営業からの要求があれば予備チケットを使う。増えたら予備チケットを使う。
仕事チケットが大幅に膨らんでしまった場合は、複数の予備チケットに分割する。当然、予備チケットではない空白チケットがあればそれを使う。考慮不足を補うのが空白チケットや予備チケットの役目だ。空白チケットはもともと予定されているけど内容が書かれなかったもの（面倒だったとか、書く時間がなかったとか）、予備チケットはいわゆる「プロジェクトバッファ」分のチケットのことになる。
５．進捗管理（工程管理）は、実際のチケット消化数と３で計算した事前のチケット消化状態と比較する。順調であれば傾き（バーンダウンチャート）は同じぐらいになる。実際の消化数が多い場合は特に問題はない。ちょっとぐらい遅れていても問題はない。総チケットの上に行かなければよい、かつバーンダウンチャートの予想直線を引いたときに総チケットのラインよりも傾きが浅くならなければよい。
予備チケットの分だけ保険が入っているので、進捗はこの間をうろうろすることになる。
バーンダウンチャートを引いたときに、赤い線より上に出そうであれば、プロジェクト進行を見直すことになる。
「生産量」を上げることはできないので（突如として「生産量」があがるという幻想は捨て去るべきだ）、
- プロジェクトメンバを増やす
- 仕事チケットを減らす（開発機能を減らす）
- 仕事をする時間を増やす＝休日出勤
ことになる。当然、開発予算を増やす交渉や納期を後ろに倒す交渉もし始める。休日出勤は緊急避難的なのでカンフル剤としてか使えない。一瞬しか進捗は良くならない。受託案件の場合、予算や納期が変わらないことが多いので、先の２点が対処になるだろう。
以上の５ステップで、計画と進捗管理はおしまい。
利点
このプロジェクト管理での利点は、先に書いた通りメンバのモチベーションとかやる気とかコミュニケーションとかの不確定要素が一切出てこない、それに頼らないことだ。それらはチーム開発では必要かもしれないが、必ずしも高度なものである必要はない。一般的にできれば十分だ。少なくとも、受託案件のような場合には「標準的な生産量」の測定が重要になるので、不確定要素に頼らないほうがよい。
欠点
これは利点と同時に欠点でもあるのだが、この方式にはミクロな視点が入らない。チケット同士の関連やなんらかの要因による「生産量」（チケットの消化スピード）の低下を予測できない。スケジュール管理自体がメンバ任せになってしまうので、効率の悪いチケットの消化をしてしまう可能性がある。
当然のことながら、規模が大きくなる場合は、
- チケット同士の関連性（PERT図）
- マイルストーン（ガントチャート）
が必要になってくる。この2つの図はおいおい活用していくとして、ガントチャートは「チケットの増加に素早く対応できない」という大きな欠点がある。チケットやタスク、WBSを増やしたときにガントチャートを修正するのが難しいため「ガントチャートが直せないから、チケットを増やさずにガントチャートのスケジュール通りに行動する」という本末転倒な心理が働いてしまう。これでは駄目だ。これはツールによる制約があるので OpenCCPM で解消していきたい点である。
おわりに
メモなのでまとめはいらないのだが、作業見積もりの20%増しとか50%増しとかで顧客に提出するとき、その保険が削られて営業サイドで勝手に値引きされてしまうことがある。お客の前で「値引き」すると案件が取りやすいからね。営業テクニックである。仕方がない。なので、見積もりを出す側（マネージャでもリーダーでも誰でも良い）では営業の値引きが明らかになっている場合は、あらかじめ「値引き」の値段だけ予算に加えておけばよい。値引き自体に根拠はないのだから。
また、予備チケットや保険の分が「顧客」に理解されないときは、計画段階や進捗管理で「二重帳簿」を作るとよい。二重帳簿は Excel などを使って自動計算すると簡単に作れる。
- 顧客や営業にとって安心されやすい「進捗」グラフ
- プロジェクトメンバがリスク管理できる「進捗」グラフ
を二種類用意するわけだ。超概算見積もりも同じパターンで作ることができる。その話は別の機会に。
