エンジニアには「意思決定のバッターボックス」に立ってほしい。エムスリーVPoEばんくし氏に聞く、印象に残る技術選定Top3

「エンジニアが技術的な意思決定に携わること」は、キャリアにおいて重要な意味を持ちます。特定の技術がどのような思想のもとに作られており、利点や欠点は何か。そして、その技術が自社の求めるニーズに合致しているかなど、複数の観点に基づき決断を下す必要があります。ひとたびその技術を導入すれば、長年にわたってメンテナンスし続けることも確定します。こうした経験を通じてエンジニアは多くのことを学び、成長するのです。

では、各企業で活躍する著名なエンジニアたちは、これまでどのような技術的な意思決定に携わってきたのでしょうか。今回はエムスリー株式会社のVPoEである河合俊典（ばんくし）さんに、キャリアのなかで印象に残る意思決定について聞きました。

エムスリーが目指すのは「全員CTOレベル」

――河合さんがエムスリーで担当されている業務についてまずは教えてください。

VPoEとして、開発組織作りに必要な仕事を担っています。現在、最も注力しているのはエンジニア採用です。それに加えて、組織の文化をより強固にしていくための仕事もしています。エムスリーはこれまで医療というドメインの課題をエンジニアリングによって解決してきましたし、強い文化を実現できているとも思います。

今後もさらに事業を拡大する予定なんですが、一般論として開発組織の人数が徐々に増えていくなかで何も対策をしないでいると組織が崩壊してしまうといったケースはよく見聞きする話だと思います。人を増やすことと並行して、エムスリーの文化も徐々にアップデートしていく必要があります。私は「文化の速度と組織の速度の歩幅を合わせる」という旨の言葉をよく使うんですが、そのための仕事に取り組んでいます。

――「エムスリーの文化」とは具体的にどのような要素だと思われますか？

私たちはよく「ギークでスマート」というワードを社内で使っています。グローバルで大きなインパクトを出している企業を見ても、トップの人間がギークであるケースが多いですし、そういった企業の開発組織にはトップレベルの技術者が集まっています。

エムスリーでもまさに、ギークな集団が力を合わせてスマートに医療を変えていくことを大切にしています。今回のインタビューでは、私の過去の技術選定についての話をしますが、「何が最も合理的な選択なのか」を前向きに考える事もスマートさの1つだと考えていて、エムスリーが大切にしている文化です。

――エムスリーでは技術選定において多様性が重視されており、トップダウンではなく各チームが採用技術を決めると伺っています。これは、どのような理由からでしょうか？

理由として、エムスリーのエンジニア組織が大事にしていることが2つあります。1つは意思決定に関わること、もう1つは新しい要素を学ぶことです。

なぜなら、意志決定に携わることがエンジニアの成長において重要だと考えているからです。エムスリーの卒業生は他社でCTOやVPoEになっている人が多いんですが、それはやはりエムスリーの業務のなかでたくさんの意志決定をして、そこからたくさんのことを学んできたからだと思うんですね。

もちろん、全社的に足並みをそろえなければならない大規模な方針策定はCTOが旗振りをすることもあるんですが、基本的に各チームに任せています。それらの意思決定を経て、みんながリーダーの素養を身につけていきます。社員採用の際にも「新しい技術に挑戦することにワクワクするか」は重要な基準の1つです。

「チームを移った際に、そのチームで採用している技術や設計などを新たに学ばなければならない」という大変さもありますが、私たちはむしろそれをポジティブに捉えています。未知の要素について学ぶなかで「このチームではこういう意図があってこの技術を採用したんだろうな」とか「このような事情があるからこそ、この設計になっているんだ」といった背景や経緯を知り考えることが、エンジニアとしての成長につながるからです。そういったことに対してもワクワクする人が集まっているとも言えますね。

