熊崎 宏樹:LLMの出力が「情報技術を深く理解していること」に取って代わるような気がまだしてこないというのが僕の感覚です。 文章の繋がりから情報工学を理解しているかのように見せかける事は病的に上手いのが近年のLLMですが、例えば今書いているソフトウェアがどうあるべきかという議題に対してまるで役に立たないからです。ある程度巨大になったコードはモジュール単位で責務が別れており、プログラマは適宜「このコンポーネントはAを食わせるとBを返す責務がある」のような脳内モデルを構築してホワイトボード上でポンチ絵を共有したりデバッグに役立てたりしています。今の所LLMはそういう脳内モデルを構築するのが致命的に下手というかそういう能力がまだ搭載されていない気がします。そのモデルに沿って「ここにデバッグ出力入れたらわかるんじゃないか」とか「その新機能はこっちのコンポーネントに実装するべきでしょ」といった話をしたいのにそのレベルには人間しかついてきてくれません。 こういう常識の欠如を「世界モデル」なんて言葉で今のLLMに足りない機能として説明している人も見かけますがそれに近いかも知れません。 https://note.com/masayamori/n/n34df50d83489 ですのでLLMが来れない部分、つまりソフトウェアやハードウェアの内部をモデル化して抽象的な話をする事について価値を出していけるよう学習内容を考えていくのが良いと思います。 それはそれとしてコードレビューを通過するようなまともなコードというのは大体パターンがあるので（配列全体を回るときは範囲イテレート文を使え、とか）模様のような決まりのあるコードパターンを書くときはLLMが大いに助けになるときはあると思います。「ブロックごとコード補完が来た」という話は今もcopilotでよく見かける話でこういうのは早期から使い慣れておくのがおすすめです。

熊崎 宏樹:僕の過去ツイートの話ですね。 ソフトウェアに限らずパイプライン処理を組むと処理がステップごとに並列化できて、皆さんお使いのCPUのALUの内部では10段以上のハードウェアパイプラインが組まれている事が普通です。 ソフトウェアパイプラインというのは例えばとても計算量が重くデータ並列性の低い処理があってもA→B→C→Dという4ステップに分割できたのなら4コアのCPUでコア1がA担当、コア2がB担当、コア3がC担当、コア4がD担当という形にしてやってくるデータをバケツリレーしながらステップごとに担当を分ける事で定常的にデータがやってくる限り4つのコアの計算力をフルに活用した処理ができるので1コアでやるより4倍のスループットが出るようになります。基本的には段数を増やすほどに並列度は上がるのでスループットの増大も期待できます。 そしてここからが面白いのですが、大抵のケースではそんな簡単にスループットは上がりません。というのもCPUのキャッシュというのは実は直感の数倍速くて、CPU間のデータ通信は直感の数倍遅いからです。ナイーブにソフトウェアパイプラインを実装すると通信のオーバーヘッドが並列化の利得を上回ってしまってトータルでは性能が落ちてしまうということはザラで、どの程度の粒度のパイプラインに分割すると性能が最大化できるかというのはいろんな要素で変動する読みにくいパラメータです。 クラウドが一般的になった現在、クラウドで使える仮想マシンには200Gbpsとか出るすごいNICがつながっています。 https://docs.aws.amazon.com/ec2/latest/instancetypes/hpc.html#hpc_network これほどの帯域があればソフトウェアパイプラインを組む際のスイートスポットも変わってくるんだろうなという気持ちで眺めています。

熊崎 宏樹:そ、そんなにこき下ろしているでしょうか…？ プログラミングにおいて教条的に何らかの思想を上から振り下ろす事に対して違和感を持っているだけのつもりで、代わりに何らかの思想を振り回す事が良いとも思っていません。 クリーンアーキテクチャの書籍では「データベースなんかは玄関のドアノブのパーツぐらいの重要度しか無いのでいつでもドアノブを取り替えれるようにだけしておいて本題に集中しろ」みたいな事を書いていたので流石にそれは無茶というか巨大プロジェクトがエアプなのかって感じる事はありました。改めて主張を整理したいと思います。 まずDBとドメインロジックをベッタリさせて書いているか？という問いですがYESです。特にGoogleの場合は「SpannerからMySQLに移行しよう」みたいな話はまず出てこないですし、仮に移行するならそういう独立したプロジェクトとしてチームで取り組む規模の話になることでしょう。またユニットテストでも可能な限り本物に近い環境を使うように努力せよという指針も公開されています。 https://testing.googleblog.com/2024/02/increase-test-fidelity-by-avoiding-mocks.html ドメインロジックがベッタリしていると困るケースとしては他にロジック自体の意味がわかりにくくなるというケースがあります。ただこちらは純粋にコードの抽象度の話であって、不慣れな人がコードを書いたら抽象度の高い業務ロジックとDB実装側の都合から来る個々のコードが入り乱れて読みにくくなるのは「DDDを適用しなかったせい」ではなくて「コードの再利用性が低いせい」です。 オブジェクト指向や他のパラダイムの事を神格化して聖典のように崇める人もいますが、一介のコード書きから見たらそれらすべて「コード整理術」の一部でしかありません。膨れ上がり続けるソースコードと向き合って増加し続ける複雑さをどう整頓するかがすべてです。整頓することの恩恵を部屋の掃除程度にしか思ってない人もいますが、コードが整理されるとバグ修正も機能追加も「ここのモジュールが本来ではこうするべきだったから」という形で責任が分割されるのでプログラミングの難度が大幅に下がるという効能があります。言い換えれば、将来のプログラミングの難度を下げる事ができるのが良い抽象化、そうでないならどんなプラクティスも自己満足です。究極的には例えば通販なら注文ロジックの最上位が「店舗.発注(注文票)」ぐらいになっていれば「これからはこういう条件の注文が来た時は却下したい」等と仕様追加があった時にどこに手を加えるべきか自明になって便利、ぐらいの簡単な話です。 ここにおいてすべての値を値オブジェクトにラッピングするのは例えるなら整頓用の箱を大量に用意する事で部屋が整頓できると信じるようなものであって有害ですらあります。 クリーンとかオニオンとかそれぞれの言葉でロジックを階層化することで複雑さを閉じ込めたと主張する人は多いです。中にはただ単に教典にある形に近くなった事を喜ぶ人もいるかも知れません。僕がプログラミング初心者に何度も強調して伝えているのは「再利用する予定のないロジックでも再利用性を重視したコードを書け」という指針です。レイヤーを分ける事自体は善にも悪にもなりますが、そのレイヤー分けの良し悪しを決めるのは「直交性」です。レイヤーごとに責務が明らかで凝集性が高いコードを…などと説明してもピンと来ない事が多いですが「仮にこの部分だけを別の目的で使いまわすならどんなインタフェースが露出していれば使いやすいか、を考える事が自ずと責務の分割と凝集性を高めてくれます（最後はセンスの問題になりますが…）。再利用性を優先することが直交性を高める為の近道である、というのはプログラミングを始めたばかりの自分にも繰り返し伝えたい直感に反する経験則です。 再利用性を優先した結果、リポジトリパターンと呼べる形にコードが落ち着く事自体はそんなにおかしな話ではありません。アプリロジックという究極的には再利用性皆無の極北からグラデーションのように段階を経てOSやDBのAPIという普遍性の塊までの間をどのように整理区分するかがプログラマに課せられた仕事であって、聖典を振り回すような場所ではないと僕は考えています。 アプリのコードの優れたアーキテクチャには究極的には未来予知が必要になります。例えば「将来的にここに仕様変更が来ると思うので拡張余地を残した」といったドメイン知識の注入が効くケースは大いにあります。ただしそれが当たったからといってそのプラクティスがどこでも通用する物であることは意味しません。重要なのは将来の変更に対して頑健であることで、将来の変更を助ける方法は小難しいテクニックを使う事とは限りません。特に最近始まったばかりのサービスというのはプロダクトマネージャにすらどこに何が起きるかわからないものですから、その内部は煮え滾る溶岩のように柔軟であるべきです。拡張性やエンバグのしにくさ(セキュアコーディングとか言いますよね)よりもコードの書き直しやすさと消しやすさに重点を置いています。拡張性ではない書き直しやすさというのは説明がしにくい指標ですが、およそ消しやすさとほぼ同義です。アプリ側の都合で数千行のコードがまるっと要らなくなることはザラに起きますが、本当にその数千行を消して良いかを判断するパッチを作るとしてその複雑さが低いほど消しやすいコードです。やたらとインタフェースを切って拡張余地を量産する場合、実際に不要だった拡張余地自体を消すのはどこから依存されているかわからなくて追加の数倍の神経を使うので、そうならないように自信を持って消し飛ばしていけるようなコードを心がけて書いています。ある程度サービスの概形が固まってきてから内部を冷え固まらせていく作業は新機能追加やデバッグのタイミングでコードの再利用と称してゴリッと書き換えて行けばよくて、人によってはこれをリファクタリングと呼ぶ人もいるでしょう。 長くなったのでまとめると * あらゆる教条主義は基本的に嫌いだけど最終的に似るのは別に良い * 凝集とか難しい言葉を使うより再利用性を意識する方が直交性に効く * 依存が少なくて消しやすいコードは正義、コードが若い時ほど消しやすさを優先 こんな感じになります。プログラマごとに違う考えがあると思うので他の意見も聞いてみたいですね。

