Photo by crudmucosa
こんにちは。倉内です。
前職ではSIerでSEをしており、炎上プロジェクトにもたびたび遭遇しました。
担当したプロジェクトの規模はさまざまでしたが、途中炎上せず成功を収めたプロジェクトは残念ながらほとんどありません。
一体なぜ炎上プロジェクトは繰り返し生まれてしまうのでしょうか？私がPMを務め大赤字＆納期遅延を引き起こしてしまった炎上プロジェクトを振り返りながら考えてみたいと思います。
目次
私の簡単な経歴
大学（一応情報系）→メーカー系のSIer→paiza（ギノ）
前職では、入社1年目は既存システムの保守・運用、2年目からは要件定義・設計・テストを担当し、3年目以降はPLやPMなどマネジメントをやるようになりました。
炎上したプロジェクトの概要
そのプロジェクトは、お客様が使っている他社メーカー製の業務システムをリプレースするというもので、約2年後の納期に向けてスタートしました。
開発は類似案件の経験がある、パートナー企業の開発チーム（拠点は海外）にお願いすることになりました。（大手のSIerあるあるですが開発のメインは外注さんです…）
私も過去何度か似た案件の経験があり、業務仕様については自信がありました。
開発工程で問題発生
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
要件定義・設計は順調に進み、スムーズに開発に着手…したはずだったのですが、予定していたスケジュールで実装が終わらない機能が多発しました。
遅れている機能の影響を受けてあとの機能も着手できず、さらに遅れていくという悪循環に陥り、しかも途中で主要機能の仕様変更を受けてしまい取り返しがつかない状態に…。
表面的な原因と本当の原因
開発の遅れは開発チームに原因がある！？
スケジュールの遅延は開発工程で発生したので、当初私は真っ先に開発チームに矛先を向けました。
「開発メンバーのスキルが足りないのでは？」「そもそも計画的に進めようという気がないのでは？」…など、開発チームに原因があると思いこんでいました。
今思うと本当に申し訳ないのですが、以下のようなことを言ったこともありました。
- この機能の実装、なんでこんなにかかるんですか？
- 前の案件で似たような機能、工数半分くらいじゃなかったですか？
- ちょっとここ変えたいってお客様から言われたのですぐ対応できますか？
- 品質悪くてCTでUTレベルのバグ出まくってるんですが…ちゃんとUTやったんですか？
我ながらひどい…。開発を請け負ってくれていたエンジニアの方々がよくとどまってくれたなと思います。
また、予定どおりに開発が進まないことをなぜもっと早く知らせてくれないのかと怒ったときもありました。こちらが提示したスケジュールや工数が合わないのであれば、先に言ってもらえたら対処できたのにということです。
しかし、遅延が発生している原因を開発チームのせいにして、上記のように詰めてみても状況が改善されるわけもなく信頼度を下げただけでした。
本当の原因はPMの能力不足
遅延に遅延を重ねてしまったこのプロジェクトを途中で立て直すことはできず、いったん私はPMから降り、火消し要員のPMに入ってもらいました。
プロジェクトを失敗させてしまった原因は大きく分けると次の3つだと考えています。
1. 技術力不足による見積もりと実態とのギャップ
2. 顧客コントロール不足による品質悪化原因の作り込み
3. 信頼関係の構築失敗によるコミュニケーション不全
それぞれについてもう少し詳しく追及してみたいと思います。
1. 技術力不足による見積もりと実態とのギャップ
- 要件を処理レベルまで落として工数を算出できない
最大の原因は見積もりの失敗です。新人～若手の頃に開発を経験する人も多いのですが、私は業務でプログラミングをしたことがほぼありませんでした。
そのため工数を実装レベルで見積もれず、過去の似たような開発案件の数字を引っ張ってくるか己の勘を信じるか…どちらにしても納期ありきの根拠のない、正確性に欠ける見積もりをしていました。
また、このプロジェクトは既存のパッケージを一部カスタマイズして導入する予定でしたが、実際は既存機能の大部分に手を加える必要がありました。
影響調査やテストなど想像以上に工数がかかることを理解できていなかったため、予定工数では全く足りず、実態とかけ離れた見積もりのまま、プロジェクトをスタートさせてしまいました。
遅延回復を図ろうとしたときも同様で、一体あとどれくらい工数をかければ開発を終えることができるのか見当もつきませんでした。
- 設計書の検討不十分や考慮漏れをレビューで指摘できない
PMの技術力が乏しいと設計書に考慮すべき箇所が書かれていなかったり漏れている処理ケースがあったりしても見逃してしまいます。
そうすると開発チームが「この場合はどういう結果を返せばよいのか？」「正常系は書いてあるけどエラー時の処理が何も書いてないんだけど！」といったことを逐一こちらに確認しないといけなくなります。
このやり取りが多いとお互い時間を取られますし、こちらが回答を止めてしまい、開発チームの手が止まってしまうこともありました。
当時、質問表を起こして管理していましたが、プロジェクトが終わる頃には数百件規模になっていて、お互いこれにどれだけ工数を割いたのか…と暗い気持ちになりました。
- 適切な開発体制を構築できない
適用することになったパッケージの導入案件は過去にも担当したことがあり、外注先も経験があるところを選定したため安心していました。
しかし、どういったスキルを有している人をプロジェクトに投入すればよいのか自分で判断することができなかったため、開発チームに入るメンバーについては外注先に一任していました。あとになって人の入れ替わりなどで経験者がかなり少なくなっていたことを知りました。
そもそも開発規模の見積もりが甘かったせいで、人数自体も圧倒的に足りていませんでしたが…。
2. 顧客コントロール不足による品質悪化原因の作り込み
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
- 顧客にいい顔をするのがマネジメントではない
要件定義はスムーズに終わったと思いきや、開発途中でお客様から仕様変更や要望がたびたび出されました。
よくある話ですが、1つ1つはささいに思える要望がほとんどで、どのくらいかかるかを正確に見積もることをしていませんでした。「1日でなんとかなるだろう」などと甘く見て、スケジュールや金額の交渉もせず受けてしまうこともありました。
安請け合いしてしまった仕様変更に対して、開発チームから「無理ですね」や「取り込むのに2週間はかかります」と言われて絶望したこともあります。
本来なら割り込み作業はイレギュラーでリスクも高いため、慎重に検討する必要があります。スケジュールの調整も必須でしょう。
これも結局は技術力がないから影響範囲や工数が分からず、開発途中の変更を簡単に受けてしまってたんですよね…。
- 設計書とプログラムの整合性が取れず不具合多発
開発途中で仕様変更を何度も受けたせいで設計書が陳腐化してしまい（時間がなさすぎてメンテナンスできる人がいなかった…）、テスト時に役立たずになっていました。
開発チームへ変更を伝えるときは仕様の変更をメール本文に書いたりExcelで簡単な資料を作成したりしていましたが、日本語を読める人が限られていたという事情もあり全員が同じ理解度ではなかったと思われます。
よって度重なる開発途中の変更により、仕様理解度のバラツキが大きくなり、品質の悪化につながってしまったものと思われます。
この設計書の陳腐化はのちに遅延回復を図って人を増やしたときも悪影響を及ぼし、新しく入った人の効率がなかなか上がってこない原因になりました。
そして私はコードレビューができなかったため、開発チームの成果物は画面実行でしか確認できませんでした。これが不具合を発見する工程が遅れた原因の一つと言えます。
3. 信頼関係の構築失敗によるコミュニケーション不全
- 開発チームから“技術者ではない”と認識され…
このプロジェクトを担当する以前に同じ外注先の開発チームから「最近注目されている新しい技術をプロジェクトで採用してみたい」と相談をされたことがありました。しかし、内容をまったく理解できず、もちろんどういう点がよいのか悪いのかの判断もできず却下しました。
そのとき開発チームのリーダーからは「そちらも技術者を出してほしい。技術的な会話がしたい」と言われてしまい、結果として私には技術的な話をしてくれなくなった苦い経験があります。
こういうところ海外はシビアですよね。日本人だとなかなかここまで言ってくれないので。
そういったことが過去にあったせいもあり、今回も私に相談や報告が上がってきづらかったのかなと思います。進捗管理も機能の難易度や割り込み作業をあまり考慮せず、完了した機能／全機能の数で見てただけですし…。極めつけは冒頭に挙げた暴言集です。
見積もりミスと同じかそれ以上に開発チームと信頼関係を築けなかったことはプロジェクト失敗の大きな原因でした。
失敗を繰り返さないための解決策
Photo by Helgi Halldórsson
このプロジェクトは結局、PM交代後に開発メンバーを増員し、お客様から納期延長の慈悲をいただき、3年近くかけて収束しました。予定していなかった増員と約1年の作業延長にかかった費用は……うっ…頭が……
冒頭でも書いたとおり、当時の自分は顧客業務については熟知しているし、上流工程は問題なくこなせるという自負もあり、PMとしてはそれでいいと思っている部分がありました。
しかし、「この機能の実装にはどんな技術を使って、どれくらい時間がかかるか？」をある程度現実味のある数字に落とすための技術力はまったくありませんでした。
このままではまた次のプロジェクトでも同じ過ちを繰り返してしまうと思い、それを避けるべく技術力のあるPMを目指し以下の内容を実践しました。
まずはプログラミングの基礎を学ぶ
手を動かさないことには何も始まらない！ということで、毎日プログラミング問題を解く習慣をつけました。無料のサービスをいくつか試しましたが、paizaラーニングが結構楽しんで続けられたのでメインで利用していました。
始めたときは冗談抜きで「標準入力とは…」で手が止まっていた超初心者でしたが、毎日続けたおかげでわりとすぐにスキルチェックのBランク問題まで解けるようになりました。
もちろん扱っていた業務システムは仕様も処理も複雑で、プログラミングの学習がすぐにそこで役立つわけではありませんでしたが、むしろそんな難しいシステムを開発するプロジェクトのPMが基本中の基本も分かってなかったことのほうがマズいと思ったので…。
のちに参画したプロジェクトでは、機能の実装にはどのくらいかかるかを具体的にイメージして見積もることができました。
設計と開発を経験する
設計ばかりやっていても開発工数の見積もりができないことがよく分かったため、設計書に沿って実装する経験を積みました。
実はこれはまだあまり習得できていなくて、「やりたいこと」をコードに落とせるレベルで設計書に書くことや、各機能を予定したスケジュールで実装する難しさをひしひしと感じています。
設計書を元にして開発をしてみると、自分が書いた内容では処理のパターンが網羅できていなかったり、考慮漏れがあったりと開発担当者に何度も質問させるはめになっていたこともよく分かりました。
新しい技術情報の収集を怠らない
私が担当していたのは業務システムでしたが、ブラウザで利用するWebアプリケーションだったので私に知識があれば新しい技術を取り入れて、よりよいものを作ることができたはずです。
PM自身が最新技術を知っていてかつ使いこなせるレベルまでには達さなくていいと思っています。
ただ、少なくともエンジニアと会話できる知識レベルにはなるべきですし、実際そうなったおかげで開発チームとの意思疎通が以前よりずっとスムーズにできるようになりました。
まとめ
開発経験がないままPMになってしまうと、マネジメントをする以前の話になってしまい、プロジェクトを成功に導くのはかなり難しいことが分かりました。
技術力0のPMだった自分が炎上させてしまったプロジェクトでは、開発チームのエンジニアたちに多大な迷惑をかけ、相当な無理をしてもらって納品までたどり着くことができました。現在はそのときの不甲斐なさを反省し、自ら手を動かすこと、勉強を続けることを心に刻んでいます。
私の場合はこの炎上プロジェクトをとおして学べたことも多く、残業・休日出勤祭りを差し引いてもよい経験だったなと思っていますが、中にはPMの技術力不足からくる見積もりの失敗がプロジェクトの失敗に繋がったことを認めないPMもいます。（つまりPMではなく…プログラマやテスターが悪いと決めつける…）
一方、前職でもプロジェクトでは管理側に回ることが多くなっても、日々スキルアップや新しい技術のキャッチアップを欠かさないPMもいました。SIerだからどうと言いたいのではなく、本当にその人の心がけ次第だなと思います。
PMの役割は確かにマネジメントではありますが、技術力がないことがプロジェクトの失敗を招いてしまうことがあります。技術力があって悪いことは何もないので、PMもぜひpaizaラーニングでプログラミング学習をしましょう！まずは自分の実力をスキルチェックでランクづけしてみるのもオススメです。
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
