※本タイトルは【こうなってます】炎上現場(前編)、及び【どう立ち回る？】炎上現場(中編)の続編となっております。まだ見ていない方はリンクを見てね！
前回、前々回では
・炎上現場の実情
・炎上現場の立ち回り方
を紹介しました。
この記事では【炎上の原因】と【その回避策】をご説明します。
「え、炎上の原因は『無茶な納期』にあるんでしょ？」
はい、その通りです。前編で説明した通り、炎上の原因が占める大きな割合は『不十分な納期』であることは確かです。
でもこの記事を見ている皆さん、こんな経験はありませんか？
「ガントチャート上で詳細設計フェーズと実装フェーズが被り始めた」
「最初は順風満帆だったのに、テストに入ってから急に工数が足りなくなった」
『最初から工数が足りなくて炎上した』と『十分な工数だったはずなのに炎上した』では、全く意味が違ってきます。
前者は『どう頑張っても無理』なのに対し、後者は『途中から工数が足りなくなった』のです。
つまり、後者はどこかのフェーズで失敗しているのです。
そしてその失敗は、要件定義～詳細設計フェーズで発生している事が殆どなのです。
それらの原因を、順を追って説明していきましょう。
なお、ここから先のモデルは『ウォーターフォール開発』で『業務システムを新規開発した』ケースです。
アジャイル開発やスクラム開発でも似た事象は発生すると思いますが、本題では私自身が経験した、ウォーターフォール開発の工数遅延パターンを元に記述していきます。
少し長くなりますが、開発経験の少ない方、及び設計者には、是非目を通して頂きたいです。
対象フェーズ：要件定義
断言します。ウォーターフォール開発の要件定義フェーズで顧客の要件を100%網羅することはほぼ不可能です。
考えても見てください。クライアントは普段の業務を行う傍らで、システム化するにあたり必要な業務フローを纏めているのです。これは非常に大変な事です。
要件定義はクライアントと開発側で相互に認識を合わせながら進めるフェーズであり、クライアントに協力してもらわなければ、完成形が見えてきません。
にも拘らず、クライアントの時間はかなり限られています。
そんな彼らから初版の要件を受け取っても、それはその業務における一般的なフローであり、レアケースや例外フローなどは考慮されていない場合が殆どです。
このフェーズはクライアントが提唱する要件を元に、それを深く掘り下げて詳細要件を引き出す事が本懐です。
相手の言葉をそのまま捉えて設計するだけではシステムは動きませんし、後々の工数調整も難しいものになります。
何よりクライアントとの信頼関係が希薄になり、柔軟な対応が難しくなります。
従って、この段階で『見えていない要件・仕様』をある程度推察できなければ、その開発は負け戦です。
見えない要件に工数は割かれません。どうしても満たさなければならない要件が詳細設計や実装中に割り込んでこれば、工数が足りなくなって当然です。
そしてそれは必ず【仕様変更/追加仕様】という形で後続フェーズに襲い掛かります。
「まだこんなに決まってない事があるのに、システムが完成するとお思いか？」
数多の隠れ要件を浮き彫りにし、クライアントの尻に火を付けるのです。それは我々の役目です。
対象フェーズ：基本設計～詳細設計
「行間を読む」
この言葉、現場で聞いた事がある人も多いでしょう。
「よろしくやってくれ」的な、曖昧～な言葉です。これを多用する設計者は要注意です。
システム開発は空気ではありません。実装者が読むのは設計書の文言だけです。雰囲気を察してシステムが出来上がるのであれば誰も苦労しません。
「ここはこういう意味で取ってほしかった」「こういう実装をしてほしかった」
設計者はそう言いますが、意図が正しく伝わっていない時点で、その設計書の記述に問題があります。実際に設計文面があるにもかかわらず「～してほしかった」と言うのは、設計者の我儘に他なりません。
実装者は超能力者ではありません。書いてあることを実装し、書いてない事は実装しません。それが当たり前です。
だからこそ、設計フェーズの終わりには『設計書のレビュー』というフェーズが存在するのです。
適当な記述は、必ず単体テストに支障をきたします。
認識の祖語が原因で正しい機能に実装されておらず、テストから実装へ逆走するケースは後を絶ちません。
設計書は誰が見ても同じ意味で捉える表現で書くのが鉄則です。
対象フェーズ：基本設計～詳細設計
設計の密度が高くなったからこそ出てくる疑問点は当然あります。
それをクライアントとメールなりQA表なりでやり取りをするのですが…前述したように、クライアントにも日々の業務があります。一日にそう何度も質問に答えてくれるわけではありません。
そのやり取りが何度も繰り返されている間に時間は過ぎ、気づけは仕様が決まらず実装フェーズに突入…そうなれば手戻りは目に見えています。
仕様が曖昧な機能を作るほど、空しいこともありません。
仕様未確定での実装フェーズ突入は、何としても避けなければなりません。
ここで気を付けるのは3点です。
1. 優先順位を付けること
2. 回答期限を設けること
3. その回答期限内に回答が来ない場合、『こちらの考えた仕様で行く』ことを明記すること。
特に3番目が重要です。「これで良いか？」ではなく、「これで行きます」と、こちらの意思をもった回答を迫るのです。これが議事録になり、後続のフェーズでのクライアントの無茶ぶりからメンバーを守ります。
私もクライアントの立場だった経験がありますが、通常業務が忙しい中だと、確認事項はYES/NOで答えられる方が有難いものです。
どんなに優先順位や回答期限を設けても、向こうが答えてくれないから進まない…と停滞してはいけません。
たとえ間違っていたとしても、追加工数を得られる形にして、先に進むのが重要です。
対象フェーズ：詳細設計～実装
設計フェーズが完了し、実装が開始され、プログラムが組み上がっていく…
そんな最中に投入される、クライアントからの一言
「この仕様も追加してください」
この一言を考え無しに首を縦に振るのは絶対にダメです。承諾してしまったら炎上確定です。
「これくらいなら簡単にできるでしょ」
なーんて安易に請け負ったPMの口から出てきた追加仕様が、他の機能に干渉する爆弾だったりするのです。
基本設計ならともかく、詳細設計フェーズより後続に発生したクライアントからの注文は『追加仕様/仕様変更』として扱い、必ず追加工数を見積もらなければいけません。
追加工数は勿論、算出する値は中編で記述した【4つのフェーズの合計値 + バッファ】です。
これが当然なのですが、クライアントと営業の仲が良かったりすると、何の調整も無しに追加仕様が飛んできたりします。
その場合は必ず工数を引き出す闘いをする必要があるのです。
追加工数の必要性を相手に認めさせるのもエンジニアの仕事であり、イコールそのプロジェクト内の実力であるとも言えます。
ここまで読んで頂けた方はお分かりと思いますが、炎上とは技術力の不足以上に、意思疎通の粗が引き起こすモノです。
技術を振るうだけでは、プロジェクトは成功しません。技術力も大切ですが、人同士のやり取りを御座なりにしては、成功するものも失敗してしまいます。
炎上プロジェクトを経験した方は、是非振り返って見てください。技術以前の問題がそのプロジェクトのどこかのフェーズに必ずあったはずです。
もしあなたがそのフェーズから参画できていたら、こんな燃え広がり方はしなかったもしれません。
結局のところ、炎上させない為には、炎上要因を抱えるフェーズである要件定義～詳細設計の間にプロジェクトへ参画する必要があります。
ですが困った事に、それをフリーランスで実現するのなかなか骨が折れます。外様の要員に設計を任せる事を嫌う会社は結構あるはずです。
ですから、現場に入ったら、まずはプロパーの信用を得る事が大切です。技術力でも人との折衝でも、手段は問いません。
その信用を勝ち取った上で、自分が上流工程に口を挟む事で、避けられる炎上があるかもしれません。
例え燃える臭いを感じ取っても、「自分の手で炎上を回避してやる！」という気概を持って、今後ともこの仕事で食べていきたいですね。
なんたってこの仕事、楽しいですから。
入会申込
ログイン
