熊崎 宏樹:ML系のインターンで内定が出たなら普通に行けば良いと思います。「MLでの採用」が各社幅があるので僕の想定しているものと違うかも知れませんが、ソフトウェアエンジニアとしての仕事とMLエンジニアとしての仕事は距離が結構近くて両方を行ったり来たりしている人もいます。最終的にML研究者やシステム系ハッカーを目指す段階なら話は変わってくると思いますがキャリアの第一歩としてどちらかを選んだら不可逆という事はありません。 そして専門性はもちろん大事ですがそれ以上にMLエンジニアでもソフトウェアエンジニアでもお金を貰って働くということは報告・連絡・相談がちゃんとできるとか問題の論理的な構造と文脈を理解するとか、共通として必要になるスキルがありますのでそれらを意識して磨いていけばどちらでも通用するエンジニアになれると思います。どの道数年後にはそれらのカテゴライズに大した意味が無くなっていたり新しいカテゴリができていたりするでしょうから。

熊崎 宏樹:すばらしい。完璧な理解です。お察しの通り、C++でのポインタの取り扱いはセンシティブなトピックです。関数のシグネチャに参照がある場合、結局機械語に落ちたときはただのポインタによる値渡しとしてコンパイルされるので原理さえ理解していれば生ポインタを関数シグネチャに使用することを一切禁じても動くコードが書けます。ですのでC++におけるポインタの存在意義は機械語を吐くための実現手段ではなくコンパイル前のコードに意図を残すための手段として再定義されています。 ポインタ渡しは参照渡しと比べて自然にNULLを渡すことができるので、それを利用して必須でない引数であるということを明示する目的で使われる事もあります。しかしそういうケースではstd::optionalで渡す方が「必須でない」という意図を表現するために適切であるという意見もあります。 またポインタで渡されたオブジェクトは関数の内部でdeleteする事が自然にできます。ですので所有権ごと渡すという意図をシグネチャに与えるために敢えてポインタで渡す事もあります。しかしそういうケースではstd::unique_ptrやstd::shared_ptrで渡す方がコードから意図が読み取れるしコンパイラが後始末の行方を見守ってくれるので安全です。 ポインタとして渡された変数はそのポインタを書き換えて別の値を参照するようにコードを書き換える事ができますが、参照は別の参照先を指すように書き換える事はできません。しかしそもそもの話として参照先を差し替えるようなコードは複雑になりやすいのでその目的でシグネチャをポインタにするのは推奨されません（どうしても必要なら int* a = &b; のようにしてローカル変数にポインタを移して書き換える方がわかりやすい）。 寿命が別の手段で管理された所有権のないデータに対する参照情報をクラスのメンバーとして保持して適宜そのオブジェクトを作り直すことなく参照先だけすげ替えたい…みたいなケースぐらいしかポインタをポインタとして利用している状況が思い当たりません。しかもこれすらも適切なクラスでラップするほうが安全でしょう。 ですので、生ポインタ(shared_ptrやunique_ptrでないポインタという意味です)に関しては一切使わないというポリシーも充分ありえます。

熊崎 宏樹: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のようなチェックサムを埋め込んでおく事でログの破損を検知することができます（そこからどう復旧するつもりかは知りませんが…）。

熊崎 宏樹:これは長年いろんな研究が積まれながら結果としてあんまりパッとしていない分野です。 例えばOracleは自社のDB専用のサーバやチップを作れる会社ですし、更に高速なDBを求める顧客にハードウェアまで垂直統合させたアプライアンスのような製品を用意するのは順当な戦略に思います。SPARC M8というCPUはまさにOracleがDB用に拡張したプロセッサ機能を搭載しています。 https://www.oracle.com/technetwork/jp/server-storage/sun-sparc-enterprise/documentation/t8m8-architecture-wp-20170914-ja.pdf > SPARC M8 プロセッサには、特定のソフトウェア機能またはプリミティブを高速化するハードウェ > ア・ユニットが組み込まれています。これらオンチップのデータ・アナリティクス・アクセラレータ（DAX）ユニットは、データベース・クエリ処理をオフロードし、リアルタイムでデータ圧縮解凍を実行し、Java > ストリームを加速化します。インメモリ・クエリ・アクセラレーションは、他の プロセッサに比べて最大 7 > 倍の性能を実現します。インライン圧縮解凍機能により、パフォーマンスを低下させることなく、同じメモリ・フットプリントで最大 2 倍の量のデータを保存できます。 > SPARC M8 プロセッサの新しいコアには、Oracle Database での実数処理を高速化する Oracle Number > ユニットも組み込まれています。 非エンジニア向けの資料なので詳細は書いていませんが大まかに雰囲気は掴めます。要するにDBの内部で行われる動作の一部をハードウェア処理にオフロードする方向性のようです。DAXユニットというストリーム処理を行うコプロセッサのような物の他は特定用途のSIMD命令かアドレス自動チェック機構あたりであって、専用プロセッサだからといってあらゆる処理が桁違いに速くなるたぐいの物では無さそうです。これに需要があることは否定しませんが、DBMS専用プロセッサをゼロから作るに値する程の恩恵が万人にあるとは思いません。クラウドで安く強いx86系のCPUが使えれば大抵の用途には合致するはずです。 オフロードする、という観点でいうと今どきの大規模なデータベースはストレージとエグゼキュータが別のホストになっていることが定番で、エグゼキュータ側でトランザクション処理を実行する傍らでストレージ側でチェックポイントや永続化や簡単なフィルタ処理の一部などをオフロードされて処理する事が一般的です。DBMS専用プロセッサにその一部がオフロードできるにしても汎用プロセッサの方ができることが多いですし、充分な通信帯域さえあればオフロード先が隣のノードで構わないという戦略が経済的に勝利したと認識しています。 データベースの処理は分析処理のOLAP、トランザクション処理のOLTP、後はストリーミング等の特殊用途の3つがメインとされます。 OLAPに関してハードウェア的なリミットはほぼ無く、基本的にCPUやマシンを並べて並列度を高めれば高めるほど高速化する事が多く、その観点においてボトルネックはタスクをデータの偏りに対処しながら上手く分配するアルゴリズムや実装上の問題の方が大きいです。強いていうとソート・ジョイン・リミットなどの並列化に関してはインターコネクトで工夫をしているようです。従来はMPIが得意としていた集合通信を用いた並列処理ですが大規模なデータを巨大なクラスタの中で合理的に並列化しようと思った際にはネットワークのハードウェアのレベルから手を入れRDMAなどの力を借りて高速化する余地はまだまだあります。 例えば以下の論文はTop-KクエリをMPIを用いて高速化するというものです。 https://arxiv.org/abs/1709.05183 OLTPに関してはワークロードとしてトランザクションが衝突しまくるケースに対する根本的な解決策は見つかっておらずとにかくCPUクロックを上げるしかありません。トランザクションの衝突が問題にならないケースにおいては内部の永続化アルゴリズム自体の方がボトルネックになることが多いようです。ここについては僕のブログ記事での論文紹介もご覧ください。 https://kumagi.hatenablog.com/entry/finding-storage-glitch 永続化アルゴリズムの問題が解決した場合には恐らくディスク帯域がネックになりますが、M.2のSSDをストライピングするなどによって容易に10GB/sec以上の帯域は出せるので不揮発メモリが真に輝く時はディスクの永続化レイテンシが問題になるケースに限られ、そこへの道のりはまだまだ遠かろうという論文もあります。 https://dl.acm.org/doi/10.14778/3603581.3603586 ストリーミング処理に関しては僕はほとんどサーベイしていないので有識者の意見を待ちたいところです。

