責任と権限の導入
おつかれさまです。経営企画のたばこ部屋 50 回目の配信です。
戦略コンセルから事業会社の経営企画、FP&A に転身したきりんが、
今日も経営企画の日記の話題をお届けしております。
50 回目という記念すべき回なんですけれども、
今日も通常通り、いつもの話をしていきたいと思います。
責任とか権限の話をしたくてですね、
責任が欲しいなって思う人ってそんなにいないと思うんですけど、
プロジェクトとか任されるときに、権限欲しいなって思うことってないですかね。
誰かを支持したいとかそういうわけじゃないんですけれども、
何か自分の支持できるようなメンバーがいたりとか、
手を貸してくれる仲間がいたりとかですね、
そういう人が、いわゆる権限を持っていれば、
もっと楽に仕事ができるのになみたいなことを、
正直思ったりすることもあると思うんですよ。私もそうで。
その権限をどのように獲得していくべきなんだろうかという話を、
今日はしたいと思っています。
情報収集の重要性
どこかに入社をしてですね、組織に入ってですね、
基本的には最初は権限が少なくて、
責任範囲もぼんやりしているようなところからのスタートかと思います。
組織の側からも、この人は何が得意で、
何をしてくれる人なんだろうかと、
そういうふうに思われていることも多いと思うんですよね。
何か役割があって、それをやってくれというふうに言われる場合であれば、
分かりやすいんですけれど、具体的にこれをやってくださいということを、
支持されないことも半ばあるんじゃないかなと思います。
特に我々のような経営企画みたいな、何でもいいじゃないですけれども、
いろんなところでいろんな仕事をしている人が多いので、
定常的にこれをやってくださいという、
例えば管理会経験の話であればあるかもしれませんけれども、
どういうところに自分の責任範囲とかを広げていくのかというのは、
フリーハンドで描ける部分もある。
それが経営企画の楽しみ方の一つでもあるんですけれども、
自分がどう価値を出していくか、
これを自分なりに定義をしていくという意味で、
この自分の価値の出しどころになりそうな仕事というものを、
まず最初はとりあえず首を突っ込んだりとか、
いろんな情報収集をしてみるというところからのスタートになるんじゃないでしょうか。
この注意点じゃないですけれども、
いろいろ情報収集をする中で、
教えてください、聞かせてくださいというふうにいくんですけれども、
そのときにあんまり、
ただ情報を聞くだけで何もしなかったねみたいになると、
だんだん情報が集まらなくなってくるので、
これは注意をしたいところで、
ある種、情報の共有を受けるということは、
その責任の一部を共有するような、
そんなニュアンスも含むものじゃないですか。
もっと言い方がいいか悪いかわからないんですけれども、
例えばいじめを知っているのに、
それを何もしないというと、
それってある意味いじめを黙認しているのと同じみたいな感じじゃないですか。
ちょっと過激な表現ではあるんですけれども、
そんな感じで何か聞くんであれば、
その聞いた情報をもとに、
自分的にこういった価値が出せそうだなということは、
常に考えながら情報収集をしておくと、
この情報収集というのは、
どんどん幅が広がってくるかと思います。
情報を与えてもブレーキをかけるだけみたいな人いるじゃないですか。
あるいはそんなことをやらない方がいいんじゃないのとか、
評論家的に評論するだけの人っていると思うんですけど、
そういう人への情報共有って基本的には外されていくだけなので、
あまりやめておきましょうねという話ですね。
情報収集の話で横道に逸れてしまいましたけれども、
権限獲得のプロセス
こういうふうに本来自分の役割ではないというところから、
自分の責任とかをまずは獲得していく流れになると思うんです。
自分の仕事ではない、
本来自分の仕事ではない部分の仕事をやる機会が生まれるというか、
自分で手を伸ばして自ら獲得しにいくというところが
ファーストステップかなと思います。
それをまず別に権限とかなくて、
自分が自分の力で自分の手で素早く小さく成果を出すというところを
繰り返していくところなんじゃないかなというところですね。
そういうことを繰り返しているうちに、
だんだんこの人にちょっと入ってもらうと、
いろいろ話が前に進むなとか、
意外と早く正確にアウトプットしてくれるなとかですね、
信頼を小さく獲得していくと、
だんだんと与えられる仕事の粒感が大きくなってくるのが
分かるんじゃないでしょうかというところですね。
そうするとだんだん粒感が大きくなってくると、
自分だけではその仕事を完成することができなかったりする、
そういう大きさになってくるんですよ。
これはつまり情報がないとか、
これまでの背景とか経緯が分からないとか、
どうしてもエンジニアの人に助けを借りないといけないとか、
物理的に1人じゃ絶対に間に合わないからチームを作らないといけないとか、
いろんなパターンがあると思いますが、
本来の自分の職責では関わらないような人間にお願いをしないと、
この自分の与えられた仕事というものが完成できない、
そういう仕事にアサインされる機会も
やがて生まれてくるんじゃないかと思います。
そうなると自分以外の人の手を借りないといけないので、
各部署の人とかに何かお願いすることが当然生まれてくるわけですが、
その人って本来自分の支持系統にある人ではないじゃないですか、
だからなかなか動いてもらうことができなかったりとか、
その方の持っている定常業務とか他の優先度の高い仕事よりも
後回しにされてしまったりとかというのは当然起きてしまうと思います。
これはその人が悪いというよりは自分もそういうふうにすると思うんですよね。
とはいえ自分の仕事が完成できないとなると困ったなというふうになるので、
その仕事の情緒ですね。
その仕事をやる上でこういうリソースが必要で、
こういう体制とかこういうお金が必要でみたいな感じで、
こういうものが自分の周りにないとできないですと。
自分でもちろんめっちゃやるんですけれどっていうのは大前提に
体制とか権限とかに関する相談をすると、
そこでようやく自分の役割みたいなところが明確化されて、
じゃああなたがプロジェクトリーダーとしてちょっと一回キックオフをしましょうかと。
このチーム体制においてあなたがこの人を支持してやるような感じで
プロジェクトにしましょうかというふうに言ってもらえたらラッキーという感じですね。
いわゆるオーソライズされたチームの獲得ができるパターンがそこであるかもしれません。
ここで言いたいのは情緒に用意してもらいましょうとかそういう話ではなくて、
そこに至るまでにもう十分に自分の責任範囲とか信頼が積もっているからこそ、
権限が獲得できるというそういう話なんですね。
要は先に責任を広げて結果が伴ってきたからこそ、
権限がそこで与えられたのだというそんな話でございます。
権限を得るための責任
権限を先に得てチームを作って進めるという言い方になると結構語弊があるんですけれども、
先に自分の方でこういう責任を引き受けた上で悪戦苦闘して、
それでも足りないからこういうふうにしたいというふうに直談判をすると、
チームとか権限とかそういうことが得られる可能性が高まるという話ですね。
少し違う話に展開することができて、
デファクトの争いと言いますか、
社内で仕事のやり方に関する議論とか、
こういうやり方がいいんじゃないか、
あるいはそのやり方よりもこっちがいいんじゃないかとかですね、
そういう議論って割と起こりがちだと思うんですね。
でももうちょっと具体的な話をすると、
何かの仕事の進め方として型を作ったほうがいい、
型を作って標準化したほうがいいんじゃないか。
いや、型を作ったらむしろいろんなイレギュラーの場合に対応できないし、
その都度考えて考える人間に育ってもらったほうがいいんじゃないかと、
そうしたほうがこの都度、
いろんなことに思いを馳せながら最適なものができるじゃないかという、
そんな主張がそれぞれあったとしましょうと。
型を作るのか否かみたいな話ですね。
それでその議論をですね、
両方言ってることは正しいわけですよ。
型化をすることってもちろんいろんな短縮にもなりますし、
主張りの主の部分ですよね。
それを作ろうという話ですし、
型やそれだけに頼っていると、
マニュアル人間になってしまうみたいな話もあると思うんですよね。
だからあんまりそれに頼らないで、
自分の頭で考えられる人を置いておこうということは、
それもそれで正しい主張であると。
いわゆる平行線をたどるわけですね、この話って。
なので、じゃあどっちが正しいねとかっていうことを
結論を出してから型を作っていこうとか、
そういうことをするんじゃなくて、
誰の承認を得ることもなくですね、
仮にそれを型を作りたいのであればですよ、
その人が私がですね。
作りたいのであれば、
もう先に型を作ってしまって、
それによって圧倒的な成果を先に出してしまうというのが、
いわゆるセオリーかと思います。
先に結果が出てしまえば、
逆にそれってどうやってやってるんですかとか、
どういう形でこれを進めたんですかとか、
そういうふうに知見を得たい人が
社内で集まってくるんですよね。
勝手に自分が先に結果を出せばですけど、
それをやれば自分の真似をしてくれる人が増えるので、
それによって勝手に型が社内に広まっていくとか、
いわゆるデファクトの地位を
結果的に獲得することができるという、
そんな話ですね。
これもやり方を議論して、
そのやり方についてオーソライズ、
承認を受けて進めるのではなくて、
その順番ではなくて、
先に承認を得るんじゃなくて、
やってみて、先にやって結果を出して、
結果としてそのやり方を正当化して、
デファクトを獲得する。
そういう順番で考えるといいんじゃないでしょうか、
型と柔軟性の議論
ということですね。
このデファクトアラートという話もそうですし、
序盤の権限とか責任の話もそうです。
権限を得てチームを作って進めるという順番で、
まず別に何も信頼もないし、
責任を持っていない段階で、
先に権限をくれというふうに言っても、
本当に君に権限を与えたらやってくれるの、
という話でしかないわけですね。
なので先にこれは私がやりますと、
私が責任を持ってやりきりますということを
ゴミとして、
その上でその責任を完遂するために、
こういうチームとかこういう予算とか権限とか
というものがどうしても必要になってきます
というふうに言えるかどうかという話で、
逆なんですよね。主従が逆。
責任から権限が生まれてくるというふうに考えると、
自分の境遇を呪うことも少なくなるんじゃないかな
というそんなお話でございました。
ちょっと固い話になってしまいましたけれども、
経営企画、特にそういうプロジェクトを有機的に
進めていくような部署においては、
非常に重要な考え方なんじゃないかなという
そんな思いでお話をさせていただきました。
今日は以上とします。
もしよろしければ、高評価やコメント、
フォローなどをいただけますと大変励みになります。
お疲れ様でした。
