日本ならではの“こだわり”と、「他の人がやってくれるだろう」を生まない環境がすばらしい　登大遊氏がリクルートのエンジニアが取り組む案件に感じること

小杉氏の自己紹介と、取り組んでいる案件について

竹迫良範氏（以下、竹迫）：続いてはリクルートの開発事例について2件紹介いたします。小杉さん、鶴谷さん、よろしくお願いいたします。

小杉衛史氏（以下、小杉）：よろしくお願いします。

鶴谷誠文氏（以下、鶴谷）：よろしくお願いします。

竹迫：それでは最初に小杉さん、自己紹介からお願いいたします。

小杉：はい。小杉衛史と申します。よろしくお願いします。私は2016年にリクルートに中途入社して、各ネットプロダクトを中心に初期開発や再構築プロジェクトの基盤を担当していました。今は社内プライベートクラウドの各種EOSL（End Of Service Life）対応を（していて）、サービス停止を無停止で実現したという案件が、このFORUMに選出されました。

ここからはこの案件の概要を説明しようと思います。

みなさん知っているように、毎日コマーシャルで流れているようなプロダクトやサービスを、リクルートは多く抱えています。この多くのサービスが稼働しているシステムを「RAFTEL」と我々は呼んでいるのですが、全社標準のプライベートクラウドを管理、運用しています。

100を超えるぐらいのサービスが動いているシステムで、やはりそれなりに規模も大きくて。物理サーバーの台数でいうと1,000台ぐらい。仮想ホスト、VMの数でいうと4,000以上。ストレージとかはもう数PBという単位の、国内のオンプレミスでもだいぶ大きな規模になっているんじゃないかなと思っています。

これだけ規模の大きいシステムになると、先ほどもあったEOSLという対応が必要になってくるのですが、機器の数がかなり多いので、年中EOSL対応をしなければ延命できないような状況が続いています。さらに、膨大な機器のEOSL対応をどうサービスに影響なく推進できるのかがポイントになっております。

中にはやはりオンライン、サービス中にEOSL対応をしてはいけないというような、ベンダーのサポートを得られないような製品もありますので、ここが我々の課題となっていました。

サービス影響なく、どう進めていけるのかを考えたのですが、全社で標準的に使われているようなアプリケーションをベースに独自のベンチマークツールを開発して、検証環境でEOSL作業を実行した時のサービス影響の可視化をしました。

そしてEOSLの対応方法の改善を繰り返して、サービス影響を極小化するというところにたどり着きました。結果、無停止でEOSL対応を推進することができて、我々の検証結果を見せて、当初サポート外と言われていたベンダーの方々からも「非公式ではあるがこのやり方で進めていいんじゃないか」というサポートをもらうところまでこぎつけることができました。

成果ですが、このEOSL対応はインフラ稼働率は2021年度で100パーセントを達成しています。計画的な作業でのメンテナンスの停止時間を含めて、年間の停止時間がわずか6秒という、サービスに影響なくEOSL対応を進められたかなと考えています。

メンテナンスの対応工数を削減できたというのが2点目の成果です。やはりシステムを止める、サービスを止めるということになると、対応工数がそれなりにかかってしまうんですね。我々は広告のモデルでサービスを提供していたり、SaaSのサービスを提供をしていたりするので、クライアントやカスタマーに広報するという稼働ももちろん発生してきます。

このあたりの工数が不要となって、本来やるべきビジネスを伸ばす業務に注力できたのが、すごく大きな成果だったのではないかと考えています。

最後（の成果）は、我々自身の組織が強化できたのかなと思っていて。先ほどのベンチマークツールを、我々自身が社内の標準的なアプリケーション、プロトタイプというか、ベンチマークツールで作成して実際に動かしているところへのインフラ作業による影響を見極めることができた。

インフラエンジニアがアプリの領域に一歩踏み出してサービス停止を回避するためのチャレンジができたというのは、インフラ組織の組織力を強化できたポイントになったのではないかと考えております。私からの説明は以上です。

竹迫：小杉さん、ありがとうございました。EOSL対応とかで、マイグレーションしている最中に予約システムとかが問題なくトランザクションを捌けるように、それをちゃんと確認しながら進めたと。

小杉：そうですね。

