この記事はEngineering Manager Advent Calendar 2023の10日目の記事です。
昨日はこにたん（@skd_nw）さんの「EMになる前となった後の話 | PengNote」でした。
対象読者
EM（エンジニアリングマネージャー）、もしくはそれに類する仕事を行っている人。
また、スクラムおよび相対見積について基本的な知識があることを前提としています。
TL; DR
本記事では、EMである僕がどのように自分の仕事を管理しているかを述べていきます。
- スクラムもどきを導入したが、可処分時間が変動するのでイマイチな結果に
- 可処分時間が変動するのは受け容れ、どれくらいなのかを予測するため時間の使い方を計測した
- 実時間を反映したポイントで相対見積して、可処分時間の予測に合わせてスプリントを計画すると上手くいった
EMの仕事は自己管理が難しい
EMといえば組織のエンジニアリングを管理する仕事です。ところで、みなさん自分の仕事の方はどのように管理されていますか？
僕は所属先の会社でEMを務めていますが、「エンジニアと比べてEMは自分の仕事を管理する難易度が高い」と感じています。
「自分の仕事の管理」とは「自分がすべきタスクを把握して所要時間の予測を立て、優先順位をつけて時間を確保すること」を指します。EMにとってこれが難しいのは以下の理由によるものです。
- 可処分時間が変化しやすい
- 仕事のサイクルが月単位
- 意思決定タスクが多い
可処分時間が変化しやすい
EMが「自分の仕事」を進められる可処分時間を自分で決められることは稀です。
他部署からの相談窓口になる・障害対応の指揮を執る・引き取り手のいないタスクを拾うなど突発的に発生する仕事が多数あるほか、採用候補者の選考・稟議申請などの書類仕事などタイミングによって物量が大きく変わる仕事もあります。
運悪くこれらが重なって「全然自分の仕事ができてないなー」とぼやくのもEMあるあるではないでしょうか。
仕事のサイクルが月単位
EMになるとミーティングの量が増えます。
それ自体は構わないのですが、厄介なのは月次のミーティングが増えるという点です。特に他部署とのミーティングは月次で設定されがちですよね。
そうすると週によって可処分時間が大きく変わるため、仕事を週単位ではなく月単位で進める必要が出てきます。
週単位に比べて仕事のサイクル長が単純に4倍になるため不確実性が急上昇し、自己管理の難易度も当然上がります。
意思決定タスクが多い
EMの主要な仕事のひとつに「意思決定」があります。
しかし、このタスクは管理する上での大きな悩みのタネです。時間をかけようと思えばいくらでもかけられてしまう。
調査をどれだけやるか、集めた情報をどのように整理するか、意思決定をいつの時点でやるか、意思決定の理由をどれだけ深掘りして説明するか……
時間を切ってやるしかありませんが、どの程度の時間で切るかもまた難しい問題です。時間を切ってもそれに間に合わなければ、やっぱり管理失敗ですから。
記事のスコープと免責事項
本記事では、EMである僕がどのように自分の仕事を管理しているかを述べていきます。試行錯誤しながら、2年ほどかけて現状にたどり着きました。
誰にでも合う方法とは限らないので、ご自身に適用する場合は状況に合わせて適宜アレンジしてください。
仕事を管理するスコープは短期（1日）・中期（1ヶ月）・長期（1年）1とさまざまですが、本記事では「中期」に絞って話をします。
まずはスクラムもどきを試した
マネジメントの仕事を初めたばかりのときは、行き当たりばったりに飛んでくる仕事をこなしていました。しかし、このままだと常に仕事に追われてしんどかったため、何らかの自己管理を行う必要があると考えました。
管理方法といえば、馴染み深いのはスクラムです。
スクラムガイドでは、1スプリントの最長の長さは1ヶ月と述べられています。これならば、月単位の仕事も管理できそうですね2。
そこで、まずは以下の形で「スクラムもどき」の自己管理を試してみました。
- 今後1ヶ月でやりたい仕事をプロジェクト管理ツール3で起票してプロダクトバックログを作る
- プロダクトバックログアイテム（PBI）を相対見積してストーリーポイント（SP）をつける
- 前回スプリントのベロシティ4に基づいてスプリントバックログ（SBL）に含めるPBIを決め、優先順位をつける
- スプリントを開始し、優先順位の上からPBIをこなしていく
一般的なスクラムのフローに沿っています。スクラムマスターもプロダクトオーナーも開発者も全部自分なので、その意味ではスクラムではないですけどね。
やることを計画して優先順位をつけるようになった分、これでも以前に比べれば仕事の見通しが立てやすくなりました。
しかし、このフローには2つの問題点がありました。
スクラムもどきの問題点
PBI消化に使える時間が月ごとにまちまち
週単位だと可処分時間が変化しやすかったので月単位の管理にすれば均せるかと思っていたのですが、そうでもありませんでした。
障害対応など本当に突発的にやってくるものは仕方ないですが、それを差し引いても人事評価・採用面接・コードレビューなど物量は月によってバラバラ。
これによって「計測したベロシティがアテにならない」という大きな問題が発生しました。
相対見積が難しすぎる
相対見積をするには「作業の質がある程度まで同様である」という暗黙の前提があります。
そのため開発タスクを見積もるのには向いていますが、雑多なタスクを比較するのには向いていません。質的に全く違うもの同士は対照できないからです。
僕は実際に見積をやろうとしてこれに初めて気付きました。スカウトメールを書くタスクの規模と内部設計のレビューをするタスクの規模、比較できますか？
問題点をどのように解決したか
上記問題が発生したのは、スクラムと相対見積がEMの仕事の管理にそぐわない点がいくつかあったからです。すなわち：
- 1人しかいない上に割込タスクが多いため、スキマ時間でPBI消化をするしかない
- 規模での相対見積を行うには仕事の質がバラバラ
よって、大枠は残したまま以下のようなアプローチで改善しました。
- 時間の使い方を計測してPBI消化に使える時間を予測する
- タスクの見積は実時間を反映したポイントで行う
時間の使い方を計測してPBI消化に使える時間を予測する
まずは何にどれくらい時間がかかっていて振れ幅がどの程度なのかを調べるため、以下のようなスプレッドシートを用意しました。
ここに毎日PBI消化とそれ以外にどれくらい時間を使ったか記録していきます。
このシートがあることで、スプリントが終わるとそのスプリントでどの作業に何%時間をかけたかがわかります。これをスプリント計画の材料にするのです。
すなわちPBI消化以外の作業のそれぞれについて、実績をもとに次のスプリントで何%の時間をかけるかを計画していきます。
このとき前スプリントの実績は必ずしも踏襲せず、例えば以下のように調整します。
- 次のスプリントで人事評価がある場合、1on1にかける時間を増やす
- 今スプリントで設計をやっていたタスクが次スプリントで開発に入る場合、コードレビューの時間を増やす
- 募集していた採用枠が埋まった場合、採用の時間を減らす
PBI消化以外にかける時間を調整したら、残りがPBI消化に割ける時間です。自分の場合はだいたい25-30%程度になります。
スプリントが20営業日だとしたら全体160時間のうちの25%なので、PBI消化に40時間割けることになります。
今度は、この40時間でどこまでPBIを消化できるのかを調べるため、見積をしていきます。
PBIの見積は実時間を反映したポイントで相対的に行う
SPも実時間も使わない理由
上記「相対見積が難しすぎる」で述べた通り、ストーリーポイント（SP）を使った見積、つまり規模による相対見積はタスクの質が互いに異なる場合には向いていません。
そもそも規模による見積を行う大きな理由のひとつが「開発メンバー間のスキル差を考慮するため」なので、自己管理でやる道理は薄いのです。
では規模に代わるタスクの見積基準は？というとやはり「時間」ですよね。
しかし、時間での見積といっても個々のタスクをサブタスクに分解して、各々が何時間かかるかの見積を積み上げる形はとりません。
なぜかといえば、この形をとると見積自体のコストが馬鹿にならないからです。作業の洗い出しが過剰に必要になる上に「何時間」という単位は見積に使うには粒度が細かすぎます。
実時間を反映したポイント
ではどのようにするか。SPを使った相対見積は、メンバーのスキル差の吸収以外にも
- 小さい自然数を使うことで適切な粗さになる
- 相対的な比較により大きいタスクがより適切な見積になりやすい
などのメリットがあります。これを生かさない手はありません。しかし、タスクの質的にどうしても規模で相対見積するのは難しい。ここでは実時間を使うしかありません。
結論として、「実時間を反映したポイント」を設定することにしました。小さいタスクは2時間=1ポイントとして時間で見積もり、大きなタスクはその相対値で見積もるのです。
SPのメリットを享受しつつ、実時間を用いることで質的に異なるタスクを比較できるようにするのですね。
ポイントを使うため、「フィボナッチ数を使う」「相対値がフィボナッチ数にない場合は基本切り上げ」などSPでのノウハウをそのまま活かすことができます。
見積の例
例えば、2ポイントの2倍くらい時間がかかりそうなタスクがあったとします。
この場合、2ポイントを倍にして4ポイントとつけたいところですが、フィボナッチ数を使うノウハウを適用して5ポイントと見積もります。
10時間かかるタスクをサブタスクの積み上げで測るためには作業内容を細かく検討しなくてはいけませんが、これならば作業の詳細化はそこまでしなくて良いでしょう。
また、「このサブタスクは1時間でも3時間でもなく2時間かかる」と決断したり「バッファをどのくらい載せるか」と考えたりする手間も、ポイントの選択肢が限られることで省略できます。
ちなみに、この見積の選択肢が限られているメリットが一番生きるのは意思決定など「どれくらい時間がかかるか分からないタスク」の見積も決めるときです。
このようにしてPBI群を見積もり、予測される可処分時間に合わせてバックログに含めることでスプリントを計画します。
どのようなフローになったか
元々のスクラムもどきのフローに上記2点の改善を施した結果、以下の図のようなフローになりました。
以下、補足を書きます。
スプリント計画
基本的には前述「時間の使い方を計測してPBI消化に使える時間を予測する」と図の通りです。
SBLを作ってみて時間が足りなかった場合はSBLからアイテムを減らしたりしぶしぶ時間外労働のカラムに値を入れたりして調整します。
スプリント中
ひたすらバックログを消化していきます。もちろん他の仕事もやります。
スクラムだとSBLの内容はそう簡単には変更しないのですが、マネージャーなのでそこは受け容れましょう。割り込みタスクもちゃんと起票して見積をし、優先順位の低いタスクをSBLから落とせば無理なく消化できます。
また、時間配分の記録は毎日やるのが理想なのですが、実際に毎日やろうとすると続かなくてやる気をなくします。Googleカレンダーにでも記録をつけてまとめて転記するのがオススメです。
ふりかえり
図の通り、実績をもとにふりかえりを行います。
1ポイントにかけた時間は、PBI消化に使った時間を消化したポイント数で割ることで算出できます。1ポイント=2hから大きくズレていた場合は、次のスプリントから見積か1ポイントに対応する時間を見直しましょう。
次のスプリント計画
ふりかえりをもとに次のスプリントを計画していきます。
続けていくうちに例えば「コードレビューは12-18%」など変動幅も分かってくるので、時間配分の予測精度が更に上がっていきます。
フローを運用している所感
このフローにたどり着いてからすでに半年ほど運用しているので、所感を書きます。
管理なしの行き当たりばったり状態・最初に導入したスクラムもどき状態から悪化した点はなく、基本的には改善した点ばかりです。
可処分時間の変化に対応しやすくなった
実績ベースで可処分時間を予測してからスプリントを開始できるため、「コードレビューがたくさん降ってきて思ったより仕事が進まなかった」という状況がなくなりました。
また、思ったより可処分時間が少なかったときも原因が特定できるため、業務調整がしやすくなりました。
時間を有効に使えているのに追われている感覚がなくなった
使える時間が限られていることを具体的に理解できる他、あまりのんびりしているとその分だけ実績に表れてしまうため、時間を有効に使えるようになりました。
一方で時間を有効に使えさえすれば計画した仕事は終わるため時間に追われている感覚はなくなり、ストレスフリーで仕事ができています。精度の高い見積の恩恵ですね。
残業時間も減りました。
依頼された作業の締切を無理なく設定し守れるようになった
依頼された作業の締切を余裕を持って設定し、無理なく守れるようになりました。
割込タスクが来た場合は見積をしてスプリントバックログに入れて優先順位を頭に持ってきて、見積をします。見積をしただけの時間が確保できる日を調べて、その翌々日あたりに締切を設定すれば良いのです。
向こうから締切を提示された場合も、無理な場合は無理だとすぐ分かるため交渉できます。
組織で仕事をするにあたって長期的に大事になるのは「この人に仕事を頼めば期日内にちゃんとやってくれる」という信頼です。
本記事で紹介しているプロセスはかなり重いですが、社内の信頼が築けるならこの手間も高くはないと思っています。
まとめ
長々と書いてきましたが、要点は以下の通りです。
- EMの自己管理にスクラムもどきを導入したが、可処分時間が変動するのでイマイチな結果に
- 可処分時間が変動するのは受け容れ、どれくらいなのかを予測するため時間の使い方を計測した
- 実時間を反映したポイントで相対見積して、可処分時間の予測に合わせてスプリントを計画すると上手くいった
自己管理に困っているEMの方は
- 可処分時間の計測
- 実時間を反映したポイントでの見積
をぜひお試しください。