要件定義のAs-Is/To-Be分析とは？業務分析のやり方と記入表

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

As-Is/To-Be分析とは？要件定義の業務分析の基本

As-Isは「今の姿」、To-Beは「あるべき姿、目指す姿」という意味です。資料ではasis、tobeのように書かれることもあります。

要件定義全体の流れは要件定義とはで紹介しています。ここでは、要件定義の業務分析としてAs-Is/To-Beをどう使うかに絞ってお話しします。

3つの言葉の関係

As-Is/To-Be分析で出てくる言葉は、次の3つだけ覚えておけば大丈夫です。

なぜ要件定義で業務分析をするの？

『システムを作るんだから、欲しい機能を聞けば足りるのでは』と思いますよね。ただ、欲しい機能だけを聞いて作ると、今の業務の困りごとをそのまま新しいシステムに持ち込んでしまうことがあるんです。

今の業務を知ってから目指す姿を描くと、「そもそもこの作業はいらない」「ルールを変えれば済む」といった気づきが出てきます。業務改善の要件定義で、業務分析が大事にされるのはこのためです。

業務分析で集める材料

As-Isを描く前に、手元に集めておきたい材料があります。聞き取りだけで描こうとすると、話す人の記憶に頼ることになってしまうんです。

規程と実際の流れを見比べると、違いのある所がそのまま聞き取りの質問になります。

As-Is/To-Be分析の進め方

As-Is/To-Be分析は、次の順番で進めると迷いにくくなります。

業務フロー図の描き方は、要件定義の業務フロー図の書き方で詳しく紹介しています。

As-Isは「ありのまま」を描く

今の業務を描く時は、決まりごとの上での流れではなく、実際の流れを描くのがコツです。規程ではこうなっているけど、実は別のやり方をしている、ということはよくありますよね。

開発側「購入の申請は、規程どおりに課長が承認していますか」
利用部門「急ぎの時は、先に注文して後から申請を出すこともあるんです」

こうした「実際の流れ」こそ、To-Beを考える時の大事な材料です。責めるような聞き方をせず、ありのままを話してもらえる雰囲気を作っておきましょう。

困りごとは原因まで書く

As-Isを描いたら、困りごとを書き出します。この時、困りごとだけでなく「なぜそうなっているのか」まで書いておくのが大事なんです。

原因まで書くと、対応の方向が自然と見えてきますよね。原因がわからない困りごとは、To-Beに進む前にもう一度現場に聞いてみてください。

To-Beは「目的」から描く

目指す業務を描く時は、今の流れを少し直すことから始めるより、変えたい理由から考えるほうがうまくいきます。「何のためにこの業務があるのか」を一度言葉にしてみてください。

例えば「購入の申請」の目的が「むだな買い物を防ぐこと」なら、少額の消耗品まで同じ承認を通す必要があるのか、という問いが出てきます。

差分から要件を拾う記入表

ここがこの記事でいちばんお伝えしたいところです。As-IsとTo-Beの図を2枚並べただけでは、要件定義は進みません。

差分を1行ずつ表に書き出し、「どう対応するか」と「要件としてどう書くか」まで埋めていきます。架空の題材として、社内の物品購入を申請してから発注するまでの業務を見直す場合の例を作ってみました。

左から右へ読むと、「今こうで、こう変えたいから、これを決める」という流れが1行で追えますよね。表の金額や期限は、業務部門と相談して決めていきます。

対応の種類は4つに分ける

差分には、システムを作らなくても解決できるものがたくさんあります。対応の種類を書いておくと、何でもシステムで解決しようとする流れを止められるんです。

「やめる」も立派な要件です。やめると決めた作業は、新しいシステムに引き継がないよう業務要件定義書に書いておきましょう。

差分に優先順位をつける

差分を書き出すと、思ったより行数が多くなることがあります。全部を一度に変えようとすると、予算も期間も足りなくなってしまいますよね。

そんな時は、効果の大きさと、変える手間の2つで差分を並べてみてください。

見送ると決めた差分も、消さずに記入表に残しておきましょう。次の見直しの時に、検討の出発点になります！

記入表を埋める時のコツ

『差分の列に何を書けばいいのか迷う』という方は、「何が変わるか」を一言で書くことから始めてみてください。うまく書けない行は、To-Beがまだ決まっていない行なんです。

業務要件を「誰が・いつ・何を・どの基準で」の形で書く方法は、業務要件定義とはで紹介しています。