竹迫：わかりました。ありがとうございます。登さんはどうですか？　今回の小杉さんの案件を見て、感想などをもらえたらと思うんですが。

登：すばらしいなと思ったのは、EOSL対応のシステム移行で停止した秒数がわずか6秒であったというところだと思います。他の国のIT先進国のIT技術者集団の一般的な考え方では「これは停めてもいいんじゃないか」と諦めることが多いと思いますが、日本のこの品質は、イメージでいうとアメリカ製の家電製品とか、アメリカ製の自動車よりも日本製の家電や自動車というのは桁違いに品質が高く、まったく心配しなくても止まらずに使えるということで、全世界に大いに普及したと思うんです。

こう考えると、今のリクルートさんの、あの膨大なシステムでなんと6秒しか全部止まらずにできるという、そのこだわりと精密さにかける情熱は、先にお話しした日本製の自動車、例えばトヨタとかとまったく同じ物のサイバー空間上の車であろうと思いました。

となると、アメリカにもクラウドサービスやいろいろなシステムインフラの事業者さんがいますが、あれの日本版みたいなものがリクルートさんの精神と同じものを共有できる、多くの日本企業から生み出すことができるんじゃないかと思います。

他の国はこれにはこだわらないですが、なんと6秒にこだわって成功させてきたということは、他の国では技術者を集めてもこれには勝てないんじゃないかと思い、ものすごく高い価値があると思いました。

小杉：ありがとうございます。

竹迫：登さんありがとうございました。

鶴谷氏の自己紹介と、取り組んでいる案件について

竹迫：では、続いて鶴谷さんからですね。リクルートの取り組みについて紹介をしたいと思います。鶴谷さん、自己紹介からお願いいたします。

鶴谷：はい。リクルートのデータ推進室の鶴谷誠文と申します。証券系SIerで10年、インフラエンジニアやシステムコンサルタントを経験した後、2015年にリクルートに中途入社しました。リクルートではリクルートIDや『SUUMO』のデータ基盤を担当しています。趣味は阿波おどりで、このままコロナが収束して、夏に高円寺や地元の中村橋でまた踊れる日が来るのを楽しみにしています。

（スライドを示して）さっそく本題ですが、私のFORUMの内容はこちらに記載の案件になります。私が所属しているデータ推進室で、企画、開発している「横断プロダクト」と呼ばれるプロダクト群があるのですが、その利用形態として、マルチテナント方式に加えて、セルフホスティング方式と呼ばれる新たな方式を整備して適用した案件となります。

そもそも横断プロダクトはリクルートの複数の事業領域での利用を想定して企画、開発しているプロダクトです。領域共通で利用できる機能を一元的に開発することで各領域の個別開発が不要となり、いわゆる車輪の再発明を防ぐことを目的としています。

そのような横断プロダクトの中で本日取り上げたいのが「Crois」というプロダクトです。このCroisですが、バッチ処理を効率的に開発・運用するためのバッチワークフロー機能を提供するプロダクトです。あらかじめ複数の領域での利用が想定される機能が共通モジュール化されていて、それらのモジュールを利用して、効率的にバッチ開発ができます。

もちろん開発者が独自にモジュールを開発して、それをみんなに公開することもできます。さらに、コードベースでバッチワークフローを効率的に開発できる機能や、バッチワークフローのスケジュール実行をしたり、実行結果や実行ログをWeb上で参照できる機能などを備えます。

これまでバッチワークフロー機能は表の左の側にあるとおり、クラウド事業者が提供しているサービスを利用している方式だったり、サードパーティ製品を利用する方式といった、外部サービスや外部製品利用が主流でした。

外部サービス・外部製品利用だと自社開発が不要である一方で、機能不足だったりライセンスコストの高さのデメリットがあります。そこで複数事業で利用できる横断プロダクトとして内製開発することで、リクルートに特化した機能をROI（Return On Investment）高く実現することを狙って開発を進めています。

ここからが課題となります。これまでの横断プロダクトは、複数領域で共用環境を共同利用するマルチテナントのみの利用形態でした。このマルチテナント方式は共用環境を共同利用可能であることから、安定運用の要求レベルが高まるにつれて他領域でバースト的な負荷がかかる際に影響が起きる可能性があったり、複数領域で同時に障害が発生した際に対応優先度が決めづらいであったり、プロダクトの内部ログが参照できないということで、障害調査に時間を要するなどの課題に直面するケースがありました。

