「終わらせる」の第一歩を考える

サーバーレス開発部の阿部です。

仕事は始まった時点から「終わらせる」ことを意識する必要があります。本来終わらない仕事はないはずなのですが、なかなかそうもならない現場というものもあって、迷走するプロジェクトというのも残念ながら出会ってしまいます。

リモートワークでマネージャをするようになって、この「終わらせる」ことの重要性をより感じるようになりました。リモートワークではコミュニケーションが非同期であることを前提として進める必要があるため、過程をウォッチするようなやり方が通用しないからです。通知を中心として情報を流通させて、そこから次のアクションを促す、プッシュ型のコミュニケーションを基盤に据えなければなりません。そのためには「終わったこと」を検知できることが重要になります。

終わらない原因を考える

基本的には曖昧さに起因するものです。終わらない、もしくは終わりのわからないタスクでは、以下の点が曖昧になっているケースが多く見受けられます。

• いつ終わるのか？
• 何をやれば終ったと言えるのか？
• 終わった後は誰が受け取ればいいのか？

これらは全て個々のタスクについてすべきことの見積もりを通じて得られるものです。当然「やってみなければわからないこと」もありますが、それを判断するための情報を揃えるタスクについてはもう少し見積もりができるはずで、やはりその場合についても曖昧な部分をわかるようにしていくための見積もりが必要ということになります。

つまり、至極当たり前の話で、終わる状態の定義が曖昧なので、終わったかどうかがわかってない、ということです。

曖昧だと何が困るのか？

マネージャの立場からいうと、メンバーがやっていることに対する予測性が重要です。

例えば、状況を元にチーム内外で調整をしなければならないケースは多々あります。この時に、マネージャが動くための判断をするベースは、タスクの見積もりに基づいた予測性です。

また、メンバーの立場でいうと、タスクのステータスがわからないことによるコミュニケーションの断絶が発生します。

例えば、本来終わっていて次のアクションに移らなければならないタスクを見合ってしまったり、終わっているとは言えないタスクに対して、終わっていると勘違いして手を止めてしまって放置されたり、といった状況です。

いずれにせよ、曖昧さは現状だけでなく、これから先のことも容易に見えなくさせます。リモートワークで仕事を進めているチームであればなおさら曖昧さによる混乱には脆弱なことでしょう。

「終わらせる」ためにやること

基本的には見積もることです。見積もりのアウトプットは工数(もしくは規模)という数値なので、アウトプットを出すためにはこの行為を通じて、仕様や期間などの曖昧さに対して前提条件を整理していく必要があります。個人的には見積もりは工数を出すことではなく、これらの不明点をだすことの方が重要だと思っています。

ただし、マネージャが全てのタスクに対して個別の完了条件を見積もることは難しいため、メンバーに対して以下のことをお願いし、合意ルールがうまくいくように取り計らっていくのが現実的なアプローチだと思います。

• タスクの見積もり(期間、ボリューム。特別な要求がある場合はそれを達成するための前提条件)
• 終わる条件とアウトプットをチームで合意(ex.チケットのステータス移行の条件)
• 終了の通知の仕方をチームで合意(Githubやチケット管理でリマインドが飛ぶならそれで)

これだけやっても後から不明点が出てくるのは常なのですが、少なくともどこが乖離しそうなのか、という点ははっきりするため、終わらせるためのアクションを絞り込むやすくなります。計画の変更は必要かもしれませんが、場当たり的なものにはならないでしょう。

まとめ

始めた仕事は終わらせましょう。