エンジニアの教養2023 #2 タスクばらし クラスメソッド株式会社 2023.05

Agenda 01 タスクばらしの概要 02 シンプルなタスクばらし 03 他者依存のあるタスクばらし 04 条件分岐のあるタスクばらし 05 繰り返しのあるタスクばらし 06 タスクばらしの⾒直し 2

教材 ● タスクばらし⼊⾨ https://zenn.dev/tbpgr/books/8562293d519b8b 3

教材 ● タスクばらし⼊⾨ https://zenn.dev/tbpgr/books/8562293d519b8b 4

01 タスクばらしの概要 ● タスクばらし = タスクを細分化して扱いやすくしていくこと ● ばらすことで、タスクを管理しやすくする ○ 割り込みに強くなる ○ ⾒積もりしやすくなる ○ 問題を特定‧解決しやすくなる ○ 協⼒を得やすくなる ○ etc. 5

余談 : 「タスクばらし」の類例‧関連事項 ● スケールアップとスケールアウト ● コード分割‧function設計 ● モノリシックとマイクロサービス ● 密結合と疎結合 ● スイッチングコスト ⼈間のタスク ↔ コンピュータのタスク 6

ポモドーロ‧テクニック ● 25分集中して働き、5分休憩する ● ⽣産性を⾼めつつ 精神疲労を減らすことが⽬的 https://w.wiki/Rva https://asana.com/ja/resources/pomodoro-technique 7

タスクがばらせる = ⾒通しが⽴てられる ● 「何をやるか」が分かってないと、タスクばらしはできない ● ⼀⽅で、 全てが分からないとタスクが始められないか、というとそうでもない ○ 後述：タスクの⾒直し ○ 全てが分かるまで待っていると遅くなる ● 「ここまでは分かってなくてもイケる」 「ここの部分は分かってから進もう」 勘を養う訓練をしていこう 8

実習 1 : 実際にタスクをばらしてみよう 例題 : Google Cloud 認定試験 Professional Machine Learning Engineer (PMLE) https://cloud.google.com/certification/machine-learning-engineer?hl=ja ● 要件 ○ 試験の受講フローはクラメソに準じる（不明な部分は想像して良い） ○ 結果の合否は問わない（1回受けて合否判定をもらうまで） ○ 開始時点でのMLに関する知識は、現在の⾃分の⾃⼰評価を基準とする ○ ツールは指定しない ○ 必要に応じて調査‧質問はして良い ● 時間 : 15分 9

ポイント ● ⼤きく4つのフェーズ ○ 試験勉強（トレーニングや模試） ○ 試験準備（アカウント作成や試験の予約） ○ 試験 ○ 試験後 ※並⾏して実⾏できるのは？ ※タスク間の依存関係：何かが終わらないとできないものは？ ※⾃分だけでは完結しないタスクは？ 10

タスクばらしの種類 1. シンプルなタスクばらし 2. 他者依存のあるタスクばらし 3. 条件分岐のあるタスクばらし 4. 繰り返しのあるタスクばらし (個⼈的⾒解) 3と4はあまり⾒ない（タスクばらしの⽬的にもよる） 11

02 シンプルなタスクばらし ● 他者へ依頼するタスク ● 条件分岐や繰り返しのないタスク “シンプルなタスクばらしは、 タスクを細かなステップに分割していくことで実現します。 どのくらいの⼤きさまで分割するかは個々⼈の好みがありますが、 ⼤きくても半⽇以内には収まるような単位まで細分化することを おすすめします。” 12 正直ケースバイケース（後述します）

03 他者依存のあるタスクばらし ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈＿ ＞ 進次郎構⽂の趣 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣ 13

Bardによる説明 16

なぜ他者にタスクをばらすのか 1. ⾃分ではできないから ○ 権限あるいはスキル、またはその両⽅が理由 ○ 「ほぼほぼ依頼するしかない(そうしないと完了しない)」ケース 2. ⾃分よりうまくやるから ○ 実⾏者の技量‧時間制約：実⾏者より熟練している、準備がしてあるものに頼む ○ 実⾏者の経験獲得の機会は失われる（⾒学は可能なこともある） ○ 失敗できないケースなど 3. 並列実⾏：ひとりでやるより早く終わるから ○ 実⾏者の時間制約 ○ 実⾏者だけでも完遂可能だが、それではタイムリミットまでに終わらないケース ○ タスクが⾮属⼈化されている必要がある 17

04 条件分岐のあるタスクばらし ＿⼈⼈⼈⼈⼈⼈⼈⼈⼈＿ ＞ 進次郎構⽂の趣 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣ 18

どういうときに条件分岐する？ ● 先の予測がつかないとき ● 予測が付かない = コントロールができない 基本的に、条件分岐は遅くなる（コストが⾼い） ● 複雑な条件分岐はスパゲティコードを⽣む ● なれてきたら、なるべく分岐しない（判定ヶ所を減らす）などの⼯夫を 19

