“選定してすぐにダメになった”を防ぐには？特定の言語にフルベットしない、一休の技術戦略

エンジニアの仕事の中でも、「技術選定」は特に難易度が高く、責任が重いものです。ひとたび特定技術の採用を決めると、容易にリプレイスできず、長期間にわたって開発や運用に影響を及ぼします。さらに、使用する技術によって採用活動や組織戦略にも大きな影響が出ます。読者の中にも、「技術選定で失敗したくない」「将来にわたって持続可能なアーキテクチャを構築したい」と考えている方は多いのではないでしょうか。

しかし、株式会社一休で執行役員CTOを務める伊藤直也さんは、「どんなに頑張っても必ず技術選定は失敗をする。むしろ、失敗を前提として備えておくことが重要」と語ります。なぜ、こうした考えに至ったのでしょうか。そして、伊藤さんが実践する技術選定の方針とは。詳しく伺いました。

• keyboard_arrow_down 技術ポートフォリオを構築し、リスクを分散させる
• keyboard_arrow_down 妥協して技術選定→失敗して作り直し
• keyboard_arrow_down 技術刷新は「ビジネスの価値につながる開発」の裏側で
• keyboard_arrow_down 技術選定とはすなわち「経営」

――今回のインタビューでは、伊藤さんの技術選定の考え方について伺います。まず、「失敗は必ず起きる」という考えは、以前からお持ちだったのでしょうか？

伊藤：どれほど頑張っても完璧は無理だ、という考えは若い頃からありました。ただ、かつては失敗に対してあらかじめ対策を講じることはあまりなかったですね。その時点で最適な技術を選定することばかりを考えていました。いつか特定の技術を捨てることになるかもしれないとか、そうした事態が訪れたときにどう対応すべきかを、きちんと検討していませんでした。

――将来的に技術をリプレイスすることを前提とする場合と、そうでない場合とでは、具体的にどのような点が変わるのでしょうか？

伊藤：技術的なポートフォリオの組み方が変わります。

会社ごとに技術選定の方針は異なりますが、たとえばプログラミング言語を一つに統一するという選択肢がありますよね。この方針の利点は、チーム間での人員の入れ替えが容易になることです。一方で、特定の技術にフルベットすることになるため、その技術が古くなると会社全体のテクノロジーが時代遅れになるリスクがあります。

その対極にあるのが、社内の各チームで異なるプログラミング言語を採用するアプローチです。この方針を取ると、特定の技術が陳腐化した際のリスクを抑えられますが、あまりに種類が多すぎると管理が難しくなり、全体の統制が取れなくなる可能性があります。

これらは極端な例ですが、技術のバランスを考慮し、ポートフォリオを構築する視点が重要だと考えるようになりました。適切にポートフォリオを組めば、「自社で使用している技術のある部分は古くなったが、他の部分はまだ新しい」といった状態を実現でき、すべてが一斉に陳腐化する事態は避けられます。

現在の一休では、事業ごとに使用技術を分けています。バックエンドの技術として、レストラン事業はRust、宿泊事業はGo、飲食店向けSaaSサービスはTypeScriptを採用しています。フロントエンドの技術はNext.js・Nuxt.js・Remixが併用されており、各チームの要件や開発方針に応じて活用されています。

――複数の事業を展開する、一休らしいアプローチですね。

伊藤：とはいえ、技術選定の失敗も数多く経験していますよ。今回はその話もします。まずは組織の状況を考慮し、ある種の妥協をした結果、技術が長持ちしなかった事例です。

私が一休に入社したのは2016年ですが、その頃は宿泊事業もレストラン事業も、バックエンドのほぼ100%が.NET Frameworkで書かれていました。完全にWindows文化圏だったわけですね。入社時点で技術的負債がかなり溜まっていたので、システムを少しずつ入れ換えていく活動を始めました。そして、「これからは.NETを採用せず、オープンソースの技術を積極的に使う*」と決めました。

*…現在の.NET Frameworkはオープンソースになっていますが、かつてはクローズドソースで提供されていました。

一休の開発組織はそれほど規模が大きくないため、オープンソースのプラットフォームに乗らなければ、他の会社と同じスピードで開発を進められないと考えたためです。Web開発が得意なソフトウェアエンジニアをもっと採用したいという思惑もありました。当然ながらその当時の社内のほとんどのエンジニアは、.NET Framework以外の技術には不慣れ。「本当に変えるんですか？ うまく適応できるだろうか」という雰囲気もありました。

伊藤：採用技術について悩んだ結果、「あまりに技術的なジャンプが大きいと、移行に困難が伴うかもしれない」いう点も考慮して、Pythonを採用しました。ある意味、妥協した選択です。ただ、その当時は正しいと思っていたこの判断も、今振り返るとこれはベストな選択ではなかったと思います。

