システム開発の要件定義とは？発注側が決めること

業務のシステム化を開発会社に相談する際、多くの経営者や業務担当者が迷うのが「要件定義で何をどこまで決めればよいのか」という点です。要件定義とは、作るものと作らないものを発注側と開発会社の双方が言葉にしてそろえる工程であり、この工程があいまいなまま開発に進むと、完成後に認識のズレが表面化しやすくなります。本記事では、要件定義で決めるべき項目と、発注側が事前に準備しておきたいことを整理します。

システム開発の要件定義とは何か

要件定義とは、「どのような業務を、どのように支援するシステムを作るか」を文章や図で明確にする工程です。発注側の頭の中にある業務のイメージを、開発会社が実際に手を動かして作れる形に翻訳する作業ともいえます。

この工程を飛ばして見積もりや開発に進んでしまうと、発注側と開発会社がそれぞれ異なる前提でシステムを思い描いたまま作業が進むことになりかねません。要件定義は、両者の認識を一致させるための共通言語を作る工程だと考えると分かりやすくなります。

要件定義があいまいなまま進めるとどうなるか

要件定義が不十分なまま開発が進むと、完成後に「思っていたものと違う」という食い違いが起こりやすくなります。これは発注側・開発会社のどちらが悪いという話ではなく、決めるべきことを決め切れていなかったことが原因で生じやすい構造的な問題です。

• 想定していた機能が入っていなかった
• 業務フローの一部が考慮されていなかった
• 追加で機能を足すために追加費用が発生した
• 完成後の修正に時間がかかり稼働が遅れた

こうした事態は、要件定義の段階で「何を作り、何を作らないか」を言葉として残しておくことで、起こる可能性を下げられると考えられます。

要件定義で決めるべき項目

要件定義では、業務の内容からシステムの細部まで、段階を追って決めていきます。主な項目は次の通りです。

業務の流れ(現状と改善後)

現在どのように業務が流れているか、システム化後はどう変わるのかを整理します。現状の業務フローを言語化することが、要件定義全体の出発点になります。

利用者と権限

誰がシステムを使うのか、役職や部署ごとにどこまで操作できるようにするのかを決めます。閲覧のみの利用者と、入力・修正まで行う利用者を分けるかどうかも検討点です。

必要な機能と画面

業務を進める上で必要な機能と、それを操作する画面のイメージをすり合わせます。一覧画面、入力画面、検索機能など、業務の場面ごとに必要なものを洗い出します。

扱うデータと既存データの移行

システムで扱うデータ項目を決めるとともに、現在Excelや紙で管理しているデータを新システムへ移すかどうか、移す場合はどこまで移行するかを検討します。

他システムとの連携

会計ソフトや販売管理など、既存の他システムとデータをやり取りする必要があるかを確認します。連携の有無によって開発の難易度や範囲が変わってきます。

運用・保守の体制

システム完成後、誰が日常的な操作のサポートをするのか、不具合が起きた際にどこへ連絡するのかといった体制も、要件定義の段階で話し合っておく項目です。

非機能面(端末・セキュリティ・バックアップの考え方)

パソコンかスマートフォンか、社内からのみ使うのか外出先からも使うのかといった利用端末の想定、アクセス制限などのセキュリティ、データのバックアップ方針も、要件として言葉にしておく必要があります。

業務要件とシステム要件の違い

要件定義では「業務要件」と「システム要件」という2つの言葉がよく使われます。業務要件は「何をしたいか」、システム要件は「それをどう実現するか」という違いで理解すると整理しやすくなります。

• 業務要件の例:在庫を部署間でリアルタイムに共有したい
• システム要件の例:在庫データをデータベースで一元管理し、各端末から参照できる画面を用意する

発注側は業務要件を中心に伝え、それをシステム要件に落とし込むのは開発会社の役割です。ただし、業務要件があいまいだとシステム要件も定まらないため、発注側の言語化が重要になります。

発注側が準備しておくべきこと

要件定義をスムーズに進めるためには、発注側が事前にいくつかの材料を用意しておくことが役立ちます。

