タスクのこなし方の基本
今月から、自分の下に2人の新卒社員が配属されています。 自分はトレーナーとして、OJTでITスキル・業務知識・ビジネススキルの向上をお助けしています。
先日、彼らに向けて「タスクのこなし方」について話したメモが好評だったので、口頭で補足したコメントを添えてブログにも書こうと思います。
背景
- 受託開発をしているSIerの保守プロジェクト。現在はレベルアップ開発案件の開発フェーズ。
- 実装チケットが6枚あったので、新人2人に3枚ずつアサインし、4日でこなすよう指示
- 1日3時間は自分とのペアプロ。方針立てたり、やり方が分からないところは助ける
新人に「やりたいチケットある？」と聞いたところ、「特に…」とのことだったので（あえて）適当にアサイン → 1人の新人の方の負荷が高い
- 4日目の昼、その新人から「終わらないです…」とのエスカレーション（ペアプロしてるので進捗は分かっていましたが、報告や相談を受けたのはこのタイミング）
- 良い機会だと思ったので、この話をした
注意点と言い訳
- あくまで、個人的な意見です。
- いわゆる「プロジェクト」ベースの仕事をする人が対象になります。「ルーティン」ベースの仕事をする人は、またちょっと違うのかなと思います。
- とはいえ、結構汎用的にはなっている…のかな？
お仕事の流れ（メモの内容）
基本的に、大概のタスクは以下のような流れで行うのが良いです。
何をするか決める
QCDについて認識を合わせる
- Quality: タスクの完了基準。成果物とその品質。
- 例) 実装して、ローカルで動作確認をして、レビューに出す
- Cost: タスクのために使って良いリソース(お金、人、時間、モノ、情報源、権力…)
- 例) 新人の時間を4日間 + 自分のフォローを1日3時間
- Delivery: タスクの期日と、納品方法(持ち込み、郵送、設置(デプロイ)…)
- 例) 4日目までに、Pull Request で。
- Quality: タスクの完了基準。成果物とその品質。
タスクを一覧化、詳細化する
スケジュールとコストを計画する/見積もる
- フィージビリティの見極め
タスクを実行
予定と実績の乖離を確認する
経過報告
(必要であれば) スケジュール、コストを再計画
タスクを実行(以下ループ…)
完了報告！！
口頭で補足したコメント（タスクのこなし方について）
何をするか、は自分で選ぶもの
「やりたいタスクある？」に対して、「特に..」というのはとてもリスキーです。
- 達成が極めて困難なタスクを押し付けられるリスク
- めちゃめちゃ退屈な単純作業を押し付けられるリスク
- 他にやるべき/やりたいタスクに取り組めないリスク
- 自分の望むスキルを得られないリスク
自分の身を守るためにも、スキル向上のためにも、「次にやりたいタスク」は意識すべきです。
(一方で、「若いうちは仕事を選ぶな！」というのも一理あるし、ウソじゃない気がするんですよね…改めて言語化したい)
タスクの実行までには長い道のりがある
タスクの実行までには以下のような工程が必要です。
- QCDについて認識を合わせる
- タスクを一覧化、詳細化する
- スケジュールとコストを計画する/見積もる
そして、これらは暗黙的に行われていることが多いのです。
ちょっと機能を実装するために、WBSを書くのはめんどくさいですよね。
- なんとなく頭のなかでタスクを一覧化して
- 「多分、明日1日あれば行けるなぁ…」と雑に見積もり、
- マネージャー/レビュワーに、「明後日の夕方くらいにレビュー出します(`・ω・´)ゞ ビシッ」と伝える…
みんな、こんな感じでやってるので、新人はここが疎かになりがちです。ただ、脳内とはいえ、皆やっているんです。 慣れないうちは、雑なメモでもいいので何かしらアウトプットすることをオススメします。
経過報告は、意外と大事
自分も疎かにしがちですが、マネージャー視点で考えるとめちゃめちゃ大事(らしい)です。(ここはマネージャーからの受け売りになります)
- マネージャーからは実際のタスクの進捗は見えなくなりがち
- 「タスクを実行する中で明らかになること」が有ることをマネージャーは知っている
1点目は、まぁ、いわゆる永遠の課題です。なので、そういうものだから、メンバーもフォローしてね、くらいです。
どちらかと言うと2点目が怖いです。実際にタスクに取り掛かってから分かること、というのは良くあることで、それは実際にタスクに携わっている人にしか分かりません。
そういった問題を共有してくれないことは品質やスケジュールのリスクに繋がるので、マネージャーとしてはこまめに状況報告してほしいのです。
コメント (その他)
- 上に書いた流れは、プロジェクト全体でもだいたい同じ
- 違うところはQCD。そして、QCDをクライアントと調整できるからマネージャーは偉い。
- QCDのサイズと、守れなかった場合の責任が大きい
- QCDの認識ズレが許されない
- 違うところはQCD。そして、QCDをクライアントと調整できるからマネージャーは偉い。
- タスクのために使っているリソースはいっぱい有る
おわりに
思ったより長くなりましたが、以上です。
長文にお付き合い下さりありがとうございました。
.... このあと、新人から「ちゃんとリスケしてリカバリーしたいんですが、優先順位ってどうなるんですか？」という質問を受けました。
それについての回答は、また次回に。→ 書きました。こちらもぜひどうぞ。
