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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. Bardによる説明
    16
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

20. 実習
    22
    

    View Slide

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

    View Slide

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

    View Slide

23. 余談
    26
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

29. View Slide