とある競技プログラマーの 1 年

お久しぶりです。riano_ です。estieに入社して 1 年と少し経ちました。

入社時にこのような記事を書かせていただきましたが、Web 開発をしたことのなかった競技プログラマーが、実際この 1 年でどのようなことを経験し、何を感じたのかを書いてみようと思います。

さて、あらためて簡単に自己紹介させていただきます。僕は大学院で修士まで理論物理の研究をした後、新卒でハウスメーカーの営業職に就き、2年ほど勤務しました。その最後の 4 ヶ月くらいで競技プログラミングを始め、それをきっかけに機械学習系のスタートアップへ、そして現職へと至りました。この時点で「なぜ？」という点がいろいろありそうですが、一旦置いておいて、要するにプログラミングについていえば

26歳で始めた
競技プログラミングと、多少の機械学習しか経験がない

という状態でのスタートでした。

結論から言いましょう。estie での仕事はめちゃくちゃ楽しいです。ありがたいことに、良い評価もいただいています。そして、同じような人にぜひ入社してほしいと強く思っています。

競技プログラマーはどう活躍できるのか？

まずとにかく、実装が速い、そして思考が速いというのが何よりも大きな価値だと思います。

これは僕個人の考えですが、プログラミング（あるいは知的作業全般かもしれません）においては個々人の能力差というのは意外なほどに大きいです。例えば、100m走であれば、一般的な成人男性が走っても世界記録の 2 倍の時間はかからないでしょう。しかし、プログラミングではそうではありません。競技プログラミングで言えば、僕が初めて出た AtCoder のコンテストでは ABC の B 問題を 30 分かかって AC しました。水色になった頃には、5 分もあれば解けるようになっています。今では、B 問題を解く速度はそう変わりませんが、ABC の E,F 問題を解く速度はその頃の倍以上にはなりました。そしてさらに上を見れば、今の自分がどうやっても全完できないセットを、50 分で解き切ってしまう人もいるのです。

少し脱線してしまいました。言いたかったのは、プログラミングにおいては個人の能力を、信じられないレベルで上げられる可能性があるということ、そして、この能力差は課題が複雑になればなるほどより鋭敏に効いてくるということです。

estie でも、お客さまの要望により、やや複雑な、あるいは論理的な難しさのある仕様を実現したい場面があります。そのようなご要望を叶えるため、そしてプロダクトとしての価値を高めるため、どのようにお客さまのデータを、つまり建物、床、募集、営業活動記録を、整理して保持するのが良いでしょうか。どのようにすれば、これらの相互作用（つまり建物が建ち、空室が生じ、募集が行われ、引き合いがあり、営業活動がある、その一連の流れ）をスムーズに表現し、必要な時に必要な切り口で情報を提供できるでしょうか。

そこには、現実に行われる複雑な事象から、できる限りシンプルな本質を見抜き、整理するという挑戦があります。その中に、とてもじゃないが解けそうにないと思っていた競技プログラミングの問題を、丁寧な考察で解きほぐし、シンプルな貪欲法とか DP とかに帰着した時の高揚感に似たものを ────── 感じるのは、僕だけかもしれませんが。

estie において、僕が主に関わってきたプロダクトでは、今年前半にそのような「データモデルの大きな変更」を 2 度経験しました。その片方を主導させていただいたのですが、不動産物件の状態の遷移をどう表現するか、といったような論理的な複雑さのある仕様を、丁寧に分解し、そして実行可能なタスクへと切り分け、整合性を確認して進めていく、という過程は、思考力を最大限活用して進めたものだと思いますし、またそのような変更を実際に短期間で実装し切るのは実装力なしでは実現し得なかったでしょう。

そしてもう一つ思っているのは、「倍の速さは、倍以上の価値を生む」ということです。

以前書かせていただいたこの記事でも触れた通り、圧倒的な速度は品質を高め、それによって更なる速度を産むための 1 つの出発点となり得ます。例えば、お客様が機能を使い始める期日より前倒しして機能を完成させれば、「導入時までに対応することが必須ではないがいずれは対応したい。しかし、利用開始いただいた後で対処するのは運用に支障がないように手順を踏んで改修する必要があり、大変になりそう」といったような課題を先回りして対処でき、お客さまへの提供期日を遅らせることもなく、結果的に将来必要になるであろう労力を削減することができます（これは 3 月に実際に実現したことです）。また、倍の速度で動ける開発チームの存在は、ビジネスチームの仮説検証を高速に、幾つも行いうる状態を作り出し、その反省を活かすことができればプロダクトの提供価値は実装速度の差異を超えた速さで成長していくはずです。例えるなら、年利 x% の複利と半年で x% の複利では結果として得られる利子には倍以上の差がつく、というようなものでしょうか（そしてその差は、利率が大きいほど、また周期が短いほど強烈な効果を生み出します）。