熊崎 宏樹:質問ありがとうございます。いくつか質問の内容がわからない所があったので少し考えていました。 TiDBの記事を読みましたが2PLとは書いておらず2PCとその内部での挙動に関する話でレイヤーが異なるようです。2 Phase Lock (2PL)と2 Phase Commit (2PC)は字面こそ大変良く似ていますが2PLはロックのComposabilityを応用したトランザクションの実現手法である一方で、2PCは故障を度外視したまま設計されたデータ複製に過ぎず、適用する対象も導入する目的もまるで異なるものです。 このTiDBの記事では事前書き込みリクエストを対象ノードすべてに送った後にコミットを改めて対象ノードすべてに送る2フェーズからなるので正しく2PCであるようです。そしてこれはロックの成長相と縮退相の2つから成るという点でも2PLでもあります。そして問題はこれがS2PLであるかどうかです。 > Raftの層である程度の Durability やConsistency を保証しているから2PSで十分 Raft自体にDurabilityを保証する機能はありません。Raft自体がデータを永続化し続けるステートマシンを前提としているからです。2PSというのが何なのかわからないですが2PLだとしても2PCだとしてもRaftだから十分という話にはなりません。 > 実際にはS2PLだが2PLと説明している これはこの文書に限らずとても良くあるパターンです。Strict 2PLと2PLをわざわざ分けて論じる必要がある時は永続性と一貫性に焦点を当てた話をする時であって、2PLと書かれている文章はおよそS2PLの事を指している事が多いです。 > Durability を一部諦めている（考えにくいですが） これは無さそうです。 TiDBの記事を読む限り「事前書き込み」が全部成功した場合に限り次のフェーズに進むそうですし、事前書き込みを永続化していないケースは無いのではないかと思います。S2PLはロックの解除前に永続化を済ませている事が条件なので「事前書き込み」が永続化されているならばこれは広義のS2PLと呼んで差し支えありません。 ここで問題になるのが何をもって「永続化」と呼ぶかという話で、直感的にはディスク書込の事を言うことがほとんどですが、もう少し考え方を拡張すると「システムが想定する範囲の障害があってもデータを失わない事」と言い換える事ができます。そもそもディスクに書き込んでもディスクごと吹き飛んだ（これはシステムが想定していない範囲の障害）ら意味がないですし、これまでは電源断からの復旧に耐えることをもって永続化と呼ぶケースが主でした。 Raftを用いた分散システムにおける「永続化」とはRaftが想定する範囲の障害つまり少数ノードの故障や離脱に耐える事であって必ずしもディスクに書き込むことを想定していない可能性もあります。TiDBはRaftで複製され永続性が保証されたストレージ(TiKV)の上に2PCなどのプロトコルを用いて複数データにまたがる一貫性を実現する構造になっていて、上下で役割を分担しています。そしてこの記事を読む限りは永続性に関してはTiKV側に任せていると取れるので実際の所S2PLに近いことが行われていると思われます。

熊崎 宏樹:技術面接の際にGo言語を選ぶ事はできますので、可能不可能という話だけで言うと可能です。 ただ「Go言語だけがめちゃくちゃ書けるけどC/C++やJavaはできない」という人間をこれまで一度も見たことがありません。もっと言うとコンピュータ・サイエンスの高い素養を持ち合わせながらC/C++もJavaもできないという人もお目にかかった事がありません。そもそも何か一つの事を突き詰めようとすると自ずとその周辺分野もある程度理解する必要があります、なぜなら理解しないと自分の分野にどの程度関わっているかすら切り分けられないからです。周辺分野に一度も興味を向けた事もなく高みに登ったつもりでいたらそれは視野が狭いだけです。Go言語もある程度以上の高みに至るとC言語と完全に無縁ではいられません。 Googleの採用の仕組みはCracking Coding Interviewにも書いてありますが、Hiring Committeeを通過した後に部署とのマッチングがあります。部署によってはJavaしか使わなかったりC++しか使わなかったりする所も珍しくないので、そういう所のマネージャは自然と「Javaが得意な人に来て欲しいな」ぐらいの事は考えます。そうしてマッチング先が一つも現れなかったら「今回はあなたに合うポストがありませんでした」として落ちる事は起こりえます。もちろん運良くGoを使っている部署とマッチングを果たすことも理論上はありうるでしょう。 これはGoogleに限らず言える事ですが、就活する際には「必要とあらば何でも学んでみせる」という覚悟を示すことは常に重要です。ですのでキャリアをGo言語と心中させにいくスタイルを貫くのはあまり賢明ではないと思います。 ここから先は完全に余談なのですが、GoogleはC++用のライブラリのabseilを公開しています。 https://github.com/abseil/abseil-cpp これは社内でC++を使い込むうちに常用されている部分を切り出してライブラリ化して公開されたものなのですが、例えばabsl::StatusOr<T>型は「成功時はT型の値、失敗時はエラー詳細を内部に持つ」という直和型でそれを返す関数をいくつも宣言して失敗時にはエラー詳細を早期リターンする、という感じのコードを absl::StatusOr<Foo> out = Bar(hoge); if (!out.ok()) { return out; } こんな風に延々と書いていると、Go言語で out, err := Bar(hoge) if err != nil { return err } と書いている時と書き味は大差ないです（個人の感想です）。Javaを使っても言語の文化としてCOBOLを書くことができるのと同様に、abseilを高度に使い込んだC++コードは文化としてGoを書いているように感じるときが度々あります。そもそもGo言語はGoogle社内でのシステム開発上での問題を解決するために作られた言語ですので、それらに類似点があるのは自然な話でもあります。 他の言語やライブラリも好き嫌いせず学ぶうちにGoの真髄に辿り着く事もあるかと思いますので是非幅広く勉強してみてください。

熊崎 宏樹:ARIESの本質、これは僕も疑問でした。Algorithms for Recovery and Isolation Exploiting Semanticsの頭文字を取ってのARIESですが何がSemanticsをExploitしているのかという点について考えるたびに別の答えが思いつくのでまるでわかりませんでした。 そこで去年、大阪に訪問していたC. Mohan先生（ARIESの著者）に直接聞いてみました。（Mohan先生の右後ろで目を閉じているのが僕です） 少し考えた後に彼は「ページのインクリメンタルな操作の中にすべての動作を畳み込んだ事こそがExploitである」と答えました。僕の理解はこうです。 * DBにおけるページとはただのディスクの断片ではなく、それぞれが独立したステートマシンである * 複数のステートマシンに対する操作（=ログ）に対してLSNという全順序関係を持った横串を刺してトランザクションレベルでの一貫性を設けた * ページごとにそのページに対して最後に操作を行ったログのLSNを記録し、それより小さいLSNのログはいついかなる時も無視する事で片方向の冪等な遷移しか起きない状況をロジカルロギング上でも達成した * リカバリ時においてはLSNの任意の断片の箇所に対して全トランザクションの成否が確定し、そこから続くインクリメンタルなRedoと更にそれに続くUndoの内容が確定する * UndoもCompensation Logを伴ったRedoというインクリメンタルな操作に畳み込んだのでAbort操作とリカバリUndoが共通化された データベースのロギングプロトコルの話を出発点にしてページをステートマシンに見立てる視座の高さに至るのは一種の悟りのようでありますが、ARIES自体はACIDにおけるAとDしか相手にしておらずトランザクションの並行制御についてはロックテーブル等に任せている事などを理解していくにつれてすんなりと理解できる事と思います。これが理解できたら発展形の一つであるInstant Recoveryについても調べてみてください。 ARIES/KVLとかARIES/IMはARIESで一貫性制御を行っている上でSerializableな分離レベルを実現するためのファントム避けのロックの話等をしているのですが個人的にはロックテーブルの側で対処すべきであってその辺の研究の流れはGoetz先生のOrthogonal Key-Value Lockingの研究の中でも説明されています。以下に引用します。 様々な試行錯誤を経た果てに地獄のように大きなロック互換表が出来上がっていますがこれはやむなしでしょうか…。以上参考になりましたら幸いです。

