システム発注が失敗した3つの理由

今回の記事はシステムを発注する側の立場の人に向けて書きたいと思います。

私がスタートアップ企業にて初めて転職したころ、システムエンジニアとして新サービス立ち上げの一大プロジェクトに携わることになりました。その企業は「シード段階」と呼ばれる事業フェーズで、リサーチで発見したニーズをもとにビジネスモデルやプロダクトを開発し、そのために投資家から出資を募ることを行う段階でまさにスタートアップといった感じでした。
また、経営陣とそのアドバイザーで構成される新サービスのプロジェクトは当時の私からすれば非常に魅力的でした。

しかしそんなプロジェクトも悪夢のような形で終わりを迎えました。
なぜそうなってしまったのか？それまでのいきさつを踏まえてお話します。

システム発注を失敗したスタートアップ企業の悲劇

私が参画したころにはそのプロジェクトは既にプロトタイプの開発や検証がある程度終わっていた段階でした。ざっくりですがシステム構成も出来上がっており、そのプロトタイプをもとにベンダー企業に話を通しているようでした。

この時の私の仕事は新サービスの事業展開に関してチームで話し合った内容を整理し、それをもとにサービスのサブシステムの設計や開発、運用をすることでした。またCTO（最高技術責任者）がベンダー企業の関係者と頻繁に交流があるようなので、現場とのコミュニケーションはCTOにお任せし、私はタスク管理を行っておりました。

私が任されていたサブシステムは異なるフォーマットの記事データに対してフォーマットを統一し、指定した時間にメインシステムに送り込むというものでした。単純ではあるもののデータ量が多く、パフォーマンスやエラー発生時の運用について慎重に検討する必要がありました。このサブシステムはサービス展開において非常に重要な役割を果たしていたため私は会議でこのことを報告し、メインシステムのほうでも耐えられるようにしてほしいことを伝えました。

サブシステムのほうは出来上がり、あとは開発中のメインシステムが出来上がるのを待つだけでしたが、リリース2週間前に問題が起こりました。

リリース2週間前にもかかわらず開発完了の連絡がなく、タスクを確認してみるとまだ開発が完了していない機能がありました。不安になってベンダーに問い合わせてみても返答がなく、数日後に「リリースが2週間延期になる」と連絡がありました。このままではテストもできずリリースが遅れてしまいます。CTOに状況を確認しようとしましたが返事がありませんでした。
なおこの日からCTOとの連絡はつかなくなりました。

結局リリース予定日の一週間後にようやく納品され急いでテストを実施。その後サービスローンチを行いひと段落がついたかと思われました。

ところが開始して1週間がたったころ突然システムが動かなくなりました。ベンダーに問い合わせて対応してもらっても翌週にはまたシステムがダウン。再度対応を依頼するもベンダーからは
「システムへの負荷が大きすぎるため抜本的な見直しが必要」
といわれて大混乱。このままではサービスが使い物になりません。以前から懸念していたサブシステムから送られてくるデータの処理ができていないことが明らかでした。

急いでベンダー企業の担当者を招集し議論することになりました。サブシステムとの連携については以前から伝えていたはず、このままではサービスとして成り立たないとクレームを申し付けたところ、ベンダー企業の担当者から
「そもそもそのような話は聞いていない」
「そんなに負荷がかかるような運用は想定していない」
の一点張り。私はそんなはずはない、うちのCTOから話を聞いているはずだと思いましたがこの時点ではその真偽を確かめることはできませんでした。

後日社長がCTOと会って話をしたそうですが、どうやら事実だったようです。

出来上がったのはおよそ1000万円近くかけて築き上げた技術負債（ガラクタ）でした。結局そのソフトウェアは捨てることにし、別のベンダーを使ってもう一度作り直すことになりました。

なぜこうなってしまったのか？

最初はベンダー企業に全責任があると思っていましたが、このような事態になってしまったのにはこちら側にも大きな問題があることが後からわかりました。

1. 情報が共有されていない

