【ディレクター・エンジニア向け】新機能を作るときの要求定義書テンプレート

こんにちは！yuzuです！
エンジニア2年目が早くも1ヶ月半過ぎようとしています。

今回は、私が新卒1年目の時に、依頼された機能を作る際に、確認が多くなったり、作ってから要件が漏れていて、実装を仕直さなければいけなくなったということがありました。

その際に要求定義をしっかりしていればと思い、作った要求定義書のテンプレートについて紹介したいと思います！

目次
・要求定義と要件定義の違い
・要求定義書のテンプレートの説明　
・実際に書くとこんな感じになる要求定義書の例

要求定義と要件定義の違い

おそらく、要件定義はシステムの機能とか仕様を決めていくといった、結構聞いたことのある言葉だと思うのですが、

要件定義 とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などを明確にしていく作業のことです。 ユーザ部門から要求を引き出し、システムに実装するべき機能を整理します。（引用：https://www.jtp.co.jp/techport/2016-07-27-002/）

要求定義ってなに？って私も最初は思いました。

要件定義と違い、こんなシステムが欲しい、あんな機能が欲しい、要望をヒアリングして機能の部分を詰めていくことだと思っています。

要件定義の工程を上流工程と呼ぶこともあります。 この工程では、開発担当のSEは、ユーザー部門から要求を引き出し、システムに実装するべき機能を整理します。 その実現のために実装しなければならない機能や性能などを明確にしていきます。（引用：https://www.widesoft.co.jp/technology/2777）

要求定義書のテンプレートの説明

・概要：何をするのか、したいのかをざっくり書く
・課題：なんでそれをすることになったのか
・目的と効果：それをしたらどうなるのか、どんな効果が生まれるのか
・問題点、懸念点：それをすることによって弊害が起きたりするのか
・解決策、方法：どういうシステムを作るかざっくり（メール送信、編集機能など）
・営業さんやディレクターさんへ確認したいこと：仕様について確認したいこと・仕様（ざっくり）
・WF（ワイヤーフレーム）：管理画面とかフロントなら簡単に書くだけでも説明する人に対してイメージしやすくなる
・影響範囲：他に影響がありそうな場合は書く
・工数（ざっくり）
・チケット、issueURL
・想定担当者：デザイナーやエンジニアの想定アサイン
・今後の流れ

まずこんな機能やりたいんだよね〜と言われたら、このテンプレートを埋めれるだけ埋めます。

埋めていくうちに、疑問点や決まってないこと、方法が現れるので、それを確認したいことに書いたり、WFを作って頭の中にイメージを作り、営業さんやディレクターさんにヒアリングをしたり、現状の仕様でできそう・できないなどを詰めていくことが多いです。

WFや仕様、工数、影響範囲はいらないんじゃないかと思う人もいるのですが、例えばすごく使われそうな機能でもあまりにも工数がかかるのであれば他のものを優先させようであったり、この機能を作ると課金周りにも影響があるな、など他に問題が出そうな所の確認にもなるので、把握している場合は書き留めておいた方が良いです！

実際に書くとこんな感じになる要求定義書の例

今回はユーザー登録の動線に、SNS登録を増やすという機能の例です。

がっつり機能ではなくても、ユーザーへのお知らせ機能とかで方法がいくつかあるとかでも大丈夫です！

# 概要：何をするのか、したいのかをざっくり書く
会員登録を簡単にするために、SNSでの登録機能を作る

# 課題：なんでそれをすることになったのか
今までは登録にメールアドレスを入れたり、項目が多く、手間がかかっていた

# 目的と効果：それをしたらどうなるのか、どんな効果が生まれるのか
メールアドレスだけでなく、SNSだと手間が省けてユーザーが入会する際に手間が省ける
会員数の増加にもつながる

# 解決策、方法
登録画面にSNS登録を作る
(複数案ある場合は、あるだけ書いた方が良いです）

# 問題点、懸念点：それをすることによって弊害が起きたりするのか
外部サービスに依存することによって、こちらで仕様を担保できなくなったりもする
個人情報的な問題もあるかも

# 営業さんやディレクターさんへ確認したいこと：仕様について確認したいこと・仕様（ざっくり）
- 他サービスでSNS登録者がどのぐらいいるのか
- どのSNSにするか（Twitter,Facebook,instagram,LINE）
- APIの仕様確認（個人情報取れないなど）
- 実際どのぐらい増えそうなのか

# WF（ワイヤーフレーム）：管理画面とかフロントなら簡単に書くだけでも説明する人に対してイメージしやすくなる

# 影響範囲：他に影響がありそうな場合は書く
通常登録にも影響あり
足りないDBの値はなんなのか調査しなきゃいけない（その場合別フォームで入力させるなど）

# 工数（ざっくり）
要求・要件定義 1週間
設計 3日
実装　1週間
テスト 3日
確認やレビュー 1週間

#チケット、issueURL
https://~~

# 担当者：デザイナーやエンジニアの想定アサイン
ログイン画面と画面遷移デザイン→Aさん
エンジニア→Bさん
ディレクター→Cさん

#今後の流れ
* チケット作成（担当：）
* 営業確認（担当：）
* 要件定義（担当：）
* WF作成（担当：）
* デザイン依頼（担当：）
* 結合テスト仕様書作成（担当：）
* 実装（担当：）
* レビュー（担当：）
* テスト（担当：）
* 本番反映（担当：）

まとめ

いきなり仕事を振られて、詳細が決まってないまま実装して戻しになったりすると、正直しんどかったり、最初に確認しておけばよかったなと後悔することになります。

そんな時は、まずはじめにこのテンプレートをぜひ使ってみてください！