_Gunso_AktskGeekLive_LT会資料_20220224_スライド用.pptx.pdf

Transcript

1. - 入社1年目の主張 -
   大規模プロジェクトの開発に
   ジョインして見えてきた
   "Good & More"
   

   View Slide

2. 自己紹介
   軍曹 / Daiya Tasaki
   • 21卒 クライアントエンジニア
   • 入社前
   • VR研究 @ 東大 あの人研
   • VRゲーム開発 @ DMM
   • 入社後
   • 大規模プロジェクトのクライアントエンジニア
   

   View Slide

3. 今回のゴール
   

   View Slide

4. 今回の目次
   1. スクラムでアジャイル開発
   2. 目指すべきはゴリラじゃない
   3. コードに対する意識変化
   1. 継ぎ足された秘伝のタレ
   2. 俗人化
   GOOD
   MORE
   

   View Slide

5. Good
   

   View Slide

6. Good1. スクラムでアジャイル開発
   アジャイル開発
   • 関係者は目的の達成のためにお互いに協力し合いながら進める
   • 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
   • 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する
   (『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
   』 から引用)
   スクラム
   • アジャイル開発のやり方の一つ
   • 固定化されたチーム、短い期間で「計画
   →実行→観測→改善」を行うというもの
   (チーム内の説明から引用)
   

   View Slide

7. Good1. スクラムでアジャイル開発
   実際に仕事がしやすい！
   • 安定している：スケジュール的にタイトな場面は今のところない
   • レスが早い　：プランナーにもデザイナーにも
   QAにもラフに相談できる
   個人開発では体感できない「仕事の枠組み」
   • この規模だからこそ、仕事の枠組みが大切なのだと思える
   • 「いいやり方」「枠組み」を考える機会に恵まれた
   

   View Slide

8. View Slide

9. Good2. 目指すべきはゴリラじゃない
   ゴリラ
   • ゴリラは、霊長目ヒト科ゴリラ属（ゴリラぞく、
   Gorilla）に分類される構成種の総称。 ( Wikipedia から引用)
   

   View Slide

10. Good2. 目指すべきはゴリラじゃない
    ゴリラ
    • ゴリラは、霊長目ヒト科ゴリラ属（ゴリラぞく、
    Gorilla）に分類される構成種の総称。 ( Wikipedia から引用)
    

    View Slide

11. Good2. 目指すべきはゴリラじゃない
    ゴリラ
    • スーパースターエンジニア (『スクラムを失敗させる51のアンチパターン』 から引用 )
    

    View Slide

12. Good2. 目指すべきはゴリラじゃない
    ゴリラ
    • スーパースターエンジニア (『スクラムを失敗させる51のアンチパターン』 から引用 )
    ゴリラの習性
    • 一人の人間（シニアデベロッパー、技術リーダー、エグゼクティブ）が会話を支配している
    • ゴリラが話すまで、人は話さない
    • チームメンバーはゴリラの意見に従う
    (『Scrum Community Wiki』から引用)
    

    View Slide

13. Good2. 目指すべきはゴリラじゃない
    ゴリラ
    • スーパースターエンジニア (『スクラムを失敗させる51のアンチパターン』 から引用 )
    ゴリラの習性
    • 一人の人間（シニアデベロッパー、技術リーダー、エグゼクティブ）が会話を支配している
    • ゴリラが話すまで、人は話さない
    • チームメンバーはゴリラの意見に従う
    ゴリラの弊害
    • チームは、決定したことを信じられなくなる
    • 本当のチームは、決して形成されない
    • 意思決定が一元化されるため、最適でない意思決定が行われる
    (『Scrum Community Wiki』から引用)
    

    View Slide

14. Good2. 目指すべきはゴリラじゃない
    要は……
    スーパースターエンジニアに「強く依存しちゃいけない」という話
    チームでは、この問題の回避のため、ペア/モブプログラミングが積極的
    に採用されています (めっちゃいい！)
    

    View Slide

15. Good3. コードに対する意識変化
    他の人のことを考えるようになりました
    • この変数名は本当にリーダブルだろうか？
    他の人から見ても理解しやすいだろうか？
    • 良い設計をチームで作り上げるためには、自分が人に説明できないといけない
    …
    そもそも自分が人に説明できるくらい、良い設計に対する解像度を上げよう！
    • 「工数を最小に抑える」とは、エンジニアだけの工数を考えればいいんだっけ
    …？
    この機能を、こう実装した場合、
    QAさんのチェックが重くなりそうだ…
    • バグの原因が分かった、プランナーさんにはどう説明しよう
    …
    わかりやすい言葉はないだろうか？
    

    View Slide

16. 同じ本を読んだ時でも、実感が伴うように
    

    View Slide

17. More
    

    View Slide

18. More1. 継ぎ足された秘伝のタレ
    • If文の嵐
    • めちゃ長メソッド
    • GODクラス
    

    View Slide

19. 粛々とやっていくしかない……
    

    View Slide

20. More2. 俗人化
    • ある機能を正確に把握した人が限られている
    • コメントやドキュメントは乏しい
    

    View Slide

21. More2. 俗人化
    • ある機能を正確に把握した人が限られている
    • コメントやドキュメントは乏しい
    ペアプロはいいぞ
    

    View Slide

22. まとめ
    大規模プロジェクトにジョインされた結果……
    MORE
    1. タレが濃いので薄くしています 🍹
    2. ペアプロして、俗人化解消！ 🤝
    GOOD
    1. スクラムでアジャイル開発ができた 💪
    2. 目指すべきはゴリラじゃなかった 🦍
    3. コードに対する意識が変化した 🖥
    

    View Slide