熊崎 宏樹:C++を使うならポインタをいじる必要がある、というのは誤解です。C++はよく出来た言語なので実体と参照さえ混同しなければポインタに悩まされることはありません。競技プログラミングにおいても「ポインタなしでは解けない」という問題に出くわしたことはありません（そもそもほとんどの問題はC++以外の言語でも解けるように設計されているので当然といえば当然ですが）。 さて、ではなぜポインタが必要なのかというと「OSが要求してくるから」です。OSの提供するAPIは大抵の言語から触れますが最後はC言語で書いた抽象化層を経由することが多いです。OSがアプリと対話する手段は意外と限られていて、特にデータをやり取りしようと思うとreadとかwriteといった処理が典型的で、メモリ経由つまりポインタ操作で行うことになります。OSに近いレイヤーをオーバーヘッド無しで書ける事を指向しているC++を敢えて使うのであればポインタ操作に慣れ親んでこそ恩恵を受けられるし、OSに近づく気がなければいくらでもポインタの無い言語を使えばよいと思います。

熊崎 宏樹:出題側からはAIを使っているか頼れる友達と一緒に受けているかもわからない状況で出ている課題でしたら(明示されていない限り)検索でもAIでも友人でも使って提出しても構わないと思います。つまり「ただ解けるかどうか」を見ているわけではありません。 その手の課題は例外なく「この人物は一緒に働いていけそうか」を見極めるために出していますし、正解するかどうかよりも何を考えてその回答を提出したかが本題です。提出後にどう考えてこれを書いたかという面接があるはずですので、そこで「AIに書いてもらったので何もわかりません」と答えたら大きく失望させることになると思います。 自分の頭で問題を理解し、同僚の疑問にも適切に答え、長期安定や運用面での課題にも目配せをして、自信を持って正しい回答として提出するのであればそれが最終的にはAIで出力されたコードであっても出題者は気にしません。 さて、コーディング面接の勉強法という物は思い当たらないですが、Cracking Coding Interview(和訳:世界で闘うプログラミング力を鍛える本) https://www.amazon.co.jp/dp/4839960100は面接する側が何を見ているか舞台裏を書いているのでおすすめです。模擬面接を何度かやってみるのが肌感覚を得る近道ですので、面接官としてのトレーニングをした本職の人に模擬面接を依頼するのがおすすめです。そういうオンラインサービスも探すといくつか出てきます。

熊崎 宏樹:軽く検索するとS3のレイテンシは1桁ミリ秒、帯域はクライアント側のネットワークがボトルネックになるまで(つまり100Gbpsレベル)出るようですね。しかも99.999999999%(11ナイン)の耐久性という数字は生半可な努力で出せる数字ではありません。 なぜそんな高速なストレージがこんなに安いのかというのは一言では「経済の力」となりますがもう少し噛み砕くといくつかの要素があります。 S3はまき餌かも知れない クラウドビジネス各社ではオンプレミスやコロケーションで顧客自身が契約している物理ハードウェアからサービスそのままで自社のクラウド上に引っ越して貰うこと、通称リフトアンドシフトが基本戦略の一つです。その中でデータ置き場を顧客が自社管理しているNASなどからS3に引っ越してもらうのは重要なマイルストーンです。S3に置いて貰ってそこから煮るなり焼くなりしてもらうのはクラウドを使い込んでもらうために重要な起点となりますのでAWSはそのアップロードの敷居を下げるためにSnowballなどのサービスを整備しています。またS3にアップロードしたペタバイトクラスのデータを外に改めて持ち出すのはとても大変なので、AWSにロックインさせる事を目的としてS3は原価以下の価格で提供してもサービス全体では投資が回収できるという目論見でいわゆる逆ザヤをやっているのではないかという説もあります（実際の所どうなっているかは知りません）。とにかくそれぐらいやってもおかしくない戦場がクラウドのオブジェクトストレージです。 帯域は金で買える S3を運用する側が一体何台のコンピュータを使ってサービスを回しているかはまるでわかりません。ですがクラウド事業者の持つデータセンター内データ帯域は市販品とは別のライフサイクルで強化され続けており、EC2で借りれるマシンの中には100Gbpsのネットワーク帯域が出る物もあります。そしてハードディスクなどのストレージデバイスはクラウド事業者は途轍もない規模で買うのでいわゆる電気屋で一般人が買う価格と比べると圧倒的に安くなると言われています。ですので「とにかく大量のデータを保存したいから大量のマシンを調達して横に並べて負荷分散してするぞ！」と覚悟さえ決めればハードウェア的には25ドル/TB/月は実現可能な範囲にあると感じます。もちろんソフトウェアや運用のコストが掛かるのでゼロからクラウド事業を初めた人がお金だけでどうにか解決できるとは思いません。何にせよ、大量調達による仕入れ原価の削減は重要な要素です。そしてサービスのインタフェースとしてはオブジェクトストレージなのでサーバ台数を増加させることによる帯域幅の拡大は比較的自然に行うことができます、いわゆるシャーディングですね。HDDはヘッドシークに10ms程の時間が掛かってしまうのでそこが支配項にならざるを得ません、ですので可能な限り内部では並列化して帯域を稼いでいます。 レイテンシは知恵でしか買えない S3は公開情報によると複数のAZ（例えば同じ地域の別の建物など）に常に複製し終わってから初めてクライアントに完了と返事をする仕組みでその完了レイテンシは10ms前後に有るようです。S3 Express One Zoneというストレージクラスを明示的に選ぶことで一時的な耐久性を少し犠牲にしてレイテンシを1桁ミリ秒へと短縮することができると書いてあるので、その辺りがアルゴリズム的な上限に引っかかる境界なのだと見受けられます。つまり顧客から受け取ったデータを複数のAZに複製し終わるのを待つかどうかで数msの遅延が有るか無いかが変わってくるので最初に書き込み依頼を受けたサーバはローカルに書くかすぐ隣のマシンにも送るか等をして自身が即クラッシュしてもデータが永続化された状況を作り出す事で高い耐久性を実現していると考えられます。 データを複製すると言ってもナイーブな方法では故障に弱いのでちゃんとアルゴリズム的に強く検証したものを使用する必要があり、形式手法を用いて確認を行ったという話などは探すといくらか出てきます。アルゴリズムやサービスのバリエーションなどの側面でもレイテンシを縮める工夫を凝らしているようです。 僕は以下のブログを流し読みしかしていませんが、実態は絶え間ないエンジニアリングの努力の果てにできているサービスであることをしみじみと感じました。 https://highscalability.com/behind-aws-s3s-massive-scale/

