ダイニーのマネジメントのリアル。「厳しい管理」より「最良の支援」を。
今回は、2024年を振り返って、私が難しい状況において最も役に立ったマネジメントの方法について書きたいと思います。
ずばり「レポーティング」についてです。
というのも、今年のマネジメント活動において肝心だったのは、「レポーティング」だったなと思っています。
レポーティングを強化する、頻度を上げるって、いわゆる「マイクロマネジメント」的で嫌なイメージありますよね。
でも、このnoteを読んでもらえたら、そんな印象がすこし変わるのではないかと思っています。
特に顧客やプロダクト、組織に向き合って、
日々忙しくしている現場やマネージャーの人に、うまく届いたらと思っています。
マネジメントの名著に学び実践すること
インテルの元CEOが、起業家・経営者・マネジャーに向けて書かれたマネジメントの『HIGH OUTPUT MANAGEMENT（ハイアウトプット マネジメント） 人を育て、成果を最大にするマネジメント』をご存知でしょうか。
この本は、本当に学びが多いので、マネジメントに携わる人には、ぜひおすすめしたいです。
今回のnoteでは、本書の中から、私が現場でとても役にたった基本の中の基本のノウハウを、
ダイニーでの2つの具体的なエピソードを交えてお伝えしていけたらと思います。
というのも、こういったマネジメント本に書いてあることは、
読むと「それはそうだろうな」と納得する「正しい教え」が多いのですが、
多くの現場でそれを全うするのは難しかったりします。
どうしてか。
どんな施策も既存のやり方を変える必要がある、コストがかかるなど、導入の際のデメリットや抵抗があり、かつ、現場で一生懸命働いている人ほど、「管理されたくない」からです。
よって、どうこの「正しい教え」を適切に実践するかがポイントだととらえています。
「レポーティング」の重要性とは
自分の肩書きはCTOなのですが、スタートアップのマネジメントは必要なことをなんでもやる必要があります。
今回は、セールス組織のマネジメントを担ったエピソードと、管掌していたエンジニア組織のマネジメント体制を構築したエピソードの２つです。
具体的なエピソードに入る前に、「レポーティング」について、本書に書かれていることを簡単にまとめてみます。
レポーティングとは
レポーティングは単なる情報伝達ではなく、組織の健全性を維持し、問題を早期発見するための重要なツールとして位置づけられる。
適切なレポーティングにより、マネージャーは組織の状態を把握し、必要な介入を適切なタイミングで行うことが可能になる。
つまり、適切に設定されたレポートによって、マネージャーは組織の意思決定と問題解決を支援することができる。
ポイント
週次・月次などにおける情報はタイムリーではないが、随時入ってくる情報の確認を助け、重要な情報を見逃さないためのセーフティーネットとなる。
レポートの作成者は、口頭でいうときよりも、厳密にならざるをえないため、思考と規律を自らに課さざるをえない。
レポートは情報を伝える方法というよりは、「物事を厳密に把握・管理する訓練」の手段となる。つまり、レポートを〝書くこと〟は重要だが、読むことは重要でないことも多い。
プロセス
1. 指標とタイミングの設定
業務の成否を判断するための重要な指標（KPI）を特定し、適切なレポートタイミングを設定する。
2. データの収集と分析
定期的かつ一貫した方法でデータを収集。トレンドや変化の分析も含む。
異常値や変化の兆候を見逃さないよう注意。
3. レポートの作成と共有
重要なポイントを明確に示し、必要に応じて改善提案を含める。
適切なタイミングで適切な相手に共有します。
ざっとこんなところでしょうか。
ここまで読んでみて、みなさん、「そりゃそうだろう」という感じかもしれません。
しかし組織が余裕のあるときならいいのですが、逼迫している時、変化をし続けているときに、適切にレポーティングを導入しようとすると、なかなか難しいものなのです。
ハードな状況のセールスチームをマネジメントをした話
自分がセールスチームのマネジメントを直接担当することになったのは2024年の初めでした。
当時のチームは、すこし難しい状況に直面していました。
事業全体のロードマップは可視化されているものの、セールス組織の体制やミッションなどの展望が見えておらず、「いつまでこのハードな営業活動を続ければいいのか」という閉塞感があったように思います。
具体的には、以下のような状況です。
売上目標は上がり続けていたが、毎月チームでの達成は維持していた
毎日の営業活動に追われていて、みんなすこし疲れている
個人レベルでは、思うような評価を得られないこともあった
→ 理由として、チーム内の役割や定義が整備されておらず、チャレンジ機会が創出できておらず、評価のタイミングでもプレイヤーとしての数字以上の評価がしづらい環境だった
当時の課題を整理すると、このような具合でした。
半年、1年後に目指す組織図・体制を定義できていなかった
その結果、各メンバーのキャリアパスを設計できていなかった
マネージャー向けのフォローが不十分だった
チームミッションが明確ではなかった
→売上という大目標があったが、付帯業務の優先度や前さばきができていなかった。
目標を達成していたので、それはとてもすばらしい成果です。
一方、日々がんばっているのに、なぜか組織・事業の成長につながらない、という悪いループにはまりかねない状態でもあったと思います。
メンバー一人ひとりの商談に同席して状況を確認すれば詳細はわかりますが、それでは組織として回りません。
どこに注目して見ていけばよいのか、試行錯誤が必要でした。
チーム変革の２ステップ
状況を改善するために、レポーティングの仕組みを整える必要がありました。
ただし、現場のチームからすれば、「レポートをしたところで成果はあがらない」「なぜこんなに忙しくがんばっているのに、いちいち報告しなければいけないのか」という反発は当然です。
特にプロ意識の高いメンバーほど、「ちゃんとやっているのだから任せてほしい」と感じるものです。
そこで自分は、「みなさんのがんばりをきちんと理解し、評価したい」という意図を明確に伝えることから始めました。
そして「チーム日報」という形でスタートし、毎週月曜のチーム定例で定義・発表した活動優先度に合わせて、メンバー全員が日報を送るというルール付けからスタートしました。
実はこのチームのほとんどのメンバーとは、以前から飲み会などで交流があり、ある程度の関係値があったことにも助けられました。
（単純にお酒が好きという理由もあるのですが、自分は表現が得意なタイプではないので、少人数での丁寧なコミュニケーションを心がけ、一対一の深い対話を通じて人を理解することを大切にしてきました）
チームの変革は、大きく分けて2つのステップを踏みました。
ステップ１．レポートの土台を整える：顧客セグメントの再定義
具体的な課題として、顧客である飲食店の「小規模法人セグメントの管理」があいまいでした。
このセグメントを担当していたメンバーは、顧客支援やサポートに熱心で、顧客に寄り添う形の営業を得意としていましたが、もともと営業経験がなく、数字を管理しながら活動をする経験が豊富ではありませんでした。
人数が少ない頃はそれでも互いにフォローをし合って、臨機応変にできるものですが、規模が大きくなるとそうはいきません。
よって、曖昧だった顧客セグメントの定義を明確にしました。大規模法人、中規模法人、小規模法人と区分け、それぞれに適した形でレポーティングの型を決めました。
以前は売上目標を感覚的に割り振って「みんなでがんばろう」という状態でしたが、これを改め、ゴールから逆算して必要な数字を分解し、担当も再配置しました。
ステップ２．レポートの指標を設定
次に、活動量を正確に把握するために、最初は極めてシンプルな指標から始めることにしました。
ただし、売上目標が上がり続ける中で、複雑な仕組みを導入する余裕はありません。
そこで、Googleカレンダーを活用して簡単に顧客との接触頻度を計測する仕組みを作りました。これなら新しい入力作業も発生せず、負担も最小限で済みます。
ダイニーのアカウントセールスチームは、営業活動とサクセス活動を両立する必要がある難易度が高いチームです。
営業でよくある、「商談数✕受注率✕受注単価＝売上」という式では、サクセス活動の分が考慮できないので、
行動量（サクセス活動含む）→商談数（≒営業活動の行動量） → 受注率・受注単価 → 売上
とし、売上から逆算で行動量目安を定め、かつメンバー目線では最初の行動量を追うと、自ずと売上が満たされる、といった設計をしました。
この変更には慎重を期しました。数字を追うことに不慣れなメンバーもいましたので、段階を踏んで進める必要がありました。マネジメント体制も見直し、新しい仕組みを機能させるために、適性のある人材を見極めながら、少しずつ権限委譲を進めていきました。
すると、「行動量と攻めの商談数のバランスが良いメンバー」と「行動量は多いが、攻めの商談が少ないメンバー」の具体的な活動の差が見えてきました。
ただし、この数字を使って評価をするのが目的ではありません。サクセス活動を丁寧にやっている反面、商談の数が芳しくない場合は、どんなサポートが必要かを一緒に考えるようにしました。
なので、レポーティングは一つの軸なのですが、レポートラインを構築し、数字をモニターすれば OK という話ではありません。
実際は数字はズレるし、構築したレポートラインも常に不完全ではあるので、リスクを察知したらマネージャーが自ら即介入して、致命傷を防ぐ動きをすること、その結果を踏まえてレポートラインを改善すること、が重要です。
例えば、商談の準備が間に合っていないケースでは、自分自身が資料作成を手伝ったり、商談に同席して一緒に提案したりしました。チーム全体のリソースが明らかに不足している場合は、他チームからの応援を調整することもありました。
レポーティングは監視ではない
この「見える化→サポート」のサイクルを繰り返す中で、メンバーたちの意識も少しずつ変わっていきました。数字を報告することは「監視」ではなく、必要なサポートを得るための重要な手段だと理解されてきたのだと思います。
その後、チームの成熟度に合わせて、徐々に計測する指標を増やしていきました。商談数、受注率といった、より本質的なKPIも導入。これらの数字の管理も、適性のあるメンバーに少しずつ権限委譲していきました。
結果として、チームはこの1年間にわたって売上目標を達成し続けることができました。メンバーも2倍に増え、それぞれが新しい役割にチャレンジできる環境が整いました。
下期には、自分が関わり始めにやったような、「役割定義・段階的な権限委譲・レポーティング」の打ち手が、チーム内で自発的に行われるようになりました。
チームの中で、数字周りに責務を持つ役割のメンバーが先導し、チーム内の小ユニットに対して、「役割定義・段階的な権限委譲・レポーティング」をやるようになり、結果的に多くのメンバーのレベルアップ、スキルアップが実現していっていました。
そんな組織の成長の中で、最もうれしかったのは、メンバー自身から「やりがいを感じている」という声を直接聞けたことです。
もちろん、これを進める過程では、厳しい判断を迫られることもありました。特に「数字の見える化」よりも、「役割を分ける・明確化する」の方が厳しい判断でした。
人によってはネガティブに感じる差配もあったと思います。一時のことでも、モチベーションが下がったと思います。
しかし、その目的が「チームとして成果を出し続けるために、メンバーのがんばりを正しく理解し、必要なサポートをするため」であることを、行動で示し続けることで、組織は良い方向に向かっていくのだと、この経験から確信を得ることができました。
と、ここまで書くと、あたかも自分が先導してやったかのように見えるかもしれませんが、実際には方針に理解を示し、全力投球でコミットしてくれたメンバーの功績が大きいです。
この1年間、多くの組織体制や方針の変換にも関わらず、常にチームの成果と顧客目線を大事にしながら、事業貢献いただけたアカウントセールスチームのみなさんには、改めて感謝を捧げたいと思います。
組織を信じてくれて、ありがとうございます。
倍になって3層構造に移行したエンジニアチームの話
次にエンジニアチームのエピソードです。
先のセールスチームのマネジメントをするために、同じく2024年1月から自分がCTOとして管掌していたエンジニアチームを、ミドルマネージャーに権限委譲していくことになりました。
この1年でチームは、10名から20名と倍の規模になる中で、トップマネジメント⇔ミドルマネジメント⇔現場という3層構造の組織に移行しました。
ミドルマネージャーは入社半年でしたが、プレイヤーとしても、技術力が抜群でまわりからリスペクトを得ており、個人としての実績も十分。ただし、マネジメントを専門として取り組むのは初めてでした。
やはり最初に取り組んだのは、レポーティングの仕組みづくりです。
ここで重要な決断をしました。それまで3ヶ月単位だったレポート、具体的には個人目標・チーム目標の振り返り実施とフィードバックを、中間地点を設け、1.5ヶ月に短縮したのです。
中間地点でのレポートは基本的に、自分とミドルマネージャーのみで行い、一部介入が必要なケースのみ、その時点でミドルマネージャーがメンバーとコミュニケーションをとりました。
最初の権限委譲だったこともあり、丁寧に見たかったことと、3ヶ月ごとのレポーティングでは問題の発見が遅すぎるという認識がありました。エンジニアの業務の成果は、営業の売上や利益よりも、単純な数値化が難しい分、より頻繁なチェックポイントを設けることで、小さな課題や変化を見逃さないようにするためです。
3ヶ月だと「結果が出てから報告」という形になりがちですが、1.5ヶ月であれば「途中経過の共有」という性質が強くなります。これにより、報告の場が単なる評価の場ではなく、必要なサポートを検討する機会として機能するようになったのです。
よくある逆のパターンは、「うまくいってなさそうだけど、まだ1.5ヶ月あるのでもうすこし様子を見よう」と支援を保留するパターンですが、これは問題を先送りにして、課題を大きくするケースがほとんどです。
例えば、あるプロジェクトでプロジェクト内でのパフォーマンスが芳しくないメンバーがいました。3ヶ月サイクルだと「期限までに間に合わなかった」という結果報告になりかねませんが、1.5ヶ月のチェックポイントがあることで、早い段階で課題を共有。問題が深刻化する前に、チーム全体でソリューションを検討し、必要なサポートを提供することで、無事成果につなげることができました。
ここでもこのレポーティングが、「監視のためのマイクロマネジメント」ではなく、「みなさんの取り組みを正しく理解し、適切なサポートを提供するため」であることを、繰り返し説明しました。
負荷が高かったミドルマネージャーの心中
もちろん、レポート頻度を上げることはマネジメントの負荷がかかります。
実際、ミドルマネージャーのurayamaさんは大変だったと思うので、直接声を聞いてみました。
曰く「大変ではあるものの、課題への対処は早ければ早いほど良い。必要な時にリアルタイムで自分からエスカレーションするのはもちろん、明確なチェックポイントを作ることで懸念レベルのことでも拾い上げて共有できるタイミングがあるのは良い」ということでした。
エンジニア組織の改革については、urayamaさんのわかりやすいnoteがあるので、気になる方は、こちらもぜひチェックしてみて下さい。
たぶん、レポーティング頻度を上げようと提案すると、「余計な管理工数が増えるだけではないか」「短いスパンでは成果が見えにくいのではないか」といった声があがりやすいと思います。
ただうまくレポーティングができれば、評価の工数が二倍になるというより、中間レポートによって評価の工数が分散し、結果的に評価負担が減る。
また、短いスパンだったとしても、直接メンバーを見ているマネージャーであれば、1.5ヶ月後くらいの成果を予測できるということだと考えています。
方やメンバー目線では、適切に迅速な支援を受けられ、また期待値がずれないので、評価のときに悲しい思いをしないで済みます。
もともとエンジニアチームは技術力の高さもさることながら、みな士気が高く、成長意欲も高く、目標に対して貪欲な人が多いので、このやり方がうまくハマっているとのだと思います。
このように、データやファクトに基づくマネジメントと、人間的な信頼関係の両立を目指した結果、チームは順調に開発を続け、目標を達成しています。
適切なレポーティング設計は強力な構造をもたらす
個人のがんばりが、組織としてうまく結集せずに、
軌道修正や支援ができなくるというのは、どの現場でも起こる問題です。
適切なレポーティングを図るということは、以下のような構造をもたらすことになるのです。
レポートラインを構築する
構築されたレポートラインに合わせて組織設計する
結果として、各レポートラインに説明責任が生じ、それらが新しい役割設計になる
新しい役割ができ、各メンバーのミッションやネクストキャリアステップが明確になる
改めて、適切なレポーティングの導入は、単なる情報伝達ではなく、事業の状況を効果的に観測する仕組みづくりであり、事業・組織リスクの早期発見を可能にする強力な武器です。
ダイニーのみなさんは、困ったらマネージャーや私にいつでも相談してください。
スタートアップのみなさん、ともに楽しく成長していきましょう。
そして、この本が気になった人は、ぜひ一読することをおすすめします。今回書いたのは、この本のごく一部ですので。