はじめに
何らかの目標を達成しようとする時、抽象的な現状の課題やアクションプランを抽出する方法としてAS-IS/TO-BE分析があります。
AS-IS/TO-BE分析は、ASーIS（現状）とTOーBE（理想像）を整理し、その間にある差分（ギャップ）を課題として洗い出した上で、課題を解決するためのアクションを行っていくことにより、目的を達成するやり方です。
今回は、このAS-IS/TO-BE分析について説明をしていきたいと思います。
目次
- 1.なぜAS-IS/TO-BE分析が必要なのか？
- 2.AS-IS/TO-BE分析の流れ
- まとめ
1.なぜAS-IS/TO-BE分析が必要なのか？
まずは、AS-IS/TO-BE分析が必要となる理由から見ていきたいと思います。理由は様々なものがありますが、今回は下記の3点について説明したいと思います。
1.1 現実的な課題を抽出できる
現状を意識せずに課題の検討を行うと、実態にそぐわない非現実的な課題やアクションになってしまう恐れがあります。AS-IS/TO−BE分析を利用することで、必ず現状をAS-ISとして意識することから、非現実的な課題になってしまうリスクを下げることができます。
例えば、「売上を20%上げたい」というような理想像（TO-BE）があったとします。現状を分析した上で、ターゲットとする市場がまだ浸透していない状態であれば、広告を増やすなどで対応できる可能性があります。しかし、すでに市場が飽和状態であれば、闇雲に広告を増やすだけでは売上げアップはできず、まだ開拓できていない客層にヒットする広告を立てたり、開拓されていない市場に進出したりといった対応も必要になります。このように、理想像だけではなく現状を意識しないと正しい課題やアクションを導くことができません
以上のことから、現実的な課題を抽出する上でAS-IS/TO-BE分析は有効であると言えます。
1.2 意味のある課題を抽出できる
理想論や目標を意識せずに課題の検討を行うと、あまり意味がない、いわゆる「その場しのぎ」の対応となってしまう恐れがあります。AS-IS/TO-BE分析は必ず理想論や目標をTO-BEとして定義するため、TO-BEを意識することで「その場しのぎ」ではない、意味のある課題を抽出することができます。
例えば、売り上げが100万円であるという現状（AS-IS）だけがあったとします。その状態でただ売上を上げようとしたら、数万円でもアップしていけばとりあえずその場をしのげます。しかし、ただ少し売上が上がっただけで、会社に対して利益もメリットもない、意味のない対応になっている可能性があります。この際、TO-BEとして「売上を150万円にする」と言う目標があれば、150万円にするために必要となる課題を抽出することができます。それが実現できれば、少なくとも「その場しのぎ」ではない、意味のあるものとなります。
以上のことから、意味のある課題を抽出して「その場しのぎ」にならないようにするために、AS-IS/TO−BE分析は重要と言えます。
1.3 提案や説明のための論理が組み立てやすい
提案や説明の際には、わかりやすく論理を組み立てて行う必要があります。ただ起きたことや考えたことを羅列するだけでは伝わらないことが多いです。
AS-IS/TO-BE分析は、AS-ISとTO−BE → 課題 → アクションプラン の順に組み立てて説明できるので、「なぜその結論に至ったのか」と言う流れがわかりやすくなります。
このように、提案や説明をわかりやすく行うためにも、AS-IS/TO-BE分析は有効であると言えます。
2.AS-IS/TO-BE分析の流れ
実際にAS-IS/TO-BE分析を行う流れを見ていきたいと思います。正式に決まっている形はありませんが、よく利用する例として以下のような流れで説明します。
2.1 テーマを決める
テーマについて
まずは、解決したい内容のテーマを決めます。ここで決めたテーマに基づき、AS-ISとTO-BEを整理していきます。
例えば、以下のようなテーマの例が考えられます。
テーマの例
- 請求業務の改善
- システム品質の向上
- 売上の向上
テーマの記載粒度について
テーマについて細かい内容まで記載する必要はなく、簡潔な一言で記載すればよいかと思います。
なぜなら、ここで記載するテーマが細かすぎると、その後のAS-ISやTO-BEもそれに引きずられて検討範囲が狭まってしまう可能性があるためです。
例えば、テーマとして「請求の業務を自動化して作業効率化する」というような細かい内容を指定したとします。そうすると、AS-ISやTO-BEには「自動化」に関することしか記載しにくくなるのですが、実際に作業効率化のためには自動化以外の手段もあるので、検討の幅が狭まってしまいます。「作業効率化する」と言うような広いテーマにしておけば、自動化以外のことも記載しやすくなるので検討の幅が広がります。
以上のことから、テーマについては必要以上に細かくしすぎず、幅広い内容で記載すると良いです。
2.2 AS-ISとTO-BEを洗い出す
テーマが決まったら、それに対するTO-BE（理想像）を整理します。
どちらから先に洗い出すのか？
AS-ISとTO-BEのどちらから先に分析するかについてですが、状況に応じて異なってきます。
現状で問題点が明確に定まっている場合や、現状を重視した解決策を実施したい場合はAS-ISから先に分析したほうが適切と言われます。逆に、現状にとらわれずにあるべき姿や理想像を正しく見極めたい場合はTO-BEから先に分析したほうが良いです。
AS-ISから先に洗い出す場合
AS-ISから先に分析する場合、まずはテーマに応じて現状を記載します。例えば「システム運用の品質を上げたい」と言う目標があった場合、品質に絡む項目として「バグの発生件数」や「問い合わせ件数」、「システム停止時間」等の現在の数値を記載したりします。
具体的には、以下のようなAS-ISの例が考えられます。
AS-IS
- バグの発生件数は年間100件
- 問い合わせの発生件数は年間200件
- システム障害による停止時間は全体の10%発生している
次にTO-BEになりますが、基本的にはAS-ISに対比する形で記載します。AS-ISで挙げた項目に対して、理想像やあるべき姿をTO-BEとして記載します。今回の例であれば、目標とする数値などを記載すると良いです。
具体的には、以下のようなものが考えられます。
TO-BE
- バグの発生件数を年間10件以内に抑える
- 問い合わせの発生件数を年間20件に抑える
- システム障害による停止時間時間をゼロにする
TO-BEから先に洗い出す場合
次に、TO-BEから先に洗い出す例を説明します。TO-BEから洗い出す場合は、一旦は現状を意識せず、理想像と言う形でTO-BEを記載します。
AS-ISから記載する例で挙げたバグの発生件数や問い合わせ件数の理想値から洗い出していく方法もあります。それ以外にも、現状を意識せず「オペレーション業務を自動化する」、「サーバをクラウドに移管する」というような目標を立てる事もできます。このような例は現状を元に分析するとなかなか上がってこなかったりするので、TO-BEから先に洗い出しするメリットの一つと言えます。
TO-BE
- システムのオペレーション業務をすべて自動化する
- サーバをすべてクラウドに移管する
TO-BEの洗い出しができたら、TO-BEと対比する形で現状をAS−ISとして記載します。TO-BEとして記載した内容を元に、それが現状どの様になっているかを洗い出します。
具体的には、以下のような例が考えられます。
AS-IS
- 手動のオペレーション業務が一日あたり2時間程度発生している
- サーバはすべて自社のデータセンターに配置されている
2.3 ギャップを課題として洗い出す
課題の洗い出し
AS-ISとTO-BEが洗い出しできたら、次にその間にあるギャップを課題として洗い出します。つまり、AS-ISからTO-BEへ移行することにあたり、障壁となっているものを洗い出します。
例えば、AS-ISが「バグの発生件数は年間100件」、TO-BEが「バグの発生件数を年間10件以内に抑える」であった場合、発生しているバグの傾向などを分析したり、実際の開発エンジニアにヒアリングするなどして、障害が発生している要因となっているものを洗い出し、課題として定義します。
具体的には、以下のような課題が考えられます。
課題
- 外部システムへのデータ連携でバグが多発している
- バグ対応により新たなバグを埋め込んでいるケースが多い
- 現状のシステムが複雑であり、修正の難易度が高い
仮設と検証
課題の洗い出しには、仮設と検証を繰り返すプロセスが必要になります。
AS-ISからTO-BEを実現するために「これが必要なのではないか」と言う仮設を立てます。仮設を立てるには以下のような方法が考えられます。
- インプットとなる情報から分析する
- 関係者にヒアリングを行う
- フレームワークを活用する
- 類似の事例を参考にする
仮設を立てたら、それが妥当かどうか検証します。具体的には、複数の要素を元に仮設が当てはまるかを分析したり、シミュレーションをしてみたり、第三者のレビューを受けたり、といった方法が考えられます。
仮設が間違っている部分があれば見直したり、別の仮設を立てたりして、仮設と検証を繰り返していきます。そうしていく中で、今回のTO-BEの実現に必要となる課題を洗い出していきます。
2.4 課題を対応するためのアクションプランを立てる
アクションプランを立てる
洗い出した課題に対して、解決するためのアクションプランを立てます。アクションプランを立ててそれを解決することで、TO-BEで設定した理想像を達成できると言う考えです。
先程のバグ発生件数の例で洗い出した課題に対して、アクションプランを立ててみた例が以下になります。
外部システムへのデータ連携でバグが多発している
- 外部とのデータ連携部分について強化テストを行う
バグ対応により新たなバグを埋め込んでいるケースが多い
- バグ対応後に回帰テストを行う
現状のシステムが複雑であり、修正の難易度が高い
- リファクタリングによりコードを簡略化する
- 利用していない機能を停止する
優先度を決める
アクションプランをいくつか提示した後は、それに対して優先度を決めます。すべてのアクションプランを最優先で対応できればそれに越したことはないのですが、予算やコスト、人員等の都合で難しいことが多いです。そのため、優先度をつけて対応の順番を決めたり、場合によっては対応自体を見送ったりといった判断をします。
優先度の決め方については様々なやり方がありますが、そのアクションプランの実行にかかるコストと、実行した際の効果を比較した上で、コストに対しての効果が高いものから優先に対応するやり方があります。
まとめ
AS-IS/TO-BE分析の方法をご紹介しました。AS-IS/TO-BE分析を行うことで、抽象的な目標に対する課題やアクションプランを計画することがしやすくなります。
もしご興味持っていただけたら、今後の課題分析や提案活動などでご活用いただけたら幸いです。
最後までご覧いただきありがとうございます。