みなさん、プロジェクトの振り返りは実施していますか？
「プロジェクトの振り返り」とは、文字通り、プロジェクト完了時にそのプロジェクトの開始から終了までを回顧し、評価や反省をすることです。
プロジェクトの振り返りとは？
振り返りの対象となるプロジェクトが失敗した場合、失敗の原因は何だったのか、今後失敗を繰り返さないために何か対策はないか、といった事などを分析します。
プロジェクトが成功した場合においても、反省点が一つもないプロジェクトというのは、なかなかありません。（少なくとも、私がこれまで従事してきたプロジェクトにはありません・・・）。
また、プロジェクトが成功した要因はどういうポイントだったのか、反省点だけでなく、良かった点を分析するのも振り返りの一つといえます。
今回は私(以下、筆者A)の実体験をもとに、「プロジェクトの振り返りを実施する」際のポイントや、振り返りから気づいた、プロジェクトの遂行において重要な事を考察していきたいと思います。
case１：プロジェクトの振り返りは”速やかな”実施を！
とあるプロジェクトでの1コマです。登場人物は以下の3人です。
・部門長
・上司(プロジェクトリーダー)
・筆者A(プロジェクトメンバー)
設計からリリースまで約1年半の大規模システム開発プロジェクトSについて、成果物の納品、お客様の受入テストまで完了してまもなく、筆者Aは上司からこんな事を言われました。
上司「長かったプロジェクトがやっと終わったね。結合テストを実施してた頃は品質がボロボロで一時はどうなる事かと思ったけど、何とか納期には間に合ってよかった。振り返り会を実施しないといけないけど、 今は他のタスクも忙しいし、とりあえずプロジェクトメンバーで打ち上げしよう！筆者Aくん、いい感じのお店の予約頼むよ！」
上司の曖昧なお店探し指示はさておき、この瞬間、上司と私の中では、プロジェクトSの振り返りを実施しないといけない、といった考えはあったものの、プロジェクトが終了した安堵感から振り返りを無意識に後回しにしていました。
打ち上げは盛大に行われ、それから時は流れ・・・。
プロジェクトSの終了から2ヶ月が経過したある日、プロジェクトSのリーダーである上司は部門長からこんな事を言われました。
部門長「そういえば少し前に終了したプロジェクトSだけど、結合テスト時の品質が相当良くなかったみたいだね。よくよく見てみたらプロジェクトにかかったコストも当初の計画からだいぶ超過してるし、プロジェクト全体を振り返って、何が悪かったのか分析してもらえるかな？」
上司も私も忘れていたわけではなかったのですが、他に優先するタスクもあり、2ヶ月が経過したここまで振り返りは未実施でした。
上司はすぐにプロジェクト関係者を招集し、プロジェクトSの振り返り会を実施しました。
しかし、ここで問題が発生。振り返りを実施したものの、プロジェクト遂行当時から時間が経過していたため、断片的な記憶しかなく、問題の深掘り・分析ができないのです。
上司「ここの画面のテストが不自然なほどに作業工数オーバーしてるけど、これって何が原因だったんだっけ？」
筆者A「そこは確か性能の問題があって・・・あ、実際に作業を担当した パートナーさんに聞いてみましょう！」
上司「おっと。あのパートナーさんは先月で契約終了してるね・・・」
このような有様です。このケースでの問題点はいくつかありますが、もっとも致命的な点はプロジェクト終了から振り返り実施まで時間が経ちすぎている事です。
人間の記憶は個人差こそありますが、コンピュータとは違い、時間とともに薄れていくものです。よって、より効果的な振り返りを行うにあたって重要なことは、「プロジェクトは終了次第、速やかに振り返りを行う事」 であると考えます。
もし、速やかに実施できない状況や事情がある場合、対策の１つとして、記憶を記録により補完する方法が挙げられます。弊社のプロジェクト管理ツール「SI Object Browser PM（以下OBPM）」では、 障害や課題の詳細な原因や、プロジェクト途中における経緯などを記録しておくことが可能です。
具体的には、プロジェクト途中での経緯は【進捗報告登録】機能により、保存することができます。
【進捗報告登録】機能では、登録時点での進捗遅延率、残障害数、コスト超過率などといった自動計算される数値に加え、その瞬間における定性的な報告内容も記録できるので、あとで振り返りを行ったときに、
・あの時期に何が起きて進捗遅延が発生していたのか
・あの時期に何が起きて品質が低下していたのか
といった経緯を振り返ることにも適しているといえます。
また、通常では、プロジェクト完了時における各作業タスクの進捗率は全て100％になりますが、進捗報告を登録すれば、登録時点におけるガントチャート(各タスクの進捗状況)、採算情報なども保存されるため、より詳細な振り返りを行うことが可能です（下記画像内の赤枠で囲んだ部分）。
このように、ツール等を用いて過去の経緯を記録しておく事で、人間の記憶をある程度補完することは可能です。しかし、例え記録を行っていたとしても、記載のレベルは担当者により様々であり、どこまで人の記憶を補完できるかは計り知れません。記録することも大切ですが、やはり、効果的な振り返りという意味においては、振り返りを早く実施するに越したことはないのです。
case２： プロジェクトの振り返りで得た”気づき”
case1とは別の、とあるプロジェクトでの1コマです。
登場人物は以下の2人です。
・上司(プロジェクトマネージャー)
・筆者A(プロジェクトリーダー)
私がリーダーとしてプロジェクトに関わり始めて1年余り、その中の１つ、500万円規模のパッケージ改修プロジェクトZが完了してまもなく、プロジェクトマネージャーである上司とリーダーである私が、プロジェクトの振り返り会を実施している場面です。
上司「いや～このプロジェクトは見事に失敗してしまったなぁ・・・」
筆者A「ですね・・・最終的な赤字は・・・100万円近くになってしまいました。納品後の受入テストでもお客様からのクレームを数件頂いてしまいましたし・・・」
上司「原因を細かく分析しないとね・・・」
何やらどんよりとした雰囲気が漂っています。それもそのはず、このプロジェクトZは最終的な納期さえ守られたものの、当初予定してたコストに対して、実績のコストが大幅にオーバーし、最終的にはプロジェクトの利益がマイナス97万円の赤字プロジェクトとなってしまったのです。上司と私が原因を分析したところ、製造工程、および成果物納品後の受入テスト工程で大幅なコスト超過が発生しており、それが最終的なプロジェクトの赤字につながっていました。さらに詳細な分析が続きます。
上司「まずは製造工程のコストオーバー原因だけど、経緯を振り返ってみると、製造工程に至る前の要件定義、設計工程に関しては進捗推移も順調だし、コストの超過も発生していないね。製造工程自体も進捗推移は順調なのに、コストだけが超過しているね。どうしてだろう？」
筆者A「う～ん、実はこのプロジェクトZのパッケージ改修は、以前、別のお客様に対して行ったパッケージ改修プロジェクトYとカスタマイズ内容がほぼ同じだったので、その時の見積をベースに見積を作成したんです。プロジェクトYはとても良い結果を残し、社内でも表彰を受けたほどのプロジェクトだったので、この見積で失敗するはずは無かったのですが・・・」
上司「たしかに、改修対象の機能も各機能の見積金額もほぼ同じだね。どちらのプロジェクトも筆者Aくんが要件定義と設計を行っているし・・・ん、でも待てよ。以前のプロジェクトYの製造はベテランSE1名と若手PG2名が担当しているけど、今回のプロジェクトZの製造は、若手PG3名が担当しているね。原因はもしかしてこれ？」
上司の推察どおり、以前成功したプロジェクトYと今回失敗したプロジェクトZを見比べてみると、対象となる改修機能(＝モノ)、改修にかかるコスト(＝カネ)は、ほぼ同じですが、誰が改修を行うか(＝ヒト)という概念が見積にまったく反映されていなかったのです。今回失敗したプロジェクトZに関わった若手PG3名も優秀なメンバーであり、毎晩残業をして頑張り、なんとか計画通りの進捗を維持していました。しかし結果的には、ベテランSEが含まれているチームと同等の生産性で製造を行う事はできず、コストが膨らんでしまったというのが原因でした。
まだまだ振り返り会は続き・・・
上司「次に受入テスト工程のコストオーバー原因だけど・・・なぜ、あんなにクレームを受けて、日々対応に追われてしまったんだろう。」
筆者A「製造工程のコストはオーバーしてしまいましたが、品質的には問題なく、納品前の内部での結合テストも結果は良好でした。しかし、おっしゃるとおり、受入テストに入った途端、お客様から数件のクレームがあり、その原因のほとんどが双方の【仕様認識齟齬】でした。これも、以前のプロジェクトYではこのようなことは起きなかったのですが・・・」
上司「じゃあまたさっきと同じように２つのプロジェクトを比較してみたら良いんじゃないかな？」
筆者A「先ほどの教訓を活かして・・・あ、違うところがありました！これも同じく”ヒト”になるのですが、この場合、お客様が以前のプロジェクトとは異なります」
上司「うんうん、もう少し深掘りしてみようか。」
今度は私自身が原因に気付きましたね。以前成功したプロジェクトYのお客様はIT系の企業でしたが、今回失敗したプロジェクトZのお客様は非IT系の企業でした。私は成功したプロジェクトYの手法を踏襲し要件定義を行い、要件定義書のフォーマットや記載レベルも当時のまま、要件を握ったつもりでした。
しかし、要件定義書に書かれていない仕様や、私が当たり前だと思っていた表現が通用しなかった事が、結果的に受入テスト時のお客様との【仕様認識齟齬】につながり、コストオーバーの原因となってしまいました。お客様と会話するとき、お客様向けのドキュメントを作るとき、いかに相手が持っている常識や前提を意識できるかがポイントになる、 それを痛感した瞬間でした。
今回の失敗プロジェクトでの振り返りにより得た”気づき”、それはプロジェクトにおける”ヒト”要素の重要性ではないでしょうか。どんなに同じ”モノ”を作り上げるプロジェクト、同じ規模すなわち”カネ”で遂行する プロジェクトであってもそこには必ず”ヒト”が介在します。今回のケースでいえば、この”ヒト”を意識していませんでした。見積、つまり計画の段階でこのプロジェクトの失敗が確約されていたといっても過言ではないといえるでしょう。
OBPMでは過去に完了したプロジェクトの情報もデータとして蓄積され、瞬時に検索をすることが可能です。例えば、過去に取引実績のあるお客様に対して追加の案件が発生し、その計画を立てる際、【プロジェクト一覧】の検索時に「顧客」を指定する事で、そのお客様に対する過去実績を参考情報としてリストアップすることが可能です。
上記の一覧表示の段階で、指定した顧客の過去案件における実行予算(内部コスト)や、プロジェクトの利益率を確認することができます。例えば、軒並み利益率の低いプロジェクトばかりが並んでいる場合は、難易度が高い顧客という見方ができ、新規案件の見積時に細心の注意を払う必要があるといえます。（もちろん、そのような判断とはならない場合もありますが、一つの傾向として）
また、各プロジェクトの詳細を確認したければ、上記の一覧からプロジェクトメニューに遷移し、当時の見積（実行予算）や最終採算結果の詳細を確認する、といった事も可能です。ここまで行えば、誰がどの機能の開発を担当し、どのような計画と実績であったかを細かく分析することもできます。 これらの過去実績を参照しつつ、”ヒト”を意識した計画を立ててみてはいかがでしょうか。
プロジェクトの振り返りを計画に役立てる
ここまで、２つのケースについて、振り返りを絡めてご紹介しました。
OBPMには【PJ登録】画面の「完了情報」タブにおいて、プロジェクトの振り返りの結果を記録する欄があります（下記画像内の赤枠で囲んだ部分）。
弊社では実際にOBPMを用いてプロジェクト管理を行っていますが、弊社のOBPM運用ルールにおいても「プロジェクト完了時、原則1ヶ月以内にプロジェクト評価を登録する」というルールがあります。また、case1にて「速やかな振り返り実施」というポイントを挙げましたが、一定期間、完了処置が実施されていないプロジェクトについては、プロジェクトリーダーに対してOBPMの機能でアラートメールを送信する、といった試みも行われています。
「過去は振り返るな」という言葉も場合によってはかっこいい言葉ではありますが、人間は失敗する生き物であると同時に、反省から学び成長する生き物でもあります。
プロジェクト振り返りの結果を記録し、それをノウハウとして蓄積することにより、未来のプロジェクトの計画に活かしていく。それが結果としてプロジェクトの成功を増やす事につながっていくのではないでしょうか。
私自身、まだ現役バリバリのSEであり、この記事を書いてみて、プロジェクト振り返りの重要性を再実感したところです。
これからも振り返りを継続することによって、出来る限りリスクの少ないプロジェクト計画につなげていく！そう決意した次第です。