サブシステムとの連携に関する懸念点についてはCTOに伝えたのですが、CTOからベンダー企業には十分に伝わっていなかったことがわかりました。

ベンダーとのコミュニケーションについては基本的にCTOが一任していました。タスクはきちんと管理ツール上で管理しておりましたがそれ以外のことは全てCTOしか知らない状態でした。口頭でどのようなやりとりが行われていたか誰も知ることができませんでした。

また、実のところCTOが社内にいることがほとんどありませんでした。平日の会議にはほとんど現れず、コミュニケーションはメッセージと毎週土曜日に開かれる数時間の打ち合わせくらいでした。

こうしたことから社内の情報とCTOの把握している情報、それからベンダー企業に共有した情報に大幅なギャップが発生し、仕様の乖離が発生したのでした。

2. 受入テストを十分に行わない

もともと受入テストのために2週間ほどスケジュールを確保していたのですが、一刻も早くリリースするため3日で完了するよう要請されました。資金調達を行っている企業では投資家たちに進捗を報告する必要があり、さらには追加投資を行ってもらうようアピールしなければならなかったそうです。

しかし数日ではシナリオテストや負荷テストが行えません。特に負荷問題は開発段階ですでに懸念していたこともあったので相談しました。最終的に経営判断のもと負荷テスト以外のテスト行いそのまま検収することに。

その結果、リリースしてから1週間でシステムダウンが頻発。原因はサブシステムから送られるデータを処理できなかったことでした。事前に負荷テストを行っていれば避けることができた問題でした。

3. ドキュメントや履歴を残さない

今回の最大の問題と思われる点です。問題ついて議論する際多くのやりとりはCTOが口頭で行っていたため、客観的な事実を示しながら議論することができませんでした。

さらにはすべての成果物を回収するときにも受け取ったのはソフトウェアやそれに関する設定書、それから運用マニュアルといったものくらいで、設計書はおろか要件定義書すらありませんでした。要件定義書がないので本来何を開発すべきだったのかも分からず、いつ仕様変更が発生したのかもわかりません。プロジェクトは完全にCTOによって俗人的に進められていたのでした。

失敗して苦しむのは発注企業

発注企業の担当者の中には、自分たちの仕事はベンダー企業に依頼するまででプロジェクトの管理はベンダー企業の責任と思っているかもしれません。

しかしながらそうではなく発注企業側もプロジェクトマネジメントをしていかなくてはなりません。そうしなければならないシンプルな理由があります。それは結局苦しい思いをするのは発注企業だからです。

失敗によって金銭的損失が出るだけでなく、時間の浪費や市場進出の機会損失、場合によっては企業の信用低下まで被ることになります。訴訟を起こすものならなおさら発注企業に大きな負担がかかります。

また、IT紛争においては仮に訴訟を起こしたとしても立証するのが難しいと言われています。こうしたIT紛争というのは絶えず発生しており、発注側にも一定の責任がある事例が多くみられるためです。

例えば平成16年3月10日に東京地方裁判所で下された判決に以下のようなものがあります。

オーダーメイドのシステム開発契約ではベンダのみではシステムを完成させることはできないのであって、ユーザが開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、（中略）このような役割を求める委託者であるXが分担していたことにかんがみれば、本件電算システムの開発は、Xの受託者であるYの共同作業というべき側面を有する

このようにシステム開発では両者が協力して取り組まなければならないとされており、発注したからあとは全部ベンダー企業の責任というわけにはいかないようです。

同じ失敗を犯さないために

今回の失敗の背景には発注側の責任が多く含まれておりました。そして今後同じ過ちを犯さないためにも以下のことは徹底するようにしようと思いました。

• 担当者が俗人的にプロジェクトを管理してはいけない。かならず文書や履歴を残して客観的に判断できる材料を残しておく
• どんなに忙しくても社内でテストを行う。受入テストは発注企業が果たすべき責務である
• 頻繁にコミュニケーションをとる。今把握している情報が古くないか常に確認す