新人プロジェクトリーダー『新米太郎』は、先日任命されたプロジェクを完了させたようだが、どうも浮かない顔で様子がおかしい。
なんとかプロジェクトは終了したようだが、当初計画に対して、だいぶコストを超過し、納期も遅延してしまったようで、結果的に失敗プロジェクトと判定されてしまったからだ。
今日は、なぜ自分のプロジェクトは失敗してしまったのか、先輩に相談している。
初めてのプロジェクト失敗
太郎：センパーイ！今日は真剣な話をしたいのですが、お時間頂けないでしょうか。
先輩：ああ、いいよ。ん？どうした？浮かない顔をして、真剣な話ってなんだい？（いつもは真剣じゃないってことかぁ？）
太郎：ありがとうございます。
実は、私のプロジェクトが先日終了したのですが、大幅なコスト超過と納期遅延を起こしてしまい、失敗プロジェクトと判定されてしまったのです。
失敗報告書を書かなければならないのですが、自分ではなぜ失敗してしまったのか整理ができておらず、再発防止の対策が思いつかないので、どうしたらいいものかと。その辺をご相談したくて。
先輩：むむむ、そうかぁ、プロジェクトを失敗してしまったわけだね。
わかった。では、状況を教えてもらって、２，３アドバイスをするよ。
太郎：ありがとうございます。
先輩：それでは、プロジェクトの最初から最後まで、大体の顛末を教えてくれるかい？
そうだなぁ、ポイントとしては次のような点を教えてほしい。
- 契約の概要
- 顧客の要件（カスタマイズ）
- プロジェクト管理は実施していたか（タスク管理、進捗報告、レビューなど）
- スケジュール遅延、コスト超過を起こし始めたタイミングと理由
- 顧客の印象（顧客側に何が起こったか）
- どうやってリカバリーをして終結させたか
- プロジェクト管理を進めていた中で、太郎君の気づき
失敗したプロジェクトの内容と進め方
太郎：はい、ポイントとしてはこのような状況でした。
１．契約の概要
- 人材育成会社にパッケージを導入するが、一部カスタマイズ開発あり。
- 要件定義（準委任契約）：1ヵ月（開発部分とは別で契約）。
- 基本設計、詳細設計、製造・単体テスト、結合テスト（請負契約）2ヵ月。
- 開発規模の初期提示見積は3.0人月相当で事前に全工程の金額提示。
- 要件定義後、再見積の提示はしていない（当初見積に変更なし）。
２．顧客要件の概要
- パッケージ製品の事前説明、評価は営業が実施済みで、若干の機能GAPがあった。
- 機能GAPを補うために、数本の新規画面と、既存帳票の改修が発生。
- 要件の概要（画面イメージ）は入手していたが、具体的ではなかったため要件定義で顧客担当者と詰める計画であった。
３．主なプロジェクト管理は実施していたか（タスク管理、進捗報告、判定など）
- 要件定義では、入手した画面イメージを具体化するために、１つ１つの項目にどの情報を出力するか、入力したい項目は何か、詳細に定義した。
- 帳票の改修は既存帳票のレイアウト変更を行い、イメージを共有した。
- 機能（画面・帳票）の要件定義が終わったので、基本設計に移り、社内ではOBPMを使ってプロジェクト管理を開始した。
- ガントチャートでのスケジュール管理も、毎週の進捗報告も実施して、上長にもきちんと報告をしていました。
途中まで特に問題も発生していなかったので、大体は「順調です！」と簡潔に報告していました。 - 工程ごとの品質チェックは必須でなかったのですが、プロジェクト内独自に実施していました。
- 出荷判定も実施し、クリアしたため、晴れて納品となりました。
４．スケジュール遅延、コスト超過を起こし始めたタイミングと理由
- 結合テストも順調に終わり、品質も良く、顧客にお披露目（仮納品）をしたときからおかしくなりました。
受入テストを実施頂くと、「思っていた機能と違う！」となり、あれよあれよと、作り直したり、再納品したり、また指摘があったりと、それを繰り返すうちに、納期が迫ってしまって、上長に相談を持ちかけました。
ちゃんとしたものを納品したにもかかわらず、顧客が「思っていたものと違う！」と言ってきたので納期が遅れました。 - 顧客が指摘してきたことを何度も繰り返し改修をしたことで、コストも膨らんでしまったのです。
５．顧客の印象（顧客側に何が起こったか）
- 顧客側に何が起こったのか、それは分かりません。
- 基本設計以後、ほとんど話をしていませんでしたし、納品したら突然「こんなものでは運用が回らない」とか、「こういう運用のパターンもあるのに、この機能では使えない」とか、結構怒った感じで言ってきたんです。あんまりガミガミ言うので、言われるままに直したのですが、何度直しても、次々と新たな指摘が出てくる始末でした。
６．どういう方法でリカバリーをして終結させたか
- 納期が迫ってきても、顧客が満足してくれなかったので、上長に相談をしたところ、急遽ベテランの「助人（スケット）先輩」が手助けしてくれることになりました。
- 助人先輩と一緒に顧客へ訪問して、じっくりと業務想定をヒアリングしてきました。
- 開発した機能をどういった運用の流れで使う想定だったのか？
- 入力パターンの数はどれだけあるのか、通常パターンすらも運用ができないのか、イレギュラーパターンのことを言っているのか？
- など、機能の話というよりも、業務の話を沢山してから、今の機能で再改修するポイントを、顧客と一緒に整理しました。
- その改修を施したものを納品したところ、満足いただけたんです。
- 納品し、運用が開始となったわけですが、そのあとも2度ほど訪問して運用の状況がどうなのか、新たな課題はないかを確認をして、問題がないということで、検収をいただきプロジェクトが完了になりました。
７．プロジェクト管理を進めていた中で、太郎君の気づき
- 開発が順調に進んで納品したにもかかわらず、そのタイミングで別な要求をされ始めたことが失敗のポイントのような気がします。
- ほんとに困ったとき、上長に相談したことで、助人先輩が手伝ってくれたことが、プロジェクトを無事終えることになったと思っています。
太郎：プロジェクトの進み方と、解決の顛末は大体こんな感じです。助人先輩に感謝しています。
先輩：なるほどね。大体の内容は分かったよ。太郎君は、プロジェクトが失敗した直接的な原因は、「品質もよく、納品した機能に対して、納品後に文句を言ってきた顧客に原因がある」と思っているのかい？
太郎：はい、それもあると思います。
とはいえ、そうなる前にも他に、何かしらの落ち度があったのではないか、とも思っているんです。社内ルールに則って、OBPMを使い、スケジュール管理も、進捗報告も、出荷判定も、本当にきちんと実施してきたつもりです。
だから、納得できない想いはありつつも、気づいていない本当の失敗原因ってどこにあったのか、アドバイスを頂きたく、先輩に相談しに来ました。
先輩：今の話を聞く限りで、気づいた点を３つほど挙げてみようか。
薄々感じている通り、納品後に顧客が文句を言ってきたことが原因ではないよね。それは結果であって、そこに至るまでに原因が潜んでいるということだ。
太郎：・・・やっぱり。
プロジェクト失敗防止のためには、上流工程のスキルを磨くべし
先輩：１つめは、そもそも要件定義を失敗していると思うよ。これはよくある話だけど、上流工程を失敗していると、必ず下流工程にそのしわ寄せがくるものだ。今回はその典型的なパターンだと思う。
太郎：どのあたりが失敗だったんでしょうか？
先輩：そうだねぇ、顧客側から画面イメージを入手したことによって、その項目定義だけをやれば、それで終わりだと、甘く考えてしまったことが要因の１つだと思う。
太郎：はい、そう思っていました。顧客がイメージまで作ってくれていたので、それをベースに、開発ができるように不足部分を決めていきました。予定通りに進んだこともあって、再見積も不要だと判断したんです。
先輩：画面項目を定義したことに問題があるわけではないよ。業務の流れと一緒に検討をしなかった点に問題があると思うよ。
各機能は、具体的にどういった業務の流れで、いつ、だれが、何を目的に利用するのか、レギュラーパターンはクリアしたとして、イレギュラーパターンはどういう運用とするのか、回避策は決めているのか、それらを明らかにし、決定事項はドキュメント化され、顧客と適切な合意が得られているのか、この辺りが重要になってくるね。
要件定義という工程は、顧客側のスキルにも影響を受ける工程だし、顧客に言われた通りのことだけやっていたのでは、抜け漏れがある可能性が高い。
今回のように、業務がうまく流れずに、最下流工程で問題が発生することにもなりえる。レイアウトを入手していたからと言って油断せずに、機能面だけでなく、業務面も併せて検討を重ねておく必要があったんじゃないかな。
確かに、業務を一番理解しているのは顧客だから、顧客が提示した画面設計案に沿って検討すること自体は悪くはない。
ただ今回は、それを鵜呑みにして、背景の業務との連携という視点での定義を怠ったことがよくなかったんだと思う。
僕たちはプロのSIerなのだから、一つ一つの画面項目の定義だけではなく、その画面の用途を理解し、各項目にインプットするための情報はどうやって入手するのか、入力のパターンはどれだけ網羅されているのか、など顧客側では発見できない、システム全体を意識したヒアリングを心掛ける必要があるんだ。
太郎：そうですね、レイアウトが出てきていたので、それさえ作れば業務も問題ないのだと思い込んでいました。機能要件だけでなく、今後は業務の流れをもっと意識するようにします。確かに、助人先輩が助けてくれたとき、最初にやったことが業務視点での再ヒアリングでした。
先輩：うん、そうだね。こればっかりは、OBPMのようなプロジェクト管理ツールを使っていてもうまくいくようなものではないから、プロジェクトの上流工程をこなすスキルを磨く必要があるね。失敗から学ぶことはほんとに多いから、きちんと分析して何が自分に足りないか、今回の経験を生かして、次回に繋げようね！
太郎：はい、がんばります！
プロジェクト失敗防止のためには、進捗報告はとても大切
先輩：２つめは、進捗報告の「内容」に問題があると思う。
太郎：え？進捗報告の内容が間違っているってことですか？
先輩：間違っているというわけではなく、進捗報告というのは、報告する相手、報告のタイミング、そして報告の内容がとても重要だということ。
太郎君の話では、OBPMでは「順調です」しか報告していないのはひどいな。社内向けの進捗報告は毎週書く、というルールは守っているようだけど、何をもって順調だと言っているのか、報告の中身が大切だということだね。特に太郎君はまだプロジェクトリーダーになりたてだから、自分が順調だと思っていたとしても、見落としや落とし穴があるから、できるだけ詳細に報告を書いた方がいい。
今回の事例でも、詳細に記載していたら、もっと早く誰かに異変を知らせることになったかもしれない。
太郎：そうですね、簡潔に書くことを意識していたのですが、簡潔の意味をはき違えていたということですね。詳細な報告を簡潔に書くように意識します。
先輩：それと、要件定義が終わってから、納品するまで一度も顧客とコミュニケーションを取っていないというのはまずいと思う。
開発の過程で、少なからず不明点や想定外があったはず。にもかかわらず、顧客へ確認を取っていないということは、「想定で勝手に決めた」と言われても仕方ない。顧客に対しても、適切なタイミングで状況報告はやるべきということだ。
今回の件でも、定期的に顧客への進捗報告や途中経過、相談事などを実施していればもっと早い段階で認識齟齬に気づけたかもしれない。
進捗報告というのは、ただ毎週書けばいいというものではないよ。いつ、誰に、何を報告するのか、そしてその中身がとても大切だということだ。
太郎：はい、そうですね、反省します。
プロジェクトを成功させる魔法のツールは存在しない
先輩：3つ目は、今回の失敗に直接関係する話ではないかもしれないが、OBPMというツールの役割を考えてほしいということ。
太郎君は、社内のルール・手法に則って、OBPMを使ったスケジュール管理や、進捗報告、出荷判定など、やるべきことはきちんとやってきた、と言っているよね。
太郎：はい、しっかりと、ルールに従ってやったつもりです。（内容が少し薄かったですが）
先輩：それなのに、プロジェクトが失敗したと。
太郎：はい、そうなんです。
先輩：衝撃的なことを言うよ。どれだけOBPMをルール通りにきちんと使っていようとも、前述したように、詳細な進捗報告をどれだけ書こうとも、「OBPMには、プロジェクトを成功させる力はない」って言うことだ。
太郎：ん？どういう意味でしょうか？
先輩：社内のルールに従ってOBPMを使っていれば、次々とプロジェクトが成功するのなら、誰も苦労はしないぜ！ってこと。我々自身が、OBPMというツールの特性をきちんと理解して、ツールを有効活用することで、結果的に、「失敗プロジェクトが減る＝成功プロジェクトが増える」ということだ。言い回しの違いと思われがちだが、結構大切なことだからきちんと理解欲しい。
先輩：OBPMという共有のツールをうまく使うということは、情報の共有化、見える化がなされるということは分かるね。「見える化」されるからこそ、計画通りに進んでいないプロジェクトや、危険な兆候が見えてきたプロジェクト、ルールを守っていないプロジェクトなどを、いち早く発見することができるんだ。
早く発見できれば、手当するのも早くなるから、失敗プロジェクトを「減らす」ということに繋がる。
OBPMを使うことで、プロジェクトが成功するのではなく、OBPMを使うことで、失敗しそうなプロジェクトを早期発見、手当することで、失敗させない。イコール、成功プロジェクトが増えるということ。
太郎：な、なるほど！ルール通りにOBPMを使えばプロジェクトが成功するのではなくて、OBPMを使うことで、失敗しそうなプロジェクトを早期発見して、失敗させないことが、結果的に成功プロジェクトを増やすということになるのか！考え方の順序って大切ですね。
先輩：そうだよ。こう考えれば、今回のプロジェクトにおいても、きちんと最新の兆候を進捗報告できていて、アドバイスをもらったり、早期に手当をしていれば、失敗を回避できた可能性は十分あると思うんだ。
太郎：はい、その通りだと思います。納品物に対して沢山の指摘を受けたときにも、きちんとした状況報告をせずに改修を続けてしまい、コストも納期も守れなくなってしまいましたが、もっと早くに報告をして、早期に手当ができていれば、また別な結果になったかもしれません。
先輩：そうそう、最後に、納品した機能に対して、顧客の言いなりで追加の改修を続けたと言っているけど、きちんとした手順を踏まずに改修してしまうやり方は感心しないね。
太郎：え？でも、指摘を改修しないと納得してくれないんですよ？どうすればよかったんですか？
先輩：これは感情論ではなく、きちんと契約上の誓約に則って振る舞うべきところだね。
要件定義で取り決めた内容から逸脱した場合とか、合意された設計書に記載のない処理を追加で求められる場合には、仕様変更扱いとする契約のはずだ。
リーダーともなればきちんと契約の条件も把握しておくべきだよ。
実際にはそう簡単に済む話でないことが多いんだけれど、指摘された内容がそもそも要件を満たしきれていないような設計ミスであったり、そもそも要件にない要求だったり、いろんなケースが考えられるわけだから、いきなり改修ではなく、きちんとドキュメント（変更管理）化して、一つずつ影響範囲や金額交渉などをして、筋道立てて対処すべきだ。
太郎：なるほど、確かに、スケット先輩がやってくれたことです。
先輩：これは海外の例だけど、今回みたいに仮納品したものに納得がいかないと指摘した顧客に対して、『良かれと思って』設計書通りでない処理、動作に変更を施して納品したという話があるんだ。これ、請求時に契約不履行で支払拒絶されたんだってさ。
契約の観点で「設計書通りの機能が納品されていないために契約不履行」だって。
うまくいったプロジェクトでもめることはないと思うけど、失敗プロジェクトの場合には、裁判に発展するようなことだってある。普段から契約の内容や約束事、ドキュメントの保管については注意を払っておいた方がいいよ。
先輩：僕からのアドバイスはこんなところかなぁ。
太郎：ありがとうございます、とても参考になりました。これで立派な失敗報告書が書けそうです！
先輩：・・・おう、そうか、がんばれよ！（失敗報告書に立派もなにもないだろうに・・・）