• 現在の業務フローの書き出し(誰が、いつ、何をしているか)
• 現在使っている帳票やExcelファイルの現物
• 業務上の困りごととその優先順位
• 社内の決裁者と、開発会社とのやり取りを担当する窓口

これらを事前に整理しておくことで、開発会社とのヒアリングが具体的になり、要件定義の精度が上がりやすくなります。特に困りごとの優先順位は、後述する機能の線引きにも直結する材料です。

必須機能と後回しにできる機能の線引き

要件定義では、すべての要望を一度に実現しようとせず、「今すぐ必要な機能」と「後回しにできる機能」を分けることが現実的な進め方になります。

• 必須機能:それがないと業務が回らない機能
• 後回しにできる機能:あると便利だが、代替手段(手作業やExcel)でしのげる機能

この線引きをせずに要望をすべて盛り込もうとすると、開発範囲が広がり、費用や期間にも影響が出やすくなります。優先順位をつけたリストを発注側で用意しておくと、開発会社との調整がしやすくなります。

要件定義書の確認方法と合意の残し方

要件定義の内容は、口頭のやり取りだけで終わらせず、文書として残し、双方で確認・合意することが重要です。

• 業務フローや画面イメージが、実際の業務と食い違っていないか確認する
• 専門用語が分からない場合は、その場で言い換えを求める
• 「決まったこと」と「保留にしたこと」を分けて記録してもらう
• 合意した内容には、決裁者を含めて確認・押印やメールでの承認を残す

要件定義書は完成後の判断基準にもなるため、理解できないまま署名・承認することは避け、疑問点はその都度解消しておくことが望ましいといえます。

要件定義を有償の工程として依頼する考え方

要件定義は、開発会社にとっても相応の時間と専門知識を要する作業です。そのため、要件定義そのものを有償の工程として独立して依頼する進め方も一つの考え方です。

無償の範囲で簡易なヒアリングだけを行い、そのまま開発に進んでしまうと、業務の細部まで把握しきれないまま設計が進むおそれがあります。要件定義を有償工程として位置づけることで、発注側・開発会社の双方が時間をかけて内容を詰めやすくなり、結果として後工程での手戻りを減らすことにつながると考えられます。

よくある質問(Q&A)

Q. 要件定義にはどのくらいの社内協力が必要ですか

A. 現場の業務を把握している担当者がヒアリングに同席することが望ましいです。経営者だけでなく、実際にシステムを使う担当者の声も要件定義に反映させることで、現場の実態に合った内容になりやすくなります。

Q. 要件定義の途中で要望が変わってもよいですか

A. 業務を整理する過程で新たな要望が出てくることは自然なことです。ただし、追加や変更が発生した場合は、開発会社と改めてすり合わせを行い、記録に残しておくことが後のトラブルを防ぐ助けになります。

Q. 要件定義書は専門用語が多くて読みにくいのですが

A. 分からない用語があれば、その都度開発会社に平易な言葉での説明を求めることをおすすめします。内容を理解しないまま進めることは避けた方がよいといえます。

まとめ

システム開発における要件定義は、発注側と開発会社が「作るものと作らないもの」を言葉でそろえる工程です。業務フローや利用者、必要な機能、データの扱い、運用体制、非機能面まで、決めるべき項目は多岐にわたります。発注側が業務フローや困りごとの優先順位をあらかじめ整理し、必須機能と後回しにできる機能を分けておくことで、要件定義はより実のあるものになります。要件定義書は文書として確認し、合意内容を残すこと、そして必要であれば要件定義そのものを有償の工程として依頼することも、システム化を着実に進めるための選択肢の一つです。

システム開発の成功は、要件定義の質で大きく左右されます。ご自身の業務要件をどのように整理し、開発会社とすり合わせるかでお悩みでしたら、ぜひ大和にご相談ください。要件定義から開発後のサポートまで、クリエイティブなWebやシステムの視点から、貴社の課題を一緒に整理するお手伝いをします。

お問い合わせ