熊崎 宏樹:例えば「じゃがいもと人参を受け取ってカレーを作って返す関数」というものを例にお話します。 その関数はコードで書くとこんな感じになりますよね。 typedef struct { ... // じゃがいも構造体の中身 } Potato; typedef struct { ... // 人参構造体の中身 } Carrot; Curry CookCurry(Potato p, Carrot c) {...} Cではこの関数は実は問題がある可能性があります、なぜならCでの関数は「値渡し」しかできないからです。つまりこの関数を呼び出すときには、内部的にはこの関数のためだけにPotato構造体とCarrot構造体を複製して渡す事になります。複製にかかるコストは構造体の大きさに比例しますから潜在的にものすごい量のコピーが起きる可能性があります。 ところでJavaではオブジェクトは関数に対して参照渡しされるので、構造体のコピーが起きる事はありません。関数に対して「人参は冷蔵庫の野菜室にあるもの、じゃがいもは足元の箱に入ってるものを使ってね」のように材料の実体ではなく、材料の場所の情報そのものを渡すので材料の複製を行う必要がなくなります。ただしこれは良い事ばかりではなく「シチューに使うつもりで冷蔵庫に入れておいた人参なのに無くなってる！」みたいな行き違いが起きる事もありえます。ですのでImmutableパターンという物で「見るだけにしか使わないなら参照経由、実際に書き換えを行うときには複製する」みたいに迂回することもあります。これが値渡しと参照渡しの違いです。 ところでCでは値渡ししかできないのですが「場所の情報」を表現する方法があって、それをポインタと言います。 Curry CookCurry(Potato* p, Carrot* c) {...} こんな感じで「じゃがいもの在り処と人参の在り処」を渡す関数として定義すれば、その在り処が書かれたメモ自体は値として複製され渡されますが、実体としては参照渡しと同じことが行われます。参照で渡すのですからそこでの注意点はJavaと同様です。

熊崎 宏樹:僕の意見は「役に立たないとは思うが、殊更に役に立たないと主張する人のほうが役に立たない」です。 競技プログラミングと業務の関係は例えるなら100メートル走とサッカーのようなもので、どちらかに優劣があるわけでもなく、どちらかのトップアスリートがもう片方でも必ずしもトップアスリートとは限りません。 サッカーの試合中に瞬発的に短距離走の速度が重要となるシーンもありますが、サッカーの試合結果は足の速さのみでは決まりません。業務でも時々競技的なコードを書く必要に迫られることもありますが、もちろんそれのみでは業務は終わりません。その割合に関しては現場に依存するので一概なことは言えません。 ここで重要なのは「100メートル走がちゃんとできる人間はサッカーも人並みにできる」という事です。100メートル走で一人の競技者としてやっていくには靴をちゃんと履いて左右の足を交互に動かして地面を蹴って狙った方向に前進する必要があります。サッカー選手でこれが必要でないと言う人は一人もいないはずです。競技プログラミングでトッププレーヤーになる必要はありませんが、人並みにやっていくために身につける基本動作は業務でも共通します。 言い換えると「競技プログラミングは業務で役に立たない」と得意げに言っている人で、競技プログラミングの基本動作ができていない人は、まるで自分の足で走れないのに「100メートル走はサッカーの役に立たない」と言っているようなもので両方やっている人からすると滑稽に見えます。 まずは靴紐を結んで自分の足で自在に移動できるようになる事が試合で役立つには必要で、競技プログラミングのために舗装された様々な学びの高速道路はそれを獲得するためにかなりコスパの良い道であると考えています。100メートル10秒を切るまでやり込まなくていいので怪我なくタイム計測ができる程度までやる価値は大いにあります。 競技プログラミングはコードを書く競技ではありますが、書いたコードがいきなり正解である事はほとんどなく、どこでバグが混入したかを素早く見つけて解決する必要があります。これはコード規模に違いこそあれ業務でも重要なスキルであり決してバカにできるものではありません。僕もレッドコーダーと一緒に仕事をしたこともあり、彼は途方もなく巨大かつデバッグ困難なコードベースを相手にしていましたが、その場でも筋道を立てて問題を解決に向かわせる力は確かなものだと感じました。

熊崎 宏樹:基礎を学びましょう。 CPUやOSの仕組み、そしてそれを利用して動くRDBMSはどういう原理なのかを学べば「なぜインデックスを張ると速くなるのか」などは自明に感じられるようになります。 何がわからないのかがわからない場合、経験上では対象物に対する脳内モデルが完成していません。脳内モデルというのは常に完璧でなくても構いません、これまでに学んだ知識と実際の挙動について自分なりに納得の行く説明をつけられるようにすることでモデルの精度を高めていく事ができます。そして眼の前のソフトウェアが自分のモデルから乖離した動きをするたびにそのモデルを修正する、そのサイクルをアマチュアもプロも回し続けています。 脳内モデルといっても大仰なものではなく、例えば自動車を運転していれば「ハンドルを回せば前輪の向きが変わる」とか「走るにはガソリンが必要」とか「アクセルを深く踏むと速くなる」ぐらいの挙動に対して説明がつく程度の解像度でなら誰しもが無意識に脳内に持ち合わせているはずです。自動車の中身を生業にする人でないなら深入りする必要はありませんが、自動車のエンジニアとして生きていくのであればそこから深入りしていく必要があります。 ここでまた僕の好きな本である「禅とオートバイ修理技術」から一節を引用します。 > そもそも彼らがオートバイに乗り始めた動機というのも、新鮮な空気と陽光に満ち溢れた田舎へ出かけてゆくことによって、テクノロジーから逃れることであった。ようやく逃げのびたと思っているそのときに、再びその場でテクノロジーを持ち出されることは、二人にとってひどく意気をくじかれることになるのだ。だからテクノロジーに関する話になると、いつも会話が途切れて、冷たい空気に包まれることになるのだ。（中略）明確には定義し難いが、テクノロジーを生み出すある種の力、いわば非人間的なもの、機械的なもの、生命を持たないもの、目に見えないモンスター、死の力、といったものがその正体であろう。彼らは決して逃れられないと知っていながら、何かそうしたぞっとするようなものから駆け足で逃げているのである。 テクノロジーとの向き合い方ひとつとっても、この二人（ジョンとシルヴィア）のようにテクノロジーの詳細からは逃げ続ける生き方もあります。しかし、ソフトウェアエンジニアとして生きていくのであればテクノロジーという非人間的で機械的な目に見えないモンスターと戦う覚悟を持ち合わせる必要があります。幸いなことにこのモンスターとの戦い方については定石があります。 「どうすれば自分がわからない部分を言語化して自分で解決して理解できるようになるか」という問いに対してですが、わからない部分を言語化する為のフォーマットを持ち合わせてないに過ぎないのではないかと思います。つまり物事がわからない時に「わからない」とだけ言うのではなく例えば「今の私の理解が正しければ○○になるはずなのに、実際のところは△△していて変だ。私の理解のどこからが間違っているのかがわからない」と言い換えるように努力してみてください。そうする事でその「理解」のどこから現実とのズレがあるかを探索するステップに進む事ができます。 ソフトウェア開発中に遭遇する謎挙動のほとんどは経験上使っているライブラリやフレームワークや言語に対する理解の欠如であることが多く、それらを深堀りしていくと遅かれ早かれOSなどの低レイヤーな問題にぶつかります。そこに対してもさらに深堀りを重ねていけるエンジニアこそが質問者様のいう「限界」がより高いエンジニアです。その低レイヤーを学ぶためにはつい最近発売されたBinary Hacks Rebootedが大変おすすめなので是非手にとってみてください。

熊崎 宏樹:ソフトウェアエンジニアの仕事について誤解があるようです。 確かに書けと言われた題材を動くまで持っていく力は大切ですが、それよりもっと大切なのは動いている物を思い通りにする力です。ソフトウェアエンジニアの仕事の9割以上は既に書かれているコードに対して何らかの変更を加える事であって、どこをどう書き換えるべきかという疑問に対して生成AIが具体的かつ正確な答えを返す事は稀です。 敢えて主語を大きくしますが、エンジニアの仕事というのはだいたい「既に何か動いている物があって、それが思い通りではないので何とかしたい」がスタート地点であり、生成AIが得意とする「自然言語で指示が与えられた物をゼロから作る」ではありません。 エンジニアとして働きたい者としては生成AIを敵視するのではなく、エンジニアの仕事の解像度を高め、生成AIが苦手とする分野を理解してうまく付き合っていきましょう。 「禅とオートバイ修理技術」という本から僕が特に気に入っている部分を引用します。 > (3)は、実験と呼ばれる科学的手順であり、ロマン的な人間は、時としてこれを科学そのものであると思い込んでしまう。というのは、科学的な方法のなかで、唯一視覚によって捉えられるものが実験だからである。彼らが見ているものは、数多くの試験管や、妙な形をした器具や、数々の発見を成し遂げるために忙しく動きまわっている人々だけで、その実験を雄大な知的プロセスの一環としては見ていない。だから実験と証明を混同して、それらが同じものだと思ってしまうのだ。五万ドル相当に及ぶフランケンシュタインの実験器具を陳列して、世間をあっと言わせるような科学ショーをやってのけるような人物は、たとえその結果がいかなるものになろうとも、決して科学的な実験行為を行っているとは言えない。だが一方、バッテリーの具合を調べるために、ホーンを鳴らして確かめようとするオートバイの修理工は、正式とは言えないが、実際科学的な実験を行っていると言える。すなわち生じた問題点をもとに、一つの仮説をテストしているのである。「実験は失敗に終わった。期待通りにはいかなかった」というせりふは、テレビドラマに登場する科学者がよく口にする不幸なせりふだが、実はこの不幸の原因は、お粗末な台本作家にあるのだ。予想した結果が得られなかっただけでは、決して実験が失敗したことにはならない。実験が失敗に終わったと言えるのは、さらに、問題となっている仮説が十分にテストされなかったり、また実験によって得られたデータが何ひとつ立証に値しない場合に限られる。 生成AIによってたちどころに何らかの生成物が得られても、それは科学ショーに過ぎません。科学を構成する仮説の立案と検証を繰り返す雄大な知的プロセスの中においては生成AIがサポートできるのは一部に過ぎません。特にプログラミングに限って言うとブライアン・カーニハンによるこんな名言もあります。 > “The most effective debugging tool is still careful thought, coupled with > judiciously placed print statements.” — Brian Kernighan, “Unix for Beginners” > (1979) > > 最も優れたデバッグツールとは依然として注意深い思考と組み合わせて慎重に配置されたprint文である。 ブライアン・カーニハン, "初心者のためのUnix" > (1979) この本は古いですが依然としてソフトウェアエンジニアリングにおける重要なポイントを示唆しています。眼の前のプログラムが自分の思った通りに動いてくれない事はプログラマにとっての日常です、そこで何故思った通りに動いてくれないのかを具体的に立証する方法を立案する過程を生成AIは教えてくれません（デバッグに関する一般的な事は教えてくれますが）。たくさん学習させたら帰納的にできるようになるかも知れませんが、それを学習させようにも製品コード自体がそもそも膨大ですし、仮説と被疑箇所に基づいたprint文なんて製品コードには残っていないので学習する為のデータセットを集めるだけでも一苦労です。よって「眼の前のプログラムを望む仕様通りにしてくれる」という生成AIが登場するのはずっと先ですし、仮に仕様通りに動いてもそれを確認するテストやQAの仕事が生成AIに取って代わられるのは更に先の話です。 まとめると、僕の意見は「科学的手法(仮説立案・実験・考察)を身につければ少なくともしばらくは生成AIにとって代わられない仕事ができる」です。

熊崎 宏樹:そもそもインターンが目標というのが少し立ち止まって考えて欲しい所です。ここで僕の好きな記事を一つ紹介します。Joel on Softwareという有名なブログの「Finding Great Developers」です。英文に抵抗があるならページごと機械翻訳に投げ込んでも構いませんが、僕の文脈でピックアップして伝えたい部分だけ掻い摘んで伝えます、僕によるバイアスを含むので興味を持ったら是非原文も読んでください。面白くておすすめです。 * 世の中には「優秀」「無能」の2種類の人材がいて転職市場に出回っている人材のほとんどは後者 * 何故なら前者は重用されて出回らないからその人の生涯で4度程度しか転職市場に現れない * 転職市場は期待できない人間ばかりだが、優秀な人材は学生の中には社会と同程度には居るはずなので学生の中で探すほうが優秀な人材と巡り会える期待値が高い。それを市場に出てくる前に捕まえるのがインターン * ソフトウェアの世界での優秀さはその気になれば学生のうちの数年でも育つが、全く育てていない人が多すぎるので仕事の中での成長よりも才能で採る方が良い * つまり青田買いと相性が良い * インターンの中で真剣な仕事を与えて働きぶりをみれば面接よりも高い解像度で採るべき人材かどうか見極められる * 優秀であると確信した後でなら新卒より高い待遇でオファーをしても割にあう * なぜならそもそも新卒の普通の給料は人材が無能だった場合の保険を乗せて額面が削られているから これは米国の話ですが大筋では日本の労働市場でも通用します。インターンとは慈善事業でも子供向け人気集めイベントでもなく、企業がより優秀な人材を高い打率で掘り当てるための真面目な採用サイクルの一部です。「経験者を求めているインターン」というのは錯覚で、学生の中で有望そうな人をスクリーニングした結果、複数社の結論がたまたま一致したに過ぎないのではないかと思います。 さて「インターン獲得」という観点の話ですが、新卒市場に出回るような学生の履歴書は基本的には学歴+α程度しか載っていないものですから、それを見た時に人事部の社員が「この学生は高い解像度で比較してみても良いかも知れない」と思えるような学生という観点で考えるとそんなに難しい話ではありません。 * 関連の深い学科で高いGPAを獲得する * 努力で超えられない才能を持っている事をアピールする * 独学で調べて何かを作って発表していると良い、自主的に何かクールなことをやっている人間はコンピュータの才能があるかも知れない * 「やる気だけは誰にも負けません」という口先だけなら誰でも言えるのでやる気を客観的に証明できる経歴を残す * そう言えば昔こんな記事を書きました https://qiita.com/kumagi/items/62ec259ea86bdac1db4c * ただしこの指標はハックしようとするほどボロが出た時に痛いのでやる気が無いなら無理にやらないこと。ボロが出た話を風のうわさに聞いて書いたのがこの記事です。 https://kumagi.hatenablog.com/entry/career-hack * ブログやSNSや学会でポジティブな方向に目立つ * その会社が使用している技術の名前で検索した時に上位に出てくると理想的 * 採用担当だって候補者のフルネームやアカウント名で検索ぐらいします 注意点として、入賞歴やその他の華々しい活動は基本的にポジティブに受け取られますが「インターン経験」は学生の直感に反して警戒されます。3日程度の職業体験的なインターンならともかく、まともなインターンシップであれば優秀であると判明した学生はその会社の採用パイプラインに乗せて外に出なくなるようガッチリとホールドされて表に出てこなくなるはずです。それなのに表に出てきていて長期インターンの経歴が複数並んでいる履歴書は、それらの会社の採用パイプラインに乗り損ねた可能性があります。学生観点で見ると有名企業でのインターン歴が並んでいると勲章やトロフィーが並んだ履歴書のように見えるかも知れませんが、採用担当の観点で見ると多ければ多いほど良いと一概に言えるものではありません。ですので僕からできる確実なアドバイスは「学業を頑張りながら目立て」です。 日本の労働市場における「新卒カード」は充分強くてインターンに行かなかった位で絶望するような物ではないので、いっそ夏季休暇を全部趣味の開発に叩き込む方がキャリアに有利に働くかも知れません。 読み返すとありきたりな事しか言って無くてあまり役に立った気がしないので、有志が随時アップデートし続けている「インターン情報が集まる魔法のスプレッドシート」を共有します。既にご存知かも知れませんが。 https://magic-spreadsheets.github.io/

熊崎 宏樹:キャリアのために今から学位を獲得すべきか？という質問ですね。短い答えは「ノー」です。なぜならビッグテックは学位を採用条件にしていません。実際の求人をいくつか見てみましょう。ソフトウェアエンジニアリングの求人を適当にピックアップしたのであなたがこの文章を読む頃にも同一の求人がアクティブかはわかりませんが、傾向は変わらないはずです。 ビッグテックの求人例 まずはGoogleはこうなっています。 > 学士号を取得していること（同等の実務経験でも可） 次にAppleは学歴に関する言及すら無くMinimum Qualificationsには > * 2+ years of experience in web application development with an in-depth > understanding of data structures and algorithms. とあります。つまり実務経験ということで他の項目は言語やフレームワークの経験ですね。 次にFacebookことMetaは > * Bachelor's degree in Computer Science, Computer Engineering, relevant > technical field, or equivalent practical experience コンピュータ・サイエンスやコンピュータ・エンジニアリングやそれに関連する技術領域の学士、もしくは同等の実務経験と書いています。実務経験が説明できれば学歴での足切りはありえません。 そしてAmazonはPreferred Qualification (=あると望ましい資格)の所に > * Bachelor's degree in computer science or equivalent とあります。コンピュータ・サイエンスの学士号もしくは同等の学位、と言っているようですがあくまでPreferredなので足切りではなく加点ポイントですね。 Netflixの求人も見てみましたがrequirementに関する言及すらありません。 Microsoftのソフトウェアエンジニアリングは > * Bachelor's Degree in Computer Science or related technical field AND 2+ > years technical engineering experience with coding in languages including, > but not limited to, C, C++, C#, Java, JavaScript, or Python > > * OR equivalent experience. とあって、同等の経験(equivalent experience)があれば学位は無くても良いと明記しています。 書類選考について 実例を並べても「暗黙の条件が別にあるんじゃないの？」と疑うのもわかりますが、僕の知る限り求人票におけるこういった条件は本当に文字通りの解釈をするために用意されています。「ソフトウェア開発の2年の経験」と書いてあれば2年間ソフトウェア開発部署でただ椅子に座っていただけでも一応満たしますし、逆にNext.jsやDockerやクラウド技術をバキバキに使い倒したアプリとかOSとかコンパイラとかDBを1人で作りましたとポートフォリオに並べても実務経験を書いていなければ「実務経験1年同等」とすら解釈されず落とされます。 テック各社、書類選考のレイヤーでは候補者が多すぎるので機械的に該当しない人をminimum requirementsに照らしてその後の選考に進む人を選びます、ここに関しては落ちたらそういうフィードバックが貰えることもあるのでリクルーターに聞いてみると良いです。満たしているのに書類で落ちた場合は運です、学位を持っていても運悪く書類落ちすることはザラです。書類選考に対しては学位よりもリファーラルを受ける方が有効に働くと思います。 そして二次選考は主に（特にソフトウェアエンジニア職は）面接を通して行うのでそこで高評価が出せるかがとても大事です。最終決定の際に複数の候補者の間で決め兼ねた時に何を手がかりに決定するかは会社によっても違うので学歴も見るかも知れませんが、大抵は別のシグナルを用いて決めるはずです。ですのでビッグテックにおいては学歴にこだわるよりは同等の実務経験を積むほうが就職に対して合理的であると思います、学費も掛からないし給料も貰えます。 また、年齢についても各社の求人ページをよく読んでみると気にする必要がないことがわかります。例えば上のGoogleのページだと > また、人種、信条、肌の色、宗教、性別、性的指向、性同一性またはその表現、国籍、障がい、年齢、遺伝情報、従軍経験、配偶者の有無、妊娠またはそれに関連する状態（授乳を含む）、親になる予定、犯罪歴（法的要件に一致する場合）、法律によって保護されるその他の状態にかかわらず、均等な雇用機会を提供すべく尽力しています。 Metaだと > We do not discriminate based upon race, religion, color, national origin, sex > (including pregnancy, childbirth, reproductive health decisions, or related > medical conditions), sexual orientation, gender identity, gender expression, > age, status as a protected veteran, status as an individual with a disability, > genetic information, political views or activity, or other applicable legally > protected characteristics. ほぼ同じような事を書いています。わざわざ書きませんがAmazonもAppleもNetflixもMicrosoftも同様の文言が書いてあります。 なぜこれらを明記しているかと言うと、もし仮に年齢による足切りが暗黙にでも行われていた場合、それはアメリカでは人種差別や性差別と同様に違法だからです、場合によっては性別や年齢入りの履歴書を提出した際にリクルーターから消すよう依頼される事すらあります。ですので「進学したら年齢が高くなり過ぎてしまうのではないか」という懸念も不要なものです。むしろOver Qualified（過剰資格）の方が先に問題になるかも知れません。 ただし、研究職に就くのが目的である場合は論文投稿・発表実績などが加味されるため大学の研究室に所属するのが正攻法になる事もあるかと思います。 コーディング力と面接対策 AtCoder黄というのでアルゴリズム力に関しては特に不安は無いですが、コーディング面接で問われる能力はアルゴリズム力だけではありません。面接は面接でコツが要るので米国では定番の「Cracking the Coding Interview」（邦訳: 世界で闘うプログラミング力を鍛える本 ）を読んでおく事をおすすめします。オンラインで有料で面接練習ができるサービスも幾つもありますし、知り合いの経験者と模擬面接をして練習するのもおすすめです、僕に直接コンタクトをとっても歓迎です。知り合いが運営している「Engineer Guild」も何かの力になれるかと思いますし無料です。暖色コーダーでも落ちる一方で灰色コーダーでもコツさえ掴めば通るのが面接ですので入念に準備することをおすすめします。 どの会社も「仕事ができる人を採りたいが直接それを測れないので面接でアルゴリズム問題を出して近似している」が実態であって、面接では仕事ができる人であることを示す事が大事です。例えば難問に直面した時の理想的な仕草は「ダメ元でセグメント木を取り出して振り回す事(AtCoderでは意外と有効)」ではなくて「何が問題の核心でどんな道具があったら解決できるか自分の考えを整理して説明する事」だったりします。その差を理解するために場数を踏む以上の方法を僕は知りません。 進学の是非 もちろんコンピュータ・サイエンスの基礎から体系立てて学ぶ事自体は有益ですので熱意が持つのならぜひ進学すると良いと思います。ただし入社に向けての準備ではなく、入社後のキャリア形成の一環として会社から補助を受けながら進学するのがおすすめです。多くのビッグテックがそのような社員特典を用意しています。 https://www.levels.fyi/benefits/Tuition-Reimbursement/ もちろん働きながらの学業は忙しくなりますがそれだけの価値はあります。

熊崎 宏樹:アメリカの大学でCS。すごいですね、アメリカでもCSの人気は高まってて競争が激しいと聞いています。 数学を勉強していなくてセンスに自信が無いとの事ですが、大丈夫です。僕も数学は実はからっきしで、高校で3Cまで習いはしたのですが合成関数の積分あたりからテストでまともな点が取れなくなりました。大学の微積やら線形代数の授業なんかも参考書の付け焼き刃で乗り切ったに過ぎず、どこまで身についているか怪しいものです。 GAFAMで活躍している人にセンスがある、というのは正しいかも知れませんが、働いている全員にセンスがあるとは限りません。少なくとも僕自身は日々コードを書きながらセンスの無さに打ちひしがれているからです。何かすごいフレームワークとライブラリで動いているのはわかるけれどそのフレームワークの気持ちがまるでわからない、Dependency Injectionされた値がどこで取りこぼされているのか、出力したはずのエラーログが出てこない理由は何か、さっきと同じ手順で投げた同一のクエリの結果がまるで異なるのは何故か、connection refusedというログの裏の理由とは？コンフィグ内の識別子と自動生成された変数とフレームワークの引数が複雑なビルドの向こうで空中合体していることはわかるがそこで起きたコンパイルエラーは何が不満なのか、わからないことだらけの脱出ゲーム状態で試行錯誤しながら日々過ごしています。これは合成関数の積分ができれば理解できるタイプの問題ではなく、フレームワークの仕様や挙動を忍耐強く学んで活用していく事が王道です。これに対して才能がある人というのはおそらくゲームが得意な人なんだろうと思います。僕自身もゲームは人並みに得意なつもりでしたが脳の情報処理能力の限界を日々まざまざと見せつけられるような気持ちです。そうして毎日仕事終わりには「向いてないな…」とか嘆きながら席を立ちます。 さて、才能が無いなら諦めるか、という話に戻すと「才能を理由に諦めるなんてとんでもない」が僕の答えです。僕が持っていると堂々と言えるような才能は「毎日12時間はディスプレイに齧りついていられる視力含む身体的強度」ぐらいのもので、センスとか頭の良さといった観点では常時ついていけなくて悶絶しております。アメリカの大学でCSを学ぶ程に根性があるのであればその時点で僕の学生時代より遥かにアドバンテージを取れています。 微分積分の授業は参考書に齧りついていれば誰でも点が取れるようになりますが、人が後天的に「自分が書いたコードが動いた時に快感を得る」ように鍛錬することはまず無理であり、立派な才能です。「好きな事を仕事にできたら良さそうだし深堀りしてみよう」ぐらいのモチベーションでしばらく没頭し、目安的には10000時間ぐらい使ったあとで改めて考え直しても充分な程にまだまだあなたの人生には時間があります。あなたが就活する頃にはひょっとしたらもうGAFAMではなくもっと魅力的な会社が台頭しているかも知れませんし時代の流れに上手く乗れたらもっと素敵な仕事ができると思います。学んだCSの知識があと50年は無駄になることは無いでしょう。 就活は一期一会ですし現在の情勢でGAFAMに入るには単純な能力ではなくてタイミング良く狙ったポストに空きがあるかのほうが遥かに重大です。僕が入社できたのもひとえにタイミングのお陰でした。時流の流れに積極的に目を向けていきましょう。

熊崎 宏樹:RDBMSが流行った理由はトランザクションのお陰ではありません。何故ならリレーショナルモデル登場前からトランザクションをサポートしたデータベースは複数あったからです。 リレーショナルモデルの提唱者であるEdgar F. Codd氏がその当時勤務していたIBMが売っていた製品がInformation Management System(以下IMS)というデータベースで、階層型データモデルというデータ型でデータを表現していました。これは例えるならファイルシステムのディレクトリ構造とファイルのようなもので、同一の物を複数の階層から参照することすらままなりませんでした(その欠点を改善したネットワーク型モデルというのもあります)。また、データにアクセスする際にはそのデータのフルパスに相当する情報をプログラマが管理した上でアクセス手順をプログラムする必要がありました、そうやってアクセス手順を案内する必要があるという点でナビゲーショナルデータベースシステムという呼び方をされることもあります。 データベースのリカバリ戦略を特徴付ける4つの観点「複数ページの更新を一括で行えるか(≒シャドーページング等の有無)」「トランザクション実行途中のDirtyなページのディスク書き戻しを許すか」「コミット時に全ページの書き込みを強いるか」「チェックポイント戦略」において分類木を作ると左端に『ページはその場で更新・Stealあり・Forceする・コミット時に全部ディスクに強制的に書き出すから明示的なチェックポイントは要らないよね(=Transaction Oriented Chcekcpoint)戦略』IMSが分類されています。またIMS Fast Path (FP)は「ページはその場で更新・Stealなし・Forceしない・チェックポイントを取ると決めたら新規トランザクションを全部止めて今居るトランザクション全部終わるのを待って全ページFlushしたら良いよね(Transaction Consistent Checkpoint)戦略」で現在で言うIn-Memoryデータベースの源流と呼べる場所にいます。 右から3つ目の『複数ページ一括更新する・Stealあり・Forceなし・書き込みが無いタイミングで全ページFlushしたらリカバリが速い(Action Consistent Checkpoint)戦略』のところにSystem Rが居て、これはシャドーページングを使っている事でも有名なRDBMSです。 RDBMSのリレーショナルデータモデルがCodd氏から提唱されたのが1969年(論文が外に出たのは1970年)とされている中で1960年代からIMSを始めとして多くのシステムがトランザクションの永続化と一貫性について試行と改善を繰り返して来ていました。RDBMSのトランザクションの仕組みは既存の研究の一種に組み入れて論じることができる程度には一般的なものとなっていたと言えます。 さて「なぜRDBMSが主流になったか」という当初の疑問に対してよく言われているのは「OptimizerとIndexの進化」です。最初期の頃のRDBMSは研究もそこまで進んでおらず、速度面で大きなビハインドがあったためナビゲーショナルデータベースシステムの地位を脅かす物だとは思われて居なかったのですが、関係代数を基盤にした様々な最適化やインデックスによるアクセス高速化によって、手作業で職人芸めいたアクセス高速化をしなくてはならなかったナビゲーショナルデータベースシステムよりも市場に受け入れられ、最終的にナビゲーショナルデータベースシステムの最大手だったIBMがRDBMSに本腰を入れ始めたあたりから市場の大勢が固まったと認識しています。開発にかかる経済コストはこの話題における重要な要素です。 リレーション(いわゆるテーブル)の形でデータを保持すると直感的だから受け入れられたというのもそれなりに説得力があると思いますが、それでも外部キーによってテーブル間の連結関係を表現する際に整数を用いているのは印象的です。「データ独立を実現したことにより変更容易性が高くなり生産性が上がった」という点で思い出したのですが、誰かが「キーが整数ならバイナリの塊からでも人力でデータが復旧できる」という仮説を提唱しているのを聞いたことがあります。外部キーとは他のテーブルの特定の行に対する参照なのだから原理的にはポインタとかオフセット値とかもっと物理的な情報をkeyとしたほうが間接参照の回数が減るので高速化するのは確実なのですが、それをやってしまうと物理的な故障が起きた際にデータをダンプして目視で復旧する際の難度が跳ね上がってしまうので敢えて整数値による間接参照によってそのレイヤーでの柔軟性を保持することでシステム更新時のコストを抑えているという仮説です。歴史に埋もれているだけで実はハードディスクの更新などを契機に壊れてしまい復旧に多大なコストを払うことになったシステムもあったのではないかと想像しています。

熊崎 宏樹:ペアプロ・モブプロは楽しいですね。特に慣れないコードベースや言語やエディタでの習慣や作法についてコードそのものからはわからない情報が得られる点に最大の利得があると感じています。 しかしコードを属人化させないという観点ではレビューを徹底する事でも解消できますし、設計の議論を深めたいのであれば共有でオンラインなドキュメント上でコメントを応酬しながらやりあったほうが最後に記録が残り第三者が見返す事もできます、更には物理的に近い場所にいる必要もなくタイムゾーンが合わない人とすら時間的な拘束なく協力ができるので結構な利点があります。 逆に言うとペア・モブプロは記録が残らない上に時間的な拘束が発生するので最強とまでは言えないのではないかと思います。プログラマ同士で実力差がある場合のキャッチアップには便利ですが、全員それなりにシニアならそれぞれ別のコードとドキュメントを書いて他人がレビューする体制を回す方が全体としてのスループットは高いと感じます。

熊崎 宏樹:普通のプログラマとしての素直な感覚ではむしろその「奔放な変数宣言」の方が良いです。 コードを読む時は未知の識別子が出てくるたびに認知負荷が高まっていく訳ですからグローバル変数を始めとして内部から参照できる変数は少ないに越したことはありません。関数が1画面に収まるサイズならスコープの開始位置という決まった場所にあれば変数の宣言もすぐに確認できるというのは一理ありますがシリアスなコードを書いていれば1画面に収まらない関数というのはザラに出てきます。 特にC++のようにオブジェクトの生成自体に意味を持たせる事がある言語（例えばscoped_lockなど）においては宣言と生成を分ける方がアンチパターンでありRAII(Resource Acquisition Is Initialization)という言葉にも現れています。C99を策定する頃はJavaなども台頭してきておりそれらの良い所を適宜取り入れていくノリでスコープの先頭以外での宣言も許されたのだと思います。forループのカウンタのiなんかはループの外で触ってしまったら事故の元ですし、ループ外で触ったらコンパイルエラーで教えて欲しいです。スコープを細かく区切れるようにしてそこでの変数宣言は上に寄せたほうが良いというのは確かにそうだと思いますが、宣言が初期化を兼ねている方が読みやすいコードである以上は宣言位置をブロックの先頭に限定しないほうが柔軟な活用ができます。 そもそもがC89においてスコープの先頭でしか変数を宣言できなくしていたのは、その関数が使用するスタックのフレームサイズを早期に確定したいとかコンパイル中の識別子テーブルの実装を簡単にしたいといった実装依存の理由が強く、書かれるコードの品質の側面では特にメリットはありませんでした。 一方で「奔放な変数宣言」を許すと画面内のコードの塊の中で依存関係が完結しているケースにおいて読みやすくなりますしコピペしたらそのまま動くことも多いです。コードのコピペと言うと急に素人のやっつけ仕事っぽい印象がありますが、プロだって必要に応じてどんどんコピペを活用します。コード片のモジュール性が高い事の恩恵というのは日頃からデカいコードの上で仕事をしている人のほうが有り難みを感じるのではないかと思います。

熊崎 宏樹:和訳されているC++本はだいたいどれも大きなハズレではないのですが、僕がC++を学んだ時は定評のあるEffective C++から入りました。基本的な言語機能は適宜検索すればわかるので、どういうコードを書くべきでないかという観点から入れたのは自信を持ってコードを読み書きするには良いスタート地点でした。 https://www.amazon.co.jp/dp/4621066099 Effective C++の中には今（C++11以降）となっては必ずしも通用しないベストプラクティス（使える場所ではconstにしよう、など）もあるのですが、なぜ過去は推奨されておりなぜ現在は推奨されていないかを把握したほうがより良いコードが書けるので古典から入るのはおすすめです。特にJVMもV8もBlinkもC++11以前から続いているプロジェクトなので古いベストプラクティスを学ぶ事はそれらの理解の助けになります。 この原著者のスコット メイヤーズ氏の著作はどれもとても良くて、C++11/14以降でアップデートされた本（Effective Modern C++）も書いています。こちらもとても評判が良いようです。 https://www.amazon.co.jp/dp/4873117364/ Exceptional C++はC++で例外を使うのがいかに難しいかを本一冊かけて滔々と説いています。C++は言語レベルでガベージコレクションを持たない言語ですが、そこの上では例外を使うといかに発見が困難なバグを埋め込むかという事をこれでもかというほど書いています。人によってはこれを絶対読むべき本として挙げる人もいます。 https://www.amazon.co.jp/dp/4894712709 C++テンプレートテクニックは上記の本ではあまり解説されていないテンプレートの技法をたくさん説明していて良かったです。SFINAEとかType ErasureとかCRTPあたりのテクニックはそれなりに大規模なC++プロジェクトでは常識のように使われているので、自分でゼロから書けなくても「なんか上手いこと行ってこうなるらしい」という事だけわかっていれば読む際にはどうにかなります。 https://www.amazon.co.jp/dp/4797376686 本に限らずともC++を学ぶために有益なリソースはオンラインに無料で転がっていてGoogle C++ Style GuideはGoogle社内でC++を書く際の決まりごとです。ただのルールが列挙されているだけではなく、何のためにこうするのかという目的も逐一簡潔に書いてあるので勉強になります。またV8はGoogle C++ Style Guideに準拠して書かれているはずなので学んでおくと理解の助けになります。有志による日本語訳もありました。オンラインで全部読めます。 https://ttsuki.github.io/styleguide/cppguide.ja.html 最近僕が読んでいる物でいうとC++ソフトウェア設計という本がかなり良いです。デザインパターンというものがいかに誤解されているか、そしてC++20時代に於いてなお重要なパターンとその効用に絞って説明している稀有な本です。特に良いのが、パターンや言語仕様の説明のようなテクニカルな要素ではなく、大規模コードとその拡張可能な設計に焦点を当てる事を意識した本であるという点であり、これは血の通った知見であると感じています。SOLID原則について良くある誤解を例を挙げながら解説し、一つのデザインパターンでも実装上の選択肢があり、逆にほぼ同じコード構造でもプログラマの意図によって別のデザインパターンたりうる事を説明しています。駆け出しのプログラマがデザインパターンを使いこなすのは至難の技ですが、質問者様が挙げられているプロジェクトはそれらを使っているので読む際に何を意図したコードなのかを把握する手助けになります。 https://www.oreilly.co.jp/books/9784814400454/ C++にはRAIIとかRTTIとか略語が大量にあって僕も未だに知らないものがいっぱいあってこれを眺めているだけで面白いなぁと感じています。 https://quuxplusone.github.io/blog/2019/08/02/the-tough-guide-to-cpp-acronyms/

熊崎 宏樹:まずログ構造化ストレージというのはアルゴリズムの一種であって特定のハードウェアやデバイスの事を指しません。また、ログ構造化というテクニックに関して言うとSSDの内部でフラッシュメモリのコントローラが利用するケースやブロックデバイスが使うケース（e.g. Log-Structured Block Device）やファイルシステムが使うケース（e.g. RFS）やデータベースライブラリが使うケース（e.g. LevelDB）など様々あります。 永続性と応答速度を両立しようと思った時に一旦書ける場所（ログ）に書いてしまって完了を報告し、後で正しい場所に書き直そうという戦略はジャーナリングなどとも呼ばれ、様々なレイヤーで古くから活用されてきました。しかしそれだと最低でもWrite Amplifier（論理書き込み1回に対して物理書き込みが何回起きるかという倍率）が常に2を超えてしまってスループットが犠牲になります。なのであわよくばログに書いたまま書き移す事なくメタデータを工夫して参照の際にうまく取り回す事（構造化）でどうにか性能のバランスを取ろうというのがログ構造化ストレージの基本思想です。 しかし前述したようにあらゆるレイヤーで似たような事を多重に行うのはあからさまに無駄が多いのでそれを解決するためにはアプリケーションからデバイスまでで一貫した戦略をとったら良いんじゃないか等と研究（e.g. Don’t stack your Log on my Log）されており目が離せない分野です。例えば必ずSSD上でしか動かさない前提のシステムであればファイルシステムやアプリのレイヤーで書き込みをシーケンシャルにするよう拘る意義が薄れますし、DBアプリから見たストレージシステムの方で書いたデータがフラッシュメモリに書かれるまでを垂直統合して最適化したら良いんじゃないかなんて過激な研究もあります。 https://dl.acm.org/doi/10.1145/3514221.3526188 さてストレージのヘッドの話に興味があるようなのでHDDの話をしたいのだと思います。複数のプラッタを持つHDDはプラッタの枚数に比例して読み書きヘッドが増えるので「読み書きヘッドが複数ある」とは言えますがそれらは独立して動くことはないのでスループットには関係ありません。 HDD上のLSM-Treeの上で読み込みが発生して問題ないかというと、もちろん悪影響があります。ちなみに書き込み命令と読み出し命令が複数個キューに積まれた時、それをどの順序で最終的に実行するかは下のレイヤーでうまくディスクヘッドのシーク量が少なくなるよう並べ替えて実行されます。なので最終的に読み書きがどういう順序で実行されるかに付いてはアプリのレイヤーからは制御しきれません。 https://en.wikipedia.org/wiki/Native_Command_Queuing シーケンシャルな領域への書き込み命令自体が連続している場合はヘッドの移動は最小になるためもちろん最良の性能が出ますし、readが入るとヘッドシークに約10msかかるので書き込みのスループットにも悪影響は出ます。と言ってもLSM-Treeの書き込みのスループットは最良ケースであってもマージ操作の際にガタ落ちするのでReadによる外乱はそこまで致命的ではないと思っています。SSD等であればなおさら影響は減ります。 LSM-TreeのReadに関してはメモリを使ってキャッシュするのが基本戦略です。メモリ内の問い合わせによってヘッドシークの回数を減らせば減らすほど良いのでBloom Filterを用いて不在判定を高速に行うのが定番です。LSM-Treeの各レベルごとにBloom Filterを取り付けておき、不在判定に失敗した場合はそのレベル内のペイロードの実スキャンを行うのですが低レベルでの不在判定ミスは高レベルでの不在判定ミスよりペナルティが大きいので低レベルのBloom Filterサイズに傾斜をつけて大きめの容量を振っておけば全体としてスループットが上がるというMonkeyなんかは面白かったです。 http://daslab.seas.harvard.edu/monkey/ 他にも、キャッシュする際にはkeyに対するvalueのポイントクエリの結果をLRUキャッシュなどに入れておいてもレンジスキャンの際にそのキャッシュ内容をうまく活かせれないのでレンジスキャン用キャッシュとポイントクエリ用キャッシュを適応的にバランスさせながらキャッシュメモリの有効活用を試みるAC-Keyなんて研究もあります。 https://www.usenix.org/conference/atc20/presentation/wu-fenggang 何にせよメモリを使えば使うほどRead性能が上がるという点で難しいトレードオフがあります。LSM-Treeに興味があるのであれば僕のブログ記事もあなたの知的好奇心をくすぐるかも知れません。 https://kumagi.hatenablog.com/entry/end-of-freezing-lsm-tree 以上参考になりましたら幸いです。

熊崎 宏樹:できます。 むしろ「データ指向アプリケーションデザイン」ではそういった方向性を推奨しています。Redoログだけ何らかの手段で強固に永続化されていれば、そのログの永続完了を分水嶺にして個別のトランザクションのロールバック・ロールフォワードを決定できるようになり、分散DB全体の原子性を実現する事ができます。 MicrosoftのSocratesはこの方向で詳しく書いているので参考になると思います。 https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf システム図を引用すると以下です。 このXLOG SERVICEと書いてあるブロックの部分でログを永続化し、ページサーバーで必要なログを分配してページ情報をXStoreに置いています。このXLOG ServiceのLanding Zoneは3多重で複製を作り続けるAzure Premium Storage serviceを利用していると論文中で明記しています。Raftが実現するReplicated State Machineはまさにこの点でぴったりマッチします。このようにRaftで複製して永続性を保証したログはリカバリに利用できます。 ただし、リカバリという観点では正しくACIDを実現したページがアプリケーションから見える事が大切であり、そのためにはログのRedoやUndoを適切に実装する必要があります。これはRaftで自明に解決できる話ではありません、部品として使うことはできても完全な答えにはなりません。 少し衒学的になりますと、多くの人はWALという言葉を使っていますがWrite-Ahead-Logが「何が何に対してAheadしているのか」という事を説明できる人は意外と少ないという肌感覚があります。正解は「ログの永続化がページの永続化よりも必ず先行する」という意味であり、ログの永続化完了までページのpinを*必ず*維持するといったせせこましい一貫性保証の細かい実現手段を表現しているのですがただのバイナリログの事をWALと呼ぶ人が多い気がしています。このSocratesの論文ではWALという単語は使われていませんし、上のFigure 2から見てもわかるようにPrimary側のページは永続ストレージに向かって直接保存される事はありません。つまり「ページの永続化」という操作自体は存在しなくて、単に永続化されたログから一方通行でページのイメージを練り上げるという操作を行っているので先行するも何もなく、この手のアーキテクチャの分散DBにおいてはWALという言葉を使わないのが適切です。これはAuroraに関しても同じことが言えます。

熊崎 宏樹:僕の専門領域ではないですがプロの方の回答が出るまでの間、門前の小僧が習わぬ経を読んでみます。 トランジスタを小さくする事はそれ自体が目的ではなく、安く高性能なトランジスタを追い求める過程でとる手段の一つに過ぎません。微細化競争ばかりが槍玉に挙げられますがそれでなくても半導体開発は（光学に限らず）現代の科学の結晶の一つです。 まず大前提として仮に原子一個レベルにまでプロセスが微細化しても一つのチップの上に何億規模でトランジスタを載せる以上はその故障率や歩留まりに関してはトランジスタ一つあたり99.999999%の良品率でも足りません。微細化が終わっても歩留まりとの戦いはほぼ終わらないことでしょう。半導体の製造過程自体を改善して良品率を上げることもあるでしょうし、一部に不良なトラジスタが入っても完全に動くように回路に冗長性を持たせる技術も改善の余地があります。 他に挙げられるのが素材の改善です。もう10年以上前になりますが高誘電率材料によってゲート絶縁膜を厚くすればリーク電流が減るというHigh-Kメタルゲートはintelの45nmプロセスのときには既に量産に入っていたとされています。 https://www.jstage.jst.go.jp/article/oubutsu/76/9/76_1006/_pdf https://pc.watch.impress.co.jp/docs/2007/1212/iedm03.htm 他にも例えばトランジスタの形自体にも工夫の余地があります。 https://ascii.jp/elem/000/000/884/884429/ これらの研究は終わったという事は無く、業界の人々はより良い素材をより良い形で量産に適した製法で製品化できるよう今も研究を重ねています。 CPUそのもののアーキテクチャも日夜改善が繰り返されており、ほぼ同一個数のトランジスタを使いながらもより高い処理性能を実現する分岐予測とか投機的実行とかSIMDとかやることは山ほどあります。 まとめると、微細化が仮に終わってもトランジスタの性能改善はまだまだ研究余地があるし、トランジスタの有効利用法に関しても大きな研究余地があります。

熊崎 宏樹:前提として世の中にあるデータベースは基本的にログファイルが破損する事を想定していません。ログは信頼できるストレージに複製込で保存されており、化けたり消えたりする事はないという前提を置いています。想定する一番大きな障害でもMedia Failureであり、これはデータベース本体を保存しているストレージがまるごと使えなくなった場合の事ですがそれでもログから復旧できると言っておりログ自体は故障の議論の範疇外です。仮に信頼できる永続ストレージが世の中にあるならそこに全DBデータを保存すれば復旧にまつわるめんどくさい議論の大半がスキップできるのにと思っているDB研究者は多いと思いますが、実情としてはログの永続化は運用レベルで歯を食いしばって実現しているようです。運用レベルでログが信頼できるとしているのでDB開発者はログ以外の部分をアルゴリズムで守るように努めています。 さてログのフォーマットをどういう形にするかというのは広大なデザインスペースがある話題ですが、アクセスしたいと思った該当ログに対しては全探索せずとも見つけられるようにするのが定番です。破損は無いにしてもΘ(N)よりは高速に任意のログを見つけたいものです。ここに関してはPostgreSQLと(僕の理解が正しければ)MySQLが採用している定番の方法があって「ログのオフセット自体をIDとして扱う」という方法です。ログに振られるLSN(Log Sequence Number)は被りが無くて単調増加さえしていれば歯抜けがいくらあっても構わないのでファイルの先頭にあるログはLSN=0だし、その一個後のログは前のログが42バイトあってその直後をスタートとしているのでLSN=42である、といった具合です。これはLSNが与えられた時にそのファイル箇所までシークすれば読めるので圧倒的に高速です。各LogにLog長を埋め込む必要もありません。 奇しくもこの方法はrecordの一部が破損してもそこから後ろのオフセットまでは壊れないという点でも頑健です、もっというと各ログにCRC32のようなチェックサムを埋め込んでおく事でログの破損を検知することができます（そこからどう復旧するつもりかは知りませんが…）。