この素晴らしい新⼊社員と ペアプロを! 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?