社内勉強会で専門的技術力を高めるには

サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯（ヤフー内のスキル任命制度／ネットワーク・セキュリティ）に任命していただいています。¹

先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書いてみませんか？」との突然のDMが。「ホントですか！」と思わず返事をしてしまい、この記事の執筆が決定しました。

普段技術ネタが多いこのTech Blogですが、いつもと少し趣向を変えて、自分が主催している社内勉強会の様子と勉強会を通じて専門的技術力を高めるために大事と考えていることを少し紹介したいと思います。

その技術をどう学ぶかの方法論も、学ぶ

今回のLTのお題「専門的技術力を極めるための極意」といっても、何かを覚えればすぐ達成、と簡単にいかないことは皆さんも実感しているでしょう。やっぱり日々の行動の積み重ねしかありません。しかし積み重ねろと言われても、「何をどう積み重ねたらいいのか？」「何かを繰り返していれば本当にスキルは上がるのか？」といった疑問がわいてしまい、いろいろ不安を感じる方も多いのではないでしょうか。しかしいくつか大事なことを意識しながら数年間繰り返し技術を学んでいくと、驚くほどスキルが上がっていくエンジニアをこれまで何人も見てきました。

どこで見たのかというと、自分が主催していた社内勉強会の参加者からです。

私の前職では、若いメンバーと一緒にサイ本を読む「JavaScript勉強会」を開催していました。ヤフーに転職してからは、以下のスライドに書いてあるとおりNode.jsサポートチームメンバーで「Node Core API勉強会」、社内公募で集まったメンバーとCDNチームの若手とともに「TLS勉強会」を実施しています。

いずれの場合も、私が見ても羨ましいほどメキメキ技術力を付けてメンバーが勉強会を巣立っていきます。若いっていいなぁとほんと痛感します。

過去自分が主催した社内勉強会を振り返ると、当初意識してなかったのですが、専門的な技術内容を理解してもらうだけでなく、どうやってその技術を学ぶのかといった方法論みたいなものも一緒に学んでもらったような気がします。少人数で膝を突き合わせながら、一つの専門テーマについて長期間じっくり取り組む。もちろん人によって伸び方は違いますが、これを続けると経験上2〜3年後には十分スキルアップしたメンバーの姿を見ることができています。

毎週2時間、発表者の担当が終わるまで次に進みません。2時間で数行しか進まないこともよくあります。1つの担当が終わるまで2〜3カ月かかることも珍しくありません。「勉強会に参加すると、集中し過ぎで終わった後にものすごくおなかがすく」と感想を漏らしているメンバーもいました。「この勉強会が会社に入ってから一番キツイ仕事だった」とありがたいお言葉も参加者からいただいています。みんな苦労した分、身につけたことが血となり肉となり自分のスキルがひとつ上にレベルアップしていることを実感しているはずです。

その仕様になった経緯を探る

Node Core API勉強会では、APIマニュアルをカテゴリー別に分類し担当者を決め、基礎的なものから順に1行ずつ解説してもらっていました。画面をその場でスクリーンに写し、担当者がライブコーディングをしながらAPIの動作確認していきます。私は説明を聞きながら、「こういう動作になったのはなぜ？」、「こう変えたらどうなるの？」の質問を繰り返します。その都度、APIマニュアル・言語仕様・ソースコードを見ながら解説してもらいます。どうしてこんな仕様や実装にしたのかわからない時は、GitHubのPull Requestやissueを見つけ出し、その経緯を探り当てます。

よくあるサーバー・クライアント間通信に伴うAPIでは、挙動全体を見渡すためホワイトボードにフローを書いてもらい説明してもらいます。すると担当者が、真っ白なホワイトボードの前でうーんと悩んで長時間立ちすくんでたりする。時間切れとなり「来週までに宿題！」といってまた次週そこからスタート。しかし翌週になって「まずは前の週の振り返りから」と始めるとうまく説明できない。あらあら「先週の始めに戻り、もう一回説明して」ということの繰り返しです。

このあたり3年ほど前の記事ですが、「Node.jsのコミッターを迎え、炎の特訓—Node.js社内勉強会はこうして始まった」のインタビューに詳細が載っています。ぜひご覧ください。

