私自身、普段はプロダクト開発チームのEMとして、事業戦略から落とし込まれた機能開発や、デリバリー最大化のための組織ケイパビリティの維持・拡張に向き合っています。一方で、それと同時に「DevEnable室」というチームのマネージャーも兼務しています。ここは組織運営・広報・オンボーディング・活性化・発信文化醸成など、プロダクト開発以外の「組織を強くするためのあらゆる業務」を一手に引き受ける、いわば「Engineering Office」機能を持つチームです。

ある時は「ものづくり組織やメンバーの成長」を考える帽子を被り、またある時は「イベントの企画・会場手配」や「オペレーション構築」に奔走する。そんな、職種の壁さえも飛び越えるようなコンテキストスイッチが日常的に発生している状態です。

また、そういった状況下で、向き合う課題はどれも重要であるとわかりつつもタスクに追われる中で「自分の専門性は何だっけ？」「この先どういったキャリアになっていくのだろう」といった不安感を抱くこともまた、よくある話です。

この記事では、その経験を「目先の課題を撃ち落とすだけのなんでも屋」で終わらせず、「普遍的なマネジメントの型」として再利用可能な資産に変えるための思考と実践を共有します。

具体的な施策を紹介しますが、それらを支える最も重要な要素は「現状診断とそのための観察」と「馴染みのある型への翻訳」です。

🏥 Phase 1：【診断】最初の2ヶ月はメンバーと一緒に、振る舞いに徹して解像度を高めた

前任者からの引き継ぎを受け、チームへ参画してからの約2ヶ月間、私はあえて「マネジメントの裁量」を行使しない期間を設け、メンバーと共に課題に向き合いました。

着任直後、マネージャーの目には「チーム内にある課題らしきもの」や、「自身の経験上『こうあるべき』と考えるものの、そうなっていない事象」が次々と飛び込んできます。特に「やったるぞ！」と息巻いている時ほど、それらが今すぐ解決すべき「障害」に見えてしまうものです。

しかし、着任直後の私は、チームが積み上げてきた文脈を知らず、専門外の領域（採用や広報、バックオフィス）のドメイン知識もありません。

特にDevEnable室は、ものづくりをするチームとは異なり、社内のあらゆる部署から「あれやって」「これお願い」「助けて！」と、種類の異なる依頼がランダムに飛んできます。先ほど記載したもの以外にも、イベントの登壇調整、入社者のオンボーディング、社内表彰イベントの運営、制度運営など…。一つひとつのタスクの裏側には、採用人事、広報、経営陣、そして現場のエンジニアといった「異なるステークホルダーの期待」が複雑に絡み合っています。

これらが見えていない状態での「こうあるべき」の押し付けは、現場の実情と乖離し、メンバーを混乱させるだけです。最悪の場合、一見非効率に見えても実はうまくいっている「重要なプロセス」を壊してしまう可能性すらあります。

既にあるものを変えることは、メンバーにとってコストがかかります。その痛みを伴う変化の先にある結果が効果的でなかった場合、あるいは状況を悪化させた場合、信頼残高はマイナスになり目も当てられません。

まずは、チームが担う業務とその成果、周囲やステークホルダーからの期待値、そしてチームとメンバーの現状を観察・診断すべきだと考えました。診断期間は、自身の持つ「文脈の量」や「専門知識量」に鑑みて設定するのが良いですが、組成から時間が経っているチームや、業務の幅が広いチームほど、十分な期間が必要だと考えます。

着任直後は「すぐに変化を起こして成果を出したい」という焦りが生まれますが、そこをグッと堪えて、まずは現状に向き合いましょう。

🔎具体的にやったこと

チームが運営する全ての会議体に参加する一番のへたくそとして参加しているため、業務遂行のために初歩的なことからたくさん質問することになりますが、恥を捨てて聞きまくりました。

チームの向き合う業務、タスクに自分も取り組むイベント運営、設営、事務手続き、制度運営など、メンバーと同じタスクをこなしました。一番のへたくそとして入っていますので、たくさん質問することになりますが、それが大事だと考えています（大事なことなので2回言いました）。

上記に加え、1on1や資料を読み漁り、情報収集を進めました。

これらは、チームが抱える「痛み（Toil）」を自分の肌感覚としてインストールするための、最も手っ取り早く確実な手段でした。期間だけを見れば遠回りに見えますが、前述の通り「精度の低い変化」は悪影響の方が大きいのです。

エンジニアリングにおいては、「推測による最適化は諸悪の根源（Premature Optimization is the root of all evil）」という言葉があります。（Donald Knuthの言葉として有名ですね）これは一般にパフォーマンスチューニングの話として語られますが、私はこれを「計測なき変更への戒め」として捉えています。

着任直後のマネージャーが陥りがちな「良かれと思った改革」は、往々にしてこの「計測なき変更」になりがちです。どこに真のボトルネックがあるのか、肌感覚というログも取れていない状態で仕組みを変えようとするのは、システムを壊すのと同義です。

だからこそ、最初の2ヶ月は徹底的に「組織の観察・診断」に徹しました。

💡見えてきた課題の「真因」

実際に上記の取り組みを進めて観察することで、「なぜ属人化するのか」「傍目から見えていた様々な事象がなぜ起きているのか」の解像度が上がりました。

そこで判明したのは、チームには「仕組みがない」のではなく、「個人の高いプロフェッショナル性（得意領域＋責任感）」によって、業務品質が支えられているという実態でした。

しかし、これは「それゆえに特定のメンバーへの依存度が高く、単一障害点（以下、SPOF）が生じている状態」でもありました。

💊 Phase 2：【処方】課題をエンジニアリングの課題に「翻訳」する

これまでの観察と診断を通じて、手元には大量の「肌感覚ログ」と「SPOFのリスク」という事実を携えることができました。

期間内に手触り感を得ていく中で、課題だと思われるものも、すぐに「SPOF解消だ！自動化だ！」とはしませんでした。なぜなら、その「属人性」の中には、チームの強みである「ホスピタリティ」や「柔軟性」が含まれており、「守るもの」と「攻める（変える）もの」としての選別が必要でした。

🛡️ 【守り】「守るもの」と「攻める（変える）もの」を選別する：チェスタトンのフェンス

💡

一見不要に見えるルールや慣習であっても、それが作られた「理由」を理解するまでは変えてはいけない、という原則です。「無駄だから消す」のではなく、「なぜ設置されたか」を解明することが、改革の第一歩であると説いています。

一見非効率に見える手作業や承認フローも、深く潜っていくことで「私たちを頼る方々へのUXの担保」や「スピード感を持って進める工夫」といった設置理由が見えてきました。これらは「無駄」ではなく「必要なコスト」として、あえて「変えない」「残す」という判断をしています。

一方で、上記に寄与しない、明らかに構造的な欠陥（SPOFやToil）については、解決が必要です。ここから「自分の持たない専門知識」で戦おうとせず、「エンジニアリングの課題」として『翻訳』をします。

事象をシステムの問題として捉え直せば、我々EMには「解決の型（パターン）」が既にあると考えます。

⚔️ 【攻め】課題と解決の翻訳テーブル

明らかに構造的なのびしろによって疲弊している部分もありました。私はこれらを「専門領域外の課題」として捉えるのではなく、「システムの課題」として捉え直し、エンジニアリングの概念に「翻訳」しました。これまでの「ものづくり」で使っている「解決の型」がそのまま適用できます。

実際に私が頭の中で行っていた翻訳、課題と型の対応表です。

