この記事は『LITALICO Advent Calendar 2024』のカレンダー1最終日の記事です。
LITALICOでCTOをやっている@yuyaichihashiです。
今年もLITALICOでは、エンジニアだけでなく、デザイナーやPdMのみなさん含め、たくさんの仲間たちがバラエティに富んだ記事を投稿してくれています。
ぜひ、他の記事も読んでみてください！
どんな記事か？
今年の4月から、SaaSなどの開発グループを複数束ねる部署の部長を兼務しています。
今日は、CTOとしてではなく、部長としての取り組みについて書いてみたいと思います。
継続的に組織力を高め、事業成長に貢献し、ビジョンを達成するには、様々な組織作りの取り組みが必要ですが、この記事では、何はともあれ、部長として機能するために、部のマネジメントチームが機能するために、最低限必要な情報の把握やマネージャー陣とのコミュニケーションの仕組みとして導入したマネジメントレポート(週報/月報)について紹介したいと思います。
同じように間接マネジメントを役割とする方々の参考になればと思い執筆しましたが、書いてみると、直接マネジメントを役割としている方々にも、部分的に参考になることもあるかもしれません。
直接マネジメント
メンバーの方々をマネジメントしているマネージャーのマネジメント業務
間接マネジメント
マネージャーの方々をマネジメントしている上位マネージャーのマネジメント業務
として書いています
前提情報
- この部には事業領域ごとの6つの開発グループと共通基盤を扱う1つの開発グループがあります
- LITALICOでは部の長として部長、グループの長としてマネージャーという役職があります
- ただでさえグループが多い部署ですが、私はCTOが主務のため、部長として100%のリソースは使えません
- 副部長がおり、そのおかげで部が運営できています
目的
ここでいうマネジメントレポート(週報/月報)は、各グループのマネージャーから部長/副部長宛てに書いてもらっているものです。
部長/副部長宛てと書きましたが、詳細は後述しますが、他のマネージャーたちも自由に他のマネージャーのレポートを見られるようになっています。
今回のマネジメントレポートの導入では以下のようなことを目的としています。
目的①
- (限られたリソースで)部長レイヤとして必要な解像度で、常時、各グループの状態を把握する
- 経営層への正しい共有や、議論や経営判断の場面で実態と乖離した判断を防ぐ
- 単年度から中長期の戦略/計画や予算策定時に実態と乖離した判断を防ぐ
- マネージャーからの何かしらの起案や課題解決やトラブル対応などで、深く議論する際に、前提として必要な情報の理解であったり、議論の前提としてどこまでのことを部長が把握してるか双方で共通認識を持てる
- マネージャーとの責任の分かち合いや、アドバイスやフィードバック
- 他グループの知見の活用の促しや、グループを超えたリソースの調整
- 部単位で解決すべき課題の認識
- 各グループメンバーの中長期キャリア形成や人員計画のためのメンバー理解
- etc
目的②
- マネージャーの行動の促しや育成
- マネージャーにも新任から熟練者までおり、また、強み弱みもある
- マネジメント上持ってほしい観点をレポート項目を通じて設定することで、それらの観点を持ってマネジメントを行うことを促す
- 部長とのレポートを通じたやりとりや、他マネージャーのレポートを読むことでの学びの機会
目的③
- マネージャーの異動や管掌範囲の変更に備えた、横の情報を知る機会
- メンバーの異動や登用に備えた、横の情報を知る機会
- マネージャー/グループ同士で活かし合えるナレッジや取り組みを知る機会
- 部のマネジメント陣としてのチームビルドの一助
仕組みの概要
週報
- マネージャーは毎週金曜日の仕事終わりに週報(スプシ)を書き、slackのマネージャー陣のチャンネルに投稿する
- 部長は金曜のうちか週明けの月曜に週報を読み、slack上でコメントする
月報
- マネージャーは月初に月報(スプシ)を書き、slackのマネージャー陣のチャンネルに投稿する
- (週報の情報が共有されている前提で)月報を使ってマネージャーと部長/副部長で月次のミーティングを行う
週報の詳細
これが実際に使っている週報のフォーマットです。
設計上の観点
多角的な観点かつ適度な解像度で、グループの状況を把握できるように設計しています。
と同時に、マネージャーとして持ってほしい観点をある程度網羅するように設計しています。
できるだけ、悪い情報ほど早いタイミングで共有してもらうことで、マネージャーやグループだけで抱え込まず、部長としてのサポートであったり、グループ外の助けを得られるようにしたいので、顕在化した問題やリスクとして感じているものを共有できるように設計しています。
フリーフォーマットであったり、ノーフォーマットだと、なかなか悪い情報を言い出しづらく感じるマネージャーもいると思いますが、フォーマット化されていることで、報告や相談のしやすさに繋がる部分もあるのではないかと思っています。
また、リカバリ策などまで書くようにすることで、課題やリスクを捉え、解決や改善について考えることの癖付けも狙っています。
週末の仕事終わりに、少し時間を取って1週間を振り返り書けるくらいにして、できるだけ、週報を書く事自体に過剰な負担はかからないようにしたいと考えています。
パッと見はボリュームがあるように見えますが、週単位であることもあり、一度埋めてしまえば、毎回の更新部分は適度な範囲ではないかなと思いますが、このあたりは、まだ導入数ヶ月なので、マネージャー陣のフィードバックも収集したいと思っています。
計画的な活動に対する状況に関するもの
主要タスク進捗
ここでは、機能開発など開発案件だけでなく、たとえば、〇〇のパフォーマンス改善に取り組んでるとか、設計プロセスに課題があるから改善施策を進めているとか、計画し進めているものについて、主要なものを取り上げ、次のマイルストーンに向けた進捗状況や、遅延が発生していることへのリカバリ策を書きます。
プロダクト/システムの状況に関するもの
システムの状態
もちろん、グループ内では、多種多様なメトリクスのモニタリングをしますが、ここでは、最低限かつ共通して見られる健全性の指標として、ユーザー視点でのレスポンスタイムとエラーレートを書きます。
(プロダクト/システム特性によって、もう少し別の指標を追加するケースもあります。)
問題があれば、改善施策も書きます。
ユーザー問い合わせ状況
ここでは、どんなユーザー問い合わせがあったかや、問い合わせ数や内容の傾向などを書きます。
ユーザーからの問い合わせが発生する前に、バグやパフォーマンス問題など検知し修正できるのが理想ですが、そうではない事もままあります。
また、それ自体は必ずしもシステムのバグを示す問い合わせとは言えないけれど、類似の問い合わせが重なることから、調査の結果、バグであることが発覚するケースなどもあります。
他にも、UX/UIに関する気づきや、顧客ニーズに関する気づきなど、ユーザー問い合わせから得られるものは多いです。
インシデント/ヒヤリハット
各種システム障害やバグ、セキュリティ事故や法令違反などのインシデントや、ユーザー影響などに顕在化はしなかったものの危うい事があったならヒヤリハットとして、ここに記載します。
インシデントの詳細は、別途、ポストモーテムをストックするフォルダがあるので、そちらで内容を確認したりします。
チーム/人の状況に関するもの
チーム/人のコンディション
〇〇な理由でチームのコンディションやパフォーマンスが良好であるとか課題があるとか、具体的に発生した出来事や課題を書いたりします。
一人一人のメンバー(マネージャー自身を含む)についても同様です。
〇〇さんのこんな行動が良かったみたいなことも書いてくれるので、読んでいて嬉しい気持ちになったりもします。
メンバーの情報については、上長であるマネージャーとHRチームの担当だけ、など情報共有範囲をご本人と合意しながら扱う情報もありますので、それらについては書かないようにします。
事業の状況に関するもの
事業/サービス
市場環境や事業上の動きやトピック、課題や戦略/戦術の変化、営業進捗などなど、事業やサービスに関する出来事を書きます。
運用上のポイント
目的の②や③のために、個々のマネージャーと部長に閉じたものではなく、マネージャー陣の中でオープンとなるよう、slackのマネージャー陣のチャンネルに投稿をしてもらっています。
部長からのコメントも、スプシ内のコメント機能で行うこともできますが、あえて、slackチャンネル上でコメントをしており、そのやりとりも他のマネージャーが見られるようにしています。(スレッドで返信しつつチャンネルへの投稿もチェックし、他のマネージャーの目に留まりやすくしています。)
必ず、全員の週報に対して、ごく簡単でもコメントをするようにしています。
週単位なので変化量が小さいこともあり、簡素なものになってしまうことも多いですが、それによって、読んでるんだなってことはわかり、/dev/nullに週報を投げ込んでる気持ちにはならないようにしています。
また、前提情報でも触れましたが、自分が専任で100%稼働している部長ではないこと、主務はさらに階層が上となるCTOであることから、マネージャー陣から見て距離を感じやすいと思いますので、存在承認から意識的であった方が良いと思い、コメントすることはその一つになるのではないかと考えています。
コメントの内容は、塩梅も難しく、自分がうまくやれている自信は無いのですが、以下のようなことを考えながらコメントしています。
- 当然、書かれていることについての解像度や、それについて思考した量や試行錯誤はマネージャーの方が圧倒的ですので、かいつまんだ情報でわかった風な余計なアドバイスをしない
- 別途、月次のミーティングがあるので、ちゃんと情報量多くやりとりできるそちらの場で、力になれることがあればやる
- たまに、内容によってはしちゃっている気がしますが、振り返ると、その時は、他のマネージャー陣にも伝えたい考え方だったりもします
- 書かれていることに対して、もう一段深く知りたいことを質問する
- 自分が把握しておきたいのはもちろん、もし、マネージャーもそのことについて詳細に把握していなければ、質問をきっかけに把握してほしい
- 他のマネージャーも知っておくと良いんじゃないかな？と思うことを、質問することで知れる機会にもなる
- 良い行動や良い結果について触れる (まだ不足している気がします)
- 悪い情報についてちゃんと受け取ったことを表明する (まだ不足している気がします)
月報の詳細
これが実際に使っている月報のフォーマットです。
下にもう少し続くのが見切れていますが、また別の取り組みについて月報に合体させている項目なので、記事のわかりやすさ優先で省略しています。
上部のグループダッシュボードというのも同様ですので、この記事の中では触れません。
設計上の観点
週報と同様の観点も多いので、週報との使い分けについて説明しますが、週報の方は、計画の進捗やシステム/チームの状態など、マネージャーに常時意識していてほしいモニタリング寄りの項目となっていて、月報の方は、週次での変化を追うよりも、月次のミーティングでしっかりと議論しておきたい項目となっています。
リスクや課題
週報では、開発プロジェクトや改善施策の進捗観点についてであったり、システムやチームの状態であったりに力点が寄っていますが、ここでは、リスクや課題にフォーカスして、その内容や対策について書きます。
週報の設計観点でも書きましたが、リスクや課題など悪い情報について、できるだけ場に出してマネージャーと部長で共有し、解決策について議論したり、必要に応じて、グループ内に閉じない選択肢を検討したり調整を行えるようにするのが目的です。
継続的なリスクや課題については、翌年度の計画や予算策定時の投資判断にも繋がる情報になります。
メンバーのコンディションと育成状況
メンバー一人一人について、ご本人はどういうキャリアを築きたいと考えているのか、どういうチャレンジをしたいと考えているのか、それを踏まえて、1年後にはどういう活躍を期待したいのか、3年後にはどういう活躍を期待したいのか、そのためには、どういう成長課題があって、そのための機会提供やサポートができているのか、順調なのか、壁にぶつかっていてサポートの仕方を変えた方がよいのか、そういった事の議論が行えるようにするのが目的です。
(弊社では半期ごとに目標/評価があり、そのタイミングでも議論するのですが、その際に正しい議論や判断となるように、日常的な機会としての補強でもあります。)
また、エンジニア組織全体を対象としてCTO/VPoE/部長陣でも、半期ごとの評価タイミングだけでなく、年次で人材育成に特化した議論をし、グループや部を超えた機会提供の検討などをする機会を設けているのですが、その際に正しい議論を行うための土台ともなります。
フォーマット内に育成計画なるファイルがありますが、ここはまだ、ちゃんと仕組み化できておらず、まずは議論できるようにスプシ上に直接記載する形で運用を始めている状態です。
運用上のポイント
目的の②や③のために、週報同様に、slackのマネージャー陣のチャンネルに投稿をしてもらっています。
月報では、slack上でのコメントではなく、月次ミーティングを設けているのですが、あるマネージャーから、他のグループの月次ミーティングの議事録が見られると良いとの指摘をいただいて、目的から考えてそうあるべきなので、そのように運用改善するところです。(ありがとう！)
月次ミーティングについては、まだまだ、良い時間にし切れていないというのが正直な感触なので、具体性が薄い話になってしまいますが、できるだけ、ミーティングの決められた時間の中で、マネージャーが相談したいことをちゃんと相談できたり、双方の観点でちゃんと議論したいポイントを議論できる時間の使い方ができるように改善していきたいと考えています。
おわりに
いかがでしたでしょうか？
まだ、1グループで1ヶ月トライアル運用し、全グループに導入して3ヶ月目くらいですので、マネージャーのみんなの意見も聞きながら、まだまだ改善していくフェーズではありますが、なにかしら参考になる部分があれば幸いです。
ただ、マネジメントレポートの仕組み自体は、初めて試みていることではなく、その時々の組織の特性や状態に応じて、いくらか目的や形は変えながら(使わないという選択含む)、私が間接マネジメントの仕事をするようになった初期から、複数社のキャリアの中で実践している手法ではあったりします。
今でも間接マネジメントの役割でお仕事させていただいているということは、ある程度の再現性はあるのかなとは思います。(全く同じ形ではなくチューニングしているからこそでもありますが)
弊社のように、エンジニア組織だけで複数の部があり、それぞれの部に複数のグループがあって、という組織でCTOやVPoEとして務めるということは、間接マネジメントといっても、階層がさらに多段で求められることも変わってきますので、そちらはまだまだ試行錯誤の日々です。
謝辞
LITALICOのみなさん
今年もたくさんの記事を書いてくれてありがとう！
記事を書くだけではなく、読んだりリアクションをくれたり、色々な形で盛り上げてくれた人たちもありがとう！
そして、この一年もみなさんのおかげで、また一歩も二歩もビジョンの実現へ近づくことができました、ありがとう！自分たちに拍手を！
では、良いクリスマスを！そして、良いお年を！