TLS勉強会も同じようなやり方をしています。ただしライブコーディングはありません。まずはRFC5246（TLS1.2）の各節ごとに担当者を決め、自分で翻訳したものを一行一行解説してもらうことから始めました。今はTLS1.3のRFC8446まで進んでいます。ここでも、「さっき話してもらったところ聞いてもわからないから、もう一度」、「どうしてその規定になっているの？」、「ここは本当にSHOULDでいいの？」、「この言葉はいったい何を指しているの？」などなど、担当者の説明を聞いて気づいたことを次々と質問していきます。

その場でホワイトボードに書いてもらう

TLSは通信プロトコルなので、ほぼ毎回説明のため会議室のホワイトボードにサーバー・クライアント間のTLSハンドシェイクを書いてもらいます。暗記する必要はないからRFC見ながら書いていいよ、と言っていますが最初のうちは全然書けない。しかし1年もすぎるとみんな体が覚えます。以下のような図は、何も見ずにスラスラ書けるようになります（しばらく書いてないと忘れる者も出てきますが）。

このホワイトボードでの説明、ただ写して書くだけではありません。担当者の説明が一段落すると、「RFCで規定していることのまとめとして、いろんな条件・パラメータでハンドシェイクが変わる部分もちゃんと把握できるよう、取りうる全てのパターンを表で分類してよ。」といった依頼もよくします。

TLSハンドシェイクをちゃんと分類して書けるようになるには、それぞれの条件が全部頭に入って正しく理解してないと書けません。依頼した私も最終的な形をはっきりイメージできていないまま聞いているので、それを形にする担当者は四苦八苦して大変です。何週間もかけRFCの同じところを何回も読み直し、狭い会議室内で整理された以下のような表とホワイトボード数枚に広がったハンドシェイクフロー図がようやくできあがります。それを見て「そうそう私が欲しかったのはこれなんだよー！　これで完全に理解したよね？」と無理やりメンバーに同意を求めたりしています。

少し前にTLS1.3（RFC8446）に入ってからは、担当者は以前より質問がきつくなったと感じていると思います。それは必ずTLS1.2ではどうだった？　どうしてそうなったのか、というのを必ず聞くようにしているからです。例えばTLS1.3のCipherSuiteはどうなったのかと問うと、こんな図を書いて解説してもらいます。できないとTLS1.2の復習からやり直しです。

担当者の説明が終わると、私から「TLS1.2以前では、CipherSuiteに各種暗号方式を埋め込むセットメニュー方式だったんだけど、TLS1.3の仕様策定でいくつか古いアルゴリズムを廃止するにあたり、それぞれ暗号方式を個別に選択できるようにCipherSuiteの選択をアラカルト方式に変更するか大論争になったんだ。 アラカルト方式にすると選択ロジックが以前と大きく変わることになり複雑になるのを避けよう、ということで結局最小限の方式だけ取り入れたセットメニュー方式に決まった。それでこれまであった認証や鍵交換方式を全部拡張領域に押し込めるようにしたんだ。」といった補足を加えます。

仕様が決まった背景の理解は大事です。続いてこのような仕様変更に伴い、周辺の仕様がどう変わっていったのか続けて理解していくのも必要です。「じゃこのCipherSuiteの変更に伴って、TLS1.3 のClientHello と ServerHello がTLS1.2からどう変わったのか、わかるように書いて。」と尋ねます。そして以下のような図が書けるまでずっと担当が数週間も続きます。鬼ですね。

このような図を書ききれると、TLS1.3からTLS1.2へCipherSuiteの書式変更に伴い、TLS1.2までの項目がどのように拡張領域に押し込まれていったのかがすぐ把握できます。将来なにか暗号方式の交換で不明なことがあっても、この図を見返せば良いのです。

このように、TLS1.2におけるそれぞれの機能がどうしてTLS1.3では変わったのか、その背景と目的をちゃんと説明できるところまで参加者にやり抜いてもらいます。簡単に言っていますが、結構きつい作業です。少し前からRFCとなるドラフトは、GitHubで管理・作成されているものが多くなってきています。しかしIETFの議論がメーリングリストが中心であることから、ちゃんとissue/Pull Requestベースで記録に残っていない記述も多いです。そのような時は修正された部分のblameから変更日を探し出し、該当日時のあたりのメーリングリストやIETF会議の資料をあさります。どのような経緯・議論を経て該当箇所の修正が決められたのか、とことん追っかけます。

