プロジェクトが失敗する10の兆候

 2016/01/03
このエントリーをはてなブックマークに追加

今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。

先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。

失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている

よくあるパターン。

たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タスク以外のことに時間を使えば使うほど、そもそもタスクにかけられる時間が短くなるので進捗が遅くなる。もしくは会議でタスクが進まないので残業につぐ残業をしてなんとかしようとすれば疲れて頭が働かなくなるので、さらなる問題をつくりだしてしまうことになる。

一端悪くなってしまったら中途半端に毎日会議をするのではなく、1日がっつりとって邪魔の入らないところで問題の洗い出し、解決の優先順位付け、解決策の検討をおこなうことが望ましい。

失敗プロジェクトの兆候(2) プロジェクト開始後かなりの時間がたったのに進捗が少ない

主な理由としては以下のようなことが考えられる(他にもある)

  • 採用した技術に精通しておらず学習に多くの時間を費やさざるをえない
  • チームのリソースがプロジェクトの性質に合致していない
  • 共通化をめざしすぎてしまい、汎用ライブラリのようなプロダクトに関係ないものばかりを作っている
  • アジャイルプロジェクトであればプロダクトバックログがない。ウォーターフォールであれば仕様がなかなか決まらない

いずれの例でも、本当にプロジェクト開始可能なのかを見極めずに開始してしまったことが原因。

失敗プロジェクトの兆候(3) 自分の常識では、このプロジェクトは絶対に顧客の要求を満たした形では終わらないと思っている…

偉い人の肝いりで始まったプロジェクトなんかにありがち。 やたらとたくさんの機能要求、なぜか短いスケジュール、とりあえず数だけ寄せ集められた要員、といった要素とセットになっているケースが多い。 開発にかかわる人が最初からうまくいかないと思ってやっていれば、それはそのとおりの方向になっていく。

ただし最初から自分は失敗すると思っているのであれば最初から声をあげること。失敗したあとに「やっぱり失敗すると思ってたよ」としたり顔で言っても同罪です。

失敗プロジェクトの兆候(4) プロジェクトに絡む政治がとても多い...

「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則をご存知でしょうか。 これはシステム構成は組織構成と同じ形になるということですが、政治が多い組織はシステムにおいても政治が多くなります。 ある部門同士があまり仲がよくないとか、担当役員同士がお互いに手柄をたてたがっていて主導権の取り合いをしているといった状況をみることもあります。 もしくは、偉い人に取り入っているベンダーが必然性もないのにプロジェクトに参画してくることもあるでしょう。

このような状況では一度決めたものがあまり合理的な理由もなくひっくり返ったり、プロジェクトの向かう先が突然変わったりしがちで、失敗に繋がることが多いものです。

失敗プロジェクトの兆候(5) 中心的な役割を果たしている外部のコンサルタントが顧客の興味を満たすことではなく自分の会社の興味を満たすことを求めている…

これ別に外部のコンサルタントでなくても構いません。よくあるのが新しい技術や製品をこのプロジェクトで試してみたいというものです。 もちろん新しい技術に取り組むことは決して悪いことではありませんし、リスクを恐れて枯れまくった技術だけを使いつづける方がかえって問題になることもあります。 ただ、いままでその技術を検証してきたので「そのプロジェクトにあうかどうかは分からない」けれどもとりあえず実戦投入する、というケースもよくあり、それが結果としてデスマーチを招いてしまうこともあります。

失敗プロジェクトの兆候(6) 外部のコンサルタントがプロジェクトをひっかきまわす

業務コンサルタントや開発プロセスのコンサルタントがプロジェクトに参画することはよくありますが、 必ずしもそういった人間が、その組織固有のコンテキストを理解しているとは限りません。 コンサルタントによっては、自分の過去の成功体験だけを「押し付けてくる」こともあり、 こういったものに従っていると自分たちの思っているのとは違う方向にプロジェクトが進んでいく可能性もあります。 以前に書いた通り、外部のコンサルタントは「適切に使いこなす」必要があります