熊崎 宏樹:Pointer Swizzlingについて詳しくない人のために概要を説明しますと、これはメモリに乗り切らないデータの断片をメモリに乗せて処理している際に、データ内での参照関係を表す論理的なポインタをメモリ上でのみ物理的なポインタへと侵襲的に上書きする事で同じくメモリに断片的に乗っている宛先データへのショートカットを提供し高速化するテクニックです。上手くいっている時は速度面では申し分無いのですがディスクに書き戻す際に再び論理ポインタに書き戻す必要があるのと、ポインタを被参照されているすべてを書き戻さないと知らずに物理ポインタにアクセスしてSEGVという事故が起きうるのが難点です。 初期のPointer SwizzlingはMMUなしで仮想メモリっぽいものを実装したり、巨大データを扱うプログラミング中での活用を目的としており、RDBMSへの貢献というよりはOSやプログラミング言語に対するテクニックとして提案されていたようです。特にOSのレイヤーでサポートするならページフォールトをトラップしてメモリを侵襲的に書き換えるなんてかなり夢のようでかっこいい技術です。しかしOSという観点では仮想メモリでやったほうが筋が良いのと、ファイル側を書き換えることさえできてしまえばCPUに任意のメモリアドレスを読みにいかせる攻撃が可能という欠点があり、プログラミング言語でいうとUnswizzlingの管理のために言語レベルのガベージコレクションに頼ったりする必要があったりしてイマイチ広く使われるには至りませんでした。 そこでGoetz先生らが出した2014年に出したIn-memory performance for big dataの論文の中で * Swizzlingは簡単には使えないけどRDBMSのB+treeにおけるブランチノードのポインタに限ってだけ使うとかなり上手くハマるわ * でもB+treeの逆参照を管理する必要があるからただのB+treeじゃダメでFoster B-treeが良いと思う * 複数の逆参照をマルチスレッド対応まで考えて上手く回すのは難しいけどFoster B-treeは全ノードは常に一つしか親を持たないから安全 * 逆参照を上手く取り回すためには物理ポインタはページに直結じゃなくてページ固有メタデータに直結すると上手く行くわ という形で再導入されLeanStoreとかでも採用するに至った、という流れがあると認識しています。

熊崎 宏樹:良いですね。日曜大工でRDBMSを作るのはもっと市民権を獲得しうる趣味だと確信しています。 分散システムを作る際に気をつける事を語ると毎度長くなってしまうのですが、データ指向アプリケーションデザイン、通称イノシシ本に書いてある事をベースラインに説明すると明快であると気づきました。 * レプリケーションされるのはトランザクションログだけで良いです。それ以外の一切のものはトランザクションログから再構成できます * ユーザに完了を報告する際に必ず永続化されるべき情報と、ユーザから読み出しが起きた時に何らかの加工をすべき情報との間に線引きが必要です * 加工をいつどこでやるかは分散DB側の裁量に委ねられています。ログの複製と同時にページへのApplyを行うのがAurora式ですが、ログの永続化と報告だけ先に済ましてしまい、Applyに関しては適宜暇な時に流すのがSocratesとかAlloyDB、という違いがありますがどちらを選んだからといって大きな間違いは無いです。 * 通信プロトコルは枯れてるものならどれを使っても劇的な違いはありません。僕ならgRPCを選びます * 故障直前にメッセージを正しく送れる保証がないので、生き残っている側が定期的に生存報告を送る事で死活確認するしかありません。RaftのプロトコルはAppendLogのRPCの中に生存報告が含まれており無駄が少ないです * RaftであればLeaderからの生存報告が途絶えたと判定するまでのタイムアウト時間を各Candidatesが乱数で決定し、その時間が経過したらLeaderに立候補します。Leaderの生存報告待ちだった他のCandidatesは一番最初に観測した（充分最新の）立候補に投票するので、乱数で決定する事になります。Paxosベースだと実装の幅があるのですがRaftのこの乱数タイムアウト立候補方式の方が引き継ぎが速いという利点があります * インスタンス同士のメンバシップはLeaderがステートマシンの中で管理するべき情報の一部です。つまり参加や離脱に関してはLeaderが認識してそのメンバシップ状態をアプリの情報とは別のレイヤーで共有し続けます。ですのでLeaderと通信できる限りは漏れなく認識できています * CockroachDBの論文の中で報告されていた事によると、障害やノード追加によるメンバシップ変更に伴うリバランス時には障害への耐性が弱まってしまうのでJoint Consensusという方法でメンバシップ変更前後のそれぞれの状態に対するメッセージの通信を独立して行う事で解決したと言っています。曰くシンプルで堅牢なアルゴリズムとの事ですがちょっと説明は難しいです Raftの挙動については英語ですがこのアニメーションの図解が一番わかり易いと思っています。 https://thesecretlivesofdata.com/raft/ もっと質問がありましたらどんどん聞いてください。

熊崎 宏樹:levels.fyiの情報を見るに中央値での年収199kドル（1ドル151円で約3000万円）というのは日本企業の中では破格と言って良いと思います。Googleと比べても劣らないと言えますが同一の職グレードに至るための難度が各社で当然違うので人によってどちらでより高く評価される事もありえますし比較は難しいです。 https://www.levels.fyi/companies/woven-planet-group/salaries/software-engineer 友人との噂話を総合すると、環境や待遇は申し分ないがソフトウェアカンパニーとして色んな意味でやるべきことがいっぱいあって人を選ぶかも知れない、という印象があります。と言ってもこんな事を言うとどこの会社もだいたい多かれ少なかれその通りなんですけれど…。

熊崎 宏樹:負債を繰り上げ返済する事の意味が大きいのは金利が高い場合です。逆に言うと負債の金利が安いのであればお金ではないのでそのまま踏み倒しても構いません。 どうした場合に「金利が高い」と言えるでしょうか、それは利子の返済に苦しんでいる場合です。もっと言うとキャッシュフローが許容できない程マイナスになっているときです。逆に言うと同じエンジニアリソースを割いた時の利益の増加の方が負債の繰り上げ返済より利得が大きいと判断したのであれば追加で負債を増やしてでも利益を増やす事がフロー改善のために合理的なこともありえます。 そもそもお金でないものをお金に喩えてる所からやや掛け違いが起きていますが、負債というメタファーでエンジニアリング上の意思決定を振り回すのであれば「お金はできるだけ早く返さなきゃ」なんて安直な議論ではなく、ビジネスの拡大と金利のバランスの中での舵取りとして考える方が建設的であります。 その上で、ソフトウェア開発での負債に乗る金利というものを正しく評価できているでしょうか？リファクタリングで返済できるような小手先の問題でしょうか、それとも構造レベルでのデバッグを要する大きな欠陥でしょうか？まずはそのあたりの可視化とモニタリングから取り組むのが解消の第一歩だと考えています。

