こんにちは、最近CloudRunに夢中な id:silverbirder180です。 2019年4月12日に、社内で開催されました「スケジュール管理能力強化勉強会」に参加しました。 良い学びがあったので、こちらで報告します。
1. 対象読者
プロジェクトで炎上した経験はありませんか?
- 見えていなかったタスクがあった
- 想定以上に工数が膨れ上がった
なぜそうなってしまったのか、その一要因として、
- もれなくタスクの洗い出しできていない
- タスクを実行可能なレベルにできていない
が挙げられます。「そんなのプロジェクト当初からもれなくタスクを洗い出せるわけないじゃん」 と思う訳ですが、そこが今回の勉強会で取り組む内容です。 もし、思い当たる節がある方は、是非とも続きを読んでいただきたいです。
2. 勉強会の目的
仮想的な課題に対して「もれなくタスクの洗い出しをする」ことで、スケジュール作成における思考力が身につくようになる。
3. スケジュール
3.1. 概要
No. | やること |
---|---|
1 | スケジュール作成の説明 |
2 | スケジュール作成を実践 |
3 | 実践内容のフィードバック |
※ 2と3はループする
3.2. [スケジュール1] スケジュール作成の説明
スケジュール管理は「技術」です。
ですので、技術は鍛えれば誰でも習得可能です。
「技術」を細かな要素として分解した「要素技術」をマスターすることで、スケジュール管理が上達します。
要素技術は、下記の5点。今回は1を実施します。その他は、また後日開かれる勉強で実施されます。
- タスク出し(概要)
- もれなく何をしないといけないのかリストアップする
- タスク出し(詳細)
- 概要レベルを実行可能なレベルまで詳細化する
- タスク間の依存関係をだす
- どことどこが依存関係になっているのか洗い出す
- タスクごとの工数見積もり
- 担当者アサイン・開始日、終了日の記入
この説明で学びがあったのは、下記2点が大きかったです。
1. プロジェクト開始時点では、不確定要素が100%状態で、そこから要素技術1と2を繰り返して、不確定要素のパーセンテージを下げる。
不確定要素という領域が0%になることはまずなく、これがすなわち「見えていなかったタスク」になります。
では、これはどうするのかというと、「その他」として定義して「分からない部分が残っているのも、分かっていますよ」と考えます。
要は、ここがバッファになったりします。また、その他の領域は、時間がある限り掘り下げて、確定要素へと明確化していきます。
「でも実際分からないタスクは、分かりようがないですよね?」と思いますが、当初の話では「もれなくタスクを洗い出す」ため、不明点という部分もカバーして、漏れていないことになります。
なんだか解決したようでしていないような腑に落ちない気持ちがあるかもしれませんが、「100%この通りにスケジュールを進めば安全だ!」というよりも「不確定要素を可能な限り減らしたが、それでもやっぱり分からないタスクも抱えている状態で、進行する」方が、私は良いのかなと思います。
※ 参考ワード「不確実性コーン」
2. 「調査」や「分析」と言ったあいまいなワードは、使用を避けるべき。
「調査します」や「分析します」と言われても、「え?具体的には?」となるので、 「ログを見て調査します。」「前後の結果を比較して分析します。」の方が、はっきりしていて分かりやすいです。
3.3. [スケジュール2] スケジュール作成を実践
3.3.1. スケジュール項目を写経
次の項目が、スケジュール表で使う項目になります。
No. | 項目 |
---|---|
1 | 工程 |
2 | タスク |
3 | 完了条件 |
4 | 担当 |
5 | ステータス |
6 | 開始日(予定) |
7 | 終了日(予定) |
8 | 開始日(実績) |
9 | 終了日(実績) |
10 | 工数(時間) |
まずは、上記項目をスケジュール表に写経します。その後、どのような項目が必要なのか意味を理解した上で お手本を見ずに書いていきました。書き終わった後に過不足確認したところ、1つ抜けがありました。再度 チャレンジした結果、過不足なく書けたのでクリアしました。 ここで、勉強になったのは、「完了条件」という項目を忘れていたのですが、これって普段のタスク管理も 忘れがちなんだなと改めて理解しました。 最終的なアウトプットは下記のとおりです。
No. | 項目 |
---|---|
1 | 工程 (大) |
1 | 工程 (中) |
2 | タスク (実行可能なレベル) |
3 | 完了条件 |
4 | 担当 (Who) |
5 | ステータス |
6 | 開始日(予定) (When) |
7 | 終了日(予定) (When) |
8 | 開始日(実績) (When) |
9 | 終了日(実績) (When) |
10 | 工数(時間, 予定) |
11 | 工数(時間, 実績) |
Why(理由),Where(場所),How(手段)を組み込むかどうかは改善余地ありかもです。
3.3.2. 課題を実践
お題は、下記のとおりです。
[課題] グループ内で席替えを行う * 現在グループで使っているスペース内で移動する(他のグループのスペースに影響しない)
で、作ったスケジュールが下記のとおりです。
オリジナル
No. | 工程 (大) |
工程 (中) |
---|---|---|
1 | 席替えの了承を得る | チームリーダから了承を得る |
2 | いつするのか決める | 事前にこの日で枠取りする |
3 | いつするのか決める | 決めた日を移動者に事前連絡する |
4 | 席替え後のレイアウトを決める | |
5 | 誰に連絡するのか決める | |
6 | 席替えをする | |
7 | 終わった後座席表の更新をする |
うん、これで大丈夫だ!ドン!提出してみました。(恥ずかしい)
3.4. [スケジュール3] 実践内容のフィードバック
フィードバック1
No. | 工程 (大) |
工程 (中) |
---|---|---|
1 | 席替えの了承を得る | チームリーダから了承を得る |
2 | 席替え後のレイアウトを決める | |
3 | 誰に連絡するのか決める | オフィスインフラチームに連絡する |
4 | 誰に連絡するのか決める | いつ完了するのか教えてもらう |
5 | いつするのか決める | 事前にこの日で枠取りする |
6 | いつするのか決める | 決めた日を移動者に事前連絡する |
7 | 席替えをする | 実施する |
8 | 終わった後座席表の更新をする | 更新する |
1回目のフィードバックでは、工程の順序を修正してもらいました。 これは、「オフィスインフラチームに連絡する際はレイアウトを共有した上で連絡する必要がある」とのことで、「そんなの知らなかった!」となりました。これって、「知らない事、まだまだあるんじゃない?」とガクガクブルブルしました。
※ オフィスインフラチーム(社内用語)は、ネットワークの配線などをやってくれるチームのことです。
フィードバック2
No. | 工程 (大) |
工程 (中) |
---|---|---|
1 | 要件を決める | 目的を聞く(→レイアウトの配置案が決めれる) |
2 | 要件を決める | いつしたいのか聞く(→ オフィスインフラチームへの依頼になる) |
3 | 準備をする | チームリーダから了承を得る |
4 | 準備をする | 席替え後のレイアウト案出しに必要な作業を洗い出しする |
5 | 準備をする | その他 |
6 | 準備をする | 席替え後のレイアウトの案出しを決定する |
7 | 準備をする | レイアウトのレビューでOKをもらう |
8 | 準備をする | オフィスインフラチームに連絡する (レイアウトと希望日を伝えて) |
9 | 準備をする | オフィスインフラチームの作業をする(他の関係者のタスクも視野に入れる) |
10 | 準備をする | オフィスインフラチームの作業がいつ完了するのか教えてもらう |
11 | 準備をする | 事前に移動日を枠取りする |
12 | 準備をする | 決めた日を移動者に事前連絡する |
13 | 実施する | 席替えをする |
14 | クロージング | 終わった後座席表の更新をする |
2回目のフィードバックでは、
- 実行者だけでなく、関係者のタスクも考慮しておく
- ボトルネックにならないようにするため
- 決定する工程の場合、合意やレビューをしておく
- 大きく覆らないようするため
- 「見えていない作業」は、「その他」にしておく
- 知らない何かがあるかもしれないため
- スケジュールをレビューしてもらう
- 第三者の立場のコメントをもらうため
でした。特に意識したことがなかった「1. 関係者」は、勉強になりました。
開催者側コメント
初めまして。開催者の松野です。 この勉強会の目的のひとつは、「スケジュール作成は練習すればできるようになる」とメンバーに伝えることでした。 私はスケジュール作成は決して得意ではなく、漠然とした苦手意識を持っており 「向いてないのかなあ..」なんて思っていました。 上長に相談したところ、「向いていない」のではなく「技術を身に着けていない」だけというアドバイスをいただきました。(目から鱗!) それからというもの、上長に今回の勉強会のような課題を用意していただき、解く→フィードバックをもらうというサイクルを回しました。 課題を通して考え方のコツが分かったことで、以前のような漠然とした苦手意識がなくなりました。(すっきり!) 他のメンバーも同じような悩みを持っているとのことだったので、是非ともこのすっきり感を味わってもらいたく勉強会を開催しました。
勉強会を通しての気づき
何人かの課題をレビューして、つまづくポイントが似ていることに気づきました。 上記レポートにもありましたが、「関係者を明らかにする」や「合意を得るまでのプロセス定義」はほとんどの人が苦手なようです。 (私も最初は全然できていませんでしたし、実際の業務だとまだまだです) 自分を含め一緒に働く人みんながこういったことが難なくできるようになれば、仕事はもっと楽しく円滑に進むだろうなと感じました。
まとめ
「自分でできる」から「人に説明できる」へのステップアップに勉強会開催はもってこいです。 参加者の皆さんにも楽しみながら学んでもらえたようで安心しました。ありがとうございました。 気負わずに勉強会ができる環境だからこそ、今回の成果が出せたのかなと思います。 上記レポートにもあったように、続編(タスクを詳細化する編)を計画中です。 グループ内外問わず多くの方に参加いただけたらなと思っております。
感想
勉強になったことは、ところどころに書いていますが、一番の収穫は「タスクの掘り下げ方」でした。
「そのタスクの決定は、どこで決めるの?」「このタスクをするとき、認識合わせしなくて良い?」など実際に進めてから困るようなことを、ちゃんとこの時点で洗い出して考えるという大切な能力を勉強しました。
最後に
実は、今回の勉強会は私の所属しているチーム外の企画でした。にも関わらず、チームを横断して勉強会のお誘いを頂きました。 このような、チーム内だけに閉じない文化があるモノタロウは、エンジニアにとって成長させてもらえる良い環境だと感じます。