はじめまして、株式会社rexcornuの自社プロダクト開発にジョインしているだーちゃんです。前職では、主にRuby on Railsのバックエンドエンジニアとして新規開発に4回ほど携わりました。今回は、フリーランスエンジニア向けサービス「TechMatch for Freelance」のリリースに際し、PMとして開発に関わりました。

本記事では、プロダクト開発における「インセプションデッキ」の重要性について、私が直面した具体的なエピソードを交えてお話しします。

インセプションデッキとは

インセプションデッキとは、アジャイル開発の初期段階で関係者全員がプロジェクトの方向性や目標を共有するためのツールです。これにより、認識のズレを最小限に抑え、プロジェクトの失敗リスクを軽減します。

インセプションデッキは10個の質問から構成され、プロジェクトの「なぜ（Why）」と「どのように（How）」を明確に整理します。作成はプロジェクトメンバー全員で行い、スプリント0の期間中に2～3日ほどでまとめることが推奨されています。これにより、メンバー間の共通認識が深まり、プロジェクトがスムーズに進行する土台を築けるのです。

実際に起こった問題

ある日、要件定義を進めている最中に、次第に機能の仕様が複雑になりすぎていることに気づきました。特に、作業実績を登録する機能がエッジケース（例外的なケース）に対応しすぎた結果、非常に複雑化してしまっていたのです。

その結果、開発担当者からも仕様に関する質問や確認が頻繁に寄せられるようになりました。Slackには「このケースの場合、どう処理すればいいですか？」というような確認メッセージが次々に届き、開発スピードが低下。各チームメンバーが理解しきれないまま作業を進めてしまう場面も増え、コミュニケーションの負担が増えていきました。

このような状況は、機能をすべてのユースケースに対応させようとするときに起こりがちです。具体的には、以下の2つのアンチパターンが見られました。

パターン1：全ユーザに対応しようとしすぎる

本来、プロダクト開発、特に初期プロダクトについては、コストが最低限で投資効果の高いMVP（Minimum Viable Product）をいかに早くリリースできるかが重要であり、完璧な製品・サービスを目指す必要はありません。しかし、「すべてのユーザを見捨てない」という善意から、エッジケースにも対応しようとする結果、機能がどんどん複雑になり、リリース時には使いづらいものに。結局、メインのユーザにとっては不便で、社内でも機能説明に苦労しました。

パターン2：サンクコストに囚われる

開発メンバー全体が「この機能は複雑だ」と認識していながらも、すでに多くの時間と労力を費やしていたため、「一から考え直そう」とは言いづらい状況に。結果として、複雑な仕様のままプロジェクトが進んでしまいました。

根本的な問題点

これらの問題の原因は、サービスのゴールや提供価値、アピールポイントが定まっていなかったことにあります。また、限られた時間・予算・品質の中で、何を優先すべきかが不明確だったことも影響しました。チーム内で意見の取捨選択ができない状態が続くと、すべての要望を取り入れようとして、結果的に混乱が生じるのです。

インセプションデッキに立ち戻ることで解決

複雑化した機能要件に直面したとき、私たちはそもそもインセプションデッキを作成していなかったことに気づきました。開発の初期段階で目の前のタスクに集中しすぎたため、サービスの全体像や目的をチーム全体で共有することを怠っていたのです。

この問題を解決するために、すぐにインセプションデッキを作成することを決断しました。デッキの作成プロセスでは、プロジェクトのゴールや提供価値、ペルソナなどを一つひとつ見直し、全員が共通認識を持つよう徹底しました。これにより、エッジケースへの対応範囲やサービスのアピールポイントが明確になり、チーム全体で優先順位を共有できるようになったのです。

結果として、作業実績を登録する機能をゼロから再考し、シンプルで使いやすい機能へと生まれ変わりました。インセプションデッキを通じて、要件定義が迅速に進み、プロダクトも大幅に改善されました。

おわりに

インセプションデッキは、プロダクトの方向性を整理し、関係者全員の認識を統一するための強力なツールです。私たちが直面した複雑化の問題も、このデッキに立ち戻ることで解決できました。プロジェクトの初期段階でしっかりと作成し、定期的に見直すことで、成功への道筋を確実に描けるでしょう。

rexcornuでは、これからの会社の成長を共にしてくれる仲間を募集しています。