失敗プロジェクトの兆候(7) リリース日が既に1度以上延期されているうえに、現実的なリリース日を決められない

ソフトウェアに関する予測や見積りは非常に難しいので、当初想定したリリース日に間に合わないのはある意味仕方のないことです(特にウォーターフォール型の場合)。 ただし、既に一度延期したにもかかわらず、リスケ後の日程が決められないということは、 プロジェクトの現在地点が誰もわかっていない、残作業がどれくらいあるのか、なにができればリリース可能になるのかがわかっていないということを示すため、 プロジェクトとしては危険極まりないということになります。 ある単純リプレースのプロジェクト(レガシー言語からモダン言語への変更)においては、 進捗は、従来のモジュール本数やコード行数を分母として、どれくらいのコードの書き換えが終わったかを常に追跡して、それを進捗のメーターにしていました。 なんらかの測定可能なメトリクスを常にもっておくことをおすすめします。

失敗プロジェクトの兆候(8) 汎用のシステムを作ったがカスタマイズや設定が複雑すぎてメンテナンスしにくい

共通化・汎用化の罠。規模が大きくなるとどうしてもアーキテクチャを一貫性のあるものにして開発者に楽に開発してもらえるように共通化や汎用化をしなければならないことがあります。 これ自体は悪いことではありません。ただプロジェクトのあまりに早い段階から共通化・汎用化を目指しすぎて、大掛かりな先行投資をしてしまうのは避けた方が無難です。 共通化しても本当にそれが使えるかどうかはプロジェクトが進まないと分からないので、いろいろ想像して作りこんでしまうと、不要なものが含まれる使いにくいものになってしまいます。 スクラムの原則では、スプリントにおいて「ユーザーに価値のある出荷可能な製品を作る」ことが求められる(実際に出荷するかは別)ので、共通機能だけでは価値もありません。 機能を開発しつつ、適宜リファクタリングしながら共通化していくことをおすすめします。

失敗プロジェクトの兆候(9) キャッシュ機構を無効にして動かすととてつもなくパフォーマンスが悪くて受け入れがたい

これはかなり技術的なトピックではありますが、 たとえばある画面を構成するのに複数のSQLを投げる必要があり、そのうち何本かが非常に重たいのでキャッシュして逃げるといったことがあります(僕が昔みた例では、ある画面を作るのに4000回のSQLが投げられておりキャッシュしないと画面応答に1分かかったものもあった)。 こういったアーキテクチャや実装上の問題を、他のソリューションを使って臭いものにフタをして逃げているといつか破綻してしまう可能性があります。 もちろん、こういうのは技術的負債と言い換えることもできるので、早めに返済していくのがよいでしょう。

失敗プロジェクトの兆候(10) 開発プロセスがプロジェクトの初期からカオスで、プロセスを決められない

プロジェクトにおけるプロセスが決まっていないのに、なぜかもう要求分析が始まっているとか、アジャイルであればいきなりスプリントが開始されている、といったシーンを見かけることがあります。ウォーターフォールだろうとアジャイルだろうと、プロジェクトは立ち上げのタイミングが一番重要です。 プロジェクトのゴールの合意、スケジュールやマイルストンの設定、リスク管理や進捗管理のやり方のようなプロジェクト管理面での決め事や、バージョン管理システムの使い方、テストのやり方、完了の定義などの技術的な決め事も必要です。

往々にしてスケジュールがきついのでとりあえず始める、とか、とにかく沢山人を集めてなんとかするというプロジェクトほど出だしが悪く、いきなり混乱状態に陥るため、リーダーシップのある人がいないと何もかもがなかなか決まらなくなります。(政治がからむともっと悲惨です…) こうなったら一度止めて全員で決めるしかありません。

まとめ

以上のような兆候を見つけたら黙認せず声をあげること。「自分が失敗しそうだと思っている」のであれば、それを伝えるのは自分自身の責任です。

 2016/01/03
このエントリーをはてなブックマークに追加

著作

人気の公開資料

寄稿

Latest post: