Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】My Monthly 1:1 Formula: 4 Health Checks + PM Feedback

2025年10月02日に「Dev.to」が公開したITニュース「My Monthly 1:1 Formula: 4 Health Checks + PM Feedback」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

エンジニアの健全な働き方を支援するため、週次の簡易チェックと他者評価、マネージャーの観察を組み合わせる1on1の仕組みが紹介されている。これにより、表面では見えないメンバーの隠れた課題を早期に発見し、具体的な対策を講じることが可能になる。チーム全体の透明性と成長を促す。

ITニュース解説

従来のIT業界におけるマネージャーとエンジニアの1on1ミーティングは、しばしば表面的な状況報告に終始し、根本的な問題を見過ごすことが多かった。たとえば、「調子はどうですか?」と尋ねれば「順調です、スプリントの作業を進めています」といった返答で、その週に起きた緊急の事柄に30分を費やし、数ヶ月後に爆発するような潜在的な問題には全く気づけないといった経験は多くの人が共有する課題である。マネージャーは断片的な情報に基づいて意思決定を行い、数週間から数ヶ月にわたるパターンを見落とし、エンジニアが限界に達したときに初めて驚かされるという状況に陥りがちだった。このような問題意識から、マネージャーはエンジニアとのより深い対話を実現するための新しいシステムを構築した。

このシステムは「月例1on1の公式」として体系化された。まず、毎週金曜日に、各エンジニアはわずか2分で完了するヘルスチェックシートに記入する。このシートには、完了したコードレビューの数とその複雑さ、予定されている会議と非予定の会議の合計時間、集中作業の中断回数を示すコンテキストスイッチの発生状況、そして1から10までの数値で示すエネルギーレベルが含まれる。さらに、「何か共有したいことはありますか?」という自由記述形式の質問が設けられている。そして、毎月の1on1ミーティングの前に、マネージャーはこれらの週次ヘルスチェック4回分、担当プロダクトマネージャー(PM)からのフィードバック、そして自身のエンジニアに対する観察結果を統合して準備を行う。この事前の準備こそが、通常では見えない隠れた情報を明らかにする鍵となるのだ。

このシステムが実際に機能する理由は、情報の多角的な収集と分析にある。多くの場合、エンジニアの自己評価、PMのフィードバック、マネージャーの観察は一致し、その結果、1on1はエンジニアの成長やキャリア開発といった前向きな話題に集中できる。しかし、約20%のケースでは、これらの情報源の間に不一致が生じる。この不一致こそが、事態を根本的に変える「発見」の兆候となる。つまり、データ間の矛盾は問題そのものではなく、より深い調査が必要であるという貴重な情報源となるのである。

具体的な事例を通じて、このシステムの有効性が示されている。例えば、あるエンジニアのケースでは、PMからのフィードバックは「納期通りに成果を出し、優れたコミュニケーション能力を持ち、積極的に問題を解決する」と非常に高評価だった。しかし、彼が毎週記入するヘルスチェックシートは、過去4週間にわたってエネルギーレベルが8から5へと徐々に低下し、会議時間が増加し、自由記述の回答が短くなっていることを示していた。このPM評価と自己評価の不一致に気づいたマネージャーは、パフォーマンスを称賛する代わりに、彼の持続可能性について話し合った。結果として、彼は密かに苦戦しているチームメイトの仕事をカバーしており、燃え尽き症候群になる前に問題が解決された。また別のケースでは、エンジニアのヘルスチェック自体に異常はなかったが、PMから納品遅延の指摘があった。この不一致から詳細を調査すると、自由記述の回答に「説明待ち」や「手戻り」といった言及が繰り返し現れていた。1on1での対話を通じて、開発途中で頻繁に要件が変更されるというシステム的なプロセス問題が明らかになり、個人を責めるのではなく、組織のプロセスを改善する方向に話が進んだ。

これらの事例から得られる重要な洞察は、フィードバックは「真実」そのものではなく、「さらなる調査を促すマーカー」であるという点だ。パターンが一致しない場合、それは問題ではなく、むしろ非常に価値のある情報源とみなされる。なぜなら、PMは納期や成果といった側面から、エンジニアは技術的負債やプロセス上の摩擦といった側面から、そしてマネージャーはチーム全体のダイナミクスといった側面から、それぞれ異なる「真実」を見ているからである。これら全ての視点は重要であり、これらの情報間の不整合こそが、本質的な会話を引き出すきっかけとなるのだ。

