要件定義の進め方とやり方｜6つの手順と週ごとのスケジュール例

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義の進め方は6つの手順で考える

要件定義とは、システムで実現することを決めて、発注側と開発側で合意する工程です。

意味から確かめたい方は、要件定義とは？意味をわかりやすく解説を先に読んでおくとスムーズです。

全体の流れは、次の6つの手順で考えると分かりやすくなります。

『手順は分かったけど、実際に何をすればいいの？』と感じた方も多いはずです。

ここからは、手順ごとに「何をするか」「何を残すか」を見ていきます。

手順ごとのやり方と、つまずきやすいところ

手順1 目的と範囲を確かめる

最初にやるのは、なぜこのシステムを作るのかを関係者で同じ言葉にそろえることです。

目的があいまいなまま聞き取りを始めると、要望が際限なく広がってしまいます。

キックオフでは、次のような問いを投げかけてみてください。

「今回のシステム化で、いちばん減らしたい手間は何ですか？」

「対象外にしてよい部署や業務はありますか？」

この2つに答えが出るだけで、決める範囲がぐっと絞れます。

手順2 今の業務と課題を把握する

次に、今の業務がどう流れているかを聞き取ります。

利用部門の担当者に、普段の作業を最初から最後まで話してもらうのが近道です。

聞き取りでは、次のような質問を用意しておくと話が広がりすぎません。

聞き取った内容は、部署ごとにレーンを分けた業務フロー図にしておくと、関係者と同じものを見ながら話せます。書き方は要件定義の業務フロー図の書き方で詳しく紹介しています。

手順3 目指す業務の姿を描く

今の業務（As-Is）と目指す業務（To-Be）を比べて、その差から必要な対応を洗い出します。

『今のやり方を、そのままシステムにすればいいのでは？』と思うかもしれません。

ただ、それでは手間の多い作業までそのまま残ってしまうことも。課題ごとに「やめる」「まとめる」「システムに任せる」のどれにするかを決めていきます。

比べ方のコツは要件定義の業務分析（As-Is/To-Be）にまとめています。

手順4 業務要件・機能要件・非機能要件を決める

目指す業務の姿が決まったら、それを実現するための要件を決めます。

業務要件は業務をどう変えるか、機能要件はシステムが何をするか、非機能要件はどのくらいの品質で動くかです。

非機能要件は、IPAの「非機能要求グレード」を使うと話がかみ合いやすくなります。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目で、レベルを0〜5の段階で選ぶ方式です。

経費精算システムの例で、3つの要件を書き分けるとこうなります。

この記入例も架空の題材です。実際には、非機能要件のレベルを関係者で話し合って具体的な値に落としていきます。

手順5 要件定義書にまとめる

決めたことを、要件定義書として文書にまとめます。

背景・目的、対象範囲、業務要件、機能要件、非機能要件、移行や運用の要件、未決事項といった章立てが一般的です。様式は会社ごとに違うので、社内のひな形があればそれに合わせましょう。

章ごとの書き方は要件定義書の書き方で詳しく解説しています。

手順6 レビューして関係者の合意を取る

最後に、関係者で読み合わせをして、修正したうえで承認を取ります。

レビューでは、「この一文を読んで、テストで確かめられるか」という目で見るのがおすすめです。

週単位で見る要件定義のスケジュール例

手順が分かっても、『で、毎週の会議で何を話せばいいの？』となりますよね。

そこで、社内の経費精算システムを入れ替える場合を例に、キックオフから合意までを週ごとに区切ったスケジュール例を作ってみました。

期間は案件の規模や関わる部署の数で大きく変わるので、ここでは週の数ではなく「並び方」を参考にしてください。

このスケジュール例は、要件定義のやり方をイメージしやすくするための架空の例です。

前半で今の業務を、中盤で目指す姿と機能を、後半で品質と文書の仕上げを扱う、という並びがポイントです。

実際には、聞き取りの回数が増えたり、機能の検討を2回に分けたりすることもあります。

会議と会議の間にやっておくこと

週1回の会議だけで要件定義が進むわけではありません。

会議の間に、次のような準備と後片付けを済ませておくと、当日は「決めること」に時間を使えます。

『資料を先に送っても、誰も読んでくれない…』ということもありますよね。

そんな時は、会議の最初の数分を「資料の要点の読み上げ」にあてると、話し合いがかみ合いやすくなります。

会議を空回りさせないコツ

定例会議が「話しただけ」で終わると、翌週に同じ話を繰り返すことになります。

