Tag
2026年3月16日に開催される「EMが「推し本」を語る会 ーEMConf JP 2026 非公式サブイベント」のLT登壇枠（5分）で話す機会があるので、まだ前日だけど、自分にとっての「推し本」について、このブログでも紹介してみる。 EMが「推し本」を語る会 ーEMConf JP 2026 非公式サブイベント (2026/03/16 19:00〜)## 📚 EMが「推し本」を語る会 - EMConf JP 2026 非公式サブイベント ### 「推し本」を持ち寄って、EMに関する悩みや葛藤、実践知・学びなどをしっぽりと語り合いましょう！ EMConf JP 2026の熱量そのままに、さらに深
たまたま見かけた、以下の DACI に関する記事を眺めていて、これまでの人生で何度か見てきた「チームの意思決定が進まない」光景を思い出した。 DACI：意思決定フレームワーク | Atlassian Team Playbookこの DACI テンプレートを使用して、チームの各メンバーに役割と責任を割り当て、意思決定をより効率的かつ効果的に行ってください。AtlassianAtlassian 経験上、チームの意思決定がなかなか進まない時には、以下のようなことが起きていることが多かった。 * 「チームワークを高めること＝合議制で進めること＝必ず良いこと」として扱ってしまう * リスクを重く捉えすぎ
仕事の割り振りで抜け落ちがちな観点 チームで仕事を進めるとき、誰に何を任せるかを考える場面がある。そのとき、つい「誰の手が空いているか」「負荷が偏っていないか」から考えてしまう。負荷分散は大事だし、特定の人に仕事が集中しすぎるのは避けたい。 ただ、負荷分散を優先するあまり、もう一つの大事な観点が抜け落ちることがある（特に自分の場合）。それは「その仕事に一番詳しいのは誰か」ということ。 自分にも覚えがある。ある仕事について、自分が一番知見を持っていたのに、負荷分散を意識しすぎて（自分がタスクをブラックホールのように抱え込んでしまう性質もあって）自分がやるという選択肢を外してしまったことがあった。
3/4に開催されるEMConf JP 2026のプレイベント、「【EMConf JP 2026サブイベント】Warm-up Party by EMゆるミートアップ」に参加。 【EMConf JP 2026サブイベント】Warm-up Party by EMゆるミートアップ (2026/02/17 19:00〜)# ステートメント 「EMゆるミートアップ」は、エンジニアリングマネージャー業を担う方同士で、ゆるくディスカッションや交流を行う勉強会です。 多様なフェーズ・文化をバックグラウンドに持つEM間での交流を通じ、マネージャーに必須の「自己開示と傾聴、相互理解」の実践の場、ひいては「EM像のア
スタートアップにおけるプロダクト開発には、不確実性がつきもの。市場環境、プロダクト戦略、技術選定、採用、などなど。正解がわからない中で仮説を立て、意思決定を重ねていくことを日常的に行っていく。 一方で、コントロールできることもある。ロードマップの策定、目標の設定、意思決定の場の設計や、決まったことの透明化。いわゆる「プロダクトオペレーション」と呼ばれる領域で、不確実性が低く、自分たちの意志があれば確実にやれることではある。 最近、高い不確実性に挑むためには、後者を確実にやることの重要性に改めて気づいた。 きっかけ 先日、チームの目標を決めるプロセスの中で、コントロールできることを徹底できていな
仕事をしていると、「a or b」を選択する場面に直面することが多い。 * スピードを取るか、品質を取るか * 全体を見るか、個人に向き合うか * 責任を果たすか、やりたいことをやるか * など どちらかを選ぶと、何かを失う（＝トレードオフが発生する）ことも多い。こういう場面で、自分は「a or b」ではなく「a and b」を選択できないか、つまり両方を取れる方法がないか模索するように心がけている。 きっかけ 心がけるようになったきっかけがいくつかある。 一つは、pmconf 2019 に参加したときに、LINE二木さんの「LINEにおけるお金とユーザーのジレンマ」というセッションを聞いたと
最近は仕事中のほとんど全ての時間をアーキテクチャを設計したり、コードを書くことに使わせてもらってます。すごく楽しいです。 そんな中、自分自身も含めたエンジニア組織のあり方について、個人的に考える機会があったので、備忘録的にメモ。 組織ではく、サービス・プロダクトが作りたい まず最初に頭に浮かぶのは、ユーザーの課題を解決し、価値を届け続けられる素晴らしい「サービス」と、それを支える「プロダクト」を作りたいということ。それを追い求める過程で、ひとりひとりが行動を積み重ね、その結果として必要な「組織」が自然と生まれていることが自分の理想。 「どんな組織を作りたいか」ではなく「どんな組織でありたいか」
2025年4月25日に開催された「Engineering Manager Meetup #16 〜EMConf expansion〜」というイベントに参加しました。 Engineering Manager Meetup #16 〜EMConf expansion〜 (2025/04/25 19:00〜)2025/03/30 増枠しました。繰り上がった方で懇親会に参加される方はこちらから参加登録をお願いします ## このイベントはEMConf JP 2025 のサブイベントです 02/27に開催されたEMConf JP 2025 は、「増幅」と「触媒」のテーマのもと大きな熱狂の中で終了しました。
チームの OKR の Objective を考える時、チームのみんながワクワク、熱狂して取り組めるものを掲げるのが大事だと思う。 一方で、組織全体を俯瞰的にみたり、他のチームからみたりするときに、何を達成するために活動しているチームなのかがパッとわかるように、わかりやすい Objective を掲げるのも重要。 ただ、他チームからみた時のわかりやすさを重視してしまうと、チーム内向けのワクワクさや熱狂できる度合いが下がってしまうこともある。表現が冗長になってしまったり、長くなってしまったり、ありきたりなものになってしまったり。 ワクワク・熱狂さを出すための方法は色々ある。Objective を達
「プロダクトマネージャーが読むべき何冊の本」みたいな記事で紹介されていたので読んでみた。（具体的な記事は忘れた。） Amazon.co.jp: 決定力！ 正解を導く４つのプロセス eBook : チップ・ハース, ダン・ハース, 千葉敏生: 本Amazon.co.jp: 決定力！ 正解を導く４つのプロセス eBook : チップ・ハース, ダン・ハース, 千葉敏生: 本Amazonのストアでお買い物 ›すべてを表示 ソフトウェアエンジニアとして日々仕事をする中で、僕はいろんなタイミングで意思決定をしている。プロダクトの仕様を決めるとき、それを実現するための設計を決めるとき、障害対応の方針を決め
会社の Slack で紹介されていた本。チームが目標に向かってリズムよく進んでいくための方法について興味・関心があるので読んでみた。 OKR（オーケーアール） 本書は、前半部分が小説パート、後半部分が OKR 自体の解説パート、の 2 部構成になっている。 小説パートは、やるべきことにフォーカスできず、問題山済みのスタートアップが、OKR を導入することで、なんとなくうまくいった感じになる、サクセスストーリー（？）的な内容。 OKR 自体の説明やユースケースについては、元からある程度知っていたり、昔以下のようなワークショップにも参加したことがあったので、すんなり理解することができた。前段の小説