炎上するプロジェクトの特徴
Tweet
プロジェクトはなぜ炎上するのか。。。
ちゃんと計画すれば、炎上なんてしないんじゃないか？と思う人はたくさんいると思います。
しかし、開発とはいつも同じことをするわけでもなく、全ての環境が違うため、いつも同じ計画だけでは失敗します。
今回、炎上プロジェクトにかかわることがあり、関わる前に以下を読んだので、
上記の本を読んだうえで、私が考え、
そして、私が出会った炎上プロジェクトの特徴を上げていこうと思います。
管理ができていない
計画も管理の一つではありますが、管理ができていないことが炎上プロジェクトのもっともたる原因です。
開発は開発者がいれば回るというバカ経営者（取締役）がいたりしますが、全く違います。
もしも、開発者だけで回るとしたら、3ヵ月未満で終わる開発です。
それ以上となる場合には、必ず管理者が必要です。
「プロジェクトのトラブル解決大全」でも、最低限の管理部分として出てくる項目に対し、
管理ができていないとはどういうことか上げていきます。
スケジュール管理ができていない
まずはスケジュール管理です。
客先から来たマスタースケジュール（マイルストーンなど）をもとに、どのようなものが開発できて、それはどのようなスケジュールかを出します。
重要なのは、スケジュールでどのようなものが開発できるかです。
決して勘違いしてはいけないのが、必ずしもスケジュール内で開発がすべて終わるわけではないということです。
客先からくるマスタースケジュールは単純にリリースしたい時期、お金から算出された開発完了時期が提示されます。
その完了時期＝開発完了と判断してはなりません。
客先と上記のようなスケジュール調整をするため、管理者は必要となります。
これをせずに、客先から来たスケジュール＝開発完了とすると無理のある開発スケジュールとなって炎上します
タスク・進捗管理ができていない
全体的なスケジュールができたら、タスク・進捗を管理します。
誰に何をしてもらうかを決定します。
これは、誰に何をやらせてもいいというわけではありません。
開発者のスキルを理解し、その人であればできるとその人に確認した後にお願いします。
お願いするときは、アウトプットを意識し、どのようなものを作ってほしいかを説明します。客先から来たものを丸投げしてはいけません
また、タスクについて俯瞰的に何があるかを理解しておく必要があります。
目の前の開発だけではなく、付随したタスク、隠れているタスクを見つけ出すことも管理者の役目です。もちろん開発者も隠れたタスクがあれば連携してもらいますが、横のつながりを理解し、俯瞰してみるのは管理者の仕事です。
タスクを見つけられていないと、後からやることになり炎上します。
また、開発者のスキルを理解していないと見積もり以上の工数がかかることになり、炎上が近づきます。
そんな時はちゃんと進捗管理をしておく必要があります。その人に渡したタスクが合わなかった場合、その作業に人を加える、もしくは、別の人に割り振る（巻き取らせる）必要があります。
「頑張れ」と言って作業を続けさせているのは管理ができていない証拠です。
なお、進捗管理については、「作業量」を管理するモノではありません。
誰が何をどの程度やってるというのは基本どうでもよいのです。
もちろん、タスク管理として、Bさんが何でも出来るから何でも任せようというのも無能ですが、作業量を調べるような管理をすると、メンバに多くの時間を取らせてしまい、かつ、作業量で管理できるのは終わった工数となるので非常に無駄です。
進捗管理としては、スケジュール・見積もり通りに、タスクをこなせているかを管理するだけで問題ありません。
Aさんが100%やっていてBさんが120%やっている程度であれば問題ないです。
もし、120%あることによって、進捗が滞っているのであれば、その時考えればよいのです。
ですので、タスク・進捗管理として誰が何をできて、タスクは何があって、誰に渡すかを正しく行わなければ炎上します。
「誰が何をできて」の部分はリソース管理という人もいるかもしれませんが、リソース管理は、これでは開発ができないという場面になるかどうかなどを管理するモノだと考えているため、タスク管理に入れました。
課題管理ができていない
課題管理とは、開発するうえで出てきた問題を管理するモノです。
メンバ数が少ない場合や枯れたものの修正などであれば管理していなくても問題ないですが、問題が発生した時にそれを忘れないように保持し、誰が何をする必要があるか、明確にしていない場合、その問題は忘れ去られるでしょう。
そして、後から対応することになり、炎上することになります。
また、課題管理をチケットシステムやエクセルを用意すればよいと考えている人もいますが、実際は違います。課題管理は管理者でそれを解決まで導く必要があります。
それには、その課題に対し、「次の作業は何」で「ボール（その作業）は誰が持っているか」「いつまでに対応できる（する必要がある）か」を考えてもらい、課題を回す必要があります。
基本、開発メンバは課題を挙げるだけになります。その後、それを回すのは管理者なのです。
課題について、「その課題を一発で解決するにはどうすればいいか」という考えを持ってしまうと、結構な割合で解決しません。課題は一歩ずつ、作業を進めるのがコツだと思います。
その他：管理できてないとよくないもの
スケジュール、タスク・進捗、課題以外に管理すべきものを上げておきます。
前述した三つよりも優先度は低いので、余裕ができたらやっていければよいと思います。
（決してやらなくていいものではありません）
リソース管理
タスク・進捗管理の部分で軽く触れましたが、リソース管理はPMの重要な管理タスクです。
メンバはもちろんですが、開発ツールなどについても管理すべきものとなります。
それが、テストで必要なサーバであったり、開発に必要なアプリであったり、物理的な道具（スマホなど）であったりします。
これらはタスク・進捗管理や課題管理で解消されることも多いため、リソース管理という一つの管理タスクとしては重要度は低いものとなります。
なお、スキルマッチしてないため、メンバの交換を持ち掛けるのも管理者の仕事です。
あまりにも使えない人を開発に入れておくとプロジェクトが健全でいられません。
申し訳ないですが、新卒や、若いメンバについて、必要ない、足手まといの場合に離れてもらう必要があります。
営業や人事が「OJTだから！」「いつまでもどこにも入れないと成長しない！！」などと言ってくるでしょうが、関係ありません。
それでプロジェクトが失敗するのと天秤にかけた場合、どう考えてもプロジェクトの成功が優先です。
リスク管理
作業に対するリスクを管理するモノです。
例えば、見積もりに関して、良くなかった場合、機能を落としますというところを客先と調整しておくものです。
これら、リスクについて客先と握っていない場合、単純に失敗となり、損害を請け負った会社が払うことになります。
変更管理
仕様が変更された場合の管理となります。
ウォーターフォールの場合には、スケジュール変更もあり得ますので、大々的に行う必要があります。
アジャイルの場合には、何がどうなったかを一覧化する程度で問題ないと思います。
これがないと、前はどうだったのに今はこうなっているという話になり、言った言わないが発生していきます。
その他：よくない管理
私が経験したものとしてあったのが、12名規模の開発でテックリーダを2名、PLを1名、PMを1名という場所で、テックリーダにタスク・進捗管理をやってもらっていた時に、全くできず、炎上しかけたとき、「テックリーダにやらせられない」「PMは何をやっているんだ」となり、てこ入れが入りました。
PLに私と、もう一人入り、テックリーダは開発に専念してもらうことになったのですが、会社の意向で、PMが3人増え、PM4人体制になりました。
このPM4人体制というのがとても大変でした。増えた3人はPMPを持っているようだったのですが、やり方が全員ばらばらで、最終的にはPM1名になるまで辞めていき、減りました。
頭がたくさんあると、管理方法がぶつかり合い、まともに管理ができなくなります。
基本的には私ともう一人のPLでプロジェクトを回していました。
あの時のPMは本当にPMPを持っていたのか疑問です。。。
管理が細かすぎる
管理をするためには、メンバにアウトプットを出してもらう必要性があります。管理者だけが忙しいのであればいいのですが、メンバに管理のための作業をやらせるとなると、開発が滞ります。
例えば、タスクが変わったときに一回10分の作業だとしても、（タスクが細かければ細かいほど）塵も積もれば山となるという言葉が当てはまり、6回変われば1時間です。
それが、20日あったら20時間です。3人日弱が一か月で使われるわけです。
無駄すぎますよね。。。
要件を客先と握っていない
開発は誰のためにするかと言われると、 お金を出してくれているお客様のために作ります。
ということは、お客様の望むものを作る必要があるわけです。
それをお互いに認識合わせせずに、開発する場合、認識齟齬が起こり、言った言わないのケンカレベルでひどいことになります。
そんな人たちが大抵やっていることを記載します
要件定義がわかってない
そもそも、上層部に要件定義がわかっていない人が結構います。
機能要件と非機能要件の話を持ち出すとはてなマークを頭に出したり、正直に「何ですか？」と言ってくる人がいます。
もちろん、その上層のSLO(Service Level Objective)/SLA(Service
Level Agreement)の話なんてもっとできません。
作るものがなんとなくわかり、開発を始めているため、後々、リリース開始するときに問題が発生するため炎上確実です
開発知識のない人を客先の窓口・調整役にする
開発について知識がない人を、客先の窓口にしているプロジェクトは大抵炎上します。
炎上していないプロジェクトは、下層部の開発者たちがめちゃくちゃ頑張っているプロジェクトです。
知識のない人間が窓口・調整役となった場合、全て受け入れて戻ってきます。
そして言うのです「これは客から来た決定事項です」「これでやるしかありません」と、、、
大抵、知識のない人間は上（客）には弱く、下（開発者）には強く出ます。
上層部と下層部について、それが上下関係と勘違いしているためです
要件定義がわかっていないというところでも同じようなことが言えますが、客先と調整しようにも知識がないため、調整する内容が分かりませんし、仕方もわかりません。
開発者から、「どうなってますか？」と言われても、「なんですかそれ？」と逆に質問を出すような状況になります。
そして、そんなことを開発者から聞いている時には、もうやらなければならない状態になっているため、グダグダになりつつやることになるわけです。
知識がないのであれば開発者に聞いてもいいでしょうが、プロジェクトが始まる前に、まず何をすればいいのか整理しなければなりません。
それができないというのは、「知識がない」で言い訳できるものではありません。
仕様書を大事にしない
仕様書は開発にとって「神様」です。
本来、開発の全てと言ってもいいものです。
開発者は、仕様書に従って実装し、仕様書に従ってテストし、仕様書に従って品質を担保するのです。
なのにもかかわらず、仕様書をないがしろにするプロジェクトが多いです。
修正したら仕様書を直さない、仕様書に書いてあってもバグとする、そもそも仕様書を書かない、そんなプロジェクトをいくつも見てきましたが、大抵、問題が発生していました。
仕様書がなければ、本来テストはできません。
実装は客先と調整しながら作れるかもしれませんが、テストは不可能に近いです。
もしそれでテストをするというのであれば、動作確認となり、品質を担保するモノではなくなります。
さらに、炎上すると、開発最優先になります。
そして、「仕様書は後から」と言っていたにもかかわらず、「次の開発があるから」と仕様書の修正が許されません。
見積もりが上手く出来ていない
最後は、見積もりが上手く出来てない場合です。
これは、開発するうえで、いつもそばにあるリスクです。
開発はいつも同じではありません
そのため、開発するのにどの程度の工数が必要かは、管理者、開発者の想定（知見）が主な検討材料になります。
そのうえで、できるだけ実工数と見積もり工数の誤差をなくす必要があります。
そのためには、「開発者を含む、複数のメンバの意見を聞く事」「実現方法（機能要件）を検討する事」が必要です。
何を開発すると聞いて、とりあえずで見積もりを出し、要件定義で再度見積もりを出すというのがよくある方法かと思っています。
ただし、上記でも炎上することがあります。
それは、とりあえずの見積もりと要件定義後の見積もりの差分が大きかった場合です。
私はこれで、めちゃくちゃ大変な思いをしました。
「とりあえずの見積もり」としては何も決定事項として握っていないとなっていたのですが、要件定義後の見積もりで差分が大きく、「なぜだなぜだ」と裏どりを永遠とやらされました。
私が入ったのは、炎上後だったので、「とりあえずの見積もり」は無視し、いまの見積もりが正しいかメンバから話を聞きつつ対応していきました。
最終的には要件定義後の見積もりは正しく、機能を削って、スケジュールに合わせる形になりました。
それでも、結構無理があるスケジュールで、不満は大きいものになりましたが、これ以上は譲歩できないということで、会社同士で決定されてしまいました。
まとめ
いかがだったでしょうか
今回は炎上するプロジェクトの特徴を 「プロジェクトのトラブル解決大全」と私の経験をもとに話させていただきました。
多少の炎上がたまにあるのはいいですが、がっつり炎上するプロジェクトは絶対に管理がよくないです。
しかも、管理者がよくないので、全て開発者のせいにしたりしています。
プロジェクトがうまくいかないのは基本的に管理者のせいです。
それがメンバを管理している人なのか、プロジェクト全体を管理している人なのか、もっと上層なのかはありますが、、、
Tweet
コメント
コメントを投稿