熊崎 宏樹:研究者であれば研究とその成果の共有（論文など）こそが本分であり、誰もが絶対に特許を出すべきだとまでは思いません。 特許のそもそもの目的は「事業上の優位性を保つために研究成果を秘匿したまま事業化されてしまうと発明が独占されて社会の損失になってしまうので、研究成果の公開とその先行者利益の保全を社会レベルで推し進めること」です。つまり事業や利益の話を抜きにして特許の話はできません。 ビジネスの戦略上、特許を取得して知見を公開しながら社会に先行者利益を認めさせる腹積もりならもちろん特許を出すべきですし、その過程でその研究内容について一番詳しい企業内の研究者にその特許を取得せよと業務命令が下る事は全く自然な成り行きです。その時に特許を出す労働者は研究者とはいえビジネスマンとしての色合いの方が濃くなると言えます。 大学の研究者ももちろん特許を取ることはありますが、特許はそこから展開するビジネスで得る利益を保護するための仕組みであって、その利益の計画が全く無いのに特許を取るのは特許の哲学に沿っているとは思いません。もちろん誰しもがこの資本主義の中で生きる限りはビジネスマンとしての顔を持ち合わせていて、あらゆる研究者が特許を取る事ももちろん肯定されるべきですが、特許を出しているその瞬間には「これでひと儲けするつもりです」というビジネスマンのタテマエで特許を出しているという意味では研究者と呼べないという主張も一理あると思います（僕はビジネスマン兼研究者というキャリアは大いに結構だという立場です）。 僕の専門であるソフトウェアに限って言うと、ソフトウェア特許を取るというのはあまり有効でないと感じています。まず自然法則を利用した技術的思想の創作としてソフトウェア上の発明を定義することが大変な上に、他人がそれを侵害している事を立証するのも一苦労ですし、裁判で争って特定の発明成果を取り合うよりもっと別のビジネスを探しに行くほうが利益の期待値が高いと考えているからです。裁判で争う価値のある特許が世の中に存在する事は肯定しますが、これから提出する特許にその価値がつく確率は高くありません。また特許はその先20年での権益を保護してくれますが目まぐるしく進化が加速し続けるソフトウェアの業界において今後20年と同じビジネスが保てると想定するほうが無理があります。 また、これから行う行動が後から他人に特許が取られてしまうかも…という懸念を口にする人も居ますが、心配であれば論文なりブログなりでどんどん発信してしまうと良いです。それなら他人に特許が取られても過去に発信した情報を元に公知であったと主張すればあちらの特許を無効化できるので自分の情報公開の1年6ヶ月以内に侵害する特許が公開されなければその後の特許はすべて無効にできます。サブマリン特許はもう塞がれてるのでまず心配する必要もありませんし…。 長くなりましたのでまとめると ・特許は取りたかったら取っても良いがビジネスマンとして取るタテマエが前提になる ・ソフトウェアに関してはビジネスマンが利益を追うなら特許以外の方が効果的だと思う 以上参考になりましたら幸いです。

熊崎 宏樹:ちょうど解説しているサイトがあります。 https://www.windytan.com/2012/11/the-sound-of-dialup-pictured.html 図を拡大すると結構たくさんの情報をやり取りしているようです。 * 「ピーピロピロ」で自己紹介して今後の通信に使える方式を情報交換して決定し * 「ロロ」でお互い送れる信号の周波数の高さで減衰などの聴き比べを行って上手く通信できそうな速度を決定し * 「ザーザー」でお互いにノイズを送りあってその状況で「１」という信号を送り合う事でイコライザを調整して受信信号を最適化する という感じのようです。電気のことは詳しくありませんがkm単位で遠い相手と通信する以上、その経路では様々なノイズや減衰などがありえるので接続の度に注意深く調整をしていたようです。 ダイヤルアップという名前の通り電話回線の上でこの通信を行っていたのですが、電話回線に流しているうるさい通信をそのままユーザーの耳に入れる必然性は全くありません。これに関して諸説あって、最初期のモデムは電話回線直結ではなく電話の受話器に向かってスピーカーとマイクを向けていたので通信中の音が聞こえるのが当たり前過ぎて逆に音を出さないというアイデアがなかったとか、単純に不具合が多かったので検証に便利だったとか、当時の電話網のユーザーはほぼ人間だったので間違えて人間のいる番号に掛けてしまった場合にはザーザー音の代わりに向こうの人の肉声が聞けたので発信側がすぐに間違いに気づけて便利だった、とか言われています。

熊崎 宏樹:端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリーフ以外の部分（ブランチノードやインターナルノードと呼びます）にキーに対するバリューを保存するかどうかです。そしてノード1つはバッファプールで管理される1ページを保持しています。ページサイズが同じならB-treeはブランチノードの中にキーに加えて値の実体も保存する必要があるのでブランチノード1つが保持できる子ポインタの数は自ずと少なくなります。対するB+treeはキーに対応する値を持たず子ノードのポインタだけを持てばいいのでブランチノードが保持できる子ポインタの数はB-treeより多くなります。下図参照↓ これによってB-treeは探索が木の途中で終わる可能性もある一方で木全体は個々のノードの小ポインタが少ないせいで高くなりがちでB+treeは木が低く抑えられます。データベースとしては検索対象のデータが常に全部バッファプールのメモリ内に収まらないという前提があるのでページのいくらかはディスクに置いたままにして、メモリの速度を最大限活かす必要があります。 さて下にB-treeとB+treeを模式しました。B+treeの方が子を多く持てるので3〜4の子ノードを持ちます。B-treeは子ノードを持てる数が少ないので2ページを子として持ちます。赤のページがメモリに載っているページで同時に5枚までしかメモリに載らないとします、黄色のページがディスクにしか無いページでその読み出しには多大なコスト(HDDの場合10ミリ秒、3GhzのCPUにとって3000万クロック！)がかかります。B+treeはブランチノードがおよそずっとメモリに載り続ける仮定ができます。B-treeはルート含めどのページにも目当ての値が保存されている可能性があります。 B+treeはどの値を読むときも常に確定で1回のディスクシークが必要ですが、メモリに乗り切らないデータを扱う以上は避けられないコストであります。B-treeは運が良ければメモリだけで値を返せる可能性もありますが最悪の場合はディスクシークが3回になります。しかも目的のページを運良くキャッシュできている可能性はディスクとメモリのサイズ比が広がる程に悪化していってしまいます。そのページに目当ての物があった場合のディスクシーク回数の回数を書き足すと以下のようになります。 B-treeは全部で15枚あるページに対して期待値1.53回(=23/15)のディスクシークでアクセスできます。B+treeは常に1回です。B+treeの方が少ないディスクシークと言えます。ハードディスクがとにかく遅い時代の設計なのでそれと比べるとツリーを辿ることのCPUコストは無視して論じる事が出来ます。 とここまでが古典的データベースの話ですが、最近は結構事情が違います。近年では * MySQLにアクセスするデータは99%以上バッファプール上のデータに当たるまでシャーディングなどでチューニングする事が良くある * メモリの価格が劇的に安くなったのでメモリに乗り切らないデータは扱わないと初めから割り切ったインメモリDBも台頭 * 何なら世の中のDBの9割は5GB未満しか保存していないなんて与太話もある * ディスクシークはNVMeでめちゃくちゃ速くなったのでデータベースアクセスの支配項が移った * 構造上ブランチとリーフに多重で同一のキーが保存されるB+treeはキーが長い文字列や複合キーなどによって複雑に長くなった場合に無駄が多い など、MySQLが設計された頃とはハードウェアや使い方の様子が大きく様変わりしているので今後またB+tree以外のデータ構造にも脚光が集まるシーンが来るのではないかと期待しています。