以下の図では、なぜTLS1.3ではsignature_algorithmとsignature_algorithm_certの2つに分かれたのか、というのを徹底的に追っかけました。

TLS1.3では、証明書で広く使われているRSA-PKCS1方式に加え、新たに暗号学的に安全性が証明されているRSA-PSSの2つの署名方式が大議論の上で採用されていました。この仕様変更が行われた月のTLS WGのメーリングリストアーカイブをあさってみると、相互接続試験で証明書の署名方式にどちらの方式が求められているのか明確にわからないのは困る、という意見が投稿され議論が始まっていました。最終的にその意見を受け、オプションで署名方式の指定が2つに分離された、ということがわかりました。このように過去の議論をほじくり返して仕様策定の経緯を追っかけるのは非常に大変な作業です。しかし一度理解すると、ものすごく納得感を得られます。

こういう社内勉強会を毎週2時間みっちり2・3年続けているわけですから、この分野の技術スキルが伸びるは当然だと思います。現在はオンライン勉強会に移行したため、担当者に同じようなサイズのホワイトボードに書かせて説明してもらうことができないのが、一番の悩みです。

社内勉強会と実務・評価

ヤフー社内で勉強会を始めた時に少し課題となったのは、その扱いでした。週1の2時間ですが、担当者の予習復習・宿題の時間は膨大です。当然業務に影響する可能性もあります。業務として行うのですから、勉強会で実施することの目標も決めて、成果の評価をしなければなりません。一人の担当者が終わるまでに2〜3カ月かかることもあります。半期後どこまで進んでいるかわかりません。そんな中で定量的に評価できる目標管理をしてもらうのは当初結構苦労しました。

しかし少したって、ある出来事が起きてからこの辺の状況は大きく変わりました。その日、あるHTTPSサーバーのOSSアプリケーションプロセスがクラッシュしました。グループでそのコアファイルを解析していたのですが、なかなかその原因がつかめない。あるTLS勉強会メンバーが 0x16,0x03,0x03 のオクテット列をコアの中から見つけました。そうです、それはTLSハンドシェイクメッセージのバイナリ列に似ています。勉強会ではTLSレコード層のオクテット列はいつも呪文のように唱えさせています。

別のメンバーがその周辺バイナリデータを抽出し、勉強会の宿題で作成したプログラムを使ってTLSフレームとして再構築し、試験を行いました。そうすると見事クラッシュが再現。未知の新しい脆弱性を発見です。早速修正パッチを作成し、開発元に連絡しました。開発元からの確認を経てCVEがアサインされ、パッチが取り込まれた脆弱性修正版のリリースが行われました。

この一件もあり、徐々にTLS勉強会が実務に役立っていることを周りの仲間が認識し始めました。「教育がこんなに早く成果がでるとは思わなかった」、あるマネージャーが後になって私に語ってくれました。今では社内勉強会自体に対する直接的な目標は作られなくなったと聞いています。勉強会で学んだことをベースとして実務でどう活かすのかといった視点で目標を立てているのだと思います。

過去の社内勉強会では、新しい技術を少し学んで検証しただけで実務的な成果につながらず、それほど評価されなかったこともあったと聞いています。私の勉強会では、常に実務を意識してwiresharkなどのツールやOpenSSLコマンドの使い方、パケットデータの分析のやり方などを実際に手を動かして学んでもらっています。基礎となる技術仕様をしっかり理解した上で周辺ツール類を使いこなす。それによって徐々に実際の実務に活かせる機会が増えてきたことが、個人的に非常に嬉しい出来事です。このような実務成果がちゃんとでるまで、辛抱強く理解を示してくれた部内のメンバーやマネージャー陣に本当に感謝しています。

専門的技術力を高めるために大事なこと

だいぶ外れてしまいましたが、最初のLTの話に戻ります。「専門的技術力を極めるための極意」を考える上で、これまで社内勉強会を通じて口酸っぱく若手のメンバーに何を伝えてきたんだろうか、何が大事なんだろうか、と振り返りました。すると、以下の4つの項目が頭に浮かびました。

「英語」、「基礎技術の理解と反復」、「一次情報へのこだわり」、「アウトプット」の4つです。

ここではこの4つの大事なことについて発表スライドを基に簡単に紹介します。LTで話せなかったことをかなり追記していますが、黒帯LT会の内容は後日Linotice でも公表される予定と聞いていますので、お楽しみにしてください。

