top of page

仕様を完全に理解できていないことで開発が失敗した例

更新日:2022年5月26日

これもよくあることですが今回は開発会社から出てきた資料が難解な専門用語を使っていたケースを出してみようと思います。



【失敗例】仕様書をなんとなく理解できたつもりでいた


発注者で要件をまとめ、構築するシステムについて社内の意見も統一したことから発注フェイズに移りました。


既存の開発会社と相見積もりも済ませ、2割ほど安い開発会社にお願いすることで上司決済ももらいました。


要件定義もまとまり、画面構成図なども出来上がり、開発会社から指摘されていた項目も全て回答しました。



開発会社から構築に関する資料をもらったのですが専門用語が多く社内で100%理解できている社員が誰もいなかったにも関わらずきちんと内容を確認しませんでした。


何度にも渡る会議で開発会社と自社で認識は一致していると思っていました。


アジャイルで開発がスタートし、いくつかの機能が出来上がってきたので機能チェックの会議を行うと、社内で想定していた構築内容とズレていることが発覚。


そこで開発会社に修正を依頼したところ、すべて事前に書面にて承諾をもらっているのになぜ今更、そのような指摘がでるのかわからない、といった回答が戻りました。


慌てて社内で開発会社から来ていた書類を全て読み返したところ理解できていないままにしていた点が原因ではないかとの判断に至りました。


そこで、開発会社に改めて説明を求め、内容を確認したところ専門用語で記載されいた箇所で開発会社と認識が合っていないことがわかり、修正を依頼。


修正には快く応じていただいたのですが修正にかかる工数が増えてしまい結果的にコストとリリースタイミングが変わってしまいました。


認識が合わないことを防ぐためにどうすればよかったのでしょうか。



【失敗の理由】発注者と開発会社の間で100%の理解が必須


この問題は社内に業務システム部が無かったり、特にエンジニアではない担当者が開発担当者を兼務している場合に生じやすい問題です。


この問題をクリアにするために必要なのことは以下であると考えます。


「まー何となく理解できたからあとは機能が出来上がってから調整すればよい」

「専門用語ばかりで正直9割程度の理解ではあるが、開発会社も理解しているだろう」

「アジャイルだし」


危険です。


開発で失敗しないためには両者の見解が完全一致している必要があります。


会議ややり取りだけが続くと時間が無駄に過ぎていくように勘違いすることがよくあります。

そんな時は9割ほどの理解でスタートしてしまいがちです。


長年付き合ってきた担当者同士であれば見えていない箇所の空気を読んで仕事することが出来ますが、どちらかの担当者が案件で初めてアサインされてくるようなケースでは9割だと不十分です。


完全一致を達成するのは厄介ですがコミュニケーションをしっかりと取り、その機能ごとに追加資料を作成するなどグレーなところは徹底して洗い出す作業が必要となります。


アジャイル開発であってもスタート前に完全一致していなければシステム開発が失敗する確率はアップします。


先の記事でも書きましたが、アジャイルとは「何でもかんでも後で修正」という意味ではありません。


あくまでも開発する設計内容を理解した上で追加、修正することがアジャイル開発の骨子です。


仕様を100%理解せずに曖昧なところを残した状態で構築を進めれば両者に認識のズレが発生するスキが生じます。



経験上、仕様を100%理解していても認識ズレが発生すると思っています。



開発会社の各種ドキュメントはエンジニアが作成するためどうしても専門用語が多くなりがちです。


専門用語を見ていると頭が痛くなってきたり、頭によくわからない英単語しか入ってこないことは理解できますがそこはグッとこらえてわからないことは分からないとハッキリと伝えることが大切です。



通常業務と開発案件を兼務している場合などは時間もありませんから自分で調べるのではなく、エンジニア経験がある人材がいれば会議に同席させたり、開発会社の担当者さんにも専門用語ではなく一般的な言葉でドキュメントを作成する「努力」をしてほしいと伝えるなど環境を自分に寄せる作業を行うことで認識ズレによる失敗の確率を下げることが出来ます。



気を付けるべき点としてもう一つ挙げておきます。


フリーランスを使う場合、その方が同種のシステム開発経験を持っているかを確認することは当然ですが、定期会議など短い期間で意思疎通ができる状況をしっかりと確立することが大切です。



フリーランスだと基本的には窓口=開発者となりますから一見すると話が早くてメリットがあるように思えますが落とし穴もあります。


過去の経験から失礼を承知で申し上げるならば、フリーランスのエンジニアさんは説明が専門的になりすぎる傾向がありました。


自分で開発しているわけですから頭の中に完成図が見えているのは開発会社のエンジニアも同じですが、自身と同レベルのスキルがあることを前提とした説明になってしまうことがありました。


同席する人物が同じスキルレベルであれば問題はありませんが、エンジニア経験者ではなかったり、エンジニア経験年数が短い場合、すべてを理解することが困難になります。


これは悪意があるわけではなくシステム開発業種の商慣習だと思っています。


開発がスタートした後は、納品までの時間を短くして次の案件探しに着手しようとする原理が働きます。

フリーランスでも開発会社でもこの流れは同じです。


そのため無駄な時間はできるだけ使いたくないという思いから専門用語による説明になりがちになってしまいます。


これは私がおなじみのエンジニアさんに聞いたところ全員が異口同音に言っておられたことです。


ただ、思い返していただきたいのは発注者はシステムを使う立場です。

作るシステムに1%でも分からないことがあっては最大限の効果を得ることはできません。


フリーランスとお仕事をする場合は、意思確認をマメに取るような開発スタイルを取ることで意思のズレを回避するようにします。


ちなみに弊社では


専門家同士で話すのが一番効率が上がりますが、認識ズレが出そうだと思った時は、営業担当者が間に入りお互いの理解度を確認するようにしています。


特に専門用語が頻発せざるを得ないような機能構築の説明会議などは慎重に事前打ち合わせを行います。


文字やことばだけでは伝わりにくいと思われると判断した場合、会議前にエンジニアに確認をして必要とあれば目視できるような資料を作成します。


営業部門が説明資料を作ることで専門用語に依存しないドキュメントの作成が可能になり、お互いの認識のズレが発生しないことにつながっています。


bottom of page