このシステムを運用する中で、マネージャーはいくつかのパターンを読み解くスキルを身につけた。まず、早期警戒サインとして、PMからの高い評価にもかかわらずエネルギーレベルが徐々に低下し、自由記述の回答が短くなるようなパターンは燃え尽き症候群の兆候と判断できる。また、PM評価は高いままであっても、ヘルスチェックの回答が次第に抽象的になり、仕事への情熱が薄れているような場合は、エンゲージメントの低下を示唆する。コンテキストスイッチが増加しているにもかかわらずエネルギーレベルは安定している、あるいは「リファクタリング」や「クリーンアップ」といった記述が増える場合は、技術的負債に対するフラストレーションが蓄積している可能性が高い。次に、システムレベルの問題としては、複数のエンジニアが「設計待ち」「要件不明瞭」「会議が多すぎる」といった共通のテーマに言及している場合は、プロセス上の問題が潜んでいると判断できる。特定のエンジニアのコンテキストスイッチが急増している一方で他のメンバーは安定している場合、知識のサイロ化を示唆することがあり、チーム全体のエネルギーレベルが同じ方向に推移している場合は、組織全体の課題を反映している可能性もある。さらに、複数のエンジニアにおいてPMのフィードバックと自己評価の間に一貫した不一致が見られる場合、それはコミュニケーションギャップが存在しているサインである。

このような情報収集とパターン認識により、マネージャーの1on1は単なる状況報告の場から、より戦略的な会話の場へと変貌を遂げた。マネージャーは1on1に臨む前に、その月にどのようなパターンが現れたのか、なぜ異なる視点が存在するのか、どのトピックを深く掘り下げるべきなのかを事前に把握している。「調子はどうですか?」といった漠然とした質問ではなく、事前に得た情報に基づいた具体的な議論が可能になるのだ。特に、「何か共有したいことはありますか?」という自由記述の質問は、エンジニアの心の内にある真の洞察を引き出す「魔法の質問」となった。「3時間かけてデバッグしたが、本来なら文書化されているべきだった」「新入社員のメンターができて楽しかった」「不安定な基盤の上に構築し続けることに不満を感じる」「プロダクトのビジョンから隔絶感がある」といった、深層にある感情や課題、貢献意識が明かされるようになった。数ヶ月間一貫してこのシステムを運用することで、エンジニアはマネージャーが自分の発言に真剣に耳を傾け、パターンに注意を払っていると信頼するようになり、より正直で深い共有ができるようになったのだ。

このシステムを導入する際、過度に考えすぎずに始めることが推奨される。最初の1~2週間は、このシステムの目的が監視ではなく、より良い1on1を実現することだとエンジニアに説明し、そのコンセプトを紹介する。3~4週間目には、毎週同じ曜日に同じシンプルな質問を用いて一貫したルーチンを確立し、信頼を築く。1ヶ月目からは、週次のヘルスチェックとPMフィードバックを組み合わせ始め、個々のデータポイントではなく、全体的な傾向(トレンド)を探すことに集中する。2~3ヶ月目には、学んだことに基づいてシステムを洗練させ、状況に合わせて進化させる柔軟性が重要である。いくつかの落とし穴を避けるべきだ。例えば、このデータを個人のパフォーマンス監視ツールとして利用しないこと、単一のデータポイントだけで判断を下さないこと、システムを過度に複雑にしないこと、そして得られた洞察に基づいて行動した際に、その結果をエンジニアにフィードバックする(クローズドループを忘れない)ことである。

このシステムは、チーム内のコミュニケーションのあり方にも大きな変化をもたらした。エンジニアは、マネージャーが彼らのパターンに注意を払っていることを理解したため、状況や懸念事項をより積極的に共有するようになった。他のマネージャーも同様のアプローチを採用し始め、結果としてエンジニアリング組織全体で、ワークロードやウェルビーイングに関する透明性が、シンプルで一貫したデータ収集を通じて向上した。プロダクトマネージャーとの連携も劇的に改善された。エンジニアの様子がなぜかおかしいと感じた時に、単なる憶測で議論するのではなく、具体的なデータに基づいて対話ができるようになったためだ。

チームの真の現実は、速度チャートやスプリントレポートといった数値データだけでは把握できない。それは、測定された情報と、エンジニアが「感じていること」との間のギャップに存在している。このシステムは、「毎週のヘルスチェック」と「PMからのフィードバック」、そしてそれらから得られる「パターン認識」を組み合わせることで、「準備された1on1」を実現する。その仕組み自体はシンプルだが、その影響は計り知れない。エンジニアが、マネージャーが個々の問題だけでなく、自分たちの状況の全体的なパターンに目を向けていると知った時、彼らはこれまでとは異なる方法で、より深く、より早く、より正直に情報を共有するようになるだろう。

このシステムは、提案された公式をそのままコピーすることが目的ではない。それは、自分のチームの現実の中に隠されたパターンを見出すための「場」を創造することに本質がある。チームによっては質問内容が異なるかもしれないし、複数のデータソースを組み合わせることも可能だろう。あるいは、隔週で実施するなどの調整も考えられる。具体的な実施方法は、その一貫性と意図こそが重要であり、細部はそれほど重要ではない。システムエンジニアを目指す初心者にとっても、このようにデータに基づいて課題を特定し、人間中心のアプローチで解決策を探る姿勢は、将来のキャリアにおいて非常に役立つ視点となるだろう。組織の課題は複雑であり、多角的な視点から情報収集を行い、パターンを分析する能力は、優れたシステムを構築する上でも不可欠なスキルだからだ。最終的に問われるのは、自分自身のチームの現実にどのようなパターンを見出すための空間を創造するか、という問いである。

関連コンテンツ

関連IT用語