【知識編】コンサルに入って最初に苦しんだこと

【知識編】コンサルに入って最初に苦しんだこと

こんにちは、kinacondaです。

これまで何度かコンサル業界について話してきました。

やはり、コンサル転職を考えている方にとって、転職後についていけるのか、というのが一番の不安かと思います。

それを踏まえ、今回は、僕が転職後に一番困ったことについてお話していきます。

 

 

全てのコンサルにとってシステムの基本知識は必須

 

営業職から転職してきた僕にとって、最も頭を悩ませたのはシステム知識でした。

ただでさえOfficeソフトさえろくに扱えなかった中で、いきなり「要件定義」のプロジェクトにアサインされたときは、もう完全にちんぷんかんぷんの状態でしたね。

自分が何の作業を何の目的でやっているかもわからない、といった感じで、当然ながら日々の打ち合わせ内容も全くついていけませんでした。

ただ、はっきり言うと、「コンサル」である以上、最低限のシステム知識は不可欠です。

それは戦略コンサルだろうがビジネスコンサルだろうが関係ありません。

なぜなら、みなさんが一見システムが絡まなそうに思うフロント向きのプロジェクトでも、結局システム導入が解決策になることが大半だからです。

例えば以下のような形ですね。

  • マーケティング改革⇒アナリティクスツールや最先端の顧客管理システム導入
  • 働き方改革⇒手作業の業務をシステム化

 

ということで、最低限の知識を効率的にインプットできる書籍を紹介していきます。

以下の二冊を通じて、普段飛び交う言語や仕組みの理解はもちろんのこと、システム案件で特に気をつけるべきことが何かも知ることができるでしょう。

 

①プログラミングについて知る

まずここで紹介するのは、プログラミング言語について細かく学ぶ専門書ではありません。

どれだけ我々の日常にプログラミング技術が密接し、我々の生活基盤が成り立っているかが学べる一冊です。

そして全体を通しては、プログラミングにおける問題を細分化していく思考が、あらゆるビジネスにも通ずるという趣旨になっています。

確かに、システムというのは、たった一つのコーディングのミスやフローの順番が違うだけでバグを起こしてしまうので、できるだけ細かく分解して検証するのが必要不可欠です。

それは業務効率化や業務刷新案件でよくあるBPR(ビジネスプロセスエンジニアリング)においても必須のスキルになります。

BPRでは、まず現在の業務全体のフローを可視化し、どこに無駄があるかを特定していく、という作業を最初に実施するからです。

 

改めてこの本通じて僕が学んだことを整理すると、以下三点に集約されます。

  • 各プログラミング言語がそれぞれ何を作るために使われるかがわかる
  • システムの全体像がわかり、日々の業務におけるエンジニアサイドとのコミュニケーションが円滑になる
  • コンサル案件の大半を占める業務効率化の具体的な進め方イメージがもてる

特にコンサルに入って間もない頃は、実際にフローチャートを散々書かされたので、そのチャートの目的と、作成する上での考え方を知れたのは大きかったですね。

僕個人としては、コンサル転職前に手に取っておけば良かったと感じた一冊です。

 

 

②システム開発について知る

次は、コンサルであれば必ず関わるであろうシステム開発について書かれた本です。

まず、日本のシステム開発の何割が炎上しているか知っていますか?

実は80%以上です。

その中でも最も難しく、且つもめる部分というのが、要件定義だと言われていて、本書はなぜ要件定義が炎上の最大要因になってしまうかについて語っています。

経験者の僕から言わせると、正に書いてある通りといった感じで恐かったです(笑)

本書でも記されていますが、だいたいもめる理由というのは決まっていて、多くは以下の二つです。

  • そもそもシステム導入の目的がはっきりしていない(なんとなく凄いと聞いたから、競合も導入してるから、というケースが多い)
  • 部門間で求めることがバラバラで、途中で「あれいる」「これいらない」の議論が噴出する

ま、だからこそ外部の人間に諸々を整理してもらおうということでコンサルが呼ばれるわけですが、

特にこの本を通じて、コンサルがシステム開発現場で何により注力すべきかがわかるでしょう。

それは基本的に以下二つだと思っていただいて大丈夫です。

  • 部署間の利害調整と進捗管理
  • 組織の全体最適を考えた要件の絞り込み(そのための市場調査やビジネスケース作成)

 

特に部署間の利害調整は、ビジネスコンサルにとっては全てと言っても過言ではありません。

僕も経験していますが、本当に各部署でやりたいこと、言っていることがバラバラなので、その妥協点を見つけるのに最も時間を要します。

最悪のケースでは、そもそも「そんなシステムいらん」派と導入肯定派の対立が起き、収拾がつかなくなることも。。

基本的にはヒアリングやディスカッションが肝になるのですが、誰の意見を取り入れ、また除外するかがコンサルの腕の見せ所になってきます。

どちらかというとコンサルを採用する企業側の目線で書かれていますが、そこで同時にコンサルへの期待値も理解できるはずなので、ぜひこの本でシステム案件での心構えを身につけておきましょう。

 

 

まとめ

 

以上、システム知識の重要性について語ってきました。

これだけITが根付いてる現状を踏まえると、コンサル云々関係なく、最低限のシステム理解はマストだと思います。

実際にプログラミングができるに越したことはないですが、ひとまず仕組みを知っておくだけでコンサルトとしてはやっていけるでしょう。

今回これを読んでいただいて、経験する前にご紹介した書籍に出会えてラッキーだったと思っていただけたら嬉しいです。

 

ではまた。

コンサルカテゴリの最新記事