システム開発の要件定義の進め方｜IT担当者がいない会社が最初に整理すること

システム開発の要件定義は、今の業務を言葉にして、流れを図にするところから始めたいと考えています。誰が、何を使って、どんな順番で仕事を進めているのか。その中で困っていることを確かめてから、変える業務と残す業務、システムで作る範囲を決めます。

私が車両管理システムを開発したときも、当初はデータ入力用の画面と管理画面を作る予定でした。ところが、クライアントと一緒に作っていく中で、そのまま導入すると現場の仕事の流れが変わりすぎると分かりました。そこで、入力には既存のExcelを残し、Webでは管理画面だけを作る方針へ変えました。

現場の目的は、システムを使うことではなく、業務を進めることです。 全部を一つのシステムに載せ替えることが、いつも正解になるわけではありません。

この記事では、この経験をもとに、IT担当者がいない会社でも着手できる要件定義の進め方を整理します。最初の聞き取りだけですべてを決め切ることは難しいので、作りながら確かめ、必要に応じて変えられる進め方も含めて考えます。

要件定義では、業務の目的とシステムに必要な条件を合意する

要件定義とは、システムで何を実現し、どんな条件を満たす必要があるかを整理して、発注側と開発側で合意する作業です。欲しい画面や機能に加え、対象となる業務、利用者、運用上の条件、今回作らない範囲も確かめます。

「業務として何を実現したいか」をまとめるのが業務要件定義。その内容をもとに、システムに必要な機能や性能などを具体化していきます。要件定義の後に行う基本設計では、合意した条件をどう実現するか、画面やデータの構成などを詰めます。工程の区切り方は案件によって異なります。

IT担当者がいなくても、業務の困りごとを伝え、何を優先するかを判断する役割は社内に必要です。技術的な検討や文書化は、外部のエンジニアと一緒に進められます。IPAの要件定義の解説でも、経営層・業務部門の参加と、業務上の要求からシステムの要件へ具体化する流れが説明されています。

入力画面を作る予定から、既存のExcelを残す方針へ変えた

車両管理システムの開発では、データ入力用の画面と、そのデータを管理する画面を作りたいという依頼がありました。最初は、その方向で開発を進めていました。

クライアントと一緒に作っていくと、システムの導入によって現行の業務フローが大きく変わり、現場の負担になるという課題が出てきました。機能として入力画面があっても、それを日々の仕事に組み込めるかは別の問題でした。

そこで、現場がすでに使っていたExcelファイルにマクロを付け、システムへデータを取り込めるようにしました。入力内容が条件に合っているかを確かめるチェック、いわゆるバリデーションも加えました。Webで作るのは管理画面だけにしました。

現場から見ると、使い慣れたExcelに入力チェックが加わる形です。この方法は受け入れられました。新しい入力画面に移ってもらうより、従来の仕事の進め方を残す方が、この案件には合っていました。

振り返ると、要件定義の段階でもっと業務フローを整理し、導入後の現場負担まで考えられていれば、最初からこの案にたどり着けた可能性はあります。ただ、それですべての問題を事前に拾えるとも思っていません。作りながら確認したからこそ分かることもあります。

この経験から、私は最初に業務を整理することと、途中で方針を変えられることの両方が必要だと考えています。

要件定義の進め方は、業務の整理から開発範囲の合意へ

初めてシステム開発を依頼する場合は、次の順番で考えると、開発会社へ伝える内容を整理しやすくなります。以下は、車両管理システムの経験も踏まえた、私が勧める進め方です。

1. 困っている業務を一つ選び、現場の流れを書き出す

まずは、どの業務で何に困っているかを一つ選びます。「管理画面が欲しい」という機能の話から入った場合も、その画面で誰のどんな仕事を変えたいのかまで戻って考えます。

実際にその仕事をしている担当者に、普段使うExcelや帳票、画面を見せてもらいながら聞きます。最初からきれいな仕様書を用意してもらう必要はありません。次の項目をメモにするだけでも、話し合う材料になります。

聞いた内容を作業の順番に並べ、担当者ごとに分けて矢印でつなぐと、業務フロー図になります。書き方に迷って止まるより、現場の人と見ながら「この間に確認が入る」「この場合は別の担当者へ戻す」と直していける図を用意したいところです。

2. 業務を変える余地と、残した方がよい部分を見分ける

現行の流れが分かったら、一つずつ「この作業は何のために必要なのか」を考えます。作業自体をなくせないか、手順を変えるだけで済まないか、既存のサービスを使えないかも検討します。

逆に、すでに現場で無理なく進んでいる作業を、システムに合わせるためだけに変える必要があるのかも確かめます。車両管理の案件では、既存のExcelを入力に使い続ける選択が、現場の負担を抑える方向につながりました。

Excelを残すことが常に最適、という話でもありません。複数人での利用、アクセス権限、マクロを使える環境、今後の保守など、残す場合にも検討は必要です。現場の使いやすさと、技術的に維持できるかを一緒に見て、業務とシステムの組み合わせを決めます。

