データ圧縮によるキャッシュ最適化
広木大地氏（以下、広木）：この「問いを立てる」ことについて、自分が取り組んだことや、若い時に取り組んできたことを考えると、本当に最初期、エンジニアを始めたばっかりの頃に、たくさんアクセスがあるサイトで、一部のアカウントだけ「有名人アカウント」みたいにフラグを立てなければいけないことがありました。
これを全部、ユーザーテーブルに1個カラムを追加してってやっていくと、昔はダイナミックにカラムを追加するのは非常に難しかったので、「じゃあ、テーブル、JOINするか？ でも、JOINしたら遅いし」みたいな状況があったのですが、部分的なデータだけキャッシュとして持っていて、その判別をすればいいじゃんというのがありました。
部分的なデータは多くて、どんどん多くなっていくわけですね。特別なアカウントとして、例えば有名人向けに、この「アカウント1」「アカウント2」を有名人にしようとか、特別な扱いをしようみたいなことをしていくと、どんどんその数が増えていって、でも、ユーザー数よりはぜんぜん少ないというようなものをうまくキャッシュに収めようとした時に、そのまま全データをキャッシュに入れるんじゃなくて、圧縮できるといいなと考えました。
圧縮する時にすごくスパースにしか登場しない数列なわけですよ。「10001」の後は「50005」みたいな感じになっている、スパースにしか登場しないものだけど、業務の都合上、5人組とかだったら5個連続で現れたりしているみたいなことがあります。この業務フローに基づいてやると、実は1回微分しちゃって、全部差として定義してあげると、「1」「1」「1」「0」みたいなものが並びやすくなります。
そうすると、間のポンと飛ぶところだけ数字が現れて、小さいデータで「1」とかの連続と大きいデータが交互に登場するような数列になります。そうすると、「普通の圧縮アルゴリズムをかけるときれいに圧縮が効いて、めちゃめちゃ容量小さくなるんじゃないか？」と言ったら、10分の1ぐらいに圧縮できました。
それをキャッシュに詰めたら、キャッシュデータとして小さくても効率的に動作させられるなというのをやったことがありました。
それはなぜかというと、業務フローとしてどういうデータの扱い方をするかを知っていたことと、どんな性質のデータかと圧縮アルゴリズムという、この解決策の部分とその業務知識みたいなものがうまく重なったから、それがソリューションとして意味を成したなということです。
時間操作とテンプレート統一
広木：小さなことなのですが、最近だとフレームワークにもあるんですけど、キャンペーンみたいなのをやる時に、「何時何分にオープン」みたいなことを機能として作らなければいけなくて、「何時何分にオープン」ってやった瞬間に、QAの人や作っている人がずっとスタンバっていて、「あぁ、よかった、出た出た」みたいにやっているのは、すごくドキドキするなと思います。
その時間をうまく操作しながらQAするのは比較的難しかったので、フレームワーク自体に時間を操作できる仕組みを組み込んでQAできるようにしてしまえば、テストの時に困らないなと思いました。
それなら、そういう仕組みを作ろうか……これも、どういうふうに時間を扱っているかを知らなきゃいけないのと同時に、何が業務の手間になっているのかみたいな、時間をうまくコントロールできないことが業務の手間になっていることと併せて問題解決しているかなと考えました。
ほかにもいろいろあって、フロントエンドとバックエンドでテンプレートが違うと困るから、同じようにメンテできるように同じフォーマットのテンプレートエンジンを作ろうとか。
当時のフィーチャーフォンとPCのフレームワークには別々に管理しなきゃいけない要素があったので、それを統一できる仕組みがあるともっといいんじゃないかということをしていったのが、最初の頃に取り組んでいたこととしてはありました。
これは技術的にメチャクチャ難しいことをやっていたというよりかは、技術的にもある程度深追いしないとできないことはあると思います。
一方で、そこが業務のリードタイムの課題になっているとか、業務のクオリティの課題になっているということを発見して、それを解こうとしたことのほうが、良い問題設定につながったなと思っています。
知識の部分と問題設定の部分をうまくつなげていくことが、やはり良い問題設定というか、あまり難しすぎる方法を取ると、誰もメンテできない方法になります。
一方で、問題があまり業務に直結しないと独りよがりになるので、このあたりをクロスさせるために、仕事を観察し、業務を観察し、俯瞰します。「これが、なんでリードタイムが遅くなっているんだろう？」と思ったら、「できる人が少ないからだ」みたいな問題はそこかしこにあって、「じゃあ、できるようにするためのサポートをしてあげれば、リードタイムが短くなるよな」とか。
そういった観察は、トヨタでは多能工といわれていて、いろいろなスキルに変容できる人が工場内にいると、それによってリードタイムを短くすることができるから、1人が何個の役割もできたりすることを目指したんだよ、みたいな話があります。
そういった部分の背景知識と併せてエンジニアリング活動を見ていると、ある時、「あっ、これって、なんかうまく問題解決できるかも」になっていくような経験をします。
ここは、その時に考えていたのは、技術的な知識を深めて技術力を上げようということよりも、問題をよりよく見ようとして……よりよく見ようとしたら、解決すべき問いが見つかって、その時に深追いする力によって問題をもっときれいに解決できるかもしれないという、この両方が必要かなと思います。
なかなかそこの部分の、課題に気づいたり深く潜っていくことを技術力だと捉えきれていないと、「なんかちょっと、技術力つけたいんで」みたいな、「もうちょっとこういうことを勉強したくて」というのがふんわりした表層的なことになりがちなのかなと思っていて、一朝一夕じゃつかない分、そういったものが僕はけっこう重要かなと思ったりするんですね。
局所解と全体最適の狭間
湯前慶大氏（以下、湯前）：課題解決力を突き詰めるのもすごく大事ですけど、この課題設定力のほうもちゃんとやらないと、何だろうな、そこも突き詰めていかないとすごく難しく解きすぎてしまうとか、本質的ではないやり方でやってしまうということになりそうですよね。
広木：そうなんですよね。なので、僕は、設定した課題があるとそれで深く行けるところもあって、最初から「深いものがあるから」ってやると、なんでもトンカチで叩くみたいな、すごく不器用な技術の運用の仕方になっていって、「それって技術なのか？」っていうところが。
昔「ニコニコ動画」とかで、「技術の無駄遣い」みたいなタグが流行って。
湯前：ありましたね。
広木：「技術の無駄遣い」というテーマで、ニコニコ学会βとかで発表したこともあったので、無駄遣いは非常に大好きなんですけど。だけど、これは無駄だと自覚していながらやる遊びだと思うんですね。
そこは、無駄に宿るおもしろさはあるにしても、問題自体を設定することを見て見ぬふりをしちゃうのは、技術力の見方が乏しい感じになってしまうなと思っています。佐藤さん、どうでしたか？
佐藤将高氏（以下、佐藤）：ここ半年、1年ぐらい、メンバーと話す時によく話す話を、今、広木さんから聞いたなという感覚があります。
最近、メンバーに問うんですよね。例えば、「その問題の問いって、それで合っているんでしたっけ？」という質問を、僕はすることが多いです。
問題自体が局所的な問題に近くて、解かれる解が局所解みたいなことがすごく多いんですよ。自分から見えている範囲で言うと、もうちょっと広い高い山、解があって、たぶんそこが、僕の中でも局所解ではあるけど、全体最適の解に近いような問いと解があって。
「そっちじゃないんだよな」と思った瞬間に、その局所解に向けた技術の使い方をすると、違う意味でちょっと技術の無駄遣いみたいな状態になったりして、すごくもったいないなみたいな瞬間はあるんですよね。
これは、僕の中で「なんでそうなるんだろうな？」と思った時に、「教育上やってないからなのでは？」と思ったのもあるんですよね。
このことは何かというと、今まで数学の問題や物理の問題や、英語の問題もそうですけど、「この問題を見て、AからDまでの間でどれかを選びなさい」という問題の解き方はやっているけど、「英語の問題を作りなさい」とか「数学の問題を作りなさい」というのはやったことがないから。
「そもそも問題ってどうやって作るんだ？」みたいな、絶妙に難しいのか簡単なのかわからないけれど、問題を作れないことで悩む人がいるなと感じるところがあります。
技術力の問いの設定みたいなところで言うと、やっていないからみんな難しくて、そこに目が向いていない可能性があるのかなと話を聞いていて思いました。
well-definedな問題を超えて
広木：そうですね。いや、それは本当に、学校教育に引っ張られているところもなきにしもあらずだなと思っています。このあたりの、仕事をしていくことはスタディ性というか、研究的な要素を伴います。僕は、自由にバーリトゥードになっていくというか、なんでもありで問題解決していく社会にポンと出てから非常に生きやすいなと思ったんですよ。
僕自身が、学校がちょっと面倒くさいなというか、学校がなんか変だなっていう感じがやはりあって、それよりは、（社会は）問題を自由に設定して探究できるっていう……。最近は、探究学習やアクティブラーニングが増えていますが、僕自身は探究心を培えるようなことはけっこう個人的にやることが多くて、学校はそうじゃないものを強いてくる場みたいな感覚だったんですよ。
でも、学校教育でこの探究的なことがぜんぜんインプットされていないからこそ、例えば大学生でゼミになって研究テーマを決めようとか、そういうふうになると、考えることを、初めて問題を創出しなきゃいけなくなってくるのが非常に重たくのしかかってきます。
仕事になってとかそういうところで、問題が与えられて、与えられた問題を良く解くんだというようなことになってくると、どんどん仕事の幅は狭まっていっちゃうし、自分で選べないなと思います。
なので、well-definedな問題、よく定義された問題を当たり前なものとして受け入れて、その中だけで答えを探っていく活動から、一歩外に出て考えていくのが非常に重要なのかなと思っているんですよね。
なので、その中でもうちょっと本質的な問題について考える、「その課題は何だろう？」と考えるアクションをすごく増やしていくことのほうが技術力に直結するような問いの立て方に近づいていけるのかなと思っています。
そのためには、抽象と具体のはしごというか、ある抽象の部分、なにかを抽象化して、あるいは問題を抽象化することと、具体的な課題を見詰めてその中の本質を見極めていくことが……見極めるというか1個ずつ解決しながら、その解答の共通性を見いだしていくことが非常に重要だなと思っています。
（次回につづく）
