はじめに
LITALICOの亀田 ( @kamesennin ) です。執行役員VPoEとしてプロダクト開発や組織づくりに携わっています。
2022年のアドベントカレンダーは2記事目です。1記事目は
・ワールドカップとGoogleから学ぶ、多様性と共に磨く、いい雰囲気づくりエンジニアリング
でした。ぜひそちらも読んで頂けると嬉しいです。
2022年を振り返ってみると、2021年までは「自分でもPJやプロダクトを主導して成果を出すこと」が多かったのですが、2022年は「皆さんがより働きやすく、生産性が高まるための地盤づくりで、組織全体の成果を最大化させること」が主要なテーマでした。
その中での学びを本記事でも書きますが、まず前提となる組織の現状を述べて、その後に本題へ入っていきます。
組織の現状
現状（LITALICOの事業/プロダクト）
- LITALICOの事業はかなり多種多様です。障害福祉領域を中心に
- BtoC（障害のある方・ご家族向け）の店舗型の支援やライフプランニングのサービス
- BtoC（障害のある方・ご家族・従事者向け）のメディアやHR系のサービス
- BtoB（福祉事業所・介護事業所向け）のSaaS型のサービス
- BtoB（学校向け）のパッケージ型ソフトウェアサービス
- 自社向けの業務システムサービス
- などなど。プロダクト/システムの視点で見ると、社内/社外合わせて20ほどあります。
現状（LITALICOの組織）
- 社員は3000名以上、2022年12月時点での私が見させて頂いているエンジニア/デザイン/ディレクター組織はパートナー企業の方も合わせて200名ほどに拡大しています。内製型の組織です。
- 他にもPdM（プロダクトマネージャー）やマーケティングやコンテンツ組織も今年1年でぐっと強化されました。今までは「支援のプロフェッショナル」として強みがあるLITALICOから、新たな専門性強化でより大きな成長を目指している状況です。
現状（LITALICOのエンジニア/デザイン組織）
- 採用の状況
- 採用プロセスのDX化で採用力の10Xを成し遂げられそうな話でも少し書きましたが、この2年で特にエンジニア採用の強化に踏み込んできました。2020年3月は約70名、2021年3月は約140名、2023年3月は約200名（見込み）というペースです。
- マネジメントの状況
- 元々はCTO（ @yuyaichihashi ）とVPoE（ @kamesennin ）の2名が主にそれぞれ担当を持ち、双方関わりながら組織を見ていたので、組織状況や困りを個別にそれなりの解像度で認識して（自分たちも手足を動かして）解決することは、100名までは大きな仕組みなく、何とか拡大してきた状態でした。（とはいえ問題解決しきれなかった点は非常に多かったですし、本来は本記事のような仕組みはもっと早めにあるべきだったと反省しています。）
- また人数が増える前に、HR組織をつくり、以下のように「オンボーディング・コミュニケーションの仕組み・評価制度・ドキュメント整備」を進めたことは、浸透具合や運用状況を見てもあって良かったなぁと思っています。（感謝）
発生した課題
- その上でも、人数が一気に増えて、リモートワークも中心で、1人あたり・1プロダクトあたりにコミュニケーションできる時間も減り、「リスクは何か、どんな困りが発生しているか、何から解決出来ると良いか」の解像度が一気に落ちました。組織全体を自分の身体に例えると「健康診断を行っていないからどこの調子が悪いのか、リスクがあるか分からなくなってきた」イメージです。
- 健康診断を行っていないから、何が健康のための問題かも分からない、何をすべきかは当然分からない状態です。このように「組織がどうなっているか、見えなくなってきた」が以前と比べた最大の差分であり、大きな課題と感じました。
背景を踏まえ、何をしてきたか（本記事の本題）
「組織の健康診断」をについて今年は試行錯誤をしてきました。
そこでの学びを本記事ではまとめていきます。
タイトルに「ヘルスチェック」という言葉を使っている理由は「健康診断」+「ITシステムの動作監視」という意味があるため、より今回行いたい内容と合致しているなと考えたためです。
また「三方良し」という言葉は「売り手の都合だけで商いをするのではなく、買い手が心の底から満足し、さらに商いを通じて地域社会の発展や福利の増進に貢献しなければならない。（参考：近江商人 - Wikipedia）」という意味があり、（少し意味は異なりますが）働く人の幸せがあり、良いサービスの創出によるユーザーの幸せ、結果としての社会全体の幸せを作りたい、というLITALICOの理念である「利他・利己」の考えに繋がる好きな日本語なので使っています。
まず何をしたか
「People Analytics」や「組織モニタリング」の事例を調べたり、本を読んだり、社内外の詳しい方に聞いたりしてきました。
その中で組織モニタリングの初心者である私にとっては「ピープル アナリティクス - re:Work - Google」と「ピープルアナリティクスで人事戦略が変わる」が勉強になり、整理の着想となっています。
などなどいろいろ調べながら、以下の順番でヘルスチェックの整備を行いました。
- ヘルスチェックの観点を定める
- どういう視点でヘルスチェックを行うかを考える（目的、観点、モニタリング頻度）
- 取得する/できるデータを調べる
- どういう情報やデータが取れそうかを調べて、考える（可能な取得頻度や項目、取得難易度）
- アウトプットに落とし込む
- 1と2を合わせて、レポーティングするフォーマットとデータを取捨選択を行う
です。
1. ヘルスチェックの観点を定める
根本は、会社のビジョン（障害のない社会をつくる）達成のため、組織をつくり、事業やサービスを開発しています。
エンジニア/デザイン/ディレクター組織は「組織」「サービス開発」の2つの観点が重要として、更に分解し、以下のように整理しました。
2. 取得する/できるデータを調べる
取得すると良さそうなデータ、取得方法/整備状況、取得難易度について一覧で整備を行いました。
データが本当に集められるか、まず集めてみました、その時に意識した点は以下です。
- 既にあるものは関係組織のリーダー陣に連絡して、抽出の依頼をすること
- 100%完璧なものを求めず、組織の現運用の自然な流れの中で無理なく取れるものにすること
- 集計して頂く、データを省く、などはせずに出来るだけローデータが集まるようにすること
- 何を集めるべきか/集められるかの自分の解像度がまだ低く、散らばっているものを集める話なので、データのあり方や観点や他の可能性を網羅的に思いつくために、自分一人で集約する場所や方法を定めること
他、データの扱い時に注意した点は以下です。
- （当然だが）機微な情報もあるので、データの権限管理に注意すること
- （ほぼ無いが）仮に集計結果を公開する場合は、情報を出来るだけ抽象化をすること
- 一方、課題解決が適切に行えるよう、限られた人員は情報と向き合い、分析や判断をすること
- 適切に判断が出来るよう、レポートの場所やフォーマットの整備・運用にこだわること
その他補足
- いろんな場所からデータを集める必要がありますが、特定のspreadsheetに各所から手に入るローデータを集めてETLのような場所を作りました。ツールが散っている場合（がほとんどかと思いますが）は結局これが一番かなと思っています。
- 「各PJ管理シート」は各プロダクトごとのPJ管理する場所（backlog、spreadsheet、Github）を参考に、一番は各担当マネージャーから、その上長がヒアリングを行うことでの主観的モニタリングが中心になっています。不確実性やの高い情報なので、これが一番確実で精度高い情報が集まるかなと判断をしています。
- システムメトリクスや障害票やお問い合わせ票などはローデータとして持ってくるというより、各ログを見てどういうリスクや状況であるかをレポーティング、示唆としてまとめたものを引っ張ってきているというイメージです。（閲覧者の主観で歪みは生じうるので、ここはもっと良くしたい）
3. アウトプットの作成
目的
- エンジニア/デザイン/ディレクター組織が直接関わる個別プロダクト/PJ/組織の、主に進捗と問題点を、出来るだけタイムリーかつ具体に理解すること
主要なフォーマット
フォーマットの中身を解説
基本情報
- 担当部門/エンジニア/PdM（誰が担当か）
- プロダクト/PJ名（チーム名はなにか）
- ミッション（何がミッションか）
- 重要資料/主要会議体（PJの重要な資料や会議体へのリンク）
- マイルストーン（年単位でのマイルストーン）
モニタリングの観点（1. ヘルスチェックの観点を定めるで定めたもの）
- ①サービス開発（①-1.PJの進捗 + ①-2.エラー/トラブル）
- ②組織状況（②-1.組織状況+ ②-2採用）
各観点の評価
- 3段階評価
- ☀：大きな問題なく、順調に進んでいる状態
- ☁：若干の懸念有りだが、巻き返しの見込みあり
- ☂：課題強め、大幅遅れ等リスクが顕在化
- フリーコメント
- ☀、☁、☂に関しての補足コメント
モニタリングの頻度とメンバー
- 頻度：週次で各項目ごとにモニタリング結果を記載して、個別確認をする（大体15-30分）
- メンバー：エンジニア/デザイナー部門の担当役員（CTO,VPoE） + 項目ごとにHR組織担当/部門全体のミッションを持つ担当などで分けている
モニタリングのポイント
- 本モニタリングは良い点も含めて状況の細かな把握、個々人の様子にまで踏み込んだ議論、具体的な課題の深堀りや分析、打ち手の議論が中心です。
- ☀☁☂とセットで書くフリーコメントの書き方は、各粒度は「大きな問題なし」「◯◯の観点で遅れるリスクあり」「◯◯の障害があり、対策検討中」「リリース前が迫ってきて、◯◯が残タスク」「◯◯との連携にやや課題あり、具体は◯◯という点」「問い合わせで◯◯が増えてきた」「パフォーマンスが◯◯くらい劣化」のような粒度です
- 「システムの品質やプロジェクトの進行状況や組織の課題感」への解像度は、直接マネジメントしている人員でモニタリングは出来るようにしています。
- 開発PJや組織状況の遅れやリスクは週次で先んじて把握して手を打つことが重要と考えています。隔週では一回見逃したり手を誤ると結局1ヶ月の遅れとなる。週次のモニタリングなら1回の見逃しやミスもカバー出来ることで、月次では全体が良好に進みやすくなるからです。
その他集めているデータで参考情報としているもの
以下は、モニタリングを進める中での客観的かつ多面的な参考情報や補足情報として集計し、見るようにしています。
労働時間、残業時間、リモート率
アンケート結果
パーソナル情報
番外編. 全社視点のプロダクト/PJのヘルスチェック
背景
上記はエンジニア/デザイン/ディレクター組織に絞って管理しているものです。その上で、プロダクト組織（エンジニア、デザイナー、PdM、マーケター、コンテンツ）全体で結局は「事業-プロダクト-組織」は一貫して見える化していきたいよねという話を管掌取締役として、それはそうと思い、やや集約難易度は上がりますが、広げて整備もしています。
そちらは出来たばかりでありますが、せっかくなので簡単にご紹介。
目的
- 全社で走っているプロダクト/PJを網羅的に確認、特にリスクや課題対策についてを改めて確認する機会を持つことで、総合的な状況の確認と組織横断の問題解決をトップマネジメントの視点から行えるようにする
- また、報告する義務により、自然と月次で論点が整理され、対策を打つ良いプレッシャーにもなり、前に進みやすいメリットもあると思っています
フォーマット
※実際に経営陣内の議論で使っているフォーマットです。
※上記「3. アウトプットの作成」をベースに整理しているので似ています。
フォーマットの中身
前提情報
- モニタリングしたい各PJを立てに並べ、各PJごとにミッションやマイルストーンを記載すること
- これを基準として順調か順調でないかなどを皆でモニタリングすること
基本情報（フォーマットの左半分）
- サービス・プロダクト（どのPJに関する情報か）
- ミッション/目標（何がミッションか）
- 観点（モニタリングすべき観点を主要PJのマイルストーンと評価観点の2つを入れる）
- マイルストーン/報告概要（年単位でのマイルストーン、過去の年月での☀☁☂の実績※自動反映）
モニタリングの観点
- 方針
- 上記エンジニア/デザイン/ディレクター組織用の項目 + マーケ/コンテンツが大項目として追加
- 各項目はシステム観点からよりプロダクト観点に広げて記載をする
- 中身
- 1.PJの進捗
- 2.組織状況
- 3.採用
- 4.エラー/トラブル
- 5.マーケ
- 6.コンテンツ
各観点の評価
- 1.3段階評価
- ☀：大きな問題なく、順調に進んでいる状態
- ☁：若干の懸念有りだが、巻き返しの見込みあり
- ☂：課題強め、大幅遅れ等リスクが顕在化
- 2.フリーコメント
- ☀、☁、☂に関しての補足コメント
モニタリングの頻度とメンバー
- 頻度：月次で各項目ごとにモニタリング結果を記載して、個別確認をする（大体15-30分）
- メンバー：プロダクト系の役員（COO、CPO、CMO、CQO、CTO、VPoE）
モニタリングのポイント
- フォーマットは自分が手探りで作りながらなので拙い部分は多いですが、フィードバック受けながら、毎月少しずつアップデートしています。「1つのシートであらゆる情報が一覧が見えること」「毎月のスポットの状況だけでなく、月次での変化が毎月追えること」の2点は意識して作っています。
- 特にPJ数は多いので、全部を毎月丁寧に書いたり見たりするよりは、「大きなリリース前後のもの」「3段階評価が良くないもの/特にリスクが高いもの」に関する「具体の課題と対策状況」の共有がメインと今はしています。
まとめ
上記をまとめると、以下のようなフローです。
運用する中での気付きや学び、今後したいこと
気付きや学び
- 私は10年ほど今の会社にいます。だからこそ分かる、各種情報へのアクセス方法、立場上得られているアクセスの権限は本整理が進めやすかった大きなポイントだと思っています。そうでもない場合にどう進めるかはあまり具体の回答はないかもしれません。権限と情報を作成する人（組織）にどう集約するかは重要になりそうです。
- LITALICOは事業/プロダクトの多種多様性が高く（20近い）、モニタリング時には多少の複雑性が発生するなと思いながら、今回の整理もその前提があることはかなり重要、他で活かす場合にはまた細かさや粒度は異なるなと感じました。
- 全社視点のプロダクト/PJのヘルスチェックでは、どこまで報告して、どういうリスクや観点を共有していけば良さそうかは、まだそんな回数を重ねていないので、アップデートの余地は特にありそうです。運用し、フィードバック頂きながら、改善していきたいと思います。
- 仮に人数やプロダクト規模が2倍、3倍になった時に同様の解像度や品質で運用が成り立つかでいうと、自信をもってyesといえませんが、規模ごとにどういう差分や課題が発生したかは、やりながら知見を貯めて、また発信したいです。
今後したいこと
- システムメトリクス観点
- SREチームがいますので、各PJごとには程度の差はあれどモニタリングはされています（感謝）
- 今後はより全社共通で見える観点整備はPJごとに異なる部分もあるかと思うので、標準化をどう進めるかは私も考えていきたい
- サーバーのキャパシティ、MTTR、MTBFなどなど
- 障害/問い合わせ票観点
- QAチームを中心に、障害票は整理されてきています。（感謝）
- チームによってはお客様からの問い合わせ票も分析できるように整備されている所はあります。（感謝）
- ただし視点の抜け漏れないように、リスクが丁寧に把握出来るようにアップデートしていきたいです
- 生産性観点
- 修正したバグの数、closeされたissueの数、リリース頻度など、などベロシティ等を測る方法や指針はいろんな所でみます、弊社でどこまで見るべきからか踏まえて議論はしておきたいです
- 売上や利益など、事業全体の成果との接続観点
- 事業成果とサービス開発の成果の関係性が正しく紐付いているかまで見れると一番良いと思っているが、本当に良いのかの検討も含めて、挑戦してみたい所です。
最後に
本記事では「現状把握」に特化した整理をしましたが、LITALICOでは各みなさんのリーダーシップによって以下のようなオンボーディングや1on1やチームビルディングやコミュニケーションの機会創出にも取り組んでいます。
- 1年で人数が倍になったエンジニアグループのオンボーディングの紹介
- 中途入社のチームオンボーディング設計まとめ（3ヶ月連続受け入れを通して）
- エンジニア&デザイナー100人組織の「全体会」がうまくいくために人事がやったこと
- リモート下でもチームメンバーのことを知れるようカジュアルな1on1を設けている話
- 成功できる組織にする為、考えた5つの取り組み(チームビルディング)
こういった1つ1つの実際の対策が組織をよくするため、日々の皆さんの努力が今の組織を作っていると改めて感じます。
今のLITALICOは、離職率という観点ではそこまで多くないのですが、働きづらさはまだまだあると実感しており、離職観点でも会社への不安や不信感ややりづらさがあって辞められてしまう方は一人も出したくないです（もちろん次への挑戦は応援したいです）。今まで退職されることになってしまった方々への謝罪の気持ちを強く持ち、LITALICOへ入ってきて下さった皆さんの期待や覚悟を裏切ることないように、より一層の努力に励みます。
また、健康診断と同じようにヘルスチェックだけしても、改善活動が行われなければ前には進みません。次は改善施策に関する取り組みに、よりフォーカスしていきます。また、感性や経験則なだけでなく、たとえば心理学などを用いた、科学的、統計的なアプローチにも挑戦したいです。
それでは、長くなりましたが、2022年もLITALICOをありがとうございました。
このような組織づくりやプロダクト開発を共に行って下さる方々を募集していますので、気になったら、ぜひお気軽にご連絡ください。（私のTwitterアカウント：@ka_me_sen_nin）
そして、来年もLITALICO一同をみなさまよろしくお願いいたします。