今回は開発の炎上案件について取り上げます。
読者の中でも一度は何らかの形で炎上案件に関わったことがあるかもしれません。
実際に著者が関わった炎上案件を例に、炎上を避ける方法があるのかどうかを書いていきます。
炎上の定義
なんとなくはわかるけど実際定義しようとすると難しい炎上という言葉。
色々な考え方があると思いますが、私個人の経験の中では以下の状態であると考えています。
納期、品質、金額のトラブルによりクライアントとの信頼関係が崩壊した状態
納期トラブル
（例）4月1日正式リリースまでにシステムの完成が間に合わない
数多くのシステム案件に携わってきましたが、大きいプロジェクトで最初に決めた納期に間に合うなんて超レアケースですね。
世の中には見積手法として「ボトムアップ」や「ファンクションポイント」など様々ありますが結局は人が計算しているのでどうしてもブレは出ます。
リリースまでに間に合わない場合はなるべく早めにクライアントへ「リリース延長」の交渉を持ち掛けなければいけませんが、クライアントがすでにプレスリリースを打ってしまっている場合や、イベント会場を押さえていたりしてしまっている場合は調整に難航します。
品質トラブル
（例）普通に操作しているだけなのにバグが多すぎて使い物にならない
システム開発というのは普通に開発しただけだと「バグだらけ」なのが当たり前です。
プログラマーが誠心誠意がんばって単体テストをクリアしても、他メンバーのプルリクレビューを通っていても結合以降でボロボロエラーは出ます。
常々思っていることですが「一応動くもの」が出来上がってからがシステム開発の本当の闘いですね。
「一応動くもの」に対してお金と工数をかけ、テスト→改修サイクルを回すことでしか品質は上がりません。
「一応動くもの」で安心していると100%トラブルになります。
金額トラブル
（例）次回も開発を依頼するのでこの機能は無償でつけて欲しい
（例）延長になったのはおたくのせいだから追加開発の費用は払えない
背中がゾクゾクしますね。
本当によくある例です。
クライアントは常に「安く済ませたい」と思っているし、開発会社側は「工数少なく終わらせたい」と思っているわけです。
構造的に利害が対立しているのでベースがすでにトラブルの温床ですね。
で、トラブルを避けてシステムを完成させることはできるのか？
性善説と性悪説
いきなり哲学か、と思われるかもしれませんがこの概念がすごく重要だと思っています。
性善説って相手を信じるという点ですごく響きは良いですね。
一方、性悪説のほうは、人間は元来悪い生き物だから・・・みたいなイメージがあります。
でも性悪説をベースに対応する方が人間にとって優しいという意見があり、私もその立場をとっています。
人間は 'やらかす' ことを前提に進める
なぜプルリクレビューをするのでしょうか？
プログラマーが一人で書いたコードはバグがあったり非効率な箇所があったりするからですね。
これはある意味で性悪説をベースとした対策であります。
この考えを拡大してクライアントのとりうる行動に可能な限り適用してみましょう。
実際に性悪説に基づいて定義と対策を書いていきます。
夜間休日問わずいつでも連絡がつくと思っている
事前にあなたの対応時間を念押しでしっかりと伝えましょう。
（例）「恐れ入りますが弊社は対応時間が平日09:00 - 18:00のためそれ以外のご連絡は翌営業日の早い段階で回答させていただきますね。」
クライアントのためと思って下手に時間外に気を利かせて対応すると「こいつはいつでも対応する」と思われます。一度やったら終わりです。
どうしても時間外の対応をする必要があるのであればその内容と費用をしっかり決めておきましょう。可能な限り契約書に記載しておくと良いです。
もし「時間外も無償で対応しろ」と言うようなクライアントならそもそもそのプロジェクトはうまくいかないので早い段階で切り上げるよう動きましょう。
送ったメールを見ない、話も7割程度しか聞いていない、送った資料も見てくれない
悲しいことですがお金を払う側というのはもらう側に対してさほど気を遣いません。
当然、こちらが送った内容を100%は見てくれないのが普通です。
こちらの提示した内容をあきらかに相手が見ていないなと気づいたときは、都度「以前メールにも記載させて頂いた通り〜」と嫌味なくさりげなく言う癖をつけましょう。
また重要な内容を送ったあとはメールでもチャットでも電話でも良いので「〜について重要な内容をお送りしたのでご確認お願いします」と追送しておきましょう。
これは後で「見てくださいって言いましたよね？」と言えるための証拠作りです。
とくに受け入れテストの期限はしつこいくらいに連絡しておかないと、リリース間近で怒涛のバグ修正依頼がくるという地獄が待っています。
いかに相手の気分を害さないように「つつく」がが大事であると思います。
予算をケチって作業を押し付けてくる
中小企業によく見られる傾向です。
そもそも予算に余裕がないのに依頼していることが多いためこの問題は非常に厄介です。
予算がないというケースは様々なトラブルを引き起こす温床です。
（例）無償で追加作業をさせる、バグ修正にお金を払わない、支払い期限までに振り込みしない
この手のトラブルが起きるケースでは多くが「契約書」を作らず口約束で初めているケースが多いです。
小さい企業同士だと法的な部分の確認ってめんどうでやりたがらないですね。そして後にトラブルが起こったときに言った言わないの論争が始まります。
最初はめんどうでも受託開発なら受託開発用の契約書ひながたを作っておくことを強くお勧めします。
そして作業内容、期間、金額、瑕疵担保期間、運用保守があるならその内容など、しっかりと記載して双方で保管しましょう。
結局、最後にものをいうのは契約書です。裁判という悲しい闘いになった場合も契約書がないと弁護士は仕事を受けるのを嫌がります。
請負をやめてラボ型＆アジャイルならトラブルは少ないのか？
ラボ型開発は準委任契約の一種なので契約上は成果物を求められません。
人月契約で完成まで毎月分の費用を払うか、完成未完を問わずあらかじめ決めた期間で終了するか。
確かにどちらも金銭的なトラブルは少なそうです。
受けるならラボ型にしたいところですが、問題は果たして「クライアントがその契約をのむのか？」に尽きます。
完成するまで毎月費用を払う、完成していなくてもその期間で終了するというのは完全にクライアント側のリスク比重が重くなるからです。
それとアジャイルというのは双方の協力が前提ですので、言葉は悪いですが「担当者ガチャ」に外れた場合、成功確率は極端に下がります。
契約前からすでに勝負は決まっている説
相手が大手企業で予算は潤沢にあり、担当者はある程度のITリテラシーと予算感を持ち、かつ開発に協力的である。そしてラボ型開発＆アジャイルの契約を結んでくれた。
ここまでの条件が揃っていればよほどひどい開発会社でもなければ成功確率は高いでしょう。
逆に予算が少なく担当者のモチベーションやリテラシーが低く非協力的な零細企業から仕事を受ける場合はどうでしょうか？
開発会社がどんなに予防線を張りながら頑張ってもどこかでトラブルが起きる可能性が高くなります。
とはいえ、前者のような良質な契約が取れないからこそきな臭い依頼にも手を出さないといけないケースもあるわけですが、ここで一つ重要なのは「いけるかいけないか」の一線を見極める力だと思います。
顧客を見極める力も開発会社の実力である
偉そうに書いてしまいましたが、開発会社の実力は開発力だけではないと考えます。
開発を成功へ導ける顧客かどうかを事前に見極め、GO／NO-GO を出せるかどうかが重要であると。
例えばコミット力が相手40、自分たちが60まで頑張れるなら合計100で理論上成功できるかもしれません。
相手が10ならどうあがいても失敗です。
もしくは時間をかけて顧客教育をしても10→40になるとは考えづらいのでやはり厳しいでしょう。
開発の引き合いを受けたら相手を見極めるチェック項目として参考にしてください。
・プロジェクト自体の予算感
・担当者のリテラシーレベル、割けるリソース、モチベーション、協力姿勢
・担当者の上席に連絡が取れる体制か
まとめ
今回は開発案件の炎上を避ける方法はあるのか？をテーマに記事を執筆しました。
少しでもみなさまリーダーの方の一助になれば幸いです。
