リモート新人教育で起きた“違和感”　ソフトウェアエンジニアが語るベアメタルの“癒着”ストーリー

自己紹介と業務内容

花川直己氏（以下、花川氏）：「この素晴らしい新入社員とペアプロを！」というタイトルで、NTT Ltd Japanの花川直己が発表します。よろしくお願いします。まず簡単に自己紹介ですが、naosukeとよく呼ばれている者です。NTT Ltd Japanでソフトウェアエンジニアとして働いて、3年目になります。

ふだんはEnterprise Cloud 2.0（ECL2.0）というクラウドサービスのベアメタルサーバーや、専用ハイパーバイザーと呼ばれるメニューの開発をRubyでしています。趣味で社内イベントや研修の講師もやっています。

「ECL2.0 is 何ぞや？」という話なんですが、2016年に開始している企業向けのクラウドサービスです。日本6拠点、海外6拠点でサービス展開をしています。

その中でベアメタルサーバーは、物理サーバーをオンデマンドで貸し出すサービスです。ユーザーがAPI経由でサーバー作成したり、電源操作したりできます。

我々としては、このAPIを受けるものを作ったり、その裏側で物理サーバーを手懐けてOSをデプロイしたり。あとはネットワークを手懐けている、別のコントローラーをAPI経由で呼び出して、ネットワークの設定を入れてもらったり。

VPNの設定を物理機器に投入するようなことを手懐けるコントローラーを開発しています。ここまで前説です。詳しくは、私の先輩が昔発表している資料があるので、そちらを見てください。

新入社員の登場とペアワークで実施したこと

ここから本題です。2020年5月、Johnという名前でチームに新入社員がやってきました。ピカピカの社会人1年生、新卒で入ってくれたニューカマーで、なんと専用絵文字は歩くx86が登録されています。

全社員研修とか受けているときに、ずっとリモートでやっていたので、社内ではリモートネイティブ世代と言われています。

学生時代はGoをメインで書いていたようです。新入社員なので、僕の1つ上の先輩社員がメンターとしてついて。僕も技術メンターというかたちで名前があがりましたが、ほぼなにもできていない状況です。

先輩社員によって、ひととおりのオンボーディングをやっていました。チームで顔合わせをして、ベアメタルや専用ハイパーバイザーの全体説明をしたり。あとはチームでの仕事の進め方、チケットの流れや、レビューの流れを経験してもらったり。

あと、運用担当と言われる、毎日交代の定型業務があるんですが、その仕方も教えています。

すべてリモートでやっていて、基本的には画面共有しながら、先輩社員と一緒にペアワークをしていました。まず先輩社員が一連のお手本を見せて、そのあとフォローしながらJohn自身でやってみるかたちです。

このオンボーディングが終わると、タスクとしてリリースのクリティカルパス。すごく重要な機能や、「これがないとリリースできません」のようなところには入らない改善系のチケットをやってもらって、いろいろ知ってもらおうとアサインしました。

先ほど言った、当番でやっている運用業務のコマンドラインを実装したり、ログ監視周りを改善してもらったりしていました。わからないことはリアルタイムというより、まとめてもらって、Daily scrumのときに、メンターや先輩社員に直接聞くなどしてもらいました。

一連が終わると、「まあ慣れたやろ」ということで、独り立ちしてくれと放り投げて。それ以降、スクラムの原則に従って事前にタスクの優先度を決めているので、1つずつ上からピックしてやっていくかたちで仕事を進めてもらっていました。

半年後に違和感を覚えた

半年くらいそういう状況をやってもらうと、働きぶりを見て、僕から見てちょっと違和感が出てきました。

勘違いしてほしくないのが、決して「仕事が遅い」とか「お前は仕事ができていない」とかではないです。すごく粛々とがんばってくれていますが、ちょっと違和感があった。

具体的にどういうものかと言うと、さっき言ったクリティカル、「これがないとリリースできない」みたいなチケットではなく、改善系のチケットばかり取っている。「なくてもリリースできるけど、あるとうれしいよね」というチケットをよく取っていると。

