はじめに
「半年後に納期が設定された新機能実装プロジェクト、何から手をつけたらいいかわからん...」
「未経験でプログラマー転職したいけど、どうしたらいいかな？」
そんな時には、As-Is/To-Beで目標と解決策を明確にしてみてはいかがでしょうか？
対象者
この記事は下記のような人を対象にしています。
- 駆け出しエンジニア
- プログラミング初学者
- 目標とか、計画とか苦手な人
結論
As-Is/To-Beを使うと課題とやることが明確になります！
(※短期で成果を出す活動の場合は、機能しない場合あり)
As-Is/To-Beとは？
As-Is/To-Beとは、現状を分析し、理想の状態とのギャップ(課題)をあぶり出し、アクション(解決策)を決めるためのビジネスフレームワークです。
横軸に時間を設定しているため、強制的に納期・締め切りが意識できる点が特徴です。
As-Is/To-Beは3つのステップで進めていきます。
それでは、個別に詳しく解説していきます！
STEP1 As-Is
最初のステップはAs-Is(現状分析)です。
まずは現状がどうなっているのか、できるだけ詳しく買い出してみましょう。
本記事では「35歳でプログラマー転職するとき」をケーススタディとして、単純化した例を挙げます。
As-Is(現状分析)に使えるフレームワーク
「いきなり現状分析しろ、って言われても無理！」というあなたのために、現状分析に活用できるフレームワークをご紹介。
ロジックツリーの中でも、Whatツリーは現状分析に活用できます。
また、もう少し深く分析したい場合は、Whatツリーを活用して原因分析までやると、後で解決策を出す時に役立ちます。
業務のプロセスを見える化するのにIPOやSIPOCが役立ちます。
どの部分がボトルネックになっているのか、明確にしましょう。
SWOT分析は現状分析に活用できます。
そのまま、解決策を出すクロスSWOTも活用できるとより効率的なのでおすすめです。
STEP2 To-Be
現状分析の次のステップは「目標(理想)を設定する」です。
ここは理想で良いので、がんがん妄想して、書いてみましょう。
その後、現実的なラインはどこか判断して設定すると良いでしょう。
「35歳のプログラマー転職」の例は下記の通り。
To-Be(目標設定)に使えるフレームワーク
目標設定に活用できるフレームワークもご紹介しておきます。
SMARTは目標設定に有用です。
目標を明確に指定できると、この後のギャップが明確になります。
STEP3 ギャップ(課題)とアクション(解決策)
最後のステップは課題と解決策の作成です。
To-Be(理想の状態)からAs-Is(現状)を引き算した時の差分がギャップ(課題)です。
この時に大事なのが、時間軸も一緒に考えるということです。
As-Is/To-Beのダイアグラムは横軸が時間になっています。
「いつまでにやるのか」「どれくらいの時間がかかりそうか」ということを常に考慮しましょう。
ギャップとアクションに使えるフレームワーク
「解決策のアイデアなんて、そんな簡単に出ないよ...」というあなたのために、アイデア発想のフレームワークをご紹介。
現状分析にも活用したロジックツリーですが、解決策出しにも使えます。
解決策を出す場合は、Howツリーを活用しましょう。
現状部門に活用したSWOTですが、解決策を出す際にはクロスSWOTを活用しましょう。
上記のフレームワークで、解決策が大量に出たはず。
すべての解決策に着手することはできません。
「やるべきか、やめるべきか」を決定するにはプロコンを活用しましょう。
上記のフレームワークでやるべき解決策がリスト化されました。
とはいえ、すべて同時に着手することは不可能です。
優先順位をつけるにはペイオフマトリクスを活用しましょう。
As-Is/To-Beは古い？
非常に有効なフレームワークですが、一方でAs-Is/To-Beは古いという評価も聞きますが、実際どうなんでしょうか？
私の認識だと、古くて使えない、というよりは向き不向きがあるという感じだと思います。
プログラマならPDCAよりOODAなのか？でも解説しましたが、As-Is/To-Beも「分析や計画立案に時間がかかる」というデメリットがあります。
そのため、下記のような状況には不向きです。
As-Is/To-Beに不向き
- 今日中に提出しなければいけない
- 明日には状況が変化するかも...
逆に、中長期の視点が必要な下記のようなプロジェクトではAs-Is/To-Beが大活躍できるので、おすすめです。
As-Is/To-Be向き
- 転職の計画を立てたい
- 3ヶ月後が納期の機能追加のTODOリストを作りたい
おわりに
As-Is/To-Beについてまとめました。
参考記事
問題解決の最初の一歩 As-Is/To-Beで現状の問題を可視化する
As-Is/To-Beはもはや限界、“DXの見取り図”からデジタル基盤を築けるか