3. 今回作る範囲と、後回しにするものを決める

システムで対応する範囲が見えてきたら、必要な機能に優先順位を付けます。最初の利用開始に欠かせないもの、後から追加できるもの、今回は作らないものを分けます。

車両管理の案件で最終的に選んだのは、Excelでの入力とチェック、システムへの取り込み、Webの管理画面という組み合わせでした。入力をすべてWebへ移す案から、作る範囲を見直した形です。

予算や利用を始めたい時期も、この段階で共有しておきます。予算が限られるなら何を先に実現するか、期限が動かせないなら何を後回しにするか。業務上の優先順位は発注側が判断し、開発側は実現方法や費用への影響を説明する、という分担が必要です。

見積もりの金額と作業範囲の関係は、システム開発の見積もりで確認したい内訳と前提でも整理しています。

4. 機能に加え、業務で使い続けるための条件を決める

データを登録する、一覧で見る、検索する、といった動作は「機能要件」です。要件定義では、これに加えて、誰が情報を見られるか、どれくらいの速さで処理したいか、止まったときにどう業務を続けるかも確認します。性能や安全性、運用上の条件は「非機能要件」と呼ばれます。

例えば、Excelからデータを取り込む仕組みなら、形式が違うデータをどう知らせるか、同じファイルを二回送ったらどうするか、取り込みに失敗した場合に誰が対応するかを考えます。これらは確認項目の例で、先ほどの案件の仕様や不具合を述べているものではありません。

技術に詳しくなければ、「この仕事は何時までに終わる必要がある」「この情報は担当者以外に見せられない」と業務の言葉で伝えてください。それを実現する条件へ具体化するところは、技術者と一緒に進めます。既存データの移行や、ほかのシステムとの連携があるかも、この時点で確認しておきます。

5. 要件定義書に残し、現場と開発側で読み合わせる

話し合った内容は、後から同じ理解に戻れるように文書へ残します。要件定義書の形式や詳しさは案件によりますが、少なくとも次の内容が分かる状態にしたいです。

• 解決したい業務上の課題と、目指す状態
• 現在の業務フローと、導入後の業務フロー
• 今回作る範囲、必要な機能、作らない範囲
• データの扱い、運用・品質の条件、既存システムとの関係
• 誰が、何を確かめて、利用開始を判断するか
• 未決定の事項と、それを誰がいつまでに確認するか

現場の担当者には、導入後の流れで普段の仕事を進められるかを確認してもらいます。予算や優先順位を決める人、技術面を判断する人も加わって読み合わせます。画面の試作品があれば、実際の作業に沿って操作すると、文章だけでは気づきにくい負担が見える場合があります。

分からないことが残る場合は、分からないまま確定したことにしない。調査や試作が必要な項目として分け、開発への影響を確認してから進めます。発注側に残したい判断については、システム開発を外注に丸投げしないためにで詳しく書いています。

変更を前提に、クライアントと確かめながら開発したい

業務フローを整理しても、最初にすべての要望や制約を拾い切るのは難しいと感じています。車両管理システムでも、クライアントと一緒に作る中で、現場の負担を考え直す必要が出てきました。

私は、こうした調整が多い案件では、準委任契約を使い、クライアントとスクラムで開発する方法が合っていると考えています。短い期間ごとに成果物を確かめ、次に何を作るかを見直していく進め方です。

請負で当初の範囲を固定して進める場合、要望が変わるたびに「契約に含まれるか」「追加の見積もりが必要か」という調整が増えやすいと感じます。そのため、変化が多いと見込まれる開発では、成果物と現場の仕事を確認する時間を確保できる進め方を選びたいです。

ただし、準委任なら無制限に変更できるわけではありません。請負では変更やアジャイル開発ができない、という意味でもありません。スクラムは開発の進め方で、契約形式とは別の話です。対象範囲、費用、期間、変更時の判断と合意の方法は、どちらの場合も確かめる必要があります。IPAのアジャイル開発外部委託モデル契約も、双方の協働と変更の扱いを考える際の参考になります。

要件定義を省いてよいとは考えていません。最初に目的や制約を共有しておくからこそ、変更案が出たときに、業務に必要な変更か、別の方法で済むかを話し合えます。

IT担当者がいない会社は、今使っている資料から相談できる

開発会社に相談する前に、完成した要件定義書を用意する必要はありません。困っている業務の説明と、実際に使っているExcelや帳票があれば、整理を始める材料になります。資料に個人情報や機密情報が含まれる場合は、共有範囲や方法を確認し、必要に応じて伏せてください。

技術者に整理や設計を頼む場合も、現場の仕事を説明できる人と、優先順位を決められる人には参加してもらいたいです。システム開発を頼むことと、自社の業務について考える役割を手放すことは同じではありません。

現場が進めたいのは日々の業務です。新しいシステムへ全部を移すことにこだわらず、今の流れを理解し、残すものと変えるものを選ぶ。そのうえで、実際に確かめながら修正していく。私は、そこから要件定義を始めたいと思っています。