ゆるふわコンサルタントの日常

設計エンジニアから業務コンサルタントに転職、その経験談や仕事術を綴ります。

仕事の流れ１：構想企画

仕事内容

どうも、業務コンサルタントのT（@T14764）です。

前回は業務コンサルタントの仕事概要について紹介しました。

 

t14764.hatenablog.com

 

ここでは一応、製造業の業務コンサルタントという注記付きでの仕事内容としてご紹介しましたが、どの業界専門であれ、基本的な業務内容はあまり変わりません。必要な専門知識が違うだけです。 

ですので、本記事以降でご紹介する仕事の流れについては、業務コンサルタント共通の内容と思っていただいて結構です。

それでは今回は、以下Twitterで呟いた内容を、もう少し詳細に記載していきます。

 

目次

 

基本的な仕事の流れ

一般的に僕らが使っている以下のフェーズ（プロジェクトの一区切り）名で区切って解説していきます。

 

  1. 構想企画

  2. 業務モデリング

  3. システム要件定義

 

まずは「1. 構想企画」についてです。長くなりそうなので、今回以降、フェーズごとに3回に分けてご説明します。

 

 

コンサルタントの役割

仕事の流れをご説明する前に、大事なことをご説明していませんでした。そもそも、コンサルタントの役割って何なのでしょうか？どんなイメージがありますか？恐らく、以下のようなものではないでしょうか。

 

  • 問題解決をする人
  • 相談を受けて、こうしましょうとアドバイスする人
  • 頭が良くてスマートに仕事をし、お客さんとあれこれ議論し結論を出す人

 

どれも正しいようでいて、実は正しくないです。なぜなら、コンサルタントは、「お客さんの意思決定を支援する」役割だからです。

上記イメージは、全てコンサルタント自らが何かを決める役割です。ですが、実際にはそうではなく、またお客さんも、それを求めていません。お客さんは、コンサルタントに何かを決めてもらいたい訳ではなく、自分達が何かを決めるサポートをしてほしいと思っているのです。

 

 

 仕事の流れ１：構想企画フェーズ

コンサルタントの役割を分かっていただいた上で、ようやく本題、実際に「構想企画」フェーズでどんなことをやるのかをご説明していきます。

「構想企画」とは、コンサルの仕事において、一番初めのフェーズになります。「構想企画」が始まるきっかけは、以下のようなイメージです。

お客さん企業内で色々と検討し、こんな目的でこんな問題を解決したい、将来こんなことをやりたい、という漠然としたイメージを描いたものの、これまでにやった経験が無く、それが正しいのか、本当に問題を解決できるのか分からない。また、社内をどう巻き込み、どう進めて行けば良いか分からない。

つまりは、自分たちで色々考えてきたことを、その道に詳しい専門家のお墨付きをもらって、社内を納得させたい、というような経緯で呼ばれる場合。意外にも、これが一般的なきっかけです。

もしくは、ここまで出来ていたら良い方で、表面的には色々な問題があるけど、背景にある問題が複雑過ぎて、根本的に何が原因でその問題が起こっているのかよく分からない、もしくは問題は分かっているけど、どう解決すれば良いか分からない。問題は漠然と分かっているけど、複雑過ぎて自分達では到底解決できないお手上げ状態、これはその道のプロにお願いして助けてもらうしかない、というケース。これが次によくあるきっかけです。

このように2つのケースがあることを、まずは知っていただければと思います。

そして、「構想企画」フェーズというのは、この2ついずれの場合にも、同様のコンサルサービスを提供します。

一般的な流れは以下です。

  1. 現状の分析
  2. 課題解決策の検討
  3. 解決による効果の試算
  4. 今後の実行計画立案

現状の業務課題とその原因を分析し、それを解決できる業務プロセスを検討し、それによる経営上の効果を試算し、今後どうやって解決に向けて進めていくかの計画を立案する。この流れは自然というか、すっと入ってくるのではないかと思います。

ここで僕が言いたかったことは、この流れの中身そのものではなく、なぜこのような流れで進めるのか、です。これはつまり、お客さんの状態がどのようなものであるにせよ、コンサルタント自身が自分達の目で見て、手を動かして、真の問題や原因を探り、本当に効果のある解決策の案を出しますよ、ということです。この考え方は、業務コンサルタントに限らず、コンサルタントの基本的な行動原理になっています。

自分の考えを述べる場合や、何かの提言をする資料を確認してもらった際、よくベテランのコンサルタントから、「それ事実？」「その根拠は？」と聞かれます。

この発言の裏には、誰かがそう言っていたから、とか、私はそう思います、とかではなく、誰が見てもそれが正しいと言える事実を元に、何かを考えなさい、あるいは提言しなさい、という考えがあるのです。かっこ良く英語でいうと、"Get the Fact"なんていうフレーズで行動原理として説明されていたりします。

お客さんがどんな状態であれ、まずはコンサルタント自ら事実を確認した上で、問題解決を支援する、それがこのフェーズで大事なことです。

そして、コンサルタントをしていて良かったなと思うのは、このフェーズの流れは、何も仕事に限らず、プライベートにも適用できる、ということです。

奥さんが、彼女が、なぜ怒っているのか？を過去の自分の行動を振り返って確認し（現状分析）、次はその行動を取らないようにすれば（解決策の検討）、奥さん、もしくは彼女が怒ることも少なくなるだろう（効果の試算）、よし、明日からそうやって行動していこう（今後の実行計画立案）、というように。

公私ともに、更には人生に渡ってその考え方が役立つ。コンサルタントは、そんな素晴らしい経験ができる仕事です。経験して損は無い仕事でしょう。

 

というわけで、今回はここまでです。

読んでいただき、ありがとうございました。

 

次回は、「2. 業務モデリング」について、解説します。