【Scrum Fest Osaka 2022】スクラムチームに放り込まれた若手エンジニアの皆さん、どのように技術のキャッチアップをしていくかイメージはついていますか？

Scrum Fest Osaka 2022 セッション の発表資料です。
タイトル：『スクラムチームに放り込まれた若手エンジニアの皆さん、どのように技術のキャッチアップをしていくかイメージはついていますか？』

プロポーザル：https://confengine.com/conferences/scrum-fest-osaka-2022/proposal/16580

Transcript

1. スクラムチームに放り込まれた若手エンジニアの皆さん

   どのように技術のキャッチアップをしていくか

   イメージはついていますか？

   

   Retty, Inc 髙橋 幹 / Miki Takahashi

   Scrum Fest Osaka 2022 

   

   View Slide

2. 自己紹介

   髙橋 幹 / Miki Takahashi

   Software Engineer / iOS Application 

   ● 大学

   ○ 情報系を学ぶ、趣味ではiOSがメイン 

   ○ コーヒーが好きで4年間カフェでアルバイト 

   ● 21年度の新卒 エンジニア 

   ○ 入社 4月 〜：Webメインのチームへ 

   ○ 10月 〜：アプリメインのチームへ 

   

   好きなこと：コーヒー・料理・ベース・カメラ 

   

   View Slide

3. このセッションの概要

   テーマ：複数のスクラムチームを渡り歩いて見つけた、技術キャッチアップの方法とそれに関する学び 

   ● Rettyの開発体制について 

   ● Rettyに入社しからの挑戦 

   ● 新たにソフトウェア開発に参加する時にまずすること 

   ● 「初めてやること」はペアワークなどでキャッチアップする 

   ● Working Out Loudによる自己発信の実践 

   ● チーム開発をしながら学んでいくために意識したこと 

   

   

   View Slide

4. View Slide

5. Rettyの開発体制の紹介

   Rettyでは、LeSS(: Large-Scale Scrum) を導入しています。 

   To B Web
 ✖3

   To C Web
 ✖2

   App
 ✖1

   分析
 ✖1

   インフラ
 ✖1

   Productivity
 ✖1

   PdM

   デザイナー

   CS

   バックログ

   PO

   ※ 全チーム SMはエンジニアが兼任している

   ※ 部門横断でLeSSの動きとは外れているチームもある

   ※ 全チーム1週間スプリントです

   プロダクトを良くすること 
 プロダクトを安定運用すること 

   

   View Slide

6. Rettyに入社してからの挑戦

   入社前のバックグラウンド 

   ● 情報系の学科で学びつつ、 iOSアプリ開発が長かった 

   ● 個人開発や、スタートアップでの開発がメインで、 大規模な開発の経験が無い 

   入社後

   ● LeSSでの開発に参加 していく

   ● To C Web のプロダクト開発 

   ● Androidアプリ開発やBFF開発 

   

   To C Web
 App

   入社　4月
 10月
 現在

   

   View Slide

7. どうしてWebチームで修行に？

   長期的に、Rettyでより広い影響範囲をもって開発できるようになるため 

   ● WebとAppがバラバラに開発されるのは本意では無い 

   ○ WebとAppが協力してプロダクトを作っていく動きを強めるのは必須 

   ● アプリよりWebのメンバーが多い 

   ○ よく知っている人が多い人が、長い目で見ると働きやすいのでは？ 

   ● より幅広くRettyのドメインを把握する 

   

   ※ 不本意な配属では無いです
   󰢏

   ※「RettyのエンジニアとしてWeb開発の技術を身につけてね」というものでは無いです
   󰢏

   

   View Slide

8. Rettyの開発体制の紹介

   To B Web
 ✖3
   To C Web
 ✖2
   App
 ✖1
   分析
 ✖1
   インフラ
 ✖1
   Productivity
 ✖1
   PdM

   デザイナー

   CS

   バックログ

   PO

   

   View Slide

9. どうしてWebチームで修行に？

   長期的に、Rettyでより広い影響範囲をもって開発できるようになるため 

   ● WebとAppがバラバラに開発されるのは本意では無い 

   ○ WebとAppが協力してプロダクトを作っていく動きを強めるのは必須 

   ● アプリよりWebのメンバーが多い 

   ○ よく知っている人が多い人が、長い目で見ると働きやすいのでは？ 

   ● より幅広くRettyのドメインを把握する 

   

   ※ 不本意な配属では無いです
   󰢏

   ※「RettyのエンジニアとしてWeb開発の技術を身につけてね」というものでは無いです
   󰢏

   

   View Slide