💥 現場で起きているつらい事象	🔄 エンジニアリングへの翻訳	🛠 適用可能な解決の型
誰かが休むと業務が止まる詳細がわからない	SPOF 特定ノードダウンによるシステム停止	冗長化構成大きな関心ごと単位での複数担当制の導入
誰かしか知らない手順がある秘伝のタレ化	バス係数の低さ / 属人化ドキュメント不足によるブラックボックス化	ナレッジの分散ペアワークやローテーションによる共有
毎回、手作業でコピペや転記をしており、つらい。ミスも起きる。	所謂Toil CI/CD未整備、手動オペレーションによるスケーラビリティののびしろ	自動化 / テンプレート化スクリプトやSaaS連携による省力化
完了基準が人によって違う「ここまででいいよね？」のズレ	完了の定義の未策定仕様と受け入れ条件が未定義	受け入れ基準の明記期待値の言語化と合意
「おもてなし」の基準が曖昧個人の価値観に依存する	暗黙知への過度な依存非機能要件（品質基準）の未定義	Values / 判断軸の明文化「良し悪し」のコード化（言語化）
あれもこれも着手してパンク全部大事に見えてしまう	WIP（仕掛かり）制限の超過コンテキストスイッチによるスループット低下	スクラム / カンバンの導入計画とWIP制限によるフォーカス
個人の判断で優先度がバラバラ本質的な積み上げが後回しになる	局所最適の罠全体最適の視点や、優先度判断ののびしろ	プロダクトオーナー（以下、PO）制意思決定者の明確化と責任の集約

たとえば、皆で運営しているイベントも、「イベントの手順はAさんじゃないと分からない」「毎月の手続きはBさんにDMでこっそり聞くしかない」といった、「この人が休むと業務が止まる」という個人の頑張りに依存した状態が生まれていました。これを単なる「属人化」ではなく、「SPOFのリスクが高く、ログも追えないブラックボックスな状態」と捉えるようにしています。そこで、まずは「ドキュメント化」と「やりとり（ログ）の透明化」を徹底し、依存関係を可視化しました。現在チームはその土台の上で、あえて主担当者以外のメンバーが手順書をベースに業務を完遂できるかテストし、冗長化に向けてトライ＆エラーを回している最中です。あれ、なんだか「フェイルオーバー訓練」っぽいですよね？

🧶 共通言語を作り、「つよみ」を資産にする

ちなみに私たちDevEnable室には、エンジニアリングの文脈に馴染みのないメンバーもいます。そのため、スクラムの導入ひいては上記の型においても専門用語をそのまま使うのではなく、全員が腹落ちする言葉への「翻訳」を大切にしています。（e.g. スクラム導入の文脈では、吉羽さんのこちらの記事を参考にして、チームへの説明や決め事に反映しています。）

私が生み出そうとしている変化は、チームが持っているホスピタリティや柔軟さを否定したいわけではありません。むしろ、その逆です。

ものづくり的な捉え方や型を通して、チームの持つ「優しさ」や「柔軟さ」を、一時的なものではなく、永続的な価値にレベルアップしていきたいと考えます。

個人の頑張りに依存するのではなく、誰かが倒れても揺るがない「つよい組織」へと昇華させたい。既に個々が発揮する素晴らしいホスピタリティを、これからもずっとチームの資産にしていくために、この仕組みを提案しました。

🙋 自分自身がPOとして振る舞うということ

上記の表の中で、特に意識的に取り組んだのが一番下の項目、すなわち「行き過ぎた局所最適化からの脱却」です。

DevEnable室のような「なんでも屋」チームには、プロダクト開発のような明確な「ロードマップ」が存在しにくい傾向があります。そのため、メンバーは社内からの「緊急度が高い（ように見える）依頼」に振り回されがちでした。

また、メンバーの自律性は尊いものですが、個々人の判断に委ねすぎると、どうしても「やりやすい業務」や「短期的な成果」が優先され、「重要だが緊急ではない本質的なのびしろ」に向き合うことが後回しにされがちです。