英語

英語には、読み・書き・聞く・話すの要素がありますが、ここでは「読み」に限定した話です。勉強会では以下の事柄がしばしば見られました。

もったいない。本当に時間がもったいないです。日々膨大な技術情報に接する環境にいるわけですから、限られた時間の中で正確に英文の技術情報を読み解かないといけません。英文法のスキルが足りないのは致命的です。「なんとなく」英文を読んでいるので、正確に内容を読めたかどうか英文法に従って客観的に自分でチェックできない。おそらく学生時代からの勉学の積み残しだと思われます。またこの問題の根が深いところは、あまり本人に自覚がないことです。正確に英文を読めないのは、自身の英語スキル不足というより、書かれている技術内容自体が理解できていないからだ、と考えてしまう傾向も見られます。確かに既に自分が知っている内容なら、わかる英単語をピックアップしてだいたいの内容をつかむことができるでしょう。しかしRFCなどの仕様書を正確に読む場合は無理です。読んで理解が不明な記述が出た場合、「このセンテンスは、英文法的にはこのような解釈になる内容が書かれている。ということは以前のあの記述を受けてここではこう規定しているから、前に読んだ部分は間違って理解していたのか。」というようなチェックが自分だけでできないのです。

なんとなく「英語は苦手」、「英語を勉強しないといけない」と思っていても、具体的に何のスキルが足りないのかわからないままずっと放置となっているのを解消しないといけません。なかなか即効性のある英語スキル向上策が思い浮かばないのですが、もしあてはまるなら以下を実践してみるのもよいかと思います。

最近では、非常に優秀な翻訳ソフトも数多く使えるようになってきています。しかし入力した英文の改行やセミコロンの位置で翻訳される日本語の意味が大きく変わるケースが数多く見られます。翻訳ソフトの出力を過信せず、常に英文と見比べてチェックできるよううまくツールを使いこなしながら英語スキルの向上を図ってほしいです。英語がちゃんと読めるようになって始めて自分の専門的技術力を高めるスタート地点に立てるのです。

基礎技術の理解と反復

大きな企業に勤めていると「すぐ業務に役立つ研修」とか「スケールする研修」を求められたりします。個人的にはこういう依頼には反対しています。上っ面だけ理解した技術者を量産するだけで、ちゃんと基礎的な技術の取得が必要であると考えているからです。

一般的に、私達が扱う技術の多くは、さまざまな要素技術に依存しています。本来はこの一つ一つをきちんと理解することが必要です。ですがそれぞれの基礎技術自体、奥が深い。

特にTLSプロトコルのベースとなる暗号技術は、少し勉強すると泥沼に落ちることが多く、高い壁が待ち受けています。そうなるといわゆる諦めのタイミングが必要になります。繰り返し学び直すことで基礎が広がり深くなる。必要な時にいつでも戻れることが大事だと考えます。自分の知識・理解の境界は常に意識しておきましょう。

一次情報へのこだわり

当初明示していませんでしたが、毎回毎回注意してたので以下3つの掟になってました。

このうち「ページ検索を使わない」は、特にRFCなど仕様書を読む場合にお勧めです。勉強会で「この言葉ってどうしてこんな意味にしていたっけ？」と尋ねると、ページ検索してハイライト部分を探すのですが、だいたい正解にたどり着けないことがよく見受けられます。なぜなら直接的に言葉の説明が書いてある部分より、それ以前のところで前提条件や理由など重要な説明がなされていることが多いからです。ページ検索で重要な説明部分をすっとばし、どんな文脈で書かれたのか全く把握せずにハイライトの周辺だけ読んでいるのですから正解にたどり着けるわけありません。そこでページ検索を禁止して、仕様書の目次から質問された言葉を探すようにします。それを何回も繰り返すとドキュメントの構成が頭にたたきこまれて、前後のセクション・文脈が意識できます。頭の中に仕様書の構成が記憶され、インデックスができる感じです。そうするとどの順番で何がどう規定されているのか、仕様書の土地勘を持つことができます。何かを聞かれてもそれがどの章・どの節の後で出てきそうなのか意識できるようになるのです。

私はある専門領域でこのような土地勘を持てることが、必要とされる重要な技術力の一つと考えています。

