こんにちは。ハウスマートの高松(@t2kmt)です。

皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか？

開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。

開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。

今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。

mini spec とは

mini spec とは開発の要件をまとめるフォーマットで、2016年頃にペロリのテックブログで紹介されていたものです。ハウスマートではそれを参考に、改良を続けながら2年ほど運用してきています。（mini spec とはペロリの社内用語で一般的な名称ではないようです）

2年ほど使い続けていますが、このフォーマットは必要なことが網羅されていて、かつ冗長な部分はカットされているため、スタートアップのような企画と開発にスピード感が求められる現場には非常にマッチしています。

最近知り合いにこのブログ紹介しようと思ったところ本家のブログが削除されていたため、誰かの参考になればと思い今回ブログにまとめることにしました。

ハウスマートの mini spec では以下の9つの項目をプロジェクトごとにまとめています。

• 解決すべき課題（Issue to be Solved）
• ユーザーストーリー（User Stories）
• 影響範囲（Repository/Platform）
• 非機能要件（Non-functional Requirements）
• KPI（Purpose）
• リリース希望日（Target Due）
• 体制 / 規模感（Team）
• ステークホルダ（Stakeholders）
• 参照（Reference）

各項目について

それぞれの項目でどのような内容を書いているかを紹介します。 以下の項目を説明も含めてまるっとMarkdownのテンプレートとし、これをコピーして説明を見ながら各項目を埋めていくスタイルで使っています。

（mini specの魅力を存分に伝えるため、項目の説明に関してはペロリブログ本家に書かれていた説明とハウスマート社内で追記・書き換えしたものが含まれていますがご了承ください）

解決すべき課題（Issue to be Solved）

現在顕在化している課題とその解決のニーズを記載します。

ここで意識するのは、いわゆる論文の前書きのように、である調で理系っぽく客観的に記述するようにしています。そのほうがちょっとカッコいいのと、誰が読んでも、それは大きな課題だなあ、やるべきだよなあ、と少し高めのサービス目線から重要性を感じてもらえるからです。 課題を裏付ける根拠や数字がある場合は併記します。

ユーザーストーリー（User Stories）

ユーザー視点でどうあるべきかのストーリーを、ユーザーが機能に気がつくところから箇条書きで順序を追って記載します。

ここで大事なのは、アクターに漏れがないかです。エンドユーザーだけでなく、コンテンツを運用する人や、分析する人、外部のパートナー等あらゆるアクターのユースケースを書きます。そうしないと、管理ツールってどうするの？みたいなあるあるが後で起きて露頭に迷うので最初から決めます。管理ツールがないなら、エンジニアが redis にデータを投入する等書きます。

そして、ここはストーリーなので特にエンドユーザー向けのユースケースは、ワクワクするような、ユーザー感情も一緒に記載するようにします。

影響範囲（Repository/Platform）

改修範囲がWeb か、アプリか、両方か、管理画面か等を記載します。アプリの場合は必要であればバージョンの指定もします。

詳細にわかればリポジトリ単位で変更点を列挙していきます。もし初期段階でわからない部分があれば複数の可能性について書いても良いです。（ここをこう変えてもいいかもしれないし、他の部分を変えてもいいかもしれない、のように書く）

非機能要件

機能以外の要件を書きましょう。 画面やAPIのレスポンススピード、バッチの処理時間、データ量などシステム的に気にしておくべきことを箇条書きで列挙します。

KPI（Purpose）

現状の KPI と目標の KPI、もしくは定性的な目標を記載します。 追うKPIを定義することで、どの数字を計測可能な状態にしておくかを明確にするのが目的です。 また、ネガティブなインパクトが考えられる数字もKPIとして定義し、可能であれば許容する範囲を事前に定めます。

リリース希望日（Target Due）

希望なのか、デッドラインなのか、理由も含めて記載します。 最終的なスケジュールは全体のプライオリティの中で決めるので、デッドラインがない場合はだいたいで大丈夫です。

体制 / 規模感（Team）

ざっくり何人でどれくらいの期間かを記載します。

リスク（Risks）

プロジェクトを進行する上で認識しているリスクがあれば記載、かつリスクへの対処法も併記します。実装で詰まる可能性が見えている箇所などがあれば挙げておいてください。また、施策の結果起こりうるリスクも記載してください。 いちばん大事なのは許容するリスクを書いておくことです。このリスクは承知で挑むのだ、ということを伝えて腹落ち感が出るように。

ステークホルダ（Stakeholders）

この要件に対してレビューが必要な人を by name で記載します。 誰にどのタイミングでどんな観点で見てもらうのかを意識して書きましょう。

参照（Reference）

参考資料があれば記載します。 過去の mini spec だったり、既存仕様、ベンチマークにしている他社サービスなど index として並べます。

どうやって運用しているか

ハウスマートでは2週間スプリントで開発を行なっていますが、ざっくり見積もった時にタスクが一人で一週間以上かかるようなものに関しては mini spec を作成するようにしています。 それより小さな開発に関してはドキュメント作成のコストが相対的に高くなってしまうためプランニングポーカーの際に要件や仕様を確認するにとどめています。

ハウスマートではプロジェクトをリードするエンジニアもしくはデザイナーが mini spec を作成します。簡単なものであれば30分程度、大きいものでも2-3時間程度で書き終わるボリュームにしています。 作成した mini spec はタスクに分割して見積もりをする前に、チーム全体でレビューをしています。

また、大きめなプロジェクト振り返りの際にはプロジェクト進行がよりよく進むために mini spec の項目自体も振り返るようにしています。

導入して感じたメリット3つ

開発前に全体感が共有できるので手戻りが少なくなった

プロジェクトに着手する前に全体感が明確になっており、チーム全体のレビューも通っているため認識の齟齬による手戻りが大幅に少なくなりました。

プロジェクトの振り返りがちゃんとできるようになった

事前にプロジェクトの KPI を明確にして開発を始めるため、その数値を取得できる状態で機能がリリースされるようになります。 そのため、リリース後のKPIへのインパクトの振り返りが確実になされるようになりました。

誰が企画しても品質に差が出なくなった

フォーマット化していることによってレビューポイントが明確になるため、きちんとレビューを行えば企画に慣れていないメンバーでも安定したクオリティでプロジェクトを進めることができるようになりました。

使う時に気をつけたいこと

mini spec を導入することの最大のメリットは、「プロジェクトの企画」という行為自体を改善するサイクルを作れることだと思っています。

あの人の企画はわかりやすい、あの人の企画は抜け漏れがある、といったような人依存の状況を脱却してフォーマットに対して建設的なフィードバックを行なうことが大切です。 なので、実際に現場で使用する際にはフォーマット自体の見直しを定期的に行うことをお勧めします。

また、フォーマットの項目や粒度などはそのチームのメンバー状況やスキルセットによって変わってくると思うので、自分達に合った最適なフォーマットを見つけてみてください。

おわりに

ハウスマートではエンジニアやデザイナーがプロジェクトの企画から主導できる環境を用意しています。 「何を作るか」から自分で考える環境で仕事をしたい！という方、ぜひ一緒に働きましょう。

今話題のReTech！業界を変えるカウルを支えるエンジニアをWanted！ 今話題の不動産テック！スタンダードを創るUI/UXデザイナーをWanted