「競技プログラミング」とは、与えられた課題に対してプログラミングによって解答を導き出し、制限時間内の正答数や解答までの時間、プログラムの処理性能などを競う競技です。このような競技プログラミングや、そこで必要とされるアルゴリズムに関する知識は、開発者としての業務スキルや開発者体験とどのような関係があるのでしょうか。
本記事では『Developer eXperience Day 2024』（主催：日本CTO協会）における高橋直大（ちょくだい）氏によるセッション「アルゴリズムと開発者体験」の内容をお届けします。
高橋 直大（ちょくだい）氏
AtCoder株式会社 代表取締役社長
プログラミングコンテストを開催するサービス「AtCoder」を運営するAtCoder株式会社を2012年に起業。Google Hash Code 2022で世界2位など、プログラミングコンテストで長年好成績を残している。
AtCoderの高橋です。ネット上では「ちょくだい」という名前で活動しています。よろしくお願いします。
今回の講演は「アルゴリズムと開発者体験」ですが、アルゴリズムと開発者体験には何も関係ないのでは？ と思っている方が多いのではないでしょうか。関係あります、というのが今回の講演です。
注意点として、本講演における「アルゴリズム」の使い方は一般とは少し異なり、競技プログラミング文脈での「アルゴリズム」について取り上げます。機械学習などの要素はあまり含めずに用いていますので、この点はご了承ください。
今回のお話は、
- 近年急増する「アルゴリズム人材」
謎の組織「AtCoder」が率いる集団「競技プログラマ」とは？ - 「アルゴリズム」が仕事に本当に必要か？
開発者体験を高めるために実は必要な「コーディングテスト」 - なぜ今更「アルゴリズム」なのか？
AI/機械学習ブームでなぜ古典的なアルゴリズム？
の3本立てでお送りします。
目次
近年急増する「アルゴリズム人材」
まずアルゴリズムとは計算の手順の話です。手順の選び方によって、計算や処理の効率が良くなったり悪くなったりします。
たとえばこのようなAからBまで行く最短経路を求める問題は、アルゴリズムを知らないとなかなか解くのが難しいです。うまく計算するとそれほど時間をかけずに解くことができます。たとえばカーナビなどでは、このような計算のより高度なものが行われているわけです。
最短経路問題のような問題が与えられ、それを解くプログラムを書いて競い合うのが競技プログラミングです。私はこの競技プログラミングの出身で、競技プログラミングを主催する会社を経営しています。
たとえば、弊社AtCoderでは6月1日から7月6日までの期間に12回のコンテストを開催していて、さまざまな企業様がスポンサードしてくださっています。AtCoderの登録者数も、現在日本・海外合わせて63万人ほどになっています。
こうした数字をみると、コンテストでプログラマが増えているのだと思いますよね。しかし、とても微妙です。ここで、業務と競技プログラミングについて話をさせてください。
競技プログラミングが得意な人というのは、私を含めてですが、アルゴリズムのコンテストができるだけです。高速で正確なコーディングや大規模なデータの扱い、計算時間の見積もりや削減は非常に得意です。そして、機械学習など未経験分野の習得も早い傾向にあります。
一方競技プログラミングをする人、つまり競技プログラマは学生も多いので、たとえばチーム開発やエラー処理、コードの保守などは未経験というパターンも多いです。これをプログラマと呼んでよいのか微妙ですよね。コンテスト経験がある方を開発経験豊富だと思って中途採用すると、問題が起こります。
先日、インターネット上で「競プロ出身者の使えなさは異常」という題の匿名記事が公開され、多くの方が閲覧していました。記事内容をみると、ほぼ確実に嘘か、もしくは誇張があります。とはいえ、一部の界隈で競技プログラマが悪く思われているのは事実です。競技プログラマを下手に雇うと、開発者体験が低下すると言ってよいでしょう。
では、競技プログラマは採用してはいけないのでしょうか。そうではありません。人を属性で判断すべきでない、というのが本講演の肝です。
このような場面で起こっているのは、ミスマッチです。たとえばアルゴリズムなど競技プログラミングの能力を活かす場面のない職場で競技プログラマを採用したり、人格面に問題があるにもかかわらず競技プログラミングの成績だけで採用したりすると、ミスマッチが起こります。
大事なのは、競技プログラマかどうかという属性ではありません。自分たちがどのような人材がほしいのかを考え、採る人材の基準を明確にすることなのです。
「アルゴリズム」が仕事に本当に必要か？
ここでは言い切ってしまいますが、開発者体験はメンバーで決まると考えています。メンバーが良いときの開発者体験は良いですし、その逆もしかりです。なお、性格などの人格的要素は面接でみることとし、ここでは技術的な能力についてのみ考えます。
たとえばメンバーの能力を図のようなレーダーチャートで表したとします。
このメンバーで行われる開発は、メンバーの能力を合わせた最大（右図の青）が扱える範囲となります。誰か1人でもその案件で求められるレベルに達していないと、業務を遂行することができません。逆に最小（右図のオレンジ）が共通認識として扱える範囲、すなわちつど説明をしなくともメンバー全員に伝わる範囲、となります。
これら最大や最小と、行う案件との乖離が大きくなりすぎると、開発者体験が低下します。最大との乖離が大きいと、メンバーがまったくわからない要件を扱うことになります。一方最小との乖離が大きいと、当たり前のことをいちいち説明しなければならない状況が発生し、とくにこちらの方が開発者体験への影響は大きいようです。
たとえば競技プログラマの中には「アルゴリズムは得意だけれどもGitが使えない」という人もいて、結果周りのメンバーがGitの使い方という共通認識を説明しなければならず、開発者体験が悪くなります。
では、理想的なメンバーとはどのような状態でしょうか。
それぞれが何か得意分野を持っていて、かつ最低限ここは守りたいというラインを皆が持っている状態、これが開発者体験が良い状態です。このライン＝当たり前を維持できるように、教育によって能力を引き上げたり、当たり前のレベルをキャッチアップする意思のある方を採用することが大切です。今の能力が仮に足りなかったとしても、当たり前を守ろうとしてくれる人・伸びそうな人は採用すべきですし、反対にその気がなさそうな人であれば採用すべきではありません。
開発者体験はメンバーだけで決まる？
ここまでメンバーの話をしてきましたが、ほんとうに開発者体験はメンバーだけで決まるのでしょうか？
さきほどのレーダーチャートで、メンバーが扱える範囲と共通認識の範囲について説明しました。
これは開発者にもよりますが、自分の能力ギリギリのところで開発ができる案件だと、開発者体験が良いと言えるでしょう。できて当たり前の案件だけでは楽しくありません。
しかし実際の案件は、図中の灰色のように扱える範囲の中に余裕をもって収まることが多いです。扱える範囲ギリギリや越えている案件は、要件定義において機能を落とすなどの決定がなされます。デスマーチになってしまう危険があるので。そうなると、能力ギリギリのおもしろい要件が残るわけありませんよね。
エンジニアの幸せはプログラムを組むことだ、と考えている方もいると思いますが、自分にとっておもしろい案件に取り組んで開発者体験を良くするためには、要件定義にがっつり入っていくべきです。
エンジニアの採用とコーディング試験
さきほども出した最短経路問題のようなアルゴリズムを問う試験、採用面接で行われることがあると思います。これ、皆さん求めてますか？ コーディング試験でアルゴリズムを出して、自分たちが求めている能力を計れますか？ ここをよく考える必要があります。
計る必要があるのは、文化に合うか、つまり共通認識を共有できるかどうかです。個々のアルゴリズムを知っているかどうか、ではないはずです。
コーディングスキルの有無を計りたい、という意図はあると思います。もしそうなら、アルゴリズムや計算量はむしろ問わない方がいいでしょう。計算の改善は不要だけれども大きく複雑な課題を出せばいいはずなのに、なぜか皆競技プログラミングを真似してアルゴリズムの課題を出してしまいます。
思考の過程を説明してもらうための題材として使うのであればわかります。しかし、単純にアルゴリズムを問う問題を出すと、当然競技プログラマが面接を通過してしまうので、ミスマッチが起こります。これは問い方が間違っていますよね。
オススメは、A4用紙2枚程度の仕様をもとにたくさんコードを書く課題を出し、実装速度をみることです。その際、必ず「可読性など、実際の開発を意識したコードを書いてください」と伝えてください。伝えたうえで、それでも実務を想定していないコードを書いていれば不採用とします。
課題の意図を伝えずに面接をするのは採用側に問題があります。
なぜ今更「アルゴリズム」なのか？
ここからは、AIや機械学習がブームとなっている今、なぜ古典的なアルゴリズムなのかについて話をします。
そもそも、なぜ皆が生成AIの話をするのか。それは、これまでできなかったことができるようになるからです。未解決の課題を解決できるのは楽しいですし、開発者は皆やりがいのある仕事をしたいと思っています。
では、アルゴリズムでの開発は、現在もワクワクの対象なのでしょうか？
最近も高度なアルゴリズムを用いた開発事例があります。液化天然ガス基地での運用効率化や、無人で車を動かし無人でダムをつくるプロジェクトがあったりもします。
こうした事例の中で扱っているアルゴリズムは、たとえば焼きなまし法など1900年代からあったものです。
これは、DXの流れがある中で、いろいろなものがデータとして扱えるようになったのが要因です。今までアルゴリズムはあるけれどもデータがなくて最適化できないものがありました。そこからデータが増えることでどんどん最適化が進んだ、という面もあります。
そして、今流行っている機械学習や生成AIというのは、万能ではないんです。
これは人工知能学会の出しているAIマップです。
ここに挙げられているもののうち、半分ほどが機械学習でできること、半分ほどは古典的アルゴリズムでできること、です。この組み合わせが強いんですね。
古典的アルゴリズムは、データが増えることでその真価を発揮します。
世の中の情報はデータ化されていて、これまで文字だけだったものが、機械学習によって画像や音声も処理できるデータになりました。データが増える、つまり計算できる要素が増えることで、それらを扱うアルゴリズムも活きてきます。
ここで1つ皆さんに質問です。アルゴリズムなどを使って、コンビニを便利にするアイデアを考えてみましょう。できる限り凄いものを考えてみてください。
たとえば私の考えたものは以下です。
- 肉まんを思い浮かべると
- それを察知したコンビニが虚空から肉まんを召喚する
- おいしい！
これは理想ですね。しかし、おそらくみなさんはこのような案を思い浮かべません。なぜか。これらが、コンピューターにはできないことだと知っているからです。
現状のコンピューターで当然できることと、魔法でないとできないことがあります。
これらの間に高度な技術があり、ここを扱いたいわけです。ただ、普通の人がコンピューターでできると思っていることは実は古くなっているんですね。2000年くらいで止まっています。
さきほどの、肉まんを虚空から召喚する理想のコンビニは問題があやふやで解けません。
しかし、理想の少し手前のコンビニとして以下ならできそうです。
- タブレットでサジェストされた肉まんをクリックする
- ドローンがコンビニから肉まんを届けてくれる
- おいしい！
これらはコンピューターでできることを組み合わせて実現可能です。
このように、理想とする状態をアルゴリズムの問題として発見し、コンピューターで計算できることを組み合わせて解決できる人が必要とされています。
コンピューターと魔法との間を考えさせたい、と思ったときに、現代の知識、最新のものを知っているのがベストです。こうした場に来ている皆さんは最新のものを知っている方々ですが、一般には難しいことです。
そこで、みんなに夢想させましょう。魔法のような「こんなのできないと思うけど」ということを考えてもらうのです。それによって、新しい高度な技術を扱える案件を引き出すことができ、やりがいのある仕事にかかわれるでしょう。
取材後記：開発者がワクワクする未来へ
アルゴリズムと開発者体験という一見関係がないように思われがちな両者について、競技プログラマと採用・メンバーの能力と開発者体験・AI/機械学習とアルゴリズムの共存など、さまざまな切り口からお話しいただきました。
現在は機械学習やAIなどが流行っていますが、以前から存在するアルゴリズムもともに重要です。開発者がやりがいのある仕事をして、未解決の問題を解決し、世の中を良くしていく。そうしたワクワクする未来へと目を向け、進んでいきたくなる講演でした。
（撮影／文：伊藤由貴）
