「過保護にならない程度のサポート」エピソード
司会者：では、ここからは@t_wadaさん（和田卓人氏）のモデレーションのもと、いろいろと対話をしていきたいと思います。
和田卓人氏（以下、和田）：ではお願いします。ということで、ここからはslidoにいただいた質問の中でアップボートの多いものを中心にうかがっていきたいと考えています。時間の中でできる限りのことをやっていきます。みなさんslidoのサイトを知っていると思いますので、追加の質問や「この質問を聞いてみたいな」というものがありましたら「いいね」、アップボートをしていただければと思います。
今日の質問は、けっこうガチな技術系の質問と、育成系の質問が良い感じに混ざっています。ちなみに僕はネットワークに関していうと素人で、ガチ技術系の質問自体は「なるほど。わからん」という感じなので、それも含めていろいろうかがっていきたいと思います。
まずは育成系からいきましょうということで、「『過保護にならない程度にサポート』の塩梅が難しいと思いますが、具体的なエピソードを教えていただけますか？」。良い質問なので、まずはこれからいきたいと思います。
木村安宏氏（以下、木村）：ご質問ありがとうございます。確かに難しい部分ではあると思います。特に新入社員2年目の方に多いんですが、どうしても指示を待ってしまう方が多いと思います。そういう時は、いわゆるコーチングとティーチングというんですかね。なるべくサポートして、まずはコミュニケーションの中で本人のやりたいことを聞き出していきます。
僕らが十分にサポートして、安心してもらってチャレンジすることを促しています。あとは過保護にならないところでいうと、例えば伝送とかでベテランがいればすぐに設定ができますが、それをあえてせずに実際に試してもらって失敗することをやってもらっています。どうしようもなくわからなくなったらサポートしたり、例えば「ここを見るとわかるよ」ということを教えたりしています。
和田：ありがとうございます。いきなりトップバッターで良い質問をしてもらえたなと思っています。ここはけっこう難しいんですね。実際にいろいろな企業でも「言うは易し」というのは、まさに塩梅なんですよね。塩梅が難しいので、このあたりを聞いていてもいわゆる「コントロールされた失敗から学ぶ」機会をたくさん作ることを大事にしているんだなということが、いろいろ見て取れたなと思います。ありがとうございます。
ということで、みなさんにもどんどん投票してもらえればと思っています。今けっこうアップボートが集まっていてありがたいです。
WhiteBoxならではの苦労
和田：では早めに上がってきた技術系の質問でいきます。「伝送装置はWhiteBoxならではの苦労はありましたか？」という質問をもらっています。いかがでしょうか？
木村：そうですね。WhiteBoxはディスアグリゲーションという言い方になると思います。伝送装置はもともとは1個の箱の中で全部完結していたものをディスアグリゲーション、要素ごとに分割して、その分割した1つがWhiteBoxとなっています。なので、今までは1個の箱の中でなにも考えずにその機能が使えていました。
例えばアンプとDemux、これがバラバラになったことで細かいところでいうとどうつなぐかとか、つないだ時のパワーのバランス調整などが今までありませんでした。このあたりがディスアグリゲーション、WhiteBoxの難しかったところだと思います。
和田：ありがとうございます。これで「もうちょっといろいろと聞きたい！」という場合は、バンバンと質問も追加でもらえればと思います。
私も「なるほど」と（思いました）。中身に関してはわからないから身も蓋も（笑）。僕の守備範囲が違って「なるほど＝完全に理解した」になっちゃうので、どんどん先にいきたいと思います。ということでババッと上がったものがあって、一気に9票（入りました）。
兼務した場合の成果・評価の取り扱い
和田：新しい質問ですが、一気に入ったものがあり、兼務（について）の話です。「メンバーは兼務（20パーセント稼働）とありましたが、兼務で実施した業務の成果や業績評価などの取り扱いはどのように工夫されておりますでしょうか」。「特に社内副業的なスキームを利用していますか」とか、そういったものも含めた工夫に関して質問が上がってきています。これは一気に（視聴者からの投票が集まり）急上昇した質問です。
木村：ありがとうございます。こちらはいろいろな要素があるんですが、まずNTT CommunicationsではCoE（Center of Excellence）という、技術者を育成する資金があります。この取り組みもその1つとして扱っているので、エンジニアで学びたい人が自由に応募できるシステムがあります。それで応募してきた方が参加しています。
評価に関してですが、僕らは運用側として年に2回、活動に対するフィードバックや改善点を、そのメンバーの上長に対して送っています。その上長がそれを見て活動を評価するようになっています。
和田：なるほど。じゃあそれも含めて社内で回すようなかたちにしているんですね。ありがとうございます。けっこう大きめの企業になると、兼務の度合いが大きくなってきます。兼務と評価はいつも頭を痛くする問題になっているんですよね。質問が上がってから一気にババッと9票入ったのは、そのあたりが背景なのかなと考えています。
ノウハウ共有のやり方
和田：今日は時間があと6分、7分ぐらいなので、アップボートが多いものからどんどん回していきます。（画面を示して）これは7票（入っている質問）で、けっこう前からじわじわと上がってきているものということで、ノウハウ共有に関してですね。
興味のあるチームで構成して解体も含めてやっているというところで、運用が変わってきたところを講演でうかがってきました。その上で、ノウハウの共有をどうやっていくかは一種の課題にはなってくると思うので、ここでどうされているかをうかがいたいと思います。
木村：ご質問ありがとうございます。まずチームが12個あると言いましたが、3ヶ月か4ヶ月に一度、各チームでの活動報告会を設けています。そこでどのチームが何をしたかがわかるように薄く広く紹介しています。それ以外にも勉強会を設けていて、そこでは特定のテーマや特定のチームが1時間発表する機会を設けています。
また、Slackを使っているんですが、Slack（のチャンネル）もオープンにしているし、ファイルとかも全身見えるようになっているので、興味がある人はSlackを覗きつつ質問を出せるようにすることをやっています。
和田：ありがとうございます。そのようなかたちでワッと集まってきて、いわゆるチームを横串に刺した知見の共有などをどうやって一定期間で回していくかが大事なテーマだったりするので、そのあたりをいろいろうかがいたいという質問なのかなというのを背後の考えとしては受け取りました。ありがとうございます。
本番環境でないと起こり得ないことをどう再現するか
和田：時間がないのでどんどん回していきます。次は「素人質問ですみません」と。「Lab内で現実のトラフィックを再現するために、どんなことをしていらっしゃいますか？ 普通のWebサービスならカナリーリリースだったりトラフィックをコピーしてステージングに流したりとかしますが、それはできないと思うので気になりました」。
（つまり）「現実のトラフィックとかを再現するために、いわゆる本番環境でないと発生しえないことを再現するためにどういう工夫をしていますか？」という質問かなと思います。
木村：そうですね。まさに我々のLabにはユーザーがいます。常時500人ぐらいが使っている規模感になるので、それがいわゆる生活トラフィックの再現かと思っています。それだけでは足りない部分に関しては、当たり前ですがテスターを使ってトラフィック負荷をかけたり、テスターに関してもいろいろなパターンをコピーして再現しています。
ただ、基本的にはユーザーがいるので、ユーザートラフィックを見てそれを現実のトラフィックに置き換えています。
和田：ありがとうございます。そもそもLabを作って回している動機の1つとして、こういう活動自体を常時行えるようにする環境を作り、共有して、公開するという意図があるという話ですよね。ありがとうございます。
Labから出た技術・人材のプロダクトへの反映方法
和田：どんどんいきます。（画面を示して）これもおもしろい良い質問ですね。6票入っています。「Labから出た技術、人材のプロダクトへの反映などはどのように実施されておられますでしょうか？」という質問がきています。
木村：良い質問だと思います。検証した技術に関しては、いろいろな事業部に紹介しています。時にはその事業部が困っていることを聞いて、実際にLabで検証をして僕らが答えることもあります。使った技術が100パーセントそのままプロダクトになることは少ないですが、Labで培っている要素、例えば自動開発ツールがプロダクトに使われることがけっこうあります。
人材に関しても同じで、Lab環境で使っている装置（を実際にプロダクト開発で使ったり）や、技術をLabで学んだ人が実際にプロダクト開発を（したり）しています。
和田：そうなると、プロダクト開発とそのLabとの間で人材流動というか、行ったり来たりとかも含めて学べるようなチーム構成にもなっている感じですね。
木村：そうですね。かつ受け入れはR＆D以外もやっているので、プロダクト側から「この技術を学びたいから」ということで（Labに来た人を）受け入れることもあります。
和田：ありがとうございます。
“ユーザー”の定義
和田：今日配信を見ている方の（中には）ネットワークとか大規模システムをよく知っている方もいれば、知らない方も……。僕も含みますが、（知らない方も）います。
そこで、先ほどからチラッと出てきている「ユーザー」という言葉があるんですが、このユーザーの定義。「常時ユーザーが500ユーザー」みたいな話をしましたが、「ここで言うユーザーとは何ですか？」ということを一度補っておかないといけないなと思いました。突発的な質問ですが、お願いします。
木村：そのとおりです。ここで言う「ユーザー」は、Labを使って検証している人だけ（のこと）ですね。Labを使ってプロダクト開発や技術開発をしていたりする人のことを「ユーザー」と呼んでいます。なので、実際のお客さまではなく、社内のエンジニアのことをユーザーと呼んでいます。
和田：実際にB to CのWebにおけるユーザー一人ひとりのことを指しているのではなくて、そもそもの単位として指しているものが違うという話ですね。
木村：はい。大変失礼しました。
和田：ありがとうございます。いえいえ。これは知っている人と知らない人でたぶん大きく解離があるものなので、補ったほうがいいのかなと思いました。ありがとうございます。
和田氏が若手育成の際に気をつけていること
和田：ということで、時間がもうないな。最後の1問が僕に上がってきてしまった。「＠t_wadaさんにも質問してみたいです。若手を育成する時に、特に気をつけていることはありますか？」というので、実はもう今日のお話の中に出てきているんですが、過保護になりすぎないようにする（ことです）。
ティーチングとコーチングを使い分ける。コーチングをしなきゃいけない時もあります。ティーチングをしなきゃいけない時もあります。いろいろあるんですね。あとはコントロールされた失敗の機会をなるべく数多く提供する。このあたりが大事なんじゃないかなと考えています。
ということで、（ご質問）ありがとうございます。今日の質疑応答自体はそろそろ終わりにします。他にも質問をたくさんいただいていて（いましたが）、全部捌けなくて申し訳ありません。特にガチ技術系の質問がいっぱいきていたので、そのあたりをどこかで拾えればという感じではあります。