熊崎 宏樹:眼の前の仕事を上手くやる、という技芸レベルの話では実はそれほど他社との決定的な差はなく、組織として上手く行ってるのはとにかくスケールする事を意識しているのがポイントではないかと思っています。 組織構造のデバッグが上手 仮に全社員が優秀で与えられたタスクを誠実にこなしていても、組織を大きくしていくと部署間で細かい矛盾が起きたり正義が衝突することは珍しくありません。また衝突しなくても特定の問題を解決する部署が事実上存在しなかったり問題自体が放置される事は一般的な組織において珍しくありません。 Googleが組織として上手くやっているなと感じるのはそういった組織内での矛盾を早期に見つけて自発的に解決しようとし続けているという点です。技術の創造と設計という本から図を引用しますと このように組織内での分担は膨らんだり縮んだりするのが自然の流れですが、現状の自組織が何を見落としているかを積極的に見つけ、組織の再編によってデバッグする事でみんなが働きやすくなるようにしているようです。単に組織再編だけなら大抵の組織で行われている事ですが、それによって構造レベルのバグを取り除くという力強い意志を感じています。大量のサービスが時に惜しまれながら終了しているのはもしかしたらその片鱗かも知れません。 日本の会社については詳しくないので伝聞からの推測ですが、組織レベルでの目標を見失わずにメタなレベルでのデバッグを繰り返し行っている会社としてはリクルートがそれに近いのではないかと想像しています。 文化の洗練に多大なコストを支払っている また大企業において、間接的に数百人という部下を抱えるクラスの人の発言は本人不在のままでも部下の間で繰り返し再生産され伝言ゲームが行われ、出席していない会議においてすら影響を及ぼすものですがGoogleの偉い人は何万回再生産されても構わない正しい事を文字通り部下全員に向けて直接発信しています。よくニュースサイトで「スンダー・ピチャイCEOが全社員向けに伝えたことによると…」などといった文字列が出ますがこれは本当に文字通りヒラ社員隅々まで受け取ることになるメールで直接語りかけています。CEOレベルでなくてもVPなどのそれぞれも結構な頻度で部下全員に何を目指して行くべきかを伝言ゲームではなく直接的かつ具体的に伝え続けています。 Googleの偉い人が具体的に何をやっていたのか、というのを元VPレベルだった人がブログに公開していましたが、文化を維持して高めて行くのに弛まぬ努力が必要なので「まるで職場の花に水をやるように」忍耐強く繰り返し力を加え続けることが重要であったとの事でした。こうして一歩間違えば壊れたレコードとでも評されてしまうような複雑な事を適切にやり遂げるのは特定の年数働いて自動的に昇格しただけの人間には荷が重すぎます。文化を動かし発展させることができる人間をどのように見つけ出すのか僕には想像も付きませんがそれを上手くやれているのがGoogleを他にない会社にできている要素ではないかと想像しています。 超人が頑張れば3人分ぐらいの仕事ができるかも知れないにせよ、100人の部下の生産性を1割高められれば10人分の仕事が出来たと換算できるので、組織が大きくなるにつれ「自分以外のみんなの生産性が上がる」という事自体に掛けるべき比重が上がっていきます。それが組織をスケールさせるという言葉の意味であり、昇進するに伴い適切に難度の高い仕事を優秀な人に割り当てていく継続的な仕組みの良し悪しがゆくゆくは会社の命運を左右することになります。「Work Rules」とか「Googleのソフトウェアエンジニアリング」などの本には嘘は書いていないので書いてあることを真似れば確かにGoogleっぽい会社を作ることは可能かも知れませんが、それはあくまで会社のハードウェアの話であって、文化という究極のソフトウェアは書籍化しようが社長がトップダウンに推し進めようが一朝一夕では模倣出来ませんし、そこに真の組織的強さがあると感じています。 Googleは明らかに僕より賢い人が作り上げた仕組みなので僕の貧弱な知力では解釈して説明できるのはこれぐらいですが、何かの参考になれば幸いです。

熊崎 宏樹:天才プログラマと言われて頭に思い描く人物が複数いて、共通点が実はそんなに無いので共通点を洗い出すのはやめて「自分だったらできないだろうなぁ」という事例を思い出した順に列挙してみます。 しょぼそうな高速化がめちゃくちゃ刺さる 凡人に理解できないような天才的なアルゴリズムを用いてめちゃくちゃ計算量を減らしている、なんてことは実はほぼ見かけなくて実際によくあるのがこのパターンです。賢いアルゴリズムというだけなら素養のある秀才ならなんだかんだ思いつくので個人的には天才とまでは感じません。 天才は「Aを受け取って計算してBを返す」みたいな一見平凡な処理に対し「Aの配列を受け取って結果をBの配列にして返す」みたいな誰でも思いつくようなしょぼそうな効率化を行って途方もない効率化を果たします。もちろん凡人が任意の場所でそういう細かい最適化を入れて同様の効率化が再現されるわけではないのですが、天才はただのバッチ化やキャッシュ等で10倍速以上に高速化できる秘孔を適切に突いてきます。脳内にモデル化している計算機のエミュレーション精度が異様に高いのではないかと想像しています。 とにかく異常に手が速い 天才はノッてる時のコーディング速度が異常です。一日で1〜2万行ぐらいの異常なペースでそれなりに頑健なシステムを作ってきます。凡人は数百行書いてはバグり散らしてデバッグに数日溶かし…というサイクルを回していますが、天才は一晩でモジュールいくつかを書き上げて動く物を出してきます。そういう天才は似たような目的のコードをいくつも読んでパターン化して良い部分を適切に模倣できるので実装の作法に試行錯誤する時間が短いのではないかと想像しています。 斬新なインタフェースを備えている ソフトウェアとは抽象化の連続です。同じ抽象化をする限りはその裏で行える実装の幅には限界がありますが、内部の仕様からくる都合を上手に隠蔽した抽象化は速度面やコーナーケースで意外な恩恵を示す事があります。パッと見ただけでは何だか野暮ったくて使いにくいAPIだなぁと感じる事もありますが、深く内面を理解したり他の抽象化と比べていくともはや元のAPIには戻れないような中毒性を備えたインタフェースにロックインする事になります。天才は異世界からの転生者のように「こうやって抽象化するのが一番自然だろ？」と事も無げに言いますが、凡人からするとコロンブスの卵のようです。 無味乾燥なデジタルの世界において物事をどう捉えるかというのは想像以上に大きな影響を我々の思考に及ぼしており、どんなに新しい概念でも想像しやすいメタファーに寄せて考える事で一気にフォーカスしやすくなります（これは別の可能性を無意識に切り捨てる事と表裏一体です）。天才が描き出す抽象化は自然とチーム全体の基底ベクトルのような働きをしてくれます。

