超上流工程とは？（後編）　必要となる能力や知識

---

---

唐突ですが、LTSではITコンサルタントとして超上流フェーズをやりたい！というIT業界経験者を積極的に募集しています。このコラムを読んで興味を持って頂けたら、是非こちらから応募してみてください。

---

ライター

必須の能力は、仮説を作って検証する力

企業のITに関する課題を整理・可視化し、社内の関係者が納得できる「あるべき姿」への道筋を見出すのが、IT超上流を担うコンサルタントに求められる成果です。そのために必要となる能力や知識、経験はどんなものでしょうか？

まずは「最も必要となる能力」について、LTSで超上流案件を担当するベテランのITコンサルタントに聞いてみたところ、返ってきた回答は「仮説を作って検証する力」でした。他の能力や知識は後から身に付けてもOK（スタート時点では最悪無くてもよい）ですが、この最重要な「仮説検証する力」は素養として身に付けておいてほしい能力だそうです。

仮説検証はコンサルタントという職種では案件問わず必須の能力になりますが、他のビジネスパーソンでも大小の差はあれ必要な力だと思います。普段の仕事のなかでも「今起きている問題の原因は〇〇ではないだろうか。試しに〇〇を止めてどうなるか検証しよう」という気付きを元にやり方を変えて作業をしてみて改善するか試すという方法は、おそらく多くの人が実践しているでしょう。では、超上流フェーズで必要な「仮説を作って検証する力」とは具体的にはどのようなものでしょうか。

課題に対して「仮説設定・検証・対策の選択」をどれだけ早く実行できるか？

1回目のコラムで、超上流フェーズで最初に行う「課題の明確化や現状分析など議論できる土台を作る」までが平均2～3ヵ月と説明しました。この工程は顧客からすると議論のスタートを待っている時間ですので、短いに越したことはありません。

しかし、「ITの課題を正確に把握し議論に必要な情報を集める」という目的のために必要な作業を真っ当に進めると、やるべきことが膨大になります。現行業務やシステム全ての利用状況、関係する社員全員へのヒアリング、それら集めた情報の詳細な分析…など、超上流の最初の工程だけで1年過ぎてしまうかもしれません。

そんな状況を避けて短期間で議論ができる状態に持って行くための「仮説検証ベース」の進め方が、以下の3ステップです。

1．初期のヒアリングや分析から、どのような問題が潜在しているのか仮説を立てる
2．ヒアリングや業務・システムの分析で現状把握をしつつ仮説を検証・修正する
3．業務やシステムの調査で仮説を裏付けて有効な解決手段を検討・選択し提示する

「調査したところ貴社の課題はここで解決に効果のある手段や活用可能なソリューションはこれです」という回答を短期間で返すには「最初から一定の仮説を持って動く」「仮説検証と現状把握を並行して行い仮説の精度を上げる」「裏付けた仮説に対して有効なソリューション・手法を提示する」ことができる力が必要だということです。

よくある課題と解決事例、代表的な課題解決手法／ソリューションを知っていると強い

仮説を立てられるということは、ヒアリングした断片的な情報から課題の本質と発生要因を導き出せるということです。多くの事例を知り背景も理解しており、その知識を集約し類推することで仮説を組み立てます。あとは、その仮説を事実ベースで検証し、対応する解決策・ソリューション（この場合は特定のシステムやツールの活用・組み合わせパターンなど解決手段）のパターンを提示して、議論すべき題材と論点を示します。

これらの元になる情報を知っていて、かつ課題と解決手法の組み合わせ提示をできる活用能力があれば、超上流の最も重要なフェーズを乗り越えることができそうです。

ITベンダーが提案できる状態まで落とす力

1回目のコラムで「超上流でやること」を説明していますが、実際はさらにその先にもやることがあります。それが、スコープを決めた最初のプロジェクトについてITベンダーに提案を依頼することです。これが、超上流のコンサルタントにとって重要な2つ目の能力です。

落としどころに落とす

IT企画・構想策定をする超上流フェーズでの最終的なアウトプットは、最初に実施するプロジェクトのスコープや予算・採用するシステムと発注先ベンダーを決めること、もしくは顧客企業のIT基盤について中長期の計画となるIT中期計画を作ること、のいずれかです。

