先日、弊社のとある一括見積サイトの改修プロジェクトで、リリース前に仕様齟齬が発覚し、リリースが延期なりました。この齟齬の問題につて、エンジニアチーム全員でふりかえりをしました。そのまとめを書きます。

経緯

この一括見積サイトで、新企画があり、検索条件に機能を追加すことになりました。社内エンジニアの余裕がなく、今回は、外部のパートナーに発注することになりました。そのため、仕様書となる資料を作成、POとレビューし、外注先に送りました、その時の資料の一部が添付の図なります（社外秘の部分もあるので、脚色しています）。

開発、社内エンジニアの受け入れテストが終了。インテグレーション環境でのPO確認で、

PO：これって最低人数が、X人なのに検索結果にでてるのですが、なぜですか

私：いや、でてくるのが正解ですよね。レビューしていただいた、仕様書でも、最低人数は、特殊タイプで最低人数が条件にならないと書いていますよね

PO：いや常識で考えてください。最低人数は、キモですから、条件にならないことをはありえませんよね

・・・・

仕様齟齬の原因をさぐる

このケースについて、社内エンジニア全員（他のプロジェクトのエンジニアも）で、ふりかえりをしました。ふりかえりであがってきた事項を箇条書きします。

・仮説があいまいだったのでは？

・ユーザーストリーを、メンバー同士で共有しましたか？

・ＵＩ仕様以外の仕様書（検索条件、管理画面、非機能要件）は、システム的で、ＰＯにそもそも理解できないもの。他の方法で確認すべきでは？

・このメディアは、スリーサイドマーケットプレイスですが、ユーザ/会社/エージェントそれぞれの、メリットデメリットを、仕様書作成後、振り返ったのか？

・動くものを見せるまでに、時間がかかりすぎ。仕様齟齬があってもいいように、背骨となる検索の部分だけ先に実動作確認してもらって、それから管理画面の開発に取り掛かるようにするべきだったのでは？　

・POと、静的なＵＩ図を確認しただけで、流れで確認していない(プロトタイピングしてない) のでは？

・モックでの流れの確認で、異常ユーザ想定での検証をしましたか？

・モックでの確認で、対象ユーザのパターンがたらなかったのでは

・全ての関係者のストーリーを、具体的な値で、流してなかたったのでは？

特に、エンドユーザのサイトへの訪問やサイトでの動きだけでなく、サイト利用後のエージェント、エンドユーザの動きまで 

等々、たくさんあがりました。あげられた事項は、最終的に「認識のズレを失くす為」に、「具体的なユーザーと値」で話す、というのがトピックになっていたように思えます。

まとめ

あげられた事項で、もちろんやっていたことも多数あります。とはいえ、起きてしまっている。それを真摯に受け止め、エンジニアチームとして、認識のズレをどう失くしていくのか、あがった事項を、４つにまとまりました。

１）スリーサイドで仮設を立て、その確認を、キックオフ、仕様締結、運用ミーティング、テスト設計、運用、改修後検討会で都度行う

2）具体的なユーザと値を用い、モックで、すべての登場人物の動きを演劇する

3）異常系のユーザもあらいだし、モックで、すべての登場人物の動きを演劇する

4）齟齬が起きてもリカバリーできるように、システムの背骨を動くもので、なるべく早く確認してもらう