そこで、そのような課題を解決するために新たに設計したのが、事業領域専用の環境をセルフで構築・運用するセルフホスティング方式です。即時に開発を始めたいパイロットフェーズではマルチテナント方式、より安定的に運用したい本格導入フェーズではセルフホスティング方式に切り替えることで、より安定運用を求める領域にも横断プロダクトが導入可能となる方式を整備しました。

今回実現したセルフホスティング方式がどのようなものかを、横断プロダクトCroisを『SUUMO』のレコメンドシステムに導入した際の事例で説明したいと思います。まず背景として、『SUUMO』のレコメンドシステムは『SUUMO』のサイト上でカスタマーにおすすめの物件を計算して表示しています。最新の物件情報の更新だったり、機械学習モデルの更新が行われないとユーザー体験が悪化してしまうので、Croisへ移行した際には安定運用を実現する必要がありました。

そこで、マルチテナント方式の安定運用の懸念を解消するために適用したのが、セルフホスティング方式でした。セルフホスティング方式のポイントを簡単に2点紹介します。

1つ目が、セルフ方式による自律的な構築・運用を実現した点です。Croisのインフラ環境構築手順を汎用化した「Terraform」を整理して、環境構築手順とともに公開しました。

さらにCroisを任意のバージョンに自動かつ無停止でアップデートできるようにデプロイツールを開発して、アップデート手順とともに公開しました。これらの公開したツールや手順を参照することで、『SUUMO』の領域担当が自律的に環境構築やアップデート運用をできるようにしました。

2つ目が、領域担当による一元運用と兼務体制によるナレッジ習得です。領域担当が領域専用の環境を構築をしてインフラからアプリまで一元的に運用できるようにしましたが、安定運用のためにはCroisの仕様を熟知することも必要です。そこで、『SUUMO』担当のメンバーがCrois担当チームに兼務して開発に参画することで、Croisの仕様を理解して、そのナレッジを領域に持ち帰れるようにしました。

まとめです。今回、横断プロダクトの展開方式として、共用環境を共同利用するマルチテナント方式に加えて、事業領域専用の環境をセルフで構築・運用するセルフホスティング方式を準備して、フェーズに応じた適切な方式を選択できるようにしたというのが内容になります。以上です。

竹迫：鶴谷さん、ありがとうございました。共通の基盤だとバージョンアップとかも全部一律に上げるけれど、個別環境だから、バージョンアップとかも個別にそれぞれの（領域に合わせた）スケジュールでもできるようになったと。

鶴谷：そうですね。領域ごとにサイクルとかも決めたいという要望があったので、領域個別でアップデートのサイクルとかを決められるような仕組みになっています。

竹迫：ありがとうございました。登さん、今回の鶴谷さんの案件にコメントをぜひお願いします。

登：すばらしいなと思ったのは、セルフホスティング領域という概念は、独立できるじゃないですか。そうではなく「共用のシステムを使うべし」とするのは、日本企業の多くのITの考え方にいつのまにかはびこってしまった。良いところもあるものの、一番レベルの低いところに合わせないといけないという悪いこともかなりあると。

リクルートさんのセルフホスティングは互いに違うバージョンを好きに使ってよろしいということを認めて、しかも（そうすることで）先ほどの運用担当者という概念がそれぞれ別々に成立します。そうすると、各担当者、各部門の中のIT・リテラシースキルがイヤでもこれで高めなければならないということになります。

日本企業にはびこっている共通方式では、「他の人がやってくれるだろう」と言って担当者に押しつけ、担当する人も、たくさんのものの共通的な、全員が納得するようにするのは大変だから外注します。

そのように外注するとわけわからんことになりますが、「自分のところは自分の力で守る」というということは最高じゃないですか。Croisという概念はバッチ処理ですから、これはまさにシステムソフトウェアの領域だと思うんですよ。

