ミッションクリティカル領域にAIを推進するコーピーで、CTOのRyan Ginstromはシンプルな原則を貫いてきました。「システムは、本番環境で確実に動き、測定可能な価値を生み出して初めて意味を持つ」。その姿勢は、厳格なエンジニアリング規律、強制力のある基準、そしてデリバリーへの執着という3つに支えられています。

信頼性は「設計し、計測し、徹底させるもの」だと彼は言います。20年以上のエンジニアリング経験とメルカリでのMachine Learning組織のリーダー経験を経て、「使えるはずなのに、使えない」AIの壁を壊すためにコーピーへジョインしました。技術への敬意と顧客への徹底したこだわり、そして静かだが揺るぎない信念を持つCTOに、仕事の哲学とこれからのコーピーについて、じっくりお話を伺いました。

「失敗」の重みが、根本から違う

—メルカリではコンシューマー向けの機械学習チームを率いていました。コーピーでは何が根本的に違いますか？

メルカリはコンシューマー向けの会社なので、すべての機械学習/ML(Machine Learning)はユーザーに向いていました。コーピーではお客様は企業です。ただ、MLの目的は変わりません。顧客に価値を届けること。何かの問題を解決する、新しいメリットを生み出す。そこは同じです。

決定的に違うのは、失敗したときの重さです。前職であるメルカリの僕のセクションでは、失敗してもクエリが5秒遅くなるとか、結果の精度が少し落ちる程度。ユーザーにとっては不便ではあるけど、それ以上ではない。でもコーピーでは、設備が壊れるかもしれない。人の健康が危険にさらされるかもしれない。失敗が許されない責任の重さが、根本から違います。

この責任の重さが、システムの作り方そのものを変えます。僕たちは「トレーサビリティ」を前提に設計している。つまり、何が起きたのか、なぜ起きたのか、どう直せばいいのかを、推測ではなく確実に答えられる状態にする。信頼性とは、失敗を防ぐことだけではなく、失敗を診断でき、回復できる状態にしておくことなんです。

—その責任の重さにチャレンジしたい、というのもコーピーに来た理由ということですね。その他にコーピーを選んだ理由はどこにあるのでしょうか。

2つあります。ひとつは、コーピーがいる領域が世界の未来にとって非常に重要だということ。MLは社会のあらゆる場所に広がっていますが、信頼性や安全性が足りなくて使えない領域がまだたくさんあります。もしコーピーが安全性と信頼性でブレイクスルーを起こせれば、MLが使える場所は飛躍的に広がる。とてもユニークで、わくわくする領域です。

もうひとつは、自分が貢献できると思ったから。コーピーは小さな会社から中規模の会社へと成長してきました。僕は大企業で厳格なエンジニアリング基準のもとで働いてきた経験があるので、それをコーピーのエンジニアリング文化に持ち込んで、よりプロフェッショナルで信頼性の高い組織にできると考えました。

—「よりプロフェッショナルで信頼性の高い組織にする」というのは、具体的にどういうことですか？

エンジニアリングをROIドリブンのシステムとして運営することを目指しています。どの取り組みにも、デリバリーの速度、信頼性、売上——何であれ、明確に期待する成果がなくてはいけない。その価値を説明できないなら、そもそもやるべきではない。これは、エンジニアリング組織でよく起きる問題、時間が経つにつれて「努力」と「インパクト」が乖離していく問題を防ぐことにつながります。

「不可能」を証明することも、良い結果

—R&Dの現場で、技術以外の理由でプロジェクトが止まることはありますか？

たくさんあります。大きいのは、お客様の考えが変わること。最初はこうだと思っていたのに、ソリューションの形が見えてきた段階で「実はこれじゃなかった」となる。もうひとつは予算です。僕たちのプロジェクトは何年も続くことがあるので、その間にお客様の予算状況が変わることもあります。

