つい「難しいですね〜」と言って逃げてしまう私のための思考プロセス

こんにちは。株式会社エス・エム・エス で「カイポケ」という SaaS の Engineering Manager をやっている酒井です。Engineering Manager Advent Calendar 2023 の21日目向けの記事を書きます。

「難しいですね〜」と言ってしまう私

みなさんは、日々マネジメントの現場で組織課題を思考している時など、何か難しい問題に向き合っている時に、「いや〜難しいですね〜」というようなことを口にしていませんか?私はよくします。

会議などで「いや〜難しいですね〜」と言って時が過ぎ、「一旦時間も来ましたし…また次回考えましょう…じゃあ、おつかれさまでした………」これです。

いつも「難しいですね〜」を言ってしまって気がつくのですが、「難しいですね〜」を言っている瞬間は多分自分がその問題に本気で向き合っていない状態なんだと思います。別に言ってはいけない NG ワードとかではないのですが、私の中では「難しいですね〜」を言ってしまったときこそ「あっ、ちゃんと向き合わないと」と気づき、思考を整えるセンサーのようなものとして捉えています。

難しい問題にどう向き合うか

まず前提として、事業やプロダクトがスケールしていく状況において、マネジメントの役割が簡単な問題だけを解いていては、組織の成長が追いついていかなくなると思います。難しい問題が存在しているということが成長のチャンスであり、乗り越えた先のより良い状態を目指してこそ意味があると思います。とはいえ、そういう場面で出現してくる難しい問題は、まず向き合うのがとても面倒です。

私は、難しい問題に向き合う時に以下の手順でアクションプランを立てていきます。

  1. 大きな問題を小さな問題に分割・変換する

  2. 小さい問題の原因を言語化する

  3. ソリューションを考えながら影響する変数を整理する

  4. 最適なソリューションを見つける

  5. 小さくアクションする

こんな感じかなと思います。それぞれの手順の中でどう思考しているかを見つめ直してみたいと思います。

今回はとても難しそうなバーチャルな問題を考えてみます。たとえば「組織メンバーの主体性が上がらない」というシンプルな問題。どうですか??? テキストにするとシンプルですが、これを突きつけられると、とても難しそうですね??? 向き合うのもとても面倒そうです。

1. 大きな問題を小さな問題に分割・変換する

組織メンバーの主体性が上がらない」という問題があったとして、これを小さな問題に分割してみます。あくまでも仮説です。分割してみた問題たちが実際にメンバーの足元で発生しているのかは、後ほどの手順でちゃんと確認をしていきます。

まずはひとつの問題から関連する(かもしれない)5つの問題に分割されました。他にもまだまだ分割できるかもしれませんがひとまずここまで。そうしたら、一段目をさらに3つずつの問題に分割してみます。とはいえ、まだまだ仮説です。

ひとつの問題が関連する15個の問題に分割されていきました。こうやって、どんどん小さく問題を分割していくと、いずれそれぞれの問題が意外にも解決策を導いていきやすい・過去に対処したことのある問題の粒度になっていることに気づくことができます。

実際は、ここは別に 15 個じゃなくても良いです。たくさん出していけばいくほど、問題解決の実現可能性が広がっていくのを感じられます。

2. 小さい問題の原因を言語化する

さらに、それぞれの問題に対して、ここが原因なのではないか?というところを分析していきます。この分析作業は、想像・仮説で進めてはいけません。徹底的に情報を収集し、FACT に基づいて原因を特定、言語化していきます。試しに、一部分だけバーチャルな FACT を書き出してみます。ここは本来、チームやプロジェクト活動に deep dive していったり、個人との 1on1 やふりかえりイベントへの参加など、さまざまな場所に出向いて自分の目で・耳で情報を収集していくべきところです。



3. ソリューションを考えながら影響する変数を整理する

次に、それぞれの FACT から導き出した問題の原因と思われる箇所に対して、それを解決することができるソリューションを仮説的に考えて出していきます。この際に、それぞれのソリューションで影響するものごと(変数)を一緒に書き出していきながらその影響範囲や影響の大きさなどを整理していきます。それぞれのソリューションがどの変数に影響するのかを把握すると、次の「最適なソリューションを見つける」手順において、意思決定がしやすくなります。

4. 最適なソリューションを見つける

ここまでいくと、大きな問題の原因と解決策・その影響範囲までが可視化されるので、アクションしやすい気持ちになり、少しだけ自信が生まれてきます。また、思考プロセスにおいて、変数は多ければ多いほど良いです。問題を解決するとどういうメリットが生まれ、一方でどこにデメリットが生まれるのかが想像しやすくなります。また、ソリューションを実行しても大して変わらないことなども把握しやすくなります。

また、あるソリューションでは状況にポジティブな変化を生み出せなくても、別のソリューションを同時に(もしくは続けて)実行することで、より広くポジティブな変化が生み出せる可能性があることも分かってくるかもしれません。

以下の例では、まずは⭐️のついたふたつのソリューションを実行してみることで、「難しいですね〜」と言って逃げてしまっていた、根本の「主体性が上がらない」という問題に対してアクションしていく道を見つけることができました。

5. 小さくアクションする

ただし、ここまで決めていったソリューションはあくまでも仮説です。

実際に「主体性を上げる」ことができているかは、組織の中の人との対話で確認していくことが重要です。ソリューションが適切な問題解決になっているかどうかは、常に小さなアクションに対してフィードバックを得るようにします。

あまり効果がない、効果が小さい割に苦労しすぎている、などの状態がわかれば、すぐにその取り組みの方向性を変えたり中止したりすべきです。プロダクトをアジャイルに育てるのと同様に、組織も常に小さく試し、フィードバックを得ながら機動的に問題解決していくべきです。フィードバックサイクルを大事にしてアクションするようにしましょう。

難しい問題は怖くない

「難しいですね〜」と言ってしまうような問題に対しては、私はなるべくここまで書いてきたように分割・変数抽出・仮説定義を繰り返していくことで、ある程度解きやすい問題に変換し、影響させたいポイントを狙ってアクションするようにしています。

ただ、実際はこんなにシンプルではないでしょうし、問題同士が複雑に絡んでいて、制約も多いと思います。とはいえ、まずは向き合っている問題に対して可視化・言語化していくために手を動かしていくことはとても重要で、それをやっていくことで少しでも気が楽になっていく効果はあると思います。

そういうわけで、手と足と目と耳を動かしてマネジメントしましょう!!!!!

以上です!!!!!