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


自己紹介
 髙橋 幹 / Miki Takahashi
 Software Engineer / iOS Application 
 ● 大学
 ○ 情報系を学ぶ、趣味ではiOSがメイン 
 ○ コーヒーが好きで4年間カフェでアルバイト 
 ● 21年度の新卒 エンジニア 
 ○ 入社 4月 〜：Webメインのチームへ 
 ○ 10月 〜：アプリメインのチームへ 
 
 好きなこと：コーヒー・料理・ベース・カメラ 


このセッションの概要
 テーマ：複数のスクラムチームを渡り歩いて見つけた、技術キャッチアップの方法とそれに関する学び 
 ● Rettyの開発体制について 
 ● Rettyに入社しからの挑戦 
 ● 新たにソフトウェア開発に参加する時にまずすること 
 ● 「初めてやること」はペアワークなどでキャッチアップする 
 ● Working Out Loudによる自己発信の実践 
 ● チーム開発をしながら学んでいくために意識したこと 
 


No content

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週間スプリントです
 プロダクトを良くすること 
 プロダクトを安定運用すること 


Rettyに入社してからの挑戦
 入社前のバックグラウンド 
 ● 情報系の学科で学びつつ、 iOSアプリ開発が長かった 
 ● 個人開発や、スタートアップでの開発がメインで、 大規模な開発の経験が無い 
 入社後
 ● LeSSでの開発に参加 していく
 ● To C Web のプロダクト開発 
 ● Androidアプリ開発やBFF開発 
 
 To C Web
 App
 入社　4月
 10月
 現在


どうしてWebチームで修行に？
 長期的に、Rettyでより広い影響範囲をもって開発できるようになるため 
 ● WebとAppがバラバラに開発されるのは本意では無い 
 ○ WebとAppが協力してプロダクトを作っていく動きを強めるのは必須 
 ● アプリよりWebのメンバーが多い 
 ○ よく知っている人が多い人が、長い目で見ると働きやすいのでは？ 
 ● より幅広くRettyのドメインを把握する 
 
 ※ 不本意な配属では無いです 󰢏
 ※「RettyのエンジニアとしてWeb開発の技術を身につけてね」というものでは無いです 󰢏


Rettyの開発体制の紹介
 To B Web
 ✖3 To C Web
 ✖2 App
 ✖1 分析
 ✖1 インフラ
 ✖1 Productivity
 ✖1 PdM
 デザイナー
 CS
 バックログ
 PO


どうしてWebチームで修行に？
 長期的に、Rettyでより広い影響範囲をもって開発できるようになるため 
 ● WebとAppがバラバラに開発されるのは本意では無い 
 ○ WebとAppが協力してプロダクトを作っていく動きを強めるのは必須 
 ● アプリよりWebのメンバーが多い 
 ○ よく知っている人が多い人が、長い目で見ると働きやすいのでは？ 
 ● より幅広くRettyのドメインを把握する 
 
 ※ 不本意な配属では無いです 󰢏
 ※「RettyのエンジニアとしてWeb開発の技術を身につけてね」というものでは無いです 󰢏


入社後Webチームで学ぶ必要があるもの
 聞いたことはあるけど触れたことのない物ばかり　 
 ● スクラム開発・LeSSのお作法 
 ● Rettyのプロダクト
 ○ 旧環境：PHPのモノリス + フロントエンドをマウントするvue.js 
 ○ 新環境：Goのマイクロサービス + Nuxt.js 
 ○ AWS周りの知識もたまに... 
 ● アプリとは違う基礎的な開発力 
 ○ HTML / CSS・Web・http・ブラウザ 
 ○ DBアクセス・ネットワーキング・デバッグ方法 
 ● 諸ドメイン知識


入社後Webチームで学ぶ必要があるもの
 聞いたことはあるけど触れたことのない物ばかり　 
 ● スクラム開発・LeSSのお作法 
 ● Rettyのプロダクト
 ○ 旧環境：PHPのモノリス + フロントエンドをマウントするvue.js 
 ○ 新環境：Goのマイクロサービス + Nuxt.js 
 ○ AWS周りの知識もたまに... 
 ● アプリとは違う基礎的な開発力 
 ○ HTML / CSS・Web・http・ブラウザ 
 ○ DBアクセス・ネットワーキング・デバッグ方法 
 ● 諸ドメイン知識
 → 一気に学ぶことはできないので、少しずつキャッチアップしていく必要がある。 


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

技術領域を被らせて良かったこと
 デリバリーに向けて、自分の切れるカードが増えた 
 ● 繋ぎ込みの時に予期していないことが起こった時の初動が早くなる ● 開発の会話をできる人が増える ● フィーチャーチームの柔軟性が上がる ○ 出来ることが増えると、チームでデリバリーをしていく意識が上がる Rettyでより広い影響範囲をもって開発できるようになれそうですか？ 
 ● なれます。なれてます。とても楽しくやらせてもらってます。

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