きっかけは2つ案件での失敗

昨年後半から今年にかけて担当した2つの案件で開発のトラブルに見舞われた。簡単に言えば、顧客の望むものが作られず、まともに動かずに期限を迎えた。

私自身は開発を担当せず、顧客側で開発業者に対してマネジメント視点で見てきたのだけど、いざ失敗だったという結論が出ると自分のことのようにショックを受けた。(自分が開発側に入ってやる場合は決して失敗は起こさせないけどね ;-))

開発業者や顧客に対して指摘や提言はしてきたのだけど、改善されることなく結果生じてしまった。自分が関わるプロジェクトが連続で起きたのでちょっとなんとできなものかと思い始めた。

「システム開発の失敗は防げないのだろうか」この視点で考えてみる。

自分の経験から

働き始めて20年経つが、振り返ってみればNTT時代の法人営業のシステム開発もスッキリと行かない案件もあった。 他社の事例として顧客ともめて結局裁判沙汰になった高額案件もニュースになった。

そういう状況は少なくともここ20年変わってないのではないか。もちろん顧客の求めているものを開発し収めているケースもあるが、それでも失敗は今でも起きている。

こういった失敗の経験をもとにアジャイル開発の手法が生まれたわけだけど、上場した大手IT企業では当たり前に習慣化していると思うけど、受託開発会社にはあまり浸透されていない気がする。少なくとも最近であった開発会社はウォータフォールに近いアプローチを取っていた。

顧客と開発会社

ソフトウエア開発は人が生産工場になるので不確実性が高い作業ではある。人もスキルセット、経験値など個人差があるので、同じ要求をしても同じものは出てこない。人が行うことは不確実性が高いから、何かしら不一致がそもそも出やすい状況ではある。

といってもシステム開発の需要は今後も継続するだろうから、確実性を高めたやり方を模索する必要がある。

実際失敗したケースを振り返ると顧客と開発業者のどちらかもしくは両方に原因があると思われる。

顧客がしっかり仕様や要件定義を示しても、開発会社が形にできずに遅延すれば失敗する。逆に、開発業者が実装するための質問を投げかけても、顧客がしっかり答えられなければこれも失敗する。

顧客と開発会社が両方正しく動けてはじめて成り立つ。

失敗しやすい特徴

そもそも失敗とは、顧客側で投資した時間とコストが無駄になること。開発されたシステムは思っていたのと違っていて、しかも正しく動かない。というケース。 厄介なのは、顧客は最初にプロジェクトを見積る時に、決められた予算以上は出せない(最大コスト)し、期限の延長は考慮していない(最短時間)ので、少しでも自体が変わると失敗になりやすい。

契約上、検収してから請求が確定とするとすれば、動かないシステムは受け入れられずコストの無駄は割けられそうだけど、意外とこの条項を知らずに、開発業者の工数ベースの請求を開発が完了していないにもかかわらず、払ってしまったしていたケースもある。

まずは顧客側の失敗しやすい特徴を並べてみる。

• システム開発経験者がいない
• 契約書でリスク管理してない
  • 納品物に対する検収でチェックする請求フローになっていない
  • 期日に間に合わなかった場合やトラブルになった場合の回避方法や請求への考え方を示していない
• スケジュールに対してルーズ
  • 遅れても改善策を求めていない
  • 遅れていることを指摘しない
• 記録を取っていない
  • ミーティングメモがない
• 同意事項を取ろうとしない(やってくれるだろう前提)
• 途中でレビューしない

次に、開発側の失敗しやすい特徴を並べてみる。

• 仕様や要件に対して質問をしないもしくは極端に少ない
• 同意を取らずに思い込みで実装する
• スケジュールに同意したのに遅れる
• 自発的に進捗報告しない
• 記録を取っていない
  • ミーティングメモがない
• 途中でレビューを求めない
• 何か問題が生じた場合、自らの保身のための言い訳・言い逃れをして、最終的に嘘をつく

この結果何が起きるかというと、

• 期限の最後になってはじめてうまくいっていないことが分かる
• 顧客は思っていたのと違うと言い、開発会社は言われたとおり(資料通りとは言わない)つくったと言う
• 言った言わないが起きる
• 顧客は直せと言い、開発会社は変更対応なので追加工数だと主張する

というゴタゴタが生じる。

失敗をカテに成功要因を導く

失敗した特徴から、顧客と開発会社両方に共通している項目は、

• 同意をとっていない
• 記録を取っていない
• 途中でレビューしていない

というところで、失敗を生じさせないためには

• 同意を取る
• 記録を取る
• 途中でレビューする

ということだと言える。中間レビューはアジャイル開発の手法であるし、理にはかなっていそう。

システム開発の失敗を起こさなためのサービスを作れないだろうか

20年以上生じているシステム開発の失敗を解決するサービスはないのだろうか。需要は充分あると思う。

Github, Bitbucket, Backlog などのプロジェクト管理ツールはあるが開発側に近く、何しろ項目としてあげた部分に対応していない。

イメージ的には、顧客と開発会社が1つのプロジェクトに属している状態で、

• 文章による同意を取るための承認・コメント機能
• ミーティング実施時には必ずメモを記して、参加者の承認を得る機能
• プロジェクト期限、提供機能の期限、レビュー実施日の設定、期限が近づいたら通知する機能

これらの機能が1つのサービス内で提供されると良さそう。

現状、このようなサービスはあるのだろうか？ 特に同意を取ることや自動で通知してくれるようなものは、他の業務で忙しい顧客にはプロジェクト推進支援ツールとしてありがたがったりしないだろうか。

もし需要があればうちの会社で作ってみたい。