熊崎 宏樹:コンピュータアーキテクチャ 大学の情報工学科に入学時に教科書として指定されたいわゆるパタへネを推します。 コンピュータの構成と設計 第5版 CPUの構造と基本は現代ではかなり複雑になりましたがこの本に書かれている基本を知っているかどうかで込み入った問題にぶち当たった場合の解像度が違います。 データベース 由緒正しいDBの読本というとオンラインで読めるRedbookとなりそうですがここは敢えて データ指向アプリケーションデザイン いわゆるイノシシ本を推します。名前からしてアプリケーションの話のように見えますし、分散システムに関する話が多いのですが最終章まで通して読むと「アプリケーションとデータベースの境界とは本来存在せず、入力されたデータを『いつ』『いかに』『安全に』加工・保存・出力するかがアプリケーションであり、その目的に対する最善手をフラットに考えるとある意味でアプリケーション全体が既にひとつのデータベースであってその仕事の一部を既存DBに分担しているに過ぎない」という少し過激な思想を啓発しています。大変な労力をかけてサーベイされた良著ですのでぜひ一冊お持ちください。 OS プログラマたるもの一度くらいはスクラッチでOSを作ってみないとなということで ゼロからのOS自作入門 を推します。通称みかん本です。 アルゴリズムとデータ構造 大学の教科書でいくつもあるのですがあまりわかりやすいとは言い難く、実践的に学べる競技プログラミング方向の入門書がわかりやすくておすすめです。 プログラミングコンテスト攻略のためのアルゴリズムとデータ構造 いわゆる階段本です。競技色があるのが抵抗あるなって人はラムダノートの みんなのデータ構造 が良いんじゃないかと思います。 セキュリティ 残念ながら専門外なのでパスします。 ネットワーク 最近のトピックは追えていませんが、古典的な知識からの積み上げが大事な分野であって知り合いの専門家はだいたいこの本を通読しています。 マスタリングTCP/IP　入門編 あと個人的にはあまり好まないですが人によってはタネンバウム先生の コンピュータネットワーク を挙げる人も居ます。どちらも入門的な内容を丁寧に説明しているのでお好きな方を読んだら良いかと思います。ラムダノートのピアリング戦記も面白かったんですけどこれが日々の業務に役立つ人は稀でしょう…。 より実践的な内容で高みに立ちたいのであればCiscoの資格試験としてCCNA, CCNP, CCIEといったレベルのそれぞれの試験対策本がいっぱい出ていますので「試験対策勉強の方が身が入る」というタイプの人はそちらのルートから学ぶ手もあります。 プログラミング メインで使うプログラミング言語が決まっているのであればその中での良著を探したほうが良いですが、言語を限定せずにプログラミングタスク全般に対して実用的な文化を学びたいのであれば Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス が良いと思います。ソフトウェアを書いて保守して運用するという流れに欠かせない万事の知見がつまっており、読み返す程に学びがあります。英語の本を恐れないのであれば A Philosophy of Software Design が僕のお気に入りです。過去にこのmondでも何度かおすすめして来ていますが、和訳される予定はしばらくなさそうなので渋々英語で読んでいます。 仮想化技術 残念ながら専門外なのでパスします。

熊崎 宏樹:これを理解するには、そもそも読み書きがシンプルでないケースについて学ぶのが良いと思います。 シンプルでない書き込みの典型的な例がトランザクションです。トランザクションを使うと、複数の箇所に書き込みを行ってもコミットという特殊な操作を明示的に行うまではそれらの書き込みが他の人からも見えず、更には途中で中止や電源断が起きたら勝手に元通りに戻ります。 これを実現するためには必然的にコミット前と後の両方の情報を他者が復元できる形で永続化する必要があり、読み出しを行う際にも他人が書きかけであるかどうかを認識して読まないor読んで良いものだけ読むというトリックが必要です。これらの実現手段には様々なバリエーションがあり、どこのレイヤーで実現するかによっても効率は大きく変わるのですが総じて読み書きに必要なやり取りの量は増えざるを得ず高いパフォーマンスを出すのが難しくなります。 https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/transaction-apis.html DynamoDBは実はトランザクションをサポートしており、コーナーケースを無視すればそれっぽい動きはするようです。ただし「トランザクションの項目ごとに 2 つの読み取りまたは書き込みオペレーションを実行するのに十分なスループット容量をプロビジョニング」と書いてあるところを見るにおよそ倍のスループット容量を消費するつもりで総量を設計する必要があるようです。つまりトランザクションを行うと悪くて1/2の性能になると言っています。 シンプルでない読み出しの一例がジョインです。RDBMSで複数のテーブルを内部のデータに基づいて結合する操作ですが、テーブルが大きくなると効率的にそれを処理する方法は多岐に渡ります。例えば5000万人の顧客を抱える携帯電話サービスで家族内で余剰な通信容量（通称ギガ）を分け合えるサービスを実施するとして、5000万行の顧客テーブルと3000万行の家族テーブルがあり、全部の顧客は一つの家族IDを持つことで対応する家族テーブルのどれか1行に紐付けられ（家族は同一の行に紐付けられる）ギガ残量は顧客毎に存在します。顧客テーブルを1行1000バイトと見積もると5000万行は50ギガバイトとなり普通のマシンのメモリには乗りません(今どきは電気屋でも64GBとか128GB積んだマシンは買えますが)。 1人の顧客としてあなたは「自分が今月あと何GBまで（家族のシェア分含めて）使えるのか」を知りたくなって問い合わせを行うと、サービス側はあなたの顧客IDを用いて5000万行の中から索引し、そこから分かった家族IDを用いて再び顧客IDに対して貼ったセカンダリインデックスを用いてあなたの家族全員を探し、それらのギガ残量を合計して返す、という処理を行う事になります。インデックスのお陰で全件を走査せずには済みますが発生するIO処理は何往復にも渡り結構な負荷がかかります。更に毎月、ギガを超過した分などを精算し料金を請求する必要がありますのでそれを5000万人の顧客全員に対して実行すると1人あたり0.01秒で済んでも138時間（5.7日）かかります。シンプルに見えますがこれを間違いなく実施する事は遥かに大変で携帯キャリア各社は何億円も設備投資してこの計算を行っています。 DynamoDBはジョイン操作や集計などの処理をサポートしていないため、当然ながらDynamoDBの外でサービスに必要な集計などを行う必要があります。大抵のRDBMSはそれらを効率的に実行できるように工夫が凝らされているので原則としてはRDBMSのオプティマイザを頼って全部依頼するのが定石の一つですが、扱っているデータや処理量が大き過ぎる場合はDynamoDBなどをデータ置き場として利用するだけにとどめ、集計に相当する処理をプログラマが実装せざるを得ない事もあります。サービスとして必要な処理はDBなりアプリサーバなりがどうにか実行しなくてはならない以上、どこで実施するのが一番効率的でメンテしやすく経済的かつ変更に強いかを加味しながらバランスの良い設計をするのがソフトウェアエンジニアの腕の見せ所、というのがデータ指向アプリケーションデザイン（通称イノシシ本）の主張です。まぁ大抵はSQLで行けるとこまで行くのがおすすめですが…。