10. 入社後Webチームで学ぶ必要があるもの

    聞いたことはあるけど触れたことのない物ばかり　 

    ● スクラム開発・LeSSのお作法 

    ● Rettyのプロダクト

    ○ 旧環境：PHPのモノリス + フロントエンドをマウントするvue.js 

    ○ 新環境：Goのマイクロサービス + Nuxt.js 

    ○ AWS周りの知識もたまに... 

    ● アプリとは違う基礎的な開発力 

    ○ HTML / CSS・Web・http・ブラウザ 

    ○ DBアクセス・ネットワーキング・デバッグ方法 

    ● 諸ドメイン知識

    

    View Slide

11. 入社後Webチームで学ぶ必要があるもの

    聞いたことはあるけど触れたことのない物ばかり　 

    ● スクラム開発・LeSSのお作法 

    ● Rettyのプロダクト

    ○ 旧環境：PHPのモノリス + フロントエンドをマウントするvue.js 

    ○ 新環境：Goのマイクロサービス + Nuxt.js 

    ○ AWS周りの知識もたまに... 

    ● アプリとは違う基礎的な開発力 

    ○ HTML / CSS・Web・http・ブラウザ 

    ○ DBアクセス・ネットワーキング・デバッグ方法 

    ● 諸ドメイン知識

    → 一気に学ぶことはできないので、少しずつキャッチアップしていく必要がある。 

    

    View Slide

12. Good First Issueで開発の流れを知る
    

    View Slide

13. スプリントでの開発を一通り体験する

    リファインメント → スプリントプランニング → 実装 → レビュー → 検証 → リリース 

    一番小さいストーリーで、開発の型・お作法を知る
    ● チケット（ストーリー）に書いてある内容を知る
    ● 変更を加えつつ動作確認する
    ● コーディング環境を最低限整える
    ● レビューを依頼する
    ● 検証環境を知る
    ● リリースフローを知る
    一通り体験すると、1つのストーリーをDoneにするのにどれくらいの時間がかかるのか分かる
    

    View Slide

14. 初めて触れることは、一度おんぶに抱っこになろう
    

    View Slide

15. ペアワークで開発業務をどんどん学んでいく

    本当に初めてのものは、ほんっっっっとうに分からない。 

    ● AWS / Datadog / IDE
    ○ 操作もだけれど、単語が特に分からない
    ● DBアクセス / ネットワーキング
    ○ SQLClientでDBアクセスしてゴニョゴニョしたことない
    ○ CLI操作で動作させるのあまりやらない
    ● 環境構築 / リリースフロー
    ○ 古いレポジトリはあまり整備されていないことも ...
    

    View Slide

16. ペアワークで開発業務をどんどん学んでいく

    本当に初めてのものは、ほんっっっっとうに分からない。 

    ● AWS / Datadog / IDE
    ○ 操作もだけれど、単語が特に分からない
    ● DBアクセス / ネットワーキング
    ○ SQLClientでDBアクセスしてゴニョゴニョしたことない
    ○ CLI操作で動作させるのあまりやらない
    ● 環境構築 / リリースフロー
    ○ 古いレポジトリはあまり整備されていないことも ...
    怖がらず、おんぶに抱っこされてみましょう！！

    

    View Slide

17. ティーチングのステップ

    トレーナー視点の3ステップ 

    サクッと教えてもらって、サクッと試して、
    なおかつチームメンバーと同じように作業できるようになるには
    このステップを小さな単位で、素早く回すことが大切
    1. やって見せる 2.やってもらう 3.フォローアップする
    

    View Slide

18. ペアワークで基礎を、モブワークで更にキャッチアップ

    初めて使うものは “ペアワーク” で自信を持って使えるようにする
    ● 3stepのおかげで「多分あってるよな〜、よし。」で終わらない
    ● エンジニアは割とフォローアップが好き
    ○ この操作、簡単にできるよ
    ○ こういうツールあるよ
    慣れてきたら “モブワーク” で雑談しつつ作業をして、色々教えてもらう
    ● 「やりたいこと」に対して
    「何をすれば良いのか」と「どうしたらそれが出来るのか」
    を効率よく学べる
    ● 雑談して、関連知識を色々教えてもらうのも大切
    → 気づいたら調べながら自分でできるようになってくる
    

    View Slide

19. Slackで自分の状況を発信し続けよう
    

    View Slide

20. Slackで状況を発信し続けよう

    入社して間もなく、Working Out Loudという言葉を知りました。 

    ● 自分の状態を発信し続ける
    ○ 勉強中は学びの過程を発信する
    ○ 無謀な挑戦をしている時は止めてくれる
    ○ 頑張っているのに「何をしているかあまり分からない」というのは勿体無い！
    ● 作業ログを残す
    ○ うまくいかない時に初めてログを残すのではなく、うまくいっている時から残しておく
    ○ 未来の自分や他人が助かるかもしれない！
    ● 助けを求める
    ○ 後に詳しく
    Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成
    

    View Slide