05 繰り返しのあるタスクばらし ● （AA略 20

なぜツールは「繰り返し構造」をサポートしないのか ● 仮説 1 : 代替表現があるから ○ ひとつのタスクを「定期実⾏」する など ■ ループではなくイベントドリブン ● 仮説 2 : タスク管理上、繰り返し構造は好ましくない（避けるべきだ）から ○ 1週⽬のループと2週⽬のループは本当に同じものだろうか？ ○ ループ構造とせずに「ばらし」た（展開した）ほうが良いのでは？ 21

実習 22

実習 2 : 実際にタスクをばらしてみよう その2 例題 : 想像上のアプリケーション（Webアプリ or モバイルアプリ）のリリース ある年の5/19、「商⽤アプリ作ろう、オレにいいアイディアがある」と メンバーの誰かが⾔い出したので、みんなで作ることにした、という想定 ● 要件 ○ チームメンバー : 4名 ■ 全ての分野の専⾨家がそろっているとは限らない ■ メンバー構成と各メンバーの得意分野は全体で協議 ● 基本的に全員コード書ける前提、ひとりインフラ得意、ひとりデザイン得意 ○ リリース⽇は未定 ○ その他、あらゆるディティールは勝⼿に想像して良い ● 時間 : 30分 24

06 タスクばらしの⾒直し ● ここでいう「⾒直し」= タスク実⾏中の「計画変更 (Plan B)」 ● 条件分岐の特殊例 ○ 分岐ポイントがあらかじめ⾒えなかった ○ 分岐先があらかじめ想定できなかった 25

余談 26

複雑なタスク間連携 タスク同⼠の依存関係 ● A のタスクが終わらないと B のタスクが始められない ● C のタスクは A 開始後のスタートになり、A‧B と並⾏して進められるが、 D は B と C 両⽅が終わってないと開始できない ... タスクにおける時間的制約 ● P のタスクは XX ⽉ XX ⽇にならないと始められない ● Q のタスクは必ず YY ⽉ YY ⽇までに終わらせないとならない ● R のタスクは最低 nn 時間かかる タスクの流れがシンプルなうち（頭の中で把握できているうち）は良いが、 複雑になってきたらツールを使って管理しよう 27

タスクの粒度問題 “海岸線の⻑さを測定するとき、 物差しの⻑さ(測定単位)が短くなれば なるほど海岸線の⻑さは伸び、 しかもおおよそ際限がない” ──海岸線計測のパラドクス[要出典] ● 複雑に⼊り組んだ地形(岩肌や砂粒) ● どこまで細かく正確に計測するか？ ● そもそも：波や潮汐による経時変化 ● タスク完了までの時間も延びていく File:Shoreline of the Oumijima island 青海島の海岸線，海食地形 - panoramio.jpg https://publicdomainq.net/ruler-0013070/ 28

そのタスク、予定(予想)通りに進められると思うなよ ● 時間的な⾒積もりは常に 1.5 倍に ● ⾮常事態に備えて、代替プランや緩衝領域(バッファ)を常に念頭に ● アラートは必ず「進⾏不可能になる前に」出す ○ 進⾏不可能 = リカバリの時間的余裕も含めた概念(忘れがち) ○ 「砂漠では、⽔が飲みたいと思ったら既に⼿遅れ、  脱⽔症状なのです。  喉が渇く前に⽔を飲むようにしましょう」 ■ AWS re:Invent 2017 JAPANツアーコンダクタの⾔葉 ● 割り込みを回避する技術 ○ 割り込みを受け付ける/受け付けない時間を決めて公⾔するなど 昔からこんな本も あってですね。。 29 https://www.oreilly.co.jp/books/4873113075/

悲観的に準備し、楽観的に対処せよ 危機管理評論家の佐々淳⾏⽒がよく⼝にした（らしい） ● 「起こりうる最悪の事態を想定してそれに備え、  ⼀朝事あればことさら先⾏きを悲観せずに冷静に臨め」 ● 転じて「計画は悲観的に、実⾏は楽観的に」など 類義 ● optimistic pessimists ○ “規模の将来予測については楽観的に（= 拡⼤するものとして）⾒積もり、 かつ運⽤の健全性（operational health）については悲観的に、 好奇⼼を持って（= 考慮漏れや改善の余地を常に探るように）あたるべき” https://mainichi.jp/articles/20200310/ddm/001/070/085000c https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/ 30

WBS ● Work Breakdown Structure ● みんな⼤好き(意味深) ○ 特定の過去を持つひとの トラウマ 思い出を深くえぐる単語 ● WBS⾃体に罪はないです ○ 類似の単語：線表‧ガントチャート ● チームがチームとして、特定の成果を特定の期間内に達成するためのもの ○ 特に⻑期間におよぶプロジェクトを進める際には必須 ○ ウォーターフォール (そのうち)必要になったら⾝につけましょう 31

No content