あと、こういうチケットを取ったあとに、チケットが全部終わって出来上がるまでに、少し時間がかかってしまっているな、と。2週間スプリントをしているんですが、2スプリントくらいかかったり、1スプリント半かかったりがチラチラと見えました。

時間が比較的かかっているわりに、日々のDaily scrum、スタンドアップミーティングでは本人から「ちょっと困っているんです」という声も、僕から見るとあんまり見えていませんでした。

これを見ると、ちょっと個人的に「ちょっとヤバいのかなぁ」と思ってしまいました。何が具体的にヤバいと思ったのかと言うと、大きく2つあって。Johnがアラートをあげていないという問題。あともう1つは、難しいチケットに取り組めていないのは、実は取り組む機会がうまく取れていないのでは、という問題です。

（スライドの）左側はチームに馴染みきれていないからこそ、質問しづらくて難しい。困ったときにアラートをあげづらいのかな、と思いました。

右側は、僕はけっこうチケットをどんどん上から取っていっちゃうような人間なので、難しい優先度の高いものを、先にほかの人が取っちゃっている問題があるのかなと。

スクラムとしてやっているので、ある程度は仕方がない部分もありますが、やはりちょっと難しめのチケットをやって、力をつけていったほうが、働く側としてもうれしいのかなと思いました。

これは両方とも僕が勝手に想像している問題なので、実際はこの状態ではわからないものでした。要するに問題は、チームビルディングがうまくできていない問題と、Johnの成長機会が奪われている問題です。

悶々として書き込んだポエムにリアクション

そんなことを考えながら、僕は悶々としていました。よくやっているんですけれども、深夜お酒を飲みながら自分の分報に……僕はポエムってよく言うんですが、よくポエムを書き込んでいます。

そういった中の1つで、「ふとお酒を飲みながら、年明け1月からJohnとつきっきりでペアワークでもしようかなとか思い始めた」と書き込んでみました。これはさっきの「難しいチケットが取れない」とか、「ヘルプをお話しづらい」という話なら、じゃあ一緒に仕事すればいいじゃん、という。そういう雑なソリューションです。

とは言いながら、これは深夜テンション、かつ、お酒を飲みながらのテンションなので。とりあえず思いついただけで、1週間くらい考えてから実施しようかなとニコニコしながら考えていたら、次の日見たらなんと「やりたい。お願いします」というリアクションがついた。

誰がつけたをよく見ると、John本人がつけてくれていました。これをつけられるとね、やはり先輩としては「もうやるしかない」と思っちゃうので、Johnと仲良くなる、という意味で“癒着”というタイトルで前向きにイベントを計画して、よっしゃやっていくぞといろいろ計画を始めました。

癒着のはじまり、はじまり

さあ、癒着のはじまり、はじまりです。今までこういうことをあまり前向きにやったことがなかったので、ちょっとまじめに考えてみました。なんと一晩、23日に考えて24日に思いついて、その日のうちにガーッとConfluenceのページに書き上げました。

僕自身がどういう問題を感じていたかと、ペアワークするならどういうふうにやったらいいかを、とりあえず案として、いくつかガーッと書き出しました。この時点では癒着が、将来オンボーディングとしてけっこう有効なのかなと、僕自身意識しながらいろいろ考えてみました。

これだけだと「お前の中ではそうなんだろ」のような感じになっちゃうので。Johnに「どうして乗り気だったの？」と聞いてみました。やはり本人もいくつか不安を感じていたようで、難しいチケットに1人で手を出すにはためらいがある。躊躇してしまい、1人で全部チケットをDoneにできるようなものを取りがちだった、とか。

あとは、ベアメタルに関する開発知識が本人的に足りないと思っていたようです。ペアプロや癒着で一緒にやっていくことで、質問しやすいとか。そういったものができるかと期待してくれていたようです。

あと、初めて社会人になって一緒に働いているので、先輩やほかの社員が、どんなふうにタスクをこなしているかがやはり気になる、ということがありました。これは僕にとって意外な視点でした。

ベアメタルの辛いポイント

「半年して開発知識が足りないって、どういうこと」という話ですが、ベアメタルはけっこう辛いポイントがいくつかあって。