余談ですが、エムスリーが採用で用いている資料には「CTOレベルの人材を集める」と書かれています。エンジニア全員に、CTOを担えるくらいのスキルを習得してもらいたいんです。では「多くの会社でCTOになるのはどんな人か？」というと、それぞれの技術の利点や欠点を正しく理解したり、自分たちの組織や事業の状況などを踏まえて採用技術を決めたりといったことができる人です。

だからこそ、そのスキルを身につけるために技術選定の打席に立つ経験をしてほしいというのが、エムスリーの強さの根幹にあるなと思います。そのバッターボックスを増やすのが今のVPoEである私やCTO山崎の仕事になっています。

C#の会社に、Pythonを持ち込んだ

――では、ここからは過去に取り組んできた技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。

私はこれまで複数の会社で働いてきましたが、今回はSansanとヤフー、エムスリーの話をそれぞれしようと思います。Sansanには新卒で入社してR&D部門に所属しました。機械学習エンジニアとして最初は小規模な改修を経験し、その次に大規模プロジェクトとして顔画像の認識機能を担当しました。

同社が提供する営業DXサービス「Sansan」では名刺の画像データを取り込むことで、記載されている情報をデータベース化できます。その裏側では、画像データのテキストを読み取るOCRの技術や、読み込まれた画像データを個人情報が特定できないレベルまで分割する技術、そして人間のオペレーターが内容を目視でチェックして正確さを担保する技術などが用いられています。

名刺のなかには、顔写真が入っているものがありますよね。でも、顔写真の情報がオペレーターの方々に見えるのは、セキュリティやプライバシーの観点から良くありません。その課題を解決するためのプロジェクトを担当しました。

今もそうですが、Sansanでは当時サービスを開発するための言語として主にC#を使っていました。所属していたR&D部門でも、もともとはC#しか使っていませんでしたね。C#は非常に良い言語なんですよ。ただ、当時の私はそのR&D部門での業務を進めるうえで「Pythonを導入するべきではないか」と考えて、Sansanで初めてPythonを使い始めました。

理由はいくつかあります。まず、私は学生時代のアルバイトから機械学習を経験していたので、ライブラリの充実度やAI・ML領域との親和性などを見てもPythonの流行が来ることはまず間違いないと思っていました。また、画像認識に関して言えば、C#よりもPythonを使うほうが精度を向上させられるだろうと判断したことも大きいです。

――チームに新しい技術を持ち込むにあたり、どのような方法で導入を成功させましたか？

新しい技術を導入するには「会社や事業、チームが何を重視しているのか。そして、その技術がそれを実現できるのか」を明確にすることが大切だと思っています。そのうえで、このプロジェクトにおいて最も重視すべきは「画像認識の精度を出せるかどうか」でした。そこで導入の際には、画像認識の処理をC#とPythonの両方で簡易的に実装して比較し、後者のほうが良い結果が出ることを確認しました。

Pythonの導入は、画像認識の精度の向上以外に利点がいくつもありました。その後、実際にAI・ML界隈におけるPythonのブームが来たこともあり、新卒やインターン生など若い人に対する受けがかなり良かったんです。結果として、優秀な若手がたくさん入社してくれました。また、もとよりR&D部門にいた先輩方もPythonに興味を持って、積極的に学んでくれました。チーム全体の技術力の底上げになり、メンバー同士でPythonについて議論できるようにもなって、互いに高め合える空間になり本当に楽しかったです。

ただ、当時した選択のなかで後悔していることもありますけれどね。その頃は、ちょうどPythonのバージョン2・3問題にみんなが直面していた頃で、世の中のオープンソースのライブラリにも、バージョン2では動くけれどバージョン3では動かないものがいくつもある状況でした。

そしてライブラリの依存関係の都合上、Pythonのバージョン2を採用したんです。でも、その数年後にはバージョン3への移行を考えなければならない状態になってしまったので、最初からバージョン3にチャレンジしておけば良かったと、今になってみれば思います。

――この経験を踏まえて、読者へのアドバイスはありますか？