21. 具体的な状況を発信をしよう

    抽象的な文句を言っても、盛り上がるだけで目の前の問題の解決はしない 

    ● 具体的な文句を言うと、一緒に戦ってくれることがある
    ○ 無謀な挑戦をしようとしていると、止めてくれる
    ● 「自分で1人で行けるところまでやってみたい」という時ほど、何をしているかの発信はしておこう
    ○ 分からなくなった時に、何をしていたかも大抵分からなくなる
    ● 「この人は、こういう手順で学ぶんだな」というのを知っている方が、周りも学習を手伝える
    

    View Slide

22. 質問をしよう・言語化をしよう

    「質問するのが苦手」というあるあるにどう立ち向かうか 

    

    

    結局、何が分からないのか分かっていなくて、質問に踏み出せない
    ● 「何が分からないのか」や「何を知りたいのか」を言語化する
    ● つまづいたら自分と対話をして、自分の状況をメタ認知する
    ○ 「分からないこと」が分かったら、次に進む or 質問する
    ○ 「分からないこと」が分からなそう
    → キャパオーバーです！！！助けを求めよう！！！
    発達の最近接領域みたいなお話です、
    

    View Slide

23. 自分と対話をしよう

    自分と対話をして「分かっていないこと」を炙り出していく 

    自問自答して、範囲を小さくつつ繰り返し、言語化する。
    自分で答えられなくなったら助けを求める
    自分と対話している過程を Slackに残しておくと良さそう。
    What
    やりたいことは何？
    Why
    なぜやるの？
    HOW
    どう変更する？

    Where
    どこを変更する？

    

    View Slide

24. ラフに助けを求めよう

    「分からないこと」が分からない時は、どうしようもないケースが多い。 

    ● 自分の知識が足りなくて言語化できない
    ● 勘違いをしていて、何度確認しても分からない
    ● 聞いたこともないドメイン知識が関連する
    ● 「みんなが一度は踏む地雷」や「秘伝の何か」がある
    → 足掻いたってどうしようもない。 1人で解決できるかは運次第、、
    

    View Slide

25. 技術領域を広げてデリバリーに貢献しよう
    

    View Slide

26. アプリチームでの技術領域拡大の必要性

    iOSアプリ開発メインの人間が、AndroidアプリとBFF開発へ挑戦 

    アプリチームでは iOS / Android と アプリ向けのバックエンド（ BFF）開発している
    ● アプリを通して「Rettyならではの価値」を強めていきたい
    ● iOS / Android / バックエンド を分担性で進めては、ベロシティが上がらない
    Web開発に放り込まれるよりはハードルが低かった
    ● 同じ施策を複数プラットフォームで開発する
    ● BFFの成果物をクライアントで使うので、アプリ開発と繋がっている
    → チーム「興味があるならやってみよう 👍」
    

    View Slide

27. 技術領域を広げるためにどんなことをしたか？

    自分のメイン業務に関連が深いところから、PR読みやペアプロで触れてみる 

    ● PRレビューなどを通して、 iOSで実装したロジックと Androidのそれを見比べてみる
    ○ こういうところからkotlinに慣れていく
    ○ 自分の持っている技術と、キャッチアップしたい技術の差分を見比べて、
    初見のものは調べてみる・聞いてみる
    ○ 同じ「やりたいこと」に対して、実装はどういうふうに違うのか学べる
    ● 実際に、自分のメインの業務に関連が深いところからペアプロなどで触れてみる
    ○ まずはチーム内のProに聞く
    ○ なんとなく概要を掴んでからチュートリアルなどで学ぶ
    

    View Slide

28. 技術領域を被らせて良かったこと

    デリバリーに向けて、自分の切れるカードが増えた 

    ● 繋ぎ込みの時に予期していないことが起こった時の初動が早くなる
    ● 開発の会話をできる人が増える
    ● フィーチャーチームの柔軟性が上がる
    ○ 出来ることが増えると、チームでデリバリーをしていく意識が上がる
    Rettyでより広い影響範囲をもって開発できるようになれそうですか？ 

    ● なれます。なれてます。とても楽しくやらせてもらってます。
    

    View Slide

29. まとめ

    ● まずGood First Issueで開発の全体感を抑える
    ● 初めてのことは、ペアワーク
    ○ 「やってもらう」「やってみる」「フォローアップしてもらう」
    ● 慣れてきたことは、モブワーク
    ○ 話しつつ作業をして、出来ることを増やす
    ● Working Out Loudの実践
    ○ 自分と対話をして、状況を発信をする
    ○ 自分から、学ぶ環境を整備する
    ○ うまく行ってる時から常に共有する
    ● 自分のメインの領域と近い領域から広げていく
    ○ PRをみつつ、技術をキャッチアップできる
    ● 出来ることが増えると
    ○ 「チームで開発する」ということに目が向くようになる
    ○ 「デリバリーへの貢献」を実感できて、満足度が高い
    

    View Slide