
グロースする?それともクローズする?
こんばんは、ピンチのときほど責任者をやりたがるIwaoです。
事業って右肩上がりのうちは楽しいですよね。すべての行動が効果的なんじゃないかって思える不思議があります。
しかし、最もインパクトがあるのは事業の経営がピンチのとき、つまり成長が止まって売上が下がったときです。財布を見るとまだ大丈夫って思う反面、売上が下がり続けることを想像するとそれはもう恐怖です。
そんな事業がピンチのときにどういう行動をとればよいか、僅かな経験則ですがまとめてみます。ご参考までに!
1. 現状分析
まずはお決まりの現状分析から入ります。当たり前だと思われるかもしれませんが、テンパってしまうと思考する前に変な行動をとってしまいがちです。決断には分析がセオリーです。
ピンチの要因を分析して、課題の仮説を立てます。
分析もレポートにするだけではダメで分析レポートは意思決定できるクオリティでなければなりません。意思決定というのは進むかやり直すかの0 1かもしれないし、優先度の選択かもしれません。
課題はロジックツリーでツリー上に分解して因果関係を可視化すると良いでしょう。なぜなら誰でも共感できるようにわかりやすくするためです。
- 製品の売り上げが低下している
- 販売力が弱い
- 製品の価値を顧客に届けられていない
- セールスの製品知識が不足している
- 価格が高い
- 低価格の競合製品が増えた
- 原価が高くなった
- 製品のクオリティが低い
- バリューの定義が間違っている
- ニーズの分析が不十分である
またピンチのときでも誰が悪いという思考じゃなくてなぜ起こったのかという思考をしてください。Whyが分かればHowとなる施策を立てやすくなります。
3C、PEST、SWOTなど分析手法は多々あります。経営企画みたいな部門があれば色々知っていると思うので相談しましょう。
2. 課題から計画を立てる
現状分析から課題が出たら、課題を解決するためにどう行動すればよいか計画を立てます。ここでは各リーダーの知恵・意見を重視したほうがよいです。なぜなら会社の目標はすべてのチームの目標の集合体であり、その目標が達成できてないからです。
ここでは5W1Hのフレームワークがシンプルです。こちらに思考法をまとめています。
一つ一つの課題に対して、共感・定義・概念化はやったほうがいいでしょう。適当な例を貼っておきます。
- バリューの定義が間違っている
Who: プロダクトマネージャーは
Why: 顧客に正しいバリューを届けるために
How: バリュープロポジションのKPIを定義し直して顧客ニーズを定量化して優先度を並べ替えて
When: 3ヶ月後までに?
Where: -
What: 開発へ落とし込む
ピンチのときこそリーダーの本領発揮のタイミングです。課題に真摯に立ち向かい、チームに状況を説明して共感を得る必要があります。
起業してたときも何度も徹夜したり、誰かに助けを求めたり非常に苦労しました。リーダーがスタッフより高い報酬を受け取っているのはこのためでもあります。
いっぽうでピンチのときは人事制度を見直すいいきっかけです。優秀な人にはいいポストを用意しましょう。優秀な人はリスクとリターンのバランスを考えてるので大きなミッションにはそれなりのリターンを用意しましょう。サラリーマン時代は多くの人がそれで出世し、周りも納得感を得られます。
3. 計画を実行する
計画が全て出揃ったら誰が責任を持つか、課題に対してアサイニーを割り当てます。この人がPMであり、ここからがプロジェクトマネージメントの領域です。PMの方程式(自作)貼っておきます。
プロジェクト=共感+定義+概念化
マネジメント=人材配置/採用+コーチング+目標設定
いっぽうでピンチはチャンスって言葉はここで発揮されることになります。
経営者
組織のパフォーマンスを最適化する最大のチャンスです。サッカーチームなら課題が戦術なら監督を解任し、課題が得点力不足ならオフェンスの選手を入れ替えます。ここでもし配置替えできないならそれはチームワークの効果性を理解していない組織の責任になると思っています。
スタッフ
ここで活躍するとヒーローになれます。同じパフォーマンスでもピンチのときほど評価されやすく、僕は大企業で賞を貰ったのはすべてピンチを救ったときです。実際に負荷がかかるのはスタッフなので、しっかり成果に対するリターンを主張しましょう。
4. ふりかえり
プロジェクトごとに課題解決に向けて一丸となって進んでいきます。ピンチのときほどチームワークが重要になってきます。スクラムマスターみたいなパフォーマンスを上げれるリーダーシップを持つ人がチームにいると成果が出やすくなります。リーダーシップ=リーダーではないので注意が必要です。
プロセスに関しては再現性のあるフレームワークを選択することをオススメします。ピンチのときはイテレーション(サイクル)を短くすることが定石です。
PDCA: シンプルだがdisり記事が多くて時代遅れ説あり
PDR: 準備をしっかりするので若手主体のチームに効果的
FFA: コーチング成分高めで自発性の高いチームに効果的
大事なのは再現性のあるサイクルを回すことです。よくPDCAと比較されるデザイン思考はそもそも思考なので、ここではなくもっと上位のレイヤーで議論すべきなので無視しましょう!
まとめ
気づいている人もいるかと思いますが、この時点で通常営業時とピンチのときとで何もプロセスが変わっていないことにお気づきでしょうか?
そうなんです。今回はピンチを例に課題出ししたに過ぎず、再現性を担保できるビジネスフローであり状況変化に強いとされているビジネスのアジャイル化を解説していただけです。
アジャイルって何?ってググれば山のように出てきますが、長年エンジニアをやっている身ですからアジャイルの本質を投下しちゃいますね。
核心にある動機は、
・いつも不満を抱えている顧客
・いつも不機嫌なマネージャー
・疲れ果てた開発者
という状況認識であり、その原因を、
・官僚的な組織構造
・コマンド&コントロール型マネージメント
にあると捉えている。
状況が良くないことの原因は、組織構造とマネージメントに辿り着くとあります。開発チームはとりわけ組織構造とマネージメントが悪いとパフォーマンスが落ちるのも事実です。それを回避するために考えられたプロセスがアジャイルなのです。
ちなみにコマンド&コントロール型マネージメントとは、リーダーがスタッフに細かく指示をして、リーダーはスタッフの状況を監視して管理していくことです。マイクロマネージメントとも皮肉られるアンチパターンですね。
雑感
日頃から組織をクリーンにして、各チームの信頼性を損なわないマネージメントをしていれば、突然やってくるピンチにも柔軟かつ冷静に対応できることが伝わったかなと思います。
これだけ多くの多種多様なサービスが生産されマイクロ化してきているので、一つの事業の伸びは緩やかになって、ピンチの回数も増えていくことになります。だからこそビジネスのアジャイル化は昨今注目されているわけです。
そこではリーダーだけでなく全メンバーが組織を改善する行動を求められており、一人一人が経営的目線で業務を遂行する時代になってきている証拠かなって思います(^^)