これを第三者任せにせず、なんと自社で開発していて、しかもそれを社内で分散してそれぞれのシステムで動かすことができているというのは……。20年前ぐらいのAmazonの会社の中で大量の分散システムをいかにうまく分離して、かつ統合するかということを彼らも考えたそうです。あの大量のLinuxをどうするか。ネットワークをどうするか。それぞれが分離して、しかし統合してやるには自分たちのシステムを作ることが重要だと。

（ということで）そのフレームワークを社内で作ったらしいんです。それがAWSとかEC2と今呼ばれているものだと。歴史上残っているので、今のリクルートのやり方も相似的に見えましたから、日本からもそういうものが生まれるかもしれない。

社内だけで使おうと思っていたものが、優れたものであれば外でもどんどん使われて、いずれ世界の中の中心的存在になるんじゃないかとというふうに、今聞いたことで思いました。

鶴谷：ありがとうございます。

竹迫：登さん、お褒めの言葉をいただけて大変うれしいです。今回は時間の関係上、Croisのシステムについてはあまり言及しなかったんですけど、巨大な分散Makefileみたいな仕組みで動くものです。あとは、特に中間ファイルとかが途中で生成されるんですが、それも処理が終わったら安全に消去するとか。

リクルートって、カスタマーの個人情報というお客さまの大事なデータを扱っているので、きちんとあとが残らないように処理することをそこで担保しているという仕組みになっています。

登：内製で作られたというのがすばらしいなと思います。

鶴谷：ありがとうございます。

シン・テレワークシステムの運用の仕組み

竹迫：ちなみに、登さんはシン・テレワークシステムとかも作られて運用もされていると思います。あれってけっこう自治体向けとかと、あとはオープンソース版とかいろいろあると思うんですが、そのあたりの運用の仕組みとかもちょっと教えてもらえますか？

登：まさに（今）示されたCroisと同じような感じになっています。ベースとなるソースコードのGitリポジトリがあります。Aシステム、Bシステム、Cシステムって派生のものがあるんですけど、好きなバージョンを使い、場合によってはブランチで分けても良いようになっていて。先ほどコメントがあった自治体向けと民間・一般企業向けとオープンソース版は、全部世代が違うんです。

世代が違っても1個は新しい機能を追加したら、他にもうまくそれを持ってこれるような感じになっているので。たぶんリクルート社の中でも同じ……。まぁ技術者はみんな同じような発想をしますから（笑）。「これをやろう」という時に、技術者のその「やろう」を妨げることなく「まぁ、自由にやってください」と言われたんだと思います。だからうまくいっているんじゃないですか？　これはすばらしいと思います。

竹迫：ありがとうございます。

けしからん大企業が自由な開発を行うためにできる説得方法

竹迫：ではここからはみなさんの質問に答えていきたいと思います。まず1番目の質問ですが、登さんに質問です。「けしからん大企業において、自由な開発を行うためには、どのような説得方法が考えられますか？」。

登：これは説得を紙に記述して「説得に行こう」という、事前の説得を考えるという戦略に聞こえます。思うに、経営者という方々は、ふだんリスクや、それをやった時にいったいどんな利益があるのかとか、どんな訳わからないことが発生するのかを常日頃考えることを仕事にしているんだと思うんです。

我々のような技術者も、経営者の方々に説得する時は事前にQ&Aを用意するのではなく、経営者の方々が有している勉強の知識とほぼ同じものを勉強するというのが、もっとも説得をしやすい方法です。

あれはなんか口頭試問だと思うんです。「これはどうなんだ？」とかリスクについて聞かれた時に、「考えます」と言うんじゃなくて、「それはそうに決まっているじゃないですか！」って言ったら「あ、自分と同じようなことを考えているんだな。じゃあ安全やな」と。これで説得が可能なんじゃないかと思いました。

竹迫：ありがとうございます。そうですね。リクルート社内でも起案というやり方で図ったりしますが、小杉さんとか鶴谷さんのほうではどうですか？　登さんと同じような経験や説得の方法ってあったりしますか？

小杉：同じ目線で立つということは僕も考えますね。「経営層はどう考えるんだろう」ということを、自分でも考えられるような視点とか視座を身につけようというのは意識して日々業務をしています。

竹迫：わかりました。ありがとうございます。

無停止EOSL対応を推進する際に特に重きを置いた点や難しかったこと