影響調査も要件定義で行う

差分が出そろったら、次は影響調査です。ある業務を変えると、その前後の業務や、つながっているシステムにも変化が及ぶことがあります。

影響調査とは、変更によって影響を受ける業務、部署、データ、システムを洗い出す作業です。要件定義の段階で調べておくと、設計やテストの途中で「そこにも影響があったのか」と慌てずに済みますよ。

影響調査の記入例

影響調査の結果も、表にしておくと関係者と共有しやすくなります。差分の行ごとに、影響を受ける先と、その対応を書いていきます。

影響を受ける先の担当者には、要件定義の段階で一度話をしておくと安心です。後から「聞いていない」と言われるのを防げますよ！

特に、担当者が個人で作っている集計は、業務フロー図に描かれていないことが多いんです。ヒアリングの最後に「この記録を、ほかに使っている人はいますか」と一言聞いておきましょう。

システムを入れ替える場合の影響調査や移行の考え方は、システム移行・リプレースの要件定義で詳しく紹介しています。

業務改善の要件定義でつまずきやすいところ

業務改善を目的にした要件定義では、As-Is/To-Be分析でつまずくポイントがいくつかあります。よくあるものを先に知っておくと、避けやすくなります。

As-Isに時間をかけすぎる

『今の業務を全部描き切らないと、To-Beに進めない』と考えてしまう方もいます。気持ちはわかりますが、As-Isの図を細かく描くことに時間を使いすぎると、肝心のTo-Beを考える時間がなくなってしまいます。

As-Isは、困りごとと、その原因が見える細かさで十分です。変えない部分は、ざっくりと描くだけにしておきましょう。

To-Beが理想だけになる

逆に、To-Beを理想だけで描いてしまうこともあります。予算や期間、今の人員で回せるかを考えないと、描いた姿が絵に描いた餅になってしまいます。

関係者の意見が割れた時

To-Beを描いていると、部署によって目指す姿が違うことがあります。こうした場面では、どちらが正しいかを決めるより、目的に立ち返るのが近道です。

利用部門「承認を減らすと、むだな買い物が増えるのが心配です」
開発側「では、金額ごとの申請の件数を見てから、課長だけで承認する金額を決めるのはどうでしょう」

このように、心配の中身を聞いて、判断の材料を用意すると話がまとまりやすくなります。決まらない点は、決める人と期限を書いて課題一覧に残しておきましょう。

To-Beは、業務部門の責任者と担当者が一緒に描くのが基本です。要件定義全体での進め方は、要件定義の進め方も参考にしてみてください。

よくある相談に答えます

As-Is/To-Be分析や業務分析について、よく寄せられる相談を要約してお答えします。

やったことのない業務の要件定義は、どう進める？

「自分が経験したことのない業務を要件定義する時は、どうすればよいのか」という相談があります。結論から言うと、まずAs-Isを教えてもらうところから始めるのが近道です。

業務の担当者に、今の流れを一つずつ話してもらい、その場で業務フロー図に描いて見せてみてください。「そこは違う」と直してもらううちに、業務の目的や困りごとも自然と見えてきます。

要件が技術的に難しすぎるとわかったら？

「要件定義の途中で、ある要件が技術的に難しすぎるとわかった時はどうすればよいか」という相談もあります。As-Is/To-Beの記入表に戻って、その要件の元になった差分を見直してみてください。

差分の対応を「システム化」から「ルール変更」に変えるだけで、目的を果たせることもあります。目的は守りつつ、手段を変えられないかを業務部門と話し合いましょう。

オリジナルのシステムの見積もりは、何をもとに作る？

「完全にオリジナルのシステムを作る時、見積もりは何をもとに作ればよいのか」という相談も見かけます。見積もりの土台になるのは、要件定義で決めた作るものの一覧です。

As-Is/To-Beの記入表で「システム化」とした差分が、作るものの候補になります。差分の行数や中身がはっきりしていれば、見積もりの前提も説明しやすくなりますよ。

逆に、To-Beが決まっていない段階で出した見積もりは、前提が揺れやすくなります。見積もりを頼む時は、記入表と一緒に「まだ決まっていないこと」の一覧も渡しておくと、見積もる側も前提を書き添えやすくなります。

よくある質問

まとめ

あわせて読みたい

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

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

業務要件定義とは？誰が・いつ・何をで書く記入例つき解説