時間がない…と嘆きがちなマネージャーに読んでほしい、割り込みタスクをなんとかする方法｜dora_e_m
時間がない！！マネージャーの皆さん、マネージャーではないけれども割り込みタスクに忙殺されているみなさん、おはようございます。 先日、友人と会話しているときに「いつもレスが速いけど、どうやって処理してるのか」と聞かれました。何って…ただ目の前にきた問い合わせを素早く処理してるだけだが？と思いつつ会話を進めていくと、ああ自分がやっているタスクのさばき方は一つの技術なのかもしれない、と思い至ったので書き記しておきます。なお、基本的にはGTDの考え方でやってます。 前提:人間はシングルコアであるまず前提として、人間はシングルコアです。同時に二つ以上のことはできません。（じゃあギターボーカルはどうなるんだとかそういう話は今回のスコープじゃないので置いておきます。） では、シングルコアしかない人間は、どうやって割り込みタスクに対処すればよいのか。 簡単に捌けるもの（自分が知っていることに関する質問）で
OKRをツリーにする前に言っておきたいことがある｜dora_e_m
「OKRはツリーではない」から約1年半以前、「OKRはツリーではない」というタイトルで登壇したことがあります。OKRを採用している多くの現場で、組織レベルのOKRから個人レベルのOKRまでをツリーでつなげる「OKRツリー」で運用しているけれど、OKRはツリーじゃなくてもいいんだよということを伝えたい発表でした。 「ツリーじゃなきゃいけないと思っていたけど、ツリーじゃなくてもいいんですね！」など、様々な反響をいただきました。 それから1年半。「OKR」というキーワードを入れてGoogleで画像検索すると、OKRをツリーで捉えた画像がたくさんでてきます。この状況は1年半前とあまり変わっていません。それだけ、目標を組織全体で連携させていくことは重要だということの表れです。 ツリーで扱うときに気をつけておきたいことOKRをツリーで扱うことは、組織ーチームー個人の目標をアラインメントさせるという点に
Scrum Fest Kanagawa 2024- 春の陣 - でみんなの心に放火してきた （3/18加筆修正）#ScrumKanagawa｜dora_e_m
はじめにイベント終了直後に、失いかけた意識の中で参加レポートを投稿しました。8時間寝て元気が出たので、あらためて加筆修正して投稿します。 スクラムフェス神奈川2024春の陣でキーノートやってきたよいってきました、スクラムフェス神奈川。 プレイベントを挟んで、スクラムフェス神奈川主催としては初めての本格的なカンファレンス(しかも合宿)でキーノートを担当させていただくという身に余る光栄に預かりました。 さて、スクラムフェス神奈川いったいどこでやるのかというと、なんと小田原でした。小田中が小田原へ。 ロマンスカーの神様、今日もありがとうスポンサーLTから最高イベントはまずスポンサーLTから始まったのですが、これがもう最高でした。 スクラムフェスという場を盛り上げるための、マスコットキャラクターの名付けから始まり、モブプロでチームに起こった変化、自分のチーム鬼速で最高！という熱い話が立て続けに繰り
結局のところ、エンジニアリングマネージャーとは何者なのか｜dora_e_m
はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象
グルーとしてのエンジニアリングマネージャー｜dora_e_m
はじめにこれはQiitaのEngineering Manager Advent Calendar 24日目の投稿です。 エンジニアリングマネージャー（EM）の役割EMというロールの定義は組織によって異なりますが、共通項としては「チームのパフォーマンスを最大化すること」があります。 チームのパフォーマンスを最大化するためには様々な打ち手が考えられます。 チームのイネーブルメント チームメンバーの採用、育成、評価の実施 キャリア形成支援 パフォーマンス・マネジメント ロードマップに沿ったスケジューリング、チーム内の体制最適化 技術的リーダーシップ 技術的意思決定への参加 技術的課題の解決への貢献 コミュニケーション コミュニケーションパスの設計 チームのAPIとしての機能 プロセス改善 予算管理 チームの規模や会社のフェーズ、そこにいる人々の特性によってとるべき打ち手は異なってきます。 私が今
1on1の普及と「とりあえず1on1」問題｜dora_e_m
1on1ミーティングの普及1on1ミーティングが多くの現場に浸透してずいぶん経ちます。1on1という仕組みの普及に大きく貢献したのは「ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法」でしょうか。 本書の帯に「部下のための時間」と書かれていることからわかるように、1on1はその普及段階においては「上司と部下の間で定期的に行われるミーティング」という意味合いでした。 ここ最近では1on1という言葉が指す範囲がもっと広がっていると感じます。同僚同士でのコミュニケーションだったり、定期的ではなく突発的に設けられた場だったり。 物事が普及していく過程でもともと持っていた意味合いが変化していくのはよくあることで、こういった意味の広がり自体が1on1が広く普及しているという事実を物語っています。 同僚同士の1on1上司ー部下という関係性ではなくフラットな関係性での1on1は、上下関係があ
エンジニアの目標設定って難しいよね、という話とOKRでなんとかできるのではという話｜dora_e_m
「目標設定、ニガテなんですよね」組織に属するメンバーを育成し、評価する。そのための材料として「目標設定」を活用している組織は多い。MBOか、それに類する形を採用しているところが多いのではないか。（観測範囲での判断なので今は違うかもしれない） そして、「目標設定」を行う組織は多いというのに、「私、目標設定得意なんですよ」というエンジニアの存在は寡聞にして存じ上げない。なぜなのだろう。 エンジニアの目標設定は難しい？組織のレベルでは、「売上○○円」「ユーザー数○○人」「平均DAU○○」といった目標が設定されることが多い。財務に直結するものだ。翻って、エンジニアたちは組織にどう貢献するのか。エンジニアリングだ。直接売上がどうこうではなく、「どうすればビジネスに貢献するか」から立脚された仮説に基づいて行動をしていくことになる。 こうすれば画面遷移数が減って使いやすくなる、その事により利用率が向上す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
