炎上する案件としない案件
エンジニアを目指すと一緒についてくるイメージのある炎上案件。 炎上する理由は色々言われがちで、マネジメントができていないから、技術力が無いから、というものは良く言われるもの。
ウォーターフォールはだめ、アジャイルで、SCRUM なら、本当に色々言われてるし、色んな手法がでてきたけど、結局炎上する案件は炎上するし、 その案件には燃える理由があるという事を認識しないといけない。
炎上とは
そもそもこの話を始めるまえに、炎上の定義が必要だと思う。
goo 辞書で意味を見てみると、1 に「火が燃え上がること」とあるが、エンジニアの業界でもこの言葉の意味で使われている。 この場合の「火」とは「トラブル」のことであり、トラブルが連鎖的に発生 (飛び火して燃えあがっていく) する事をイメージする。
そもそも何故そんなに連鎖的にトラブルが発生するのか、じゃあトラブルってなんだ、という事に問題は移っていく。
トラブル (単体の火)
トラブルとは「揉め事」のことであり、揉め事の相手は「顧客」となる。 「顧客」と表現しているけど、実際には社内プロジェクトでも炎上するので、顧客は「仕事の依頼者」くらいの認識になる。
つまり、トラブルが発生するという状態は、顧客との揉め事が発生したという話となる。 これが連鎖的に発生して手がつけられなくなってくると、「炎上」の状態となる。
連鎖的に発生するトラブル
トラブルが連鎖的に発生するなんてトンデモナイって思うかも知れない。 でも実際には「揉め事」というのは多く、しかも簡単に発生する。
「言っている事が違う」「前はこれで良いと言っていた」「出来ると言っていたのに出来ないと言いだした」などの問題や、単純な意見の食い違いから、深刻な問題まで色々ありうる。 この深刻度が様々な状態の食い違いのうち、深刻なものが抉れると、それが呼び水となって開発側に不信感を抱き、今迄許容できていたものにも我慢できなくなる。 勿論単純にやることなすこと全て駄目と最初から思われるケースもあるので、必ずこうとは言わないが、不信感を募らせた結果爆発的にトラブルが増加するのは本当によくある。 これはロジカルな話ではなく、人間の感情の部分が作用するので中々論理的に解決する事は難しく、結果「炎上」という事になる。
具体的な揉めるケースは大体は下記 3 つの内容にあてはまる。
- 機能の挙動が違う (足りない機能があるなど)
- スケジュールが遅れている
- 不具合がある
上記を見た限りだと、開発に問題があり、なんだ技術力がないから燃えるんじゃないかという考えになりそうだが、実はそうではない事が多いのが炎上を回避しづらい、厄介なポイントだったりする。
1. 機能の挙動が違う問題
顧客からの「機能が違う」「足りていない」という話は本当によくある内容で、言われた側は「言われた通りに作った」という平行線な主張になり易い。 これは完全にコミュニケーションの問題で、顧客が勘違いしないような具体性を持った方法で、実装される機能の動作を説明する必要がある。 これが出来ていないために、自分達が作ろうと思っているものと顧客が作ろうとしているものの機能が異なるハメになる。
「~みたいな機能」「~みたいなデザイン」という依頼を貰った際に、その内容のママ内部に持ち帰ったり、あいまいな表現のまま持ち帰るとこういう問題が特に起きやすい。 それは機能の仕様化と、その認証を怠る事で発生する (意図的に怠る場合と、意図せず怠る場合があるが、ここでは同列に扱う)。 定義された仕様に過不足が無いと承認 (承認の証拠は必要) を得られていれば、その通りに実装することでトラブルが発生することは無くなるので、この問題でトラブルが発生する場合は進め方に問題があったという事になる。
2. スケジュールが遅れている問題
この問題には色々なケースがありうる。
- 技術的に解決が難しい問題にあたった (局所的な問題)
- 開発チームのレベルが足りない (大域的な問題)
- 途中で仕様変更、作り直すと間に合わない
- 開発期間が短かすぎる
この中で本当に開発チームに過失が存在するのは 2 (厳密に言えばアサインした人の過失だけど) で、他は開発と別の所に問題があったりする。 1 も内部の問題に見えるが、実はこの問題を回避できたりする。
スケジュール問題 1：技術的に解決が難しい問題 (局所的)
一部の機能の実装で、システム全体の兼ね合いや、ベースに使ったシステムでサポートされていない問題など、様々な原因があるが、実は仕様の調整で問題ではなくなる場合がある。 その為、実装担当者が仕様的に難しいと判断した時や、かなり無理な実装をする必要があると思った段階で、顧客にその件を報告し、迂回策を提案する事が望ましかったりする。 仕様は絶対だという主義のチームでこの手の問題でスケジュールを遅らせて燃やすケースは多々ある。
一番良いのは見積り、仕様洗い出し時点で難しいポイントが特定できており、その検証を開発期間、費用に組み込んだうえで第 2 案 (プラン B とも言う) を用意する。この第 2 案は技術的に難しいポイントを仕様で回避する内容にする (確実に回避出来る見込みがない場合は複数プランを出す)。
スケジュール問題 2：開発チームのレベルが足りない
この問題は実はそんなに多く発生しなかったりする。 というのはあまりにも自分達の組織で出来ない難題を仕事として請ける所はそうそう無いため。 本当にチームの開発技術が未熟である事が原因の場合、案件を請けたことや、アサイン自体が間違えている事になる (最初から無理なチームだった)。
ただ、案件受託時に確証のあるものや経験のある開発のみ請けるという事は普通はなく、案件獲得時にはメンバーの成長見込みを含めた上で請ける事がほとんど。 そのため、その見積り (無茶な成長を狙ったこと) が間違っていた、という事になる。
この場合、回避策は開発チームのメンバーでは出来ない事を正しく認識し、それを出来る人を連れてくる (社内 or 社外) という事になる。
スケジュール問題 3：途中で仕様変更、作り直すと間に合わない
開発案件では途中が仕様が変更される事は良くある。 そのため、炎上した理由として一番多く挙げられる原因かもしれない。
仕様変更の問題が一番面倒な揉め事ではあるが、大体の場合は目先の話のみで仕様を決定するなどしてしまうために発生する問題だったりする。 顧客の「言葉通り」のシステムを作る時にこういった事が発生しやすく、本来仕様を策定する際にはその言葉の先にある要求を拾わないといけない。そのためには顧客と同じ視点に立てるだけの知識とそれなりの経験 (ドメインの話) を持つ必要があり、顧客がシステムを通してやりたい事、表現したい事を認識した上で、より良い仕様に昇華する必要がある。
また、顧客の「言葉」を仕様に噛み砕く作業をしない場合も「炎上」を呼ぶ一因になる。 仕様書に求められる内容は、誰が見ても同じものを認識できる曖昧性のないロジカルなもので、「~のようなもの」や、「~を参考に」「いい感じにする」等は仕様ではない。 これを仕様と思っている人が多くいる (仕様と思っていないがこういう資料しか書かない人は仕様を作っていない事になるので一番悪質) が、それはアイディアレベルのものである。
仕様をうまく書けない場合、顧客によほど恵まれるか、開発メンバーに恵まれない限りほぼ確実に炎上する。 それくらい仕様は大事となる (仕様を通しての顧客とのコンセンサスが重要という話)。 さらに、仕様を策定する際にエラーケース等、通常想定の使い方以外をした際にどうなるか、悪意を持たなくても発生しやすいもの程ここで詰められないと本当に苦労することになる。
ただ、あまりに細かい仕様は最初期のフェーズで詰めようとしても無駄になりがちなので、ある程度 (少なくとも正常系の動作を定義する程度は欲しい) 作成したら、一旦実装、動作検証、顧客からのフィードバック、仕様 FIX という流れがオーソドックスだと思う。 とくに最後の仕様 FIX のフェーズが大事で、この時点で一度確定させ、ここで細かな情報を仕様として盛り込んでおかないと、後々細かな仕様が不明になり論争の種になったりする。 仕様のアップデートをせず、納品まで仮作成時の仕様のまま放置されるなどが炎上の引き金になるので注意するポイント。
スケジュール問題 4：開発期間が短かすぎる
端的に言うと、見積りが明らかに間違っているケース。 とはいえ、見積りをどれだけ頑張ってもピッタリうまく行くというのは余程の練度がない限り難しい。
良くバッファ (空きのこと) を持たせるという話もでるが、バッファというのも本来の意味からするとおかしな話である (開発期間に余分な期間を入れる意味は顧客に説明できない)。 開発をする際、下記のようなステップが必要になり、それぞれである程度の期間が必要になる。
- 見積り
- ヒアリング & 要求分析 & 仕様策定
- 工程洗い出し
- スケジューリング
- 開発 (随時ドキュメントの作成も含まれる)
- 内部テスト
- 受け入れテスト
これだけある工程のいくつかは小規模の案件では省略されがち。 本来は見積りの際にこの工程全ての期間を考慮した上での金額と期間を提示するべきなのだけど、顧客側の強い要望によって色々なものが省略されることもある (勿論開発側がこの体制を何故かとっていないことも良くある)。
金額の減額交渉や納品までの期間の短縮交渉など (ひいてはその両方も) が顧客から良くある要望なのだが (この時点ではまだ要望)、仕事を取るために応じる事は良くあることなので、その際に上記項目が暗黙の内に削られることとなる。
その際には、本当は削られる分だけ何かが犠牲になるため、依頼してきた顧客にはその説明と納得をして貰うようにマネージャーは動く必要があり、それが出来ない場合は、内部の努力によって無理矢理捩じ込む事となる (そういう分かり易く駄目そうなものは、見積り段階から「炎上案件」と呼ばれたりする)。
不具合がある場合
不具合がある場合は請負の場合、瑕疵担保責任 (かしたんぽせきにん) が発生し、修正する義務が生じる。
そのため、修正するコストを開発側が負担する必要があるため、この修正で稼動した分は請求する事はできない。 不具合が軽微なものであれば、すぐに直してチェックにまわす事ができるが、重篤な不具合の場合は直ぐに納まらず、延々と顧客に怒られながら修正対応をする事になる。
正直、不具合のケースでは回避策というものはなく、いかにこれ以上燃やさずに後始末をするかになってくる。 現開発チーム (プロジェクトマネージャー含む) で収拾が付かない雰囲気があるのであれば、チーム外から人を連れてきて、不明瞭な仕様の洗い出しと、不具合の洗いだしを先に行なう必要がある。 この時に闇雲に修正作業を行なってしまうと、後でとりかえしの付かない不具合が別の箇所から出る事もありえるため、一旦作業の手を止めて、状況の精査と顧客とのやりとりを優先する事が先決となる。
また、修正作業の際に、顧客から修正に乗じて追加作業を依頼されたりもするのだが、直り切っていない時に追加機能を入れると更に状況が悪化するため、この状況のときは絶対に受け入れてはいけない。
結論
プロジェクトマネジメントは基本的にプロジェクト内での QCD が適切に定義されていないと滅茶苦茶になることがある。
一般的には上流 (この呼び方はあまり好きではないけど) と呼ばれるフェーズは非常に重要な役割を担っており、ここで転けている場合は全て開発に皺寄せがくることになるし、開発が始まる前から不穏な空気が漂うことになる。 また、上流工程の人間がプログラムを書けなくても問題ないという意見などがネットで見られるが、上流のみ担当し、プログラムが書けない人間が間に入る事で、顧客とのコミュニケーションが全く上手くいかず、大変な抉れかたをすることも多々ある。 そのため、上流工程のみを担当する人間は開発速度や生産性という部分では能力を求められないが、実際にプログラムを書く人間よりも幅広い知見と技術を持っていないと、開発メンバーの発言の意図が汲み取りきれず顧客に間違った話をしてしまう事がある。
ただ、プロジェクトマネージャーはプログラムを必ずしも書ける必要はなく、適切に顧客や開発チームの両方とコミュニケーションができ、両者の利益が最大になるようなバランス感覚を持っている事が重要だと僕は思っている。 その為、プログラマからプロジェクトマネージャーに昇格という文化は、マネージャーがバランス感覚を欠いている上に、マネジメントという専門技術を訓練せずに転職するに等しい行為のため、炎上を増やす仕組みに見えてしかたない (もちろん上手く人も多くいるが、それはその人が凄いだけで流れが適切という話ではない)。
本来適切にマネジメントすることで回避できる案件が非常に多いのを会社を立ち上げ、色々な業務に関わってくる事で非常に強く感じた。 立ち上げる前はチームの動かし方など、チーミングに近い方に関心が強かったのだなと思う。
