コンサル的思考実験と読書メモブログ

ITコンサルタントが身を持って学んだこと、フレームワークの使い方、書評などを挙げていきます。IT企業や企業内IT部門の管理者やリーダ層の方、ITコンサルタントを目指す方に参考になる情報発信できればと思います。

コンサルタントの仕事術〜アウトラインを描く〜

こんばんは。atomです。

 

今回は作業の進め方についてです。

 

コンサルティングの提供方式にもよりますが、私は案件掛け持ちで実施するので、一つの事に集中しきれる状況には無いです。

 

物理的に工数か足りなくなるというよりも、色んな事を並行で考える為、脳内のメモリが不足するという実感に襲われます。

 

特に設計作業。

 

提案内容や対策方法、計画の作成、合意形成までのシナリオ作成などは非常に頭を使う作業で、私は設計作業と位置づけています。設計作業は時間があっても進まない事もあれば、スラスラと出てくる時もあります。

 

特に未経験の課題に対する設計は目処が読めないので、納期まで終わらないリスクを減らす為、早く着手するようにして、アウトラインを描く事に最大限注力します。ここでは、マルチタスクというよりは、シングルタスクで一つ一つを最速で終わらす事にしています。

 

アウトラインが描ければ、あとはピースをはめていくだけ、説明資料に落とすだけなので、目処がつく領域になります。

 

目処がつけば見積もりができるので、自分もしくは、協力者のリソースを分配することで、対応がとれます。

 

アウトラインが描けない時は、作業場所を変えて一旦離れる、情報のインプットを増やす事で滞留を防ぐようにしています。

 

自分なりの脳内のメモリ解放にあたる行為なのかもしれません。

 

ここにコンサルタントとしての生産性の差が出る気がします。

 

普段本を絶えず読んでいるのも、知識を得るというのもありますが、この滞留が「怖い」からかもしれません。

 

ちなみにアウトラインをうまく描けず進める仕事は大体クライアントと話をしても進まない事が多いです。

 

取り敢えず着手して、うまくアウトラインが描けそうか確認するのはよいですが、アウトラインを描けないまま、がっつり作業するのは手戻りになるので絶対にやめた方がいいです。

 

別の機会に実際にアウトラインとはどういったものを作っているかなんかもお話できればと思います。

 

ではでは。