速さ以外にも、競技プログラマーに期待していることがあります。それは、実装者としてプロダクトの品質を保つことです。これは自分でも意外なのですが、普段仕事をしている中で、コードレビューや動作確認をしていて、バグや不自然な仕様を発見して未然に防ぐことが他のメンバーと比べても非常に多いという事実があります。

なぜそうなるのか、は分かっていないのですが、2 つ仮説があります。1 つめは、単に実装が速く、その分プロダクトの多くの部分に触れて仕様を理解しているということ、また実装した分動作確認も多く行うことになるので、バグに気づきうる機会が多いということ、つまり「速さ」からの帰着です。2 つめは、競技プログラミングにおいて、何度もコーナーケースに泣かされた経験から、特に条件分岐や想定外のケースといった部分において、こういうところはバグが起きそうだな、という感覚や疑う習慣が身についているのではないか、というものです。どれだけレートが上がっても（少なくとも橙では）、自信満々で提出した解法に WA や RE を叩きつけられ、必死にデバッグする作業からは逃れられません。それ自体は忌々しいことではありますが、その屈辱的な経験の数々は仕事をする上では役に立っているのかもしれません。

夢中で取り組むことが最良の経験

ところで、「実務でのアルゴリズム能力は大抵の職場で、水色でカンスト」と言われることがあります。estie においても、フローや遅延セグ木を書いたりすることは（自分の知っている範囲では）ありません。しかし、青色以上の能力を持て余すかといえばそうではありません。

正確に言えば、青色相当以上のアルゴリズム知識は、持て余すと思います。しかし、思考力と実装力はそうではありません。ここまで繰り返し述べた通り、速さとは、ビジネスを前に進めるための 1 つの強力な要素であり、思考と実装の速さにカンストという概念は存在しないからです。

そして、これはあくまで自分の場合ですが、そのような能力の断片を（まだまだ不十分ながら）身に着けることができたのは、「面白い」という純粋な興味に突き動かされて競技プログラミングに取り組んできたからだと思います。役に立とうが、立たなかろうが、夢中で何かに取り組む。そういった経験の中で磨かれた無形の能力こそ、最も自分自身の助けとなってくれるのではないでしょうか。それは別に競技プログラミングでなくても良いのですが、少なくとも競技プログラミングに夢中で取り組んだ経験のある方がその過程で身につけた能力は、とても価値のあるものだと思っています。

競技プログラミング以外で何を求めるのか？

ここまで「競技プログラマーは活躍できる」というような内容を書いてきましたが、一方で、競技プログラミングだけできても実務ができなきゃだめだ、という側面もあると思います（会社の採用基準としては、それは間違いなく正しいと思います）。しかし、「実務ができる」を単に「開発経験がある」と読み替えてしまうのは、とてももったいないことだと思います。（もちろん、経験に由来する知識が有用であることに疑いの余地はないと思いますが。）

estie には、様々な「プロフェッショナル」がいます。Rust の本を出版したエンジニアがいて、フロントエンドの経験を積んだエンジニアがいて、とことん頼りになるプロダクト責任者がいて、とんでもない熱量の営業がいて、確かな土台の上に大きな構想を築き上げる経営陣がいます。それは、自分がまだ知らない領域を任せられる人が、それだけいるということです。もちろん、任せっきりにするから永遠に知らなくていいのではなく、それらの人々から学ぶ姿勢を忘れないことは絶対に必要です。しかし、少なくとも最初から全てを知っている必要はないということであり、そして望めば必要な手助けを受けられるということでもあります。実際、自分は Web 開発未経験で入社しましたが、周囲からありがたい支援を受け、チームに貢献することができるようになりました。

そのような環境で期待されるのは、自分自身もまた得意分野を活かして、あるいは見つけ出して、「プロフェッショナル」になることです。僕の場合は、「複雑な課題をシンプルに解きほぐすこと」「それを圧倒的な速度で実装すること」はある程度入社前から自覚していた強みであり、実際にそれを活かせているのではないかと思います。一方で、仕事をする中で「バグの種を大量に潰すこと」「お客さま目線でフラットにプロダクトを眺められること」といった強みも見つかってきたと思っています（前者は競技プログラミング、後者はもしかすると営業経験によるものでしょうか？）。そのように、自分がどのような働きをすればプロダクトに最大の貢献ができるか、を考えることができる人であれば、きっと大いに活躍してくれるのではないかと思います。

つまり、これは僕個人の考えですが、