エンジニアの教養2023 #2 タスクばらし

Transcript

1. エンジニアの教養2023 #2 タスクばらし クラスメソッド株式会社 2023.05
2. Agenda 01 タスクばらしの概要 02 シンプルなタスクばらし 03 他者依存のあるタスクばらし 04 条件分岐のあるタスクばらし 05 繰り返しのあるタスクばらし 06 タスクばらしの⾒直し 2
3. 教材 • タスクばらし⼊⾨ https://zenn.dev/tbpgr/books/8562293d519b8b 3
4. 教材 • タスクばらし⼊⾨ https://zenn.dev/tbpgr/books/8562293d519b8b 4
5. 01 タスクばらしの概要 • タスクばらし = タスクを細分化して扱いやすくしていくこと • ばらすことで、タスクを管理しやすくする ◦ 割り込みに強くなる ◦ ⾒積もりしやすくなる ◦ 問題を特定‧解決しやすくなる ◦ 協⼒を得やすくなる ◦ etc. 5
6. 余談 : 「タスクばらし」の類例‧関連事項 • スケールアップとスケールアウト • コード分割‧function設計 • モノリシックとマイクロサービス • 密結合と疎結合 • スイッチングコスト ⼈間のタスク ↔ コンピュータのタスク 6
7. ポモドーロ‧テクニック • 25分集中して働き、5分休憩する • ⽣産性を⾼めつつ 精神疲労を減らすことが⽬的 https://w.wiki/Rva https://asana.com/ja/resources/pomodoro-technique 7
8. タスクがばらせる = ⾒通しが⽴てられる • 「何をやるか」が分かってないと、タスクばらしはできない • ⼀⽅で、 全てが分からないとタスクが始められないか、というとそうでもない ◦ 後述：タスクの⾒直し ◦ 全てが分かるまで待っていると遅くなる • 「ここまでは分かってなくてもイケる」 「ここの部分は分かってから進もう」 勘を養う訓練をしていこう 8
9. 実習 1 : 実際にタスクをばらしてみよう 例題 : Google Cloud 認定試験 Professional Machine Learning Engineer (PMLE) https://cloud.google.com/certification/machine-learning-engineer?hl=ja • 要件 ◦ 試験の受講フローはクラメソに準じる（不明な部分は想像して良い） ◦ 結果の合否は問わない（1回受けて合否判定をもらうまで） ◦ 開始時点でのMLに関する知識は、現在の⾃分の⾃⼰評価を基準とする ◦ ツールは指定しない ◦ 必要に応じて調査‧質問はして良い • 時間 : 15分 9
10. ポイント • ⼤きく4つのフェーズ ◦ 試験勉強（トレーニングや模試） ◦ 試験準備（アカウント作成や試験の予約） ◦ 試験 ◦ 試験後 ※並⾏して実⾏できるのは？ ※タスク間の依存関係：何かが終わらないとできないものは？ ※⾃分だけでは完結しないタスクは？ 10
11. タスクばらしの種類 1. シンプルなタスクばらし 2. 他者依存のあるタスクばらし 3. 条件分岐のあるタスクばらし 4. 繰り返しのあるタスクばらし (個⼈的⾒解) 3と4はあまり⾒ない（タスクばらしの⽬的にもよる） 11
12. 02 シンプルなタスクばらし • 他者へ依頼するタスク • 条件分岐や繰り返しのないタスク “シンプルなタスクばらしは、 タスクを細かなステップに分割していくことで実現します。 どのくらいの⼤きさまで分割するかは個々⼈の好みがありますが、 ⼤きくても半⽇以内には収まるような単位まで細分化することを おすすめします。” 12 正直ケースバイケース（後述します）
13. 03 他者依存のあるタスクばらし ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈＿ ＞ 進次郎構⽂の趣 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣ 13
14. Bardによる説明 16
15. なぜ他者にタスクをばらすのか 1. ⾃分ではできないから ◦ 権限あるいはスキル、またはその両⽅が理由 ◦ 「ほぼほぼ依頼するしかない(そうしないと完了しない)」ケース 2. ⾃分よりうまくやるから ◦ 実⾏者の技量‧時間制約：実⾏者より熟練している、準備がしてあるものに頼む ◦ 実⾏者の経験獲得の機会は失われる（⾒学は可能なこともある） ◦ 失敗できないケースなど 3. 並列実⾏：ひとりでやるより早く終わるから ◦ 実⾏者の時間制約 ◦ 実⾏者だけでも完遂可能だが、それではタイムリミットまでに終わらないケース ◦ タスクが⾮属⼈化されている必要がある 17
16. 04 条件分岐のあるタスクばらし ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈＿ ＞ 進次郎構⽂の趣 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣ 18
17. どういうときに条件分岐する？ • 先の予測がつかないとき • 予測が付かない = コントロールができない 基本的に、条件分岐は遅くなる（コストが⾼い） • 複雑な条件分岐はスパゲティコードを⽣む • なれてきたら、なるべく分岐しない（判定ヶ所を減らす）などの⼯夫を 19
18. 05 繰り返しのあるタスクばらし • （AA略 20
19. なぜツールは「繰り返し構造」をサポートしないのか • 仮説 1 : 代替表現があるから ◦ ひとつのタスクを「定期実⾏」する など ▪ ループではなくイベントドリブン • 仮説 2 : タスク管理上、繰り返し構造は好ましくない（避けるべきだ）から ◦ 1週⽬のループと2週⽬のループは本当に同じものだろうか？ ◦ ループ構造とせずに「ばらし」た（展開した）ほうが良いのでは？ 21
20. 実習 22
21. 実習 2 : 実際にタスクをばらしてみよう その2 例題 : 想像上のアプリケーション（Webアプリ or モバイルアプリ）のリリース ある年の5/19、「商⽤アプリ作ろう、オレにいいアイディアがある」と メンバーの誰かが⾔い出したので、みんなで作ることにした、という想定 • 要件 ◦ チームメンバー : 4名 ▪ 全ての分野の専⾨家がそろっているとは限らない ▪ メンバー構成と各メンバーの得意分野は全体で協議 • 基本的に全員コード書ける前提、ひとりインフラ得意、ひとりデザイン得意 ◦ リリース⽇は未定 ◦ その他、あらゆるディティールは勝⼿に想像して良い • 時間 : 30分 24
22. 06 タスクばらしの⾒直し • ここでいう「⾒直し」= タスク実⾏中の「計画変更 (Plan B)」 • 条件分岐の特殊例 ◦ 分岐ポイントがあらかじめ⾒えなかった ◦ 分岐先があらかじめ想定できなかった 25
23. 余談 26
24. 複雑なタスク間連携 タスク同⼠の依存関係 • A のタスクが終わらないと B のタスクが始められない • C のタスクは A 開始後のスタートになり、A‧B と並⾏して進められるが、 D は B と C 両⽅が終わってないと開始できない ... タスクにおける時間的制約 • P のタスクは XX ⽉ XX ⽇にならないと始められない • Q のタスクは必ず YY ⽉ YY ⽇までに終わらせないとならない • R のタスクは最低 nn 時間かかる タスクの流れがシンプルなうち（頭の中で把握できているうち）は良いが、 複雑になってきたらツールを使って管理しよう 27
25. タスクの粒度問題 “海岸線の⻑さを測定するとき、 物差しの⻑さ(測定単位)が短くなれば なるほど海岸線の⻑さは伸び、 しかもおおよそ際限がない” ──海岸線計測のパラドクス[要出典] • 複雑に⼊り組んだ地形(岩肌や砂粒) • どこまで細かく正確に計測するか？ • そもそも：波や潮汐による経時変化 • タスク完了までの時間も延びていく File:Shoreline of the Oumijima island 青海島の海岸線，海食地形 - panoramio.jpg https://publicdomainq.net/ruler-0013070/ 28
26. そのタスク、予定(予想)通りに進められると思うなよ • 時間的な⾒積もりは常に 1.5 倍に • ⾮常事態に備えて、代替プランや緩衝領域(バッファ)を常に念頭に • アラートは必ず「進⾏不可能になる前に」出す ◦ 進⾏不可能 = リカバリの時間的余裕も含めた概念(忘れがち) ◦ 「砂漠では、⽔が飲みたいと思ったら既に⼿遅れ、  脱⽔症状なのです。  喉が渇く前に⽔を飲むようにしましょう」 ▪ AWS re:Invent 2017 JAPANツアーコンダクタの⾔葉 • 割り込みを回避する技術 ◦ 割り込みを受け付ける/受け付けない時間を決めて公⾔するなど 昔からこんな本も あってですね。。 29 https://www.oreilly.co.jp/books/4873113075/
27. 悲観的に準備し、楽観的に対処せよ 危機管理評論家の佐々淳⾏⽒がよく⼝にした（らしい） • 「起こりうる最悪の事態を想定してそれに備え、  ⼀朝事あればことさら先⾏きを悲観せずに冷静に臨め」 • 転じて「計画は悲観的に、実⾏は楽観的に」など 類義 • optimistic pessimists ◦ “規模の将来予測については楽観的に（= 拡⼤するものとして）⾒積もり、 かつ運⽤の健全性（operational health）については悲観的に、 好奇⼼を持って（= 考慮漏れや改善の余地を常に探るように）あたるべき” https://mainichi.jp/articles/20200310/ddm/001/070/085000c https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ 30
28. WBS • Work Breakdown Structure • みんな⼤好き(意味深) ◦ 特定の過去を持つひとの トラウマ 思い出を深くえぐる単語 • WBS⾃体に罪はないです ◦ 類似の単語：線表‧ガントチャート • チームがチームとして、特定の成果を特定の期間内に達成するためのもの ◦ 特に⻑期間におよぶプロジェクトを進める際には必須 ◦ ウォーターフォール (そのうち)必要になったら⾝につけましょう 31