【b→dash #06】半年後に差が出る、非エンジニアのための要件定義３つのポイント

b→dashの導入・運用に対してお悩みをお持ちの  マーケターの方・その上司の方に向け、全12回に渡り解決のヒントをお伝えしていきます。

第6回は、非エンジニアのマーケターのための『半年後に差が出る 要件定義*３つのポイント』をテーマにお届けします。最後におまけ資料もありますので、ぜひ最後までご覧ください。
*要件定義：システム開発などのプロジェクトを始める前の段階で、必要な機能や要求をわかりやすくまとめていく作業のこと

非エンジニアであるマーケターのための半年後に差が出る要件定義のポイントを解説するにあたり、そもそも「要件定義」という非エンジニアにとって聞きなれない言葉について説明していきたいと思います。※ここでは、一般的なシステム開発ほどの高度な要件定義には言及せず、あくまでb→dashにおいて必要な最低限度の要件定義についてお伝えします。

私も完全未経験からb→dashの世界に飛び込んだ際に、この「要件定義」なる取り組みには本当に手を焼きました。基本的に、b→dashにおける要件定義は以下の流れで進みます。
１．要求の確認
２．課題や目的の明確化
３．アウトプットイメージの明確化
４．機能要件定義
５．非機能要件定義
６．要件定義書の作成
７．（データ設計）

まず、「要件」と「要求」の違いを簡単にお伝えすると、後者（要求）は「こういうことがしたい」という抽象度の高いビジネス上の目的を端的に表したもので、前者（要件）は「要求を充たすために必要となる条件」を表します。従って、「要求の確認」とは、新たに行う分析や施策において、何を達成したいのかをざっくりと確認します。

次に、より詳細に「要求」が解決したい課題や目的を明確にします。なぜならば、課題解決や目的達成の手段（＝要求）は１つではないからです。より経験豊富な担当者になれば、課題解決・目的達成のためにもっと効果的な要求を引き出してくれるかもしれません。

次に、上記を充たすためには、どのような分析用データ・施策用データが必要かを決めていきます。Excelなどを使って、実際のレポート画面のイメージや、メール配信シナリオなどを描き、最終的に必要となるデータにズレが起きないようにします。

次に、アウトプットイメージに沿って、どのようにデータを加工していけばいいかを明確にしていきます。例えば、「売上」という金額があったとしても、税込みで見たいのか、税抜きで見たいのか。値引き後の金額で見たいのか、送料はどうするのか、などを決めていく必要があります。

次に、「ｘｘ時までにレポートが最新化されてほしい」「ｘｘ時には、メール配信用のデータが最新化されて、自動で毎朝ｘｘ時にメールを配信したい」など、非機能要件（ユーザビリティ、性能、拡張性、セキュリティなど）を決めていく必要があります。

最後に、これまで決めたことをドキュメントに落とし込み、双方で検収を行います。

百聞は一見に如かず（ひゃくぶんはいっけんにしかず）という言葉通り、この文章を読んでもいまいちわからないと思いますので、ぜひおまけ資料を請求してみてください。

それでは、上記の流れを踏まえた上で、半年後に差が出る要件定義３つのポイントを見ていきましょう。

まず何より大事なことは、『ヒアリングの型を作ること』です。

ウェブサイトの構築などのシーンでも「ヒアリングシート」というものを用意することがほとんどだと思います。予めどういった内容をクライアントに確認をすれば、社内に確認をすれば、抜け漏れなく要件定義ができるかということをヒアリングシート（ドキュメント）に落とし込んでおくことが重要です。新しい要求が生まれるたびに、また一から思い付きでヒアリングをしてしまっていては、いずれ絶対聞き漏らしたポイントが出てきて、やり直しが発生し、プロジェクトが停滞してしまいます。

ヒアリングシートなどの型が予めあれば、誰が要件定義してもある程度の品質は担保できるようになります。ヒアリングをする側も楽ですし、ヒアリングをされる側も「毎回これは聞かれるから事前に決めておかないといけないな」という感じで事前準備をすることができるようになり、品質だけではなくスピードも向上することが可能となります。

但し、型を作りさえすればいいというものではありません。そこには適切なコミュニケーションが必要となります。まず間違いなく「これ埋めておいて」だけでは相手には正しく伝わらず、雑に記入したヒアリングシートが戻ってくるだけです。また、ヒアリングシートにおいて大事なのは「解釈の余地を残さないこと」です。b→dashに限らず、仕事において起こりがちなのが「ｘｘｘだと、思っていました」という思い込みによるやり直しです。主観的な「思っていました」ではなく、「誰がどう読んだとしても、同じ理解に至る」ような型であったり、書き方であったりする必要があります。そして、そのような書き方となるよう、時には読み合わせをしながら一緒に埋めていくことも必要となります。

最後が『要件定義した内容はドキュメントに残し、バージョン管理を適切に行うこと』です。

一般的に、要件定義後（最中）は、要件定義書に決定事項を落とし込んでいくものです。しかし、このドキュメンテーションにおいて起こりがちな失敗がいくつかあります。
・改修が発生した際に、要件定義書が更新されていない
・要件定義書が担当者のパソコンのローカル環境で管理されており、最新の要件定義書がわからなくなる
・改修内容が適切に管理されておらず、前回のバージョンから何がどう変わったのかがわからないなどです。

これらのドキュメンテーションにおける不備を避けるためには、ドキュメンテーションの業務プロセスを定義し、適切に運用されているかを逐次管理する必要があります。こういった面倒なバージョン管理は、非エンジニアにとっては慣れない作業であり、どうしても滞りがち、後回しになりがちです。一方で、エンジニアの方々はGitと呼ばれるソースコードや変更履歴を管理するために使われるバージョン管理システムを用いるのが一般的であるため、違和感のない作業となっています。

私も数多くのクライアント、特に引継のプロジェクトにおいてこれらのドキュメンテーションの運用が適切に行われておらず、実態の調査に多くの工数を費やしたことがあります。急がば回れです。あとから振り返った時に必ず役に立ちますので、要件定義書の管理は適切に行っていきましょう。

いかがでしたでしょうか？全12回の連載のうち、今回は『半年後に差が出る 要件定義３つのポイント』というテーマでお伝えさせていただきました。もし少しでもb→dashの初期導入における要件定義に不安を感じていらっしゃる方は、ぜひumbrEllaに一度お悩みをぶつけてみてください。きっと何かのお役に立てるかと思います。

最後までご覧いただきありがとうございました。

「問題はわかったけど、じゃあどうしたらいいの？」と思われたかと思います。続きが気になる方は以下の資料で「明日から使える３つのアクション」を解説しています。ご興味を持っていただけた方は、ぜひお気軽に資料請求をしてみてください（しつこい営業は一切行いません。※同業他社の方からの資料請求はお断りしておりますので予めご了承ください）。