コンポーネントが多いとか、ソフトウェアだけでなく、物理サーバーとかほかの物理機器の知識がけっこう必要になるなど、普通のソフトウェア開発ではなかなか経験できない問題があります。

これらは口頭で伝えていく秘伝の知識になってしまいがちで、ドキュメントがあまりなかったり、あったとしてもちょっと探しづらいところにあるとか。けっこうサーチビリティが低いドキュメントが多かったです。

知識的な問題と、あと開発環境的に手元で動作確認ができない問題とか。テストが辛い問題などがありました。物理機器があるので、ある程度は手元で動かないのは、当然ですけれど。

なによりもテスト環境で動かすテストがすごく辛くて。まずテスト環境がみなさんお馴染みの巨大戦艦Jenkinsが、7年モノで動いています。物理機器のステートが存在するので、Unit Testが少しガチャり気味（※再現性がなく不安定な状態）だという問題。

あとIntegration Testです。結合テストが環境を作ったりするのに、「この状態だったらこのタスクを流すといいよ」という、少し暗黙的な職人芸が実は必要になったり。開発自体もいろいろ難しいものがありました。

2019年以前だと、同じ職場で顔を合わせて仕事していたので、「ちょっといいですか？」とホワイトボードを使って説明してもらったり、気軽に質問がしやすかったんですが。

2020年、ほぼリモートでお仕事しているわけなので、「ちょっといいですか？」というのが、やはりハードルとして高くなってしまう問題がありました。我々のチームとして、リモートでイチから全部教えるのも、ほぼ想定できていなかった問題も新しく見えてきた感じです。

こんな辛いポイントがありながら、逆に解消していかなきゃいけないということで、「やりたい」とチームに提案しました。「いいですか？」というよりもほとんど「いいよね？」という、「goしてよ」という勢いで提案しました。

「具体的にどうやるの？」のようなHowの質問は出ましたが、やること自体にはありがたいことに反対意見が出なかったので、「じゃあやろう、やるしかない」のような感じで。けっこうチームにも助けてもらって「よし、やっていこう！」という状態でした。

癒着で取り組む作業の決定

こういうHowを考えながら、具体的にどういうタスクをやろうか考えました。最初は一緒にふだんの1日の仕事をやろうかと考えたんですが、提携的な業務はそれなりに1人でこなせるので、難しいタスクを一緒にやりたいという本人からの意向もあって、一緒だからこそできる、ちょっと難しめのタスクをやろうと決定しました。

というわけで、さっき見せた図のうち、我々が開発しているベアメタルコントローラーと、ほかのチームが開発しているネットワークを司るコントローラーを結合する部分のバグを修正しようとなりました。

選んだ理由としては、期限付きで来ている、わりとめずらしいタスクだったのと、ベアの中でもほかの部分と結合していて、ほかのリソースモデルとの情報の整合性などを取らないといけない、けっこう複雑に作り込まれている場所だったのと。

これは笑い話ですが、僕が仕込んだバグを修正するチケットだったので、僕がなにをやらかしたかが一番よくわかっているものだったので、僕として教えやすいというメリットもありました。

癒着で実施した具体的な内容

ここまでいろいろ考えて、そんなこんなで「よっしゃ、やっていこう」と癒着を開始しました。当初は1日90分という枠の中で、1日90分を何日か続けていく感じで計画して、やっていました。

環境としては、VSCode LiveShareというプラグインを使って、かつGoogle Meetで画面共有をしながら一緒にやっていました。なにかを動かしてみたいときは、Johnの画面を共有してもらったうえで、一緒に開発環境やIntegration Test環境にSSHしてもらって、Johnが操作するかたちを採りました。

僕はそれを見ながら、適宜コメントをしたり、わからなさそうだったら解説したりしました。最初は特に交代は設けていなくて、ずっとJohnが操作、僕がサポーターでアドバイスを出すかたちで、決め打ちしていました。

途中で戸惑っていたり、わかっていないところをなんとなく感じとったら、僕が指針を示して、「こうやるといいよ」「ここはこうなっていてね」と教えるようなかたちでやっていました。

（次回につづく）