今回のコラムは前者を中心に説明をしています。けっきょくのところ、超上流フェーズのコンサルティングを依頼した顧客企業としては最初のプロジェクトのキックオフまでたどり着かないとあまり意味がない訳です。ですので、ここを支援するコンサルタント側としてもなんとかしてプロジェクトが開始できる状態まで持っていきたいという思いがあります。

1回目のコラムで「最初のプロジェクトのスコープを定める」という話をしていますが、これは顧客企業のITの課題解決をすることが目的であると同時に、プロジェクトに参画してもらうITベンダーが受けられる範囲のスコープや条件に落とし込むという話でもあります。顧客の課題と要望を上手く切り分けて優先順位付けしてスコープを切るということを、同時に「このスコープなら、やや高額だがA社のパッケージシステムか、もしくはB社のシステムと機能的な不足分は別のツールを組み合わせれば対応できそうだ。予算的にもなんとかいけるだろう」という発注検討先を見据えつつ落としどころを探るのが、現実的なプロジェクト化の支援に向けてコンサルタント側に必要となる能力です。

知識として知っておいたほうがよいこと

あとは簡単に超上流のITコンサルタントに必要な知識について書いておきます。

超上流フェーズで検討する企業のIT企画構想の先にある最初のプロジェクトは、多くの場合「基幹システムの刷新」になります。そのため基本的な会計周りの知識は必要です。また、データベースや業務システムの基本的な知識・構造理解も必要です。データ構造から業務が想像できる、また逆に業務側で必要としているデータの構造を想定できないと、スピード感を持って現状業務やあるべきシステム像を把握できないからです。

これらはIT業界で特にバックオフィス系のエンジニアには必須のスキルと思いますので、個々人の経験による差はあると思いますが、基礎的な知識は身に付けている人が多いのではないかと思います。

また、各種のERPなどパッケージシステムについて幅広く知っていると、前述した「ITベンダーが提案できるまで落とす」の判断がしやすくなると思います。

超上流プロジェクトで未経験者が担える役割

色々と必要な能力や知識について書きましたが、実際LTSがこの領域のコンサルティングをする場合、顧客へのヒアリングやその調整、議事録作成、またITベンダーとのやりとりなど、細かい管理系の業務も多いため、新卒社員も必要戦力として活躍しつつ経験を積んでいます。

実際に、様々なバックグラウンドを持つメンバーがコンサルタントとして活躍していますので、未経験の方もこの領域の経験者も是非足を踏み入れてもらいたいです。

---

終わりに

このコラムを書いたのは、IT企画構想のフェーズについて実際の事例やコンサルティング支援の中身を知りたい、と思ったことがきっかけでした。

私は小さなソフトハウスのエンジニアとして十数年前に社会人生活をスタートしました。2度目のキャリアチェンジを経てLTSでコンサルタントの立場となりITの世界に身を置き続けています。

超上流のような情報システムの設計前フェーズを知ったのはコンサルタントになった後でした。コンサルタントとしての自分の専門は新システムや新業務を現場ユーザーに展開し定着させる超下流のフェーズだったため、超上流を担当する機会がなかったという理由もあります。私にとって超上流でやることは「自社にとってあるべきITシステムを検討する≒IT中期計画を作る」という程度の曖昧な認識であり、同時に「あるべきITの検討といっても実態はシステム刷新プロジェクト。最後は現行システムをベースに入れ替えをすることに落ち着くのではないか？」と思っていました。もともと自分のキャリアのスタートが開発側のエンジニアだったので、システムありきの考え方をしていたと思いますが、これは同時に多くのエンジニアが感じている疑問なのではないか？と考えています。この疑問を解くために、超上流案件を解説するコラムを書くことにしました。

実際コラムにまとめてみて感じたのは、企業のIT基盤・ITアーキテクチャの在り方を考えるフェーズはやはり本来はその企業内でしっかり考えて進めるべきものだということです。しかし、コラム内で説明もしていますが、この領域を検討する難易度や専門性が非常に高くなっており、専門家なしで検討するのが困難な実態があるため、あるべきIT構想の検討と意思決定をするプロセスの社内での推進を専門家として支援することが、この領域のコンサルティングサービスなのだと理解ができました。

ヒアリングに協力頂いたLTSのコンサルタントの皆さん、ありがとうございました。

ここまで読んでいただいた皆様、ありがとうございます。また次の記事でお会いできると嬉しいです。