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

by akatsukinewgrad

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

今回のゴール

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Good

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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