最近、締め切りのある大きめなプロジェクトでWebアプリケーションエンジニア兼プロジェクトマネージャーとして仕事をしました。一年目なので当然プロジェクト管理の経験はなく、本を読んで知識を得たり、チームメンバーに助けられたりと、だいぶ手探りでの挑戦となりました。その中でもっとも難しかった仕事の一つとして、タスクの効果的なアサインがあります。
エンジニアは最大8人おり、その技術力、ドメイン知識、勤務地などは多岐に渡ります。ウォーターフォール的な開発だったため、タスクは事前に洗い出されており、タスク管理ツール上に無数に登録されていました。適当に人とタスクを辞書順でソートしてアサインするだけなら簡単ですが、現実はそうもいきません。締め切りは厳しく、チームの生産性を少しでも高く維持しなければいけません。メンバーのモチベーションが下がったり、依存の多いタスクが遅れたりといったことはなんとしても避けたいものです。この難しい課題を乗り越えるために、私はタスクと人の両面をよく理解することから始め、その知識に基づいて、パズルを解くようにしてアサインを決めました。本記事では、その際に検討した8つの軸をまとめます。
8つの軸は「タスク優先度」と「人」の2側面に大別されます。まずは「タスク優先度」から見ていきましょう。
タスク優先度に関する2つの軸
タスクを消化する順番は非常に重要です。これを間違えると、作業が止まってしまったり、あとから複雑な要件が明らかになったり、プロジェクトの安定した進行を脅かします。そうした問題を回避するために、今回のケースでは大きく分けて「依存関係」「不確実性」の2つを検討しました。これ以外にもプロダクトオーナーの要請などで優先度が変化することはありますが、支配的な要因ではありませんでした。
依存関係
Webアプリケーションの機能には、当然ながら依存関係があります。Aという機能を作ってからではないとBという機能を作りづらい、といった事情が無数にあります。これによって、先に着手しておかないと困るタスク群というのが現れます。これを、担当者がなるべく依存関係を気にしないで済むように‥‥最低でも依存関係によって作業が止まることのないようにできれば、チームの生産性は上がるはずです。
「精査して気をつける」以上の取り組みとしては以下のようなものがありました。
- もしどうしても依存のあるタスクを並行して進める必要がある時は、両方の担当者に対して情報を共有し、お互い連携しつつ進めてもらうように依頼する
- チームメンバーの「依存を解決できる最小のタスクを作って進めると良いのでは」という提案に基づいてタスクの分割の仕方を変えた
また、今回のプロジェクトでは、機能ができないとデザイナーが稼働しづらいという依存関係もあり、デザイナーの稼働率を上げるために画面に関連するタスクを優先的に消化する必要もありました。
不確実性
要件や実装方法が明らかではないタスクは、実装にかかる期間を見積もりづらくリスクが高い状態で、早めに着手するのが望ましいとされています。私が今回携わったプロジェクトでは、既存システムをそのまま利用できない「新機能」の枠がこれにあたりました。幸い、チームのベテランエンジニアが、割と早い段階で「新機能は危ない」と声を上げてくれており、事前にタスクにタグ付けをしていたため、容易に一覧して検討材料とすることができました。不確実性の高いタスクの注意点として、期間だけではなく、難易度も不確実であるということがあります。調査をしてみたら異常に難しい、よくある解法を知らないと難しいといった可能性があり、誰をアサインするかは注意深く検討しました。
人に関する6つの軸
個人の特性に合わせてタスクをアサインすることは非常に重要だと感じます。全員に興味と能力にマッチしたタスクをアサインできれば、チームの生産性は間違いなく向上するでしょう。モチベーションの向上に伴ってチームの雰囲気も上向くでしょう。全員のタスク完了ペースも揃いやすいので、ベロシティを安定して計測できるといったことも考えられます。こうしたメリットを狙って、人に関する軸として「技術力」「ドメイン知識」「興味・得意分野」「成長機会」「コミュニケーション」「自分」の6つの軸を検討しました。
技術力
これは言うまでもなく重要な軸です。チームメンバーは全員優秀で、誰にどのタスクをお願いしたとしても、どうにかして完遂してくるだろうという信頼はありました。しかし、締め切りに追われる状況下では「安定して」「筋よく」各タスクが完了するのが望ましいです。止むを得ない側面もあり、技術的に難しいタスクは、経験のある技術力の高いメンバーにアサインするというのを基本方針としました。しかし、これには若手の成長機会が失われるといったデメリットもあり、後述する他の軸も検討してバランスを取るように心がけました。
ドメイン知識
これは「技術力」と同じ、エンジニアのシンプルなパワーに関する軸で、やはり重要です。今回のプロジェクトでは、既存システムの改修やつなぎ込みが必要な部分があり、その既存システムを理解していないと難しいタスクがいくつかありました。そういったタスクを社歴の浅い人にアサインするのは、スピード重視の状況下ではあまり筋が良いとは言えません（一般にはドメイン知識を展開するメリットを考慮するべきでしょう）。過去のプロジェクトの話を少し聞いてみたりして、よりドメイン知識がマッチする人にタスクをアサインできないか検討しました。
興味・得意分野
締め切りに追われる日々だとしても、毎日の仕事が楽しいに越したことはありません。一人一人がやりがいを感じて働けることは、他の人にも良い影響を与えるでしょう。そうした観点から、興味や得意分野を把握できている人には、なるべくそれに近いタスクをアサインするように心がけました。とはいえ、急ごしらえの大きなチームでメンバーの嗜好を把握しきれなかったり、他の軸を優先せざるを得ない場面も多かったりと、なかなか上手くハマる場面は少なかったという印象です。次に大きなプロジェクトをやるときに、重点的に考慮したい軸の一つです。
成長機会
この軸については、id:t_wada さんの こちら の発表が大変印象に残っています。
では、品質と速度についてのトレードオフが意識されるとき、実際には何と何が秤にかけられているのか。
（中略）プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。
タスクのアサインを検討する中で、チームの生産性を向上させるための最も素朴な最適化は、難しいタスクをできる人にアサインすることでした。しかし、それを続けていては知識は展開されませんし、時間があればアサインできていたはずの若手の成長機会が失われます。今回のプロジェクトでは、興味・得意分野が上手くハマる場合に少し挑戦的にアサインをしてみたり、一時的にベテランと若手の2人をアサインしてペアプロをお願いするなどして、ささやかな抵抗を試みました。これはまさに「抵抗」という言葉がぴったりで、締め切りによって失われたエンジニアとしての楽しみを、少しでもチームに取り戻すという気持ちで検討しました。
コミュニケーション
誰をアサインするかによって、タスクを進める上でのコミュニケーションの難易度は変化すると考えます。例えば、社歴の浅いメンバーにとって、チーム外調整が必要なタスクは相対的に難易度が上がります。上で述べたペアでのアサインでも、勤務地が違う2人をアサインするより、同じ勤務地でペアプロをしやすい2人をアサインした方が簡単になります。調整が可能な場合は、こうした細かい最適化も検討しました。
自分
これは、いわゆるプレイングマネージャーとして取り組んでいる場合に特有の検討事項でした。自分は、いちエンジニアとして作戦を考えて、時には他のエンジニアに厄介な仕事をお願いする立場です。しかも、やろうと思えば自分に一番面白いタスクをアサインすることすらできてしまいます。そういう立場で、いかにチームメンバーからフォロワーシップを引き出せるかが重要だと感じていました。そのために、自分がラクをしないことを心がけました。厄介な新機能や、チーム外との調整が必要になるタスク、クリティカルパスに関わる割り込みを積極的に取って、1人のプレイヤーとして、締め切りに対して誠実に行動していることを示せるように心がけました。幸いチームメンバーは優しい人ばかりだったので、実際のところフォロワーシップの心配はありませんでした。しかし、そこにあぐらをかくわけにはいきません。これはプライドの問題です。
まとめ
以上、効果的なアサインを考えるために検討した8つの軸を紹介しました。どの軸を重視するかといった問題も非常に難しく、プロジェクトの状況に応じて柔軟に検討するようにしました。プロジェクト自体はなんとか成功しましたが、アサインミスで特定の人の負荷が上がってしまったり、そのしわ寄せによってチームの他のセクションが不安定になってしまったりと、色々と反省ポイントはありました。また、今回の議論は、場当たり的に必要なものを挙げていった結果生まれたもので、先人の議論を十分には参考にできていません。また、全ての軸を効率よく検討する手法も確立できていません。より再利用性の高いフレームワークとなるように、今後も改善を続けていきたいと思います。
コラム: タスクをアサインすることの是非
一般的なアジャイル開発においては、スプリントプランニングで人にタスクをアサインしないのが良いとされています。タスクの属人性を排除することで、チームとして仕事を進められるようになり、結果として助け合いなどが起こり安定した生産性を発揮できるようになるという考え方です。しかし、今回はプロジェクトがあまりにも難しく複雑でした。アサインをすべて決めることで、属人性すら最適化の道具として利用し、チームの生産性をシビアに議論する必要がありました。それがチームにとって最良の状態ではないという意識は常にあり、プロジェクトの不確実性が減少するにつれて、少しずつチームメンバーにタスクを選んでもらう形式も取り入れました。プロジェクトの性質やチームの状況に合わせて、スプリントプランニングの方法を検討できると良いのでは、というのが所感です。