熊崎 宏樹:あるとしたらかなりニッチになることは間違いないと思っています。 ソフトウェアトランザクショナルメモリ（以下STM）は並行性にまつわる問題をトランザクションのセマンティクスの向こう側に隠してしまう事で誰でも簡単にマルチコアを活用するコードが書けるようになるというソフトウェアの機能ですが、10年ほど賢い人たちが色々研究した結果として性能面で完全無欠な速度を出す方法は見つかりませんでした。 STMはどう実装しても論理的に操作対象のメモリが衝突していたらどちらかが待たされざるを得ません。メモリの読み書きというプリミティブなセマンティクスをユーザーに見せている概念なのでCRDTやConcurrent Revisionsのような方法で操作を結合することはできず、MVCC的にオーバーラップできても論理衝突時にはアボートが必要となります。 アボートが起きること自体はRDBMSの上でも珍しくないのですが、言語の下のレイヤーでそれが行われるとデバッグが結構大変という問題があります。特に複数のトランザクション同士がお互いの尾を踏みあって共倒れする（Live-Lock）状態などはDead-Lockと違って発生に気づく事すら難しく性能のチューニングを難しくします。 マルチコアの性能を引き出したいからマルチスレッドで書いているのにマルチコアの性能をチューニング込みで引き出し切るのに向いていないというジレンマを抱えているのがSTMです。 なので「性能が読めなくても多少無駄でも構わない」かつ「でもマルチコアを使いたい」かつ「しかもデータ並列性だけでは綺麗に分けれない」というあまり一般的とは言えない分野で何か刺さるのであれば専用言語の機能として搭載するのはありうるかなというレベルです。 100コア以上積んだマシンを使うのが一般的になってそこそこの効率で走ればいいやって未来が来たら抽象的な粒度でタスクを記述することで良きに計らってくれる言語も需要が出てくるかも知れませんが…。

熊崎 宏樹:僕の短い答えは「興味がなければ知る必要はありません」です。 OSやCPUは使い方がよく文書化されていてそれらを良く理解すれば機能的にはほとんど困ることが無いように整備されています。使い方さえ理解すればその裏で何が起きているか知らずに済むというのは複雑さが増大し続けるソフトウェアの世界における数少ない救いです。自動車の運転だって自動車学校で習う事さえきちんと学んでおけば大半の人間は生涯運転する上で不自由はしないですし、エンジンを構成する個々の部品の名称を暗記するよりもマナー良く運転する事のほうが大事です。ペダルやハンドルの向こう側でどんな物理現象が起きているかは自動車の開発者や保守作業員が知れば良いことです、プロに任せて自分の仕事に集中しましょう。むしろそのような分業が成立すること自体がある意味で巨人の肩に乗れており、わざわざ知らなくても良いことを知りに行くのは巨人の肩から降りているとすら言えます。 さて質問にあった低レイヤを勉強することで役立つ場面を思いついた順に列挙してみますと * 新技術を理解するのが速くなる * サイドチャネル攻撃を思いつけるかも知れない * 問題に対してより多くの仮説を出せる * 良い設計の手本を知れる 例えばeBPFとかDPDKはカーネルとユーザランドの間でのやり取りについてある程度知らないとどんな問題をどう解決しているのかまるでわからないです。他にも例えばSpectre脆弱性はCPUの内部動作についてある程度の知識がないとまずそこから学ぶことになりますし深刻さもピンと来ません。所属する技術界隈にも依りますが、低レイヤーの事を学ぶほどそれに付随して土地勘が働き理解の助けになります。そしてその土地勘は技術者としてさらなる高みへ到達する手がかりにもなります。 あなたはスマホであれノートパソコンであれ何らかのデバイスを使ってこの記事を読んでいますが、そのデバイスのスペックは覚えているでしょうか。あなたは物理的にそのデバイスを使用していますが、精神的には理想の世界にあるデバイスのイメージを使っているに過ぎず物理デバイスとは乖離があります。しかしデバイスに詳しくなるほどイメージの解像度は上がり現実との差が縮まり様々な事がわかるようになります。例えばデバイスのカタログスペック（ピーク性能）と実際のベンチマーク結果（実効性能）が完全に一致することはまず無いですが、内部で何が起きているかを適切に理解することで現状感じている不便が性能の限界なのかバグなのかを切り分ける事ができます。コンピュータの内部は視認できない物だらけなのでバグと性能限界を見極める事すらそれなりの知識が必要です。 性能問題にぶち当たった時に何を測定したら解決するか究明するのは口で言うほど簡単ではなくその推測や測定の方法だけで分厚い本が何冊も書かれています。例えばBrendan氏はパフォーマンス測定に関する書籍を書いている方でこの分野では有名な方です。 https://www.brendangregg.com/linuxperf.html この図は上のURLから引用した「OSのコンポーネント間の境界で何が起きているか確認するためのコマンド群の一覧」です。ひと目見ただけでOSがいかに多くのコンポーネントから成り立っており、その確認だけでも大変そうであることがわかると思います。 サイドチャネル攻撃というのは本来防御対象として想定していなかった角度からセキュリティなどを攻撃します。例えば暗号などを数学的に攻撃するのではなく、消費電力とか温度とか振動とか微細な反応速度の遅れといった思いつく限りあらゆる手段を用いて何ビットか情報を盗み出すという高度な技術です。これはいわば総合格闘技なのでシステムに関する深い知識が自ずと必要とされます。セキュリティ関連のこうした研究はもちろんですが、研究者の多くは万人が持たない特殊な知識や固有スキルを持ち込む事でオリジナリティを出す事が多いので研究対象の周辺や裏側の知識を貪欲に集めて活かそうとするのはある意味では常套手段でもあります。「僕が誰よりも上手くCPUを使えるんだ…！」という気概は職人的プログラマの誰もが持っている感覚かも知れません。 と色々書いたのですが、実際の所これを読んでいるあなたはOSやCPUの仕組みを深く理解しなくてもこれまでそれなりに満足に使えているのでこの質問をしているのだと思います。それはOSやCPUが「ここからこっちは自分の責任でどうにかするよ、こっち側の内部は知らなくて良いよ」という境界線を緻密に引いて念入りに踏み固めてくれているからです。これがもし不完全な境界線だった場合、誰もがその境界線のあっちとこっちを行き来しながらデバッグする必要がありCPUの実装を熟知せずにプログラマになることなんて到底無理な世界になっていました。そうなっていないのはひとえに今のOSというレイヤーが良く出来ているからに他なりません。 これは持論ですが、OSの上で走るDBでもwebサービスでもVMでもクラウドサービスでも複雑な物は内部では複数のレイヤーからなっており、そのレイヤー間の切り分け方の筋の良さで未来が決まります。外観だけ似たように見えるものであっても内部では機能拡張や運用や保守や性能向上のために様々な問題に直面しており、時の洗練を経て生き残った物だけが使われていくのがミドルウェアの歴史です。このソフトウェアの世界において、レイヤーを切り分けて「ここから向こうは自分が知らなくていい」と責任分担をして関心を分離するのはアップグレードに伴い無限に増え続ける複雑さに対して人類が使える数少ない武器です。あなたが積み重なるソフトウェアスタックのどこのレイヤーで働くことになるかは知りませんが、問題を切り分ける際のヒントとして過去に大成功を収めた事例であるOSを活用するのは良い考えかも知れません。

