業務コンサルの仕事の始まり
CS Harmony Radioの番外編を始めていきたいと思います。
よろしくお願いします。
よろしくお願いします。
前回まで若干、こう難しい系をやってたので、今回ですね、ライフハック系というか、仕事の仕方みたいなところのお話できたらいいかなと思ってます。
私自身がコンサルティングをしているので、ちょっとコンサルの仕事からお話をさせてもらいたいなと思ってます。
基本、業務コンサルやってます。このラジオの中でもお話してますけど、プレップモデルという業務プロセスを書いたりとかもしてますし、それ以外のやり方も含めていろんな手法を使いつつやってたりするんですけど、
もともと研究者ではあって、側面的には。
そうですよね。
そうなんですよ。肩書き的には研究をやってる人なんですけど、業務的にコンサルティングをしてるっていうのが不思議なことではなってるんですけど。
なので、研究されている手法とかそういったものを実際の業務で使ってより良くしていくっていうのが主なお仕事で、
どちらかというとその適用する方、コンサルティングする方が動きが多くなってきてコンサルティングをやってるっていうのが経緯的にはあるんですけど。
研究でもコンサルでも一緒なんですけど、だいたい仕事の仕方ですると、ちょっともしかすると一般的な業務とちょっと違うかもしれないのは、
業務のプロセスと改善策の提案
まず組織の問題とか業務そのものの問題の分析みたいなところをやるっていうところがまず最初に入ってきます。
問題を分析して、問題の分析の仕方は業務のプロセスを書いてそこから見つけるっていうパターンと、
あとはお客さんとワークショップみたいなところで困ってることとか起こってる問題点みたいなのを整理して問題構造を作ったりとか、
フレームワークで整理してここはこうですよねみたいなのも含めて取り組むべき対象みたいなものを絞り込んでいくというようなところから入って、
その後にそれに対してどういう改善策が必要かと。この改善策のところで研究者っぽいところが出てくるのは、
新しい技術が世の中こういう技術があってとか、自分たちが知っている手法とかっていうのを適用した上で、
私の場合はTOCっていう制約理論っていうものの専門家でもあるので、そちらの中のソリューションみたいなのがあるので、
そういったものをこうだとこうやってやるとうまくいってますよみたいなのを提案した上で組み立てていくというような感じですね。
手法だけだと動かないので、結果的に業務を組み立てて、Azureの業務を聞きしてたりするので、
新しい手法を入れた後どういうプロセスなのかというところを業務設計して、かつAzure SQL 2Bにはどうやっていくのかっていう実行計画みたいなところ。
そこまでお手伝いできるかわからないんですけど、お客さんになっちゃうのでわからないですけど、そこまでやる場合はやっていくというような感じですね。
なるほど。兆材があって、それを導入支援するとかっていう話じゃなくて、まず困りごとを特定して、その困りごとを解決してサポートするっていう。
そうですね。
コンサルティングってそういう仕事だとは思うんですけど、聞いていいですか。
はい、どうぞ。
兆材あったりとか扱うものが決まってると、それについて覚えたりとかトレーニングってできると思うんですけど、
ヤギさんみたいな仕事って困ってる話って、事前に聞いてある程度は予測できるにしても、実体細かいところまでわかるのって現場に行って初めて知るみたいなことが多いじゃないですか。
はい、そうですね。
そういうところって普通の職種とは違う特徴的なところかなと思うんですけど、どうやってトレーニングしてたりするのかっていうのが気になっていて。
それって本編とかでもちょっと話したんですけど、シミュレーションしてるってことになるんですかね。
そこは一つあるのと、本編に絡みますけど、カタカみたいなのは意識はします。
パターンあるんですね。
はい。
困り事もだいたい枠でこんな風になるよねみたいな。
例で言うとあれなんですけど、もともとソフトウェアの開発するところを専門でやったんですけど、あるときに対象を製造業、しかも生産計画とかそういうところに移ったことがあるんですよ。
はい。
もともとソフトウェア開発の中だと問題ってだいたいわかってるなってなってたので、別にどんな現場に行っても聞いたことあるわみたいな話にはなったんですけど。
新しくそういった分野に入ったときは、最初はもうやるしかないので、まず1個ずつこなしていくっていうところから入ったんですけど。
2年ぐらい経つと、ある程度どんなんでもいけるっていうのがなりました。
今だから多分製造業のところに行って、自分の知らないような原因で発生してるものってほぼないかなと思って。
今の話って業界知識みたいなところは足りてないとちょっとしんどいけど、ある程度キャッチアップしていくと、どんな問題でも対応できるようになってきますっていう。
そういう意味で問題が何だろうかっていうのがよくわからないので困ることはほとんどないかなと思います。
そしたら困ることはもうないんじゃないですか?
その時点では困らないですけど、あとはどういうふうに2B側に向かわせるとか、2Bを描くときにいいとこの落としどころ。
2Bって言っても例えば5年後なのか10年後なのか直近なのかで変わってくる。
どの辺に折り合いつけますかっていうのと、どこ目指したいですかみたいな話のところの調整が基本。
Azureで起こっていることは正直そんなに新しいことはあんまなくて。
問題見えてるし解決策とか大体わかるんだけど、じゃあ実際どうやったらそれをここに向かっていって進んでもらえるかっていうところに導く部分が難しいって感じですか?
そこがコンサルティングとしての腕の一番大事なところじゃないですか。
その話だけ聞くと本当カスタマーサクセスみたいな仕事ですね。
言い方はあれなんですけど、速度感を2つ持ってて、問題分析と解決策立案までは超高速にやれるんですけど、その後クライアント側がついてくるのに待たなきゃいけなくて。
そこはすごく時間かけて丁寧にやるっていう速度感を持ってて。
これどっかで言いましたけど、最終的には空気になるべきで、実装してもらわないといけないんで、そういう最終ゴールにはなるんですけど、だからすごいカスタマーサクセスに似てるというか、やり方に近いんじゃないか。
本編でも話してましたけど、コンサルとカスタマーサクセスかなり領域近いところで、本当に前半はコンサルティング業で、後半になるとコンサルタントという肩書きだが、カスタマーサクセスのような動きしてるっていう感じですね、今のお話だと。
やはり成り立てでコンサルやってたときは、大体3年ぐらいやるんですよね、同じお客さん。
初年度ぐらいにほとんど問題もわかるし、解決策の方も自分の中ではわかってて、小出しにするわけじゃないんですけど、お客さん側でそれが噛み砕ける状態で、かつ組織として動ける体制になるのは大体1年とかかかるんで。
待ってて、2年目ぐらいから実際それやり始めます。3年目になると、私ほとんどいらなくなるんですよね。
ここまで来ると仕事的に楽なんで、何もしなくても大体大丈夫。ただ監視してなきゃいけないのは、アイロ事故というか、変なことになったときに補正してあげるとかいう仕事がいるので、そういう関わり方になってきていて。
そうなってくると、次の案件みたいなのが見えてくるんですよ。そのための準備とか仕込みとかをその時期にするみたいな感じに。
それはなんかコンサルタントの業界構造の佐賀っぽい動きしてますね。
こんだけいろいろやってくると、大体パラで持たされてくるんで。
多重度みたいな話ですね。
そうですね。仕事術みたいな話になりますけど、基本マルチタスクは私苦手なんで、なるべくシングルにしようとします。
単案件とかぐらいはやってたりするんですけど、パラで。
基本的には、頭の中に全部抱えると死んじゃうんで、まずやらなきゃいけないことは全部頭から出す。
いわゆるタスクボードって言われる。To DoとDoingとDoneみたいな。
作業を終わって、そこに何が今残ってて、今終わって何が終わってて、今どれが仕掛かってるのかみたいなやつがありますけど。
そういうのをアナログでもいいですし、今だとマイクロソフトのプランナーとかトレロとか。
そういったものを使って、タスク全部出して、今どれが仕掛かってて、何が残ってて、みたいな感じのことをやって。
これも手をつけると大体全部死んじゃうんで、今はこれ手をつけないっていうふうに決めて。
優先度の中に一つはやはりノーキーっていうのがあるんで、それも含めて優先度を決めて。
細切れにやるんじゃなくて、一個ずつやっていくっていうのは意識してやってますね。
たぶん切る量っていうか流度。そこ結構コツがあるような気もするんですけど。
あると思いますよ。
どれぐらいの単位でやってらっしゃるんですか?
単位はできれば2時間。
時間で見てるんですね。だいたい2時間ぐらいの作業でやるとここまでは行きたいみたいな、そういう切り方なんですね。
この辺実はタスクボード使った改善とかもコンサルしてたこともあって、それぐらいがいいよって。
個人的には難しいなと思ってて、僕も一つのことしかできないんで、他のことって出したいんですよ。
同じようにタスクボードとかToDoとかに書いといて、一旦忘れてやることだけできるようにするんですけど、
その時って区切りってこれ作るとかこれ完成させるみたいな感じになっちゃうんで、時間が結構読めないというか。
もちろん打ち合わせとか次決まってってなると強制的にシャットダウンみたいな状態になっちゃうじゃないですか。
でもそういうのがない時間だと、例えば2時間で終わらせたいと思っても3時間かかったりってなって、うーんってなる時が結構あるんですけど。
その辺って何か工夫とかされたりとか、こうやるといいとかありますか?
たぶん経験値って見積もりとの差なんだと思うんですよ、それ。
見積もり制度って結構難しい部分がありますよね。見積もりやすい作業と見積もりにくい作業ももちろんある。
今ちょっとできてないんで正直これがいいですよって言いづらいんですけど、これ自分ができてないんで。
ただちょっとコンサルモードで言うと、少なくとも見積もりを出しますっていうところと、
実体どれぐらいかかりましたかっていうのを記録するとその差が出てきます。
そうなるとこういう仕事はこれぐらいだっていう、ある意味その作業量とか自分の能力値みたいなのが数値化されるじゃないですか。
今度見積もるときはそれを参考にしてやりましょうみたいな、教科書的には。
堅実ですね。
実際やってる話として見たときに、不確実なものと確実なものは切り分けます、個人的に。
2時間って時間の目安は言ったんですけど、これは確実に2時間内に終わるというか、
要は固い仕事でそんなに時間のぶれはないものだっていうものと、
いやこれって2時間から3時間だねみたいなものはちょっと分けて考えます。
できれば2時間って言ってる中に固いのと柔らかいのが混じってるんだとしたらできれば分けたい。
ちなみにその固い柔らかいっていうのはヤギさんにとってどういうところで固いとか柔らかいって話ですか?
実感通り終わるかとか。
っていうのはあれですか、大体やること見えてて、要は試行錯誤がそんなになくて済むとかそんなイメージですか?
そうですね。
たぶんゴールイメージがあって、あとは作業レベルに落ちそう。
落ちててもいいですし、なくてもいいです。
だからイレギュラーなパターン、手が止まる瞬間がおそらくなさそうだなって思ったらそれ大体時間通り終えれるんで。
結構個人的には設計するところって読めないなと思って。
読めないですね。
試行錯誤の設計と論文作成プロセス
こういう構造でやろうとか、こういう形にしていこうとかって考えだすと、
細かいところ入っていくと、こっちもこうしたいから上直そうとか結構あるじゃないですか。
それやってると大体時間通りに終わんないっていう問題には直面してるんですけど、
それやっぱり試行錯誤の時間が長いからそうなっちゃうよねっていうことですよね。
試行錯誤をどこでするかって設計が、繰り返し性があればそれができて、
例えば私の場合論文書くんですけど、論文書くときって私の場合はまず目次を基本的に考えるっていうのはあって、
まずいきなり書き出すんじゃなくて、ファインドマップ使ったりしますけど構造を書き出して、
ここの章ではここまで書く。本当にちゃんとやるときは、この文節ではこれを伝えるまでに分解します。
この文節ではこれを伝える、次の文節はこれを伝えるっていう文節レベルで全部分けてて、
書いた上で見積もると、それはもうほぼ作業なんでザッて書けます。
図表とかもその時点でこの辺でこの図表を作る。図表を作るのも多分この時間だいたい読めるんで。
っていうようなやり方をすると手が止まらないので、読めるかなっていう感じ。
そしたら準備ですよね。
話し手 2 論文みたいに型があるとなおさらそのあたりってガイドがあるからやりやすいですよね。
話し手 1 そうですね。
話し手 2 いやー、いつも結構読めないんでできてないところですね。
モヤモヤした時間について
あと研究者なのである程度モヤモヤした時間っていうのをまとめて確保しようとしますけど。
プライベートに関わっちゃうんで人によってはちょっとどうかと思ってるけど。
まずそのモヤモヤするためにインプットとなる情報はいります。
例えばお客さんとかの問題がどうなのかみたいな。
一般常識としてこういう情報が世の中にあるよねとかも含めて。
っていうのをまずザーってインプットするだけ時間作って、あとは寝かせて。
話し手 2 わかりますわかります。
なんか脳の中である時に変に繋がったりする感じがありますよね。
散歩してる時になんか全然関係ない2、3日前の話がふと思い出されて。
こうした方がいいなとか。そんな感じですか寝かすっていうのは。
話し手 1 そんな感じです。
で、そういうのをどっかで構造化の話しましょう。
フレームとかに当てはめていけるなって思ったら作業レベルに落ちるので。
そっから多分見積もり取りに来やすい。
思いつくとかって正直見積もり用がないんで。
話し手 2 寝かせますって。いつまで寝かせればいいんですかって言っても。
さーってなっちゃいますよね。
話し手 1 だからそれはなるべく早くインプットだけしといて。
頭の片隅に置いとくっていう。
それによっては嫌がるかもしれない。
話し手 2 今言ったようにもやもやしたりとかなんか寝かしとくやつは分けて。
で、やることはやることでちゃんと仕事としては区切って進めていくっていうのが
今ヤギさんが気をつけてるっていうそんなことですかね。
話し手 1 そんな感じで仕事しております。
話し手 2 私もちょっと近いんでよく分かります。
ちなみにある種、自分がやりたいことを自分でコントロールしてる状態じゃないですか。
その話で。
でも仕事って割り込みとかなんか揉め事とかいろいろあるじゃないですか。
そういう時どうしてるんですか。
話し手 1 あの2個あって割り込みがあるやつは
優先度と鑑み手相談があって。
あとは受け取っといて寝かしとく。
割り込みが入ったら割り込みに受けちゃうと実は結構嫌になっちゃうんで。
一旦受けるんだけどすぐ手つけないっていうのが多分一つの手段だとは思いますけど。
話し手 2 あーなるほどなるほど。
話し手 1 割り込みに関して。
トラブルがあるやつで、私の場合ってたまにあるんですけど
炎上してるやつに突っ込まれる時がある。
話し手 2 炎上プロジェクトに。
話し手 1 炎上してる時ってなんか揉めてるので
人を変える意味で突っ込まれる場合がありますけど
その時やることはオプションを減らすっていうやり方をします。
具体的に言うとあえてタイロを立つみたいな。
もうちょっと具体的に言うと
場合によってはお客さんを切ってもいいですかっていう
社内的なところを取り付けた上で
私がダメな場合はこのプロジェクトは終了ですって
お客さんと話をするとか。
そうすると向こうもそういういろんな選択肢が取れなくなるので
やるべきことに集中しやすくなるっていう。
なるほど。
それできるかどうかは場合によりますけど。
そうですね。できるかどうか問題だなと思いますけど
アプローチとしてはなるほどよくわかりました。
炎上して頼まれてる、言ってる方なんで
ある程度社内も言う聞いてくれる場合があって
これダメな場合断っていいですよねって。
ここまでやってんだからねみたいな話ですね。
そういうとこですかね。
相手もなんか増長しちゃう可能性が高いんで
やっぱここまでしかできないですよとか
こうなっちゃったらもうこれ進まないですよみたいなことを
先に決めちゃうとそれ自体がある種
冷静さを取り戻すきっかけになるみたいなところはありそうですね。
昔期待値コントロールの話をしましたけど
期待値の上限を決めるみたいな多分話に。
まさにそうですね。確かに。
そんな何でもかんでもできないよねっていう話だと思うので
ここまでですよっていうことですね。
なるほど。
ちょっとまとめると1個集中するっていうのが
1つのポイントかなとは思ってますけど
1つのことに集中する。
作業も1つのことだし
プロジェクトが炎上したときも数減らして1個にするとか
もやもやしたところをやるときも
あれもこれもになりやすいので
もやもやしてるときはもやもやしてることに集中する
っていうのがいいんじゃないかなと思います。
参考になったけど
真似できるかどうかまたちょっと別問題だなと。
そうですね。
私はこう仕事しております。
個人的にはもやもやするのを置いとくのが苦手だったりするんで
寝かしとこって思えるかどうか結構難しいなと思いました。
もやもやしてるの大好き。
それはちょっと人によりますね。
そうですね。性格もあるなと思いましたね。
確かにシングルタスクでやってきつつ
考える時間もタスクの中に入れ込んで
厳密に言えばタスクの外なんだけど
マルチタスク的にやってる部分もあるっていう
面白いやり方ですね。
もやもやする時間は大切にできるようになれると
幸せになるかもしれないですね。
では以上にしたいと思います。
ありがとうございます。
ありがとうございます。
