NTT Tech Conference #5 にて発表した「この素晴らしい新入社員とペアプロを」の資料です． スライド中のhow-to-create-baremetalのリンクはこちら
この素晴らしい新⼊社員とペアプロを!Naoki Hanakawa / NTT Ltd Japan
View Slide
whoamiNaoki Hanakawa (@naosuke|hanasuke|naosuke2dx)Software Engineer at NTT Ltd Japan• NTT Com(2018⼊社)-> NTT WT(2020年⼊社) -> NTT Ltd JapanECL2.0 ベアメタルサーバ/専⽤ハイパーバイザ開発チーム所属• 普段はRubyを書いて⽣きています• 趣味で社内のイベントや研修の講師などもnaosuke2dx
About Enterprise Cloud 2.0 (ECL2.0)ɾ։࢝ͷΫϥυαʔϏεɾຊڌւ֎ڌͰαʔϏεల։த
About BaremetalServer (BM)ChassisSSLVPNBaremetalControllerSwitch(D-plane)Switch(D-plane)Switch(St-plane)Switch(St-plane)BlockStorage(iSCSI)FileStorage(NFS)ChassisFWVM LBVMInternet GWVPNGWInternetMPLSVPN...StoragePlaneData PlaneCollocation Inter Connect(10G/1G)Collo-cationRackNetworkControllerユーザによる操作Tenant LogialNetworkIPMIIPMI(via SDNController)• サーバ作成/削除• 電源操作/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に関する開発知識が不⾜• ペアプロで質問しながらしてみたい• 他の⼈のタスクのこなしっぷりを⾒てみたい
• コンポーネントが多く複雑• ソフトウェアの知識だけでなく，物理サーバの知識が必要• ドキュメントがあまり存在しないベアメタル⾟いポイント• ⼿元(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?
hanasuke
usamik26
jmatsu
syumai
gregonnet
ancaghenade
mukky620
munetoshi
honma12345
hitokun
fornewid
mraible
colly
hursman
cherdarchuk
notwaldorf
destraynor
philhawksworth
philnash
keavy
thekraken
paigeccino
rocio