会議の進め方は、毎回次の形にそろえておくと安定します。

最後の読み上げでは、こんな言い方が使えます。

「今日決まったのは、承認は2段階にすることです。部長不在時の扱いは、利用部門で来週までに決めていただく宿題でよろしいですか？」

この一言があるだけで、後から「そんな話だったっけ？」となるのを防げます！

業務要件定義とシステム要件定義で進め方はどう変わる？

要件定義と一口に言っても、業務の話を決める段階と、システムの話を決める段階があります。

業務要件定義の進め方では、今の業務と目指す業務を比べる手順2と3に時間をかけます。

ここで気をつけたいのは、今のやり方をそのままシステムにしないことです。課題ごとに、やめるか、まとめるか、システムに任せるかを利用部門と一緒に決めていきましょう。

システム要件定義の進め方では、手順4の機能要件と非機能要件を細かく決めることが中心です。

システム開発の要件定義の進め方として、両方を一続きで進めることも多いです。

例えば、業務の流れを決める会議に開発側のSEが同席すると、実現できるかどうかをその場で確かめられます。

逆に、画面や性能の話をする会議には、実際にシステムを使う担当者に来てもらうと、使う場面に合った要件になります。

その場合も、会議の議題が業務の話かシステムの話かを意識しておくと、参加してもらう人を選びやすくなります。

要件定義の進捗管理のやり方

要件定義は、作る物が目に見えにくい工程です。

だからこそ、要件定義の進捗管理では「何が決まって、何が残っているか」を表で追えるようにしておくのがおすすめです。

例えば、課題管理表はこんな形で書きます。

この記入例も架空の例です。状態は「未着手、対応中、決定済み」の3つ程度に絞ると、毎週の更新が楽になります。

こうしたサインが出たら、決める人を一人に絞るか、上の立場の人に判断を預ける場を作りましょう。

進捗を報告する時の伝え方

上司や発注側の責任者に進捗を報告する時は、「予定どおりです」だけで終わらせないのがポイントです。

決まった項目、残っている課題、判断してほしいことの3つを、短く伝えましょう。

「機能の一覧は予定どおり決まりました。残る課題は2件で、そのうち旧データを移すかどうかは、来週までにご判断いただきたいです」

判断してほしいことを最後に置くと、相手も何をすればいいかがすぐ分かります。

遅れている時ほど、早めに伝えるのが大切です。理由と、取り戻すための案を一緒に添えると、相談として受け止めてもらいやすくなります。

要件定義が進まなくなる理由は、要件定義が難しい理由とつまずきポイントでも詳しく見ています。

よくある相談に答えます

要件定義の進め方について、よく寄せられる相談を要点だけまとめて答えます。

キックオフミーティングでは何をすればいい？

『キックオフって、あいさつだけで終わっていいの？』という相談は意外と多いです。

キックオフでは、目的、対象範囲、体制、会議の日程の4つを共有するのがおすすめです。

特に「誰が最終的に決めるのか」は、この場ではっきりさせておきましょう。ここがあいまいだと、後の会議で決めきれない場面が増えます。

もう一つ大事なのが、会議の進め方のルールを共有することです。

「資料は前日までに送ります」「決まったことは当日中に議事録で共有します」と最初に伝えておくと、参加者も準備がしやすくなります。

経験はあるのに、上流の仕事の進め方が分からない

開発やテストの経験はあるものの、要件定義のような上流の仕事になると何から始めればいいか分からない、という悩みもよく聞きます。

上流の仕事は、作る作業よりも「聞く」「書く」「決めてもらう」作業が中心です。

まずは議事録を書き、課題管理表を回すところから担当してみてください。会議で何が決まり、何が残るのかが見えてくると、進め方の勘所がつかめます！

確認し忘れた要件が後から見つかって、やり直しになる

要件定義から設計に進んでから、肝心な要件の確認漏れに気づくという相談もあります。

これは、手順2で例外の扱いを聞いていない時に起こりがちです。

聞き取りのたびに「いつもと違う時はどうしていますか？」と一言添えるだけでも、漏れはかなり減らせます。

あわせて、手順6のレビューで「この要件はテストで確かめられるか」を一つずつ見ていくのも効きます。確かめ方が思い浮かばない要件は、まだ決めきれていないサインです。

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義書の書き方を手順で解説｜NG文の直し方と章ごとの記入例

要件定義の業務フロー図の書き方｜スイムレーン図の手順とチェック