プロジェクトの失敗を繰り返さないためには、精神論でなく技術的な管理 手法が必要である。 本書では、とかく精神論になりがちなテーマである「プ ロジェクト管理」について、 テンプレート (雛型) を作成しながら体系的に 説明する。この章のテーマは、プロジェクトのオーバーランの原因と対策、 スケジュール表の作成方法とそのテンプレートである。プロジェクト管理の 3要素の中でも最も失敗の多い「スケジュール管理」の手法を体系化していきましょう。
プロジェクトの失敗に学ぼう
「人間はロボットじゃないから過ちを犯す」 と言う。 日頃、コンピュータ の仕事に携わっている身からするとロボットだってミスも故障もすると思う が、とにかく仕事でも人生でも失敗は付きものだ。 もちろん、 失敗しないよ うに心がけることが一番で、 本書もそのために書いているのだが、 どうして も失敗をゼロにすることはできない。 であれば、 大切なのは失敗した後の対 応・対策と言えようです。
決して失敗しないことが金メダルであれば、失敗したときに適切なリカバ リーを行なえることが銀メダルである。 しかし、実はこれもなかなか難しい。 いったんプロジェクトがおかしくなってしまった場合、その状況を冷静に判断できずに対処を誤り、ますます泥沼化してしまうことが少なくないのであ る。 では結局、 銀メダルもとれずに、失敗プロジェクトをどっぷりと味わっ てしまったらどうしたらよいか?こんな場合でも、そこから何かを学んで 次につなげることができれば、かろうじて銅メダルに値します。
情けないのは、同じ失敗を繰り返すことだ。 あるプロジェクトで納期遅延 したのに、次のプロジェクトで同じようにオーバーランを繰り返してしまう のだ。この原因としては、失敗の原因を客観的に把握できていない、プロ ジェクトリーダーやメンバーの資質力量が不足している、組織的にプロ ジェクトが失敗しやすい体制であるという構造的問題など、さまざまな要因 が考えらます。
そこで、まずプロジェクトがオーバーランする原因を客観的に捉え、その 対策を具体的手法にまとめることにしよう。プロジェクトの失敗に学ぶとい う銅メダルからスタートし、同じ失敗をしないという金メダルにたどり着くのであります。
オーバーランのリスクをチェック
「開発プロジェクトがオーバーランする原因にはどんなものがあるか?」 この質問をプロジェクトリーダーやサブリーダーに投げかけてみよう。 経験 豊かなプロジェクトリーダーであれば、いくつかの原因を客観的に整理して 答えられるはずだ。もし、責任転嫁的な甘い回答しか得られないようであれ ば、その人がリーダーをやっているプロジェクトは失敗のリスクが大きいか「開発プロジェクトがオーバーランする原因にはどんなものがあるか?」 この質問をプロジェクトリーダーやサブリーダーに投げかけてみよう。 経験 豊かなプロジェクトリーダーであれば、いくつかの原因を客観的に整理して 答えられるはずだ。もし、責任転嫁的な甘い回答しか得られないようであれ ば、その人がリーダーをやっているプロジェクトは失敗のリスクが大きいかもしれない。
開発プロジェクトの工程が遅れてしまう原因はいろいろあるが、 代表的な ものを表1のチェックリストに示す。 自分の携わっているプロジェクトの中 で該当する項目がいくつあるかチェックしてみよう。5つ以上当てはまると したら、何らかの手を打つべき段階と考え、対策を検討してほしい。
オーバーランをしないために
では、このようなオーバーランの問題を繰り返さないためには、どのよう にすればよいかを一緒に考えていこう。 結局のところ、プロジェクト体制や 要員、品質など多種多様な問題がすべてスケジュールとコストに跳ね返るの であるが、この章ではその中でも直接スケジュールに関わる問題を取り上げ る。要員外注管理やコスト管理など他の要因については、次章以降で順を 追って考えていきましょう。
スケジュール表を作成・更新する
プロジェクトのスタートにあたり、 スケジュール表を作成するのは当たり 前のことと思えるが、意外にきちんと作成していないケースが多い。 また、
スケジュール表は作成したものの、最初に書いたままの状態で放置し、 実際 の進捗と乖離しているのにスケジュールを立て直すことをしないリーダー いる (T1)。 プロジェクトリーダーに選任されたからには、 ①適切なスケ ジュールを立て、 ② メンバーの進捗をきちんと管理し、③遅れていたら適切 な指示を出す、という3つくらいは最低限実施してほしい。
テンプレートを持ち、使用を義務付ける
エンジニアという職種は、職人気質で我流を好む。 他人の作ったプログラ ムなんかは、 「え、ひっどーい。 こんなの作り直しだ!」 とすぐに自分流に 作り直したがる。 その習性のせいか、 放っておくとスケジュール表もプロ ジェクトごとに多種多様なものができてしまう。これらの自己流フォーマッ トは、綿密すぎてメンテナンスが大変だと思われるものもあれば、 シンプル すぎて「これで何を管理できるのか」 と思わせるものもあります。
組織としての効率化を実現するには、スケジュール表のテンプレートを用 意し、すべてのプロジェクトで記述・管理手法を揃える必要がある。 大切な のは、テンプレートを持つだけでなく、 その使用を各プロジェクトリーダー に徹底させ、使いにくいところがある場合はテンプレートを改良するという フィードバックの手段を用意することである。 とにかく “自分流が一番” と 思い込んでいるリーダーたちに、「スケジュール管理表テンプレートの使 用を義務付け、 「使いにくいところがあったらフォームを直すから、意見を 出すように」と通達するのであります。
スケジュール表の作り方
それでは、スケジュール管理表のテンプレートを作成してみよう。 ここでは、 図1のようにプロジェクト全体のスケジュールを示す 「総合スケジュール」と サブシステムごとに作成する 「詳細スケジュール」、そしてプログラム単位の 進捗管理に使用する「機能別スケジュール」に分けて作成する。 作業項目(縦 欄)のまとめ方や日程(横欄)のメッシュなどは、プロジェクトごとに異なる 場合もあるので、これらのテンプレートをカスタマイズして利用してもらいます。
総合スケジュール
プロジェクト全体のスケジュールを1枚に表わしたものが「総合スケ 「ジュール表」 である。 できるだけ一覧性を重視してまとめることが大切で、 1次開発、2次開発とフェーズを分けた開発プロジェクトでも、時期がそんな にずれていなければ1枚で表記する。 表2は、 PYRAMIDの総合スケジュール のテンプレートで、 ウォーターフォール型の開発例を記載している。 上部に マイルストーンを記述し、客先とベンダ (自社) の役割分担も一目で分かる。 各フェーズの工程は、上部に計画、下部に実績というように予実対比型にす る場合もあるが、総合スケジュール表は「プロジェクト全体の計画」 を表わ すものなので、計画(予定)だけの方が一般的であります。
詳細スケジュール
前述したように、総合スケジュール表はプロジェクト全体の計画を記すも のなので、大雑把すぎてプロジェクトの進捗管理や作業内容の把握には不向 きである。作業内容の詳細設定と進捗管理に使うのは「詳細スケジュール表」 であり、こちらは原則的にサブシステム単位で作成する。ここで言うサブシ ステムとは、トータルシステムを機能別に大きく分類したものであるが、 ハードウェアやネットワークなどの基盤構築作業もアプリケーション開発と は別のサブシステムとして取り出したほうが管理しやすい。 表3は、詳細ス ケジュール表の例である。 総合スケジュール表と比べると、縦欄の作業項目 がより具体的になっていて、 その作業分担も明確になっている (T5)。 詳細 スケジュール表は、計画と実績を対比させて作業の進捗管理に利用するのが 普通であります。
機能別スケジュール
実際の担当者ごとの作業管理は、もっと綿密に 「機能別スケジュール表」 をベースにフォロー・管理される。この表は、1つひとつの機能ごとに作業 工数を算出し、担当者を決めて具体的な日にちを割り付けたものである。つ まり機能別スケジュール表は、進捗管理表として使われるものである(T3)。 表4は機能別スケジュールのテンプレート例である。 各機能の難易度に基づ き、詳細設計とプログラミング&単体テストにかかる工数を見積もり、各担 当者の作業日程を細かく定めている。このテンプレートでは、詳細設計とプ ログラミングという2つのフェーズを一緒に管理しているが、もちろん、こ の2つをそれぞれ別の表で管理してもよい。 また、基本設計や結合テストな ど、他のフェーズでもこのような機能別スケジュールを作成し、具体的な日 程管理を行なうほうが好ましい。 その場合の機能のくくり方は、それぞれの フェーズに合ったものとなります。
3種類のスケジュール表を規模により使い分ける
3種類ものスケジュール表を作成するかどうかは、プロジェクトの規模に よる。規模が小さい場合は、表6のように2種類または1種類のスケジュール で間に合わせることができる。 そもそも、総合スケジュール表と詳細スケ ジュール表は一体のものだ。本来タスクは階層構造となっており、総合ス ケジュールのタスクの内訳に詳細スケジュールのタスクが含まれている。 つまり、タスクをツリー構造にできるスケジュール管理ツールを使うよう であれば一本化できる。 しかし、ここで示すExcelテンプレートのように、 詳細タスクを切り出して別スケジュール表として管理する方が使いやすい 場合もあります。
規模により作成するスケジュール表を使い分ける
まとめ
さて、最後にもう度この章の鉄則を復習しましょう。 当たり前のことばかり であるが、なかなか実践できていないことでもあります。
- 過去の失敗から学び、 同じ失敗を繰り返さない
- チェックリストで失敗リスクを認識する
- スケジュール表を必ず作成し、定期的に見直す
- 進捗は数値で管理する
- 4種類のスケジュール表テンプレートを利用する
- 機能別スケジュール表は、 前フェーズの最終段階で作成する
- 進捗ミーティングは定期開催ルールを決めて
本章では、プロジェクト管理の基本となるスケジュール管理について、 4つのテンプレートを元に説明した。 スパイラルモデルのスケジュール表や数 値ベースの進捗管理表などもこの後の章で紹介します。
オーバーランのリスクを把握して、失敗しないように気を付けてほしい、しかし、それでもどうしようもなく泥沼化してしまう場合があるのがプロ ジェクトの難しいところです。 そんな現場ではもはや会話もなく、 生気の抜け たゾンビたちが情性のようにモニタに向かって作業しています。勤怠も悪くな り、ぷっつんして出社拒否になってしまう人が、1人、 また1人と。。。
そんな最終段階でプロジェクトリーダーはどうすればよいのか? 筆者の 場合は、ただただ明るく元気に振る舞うことにしています。(ただのアホみたい だが……)
詳しくは、NALまでお問い合わせ ください。