タスクをアサインするという行為に秘められた価値を最大化するためには

はじめに

こんにちは。
この記事は株式会社ビットキー Advent Calendar 2022 11日目の記事です。

モバイルアプリチームのEngineering Managerを務めている ＠Gos67からお送りします！
本記事では普段何気なく行っている「タスクのアサイン」という業務/行為について、その効力を振り返るとともに効力の最大化に至るにはどこに注意すべきなのか？を考察してみたいと思います。

TL;DR

• タスクのアサインという行為から得られる価値を最大化するためには、いかにアサイナーとアサイニーの間にある知識のギャップを埋めるかがカギ
• そんなギャップを埋めるためのタスクの精査には当然時間がかかる。だが最後の最後でタスクを1からやり直しになるリスクを回避するためには必要なコストであり、惜しむべきものではない
• タスクを精査・詳細化した後も決して自分本位にならず、自分の意図したことが正しく伝わっているかをアサイニーとすり合わせを行うことが重要

本記事のモチベーション

「タスクをアサインしたのに、アウトプットが自分の想定したものと違った！」という経験は誰にでも当てはまると思います。
そんなギャップを生じさせないためにはどうすればよいのでしょうか？
これには自分の想定しているアウトプットと、アサイニーが想定したアウトプットをすり合わせるということが何よりも大切です。
本記事では、そのようなアウトプットの擦り合わせを行う上で私が重要視している観点をまとめあげていきます。
1点注意として、アジャイル開発を行っているチームであることが本記事の前提となっていますのでその点だけご留意いただければ幸いです。

本記事で扱う用語について

• アサイナー: タスクをアサインする人
• アサイニー: タスクを受け取る人

本記事の対象読者

• Engineering Manager
• スクラムマスター
• （広義の）チームリーダー
• （タスクをアサインされる側の）エンジニア

本記事の対象範囲

[対象💡]

• タスクの詳細化を行うにあたっての心構え
• タスクを詳細化を行うにあたっての標準化手法
• タスクの詳細化の意義の考察

[対象外🙅‍♂️]

• コミュニケーション手法そのもの
• タスク管理ツール
  • 本記事ではタスク管理ツールについては取り上げません。
    タスクのアサインをどのように行っているかは各々で異なると思いますが、
    どんなツール・手法を用いていても、あるいは仮に口頭での会話であったとしても重要となる部分について記載をしています。

タスクの詳細化を行うにあたっての心構え

アサイナーが前提として持ち合わせておくべきこと

もはや言うまでもないことですが、アサイナーとアサイニーは赤の他人です。
自分の思考は言葉に、あるいは文章にしないと相手には伝わりません。
この「伝わっていない領域」が広ければ広いほど、あるいは多ければ多いほど最終的なアウトプットのギャップもまた広がっていきます。

ではこの「伝わっていない領域」を生み出すもととなっているのは何でしょうか。
そもそもの伝え方が悪かったという例もあるでしょうし、相手の理解度に合わせた言葉遣いができていなかったということもあるでしょう。
しかし、これは言葉や資料の問題だけではありません。
たとえば「自分はプロダクトオーナーであり相手はエンジニアである」といったように立場・視座が異なっているケースもあるでしょうし、「過去どれくらい対象となるプロダクト・プロジェクトに関わってきたか」といったドメイン知識の差も影響するかもしれません。

以上見てきたように、自分と他者とのギャップは多くの場所に潜んでいます。
これらのギャップを可能な限り言語化し・整理し、アサイニーとすり合わせを行うという行為があって初めて、あるタスクに対する自分の期待値と相手の期待値とを近しい状態に持っていくことができるわけです。

ギャップを効率的に取り除くには

正直に申し上げると、瞬時にギャップを取り払うような魔法は存在しないのが現実です。
ただし、以下の項目を意識することによってある程度効率的に・効果的にギャップを取り払うことはできると思っています。

1.（タスクをアサインするにあたってドキュメント化する場合）テンプレートを用いて標準化する

2.タスクの詳細化が完了したところで、アサイニーと擦り合わせの場を設ける