竹迫：続いて小杉さんに質問です。「無停止EOSL対応を推進する際、特に重きを置いた点や難しかったことは何でしょうか？」という質問です。

小杉：一番重要視したのは、サービスを止めないということです。我々のエンジニアの作業だけではなく、やはりクライアントやカスタマーに多くの事業の方々、営業の方々が調整しなければいけないという工数が発生してしまうんですね。エンジニアの（システム）作業だけではなく、やはりリクルート社全体での工数を考えた時に、やはり停めずにやれるのであればそれが一番望ましいかなと。

それで本来やりたいビジネスを伸ばすという業務に注力できる状態を作れるということを考えた時に、サービスを止めないということを意識して進めました。

竹迫：ありがとうございます。

Croisで独自システムの開発を選択した基準

竹迫：次は3番目の質問ですが、鶴谷さんに質問です。Croisの最初のほうに内製するか、その外部のツールを使うかという選択があったと思いますが、「業務をシステムに合わせるのか、それともシステムを業務に合わせるかの選択で、独自システムの開発を選択した基準というのは何だったのでしょうか？」という質問です。

鶴谷：そうですね。2つの大事な観点があって、まず、（実際にプロダクトを使う）利用者が幸せになるかというのがありました。移行して利用者の開発体験が上がったりとか、運用が楽になったりというモチベーションが湧くようなことの観点が1つあります。

もう1つは移行の実現性です。やはりどんなに計画が良くても、結局できなければ意味がないので、実現性の高い計画や移行の方式を考えるという2点を「満足させるには」と考えた時に、今のクラウドのサービスにあるバッチワークフローだと独自言語を覚えないといけないなどの要件があって、開発者のハードルも高かったので、「だったらじゃあみんなが幸せになるCroisに移行したほうが幸せだよね」というモチベーションを大事にして内製を選択しました。

竹迫：ありがとうございます。やはりシステムを使う人を「使わせる」という強制（の考え方）ではなくて、「その人が幸せになるようなシステムを提供する」という、そういう考え方が1つの基準だったということですね。

鶴谷：はい。

竹迫：ありがとうございます。

ICTの次世代の人材育成のために子どもたちに向けて広く仕掛けていきたいこと

竹迫：続いて、登さんにまた質問があります。「ICTの次世代の人材育成のために子どもたちに向けて広く仕掛けていきたいこととかはありますか？」という質問が来ています。

登：はい。コンピューターのアプリケーションだけではなくて、インターネットのインフラレイヤー。小さな小学生、中学生の方々が見ても、その裏側がどうなっているかというのを知りたい方は一定数いるので、そういう方々に若い頃からインターネットのインフラ部分を触ってもらう。

（それをすることで）もちろん技術者として優れた能力を有するようになるんですが、もう1個重要なのは、自分、例えば個人でもいいし、自分の会社組織でもいいし、自分自身は自分で守る。他が倒れても自分のところは倒れないように。先ほどのリクルートさんの内製（の話）というのもまさにそうで、他のフレームワークを輸入して買うと、そこの開発元が倒れたらリクルートさんもその部分が倒れてしまいますが、そうならんと。

インターネットの部分は何でも自分でやらないといけないということになりますから、それを勉強するうちに、他が倒れても自分は倒れないような最善の努力を自分の頭脳だけでやらんといかんという、そこが習慣づけられるんじゃないかと思います。これが若い方々に対して非常に重要な価値を帯びるんじゃないかと思います。

竹迫：ありがとうございます。あとは、（登さんは）つくばで中学生向けにRaspberry Piとかのワークショップとかをやられていますが、あれはどういうものなんですか？

登：あれは最初はみんなと一緒に始めて、うまいこといったらしくて7年ぐらいやっているんですけど。グローバルIPの無添加、NATなんかのイヤな添加物が付いていないIPアドレスとサーバーを、中学生の教育委員会なんかで20名ぐらい募集して、中学生に配るんですよ。そうすると（その子たちは）生き生きとして。（その環境には）Webサーバーとか、自作プログラムとか、グローバルIPとか、そういうのをずっと置いていてもいいんですよ。

校舎に置いてあるんです。非常に人気が出ていて、今は自分たちの一派の後輩のみなさんがやっているんですけども、あの異常な人気をどうスケールするかというところが重要で。そういうのが好きな先生とか大学の方々を日本中で集めれば、いろいろなところでそれができるんじゃないかと今は思っていますが、まだ準備ができていないです。