私はここまでの観察・診断を通してDevEnable室におけるPOとして振る舞うことを決めました。具体的には、バックログ（チーム内では「やることリスト」と呼んでいます）の優先順位決定権を私に集約し、「今、チームとして最もレバレッジが効く活動は何か」を全体最適の視点で判断するようにしました。

これにより、これまで手がつけられていなかった「技術的負債の返済」や「将来のための仕組み化」といった、チームののびしろに対して、意図的にリソースを投資できるようになりました。意思決定を集約することは、管理強化のためではなく、チームの成果を最大化（レバレッジ）するための戦略なのです。

📍 Phase 3：【兆し】「のびしろ」への投資は始まったばかり

Phase 2の取り組み（翻訳とPO制の導入）を始めて、まだ1〜2ヶ月です。正直に言えば、まだ現場はバタついていますし、「課題解決！」と胸を張れる状態ではありません。しかし、これまでの「個人の力でなんとかねじ伏せていた状態」から、「集合知を活かし、持続可能な仕組みで価値を生み出す組織」へと、確かな変化の音が聞こえ始めています。

「誰かにしかできなかった業務」は着実に対応できるメンバーが増え、組織的な判断をする場面も増えてきています

🌀 属人化からの脱却と、業務ローテーション

ペアワークやドキュメント化への着手により、特定のメンバーに依存していた定常業務の標準化が進みました。「Aさんしかできなかった業務」をBさんやCさんが担当する「業務ローテーション」が、実際に回り始めています。「自分が休んだらどうしよう」という個人の孤独な不安は、「チームでどうカバーするか」という建設的な作戦会議へと変わりつつあります。

🧠 「個人の戦い」から「Collective Intelligence（集合知）」へ

以前は、それぞれの専門領域で孤独に課題へ向き合う「個人の戦い」でした。現在はペアワークやモブワークを取り入れ、一人で抱え込まずに、チームの「集合知」としてソリューションを導き出しています。これは業務品質の向上だけでなく、特定メンバーへの負荷集中の防波堤としても機能し始めています。

📈 「改善」の速度が変わった

POとして意思決定を集約し、局所最適化を止めたことで、チームにわずかな「余白」が生まれました。その変化は「ふりかえり」の場で顕著に現れています。お気持ちの共有に終始しがちだった場から、未来に向けたネクストアクションの量が増えています。

数ヶ月前とは違い、私たちは今、自分たちの意志で変化をし始めています。

🏁 おわりに：専門領域外の経験は「キャリアの寄り道」か？

EMが、採用や広報、バックオフィスといった専門外の領域を任される時。ふと「これはキャリアの寄り道ではないか？」「技術から離れてしまっていないか？」と不安になることもあるかもしれません。

しかし私は、今回のDevEnable室での実践を通じて、少しずつ手応えを感じています。 EMで積み上げてきた「型」は、ものづくりの外側でも通用する普遍的かつ強力な経験です。

徹底的な観察と診断で現状を正しく把握し

チェスタトンのフェンスで守るべき価値を見極め

翻訳により課題を構造化し

レバレッジの効く打ち手を置く

このプロセスは、対象がシステムであれ組織であれ、変わらずに機能します。

もし今、「なんでも屋」のような状況に置かれ、専門性の迷子になっているEMの方がいれば、ぜひ目の前の忙しさや業務を「未開拓のシステム」と捉え直してみてください。そこには必ず、あなたのエンジニアリングのアプローチで解決できる「のびしろ」が眠っています。

そののびしろを開拓した経験は、あなたの背中を支える「汎用的なマネジメントの資産」になるかも？と思っています。

🤝 We are hiring!!

事業とものづくりはもちろん、組織的な関心事にもしっかり向き合う環境です！そんなタイミーにご興味があればぜひお話ししましょう！🗣️

株式会社タイミー | プロダクト採用サイト

株式会社タイミーのプロダクト採用についてご案内しています。エンジニア職、デザイナー職などの募集情報はこちら。

https://product-recruit.timee.co.jp/

カジュアル面談申込はこちら