だから常にお客様と密にコミュニケーションを取っています。ニーズが変われば、僕たちも適応する。MLの場合は特にそうで、お客様は非常に技術的に詳しい方が多いですが、ML自体の専門知識は持っていないことが多い。MLに何ができて何ができないか、最初にしっかり説明することが重要ですし、プロジェクトが進む中でも常にアップデートし続ける必要があります。

—PoC、つまり概念実証で終わるプロジェクトと、本番導入まで進むプロジェクトの違いはどこにありますか？

PoCが成功するかどうかは誰にもわかりません。それがProof of Conceptの本質ですから。僕たちは技術の最前線で仕事をしています。まだ誰もやったことがないことに挑戦している。可能性があると判断しなければPoCは始めませんが、結果的に技術がまだ成熟していなかったり、コストが見合わないとわかることもあります。

でも、PoCが続かなかったからといって、それを失敗とは考えません。ちゃんとしたPoCをやって「これは今は実現できない」と証明できたなら、それも良い結果です。「これはうまくいかない」と証明するPoCにも価値があります。僕たちとお客様が、間違った方向に投資し続けるのを防げるからです。その意味では、ずるずる続く曖昧な「たぶんいける」よりも、早い段階ではっきりした「NO」のほうが、ずっと良い結果なんです。

エンジニアは賢い。そして、良い仕事がしたいと思っている

—20年以上エンジニアとして歩んできて、変わらない信念はありますか？

エンジニアに対する信念が2つあります。ひとつは、全員が賢いということ。採用のハードルを超えてきた人で、賢くない人はいません。もうひとつは、99.9%のエンジニアが良い仕事をしたいと思っているということ。

この2つを前提にして会話を始めると、物事はうまく進みます。誰かがミスをしたとき、「この人は頭が悪いんじゃないか」という発想は最初から捨てられる。知識が足りなかったのか？コミュニケーションに齟齬があったのか？本質的な原因にすぐたどり着ける。20年以上やってきて、頭の悪いエンジニアに会ったことは一度もないし、良い仕事をしたくないエンジニアにも会ったことがありません。

—その前提に立つと、ミスや品質の問題が起きたときの対応も変わってきそうですね。組織が大きくなると、それでも基準を揃える必要は出てくると思いますが、その点はどうしていますか？

信頼と仕組みは対立しないんです。むしろ逆で、「全員賢くて良い仕事をしたい」と信じているからこそ、基準を明文化する意味がある。賢い人に"良い仕事とは何か"を毎回推測させるのは時間の無駄だし、良い仕事をしたい人に曖昧な基準を渡すのは不親切でしょう。だから僕たちは、期待を「チェック」に変換するようにしている。見える、測れる、一貫して適用される状態にする。そうすれば、エンジニアは「良い仕事」がどう見えるかを推測する必要がなくなるし、僕たちも品質を保つために手動レビューを繰り返し続ける必要がなくなります。

—チーム内のエンジニアと意見が割れることはありますか？CTOとして、最終的に何を基準に判断しますか？

自分の好みを押しつけないようにしています。エンジニアが僕と違うアイデアを持ってきたとき、頭ごなしに否定はしない。客観的に見て、僕のアイデアと同じくらい良い、あるいはそれ以上だと判断したら、エンジニアの選択を尊重します。自分が本当に興味を持っている技術で仕事をするエンジニアは、良い成果を出しますから。

客観的に劣る選択だと思ったら、一緒にメリットとデメリットを整理します。僕の経験では、エビデンスを見せれば、エンジニアは必ず「じゃあそっちでやろう」と言います。良い仕事をしたいと思っているからです。でもそこには信頼が必要で、逆に彼らのアイデアが良ければ僕がそちらを採用すると、彼らはわかっている。

技術そのものの適合性に加えて、広く使われているか、最後にアップデートされたのはいつか、メンテナンスしやすいか、チーム内で何人が知っているか——そういった点も判断材料にしています。