竹迫：ありがとうございます。ちょうど私が1995年に大学に初めて入学して、インターネットにも触り始めたんですけど。当時はファイアウォールがなくて。イスラエルの会社がちょっと作っているとか、そういうぐらいのものでした。まさにプリンター1台にもグローバルIPアドレスが付いていて、外から何でもパケットが来放題な感じだったんです。

だけど今は学校とかいろいろな組織の中ではNATみたいなものがあって、ぜんぜん外から来ないんですよね。

登：そう。なんか脆弱になってしまったんですよ。ずっと過保護な人がいるから、中の人が「何もせんでも安心やん！」みたいな感じになっている。

竹迫：なんかアレですよね。無菌状態で育っちゃうと、外から刺激物が来ると大騒ぎしちゃうみたいな。鶴谷さんとか小杉さんとかは、何か経験あったりしますか？

小杉：そういう経験はあまりないかもしれないですね。無菌状態か。守るという前提になってWebサービスを作り始めたので。外部からは遮断しなければならないものだと思っていました。

竹迫：なるほど。そっか。でも面倒見て、過保護にしてあげればあげるほど、実は次の世代が育ちにくいみたいな話もあるので。やはり本番環境だと難しいから、実験環境とかそういうのを用意して、そこで自由にできる仕組みが必要なのかもしれないですね。

小杉：そうですね。開発環境をローカルに作る。それで自由に触れるようにするみたいなことは、最近はコンテナとかも使えるようになってやりやすくなってきたので、そこを実験場にするというようなことはやっています。

竹迫：鶴谷さんのデータ推進室というところも、従業員の人が「このクラウドをお試しで使いたい」と言ったら「使っていいよ」と。アカウント発行とかもやったりしていると聞いたんですけど。

鶴谷：そうですね。今はちゃんと整備しようと始めたところではあるんですが、自由に遊べる環境があると、いろいろ試したりして、そこでアイデアが生まれたりというのがあるので。もちろん企業なのでセキュリティだったりコストだったりの制約がありつつ、その中でうまく勉強環境みたいなものを作れればなというところで環境整備を（ちょうど）今進めています。

竹迫：ありがとうございます。

サービス部門で働くエンジニアはリクルートにはいるのか

竹迫：じゃあ次は小杉さんへの質問へ行こうと思います。「エンジニアが開発現場ではなくて、あえてサービス部門で働くことに一定の価値があるように感じます。現場にそういった人物はいらっしゃるのでしょうか？」という質問が来ていますね。

小杉：サービス部門。

竹迫：いわゆるSIerのインテグレーション部門じゃなくて、サービス、事業会社とかそういったところですね。

小杉：そうですね。我々の会社の中だと、ディレクションという、開発マネジメントをするチームがあります。あとはITサービスマネジメントを専門にやっているチームもあるんですね。システム運用とかセキュリティとかの専門家はいたりするので、そこはやはり横断の組織の中で動く、我々のような横断でプラットフォーム、ソリューションを提供するというのではなく、事業と近いところでそのプロダクトに伴走して動いていくというような役割が必要で、今はすごく機能していると思います。

我々からも、その方々を通じて事業に関わる多くの人とコミュニケーションを取れるという状態が作られ始めているので、すごく動きやすくなったなとは思っているところです。

竹迫：ありがとうございます。

エンジニアから見た、証券システム系の会社とリクルートの文化の違い

竹迫：続いて鶴谷さんに質問があります。「エンジニアから見た証券システム系の会社と、今のリクルートの文化の違いって何かありますか？」という質問です。

鶴谷：そうですね。私は新卒で証券系のSIerに入ったんですが、証券系のシステムのデータセンターを移転して、基幹システムも含めて丸ごと新しいデータセンターに全部引っ越すということをやったんですけど。これには4年かかりました。リクルートだとたぶんこの4年が何分の1ぐらいになる感覚なので、結局やることは変わらないんですが、リードタイムというところのスケールをどう考えるかだとは思います。

