失敗から学ぶことは大いにあります。
私もIT業界に長きにわたり身を置き、様々な失敗をしてきました。
失敗の数だけ成長もしてきたと思います。
その数々の失敗を公開する事で他の皆さんの何か助けになれば幸いと思って、「SE失敗物語」を書いてみました。笑ってみて頂ければ幸いです。
この話は西暦2000年、まだまだWebシステムが走りだった頃の時代です。
かなり時間は経過はしていますが、この失敗は現代でも活用可能です。
いやぁ、あの時は本当に辛かった・・・昼休みにご飯食べれなくて一人で公園のブランコに乗ってたりしたなぁ。
改めて振り返ると色んな意味で若かったなぁと思いつつ、今の自分にとって非常に良い教訓を得た出来事です。
こうやって文章化して見える化する事で、自分にとっての「しかみ像」になる内容です。
納品後に「こんなシステム頼んでない！」と大問題になる
さて、まずはトラブルの内容を説明します。
営業が謝罪しにいき、要件定義から全て無償でやり直しとなり、当初の工数の6倍のコストを追加費用無しで開発する事になった。
こんな内容です。よくあると言えばよくある。しかし当時まだまだ駆け出しの自分にとっては非常に大きな失敗でした。まさしく自分を追い込むのに十分な失敗でしたね。今思えば「大したことない」と言えば語弊がありますが、こんな初歩的なミスはしません。
しかし、この初歩の初歩に非常に大切なエッセンスが詰まっている訳です。
とてもシンプルなシステムの想定だった
ではでは、どんな案件で失敗したのでしょうか？
2000年といえばWebアプリ黎明期。今となってはレガシーと言われるASP全盛期です。言語はVBA。
案件の内容はいたってシンプルです。EXCELで管理していた顧客情報をRDBに入れてイントラでWebシステムにして検索出来る様にしたい案件です。
これだけです。
本当にシンプルですねぇ。なんでこんなシンプルな案件でこんな状況に陥ったのでしょうか？
ここなんです。ここが本当に当時は若かったと思います。
それでは問題が発生するまでの出来事を時系列で並べていきます。
プロジェクト開始の状況
本案件は私が派遣で行っていた会社先の案件でした。派遣して一番最初に任されたプロジェクトがこのプロジェクトでした。
そこで既に受注している案件としてアサインされた訳ですが、既に顧客から発注されていて金額、納期が決まっている案件でした。
アサイン後営業からこんなことを言われます。
営業「空飛さん、明日この案件でお客さんに要件を聞きに行くからよろしく」
私「え？まだ要件決まってないんですか？」
営業「大丈夫、納期に合わせて出来る機能だけで実装すれば良いから」
私「そうなんですね。わかりました」
どうですか？違和感しかない会話ですよね。
違和感その1 要件のヒアリングが出来ていないのに発注が来ている
まず、これから要件を聞きに行く案件なのに既に発注書が来ている。そうなんです。金額と納期が決まっているんです。
どういう事？
今となってはホラーでしかないです。
誰がどうやって見積もったんでしょうか？
実は納期ありきで営業が人月だけで金額を出していたらしいんです。
納期まで1ヶ月だから〇〇万円！
じゃあ発注！
こんな感じだった様です。
時は2000年。ギリ20世紀ですが、20世紀のプロジェクトなんてこんなザックリ勘定で走っているプロジェクトだらけでした。それだけ痛い目にあっているエンジニアが多かったのも事実。
これだけでもプロジェクトがコケる要因（ツッコミどころ）が沢山ありすぎです。
- 営業が見積もっている
- 納期ありきの意味不明な見積り
- 要件ヒアリング前に金額と納期が決定（発注されている）
まぁ、これは今のご時世ありえないと思うので、得られる教訓はないかと思います。
違和感その2 金額と納期に合わせたシステムにすれば良い請負契約
ここです！ここの違和感に当時の自分は気が付かなかった。
営業の「大丈夫、納期に合わせて出来る機能だけで実装すれば良いから」を納得してしまったんですね。
そうなんだーって。
もう本当にバカだった。
そんな請負契約ある訳ないですね。
作業範囲が決まっていない、契約後にこちらの言うとおりに作業範囲が決められる請負契約。
請負人の義務として仕事完成義務と言うのがあります。契約した内容について契約した時期までに完成する義務を負う訳です。
この契約、何を完成すれば良いのかが無い訳です。
それをこちらが出来る範囲で大丈夫と営業は言っているんですね。これって、逆もまた真なり。言い換えれば注文者も自由なんですよ！！
本当に無知でしたねぇ。
今の自分だったら営業に食い下がるでしょうし、一番最初の打合せで顧客にまず念押しをして上でエビデンスも取ったでしょう。
その前に「こんな契約で良いんですか？」と顧客に伝えていたと思います。
そんなこんなでスタートしてしまうプロジェクト
今思えばスタートから泥船なプロジェクトだった訳ですが、当時の自分は営業の言葉を疑っていないので、これから発生する問題なんて想像もしてなかった訳です。
要件をヒアリングしにいった時に、初めて顧客管理で利用しているEXCELのフォーマットと説明を聞きます。これは営業も初めて見たと言っていました。
EXCELで纏めている顧客情報の各項目で検索をしたいと言っていたので非常にシンプルな仕組みで実装できそうだなと思っていました。
ここでも経験不足を露呈しています。
どんな所でしょうか？
業務の深堀りが出来ていない
顧客検索とは聞いていましたが、「何のための顧客検索なのか？」「どんな業務で利用するのか？」「検索した結果は何に使うのか？」などのヒアリングが出来ていません。
「顧客検索」機能として聞いているだけで、顧客の業務が聞けていないんです。これでは要件のヒアリングになっていません。単発の機能を決めているだけで何の役にもたっていないんですね。
何の業務の時に使うのか？を聞いただけでも、「何で検索する事が多いのか？」「顧客検索をした時に必要な情報は何なのか？」「アウトプット形式はどうなるのか？」「検索後に必要な機能は何なのか？」などなど付随した情報がどんどん提案できた筈なんですね。
この経験不足が後々尾を引きます。
機能仕様書作成中に増える要件
やはり、この時の経験不足ですよね。必要な機能がポロポロと顧客から出てくるわけです。
- 企業情報をD&Bから引っ張れるようにしたい
- 検索項目をこうしたい
- CSVで出力できるようしたい
- 名寄せ検索がしたい
こんなような内容でした。
そりゃそうですよね。顧客を検索して終わりって訳でない訳ですし、当然後工程に流す情報になる訳ですから。色々ありますよね。名寄せだってそうです。顧客情報の仕入先がセミナーやカンファレンスでの顧客アンケ―トだったりする訳で、そうなると「株式会社」だったり「（株）」だったり。企業名もフルネームだったり略称だったりと様々ある訳です。こういったデータの名寄せ作業や検索機能として設けたい事も多々ある訳。
ただ、先方の担当者もおっとりした方で、これらの連絡がポツリポツリと上がってくるくらいでした。
それに「納期までに出来る所だけ」との営業の言葉があったので、「これは実装は間に合いません」「これはこうだったら出来ます」と返信をしながら機能仕様書を作成していました。
メールで機能設計書を送付して開発着手
ヒアリングした内容を機能設計書にしたため、顧客に送付しました。要件を聞く前に設定されている納期も迫ってきておりギリギリのスケジュールだった事もあり、担当者に「いついつまでにドキュメントを確認して欲しい、確認後に着手するから返信をくれ、期日までに返信がなければ着手する」と言った文面のメールを送付しました。
——————————–
担当者様
お世話になっております。空飛です。
前回のお打合せを踏まえて機能設計書を作成致しました。
〇〇日までご確認をして確認結果をご連絡下さい。
納期も差し迫っている事もあり、〇〇日までに
ご回答が無ければ、機能に同意したものとさせていただき、
開発を開始させて頂きます。
以上、よろしくお願いいたします。
——————————–
今見ると恐ろしいメールです。
この時の自分は営業の「大丈夫、納期に合わせて出来る機能だけで実装すれば良いから」バイアスがかかっており、納期ありきで事が進んでいると信じていた訳です。
担当者から連絡が無く開発スタート
メールを送って数日、期日になっても担当者から連絡が来ないまま開発がスタートします。
一応、担当者には開発を始める旨の連絡、開発の進捗状況の連絡をしていましたが、担当者からはなしのつぶて。
そうこうしている内に機能設計書に書かれている機能は実装が完了、お客様が検収で使える環境にデプロイして連絡をしました。
これでも連絡なかったら困ったなぁなんて、呑気な事を考えていました。
突如来る怒りのメール
今思えばこのまま連絡が無かった方が良かったと思う位です。
翌日・・・
突然、担当者の上司から怒りのメールが！！！
一方的にドキュメントだけ送られてきて、こちらが検討をする前に勝手に作ったものを受け入れられるはずがない！
と相当お怒りのご様子のメールでした。
え～そんなぁ、こっちもちゃんと確認しながら進めてたのに・・・とか思いながらも、営業が状況の確認と謝罪をしに行くとの事。
しばらくして営業が客先から帰ってきて打合せの結果を教えてくれました。
一方的と言われていた件に関しては、営業からドキュメントを関係者に送付してましたと伝えると、「担当はシステムの事なんてわからないからドキュメントだけ渡されても判断できるはずがない」と取り付く島が無かったとの事。え～と思いながらも失敗したなぁと反省していたんですが、顧客からこんな事を言われたとの事。
本当はこういう機能や、こういった機能、あれもやりたいし、こういうのもやりたいと思っていた！と言われたとの事。どうやら営業はその場で要望を聞き出すことが出来なくてすみません。要件のヒアリングからやりなおさせて欲しいと言ってきたらしいのです。
おーーーーーーーい！！！
もうビックリですよ。
「納期に間に合うまでの機能で良い」と言っていたのも営業。要件聞く前に勝手に見積もったのもの営業。
「いやぁ空飛さん、ちゃんとヒアリング出来てないのはマズいよ」
そうだけど・・・そりゃそうだけどさぁ。
ここでの反省点は沢山あります。沢山ありすぎです。
機能設計書を送りっぱなしにしてしまった
もうこれダメ。ちゃんと読み合わせしよう。読み合わせをしたらあーだこーだその場であった筈。
相手任せにしちゃったんですよねぇ。ボールを相手に渡している様で聞きに行くと言うボールは持ったままになってしまった。
余計な要望が出てくると納期に間に合わなくなる可能性があって交渉が面倒だなぁと思い、メールで送りつけるだけで済まそうとした結果がこれです。急がば回れですね。
一方的な期日設定
これまで先輩方には「お客様への確認事項は期日を設定して、それ以降ならこうなりますってしとかないとだぞ」と言われて育ってきました。その教えを守って、
「いついつまでに返信がない場合は合意したとみなします」
と記載したのですが、いやぁ今振り返ると酷い大きさを丸投げしてますね。これは一方的なエゴです。システムの一部機能に対して「こういう機能で考えてみたんでいついつまでに連絡下さい。連絡なければ作ります」くらいのデシジョンなら良いのですが、システム全体をこの一文で済まそうって言うのはいくら何でも強引すぎます。
作ってみたけど、やっぱりこう直したい
となった時に身動きが取れなくなりますよね。誰も責任が取れなくなる。これはあまりに無責任な責任の投げ方ですよねぇ。
交渉と謝罪に営業だけで行かせてしまった
これも失敗です。当事者は自分な筈なのに完全に蚊帳の外であり、交渉の場がブラックボックスすぎます。すでに見積の段階でブラックボックスになっているのに更にブラックボックスです。おかげさまで要件定義から全部やり直しというとんでもない結果を持って帰って来てくれました。
交渉は自分ですべきですよね。どんな不利だとしてもシッカリと自分ですべきです。
そして次から次へと要望が止まらないデスマーチが始まった
ここから地獄の入り口でした。
むこうさん某外資系マーケティング部門の方々なんですが、今まで見た事のない大勢の人達がずらりと会議室に集まっていまして。
まぁ、「あんた何もわかってないな」みたいな感じで一方的に攻め立てて来るんです。怖かった。あれでスッカリ恐縮してしまってNOと言えなくなった自分は顧客から出てくる要望を全て受け止める事となり、まさしくデスマーチでした。
お客様からは会議で罵倒され、営業からも何とかしろ的なプレッシャーをかけられ、どんどん精神的に追い込まれていき、遂には冒頭で書いたようにご飯も食べれず、でも会社にはいたくないので昼休みは公園のブランコで時間を潰してから会社に戻って深夜まで作業をするの繰り返しでした。まさしく地獄。
実はこの話、デスマーチを一人で乗り切る事になるんですが、それはそれで別の教訓があるので、その話は別の記事に記載しています。
こちらからです。ぜひ見て下さい！
今回の失敗談から得ら教訓をまとめてみる
今回の失敗談。様々な失敗ポイントがあって全てが全てアカンヤツです。
その内、まぁこれだなぁという大きな２つをピックアップしてみます。
作業範囲が決まっていない請負がヤバイと気が付く事無く開始した
本当にこれに尽きます。ここを抑えていたらこんな問題にならずに済んだと思います。
作業範囲が決まっていない請負開発の恐怖を理解して、営業にもお客様にもキッチリ説明が出来ていたら・・・
うーん、自分の無知さが怖いですね。営業の「出来る範囲で作ってくれれば」って言葉を信じしてしまう自分の無知さ。
はい！1つ目の教訓です。
逆に言えば作業範囲が不明瞭な請負案件は請けてはだめです。ムリゲー確定です。
スケジュールが乱暴
これあまり表面に書いてませんが、実は非常に大きな要因です。これを引き起こしているのも上に書いた「めちゃくちゃな請負」なんですが、スケジュールに現れるポイントポイントのマイルストーンが雑です。機能仕様書フィックスの段取りとか。
メール送っただけで終わりとかどれだけ雑なの？とか思います。
それもこれも「出来る所まで」のバイアスが掛かっているのがあるのですが、本来であれば認識齟齬があって差し戻っても取り返しの付く単位で小まめなマイルストーンを置くべきだし、それを踏まえたスケジューリングをすべきですね。当然期日内に出来ることは限られてくるわけですから、スケジュールの相談だって出来たはずです。
スケジュールが「これで大丈夫」と言った思い込みだけで作ってしまった事が大きな要因だと思います。
コメント