習慣をつけておくと、一年もたつと無意識に自然にインデックスから探しています。APIドキュメントの構成やソフトウェアのソースコードレポジトリのディレクトリ配置なども同じ要領で土地勘を持つと強くなれます。お勧めです。

次に、一次情報に向き合いどうしてこうなるのか徹底的に調べるということは、勉強会の様子で述べた通りです。エピソードまで含めた理解は、技術に対する深い理解をもたらします。「なぜそのような仕様になっているのか」、「どういう考えで技術が発展しているのか」を理解すると自分の中にブレない軸ができます。それが時代を経ても変わらない本当の意味での技術力です。

アウトプット

実はインプットばかりやっていると、知識がいびつになります。同時にアウトプットすることを考えることで、結構知識のバランスが取れます。アウトプットを意識すると、自分に足りないものが見えてくるからです。それをきっかけにさらなるインプットにも精が出ます。この好循環を起こすことが非常に重要です。インとアウトのバランスは、技術者が成長するためには不可欠のものだと思います。

アウトプットで余分なことを削ぎ落とす作業は、本質を見るために重要な作業です。100調べたことをそのまま全部出しちゃうと、どうしても内容が浅くなってしまいます。単に自分の備忘録程度にしかなりません。100調べたことを10に絞れば、全体のエッセンスが際立ちます。たとえ発表しなくても、残りの90は自分の資産になって残ります。アウトプットは自分のためと思って頑張りましょう。

勉強会参加者からの声

以上私の視点からばかり書いていましたが、当の参加者はどう捉えているのでしょうか？

3名の参加者から、「これからスキルアップを目指しているエンジニアに対して一言」でコメントをいただきました。

大石 剛さん

勉強会を通じて大津さんから学んだことで一番伝えたいのは、「一次資料を丁寧に読む」という技術です。

勉強会ではRFCを読んでいますが、この技術は次の事が全て出来るようになって初めて「読めた」と言えることを教わりました。

• 英語を正しく理解し、日本語に置き換えることができる。
• その文章の意味を正しく理解する。
• 他の人にも簡潔に説明することができる。
• なぜそのような仕様になっているのか、歴史的経緯も含めて説明することができる。

勉強会は常にこの姿勢で臨む必要があるのですが、 上記ができなければ結局何もわかっていないということで、1回2時間の勉強会で1, 2行しか進まず落ち込んだ時もありました。

勉強会に限らず「一次資料を丁寧に読む」という技術は、今後の自分の財産になると思います。あとは日々実践していきたいと思います。

五水井 柾人さん

「専門的技術力を高める」というのは、武術や芸術の求道に似ていると感じます。日々為すべきことはシンプルなのですが、それを高いレベルで継続・向上し続けるのが難しいのです。IT業界は、学ぶべき技術自体の変化や興廃が激しく、日々の業務にも忙殺されがちですが、勉強会を通じて徹底して自分を磨く時間を持つことができ、幸運だったと思います。何を学ぶべきかを見定めたら、後は「修行」ですね（笑）

染野 敦則さん

仕様書の1文1文に対して、ここまで「なぜ」を求めることが今までなかったので理解することの難しさと大変さが身に染みました。

その節についての理解はもちろんですが、この勉強会では、その節に記述している関連資料（他の節など）も読んだ上で発表に臨みます。関連資料がまだ先の章の節だったとしても読みます。読み進んで行ってその関連資料の節の発表の際にまた読むので反復する機会は設けられ、定着させられる機会は増えると思います。

正直、1節を発表するための準備に時間はかかりますが、このやり方を継続していくことによって理解と定着に確実につながると感じています。1人で継続するにはモチベーションの維持がなかなか難しいと思いますので、何人か集まってやってみてもいいかもしれません。

最後に

私ももう歳なので、いつまでこのような社内勉強会を続けられるかわかりませんが、まだ黒帯でいられるうちはこのように若手と一緒に最新技術を学ぶ場を作っていきたいと思っています。

ここに書いてあることは、ある意味恵まれた環境の中で理想的な学び方を実践したに過ぎません。これだけのコスト・時間をかければ当たり前と考える方も多いでしょう。この記事で偉そうに書かれていることの全てを実践したほうが良いとは申しませんが、これからスキルアップをしようとする方でなにか一つでも気づきを持っていただいたら幸いです。

[1]ヤフーの黒帯制度については、こちらをお読みください。