証券系だと（リスクに重きを置いて）登り方をゆっくり時間をかけてやるところを、リクルートだと、ある程度さらにリードタイム短くやるというところが違いで、そこにおもしろさを感じたりもしています。

竹迫：ありがとうございます。

無停止移行できると思った判断基準

竹迫：続いて小杉さんに質問です。「実際に失敗したら大変だったと思うんですけども、メーカーのサポートもないのに無停止移行できると思った直感とか、判断とかって何だったんでしょうか？」という質問です。

小杉：やはりサポート外のことを進めるというところに障壁はものすごくありまして。たぶん数百回、数千回は下らないと思うんですが、どういう作業をやった時にアプリケーションにはどういう影響が出るかを確認しながらテストを繰り返して、「このレベルであればサービスに影響を出さずにできるかな」というのを、先ほど説明したベンチマークツールで判断したというのが、兆しが見えた点です。

とはいえ、やはり本番のアプリケーション、商用で動いているアプリケーションで試さないと、「本当にやって大丈夫なのか」という判断がなかなかつかなかったので。リクルートの中でも年間のトラフィックが一番高いサービスがあるんですが、そこの負荷環境を間借りして検証させてもらって。そこで影響がなかった時に初めて「あ、これはもう全体に適用できるんじゃないか」という判断をしました。

竹迫：ありがとうございます。

発想力を得るためにエンジニアリングの勉強以外に役立ちそうなこと

竹迫：次は登さんに質問です。「登さんのような発想力を得たいです。エンジニアリングの勉強以外に役立ちそうなこと。趣味でもいいので何か教えてください！」という質問が来ていました。

登：自分の発想力はだいぶ乏しいので役に立たないと思いますが、やっていることとしては人文系、社会系の書籍とかを暇な時間に読むとか。あとは、役所の中のアーキテクチャは、大企業もそうですが、人間のアーキテクチャも含めて、だいたいは巨大な組織になると1人の人が把握できない、いろいろなコンポーネントで数珠つなぎになっておりますから、それを全部わかる人は誰もいないというところが驚くべきところなんです。

誰もいないけれども、自分ぐらいはちょっとがんばって全部把握するとおもしろいんじゃないかと思って、それを1つずつつないでいくのであります。そういうふうにやると、「ここはどうなっているんやろう？」とか、いろいろな諸制度についてどうしても自然に勉強することになるんだと思います。それらとコンピューターの物事のつながりのかたちは、コンピューターのシステムの中におけるつながりのかたちと相似なかたちを持っていると思います。

それで「これとこれはえらい似ているなぁ」とかみたいに感動を受け、より調べたいと思うという、その繰り返しで。物好きなので、物好きしか調べないようなことを調べていくということで、スムーズに進んでいるんじゃないかと考えています。

竹迫：ありがとうございます。実は私はIPAで未踏のプロジェクトマネージャーとかもやっているんですが、そこの統括PMの竹内先生（竹内郁雄氏）が「優秀なプログラマーって、実は国語力がメチャクチャあるよね」という話をされていて。いわゆる日本語をちゃんと書くとか、相手に伝わるように書くというのは、実はコンピューターに指令を送るプログラムも、コンピューターに対してちゃんと伝わるように書く（のと同じ）。

そのどちらも訓練ができているという話とかもあったりとかしていて。登さんがそういう人文学的な、社会学的なところにも興味があるのは非常におもしろく感じました。登さんが公開している文章とかも、すごく長いものが多いですよね。

登：コンピューター以外の他の全学問分野は、あれぐらい長いものを書いて次の世代に継承しているんです。（本来は）自分の勉強したことは全部次に教えるべきなのに、コンピューターのものだけは頭の中に暗黙知として留め、文書化するのをこの30年あまりやっていないから、これはまったくもって「けしからん」才能の私物化であると思います。

したがって、リクルート社の中にあるノウハウも、内部・外部であまり分け隔てなく文書化すると、世界一の日本語で書かれた文献群が生じ、それが他の発展途上国にもどんどんと勉強のために使われるような、そういう輝かしい価値が生じるんじゃないかと思いました。文章を長く残すことはもっとも重要で、人間の存在できている要因は、その文章の存在だというふうに思います。

竹迫：ありがとうございます。それではみなさん、本日はたくさんの質問をいただきありがとうございました。