5年ほど開発を続けた後、新型コロナウイルス感染症の流行により、飲食業界に大きな影響が出ました。その結果、レストラン事業の開発が約2年間ストップ。一方で、国内需要が高まった宿泊事業は開発が継続され、社内のエンジニアも宿泊事業に集中させることになりました。

しばらく経ち、2年ぶりに「よし、レストラン事業の開発を再開しよう」と思ったところ、システムを最新化するのが困難なことに気がつきました。しばらく触れていない間に Pythonモジュールの依存関係がうまく解決できない状態になっていて、バージョンアップできなくなってしまったんです。

また、当時宿泊事業の方はGoでのリプレイスが進んでいましたが、Pythonで記述されたレストラン事業のシステムと、Go で記述された宿泊事業のシステムでコンピューティングリソースの利用効率に想像以上に差がついていました。クラウドに全面移行した今、Pythonでレストラン事業のトラフィックを全部受け止めるのは費用対効果が悪いことも明らかになりました。

プログラミング言語のトレンドも、その5〜6年の間に様変わりし、静的型付け言語での開発が盛んになりました。

こうした状況もあり、Pythonのような動的型付け言語で高トラフィックの大規模サービスの開発を続けていくのは、相対的に難しいと考えるようになりました。結果、コロナが開けての開発の再開にあたり、レストラン事業はRustで全面的に書き換えることにしました。

また、宿泊事業の開発の方でも、Goを導入する前に「C#で書かれたシステムをC#でリプレイスする」という試みも行われていました。これも「短期的には技術的なジャンプがないほうが開発が速く済む」という考えからの決断でしたが、その後に他の部分をGoで作り直すことになって、結局はC#でリプレイスした部分もその後にGoで作り直されることになりました。つまり、「エンジニアが最速で開発できる技術」を選んだものの、最終的にはGoやRustへ移行することになったわけです。

この話に関連する考え方として、TypeScriptをはじめとしたフロントエンド技術のスペシャリストであるuhyoさんが以前ブログで書いていた「積極的な技術選定と消極的な技術選定」という概念があります。

消極的な技術選定とは、技術以外の要素として「チームのメンバーがコードを書けるかどうか」「今のメンバーで開発すれば最速で進められるか」などを重視して決めるものです。一方で、積極的な技術選定とは、その時点でその技術的なユースケースに最も適している、言うなれば最強の技術を採用すること。この考え方をすれば、初期の学習コストはかかるかもしれませんが、中長期的には少なくとも「選定してすぐにダメになった」という事態を避けられます。

Rustを選んだのは、この考え方に基づいています。2年前のことですが、当時「RustでWebアプリを開発します」と言ったら、社外の人からは「正気ですか？」と言われました（笑）。しかし、今ではそんなことはありませんよね。

――「将来的に、この技術は生き残るだろう」といった肌感覚は、どのように磨かれてきたのでしょうか？

伊藤：常に、自分の価値基準をインターネットのど真ん中に置いておくことが大事かなと思っています。

技術選定の必要に迫られたときに、急に情報を集めても正しい判断はできません。特にオープンソースの技術には、その実装が生み出された背景や、それがコミュニティに支持されるようになった理由が必ずあります。そういう文脈を正しく理解しておかないと、自分たちのユースケースとの突合が難しいです。

日常的にさまざまな情報をチェックしながら事例を見聞きし、技術の表面的な善し悪しではなく、なぜその技術が期待されているのか、あるいは支持されなくなりつつあるのか、エコシステムが活発でいられる理由は何なのかなどの背景を追い続ける。そうすることで、「この技術はまだしばらく生き残るだろう」「このユースケースなら、この技術を選ぶべきだろう」と自然に判断できるようになります。

――他にも、失敗から学んだ事例はありますか？

伊藤：サービス分割の失敗でしょうか。

本来、モノリシックなサービスを分割する際には、業務ドメイン単位で境界を決めるべきだと思います。しかし、かつての私たちはマイクロサービス化の知見に乏しく、適切とは言えない分割をしてしまったケースが何度もありました。

たとえば、認証・認可の機能のうち「会員のランク情報」を扱う処理だけを切り出したことがあります。この機能はトラフィックが非常に多く、ランク判定の処理も複雑だったため、この部分を独立させるのが適切だと当時は判断したためです。しかし、本来であれば「会員管理」というより大きな業務ドメイン単位で分割すべきであり、その後、徐々に開発に支障が出るようになりました。

また、一休の社員が使用する最も古い管理画面は20年近くの歴史があり、VB.NETで動いていました。新しい機能を追加しなければならない局面で、エンジニアの中には「できるだけ古いコードを触りたくない」と考える人もいました。そうしたメンバーが、新しい技術を用いて別の管理画面を作り始めたんです。

