至高のタスクマネジメント
私はエンジニアが軸足ですが、マネジメントも含めなんでもやるタイプです。
別に自信があるわけでもないですが自分が管理する案件はだいたい平和になる、というか平和にするまでありとあらゆる手段を尽くして平和にしています。
その辺の自分にとっては普通にやっていることを言語化して発信することに意義があるのではないか、と思う所があったので書いてみます。
至高のタスクマネジメント
至高という言葉は料理研究家youtuberの影響で軽率に使っているものであり、タスクマネジメントの手法は組織の形に応じていくらでも正解があるものだと思っています。
実態としては自分はこうやってます、という事を書きます。
至高のタスクマネジメントツール
マネジメントを行うためのツールは何でも良いとは思っていますが自分はBacklogを使ってます。
Backlogについては至高のマネジメントツールといっても差し支えないと思っています。
特にカテゴリとマイルストーンの存在を重視して使っています。
カテゴリの使い方
カテゴリ = 誰に任せられる仕事か
カテゴリはプロジェクトに応じて粒度は変えていますが、ある程度の規模だとフロントエンド、バックエンド、インフラ、更には管理画面フロントエンド、○○ページフロントエンド、と詳細化したりしています。
これは、カテゴリでタスクを分けることで、誰かにタスクをアサインする際にその人に任せられるタスクを検索する際に役に立ちます。
大体のエンジニアはフロントエンドエンジニア、バックエンドエンジニア、など得意領域を分けたがる傾向にあるため、そうしています。
業務ではなく技術カンファレンスの準備などでしかお目にかかれない現象ですが、
全員何でもできるスーパーマンでチームができた場合はカテゴリは重視していません。
マイルストーンの使い方
マイルストーン = ユーザーストーリー
マイルストーンというとアルファ版、ベータ版、のような使い方をされがちですが、
自分の場合「マイルストーン = ユーザーストーリー」になるような意識でマイルストーンを使っています。
仮にブログサービスを立ち上げる場合「記事閲覧機能完成」「記事投稿機能完成」のようにしています。
なぜこのようにしているかと言うと、どのようなユーザーストーリーを何月何日に実現できるのか、という思考回路でプロジェクトを整理できていることが大切だと考えています。
MVPと評価できる機能は何で、何ができることがストレッチゴールなのかを言語化することがプロジェクトを成功に導きます。
最悪な管理がされているプロジェクトはベータ版のデッドラインの日付に胴体着陸した状態をベータ版と呼びます。
タスク期限日は適当でも良いので必ず入れる
Backlogのタスクには期限日があります。
これは起票した日の2週間後、とか適当でも良いので必ず入れるようにしています。
炎上一歩手前まで追い詰められない分には、細かい期限日を守れているかはそれほど重要ではなく、期限を過ぎたらそのまま期限日を後ろにずらします。
デッドラインに対し余裕がない時は、日時でチケットの消化状況をslack通知するなどして、期日を守れそうにないタスクが無いかを厳しく管理し、若手メンバーにアサインしているタスクを巻き取るなど救済措置をマメに行っていきます。
slack通知ツールは昔作ってOSS公開しています。
近年は自分が完全掌握しているチームについてはこのツールを使うまでもなく推進できているので、作った自分自身がこのツールを使っていません。
自分以外にマネージャーがアサインされているが、チケットが腐敗しがちな時に人間が逐一ツッコミを入れると角が立つので、そんなときに活躍してくれます。
期限日まで入力すると健康状態が可視化される
Backlogではマイルストーンと期限日を入力すると、バーンダウンチャートが自動生成されます。
これが可視化されていると順調にタスクが消化されている雰囲気を可視化したり、貢献できている人を自動でほめてくれたりと、便利に使う事ができます。
適当に入れた期限日が滅茶苦茶なブラック企業状態になっている場合はバーンダウンチャートも割とハードスケジュールになります。
逆もしかりで緩すぎるときはバーンダウンチャートがイージーモードになります。
この辺はガントチャートバーンダウンチャートを眺めて微調整しています。
バーンダウンチャートが綺麗になったり、マイルストーンの消化度が100%になった時に祝う事ができます。
そういう意味でもマイルストーンはなるべく細かい分解能で設定できている方が良いです。
タスクの記載率は100%、遅延は0%が当たり前を目指す
自分が観測している炎上案件はだいたいやる事がチケット化されていなかったり、未完了のまま完了期限を過ぎても平然と放置されているチケットが山積みです。
この状態は普通にプロジェクトが崩壊しています、こうなっても何も感じずアラートを上げない事が炎上に繋がります。
やる事がきちんと言語化され、チケットとして並べられ、進行状況が可視化できている状態にできて当然という意識が炎上鎮火することに繋がります。
と言いつつ自分の場合は30分で終わるバグFIXは起票せずに治したりしています。
タスク一覧がプロジェクトの進行状況を隠蔽せずステークホルダーに説明できる材料になっているレベルになっていることが重要です。
タスクマネジメントとは言語化と俯瞰、可視化
タスクマネジメントの重要性は、プロジェクトの健康状態だけでなく、そもそもプロジェクトの全体像を可視化するためにあると考えています。
タスク一覧が崩壊しているチームはそもそも自分たちが何をしないといけないかを認識できていなかったり、プロジェクトの全体像を把握、整理できていなかったりします。
結果ステークホルダーと何も合意形成できていない事が浮き彫りになります。
タスクを整理できていないから炎上するのではなく、そもそも整理する力が無いから炎上しているのです。
タスクを全て一覧化できるという事は、タスク一覧の範囲、粒度まではプロジェクトを掌握できるという証左であり、早期にTODOを整理することは、チームの実力を早期に測定することになります。
タスクを整理できていないまま見切り発車する事は自殺行為です。
タスクを整理することそのものは炎上を防ぐ術では無い
タスクをどれだけ綺麗に並べても、チームにそのタスクを既定の期日で完了する力が無ければ当然予定通りにプロジェクトは推進できません。
メンバーは決して本気を出していないわけではなく、期日を厳しく設定し口うるさく急かす事では、タスクの消化率はたいして上がりません。
チームの空気を悪くするデメリットの方がはるかに大きく、限界があります。
タスクマネジメントは、タスクを健康的に消化できない事を早期に、精緻に可視化する事に意義があります。
その後プロジェクトを健康的に推進することは、チームビルディングや、要件定義による期待値コントロールの仕事です。
その辺はタスクマネジメントではなくプロジェクトマネジメントの話に派生していくので割愛します。
いずれのマネジメントであっても俯瞰する力と言語化する力が重要であると考えています。
まとめ
- 自分はbacklog使っています
- カテゴリーとマイルストーンが大事
- 処理状況が可視化できていると便利
- タスクの処理状況への意識は高い方が良い
- タスクの可視化状況が炎上を可視化する
- タスク管理は銀の弾丸ではない、あくまでも可視化手段
Discussion