今回はちょっとネガティブですが、炎上プロジェクトに関するお話です！
※炎上プロジェクトに関する記事の一覧はこちら！
カテゴリ：炎上プロジェクトのお話
これからIT業界を目指す方からすれば、夢も希望もないテーマかもしれません。
でも、泥臭い部分も是非知っておいてください。こういった局面での立ち回り方も、１つの技術です！
また昔話みたいなノリでみてくれればいいぞ
通常、お客様にシステムを提供する場合は、プロジェクトを立ち上げて、お客の要望を聞き様々なものを提供します。
遠目で見ればお客様の欲しいものを聞いて、作って収めるだけの話に思えるかもしれませんが、これがそう簡単には行かないんです。
そこには色々な人の目線・能力・立場・コスト、などなど利害関係を含めた様々な人間ドラマがあります。
今私たちが普通に使っている便利なシステムは、体を壊してぶっ倒れた、先人たちの屍の上に成り立っていると言っても過言ではありません。
では具体的にどんな感じだったのか？
昔ネットで話題になった風刺画と、私の経験をミックスして、独自の解釈をしていきたいと思います！
昔流行ったプロジェクトの風刺画
これが話題になった風刺画です。30代後半以上の方はどっかで見た事あるかもしれませんね。
この絵は、システム開発の状況をブランコで表現しています。
この絵の解釈に正解の設定はありませんが、多くのプロジェクト経験者が「あるある」として当てはまりすぎる事が、当時話題になりました。
昔は炎上してるプロジェクトの方が多かった気がするぞ
では、私の経験を例にして、この絵がどういうことなのか、１つ１つ解説していきます！
顧客が説明した要件
お客様はこういうものが欲しいという、理想だけをまとめた内容で依頼をしてきます。
基本何でも出来ると思ってる場合も多いんですが、これは当然の事です。
言ったものをそのまま作ったら本当に便利になるのか？なんていうのも当然解らないです。
というか・・この時点ではそんな事、誰も解る訳ないですよね。
このブランコの絵はまさにそんな状況を表していると思っています。
皆様はブランコの使い方を知っているので、この絵がおかしい事が解りますよね。
一瞬見ただけでもいくつか疑問が浮かんでくると思います。
例えば・・・
- ブランコに板を3つ付けて何したいの？
- 枝とロープの強度はこれで大丈夫なのか？
- 単純にイメージがずれているだけの話なのか？
ここで、意図も確認せず、悪い意味で空気を読み「口出しせずに言う通りに作ろう！」って感じで進んだとしましょう。
そうなると、意味不明なシステムが完成して、誰もハッピーにならない結果になるんです。
では、どうすべきだったのか？
ここで必要だったのは
・何をしたいか？
・何故それをしたいか？
・出来る事・出来ない事
・やろうと思えば出来る事
・どうやって実現するか？
を何度も話し合い、お互いのゴールをクリアにする事だったんです！
相手に話が伝わらなくても、何度も説明して、脳内同期する事は、一番重要なポイント！
そして話がまとまったら、資料化してエビデンス化(最終決定した証拠）するのも重要です！
エビデンスは「言った言わない」の防止策としてすごく有効だぞ！
何をしたいか？どう実現するか？何が出来て何が出来ないかを徹底的に話し合う。
そして、お互い認識に相違がないか、確認して進めていく作業を「要件定義」といいます。
忖度して要望を一方的に聞いてるのは要件定義じゃないからね！
同調圧力を食らおうが、相手の機嫌が悪くなろうとも、この部分は死守して進めるべきだったんです。
プロジェクトリーダーの理解
プロジェクトリーダーの仕事はお客様とやりたい事を話し合い、要件を詰める事です。
だけど、この人は、とりあえずブランコという「大項目」だけを理解している状況です。
以下の点はイメージできているので、何とか工夫をして調整してますが、実はこの人これで本当に動くかどうか解ってません。
・2本の枝からロープを結んでみた
・無意味な3枚の板を1枚にしてみた
ここで問題なのは、お客様の言っていた要望と、出来る事・出来ない事の共通認識が取れていない事。
さらに問題なのはプロジェクトリーダーも本当にちゃんと動作するか解っていない事。
この絵を見ると木が邪魔で動かないのは確実ですよね？
結局、動かない事に気付けずにこのまま次のフェーズに進んでいきます。
怖い！怖すぎます！
どうすべきだったのか？ その２
ここでやるべきだった事は、有識者の同席による最終確認。
もし有識者でも判断が難しかった場合は、事前検証をするべきだったんです。
もしかして検証環境でデモのような物を見せれれば、お互いの認識がクリアになったかもしれません。
ただ一昔前は良くなかった風習がありました。
お金を払って業者に丸投げして、もしうまくいかない場合は「キレれば良い」みたいなお客様が正直多かったんです。
更に言うと、有識者が動作しない事を伝えても、ただのネガティブな人だと、認識される事も多かったんです。
そして、勢いでそのままプロジェクトを進めてしまいます。
いま振り返って考えてみると、上記の様な事が原因で、コミュケーションエラーが起きていたのかもしれません。
アナリストの設計
続いてこの人は設計書をつくる人。
プロジェクトリーダーがヒアリングした内容を元に、設計書を書いていきます。
そもそも動作確認もなく、要件が間違ったまま進んでます。
しかしながら、アナリストはプロジェクトリーダーの間違った要件を、システムに無理やり組み込んでいきます。
この設計者の修正により、ブランコを揺らすことができる様になりました。
しかし、幹を切り取ってるから、枝にさらなる負荷がかかる気がするし、そもそも不自然な感じは否めません。
これも、言われた事をそのままやった結果ですかね。いや・・これでいいのか？と疑ったかもしれない。
でも「もう1回最初から要件を見直してくれ」の一言が言えなかった。
もしくは言ってみたけど「まったく問題視されなかった」可能性も考えられます。
また、本来無理な事を、強引にできるように設計した可能性もあります。
※もちろんユーザーの目線はまったく考慮されずに
プログラマのコード
次はプログラマがコードを書き始めます。
ただ、設計書に書いてある内容で、できそうなのはロープとブランコを繋ぐことだけ。
どの枝に結んでも折れる事が解り、他に結べるとこも見つからなかった為、幹に直接結んでみました。
そもそも設計が破綻しているので、これが限界だったかもしれません。
この絵をみると、ブランコを作ってみたけど、結局まともに動かないものが出来上がったと推測されます。
つまり「とりあえずできました」という状態です。この辺でそろそろ炎上が始まってるかもしれませんね。
これが、プログラマーの改修＆仕様変更地獄の入口かもしれません。
営業の表現・約束
営業は売上を作る事が使命です！それは理解してます！
でも、納品さえすれば後はなんとかなるから、まずは何としてでも売れ！
・・みたいなノリの会社がかなり多かったんです。
そうなると付加価値をつける為、必要以上に風呂敷を広げる様になります。
それがまさにこの絵！
そしてこんな事が起こります。
- できない事をできると言ってしまう
- 過剰な導入効果を約束してしまう
- 強引な差別化の為、必要無い機能を提案する
例としてブランコの提案で表現すると、豪華な椅子を、ブランコに提供する事を約束して契約をとります。
でも、豪華な椅子の材料なんてありません。
ロープと板しかないのに「豪華な椅子でよろしく！」とそのまま技術側に丸投げしてくる感じです。
売った後は、ささっと営業はプロジェクトから外れます。
そして技術側は悲鳴をあげながら、後処理をする事が、昔は結構あったんです。
数字だけを追い求めるビジネスはトラブルしか生まないのかもしれないな
成功には数字だけじゃなくお客様の笑顔も必要かもしれないね！
プロジェクトの書類
この絵は、仕様書であったり手順書がないって事なんですが、色々なケースでこうなった事が予想されます。
実際にあったのは以下みたいな場合でした。
人が入れ替わりすぎて、内容をしっているエンジニアがいなくなってしまった
仕様変更や改修がいつまでたっても終わらないので更新する意味がない。
終わりが見えなくて、それどころではなかった。
エンジニアに私の仕事じゃありませんと断られた。
実際の運用
調整に調整を繰り返し、お客様からは怒号の声が飛び交う中、やっと折り合いを付けてこうなったんだと思われます。
このブランコ座れないけど、ロープにぶら下がって遊ぶ事はできます。
最低限やりたい事だけはできる様になりました。
でも結局出来上がったのは、不便で中途半端なブランコです。
いや果たしてこれをブランコと呼んでいいのか・・？
こうなると、高いコストをかけてこのシステムを導入する意味あったんだろうか？と利用者が疑問を持ち始めます。
でもこうするしかなかったんだよ・・。
顧客への請求金額
開発やSierは、人が何時間作業をしたか？で金額を決めてます。いわゆる工数ってやつですね。
トラブルだったとしても、人が動いた分ちゃんと工数を請求しなければ赤字です。
ここまでトラブってると、作業時間が予定よりも大きく膨れ上がってる事が予想されます。
お客様の目線に立つと、納品されたのは紐1本のブランコ。営業が言っていた約束も守られてません。
なのにジェットコースターを建設したくらいの請求（人件費で）が来るので、まぁ揉めますよね。
要は成果報酬ではなく人件費の請求なんで、この辺のギャップが原因で炎上する事もありました。
得られたサポート
この絵は、ブランコの部分がないですよね？私はこの状況をこう考えています。
このシステムの運用が開始されたのは良いのですが、結局出来上がったものは、本当に導入が必要だったのか？
そして不便を感じたユーザーが、今度は悲鳴をあげて、サポートに連絡しまくります。
でもブランコの部分は変える事ができません。だって仕様ですもん。
サポートが出来る事は、「ひたすら謝る」か「仕様です！」とビシっと伝えるかくらいしか選択肢がありません。
つまり、ブランコの部分については、サポートのしようがないので、切り株なのではないかと私は勝手に妄想しました！
顧客が本当に必要だったもの
結局お客様はこれがあれば十分という話でした。
シンプルで解りやすく、ブランコよりも遊び方に幅がある。
でも揺れて遊べればOK、みたいな感じがゴールだったのかもしれません。
板や強度にこだわる必要なんてなかったのかもしれませんね。
でも、この答えをこのお客様から引き出す事はとっても難しい状況だったとも感じます。
最後に
残念ながら、今でもこんなノリの会社はまだ存在しますが、ちゃんと対策できてる会社は今では大分多いです。
現在ではこれらの対策として「アジャイル開発」という手法や「セールスエンジニア」というポジション等、今ではたくさんのノウハウが活用されています。
↓アジャイル開発やセールスエンジニアの話については、こちらの記事を見てみてください！
関連書籍（今回のテーマに近い書籍）
今回のお話でプロジェクトの炎上ネタに興味が出た方は、以下のように簡単に解説している本が結構出てるので、まずこういうのから読んでみると良いかもしれません！