—ここまで聞いているとすばらしい哲学をお持ちだと思います。そんなRyanさんが、エンジニアとして影響を受けた人はいますか？

10年ほど前の上司です。1980年代にヒューレット・パッカードでキャリアをスタートしたベテランで、MLのことはまったく知らない人でした。でも僕が問題を持っていくと、彼は質問をしてくるんです。そして質問が終わる頃には、なぜか問題が解決している——自分自身で解決しているんです。彼はいつも、ちょうど正しい質問の仕方を知っていた。あのマネジメントのスタイルには本当に敬意を持っていますし、今の自分のリーダーシップにも影響しています。

コードを書き終えたら仕事が終わりではない。好奇心を持って、届けきる

—チームにこれだけは守ってほしいと伝えていることはありますか？

顧客志向です。顧客価値がゴールですが、そこに辿り着く唯一の方法は”ship”、つまり届けること。コードの最後の一行を書いたら仕事が終わり、ではありません。システムが本番環境で動き、価値を生んでいて、初めて仕事は完了です。設計も、ツールも、リサーチも——それが前に進まない限り、意味を持たない。お客様が価値を得ていなければ、それは無意味です。意味を持つのは、誰かに価値を届けた瞬間からです。

これは僕にとって個人的なこだわりでもあります。MLの世界では、ラボから出ない、実験段階から先に進まない成果物が非常に多い。メルカリで僕のチームは、社内で初めてMLをプロダクションに投入して、実際のユーザーの前に出したチームでした。30人のMLエンジニアがいて、MLエンジニアが作ったものが一度もユーザーに届かないケースは、正直よくあることです。僕はそれが勿体ないなと思っていました。MLを始めた時からずっと、「これをお客様に使ってもらおう」「プロダクトに載せよう」と言い続けてきた。それが10年以上、僕のフォーカスです。

—LLM全盛の市場で、コーピーが勝てる領域はどこですか？

2つの観点があります。ひとつは、従来のML技術の蓄積です。純粋なLLMベンダーにはない機能を付加できる。たとえば多くのLLMシステムにはOCR機能がありますが、僕たちは特殊なOCR——図面や電気回路の読み取りなど——に深い経験があります。それをLLMシステムに組み込むことで、システム全体を強化できる。

もうひとつは、信頼性と説明可能性への注力です。LLMは確率的なシステムで、同じ質問を100回しても100回同じ答えは返ってきません。間違った答えが出たとき、なぜ間違えたのかを突き止めるのも非常に難しい。僕たちは信頼性と説明可能性にフォーカスしているからこそ、より堅牢で信頼に足るシステムを構築できます。実はこれがコーピーに来た大きな理由のひとつでもあります。ニーズは巨大なのに、取り組んでいるプレイヤーが少ない。なぜなら、難しいから。

—そんなコーピーで活躍するのはどんな人ですか？

おそらく一番大事なのは、好奇心です。コーピーではたくさんの新しいことに取り組みます。コーピーでは、プロジェクトごとにドメインが違い、使う技術も違う。常に学び続け、常にテクノロジーの最前線にいられる。新しいことを試すのが好きで、好奇心を持ち続けられる人は、ここで力を発揮できると思います。

—最後に、これからコーピーで一緒に働く人に伝えたいことは？

コーピーはユニークな環境です。最先端の技術に取り組み、お客様は製造業やリサーチなど各分野のリーダー企業ばかり。そして、日本で活動するインターナショナルな会社です。この組み合わせはかなり珍しい。日本で、日本の環境の中で働きたい。でもエンジニアリング組織は英語で、最先端の技術に多様なプロジェクトで関われる——そういうことにわくわくする人なら、コーピーが最適な場所です。

コーピーでは、好奇心を持って新しい挑戦を楽しめる方にぴったりな環境を提供します！ 一緒に、機械学習が活躍できる領域を広げていきませんか？