$30 off During Our Annual Pro Sale. View Details »

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

Seigo Watanabe
July 07, 2023
2.9k

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

Seigo Watanabe

July 07, 2023
Tweet

More Decks by Seigo Watanabe

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