Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
この素晴らしい新入社員とペアプロを! / Pair-programming with wond...
Search
naosuke
February 26, 2021
Programming
2
1.9k
この素晴らしい新入社員とペアプロを! / Pair-programming with wonderful newcomer!
NTT Tech Conference #5 にて発表した「この素晴らしい新入社員とペアプロを」の資料です.
スライド中のhow-to-create-baremetalのリンクは
こちら
naosuke
February 26, 2021
Tweet
Share
More Decks by naosuke
See All by naosuke
クラウドサービスのウラオモテ / Outside and Inside of Cloud Services
hanasuke
0
1.4k
学生サークルとOSCのつながりとこれから
hanasuke
0
340
マルコフ連鎖でツイート生成
hanasuke
0
1.5k
TouchBarを触りたかった話
hanasuke
2
1.6k
ふりかえりを実践した話
hanasuke
0
250
Other Decks in Programming
See All in Programming
気をつけたい!Desktop対応で陥りやすい罠とその対策
goto_tsl
0
190
DevTools extensions で 独自の DevTool を開発する | FlutterKaigi 2024
kokiyoshida
0
420
競技プログラミングで 基礎体力を身につけよう / You can get basic skills through competitive programming
mdstoy
0
140
Discord Bot with AI -for English learners-
xin9le
1
110
Functional Event Sourcing using Sekiban
tomohisa
0
130
テストコード文化を0から作り、変化し続けた組織
kazatohiei
2
510
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
3
850
事業成長を爆速で進めてきたプロダクトエンジニアたちの成功談・失敗談
nealle
3
1.2k
Arm移行タイムアタック
qnighy
0
400
Jakarta EE meets AI
ivargrimstad
0
1.1k
WebAssembly Unleashed: Powering Server-Side Applications
chrisft25
0
2.1k
Reckoner における Datadog Browser Test の活用事例 / Datadog Browser Test at Reckoner
nomadblacky
0
190
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
How to Ace a Technical Interview
jacobian
276
23k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Scaling GitHub
holman
458
140k
Speed Design
sergeychernyshev
25
650
Imperfection Machines: The Place of Print at Facebook
scottboms
266
13k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Transcript
この素晴らしい新⼊社員と ペアプロを! Naoki Hanakawa / NTT Ltd Japan
whoami Naoki Hanakawa (@naosuke|hanasuke|naosuke2dx) Software Engineer at NTT Ltd Japan
• NTT Com(2018⼊社) -> NTT WT(2020年⼊社) -> NTT Ltd Japan ECL2.0 ベアメタルサーバ/専⽤ハイパーバイザ開発チーム所属 • 普段はRubyを書いて⽣きています • 趣味で社内のイベントや研修の講師なども naosuke2dx
About Enterprise Cloud 2.0 (ECL2.0) ɾ։࢝ͷΫϥυαʔϏε ɾຊڌւ֎ڌͰαʔϏεల։த
About BaremetalServer (BM) Chassis SSL VPN Baremetal Controller Switch (D-plane)
Switch (D-plane) Switch (St-plane) Switch (St-plane) Block Storage (iSCSI) File Storage (NFS) Chassis FW VM LB VM Interne t GW VPN GW Internet MPLS VPN ... Storage Plane Data Plane Collocation Inter Connect (10G/1G) Collo- cation Rack Network Controller ユーザによる操作 Tenant Logial Network IPMI IPMI (via SDN Controller) • サーバ作成/削除 • 電源操作/BootOrder変更 • メディア接続 • UEFIパラメタ変更 • BMCアクセス(over SSLVPN) 詳しくは http://bit.ly/how-to-create-baremetal
2020年05月,チームに新入社員がやってきた!
• 名前はjohn • ピカピカの社会⼈1年⽬ • 専⽤絵⽂字は 「 」 • 「リモートネイティブ」世代
• 学⽣時代はGoを書いてブイブイいわせていた • メンター: 4年⽬社員 (先輩社員) • naosukeは技術メンター › しかしnaosukeはほぼ何もせず 新⼊社員 john
⼀通りのオンボーディング (by 先輩社員) ⇒ このご時世なので,すべてリモートで実施 • 環境セットアップを題材に… • レビューの流れ •
プルリクの出し⽅ … などなど • チームメンバーの⾃⼰紹介 • お互いへの質問コーナー • 他チームとの関係紹介 チームでの顔合わせ • BM/DHのサービス仕様 • 内部コンポーネントの構成 • デプロイの流れ BM/DHの全体説明 お仕事のススメ⽅ • “運⽤担当”と呼ばれる当番業務 • 問い合わせ対応 • E2E監視の対応 当番制の定型業務
⼀通りのオンボーディング (by 先輩社員) ⇒ このご時世なので,すべてリモートで実施 • 環境セットアップを題材に • レビューの流れ •
プルリクの出し⽅ … などなど • チームメンバーの⾃⼰紹介 • お互いへの質問コーナー • 他チームとの関係紹介 チームでの顔合わせ • BM/DHのサービス仕様 • 内部コンポーネントの構成 • デプロイの流れ BM/DHの全体説明 お仕事のススメ⽅ • “運⽤担当”と呼ばれる当番業務 • 問い合わせ対応 • E2E監視の対応 当番制の定型業務 画⾯共有してペアワークとして実施 • 先輩社員による⼀連のお⼿本 • 先輩フォローによるjohn⾃⾝での業務実施
オンボーディング後のタスク • リリースのクリティカルパスに⼊らない改善系のチケットを実施 • 運⽤業務⽤のコマンドCLI実装 • ログ監視周りのCLI実装 • わからないことはDaily scrumの後にメンターに直接聞くなどしていた
• それ以降は,スクラムの原則に従って優先度の⾼いタスクをとっていく
そんな感じの状態が続いた12⽉頃 • ふと,johnの働きぶりをみて違和感が… • 決して「仕事ができてない」わけではなく,粛々と頑張ってくれているのだが… › 改善系(クリティカルでないもの)のチケットをよくとっている › チケットを持ってからDoneにするまで,時間が⽐較的かかりがち ›
⼀⽅で,Daily scrumで「やばい」という声は特に上がらない
そんな感じの状態が続いた12⽉頃 • ふと,johnの働きぶりをみて違和感が… • 決して「仕事ができてない」わけではなく,粛々と頑張ってくれているのだが… › 改善系(クリティカルでないもの)のチケットをよくとっている › チケットを持ってからDoneにするまで,時間が⽐較的かかりがち ›
⼀⽅で,Daily scrumで「やばい」という声は特に上がらない これはまずいのでは…? naosuke
johnがアラートを上げづらい問題 • チームに馴染みきれていない? • → 難しい問題に取り組み⾟い • → 困ったときにhelpを求め⾟い naosukeの考える「良くないポイント」
難しいチケットを取り組む機会がない問題 • そもそも難しいチケットを他の⼈が先⾏でや っちゃっている • スクラムとしてやっているので, 仕⽅がない部分もあるが…
johnがアラートを上げづらい問題 • チームに馴染みきれていない? • → 難しい問題に取り組み⾟い • → 困ったときにhelpを求め⾟い naosukeの考える「良くないポイント」
難しいチケットを取り組む機会がない問題 • そもそも難しいチケットを他の⼈が先⾏でや っちゃっている • スクラムとしてやっているので, 仕⽅がない部分もあるが… チームビルディング うまくできていない問題 johnの成⻑機会が 奪われている問題
悶々としていた12⽉ • 深夜,酒を飲みながらふと思いついたことを分報に書き込む • 「難しいチケットを取れない/ヘルプを頼みづらいなら, ⼀緒に仕事すればいいじゃない!」みたいな雑なソリューション • 「まあ,深夜テンションで思いついたし書き込んでおいて後⽇考えよう…」
本⼈からも前向きなリアクションがつく • なんと「やりたい」とか「お願いします」というリアクションがつく • 誰がつけたかと思うとjohnがつけていた…! • 本⼈が前向きならやるしかねえな…! • → イベント名「癒着」として前向きに計画して「やっていき」していくことに
癒着の計画
Slackの発⾔の翌⽇… なおすけが⼀晩でやってくれました • 前述の問題点も含めて,Confluenceに⼀気に まとめ上げる • 今までチームでペアワークをする⽂化がほぼ なかったため,具体的なやり⽅についても案 をいくつか考える •
「癒着」が将来的なオンボーディングへの 布⽯になることを意識しつつ…
⼀⽅でjohnに聞き込み 「乗り気だった理由」を聞いたところ, 本⼈もいくつか不安を感じていた様⼦ • 難しいチケットに⼿を出すのに躊躇 • ⼀⼈で⾛れそうなものをとりがち • BMに関する開発知識が不⾜ •
ペアプロで質問しながらしてみたい • 他の⼈のタスクのこなしっぷりを⾒てみたい
⼀⽅でjohnに聞き込み 「乗り気だった理由」を聞いたところ, 本⼈もいくつか不安を感じていた様⼦ • 難しいチケットに⼿を出すのに躊躇 • ⼀⼈で⾛れそうなものをとりがち • BMに関する開発知識が不⾜ •
ペアプロで質問しながらしてみたい • 他の⼈のタスクのこなしっぷりを⾒てみたい
• コンポーネントが多く複雑 • ソフトウェアの知識だけでなく, 物理サーバの知識が必要 • ドキュメントがあまり存在しない ベアメタル⾟いポイント • ⼿元(local)で動作確認/テストができない
• テストが⾟い • 使い込まれた巨⼤戦艦Jenkins (7年モノ) • Unit Testはガチャる • Integration Testは職⼈芸が必要 これまでは職場でホワイトボードを使って説明 現地で「ちょっといいですか」気軽に質問が可能 2019年以前 職場に⾏くことはほぼ無く,リモートコミュニケーション 「ちょっといいですか」の難易度が⾼くなる 2020年
• コンポーネントが多く複雑 • ソフトウェアの知識だけでなく, 物理サーバの知識が必要 • ドキュメントがあまり存在しない ベアメタル⾟いポイント • ⼿元(local)で動作確認/テストができない
• テストが⾟い • 使い込まれた巨⼤戦艦Jenkins (5年モノ) • Unit Testはガチャる • Integration Testは職⼈芸が必要 これまでは職場でホワイトボードを使って説明 現地で「ちょっといいですか」気軽に質問が可能 2019年以前 職場に⾏くことはほぼ無く,リモートコミュニケーション 「ちょっといいですか」の難易度が⾼くなる 2020年 これまでリモートをほぼ 想定していなかった問題
そんなこんなでチームに提案 • ほとんど「やるけどいいよね?」みたいな勢いで提案 • どのタスクをやるか,どれくらい時間をかけるか,みたいなHowの質問は多く出た • ⼀⽅で,やること⾃体の反対意⾒はなく「やっていき」状態だった
• 普段の業務を⼀緒にやるという案が出た • → ⼀緒だからできるタスクにしよう BaremetalController -> NetworkControllerの結合の修正 • 「2⽉までに修正したい」という期限付き
• BMの中でも特に複雑な部分 • naosukeが仕込んだバグなので教えやすい やるタスクの検討
そんなこんなで癒着開始
当初の進め⽅ • 1⽇90分 • VSCode LiveShare+Google meet • なにか動かしてみたいときなどは画⾯共有した上でjohnが開発環境で調査 •
naosukeはmeetを⾒ながら適宜コメントしたり解説したり › 特に「解説タイム」などは設けず,悩んでそうなタイミングで介⼊ • Driverはjohn,Supporterはnaosukeで決め打ち • 途中とまどったり「わからない」みたいなところでnaosukeが指針を⽰す
当初の進め⽅ 2⽇ほどやってみたがなんだか様⼦がおかしい… うまくいかない… • 1⽇90分 • VSCode LiveShare+Google meet •
なにか動かしてみたいときなどは画⾯共有した上でjohnが開発環境で調査 • naosukeはmeetを⾒ながら適宜コメントしたり解説したり › 特に「解説タイム」などは設けず,悩んでそうなタイミングで介⼊ • Driverはjohn,Supporterはnaosukeで決め打ち • 途中とまどったり「わからない」みたいなところでnaosukeが指針を⽰す
ふりかえってみる • 毎回癒着が終わったときにふりかえってみた • KPTよりもっとラフに › 今⽇の感想などを書く程度 • これをベースに,翌⽇やり⽅を変えてみる •
もちろん「これいい感じ」も書いていく
• ⼿が⽌まったな…悩んでるんかな • リアクションないな…⼤丈夫かな johnの状況をうまく把握できていない ⾒えてきた問題 • 理解してるけどどう実装しようかな ⽐較的⻑考してしまう •
そこはわかってるんだけど, 詳しく説明してくれてる… ⾃分の状況をうまく伝えれていない naosuke john よくあるリモートならではの コミュニケーションミスが発⽣していた
• ⼿が⽌まったな…悩んでるんかな 「⻑考タイム」は邪魔をしない • リアクションないな…⼤丈夫かな 引き続きうまい⽅法を考えてみる 問題点を修正してやっていき • 理解してるけどどう実装しようかな ⽐較的⻑考してしまう
→ 考えたい/整理したいときは 「⻑考タイム」を宣⾔する • そこはわかってるんだけど… 今何しているかを⼝に出してみる naosuke john お互いコミュニケーションを重視するのが重要
• ここはこんな処理を書けばいいのに • ここはこういう感じ,なんだけど 説明難しい… ⼝頭で話すだけでは限界が… さらに⾒えてきた問題 • コードをどう書こうか思いつかない •
ここの挙動がどうなっているのか わからない… naosukeは普段どう書いてるんだ… naosuke john 指⽰を出すだけは限界が来た もともとjohnが知りたいことが知れていない
ちくしょうこうなったらペアプロだ! Driver/Supporterをちゃんと交代するようにして,お互いコードを書いていくことに • johnがDriverのときは… • 質問OK,むしろnaosukeは敢えて黙ってたり • 「ここどう書くかわからない」をコメントで残したり⼝頭で話したり • naosukeが書いているときは
• johnの質問に答えたり,解説をしたり › だいたいこれでnaosuke分の時間を使い切る この形式を採⽤して,振り返りながら少しずつやり⽅を⼯夫していくと いい感じになってきた…!
最終的に落ち着いた環境 • Google meetによる画⾯共有 • john/naosukeの画⾯を常に表⽰ • お互いが他⽅の画⾯共有を表⽰して,いつでも⾒合える状態に • VSCode
+ LiveShareによる同期 • お互いのカーソル位置まで反映されるため,追っかけやすい • ただし,複数ペインに分けると厳しくなるので,Google meetなどと併⽤が必要 • iPad Pro + Apple Pencilでお絵かきアプリ(naosukeのみ) • 複雑なリソースモデルなどは,図を書いて解説
少しずつ試⾏錯誤しながら…2⽉上旬 \問☆題☆解☆決☆/\( ゜ヮ゜)> \(゜ヮ゜)/ \(゜ヮ゜)/ <(゜ヮ^ )/ コードもマージされ,癒着完了!
癒着をやってどうだったか johnの感想と個人的な考察
良かった!!! • 気軽に質問できる • 質問を通して周辺知識が⼊りやすい • 他の⼈の仕事の進め⽅を通して学べる • コードを書くときの動きや, 開発環境での動作確認⽅法
• ドキュメントに未記載なノウハウ • コードの道標が出してもらえるので, ⻑考が減ってスムーズ ペアプロが終わった後の感想ヒアリング 改善の余地あり • 2⼈分の稼働が使われているという意識 • もっと早く進めたいという焦ったり • 待ち時間などがムダなのかなと不安になる • お互いのコミュニケーション負荷が⾼い • 理解度をはかるとか • ⾃分の考えを発信するとか • 90分でも体⼒を消耗する • しかし,短すぎるとタスクが⻑引く
メリット • わからないことを気軽に聞ける空気ができる • アイスブレイクするきっかけとなりうる • ドキュメントに書ききれない細かいノウハウ を伝授できる • タスク以外の周辺知識の伝授ができる
• 理解度に応じた知識のインプットができる オンボーディングとしてのペアプロの考察 考慮するべき点 • なんだかんだ体⼒を使う • 気合でどうにか(ry • ペアプロ⾃体が合う合わないありそう • 理解度の⾒極めや,適切なタスクの設定が難 • 時期や⼈によってかなり変わってくる 初⼿ペアプロして終わりというより, 継続して定期的にやっていくのが良さそう
ぼくのかんがえるペア(プロ|ワーク)ベストプラクティス 新入社員+既存メンバという構成で
EditorはVSCode+LiveShare • なんだかんだとても優秀 • お互いの使いやすい環境でコードが書ける • 開発環境での操作はtmux sessionを共有 • まあ定番ですね
環境⾯ meetなどを利⽤して画⾯共有も⾏う • コードの共有というより, 個⼈の仕事の進め⽅の共有 • iPadの画⾯共有も使いながら図解 › Jamboardなどを使ったほうが,後か ら再利⽤ができるので◎ ⼤事なのは,お互い「何をやっているんだろう」と ムダな忖度をできるだけなくすこと
90min〜120minを1セッションとし, きちんと休憩を挟む • お互い脳に想像以上に負荷がかかるため • 知らない知識などにぶつかりまくる • 新⼊社員の理解度をはかる • ⾃分の考えを喋りながらコードを書く
• これを超えるとお互い集中⼒が落ちてくる 時間設定 Driver timeを⾮対称にする • 新⼊社員: 20〜30m • ペアプロ中に多くの処理を⾏う必要がある › コードの理解,説明の理解,実装… • 既存社員: 15m • 古いひとたちは,実装だけにほぼ専念でき るため割と⼿がはやくうごく
やっていることは全て⼝に出す • ⼀般的なペアプロでも同様 • Driver → Supporterの情報提供 • 意外と慣れてない⼈も多いので少しずつ •
最初は「今〜を実装しています」ぐらい • 慣れてきたら⾊々しゃべってみる 忖度のオーバーヘッドをなくす(再掲) 気をつけること コードを書きすぎない • 先輩社員向けの注意点 • 物知りなので書きすぎる • コメントを書く/指針のコードを書く程度で • 外部APIの呼び出し⽅ • 簡単なPoCっぽいものなど あくまで,新⼊社員のパワーアップするのが⽬的 「俺TUEEEEE」は別の機会にやるように
ペアプロ後はふりかえる 新⼊社員側のメリット • 困ってることが本当に解決できてるかを発信できる 先輩社員側のメリット • 新⼊社員の困ってるポイントを知るきっかけ • この営み⾃体が対象の新⼊社員にあってるかどうかを評価できる •
より効果的にパワーアップを促せるにはどうしたらいいかを考えられる • 結果的には,チーム全体のパワーアップにつながる
おわりに
まとめ • 新⼊社員相⼿におしかけて,癒着していった • オンボーディングとしてペアプロが想像以上に有効であることに気づけた • 「最初期にやって終わり!」ではなく,機会を空けながら定期的にやっていくのが良さそう • 新⼊社員も,ドキュメント化されてないものに悩むことが増える •
新しい知識のインプットや,暗黙的にこなしてる部分を明らかにするチャンス • 環境が整ってきており,リモートでもかなりやりやすくなってきた! • とはいえ,相⼿の理解度とかをはかっていくのはたいへん • → 俺たちの癒着はまだ始まったばかりだ!
We are hiring!
any questions?