まずドキュメントの標準化についてですが、ドキュメントはアサイニーがタスクに取り組む際の玄関口となります。よって出来る限り認識齟齬を生みにくい組織環境を作るべく、関係者にとって馴染みある形式をテンプレートとして用意することで「どの項目にどんな内容がどういった粒度で書き込まれるのか」を形式知として共有できる状態を目指します。

2点目について。
自己保身的かもしれませんがアサイナーの心構えとして「言語化に完璧を追求しすぎない」こともまた重要であると強調しておきます。
そもそもどんなに相手の目線に立ってタスクを詳細化したとしても、実際にアサイニーにタスクを手配しドキュメントを読み進めてもらうまでは、真に相手に伝わるかどうかは分かりません。
故にタスクの詳細化がひと段落ついたところで、アサイニーと擦り合わせを行うことによって完成度を100に近づけるというプロセスを取るべきです。

タスクを詳細化を行うにあたっての標準化手法

下記は「こんな項目をこんな観点で用意してみると、タスクの全貌を掴むためのサポートになり得る」という標準化の一例です。
実際のプロジェクトやチーム体制によっては、項目を追加したり粒度を変化すべき点もあると思いますので、一つの参考としてしてもらえますと幸いです。

タスクのタイトルを定義する

タイトルは、端的にそのタスクの内容を掴むことのできる内容を記載できていれば良いでしょう。
短すぎても情報が不足してしまい良くないですが、あまり長すぎると逆に意図を掴み辛くなってしまいますので、15~30字程度で表せるとベストかなと思います。

タスクの概要・前提条件を定義する

この項目は非常に重要です。
まず最初にお伝えしておきたいことは、いかなるタスクにも前提条件は必ず存在するということです。
そのタスクが生まれるに至った背景や、対象としているユーザー像（場合によっては像というより具体的な名称で語られることもあるでしょう）など、これら全てが前提条件となります。

では、この前提条件が明確にされていないと何が起こるでしょうか？
たとえば「そのタスクを達成することによってどのような現状を打破し、どのような理想を実現していきたいのか」という像がずれていくことに繋がるでしょう。また、後述する「タスクのスコープ」がブレてしまい、本来やらなくてもよかった範囲まで手をつけてしまうといったことにも繋がりかねません。

記載する際には 5W1H の形式に則って書いていくと漏れなく記載できるでしょう。

例： 
・タスクが生まれるに至った背景 (Why / When)
・どのようなユーザーからの要望で、何人くらいから誰（どこ）に対して挙げられているものなのか (Who / Where)
・どのような点についてペインを有しているのか (What / How)

タスクのスコープ・完了条件を定義する

前提条件を整理したら次は今回のタスクのスコープを定義していきます。
カギとなるポイントは、アウトプットの質と量です。
何を・どのような範囲まで・いつまでに・どのような形で対応できていると、このタスクが完了になったと言えるのかを記載していきます。
よってこの項目では5W1Hのうち、When / What / How を意識して書いていくと良いでしょう。

例:
・(タスク作成時点では)いつまでに実装や資料作成を終えていることが望まれているのか (When)
・(タスク作成時点では)何をどのように実現することが望まれているのか (What / How)

ただし一方で、下記のように「現時点でアサイニーに伝えることのできる情報」に不足があったり、改めて整理してみるとスムーズに完了条件を満たすのは難しいことに気づく場合もあるかもしれません。

実装系タスクを直接アサインする予定だったが、前提条件を記載してみたところ自分が当初想定していたよりも
不確定な要素が大きいことに気づいた。
よってこのタスクのスコープは、いきなり実装に入ろうとするのではなく、実装TODOを洗い出すタスクへと変更しよう。

このような気づきというのは喜んで迎え入れるべきものだと私は考えます。
なぜならば、これはここまであなたが行ってきた「タスクの整理」という行為によって初めて得られた気づきです。もしもこの気づきを得られていなかったら確実にアサイニーとの認識のずれを引き起こしていたことでしょう。

タスクにおけるステークホルダーを定義する

