筆者は、ＩＴプロジェクトにおいてプロジェクトマネジメントやマネジメント支援の仕事を受注することが多いです。
その仕事において筆者は（一応、、、）使命感を持って取り組んでおり、
プロジェクトを炎上させずにスマートに終わらせることで、自分も含めた関係者全員を幸せにする、ということを意識して仕事に取り組んでいます。
実績として、筆者がマネジメントとしてかかわったプロジェクトは、ほとんどが成功と言ってもよいかと思います。
ここで言う成功とは、
- メンバーの残業ほぼなし
- 遅延なし、本番稼働後のバグほぼ０
- 業務目線での当初の目的を達成（業務効率化など）
の３点を満たしていることです。
この話をクライアントとの面談などですると、
稀に「そんなことはありえない！嘘つきなんじゃないの？」というリアクションをされる方がいらっしゃいます。要は、ＩＴプロジェクトは炎上するものだという前提に基づいた発言のようです。
当然ですが、筆者は嘘をついてはいないです。
そこでこの記事では、筆者がプロジェクトマネジメントを行うにあたり、日ごろから意識していることを整理して、クライアントのリアクションとの差異を検討してみたいと思います。
そもそも簡単なプロジェクトに関与しているだけなんじゃないの？
クライアントとしては、プロジェクトを炎上させていない話が嘘でないとするならば、簡単なプロジェクトに関与しているだけなのではないか？と思われるようです。
これは確かにおっしゃる通りで、筆者は参画するプロジェクトを選んでいます。
面談などで事前に話を聞いて、直感的に炎上しそうだなと感じたプロジェクトは避けています。（様々なプロジェクトを選べるのはフリーランスの特権です。）
ですので、マネジメントするプロジェクトを選べない方のお立場からすると、簡単なプロジェクトに関与しているだけ、と言われてもしょうがないです。それはもう、おっしゃる通りです。
筆者がプロジェクトを選ぶ基準は？
筆者のプロジェクトに関わるかどうかの選定基準はシンプルで、筆者が最上流の工程から関われることです。
その理由は、ＩＴプロジェクトが炎上するほとんどの要因が、上流フェーズにおける成果物の曖昧さに起因すると考えているからです。
多くの上流フェーズでは、面倒な事や細かいことやは、それは後工程で詳細に検討、とか言って後回しにされることがよくあります。これだと課題を先送りにしているだけなので、後工程で炎上するのは当然です。
そして筆者は、この上流フェーズにおける、業務／システムの両面での精緻な検討を最も得意としております。
業務面では、業務ユーザが本当に恩恵を受けるような業務設計が詳細化されていること、システム面では、業務を実現するためのシステムが、技術的に実現できることをプログラムレベルでイメージ出来ていること。
そして、それらを実現するための成果物とタスクが詳細なレベル（担当者がタスクとして実施できる粒度）で、開発フェーズのプロジェクト計画として漏れなく策定されていること、リスクや課題についても漏れなく明文化されていること。
そして、これらをベースに、正確な見積（工数）を算出すること。
ここまでの作業をセットとして筆者は得意としておりますが、他の人が作成した成果物で、ここまで精緻に検討されたものを見たことはほとんどありません。
そのため、筆者が最上流のフェーズから携われることを、選定基準とさせていただいております。
プロジェクトが炎上するとはどういうことか？
そもそもプロジェクトが炎上するとはどういったことでしょうか？
筆者が考えているプロジェクトが炎上するという定義は大きく２つの視点あると考えております。
１つ目は、クライアントから見た視点。これは、新システムを導入しても当初の目的（費用対効果）を達成していないというものです。新システムを導入したけど結果的に何も変わっていないというのは、あるあるです。
２つ目は、システム開発会社から見た視点。当初の目標利益を達成できないというものです。当初の見積より工数が膨らんで人件費がかさんでしまうというもので、これもあるあるです。
そしてこの２つは密接に絡み合っていて、当初の見積より大幅に工数が増えてしまい、プロジェクトが炎上した結果、いつの間にか目的が火を消すことになってしまい、なんとか鎮火したものの、完成したシステムはクライアントにとって価値のないものが出来上がっているというよう構造になっています。これもあるあるです。
そしてここで一番重要と考えられる課題は、当初の見積りより工数が膨らむという箇所です。
筆者の経験上、当初の見積より実際の工数が膨らむ要因は次の２つです。
１つ目は、業務設計上の問題。業務設計を行った人が、クライアントの業務知識不足などで、業務上必要なシステム機能が漏れていたこと。本来、必要なはずの機能が見積から漏れているわけですから、工数が膨らむのは当然です。
２つ目は、必要な機能を実現するための技術的な観点での検討不足。たとえばシステム開発の知見が無いコンサルタントなどがシステム機能に対する工数をざっくりと見積もった結果、いざ実装しようとすると実現できなかったというものです。実現方法から再検討となり、当初の想定より工数がかかります。
プロジェクトを炎上させないためには？
まとめると、プロジェクトが炎上するというのは、上流フェーズでの検討不足、すなわち見積精度の低さに起因するので、上流フェーズでの成果物を精緻化して、精度の高い見積もりを作成し、それに基づいた計画を立てれば、プロジェクトは炎上しないです。
実際に筆者もこのやり方で、いくつものプロジェクトをトラブルなく終えてきました。
これは言い方を変えれば、能動的にプロジェクトを簡単にしているとも言えるのではないでしょうか。
最後にご紹介
IT・業界の転職・キャリア相談や仕事上における悩みなど
なんでも話を聞くサービスを行っております。
よろしければお使いください。↓↓↓