「何かの技術はサービスに導入した時点から技術的負債になる」とよく言われるんですが、技術選定にはそういう側面があります。もちろん、導入の時点では合理的な判断のもとに特定の技術を採用しているはずなんですが、それが正解になるかはわかりません。その技術が何らかの理由で廃れてしまう場合もあります。サービスのフェーズが変わって、その技術では要件を満たせなくなる可能性もあります。

でも、たとえ技術選定において失敗したことがあったとしても、複数の情報を参照したうえで決断した経験やみんなを巻き込んで導入を進めた経験は、その人や組織の血肉になるんですよね。だからこそ、失敗を恐れ過ぎずに技術選定に参加してほしいと思います。

その意思決定が自分自身の学びになって、後のキャリアでテックリードやCTOなどを担うために必要なスキルが身につきます。大小さまざまな意思決定を積み重ねて、エンジニアは成長していくものだと思います。

技術選定においては「他の人たちを納得させられるか」が重要

――では、ヤフー時代のエピソードも聞かせてください。

ヤフーで携わったなかで一番大きなプロジェクトとして、「ヤフオク!」の違反出品の検知があります。この事例は分散深層学習という手法を使いました。ヤフー社内で保有していたスパコンを用いて、複数のGPUをつなげてディープラーニングを実行するという、かなり大規模なプロジェクトでした。そもそも、分散深層学習をプロダクトに導入している会社が世の中にほとんどなく、参考にできる前例がほぼないという状況下での挑戦でした。

OpenMPやCUDA、ChainerMNなどの技術を採用しましたが、前例がないのでこれらのライブラリ自体のコードを読んだり、論文を読んだりしながらなんとか形にしていきましたね。また、大量のデータをGPUのメモリ上にうまく載せる技術も全く確立していない時代だったので、どうやって計算すれば効率良く学習ができて、許容範囲内の時間に収まるかを考えました。

――このプロジェクトではどのような点が、技術選定において大変でしたか？

前例がほぼない分散深層学習ではなく、LightGBMやXGBoostなどよくあるアルゴリズムを使うような選択肢もありました。ですが、このプロジェクトにおいてもビジネス要件として重視すべきは「検知の精度を向上させること」でした。まずは各種の手法を用いて簡易的な実装を試し、分散深層学習を用いることで最も良い結果が出ると判断したため、その方針で進めました。

ヤフーのプロジェクトでは「ステークホルダーをきちんと巻き込んで技術的な意思決定を行うこと」が一番大変でした。分散深層学習のように社内外でも前例がなくメンバーも不慣れな技術を用いる場合、その技術を学習するための時間が必要であることもステークホルダーに説明しなければなりません。

何かの技術選定をする際には、その決断に対して他の人が納得できなければ意味がないんですよね。それぞれの技術には利点と欠点の両方があり、どの案を選んだとしてもトレードオフの要素があります。自分たちがなぜその方針を選び、それに伴って生じる課題をなぜ許容するのか。その理由や根拠を、開発組織の人たちだけではなくすべてのステークホルダーに向けて言語化できるかが大事だと、私は思っています。ヤフーでの経験を通じて、人を巻き込んで進めていくことの大切さを学びました。

Pythonのパッケージ管理ツール、何を使う？

――次にエムスリー時代の話に移りましょうか。

エムスリーの技術選定において特に印象に残っているのは、社内で使用するPythonのパッケージ管理ツールを変更したことです。この経緯は「pipとpipenvとpoetryの技術的・歴史的背景とその展望」というブログ記事でも書いたことがあります。Pythonという言語はパッケージ管理ツールの種類が他の言語と比べても多く、そのなかでよく使われるのがpipやpipenv、poetryなどです。

pipenvは、pipに対して依存解決やlockファイル生成、env環境制御機能を提供する、PyPAが開発するパッケージ管理ツールです。そしてpoetryは、pyproject.tomlの仕様を拡張して依存解決からlockファイル生成、env環境管理、パッケージングまでを行えるようにしたパッケージ管理ツールになります。