熊崎 宏樹:日本語で質問しているので「グーグル合同会社」か「グーグル・クラウド・ジャパン合同会社」に入社することを目的としたスキル振りの仕方に関する話と想定します。 Webに明るいエンジニアも低レイヤに明るいエンジニアもそれぞれに需要があります。具体的にはGoogleが公開している求人情報を見てください。 https://www.google.com/about/careers/applications/jobs/results/?location=Tokyo,%20Japan&jlo=ja-JP&hl=ja_JP ただし、その時々で募集している役職は変わっており、例えば低レイヤに明るいエンジニアを募集していない時もあります。募集していない場合は応募しても一般に入社は難しいと思います。 クラウド側だとセールスやコンサルティングの求人もあるようですが、残念ながら僕はクラウドに関しては詳しくないのでグーグル合同会社側の話をします。 グーグル合同会社で具体的にどのようなタイプのエンジニアが働いているかというのは公開されている情報があります。 https://careers.google.com/stories/software-engineering-google-japan/?hl=ja_JP > Q: 東京オフィスではどのようなプロジェクトがありますか？ > A: > 東京オフィスでは、フロントエンドやアプリ開発などの目に見えるプロジェクトから、ハードウェアに近い領域、また自然言語処理を用いたデータ処理や機械学習の研究まで、幅広いプロジェクトがあります。これらのプロジェクトを通じて > Google 検索、Google アシスタント、Google マップ、Google Chrome OS、そして Chrome ブラウザ > をより便利にしています。 このように検索やマップやChrome OSやChromeブラウザに関する取り組みをしているので、それらの部署から求人が出る事を想定するのは悪くない考えだと思います。またGoogleはC++、Java、Python、Goを社内での公式な言語として採用しているのでこれらのどれも書けないのであれば学んでおくことをオススメします。 個人的な肌感覚としてはWebは業界が広いので潰しが効く一方で差別化が難しく、OSやブラウザの細かい実装は取り組んでいる人間が少ないので競争がその分少ないのではないかと感じていますが、どちらを選んだからといって入社を約束できるものではありません。どちらか片方に絞ってもう片方を拒絶するよりは興味の赴くまま両方を学ぶ事を厭わない人のほうが社内には多い気がします。 面接に対する心得集はGoogleから公式のものが日本語で公開されていますので一読願いたいです。 https://careers.google.com/interview-tips/ 参考になりましたら幸いです。

熊崎 宏樹:結論から言うと「必ずしも安全とは言えない」です。 CTFという競技ではパスワード付きzipから中身を盗むのは典型問題の一つで、総当りで試していく専用のツールがいくつもあります。総当り攻撃は結構強くて短いパスワードなら数秒から数分でシュッと突き止めます。 https://logmi.jp/tech/articles/324500 多少長いパスワードでも使われている単語にあたりが付くなら辞書攻撃を試みたり、仮にAES-256による暗号化を使用していない場合かつ暗号化前の中身のうち何文字かでも予め別経路でわかっているなら既知平文攻撃で探索空間を狭めたりできるそうです。 https://blog.hamayanhamayan.com/entry/2021/12/23/225445 とは言え、充分に長くて複雑なパスワードが付いた中身がわからないあらゆるzipを現実的なコストでこじ開ける方法は（いまのところ）無いので全部危険だ、とまでは言えません。

熊崎 宏樹:「何がお金に結びつくかを理解し実行できるプログラマー」が稼げるプログラマーです。これは稼げる業界を理解してそこへ転職することまで含めた話です。 複雑なシステムやアルゴリズムを理解して唯一無二の最強のコードを書けるプログラマが稼げるに違いないというのはよくある誤解ですが、たとえばあなたが1億円相当で売れるダイヤモンドを砂漠の真ん中で持っていて、水を飲まないと死んでしまうので一刻も速く換金したい場合、目の前に商人が1人しかいない状況ではそのダイヤは1円で売れるかすら怪しいです。しかしそこに2人目の買い手が現れれば9999万9999円までは買値がつくかも知れません。つまり価値に見合う売値で売れるのはそこに買い手が2人以上いる場合に限られますし、したがって持つべき物は価値の高いダイヤモンドだけではなく、それを買ってくれる(できれば複数の)人への経路です。 めちゃくちゃ高度なテクニックが高額を稼いで欲しいとは僕も昔から思っていましたが、例えばKaggleばりに心血を注いでチューニングしつくして最高精度を叩き出したランダムフォレストよりも、精度はぼちぼちだけど何故その推論を出したのか素人にも説明できるシンプルな決定木アルゴリズムの方が出資者の気に入って勝つみたいな話はそう珍しくないそうです。 一緒に働く仲間としてはもちろん手が早くてわかりやすい正確なコードを書いてくれる人が望ましいのですが、それとは別の地平では自分しか持たない特定のアプリ(e.g. MT4)のノウハウを独占してわざと読みにくいコードを書くことで他のエンジニアが触れない聖域を作り職場で唯一無二の存在となることで経営者に交渉して高い賃金を得るという手法で「稼げるプログラマー」になるルートなんてものも存在するそうで恐ろしい話です。

熊崎 宏樹:素晴らしいですね。興味を持って調べて挑戦しようという精神は何よりも貴重なリソースです。 初心者がプログラミングに挑戦する場合、その言語に対して僕が重要だと思っている物が3つあります。 * 試してすぐに結果を見れる（できれば無料の）編集・実行環境 * ググって出てくる初心者向けの学習リソース * やる気 軽く調べた所、Solidityは少なくともあなたに対してこのすべてを満たしているようです。そして僕の持論ではこの3つのうち一番希少なリソースは「やる気」です。言語としての筋の良さとか市場での採用度合いとかでいろんな人々はPythonとかTypeScriptとかGoとか口々にオススメしてくると思いますが、あなたのやる気が出ないのであればどれも同様に価値はありません。 正直Solidity自体はそこまでオススメでは無いのですが、最初に学ぶ言語が何であってもやる気さえ続くのであれば「プログラミングを理解すること」の過程に大した差はありません。なんと弊社ではHot Soup Processorという僕の知る限りかなり酷い仕様のマイナー言語からプログラミングの世界に入門したソフトウェアエンジニアを僕自身を含めて3人まで確認しました、みんなゲームが作りたくて無料のプログラミング環境を探して見つけたようです。 ですので、あなたの興味がスマートコントラクトに強く向かっていてそのための試行錯誤を惜しまない忍耐力を維持するやる気があるのであればすぐにSolidityに取り掛かりましょう。

熊崎 宏樹:それはいわゆるロックインであって技術的負債とは呼びません。 決済処理を自分でどうにかするのは地雷が多すぎて潤沢なエンジニアリソースと商業規模が無い限りおすすめできません。「他の決済APIを使いたくなるとき」という未確定の未来に基づいて設計するのは明白にバッドプラクティスとして知られておりYAGNI(You Aren't Gonna to Need It)原則と呼びます。本当に必要になるまで過剰な設計をするのを避けましょう。 Stripeはよく出来たAPI設計をしているのでStripeしか使わないと割り切って実装すると腕の立つエンジニアなら1人で数日でまともな物が作れます。それと比べて決済APIの抽象化は茨の道なので専門家を何人も集めて何人月も使う事になります。将来的に本当に他の決済APIを使う必要に駆られたとして、その時にゼロから設計すれば良いのであって、そこで数日で書いたコードすらひと思いに捨てられないのであればその時はあなたのプロジェクトは技術的負債なんかよりよっぽど悪質な病魔に蝕まれています。 そもそも、世に出る9割以上のサービスは収益化できずに撤退するのですから決済APIなんて細部ではなくてサービスの価値を最大化する事に集中する方が合理的です。