AS-ISとTO-BEを意識してやるべきことを整理しよう

# はじめに
何らかの目標を達成しようとする時、抽象的な現状の課題やアクションプランを抽出する方法として**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を整理していきます。

例えば、以下のようなテーマの例が考えられます。

:::note info
テーマの例
- 請求業務の改善
- システム品質の向上
- 売上の向上
:::

### テーマの記載粒度について
テーマについて細かい内容まで記載する必要はなく、**簡潔な一言**で記載すればよいかと思います。

なぜなら、ここで記載するテーマが細かすぎると、その後の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の例が考えられます。

:::note info
AS-IS
- バグの発生件数は年間100件
- 問い合わせの発生件数は年間200件
- システム障害による停止時間は全体の10%発生している
:::

次にTO-BEになりますが、基本的には**AS-ISに対比する形**で記載します。AS-ISで挙げた項目に対して、理想像やあるべき姿をTO-BEとして記載します。今回の例であれば、目標とする数値などを記載すると良いです。

具体的には、以下のようなものが考えられます。

:::note info
TO-BE
- バグの発生件数を年間10件以内に抑える
- 問い合わせの発生件数を年間20件に抑える
- システム障害による停止時間時間をゼロにする
:::

### TO-BEから先に洗い出す場合
次に、**TO-BEから先に洗い出す例**を説明します。TO-BEから洗い出す場合は、一旦は現状を意識せず、**理想像**と言う形でTO-BEを記載します。

AS-ISから記載する例で挙げたバグの発生件数や問い合わせ件数の理想値から洗い出していく方法もあります。それ以外にも、現状を意識せず「オペレーション業務を自動化する」、「サーバをクラウドに移管する」というような目標を立てる事もできます。このような例は現状を元に分析するとなかなか上がってこなかったりするので、TO-BEから先に洗い出しするメリットの一つと言えます。

:::note info
TO-BE
- システムのオペレーション業務をすべて自動化する
- サーバをすべてクラウドに移管する
:::

TO-BEの洗い出しができたら、**TO-BEと対比する形**で現状をAS−ISとして記載します。TO-BEとして記載した内容を元に、それが**現状どの様になっているか**を洗い出します。

具体的には、以下のような例が考えられます。

:::note info
AS-IS
- 手動のオペレーション業務が一日あたり2時間程度発生している
- サーバはすべて自社のデータセンターに配置されている
:::

## 2.3 ギャップを課題として洗い出す
### 課題の洗い出し
AS-ISとTO-BEが洗い出しできたら、次にその間にある**ギャップ**を**課題**として洗い出します。つまり、AS-ISからTO-BEへ移行することにあたり、**障壁となっているもの**を洗い出します。

例えば、AS-ISが「バグの発生件数は年間100件」、TO-BEが「バグの発生件数を年間10件以内に抑える」であった場合、発生しているバグの傾向などを分析したり、実際の開発エンジニアにヒアリングするなどして、障害が発生している要因となっているものを洗い出し、**課題として定義**します。

具体的には、以下のような課題が考えられます。

:::note info
課題
- 外部システムへのデータ連携でバグが多発している
- バグ対応により新たなバグを埋め込んでいるケースが多い
- 現状のシステムが複雑であり、修正の難易度が高い
:::

### 仮設と検証
課題の洗い出しには、**仮設と検証を繰り返す**プロセスが必要になります。

AS-ISからTO-BEを実現するために「これが必要なのではないか」と言う仮設を立てます。仮設を立てるには以下のような方法が考えられます。

- **インプットとなる情報**から分析する
- 関係者に**ヒアリング**を行う
- **フレームワーク**を活用する
- **類似の事例**を参考にする

仮設を立てたら、それが妥当かどうか**検証**します。具体的には、**複数の要素**を元に仮設が当てはまるかを分析したり、**シミュレーション**をしてみたり、**第三者のレビュー**を受けたり、といった方法が考えられます。

仮設が間違っている部分があれば見直したり、別の仮設を立てたりして、**仮設と検証を繰り返して**いきます。そうしていく中で、今回のTO-BEの実現に必要となる課題を洗い出していきます。

## 2.4 課題を対応するためのアクションプランを立てる
### アクションプランを立てる
洗い出した課題に対して、解決するための**アクションプラン**を立てます。アクションプランを立ててそれを解決することで、TO-BEで設定した理想像を達成できると言う考えです。

先程のバグ発生件数の例で洗い出した課題に対して、アクションプランを立ててみた例が以下になります。

:::note info
外部システムへのデータ連携でバグが多発している
- 外部とのデータ連携部分について強化テストを行う

バグ対応により新たなバグを埋め込んでいるケースが多い
- バグ対応後に回帰テストを行う

現状のシステムが複雑であり、修正の難易度が高い
- リファクタリングによりコードを簡略化する
- 利用していない機能を停止する
:::

### 優先度を決める
アクションプランをいくつか提示した後は、それに対して**優先度**を決めます。すべてのアクションプランを最優先で対応できればそれに越したことはないのですが、予算やコスト、人員等の都合で難しいことが多いです。そのため、優先度をつけて**対応の順番**を決めたり、場合によっては**対応自体を見送ったり**といった判断をします。

優先度の決め方については様々なやり方がありますが、そのアクションプランの実行にかかるコストと、実行した際の効果を比較した上で、コストに対しての効果が高いものから優先に対応するやり方があります。

# まとめ
**AS-IS/TO-BE分析**の方法をご紹介しました。AS-IS/TO-BE分析を行うことで、**抽象的な目標**に対する**課題**や**アクションプラン**を計画することがしやすくなります。

もしご興味持っていただけたら、今後の課題分析や提案活動などでご活用いただけたら幸いです。

最後までご覧いただきありがとうございます。