私がブログ記事を書いた頃は、pipenvはPyPAとしては公式のツールではあるものの「パッケージングの手法に課題がある」「lockが生成されるまでの速度が遅い」「（当時は）開発が滞っていた」というような欠点がありました。そのため、pipenvを使用している企業はいくつか開発の問題に直面していた背景があり、エムスリーも同様でした。そこで、poetryを採用することを決めました。

この際に重要だったのは、「poetryのほうが良いらしい」という安易な理由で採用技術を決めるのではなく、かなり時間をかけて「そもそも、なぜpipenvの課題が生じているのか」「世の中にはどのようなパッケージ管理ツールがあり、それぞれの特性は何か」といったことを徹底的に調べたんですよね。その結果、調査内容をまとめたブログは数万文字くらいのボリュームになりました（笑）。

これだけ調べ尽くしたうえでpoetryの採用を決めたので、周りのエンジニアも納得して、方針に賛同してくれたんです。技術選定のためにその事前調査を入念に行うこと、そして「そのうえで、なぜこの方針を選ぶのか」を明確にすることの大切さを学びました。その後、poetryを使う企業はかなり増えたので、技術の潮流も読み間違えていなかったと思います。

でも実のところ、私個人は最近ではpipenvを使っていたりします。今ではpipenvの開発も再開されましたし、パフォーマンスや機能も改善して利点が多くなっていますし、build関連の機能などpipenvを活用したいシーンも個人的に多くなっているためです。こういった軌道修正ができるのも、それぞれのパッケージ管理ツールの背景や特性をきちんと調べたうえで、決断したからだと思います。

技術の流行を追うだけでなく、技術的背景を知ることも選定の大切な要素の1つです。血肉になると先ほど表現しましたが、次にまた同じような技術選定をする際の判断も早く明確になりますし、周囲に説明できる状態まで言語化することで巻き込みやすくなり、組織としても成長します。技術選定に充てる長い時間は決して無駄ではないというのは、私の経験からも明確に言えることだと思っています。

エンジニアがバッターボックスに立つ頻度を増やしたい

――今後、エムスリーで何を実現していきたいですか？

今回のインタビューに関連した話をすると、やはりさまざまな意志決定をたくさんの人にしてもらいたいと思っています。これは、技術選定に限ったことではなく、プロダクトの方向性を決めるとか、組織をマネジメントすることなどにおいても同様です。

仕事のなかでの決断をくり返すことによって、その人のスキルが向上し、リーダーとしての素養を身につけていくと考えています。そのためには何が必要かというと、やはり人を増やすことや新しいプロダクトを作ること、ビジネスを成長させること。メンバーがバッターボックスに立つ頻度が増えれば決断の回数も増えるわけなので、エムスリーを「バッターボックスだらけ」にしたいと思っています。

――さらなるエムスリーの成長が楽しみですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

先人たちの過去のエピソードには、成功も失敗もたくさんあります。そうした事例を参考にして、「当時この人たちはどのような経緯でこの決断をしたのだろう」という理由を自分なりに考えていくことは大きな学びにつながります。

とはいえ、未来のことを完全に見通すことはできないので、挑戦を続ければ必ず一定の確率で失敗します。私がPythonのバージョン2を選んだ事例のように、「今になって思えば、あのときにこうすれば良かった」という話もあるはずです。でも、そういった失敗も含めてすべてが自分の糧になるので、決して恐れ過ぎずに、最後は意志を持って決定することが大切ですよね。

さらに言えば、技術的な意思決定は“面白い”んですよ。自分で決めた方針に基づいてシステムが出来上がるというのは、エンジニアリングの本質じゃないですか。だからこそ過去の事例をたくさん参考にしたうえで、楽しみながら自分自身の業務に取り組んでほしいです。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul