💧

生成AI時代にAtCoderをやる理由: 水色データサイエンティストが得た4つの学び

に公開

はじめに

rateの変遷

自分自身がデータサイエンティストと名乗って良いのか自信はないものの、以前は名刺に「データサイエンティスト」と書いてあったことを免罪符にしたい redtea です。

AtCoder という競技プログラミングコンテストをご存じですか?とても有名[1]ですし、この記事を開いてくださった方のほとんどがご存じかと思いますので、説明は概要だけに留めます。競技プログラミングとは、AtCoderでは以下のように説明されています[2]

決められた条件のもとで与えられた問題、課題をプログラミングを用いて解決し、その過程や結果を競うものを競技プログラミングといいます。
様々なジャンルの出題がされますが、プログラミングや思考力、数学力、知識を活用します。

細かいルールはいろいろありますが、アルゴリズムに関する問題が出題されるので、競技者としてはできるだけ速く動くコードを、できるだけ迅速に・正確に実装するのみです。シンプルで良いですね。

https://atcoder.jp/

今回は長くお世話になっている AtCoder の algorithm 部門で入水[3]を達成しましたので、記念にredtea[4][5]の AtCoder での学びを整理したく、筆を取りました。 なお、水色コーダーのレベル感はAlgorithm部門のレーティングと業務における期待できる活躍
で説明されています。

生成AI時代のプログラミング

2025年5月現在、AtCoder のABCコンテストとARC Div.2 コンテストでは、生成AIの使用は原則禁止されています。このルールが制定された背景は言わずもがなですが、生成AIの技術向上です。例えばABCコンテストにおいては生成AIでかなりの高得点をたたき出せてしまうのです。

https://x.com/ymatsux/status/1865396091690381482

こちらの投稿によると、2024年の12月時点の、OpenAI o1 Pro でF問題まで解けてしまっています[6]。ABCコンテストでは、A~Gの問題が出題され、基本的にアルファベットが進むほど難しい問題となりますので、ほとんど解けている状態と言って良いです。この投稿から月日は流れ、o3やo4-miniClaude Opus 4 等が登場し、FやG問題ですら安定して解けるのではないかと思ってしまうくらい、生成AIのコーディング力向上は留まるところを知りません。

こうなってくると、人がキーボードをタイプしてコードを書く意義はあるのか、という論争になります。1つの意見として、

  • AIが生成したコードの正しさを確認できるのは人間であり、修正・レビューする能力が求められる
  • 解くべきビジネス課題を分解し、AIに指示するためのソフトウェアへの理解が必要

という感じで、プログラミング能力は必要だと考えています。

これら観点ももちろん重要ですが、本記事では特にエンジニアとして普遍的に重要だと私が思っていることについて書きます。


それでは、以下の学びについて、1章ずつ設けて説明していきます。

  • コードのボトルネックが掴める
  • 爆速実装を意識できる
  • 技術的謙虚さは武器になる
  • モチベーションの維持向上

コードのボトルネックが掴める

AtCoder で得られる能力といえばやはりアルゴリズム力でしょう。競技プログラミングを始めてから知ったアルゴリズムは本当にたくさんあります[7]。当然アルゴリズムというのは知らなければ使えませんし、知らないアルゴリズムを読み解くのは厳しいです。素養のある方ならば、知らないアルゴリズムを車輪の再発明できるかもしれませんが、基本的には難しいです。生成AIに書いてもらうにも、明示的にアルゴリズムを指定しなければ書いてくれないようなアルゴリズムも多いと思っています。とにかく、アルゴリズムは知っていなければ使えませんし、検証もできません。

データサイエンティストの視点でも、高速な処理が書けることは強みになります。データサイエンティストは、統計モデルや機械学習モデルと戯れる時間よりもむしろ、データの前処理や加工をやっている時間がかなり長いです[8]。こういった前処理を高速に・正確にできなければ、それがボトルネックになりかねません。さらに、データ分析をやっていると統計や機械学習だけでなく、アルゴリズムで分析を処理する場合も多いです。データサイエンスって守備範囲が広いですよね。

最後に、アルゴリズムを知っていることはもちろんコードレビューの時にも役立ちます。生成AIがコードレビューすれば良いという人もいますが、現状人手のチェックは必須であり、そのチェックをする人がアルゴリズムに詳しいということは心強いはずです。なお、高速化が不要なときに、マニアックなアルゴリズムを提案するのはアルハラ(アルゴリズムハラスメント[9])なので止めましょう。

爆速実装を意識できる

AtCoder の100分間[10]を死に物狂いで取り組んできた人たちは、実務で生成AIを使おうが使わまいが、爆速で実装するんだ、という強い意識が芽生えているはずです。それは何もアルゴリズムの実装に限った話ではなく、例えば、

  • このデータのこの可視化、5分で書く!
  • 営業さんからのこの依頼、昼休みまでに返す!

みたいなノリです。1分1秒を争ってコーディングしている競プロ勢[11]にとって、5分あれば書ける処理は結構多いです。生成AIを使っても良い実務であれば尚更です。このような短時間でも集中してアウトプットを出すんだという強いハングリー精神は、AtCoder で鍛えられたと思っています。

技術的謙虚さは武器になる

AtCoder で出題される問題は必ずXX秒以内に解ける問題が出題されます。しかし、コンテスト中に高速化できずにTLE[12]になったり、解けると思った問題がうっかりミスでWA[13]になったりした経験は数知れずに違いありません。そんな苦い経験から導き出される事実は次の通りです。

  • 自分の力では高速化できないが、世の中の技術で高速化できることがたくさんある
  • 単純な実装でもバグを書いてしまうことがある

これらは当たり前の話ですが、こういった事実を包み隠すことなく突きつけてくれるのが AtCoder です。この事実を受け入れ、謙虚にならなければなりません。そうすれば、

  • 自分は高速化を思いつけないけど、生成AIや優秀なXさんに頼ればこの部分は高速化できるかもしれない
  • コードにはバグが含まれているはずだ、ちゃんとテストコードを書いて残そう

という強かさ、丁寧さ、につながっていきます。

実務では(XX秒以内に)解けるかわからない問題を解くことになります。「実務上のこの問題設定に無理があるんじゃないかなぁ~」って思いたくなることもあるかもしれませんが、ほとんどのケースで不可能問題[14]を相手にしているからではなく、自分の実力が足りないだけです。それを教えてくれたのは AtCoder であり、そして、それを知っているエンジニアは強いです

モチベーションの維持向上

AtCoder をやっていると、興奮と絶望を感じることがあります。Rating システムは無常にも現実を突きつけてきます。それは、自分は競技者の中で上位X%までこれたんだという矜持であったり、今まで自分が出した最高パフォーマンスを大きく上回るパフォーマンスを出し続けても、決して届かない存在への羨望に似た絶望であったりします。生存バイアスかもしれませんが、特に後者は競技者を奮い立たせます。

Rating が下がった!AtCoder なんて辞めてやる!

って言っている人ほど来週もコンテストに参加しているものです。

みなさんの職場にもきっといらっしゃるであろう圧倒的強者の存在[15]は、技術的な学び以上にモチベーションの維持向上に大きな役割を持つことはエンジニアであれば分かってもらえることだと思います。それと同じことを、AtCoder の定量的な Rating システムが提供してくれます。

結び

あたかも生成AIがあればアルゴリズム力を含むプログラミング能力が不要になるかのような言説を耳にすることがありますが、私はそれに賛同できません。生成AIが一発で動くコード生成してくれたとしても、実務では必ずコードに修正が入ります。もちろん修正も生成AIでできますが、複雑なアルゴリズムをよくわからないまま修正されたコードを顧客に提供できますか? 生成AIが書いたコード全体を見て、ここがボトルネックになる、ここにバグがある、と見抜いたり、確認したりする能力は今後も必要です。そして、これはあえて断言しますが、「プログラムは書けないがバグやボトルネックを見抜く能力だけはある」という状況はあり得ないと思っています。とにかく書けることが一番深い理解状態です。

本記事では全体的に、AtCoder は実務で役に立つと主張する表現が多いですが、私の AtCoder への基本スタイルは楽しいからやる派です。特に最近の実務では、pytorchLangChain に代表される抽象化の進んだ[16]ライブラリを用いる実装やtabキーの連打[17]が多く、プログラミングを楽しむ場が減ってきているようにも感じています[18]。ひょっとすると AtCoder で得た一番のものは、エンターテイメントとしてのプログラミングだったのかもしれません。

脚注
  1. 少なくとも私の周りではみんな知ってます(みんなとは?)。 ↩︎

  2. https://info.atcoder.jp/overview/about/competitive ↩︎

  3. 物騒な表現ですが、AtCoder 界隈では水色ランクに到達することを入水と言います。 ↩︎

  4. red の名に恥じないためには赤コーダーにならないと!? ↩︎

  5. AtCoderでのユーザー名は redtea ではありません。私は redtea という名前を使い始める前から AtCoder に登録しており、AtCoderではユーザー名の変更を推奨していないので、そのままにしています。 ↩︎

  6. 私はF問題を解けたことがないので、完全に生成AIに負けています。 ↩︎

  7. 私がAtCoderを始めて一番最初に知ったのは Union Find 木でした。 ↩︎

  8. 所属する組織や文化によって違うかもしれませんが、少なくとも私が経験した現場ではそうでした。 ↩︎

  9. Google で検索してもこんな言葉はでてきません。私が適当に思い付きで書いたアルコールハラスメントとかけたネタです。 ↩︎

  10. 私はABCしか参加したことがありません。 ↩︎

  11. 競技プログラミングをやっている人をこう表現することが多いです。 ↩︎

  12. 実行時間制限超過。 ↩︎

  13. 不正解。 ↩︎

  14. 問題設定が本当に悪いなら、問題を言い換えたり、設定しなおすことができるのも実力というものです。 ↩︎

  15. あなた自身が圧倒的強者である可能性も高いです。 ↩︎

  16. この抽象化の恩恵に大きくあずかっています。 ↩︎

  17. GitHub Copilot などのツールのことです。 ↩︎

  18. 学生時代の課題でコンパイラを実装していたときの楽しさは今でも鮮明に覚えています。 ↩︎

Discussion