トップ ／ コラム ／ 要件定義の進め方

要件定義を発注側で抱え込まない進め方｜エンジニア不在でもできる準備

「要件定義をまとめてください」と言われても、社内にエンジニアがいなければ何をどこまで書けばよいのか分かりません。かといって開発会社に任せきりにすると、できあがったものが業務に合わない。このページでは、要件定義を発注側だけで抱え込まず、それでいて丸投げにもしない進め方と、エンジニアがいなくても伝わる準備の具体的な方法を紹介します。

要件定義が「発注側の宿題」になりやすい理由

要件定義とは、「このシステムで誰が、何を、どのようにできるようにするか」を決めて文書にする作業です。業務のことを一番よく知っているのは発注側なので、従来のやり方では要件定義書の作成を発注側に求める進め方になりがちです。

ところが、要件定義書には画面の項目、データの持ち方、例外時の扱いなど、システムの作り方を知らないと書きにくい内容が多く含まれます。その結果、次のような状況が起こります。

• ひな形が埋められない

  渡された様式のどの欄に何を書けばよいのかが分からず、手が止まります。

• 想像で埋めてしまう

  分からないまま記入し、実際の業務とずれた内容が要件として残ります。

• 担当者一人が抱え込む

  ほかの業務と並行できず、検討そのものが止まってしまいます。

• 反対に、すべて任せてしまう

  途中の判断に関わらないまま進み、業務に合わないものができあがります。

問題は、発注側の努力不足ではありません。「業務を知っている人」と「システムに置き換えられる人」の役割が分かれていないことにあります。システム開発が失敗しやすい理由全体については、システム開発が失敗する5つの理由と発注側の対策で整理しています。

発注側が担うこと・任せてよいこと

要件定義を「全部自分たちで」か「全部任せる」かの二択で考える必要はありません。作業を分けると、発注側が担うべきことは思ったより限られています。

発注側が担うことに共通するのは、どれも技術の知識がなくてもできるということです。発注側が責任を持つのは「何を実現したいか」と「それで合っているか」の判断であり、文書を書く作業そのものではありません。

エンジニア不在でも伝わる5つの準備

相談の前に次の5つを用意しておくと、エンジニアがいなくても、依頼先に業務の実態が伝わりやすくなります。すべてそろっていなくても構いません。

準備1：業務の流れを「一日の動き」で書き出す

業務フロー図をきれいに描く必要はありません。「朝、申込メールを確認する」「申込内容を管理表に転記する」「月末に集計して上長に報告する」のように、担当者の動きを時系列で箇条書きにするだけで十分です。

ポイントは、誰が・何を見て・何をするかを書くことです。「確認する」なら何を確認するのか、「転記する」ならどこからどこへ転記するのかまで書くと、依頼先はそのまま画面の流れに置き換えられます。

準備2：困りごとを「場面」で集める

「効率化したい」「管理を楽にしたい」という言葉は目的としては正しいのですが、そのままでは機能に落とし込めません。困りごとは、具体的な場面で集めましょう。

• 「同じ情報を2か所に入力している」
• 「問い合わせがあるたびに、過去のメールを探している」
• 「担当者が休むと、誰も処理の仕方が分からない」

現場の担当者に「最近、手間だと感じた場面は？」と聞いて回るだけでも、多くの材料が集まります。

準備3：手元の資料をそのまま集める

規程・要領・マニュアル、申込書などの帳票、表計算ソフトの管理表、今使っている既存システムの画面。これらには、業務のルールや扱っているデータがすでに表れています。要件の多くは、新しく書き起こさなくても手元の資料の中にあるのです。

整理したり清書したりする必要はありません。むしろ、実際に使われている状態のまま渡したほうが、例外的な運用や手書きのメモまで読み取れます。個人情報が含まれる場合は、項目名だけ残してデータを消したものや、画面の写しで代用しましょう。

準備4：「必須」と「あると便利」を分ける

思いついた要望は、すべて書き出して構いません。そのうえで、「これがないと業務が回らない」ものと「あると便利」なものに分けておきましょう。最初から全部を作ろうとすると、費用も期間も膨らみ、肝心の機能の完成が遅れます。分けておけば、依頼先も優先順位を踏まえた提案ができます。小さく作って育てる進め方は、新規事業をMVPから始める進め方でも解説しています。

準備5：決める人と答える人を決めておく

打ち合わせで出た質問に答えるのは誰か、最終的に「これで進める」と決めるのは誰か。この2つを先に決めておくと、判断待ちで止まることが減ります。業務の細部に答えられる現場の担当者と、方針を決める責任者の両方が関われる体制が理想です。

「丸投げ」にしないための関わり方

要件の文書化を任せることと、丸投げは違います。丸投げとは、発注側が途中の判断に関わらず、完成品を見て初めて評価する状態のことです。次の3つを意識するだけで、関わり方は大きく変わります。

確認の場を先に予定に入れる

「何か決まったら連絡をください」ではなく、隔週などで確認の場を最初に決めておきましょう。予定があれば、判断すべきことがたまる前に片づきます。

文書ではなく画面で確認する

文章の仕様書だけでは、完成したときの姿を想像しにくいものです。画面のイメージや試作品を見せてもらい、「この画面で、いつもの業務ができるか」という視点で確認しましょう。実際の業務の一場面をたどりながら画面を操作してみると、抜けている処理に気づきやすくなります。

言葉の意味をそろえる

「会員」「受付」「完了」など、社内でよく使う言葉ほど、人によって指す範囲が違うことがあります。気になる言葉は「この場合はどうなりますか？」と具体例で確かめ、必要なら簡単な用語メモを共有しましょう。

ヒアリング当日の進め方

準備したものを持って依頼先と話すときは、次の順番で進めると整理しやすくなります。

1. 1

   目的を一言で伝える

   何のために、誰のためにシステムを作るのかを最初に共有します。

2. 2

   今の業務の流れを説明する

   準備1のメモを見ながら、一日の動きを順番に話します。

3. 3

   困りごとを場面で伝える

   準備2で集めた場面を、具体的に挙げていきます。

4. 4

   資料を渡して補足する

   規程や管理表のどこを見ればよいかを伝えます。

5. 5

   次に確認することを決める

   持ち帰る質問と、次回の確認の場を決めて終えます。

うまく説明できなくても問題ありません。質問を重ねて業務を言葉にしていくのは、依頼先の役割です。

pegの進め方：資料とヒアリングから要件を組み立てる

pegは、発注側に要件定義書の作成を求めません。ヒアリングと既存の資料を材料に、pegが要件を組み立て、完成まで導きます。たとえば次のような取り組みがあります。

• 日本眼科医会：会員管理システムの置き換え（材料：既存システム＋ヒアリング）
• ドローン操縦士協会：講習・実技時間の管理システム（材料：ヒアリング＋事務規程）
• 官公庁：予防接種の保護者不安を軽減するLINE AIチャット（材料：調査データ＋ヒアリング）

社内に専任のIT担当者を置きにくい中小企業の方は中小企業向けのご案内、協会・団体の方は協会・団体向けのご案内もご覧ください。既存システムの置き換えを検討中の方には、老朽化した業務システムの置き換え費用を抑える進め方も参考になります。

よくあるご質問