エンジニアの視点では、新しい技術のほうが開発しやすいため、自然と新しい管理画面に機能が追加されていきました。しかしその結果、社内の人からみると「管理画面が2種類あり、どちらか一方でしか使えない機能が存在する」という状態になってしまいました。どちらの管理画面にどういう機能が存在しているかが技術的な理由だけで決められていて、ユースケース的な一貫性がなくなってしまいました。ユーザーである社員からすると、目的の機能が今みている管理画面にあったりなかったりで、とても使いづらいわけです。

こうした苦々しい経験を踏まえ、今の私たちが大切にしているのは、「ビジネスの要請がないのに、エンジニアの都合だけでサービスを分割したり、新しい技術を導入したりしない」ということです。

理由は二つあります。一つは、業務ドメイン単位で分割するという前提があるため、ドメインの要請を基準に考えなければ、そもそも適切な分割や技術選定は難しいと考えているからです。

もう一つは、新しい技術を導入するのにわざわざステークホルダーを説得せずに済むからです。たとえば、「1年かけて技術的負債を解消します」というような、工数が大きくかかる技術的な取り組みに関して、経営陣を説得するのは容易ではないですよね。苦労している人も多いと思います。

経営陣からすれば、その改修がどれほどビジネスの価値につながるのか不透明なため、人員をアサインする判断ができません。そうではなく、「ビジネスの価値につながる新規開発や改善の裏側で、技術刷新が行われていた」という状態が理想です。「あるビジネスの要請を叶えるために必要だから技術的な刷新も行った」これならば、誰も文句を言いません。

ただしこのとき、ビジネスの都合上「ここまでにリリースしなければならない」と決まっているのに、開発組織の都合で「この技術的負債を解消したいから、スケジュールを伸ばす」という判断はしません。こういう場面ではたとえレガシーな技術であっても、使い続ける覚悟を決めます。

要するに、技術的な取り組みをいつどう実現するかを、開発組織自身でコントロールできるようにしたいんです。それをいちいちステークホルダーの人たちに確認したりするから、調整が難航するんです。

自分たちでコントロールするというのは、すなわち責任を自分たちで持つということでもある。任されるためには相対する人たちからの信頼を貯めていくということも大事です。「この人たちに任せておけば、大丈夫」と思われていれば、プロセスについては問われなくなるでしょう。

――それを実現するには、エンジニアも事業やビジネスのことを理解し、意思決定に関与していく必要がありそうです。

伊藤：その通りです。だから私は、経営のロードマップを常に見ながら、「このタイミングで大規模な機能開発があるから、技術的なリプレイスができそうだ」と考えています。これは読者の方々へのアドバイスですが、自分が技術の方向性を定める立場になりたいのであれば、ビジネスに関わることから逃げてはいけません。プロダクトの方向性を人任せにせず、エンジニア自身も責任を持つことが重要です。

エンジニアの口癖として、ビジネス側の人から「こういうことをやりたい」と言われた際に、「いつまでにやればいいですか？」や「これは優先順位が高いですか？」と質問することがよくありますよね。しかし、このように尋ねた瞬間、意思決定の責任を相手に委ねてしまっている。許可を与える側と許可を求める側という関係性が生まれてしまいます。

よく「エンジニアはビジネスに興味を持て」と言われますが、それは決算書を読めるようになろうとか、自社の業界知識を深めようという話ではないと思うんです。私たちはソフトウェア開発を専門とする職業であり、ビジネスを専門とする人々と同じレベルで業務知識を持てと言われているわけではない。それでは役割分担の意味がありません。もちろん、できたほうがいいですけれど。

そうではなく、エンジニアリングを主戦場としつつ、プロダクト開発の意思決定に責任を持つということ。それができれば、技術選定の機会も自分たちでコントロールできるようになります。当然、それには責任が伴いますが、その責任を負うことで自由も得られるんです。

――今回の記事は、技術選定のスキルやアーキテクチャ構築のスキルを高めたい読者に向けたものです。そうした方々に、最後にアドバイスをいただけますか？

伊藤：ここまでの話を総括すると、技術選定とは、結局のところ「経営」です。ビジネスとテクノロジーのバランスをどう取るか、という話ですね。だからこそ、自分の仕事の領域や関心を固定し、「これだけをやりたい」と考えている人が技術選定を行うと、失敗する可能性が高いです。

技術選定にはバランス感覚が求められます。世の中の動向を常に追いかけながら、技術を見極める力を養う。そして、仕事の範囲を狭く定義しすぎず、多様な領域に積極的に関与する。そうすれば、「正解」でいられる時間が長い技術を、ビジネスに貢献しつつ取り入れていけるはずです。

取材：中薗昴、光松瞳
執筆：中薗昴
編集：光松瞳
撮影：山辺恵美子