昨年後半から今年にかけて担当した2つの案件で開発のトラブルに見舞われた。簡単に言えば、顧客の望むものが作られず、まともに動かずに期限を迎えた。私自身は開発を担当せず、顧客側で開発業者に対してマネジメント視点で見てきたのだけど、いざ失敗だったという結論が出ると自分のことのようにショックを受けた。;-))開発業者や顧客に対して指摘や提言はしてきたのだけど、改善されることなく結果生じてしまった。自分が関わるプロジェクトが連続で起きたのでちょっとなんとできなものかと思い始めた。「システム開発の失敗は防げないのだろうか」この視点で考えてみる。自分の経験から働き始めて20年経つが、振り返ってみればNTT時代の法人営業のシステム開発もスッキリと行かない案件もあった。他社の事例として顧客ともめて結局裁判沙汰になった高額案件もニュースになった。いう状況は少なくともここ20年変わってないのではないか。顧客の求めているものを開発し収めているケースもあるが、それでも失敗は今でも起きている。いった失敗の経験をもとにアジャイル開発の手法が生まれたわけだけど、上場した大手IT企業では当たり前に習慣化していると思うけど、受託開発会社にはあまり浸透されていない気がする。少なくとも最近であった開発会社はウォータフォールに近いアプローチを取っていた。顧客と開発会社ソフトウエア開発は人が生産工場になるので不確実性が高い作業ではある。人もスキルセット、経験値など個人差があるので、同じ要求をしても同じものは出てこない。人が行うことは不確実性が高いから、何かしら不一致がそもそも出やすい状況ではある。いってもシステム開発の需要は今後も継続するだろうから、確実性を高めたやり方を模索する必要がある。実際失敗したケースを振り返ると顧客と開発業者のどちらかもしくは両方に原因があると思われる。顧客がしっかり仕様や要件定義を示しても、開発会社が形にできずに遅延すれば失敗する。逆に、開発業者が実装するための質問を投げかけても、顧客がしっかり答えられなければこれも失敗する。顧客と開発会社が両方正しく動けてはじめて成り立つ。失敗しやすい特徴そもそも失敗とは、顧客側で投資した時間とコストが無駄になること。開発されたシステムは思っていたのと違っていて、しかも正しく動かない。厄介なのは、顧客は最初にプロジェクトを見積る時に、決められた予算以上は出せない(最大コスト)し、期限の延長は考慮していない(最短時間)ので、少しでも自体が変わると失敗になりやすい。契約上、検収してから請求が確定とするとすれば、動かないシステムは受け入れられずコストの無駄は割けられそうだけど、意外とこの条項を知らずに、開発業者の工数ベースの請求を開発が完了していないにもかかわらず、払ってしまったしていたケースもある。顧客側の失敗しやすい特徴を並べてみる。システム開発経験者がいない契約書でリスク管理してない納品物に対する検収でチェックする請求フローになっていない期日に間に合わなかった場合やトラブルになった場合の回避方法や請求への考え方を示していないスケジュールに対してルーズ遅れても改善策を求めていない遅れていることを指摘しない記録を取っていないミーティングメモがない同意事項を取ろうとしない(やってくれるだろう前提)途中でレビューしない次に、開発側の失敗しやすい特徴を並べてみる。期限の最後になってはじめてうまくいっていないことが分かる顧客は思っていたのと違うと言い、開発会社は言われたとおり(資料通りとは言わない)つくったと言う言った言わないが起きる顧客は直せと言い、開発会社は変更対応なので追加工数だと主張するというゴタゴタが生じる。同意をとっていない記録を取っていない途中でレビューしていないというところで、失敗を生じさせないためには同意を取る記録を取る途中でレビューするということだと言える。中間レビューはアジャイル開発の手法であるし、理にはかなっていそう。システム開発の失敗を起こさなためのサービスを作れないだろうか20年以上生じているシステム開発の失敗を解決するサービスはないのだろうか。需要は充分あると思う。プロジェクト管理ツールはあるが開発側に近く、何しろ項目としてあげた部分に対応していない。文章による同意を取るための承認・コメント機能ミーティング実施時には必ずメモを記して、参加者の承認を得る機能プロジェクト期限、提供機能の期限、レビュー実施日の設定、期限が近づいたら通知する機能これらの機能が1つのサービス内で提供されると良さそう。同意を取ることや自動で通知してくれるようなものは、他の業務で忙しい顧客にはプロジェクト推進支援ツールとしてありがたがったりしないだろうか。需要があればうちの会社で作ってみたい。