ここでの「ステークホルダー」とは、一般的なアジャイル論において定義されているステークホルダーと同義であると捉えていただいて差し支えありません。
つまりプロダクトの利用者から、社内の上司や他部門のプロダクトに対して利害関係を持つような、スクラムチーム以外の人を指しています。

これを定義した場合の効能の一例は以下です。
例えばもしアサイニーがタスクの内容について相談したくなった場合に、アサイナーの貴方がすぐに対応できない状況にあったとしても、ステークホルダーを確認して助けを求めることができるようになるかもしれません。
あるいは「現時点でのアサイナーの貴方が持っている情報」よりも高品質な情報が必要になった場合に、より詳細な情報を持つであろうステークホルダーから情報を得ることが可能になるかもしれません。

「必ずしも定義されているべき項目」ではないかもしれませんが、いざという時に助けになってくれる。そんな項目がこのステークホルダーの定義と呼べるでしょう。

タスクのタイトル・まとめを見直す

ここまで来れば、ゴールはもうすぐです。
整理を行ってきた中で、当初自分が思い描いていた内容から解像度が上がり、記載している途中でスコープに修正が入ったりしたこともあるでしょう。
その場合、はじめに記入したタイトルや概要が、現在記載されている詳細の内容とはそぐわない状態になっていることも多々あるかと思います。よってこのタイミングで一度それらを見直し、本文と乖離のない状態を作れるように目指しましょう。

タスクをアサイニーに見てもらい認識齟齬がないか確認する

前項までの内容が仕上がったら、実際にアサイニーとドキュメントの読み合わせを行ってみましょう。
最初は質問の応酬になることもあるかもしれませんが、それもまた健全な活動です。ドキュメントがなければ、ともすると「何が分からないかすら分からない」状態だったかもしれません。お互いのドメイン知識を埋め合う様は、開発業務におけるペアタスクやモブレビューといった活動にも近いと思います。
また、この活動の中で発生した会話の内容は極力コメントとして残しておきましょう。口頭での意思決定をしてしまい、その内容が最後の最後でドキュメントに残らないのは勿体無いことこの上ないです。あとで詳細化されたタスク内容を見返した時のことも踏まえ、ここもきっちりと文書化しておきましょう。

タスクの詳細化の意義の考察

タスクを詳細化するのって大変ですね…

はい、とても大変です。
なぜならば冒頭に述べたとおり、タスクの詳細化は人と人の理解度を言語化あるいは文書化によって近づけるための行為です。
整理の際にどのような言葉を用いるかによって、相手の言葉の受け取り方が変わることも考慮し始めるといよいよ難易度は跳ね上がっていきますから、1つのタスクについて書き上げるだけでも大変な時間を取られることでしょう。

ですがこうした営みを経て初めて、アサイニーは認識齟齬のない形でタスクを進めることができます。引いては、アサイナーは自己が思い描いたものに近いアウトプットを最終的に受け取るに至れるでしょう（もちろん全てが完璧ということはありませんので一定のギャップは生まれてしまうかもしれませんが、整理を行ったのとそうでないのとでは雲泥の差が生まれます）。

また、他にも良い効果が表れる場面があります。
それは例えばタスク着手以後のチーム内レビューや振り返り(レトロスペクティブ)といった場面です。
タスクの着手から完了に至るまでの、一連の流れを思い起こしてみてください。
「着手前にはこのように捉えていたが、あるタイミングから状況が変わりスコープが大小した」「サブタスクの優先度が変更された」といったことは頻繁に起こります。
往々にして、タスクというものは時間とともに状況が変化していくものだからです。
複雑なタスクであればあるほど、起票当初の姿というのは見えにくくなってしまいます。振り返りを行おうにも、原初の姿が曖昧では効果的な振り返りにはなり得ないでしょう。
そんなときに、アサイナーが詳細化したドキュメントが原典として大きく力を発揮します。

おわりに

タスクのアサインという行為の重要性について思いを馳せてみましたが、いかがだったでしょうか。
ここに記載した内容の全てを実践するのはとても大変なことですが、そこにはコストをかけるにふさわしい価値が潜んでいることを認識いただけたら幸いです。

明日12/12はアナリティクスエンジニアの @i_am_miko さんの投稿です。お楽しみに！