【ちょくだい】競プロer採用のミスマッチが起こる理由と、開発者体験が高いチームのつくり方【Developer eXperience Day 2024 レポート】

日本CTO協会が主催する、開発者体験をテーマとしたイベント「Developer eXperience Day 2024」が、7月16日、17日に開催されました。

本レポートでは、7月16日に行われたちょくだい（高橋直大）氏の講演「アルゴリズムと開発者体験」でのお話を再編成してご紹介します。

ちょくだいさんが思う、「アルゴリズム」や「競技プログラマー」と、開発者体験の関係とは？

• keyboard_arrow_down 独自の知識を持つ競技プログラマー。「競技プログラミングは役に立たない」と言われる背景
• keyboard_arrow_down 開発者体験が高いチームづくりに「競技プログラマーの一括採用」が生きるかも
• keyboard_arrow_down アルゴリズム×機械学習で、魔法を現実に。難しくて面白い案件を引き寄せる方法

ちょくだい：今日は「アルゴリズムと開発者体験」というテーマで話します。

• ・競技プログラマーとは
• ・アルゴリズムと仕事の関係
• ・AI、機械学習ブームの今なぜ古典的アルゴリズムが重要なのか

以上3つのテーマをお話していきますね。

今回は競技プログラミング文脈における「アルゴリズム」のお話であり、機械学習とかの要素があまり含まれていない場合がありますので、この点はご了承ください。

まず一つ目、「競技プログラマーとは」の話です。

そもそもアルゴリズムとは何なのか？皆さんご存知だと思いますが、一応説明します。アルゴリズムとは基本的に、計算の手順などを指します。手順の選び方によって、効率が良かったり悪かったりする。この人参の例は、情報学研究所が出してるものですね。

ちょくだい：メジャーな例では最短経路問題というのがあります。

AからBに行くのにどのくらいかかるでしょう？アルゴリズムを知らないと、なかなかうまく解けない。アルゴリズムを使ってうまいこと計算すると、そんなに時間がかからず解くことができる。これのもっと高度なものが、身近なところだとカーナビなどに使われていたりします。

ちょくだい：競技プログラミングというのは、こうしたクイズをプログラムで解き、自動採点して競い合うものです。例えばHeuristic型コンテストでは、答えのない問題に対して色々な回答をして効率いいものを探したりします。

例を挙げましょう。この例題では、パネルを踏んでいってできるだけ多くの点数を集めていきます。制限時間は4時間で、時間内で最適解を追求する、という問題です。

ちょくだい：詳細は省略しますが、これはプログラムの出来によって、以下のように結果が大きく変わります。

ちょくだい：一番左が、比較的成績の低い人。真ん中が平均的な、と言っても世間一般では十分凄腕プログラマーと言える人ですね。一番右は化け物。制限時間4時間に対して、実行時間2秒程度でこういう解を出しちゃう化け物の競技プログラマーもいます。

コンテストが開かれる頻度も高まっています。直近、2024年の6月だけでも11回開催されました。そしてAtCoderの登録者数も、2024年の2月には60万人を突破しました。

すると「競技プログラミングの普及で、優秀なプログラマーが増えるんだ！」と期待感を抱くじゃないですか。しかし実際は、とても微妙です。

業務と競技プログラミングの話をさせてください。結局、僕を含めた競技プログラマーというのは、アルゴリズムのプログラミングコンテストでいい成績が出せるだけなんですよ。

得意分野としては、高速で正確なコーディング、大きめなデータの扱い、計算時間の見積もりや削減。このあたりはめっちゃ強いです。そして、機械学習など未経験分野の習得速度も速い傾向があるし、総じて「頭がいい」と感じる部分もあります。

ちょくだい：しかし、競技プログラマーには学生も多いので、チーム開発の経験がない場合も多い。するとエラー処理やコードの保守運用、セキュリティ対策など、チーム開発に必要なスキルセットを持っていないわけです。

ちょくだい：新卒であれば、競技プログラマーであるか否かに関わらずこのあたりのスキルセットが揃っていないことが多いので、採用しても育成していけばなんてことはない。ですが、特に中途採用で、コンテスト経歴の輝かしさに目がくらんで、チーム開発のスキルを問わずに「経験豊富なエンジニア」だと思って雇っちゃうと、大惨事が起こります。

その結果がこちらです。

ちょくだい：先日出たはてな匿名ダイアリー。「競プロ出身者の使えなさは異常」、こんな記事が出ています。670ユーザーがブックマーク。内容としては、競プロに傾倒してるだけの人のコードはひどい、などと書かれてしまっています。これはまさに開発者体験の低下です。

記事自体は、ほぼ確実にデマか誇張があります。記事中に「インフラの人にレッドコーダーが2人いる」と書かれていますが、レッドコーダーの日本人は63人しかいない。その中の2人が全く同じ会社、部署で働いているとは到底考えづらいですから。

とはいえ、はてブの反応やレスポンスを見ると、不評を買っているのは事実です。これは「一部の競技プログラマーを採用することで、開発者体験が低下している」と言っていいと思います。

ちょくだい：じゃあ競技プログラマーを採用しない方がいいのか？そんなわけがない。

こうした評判の背景には、色々なミスマッチが起こっています。例えばSEの特定の現場など、競技プログラマーが持っているアルゴリズムのスキルが必要とされない場で採用してしまったとか。また、レートが高いからと人格面に目を瞑って採用してしまい、その人がチームを荒らしてしまった、というのもよく耳にします。これでは、競プロへの不評が高まってしまうのも納得です。

競プロ人口は、今となっては1学年ごとに日本人で約3000人います。これを採用しないようにするのも変な話だし、活躍してる人の方が多いので、属性だけ見て判断するべきじゃない。大事なのは、個人のスキル感として、どういう人材が欲しいのかといった基準をしっかり固めることです。

そして一応言わせていただきますと、今日は冒頭から「競技プログラマーへのディスり」がめちゃめちゃ入っています。でも競技プログラマーのコミュニティーでは「月刊・競技プログラミングは役立たない」という、業務でのプログラミングと競技プログラミングを混同しているブログ記事を見つけては温かい目で見守る文化がありまして。だいたい月1でそうした話題が流れてきて、みんな盛り上がる。1年やってたら、その流れを10回以上見ています。

つまり「競技プログラミングはいかに開発ではないか」を、競技プログラマーはみんな見てきているので、8～9割は謙虚な人々です。1～2割、勘違いしちゃった人がいて変なことになっているんだと思うんですけど。採用したい人が前者か後者かをしっかり判断するために、これから話すことを参考にしてもらえるとうれしいです。

ちょくだい：では、開発者体験の高いチームをつくるために、採用や育成において重要な要素は何なのか？といった話をしますね。

あえて言い切りますが、開発者体験はメンバーで決まると思ってます。メンバーがいいときは開発者体験はいいし、そうでなければ開発者体験も悪い。これ以外の要素もあるでしょうけれど、相関はかなり大きいと思います。

今回は、メンバーの人格要素は面接で見極めるものとして、一旦能力の話をしますね。一例として、メンバーの能力のレーダーチャートをつくってみました。

ちょくだい：左側が、あるチームのメンバー3名の能力を示すレーダーチャート。右側はそのチームで行われる開発で必要な能力を示すレーダーチャートです。右側青線の「扱うことが可能な範囲」とは、メンバーの誰か1人が、その能力に達していれば業務を遂行できる範囲。その内側にあるオレンジの小さな五角形は「共通認識として扱える範囲」です。これは、わざわざ中身を説明しなくてもメンバー全員に伝わる範囲。

つまり、開発者体験を考えた上で、扱える案件の範囲はメンバーの能力のmaxで決まります。これは、得意なメンバーに担当してもらえばいいから。

一方、メンバーの共通認識としてわざわざ説明しなくていい範囲は、minで決まる。メンバーそれぞれの最も苦手な部分に合わせなくてはいけないからです。

担当する案件と、これら五角形の乖離が大きくなりすぎると、開発者体験が低下します。maxよりも高いレベルを求められると、わからないことだらけでつらいし、minの範囲が小さすぎると、全部いちいち説明しなくちゃいけなくて開発が進まない。

では理想的なメンバーの揃え方とは？おそらくこんな形になるでしょう。

ちょくだい：メンバーそれぞれが異なる得意分野を持っている上で、全員が守るべき最低限のラインはある程度高めに設定できている。この状態であれば、めちゃくちゃ開発しやすくなります。

得意分野がばらけていれば、仕事を分散できるし、各人がやりがいを持って取り組めて、メンバー同士の学びもある。そして、共通認識として持てる領域が広ければ、説明コストが減り、その分開発にコストをかけられます。極論ですが、競技プログラマーを何人か一気に採用して1つのチームをつくれば、「アルゴリズム」に関しての共通認識がめちゃくちゃ広いチームをつくることができますよね。

そのうえで大切なのは、人を増やしても「共通認識として扱える範囲」をキープすること。そのために教育や研修などで、社員のレベルを引き上げたり、この基準に届かない求職者はスクリーニングで弾いたりしなくてはなりません。

では、この場合はどうでしょう？この人の今の能力はオレンジの線くらいです。青の線が「うちではここまで分かっていてほしい」という採用基準です。採用するべき？しないべき？

ちょくだい：こうした場合は、将来を予測しなくては判断できませんよね。

ちょくだい：左側の人は、採用すべきです。入社までに足りないスキルをつけてくれそうだったり、足りない部分に課題を感じているのがにじみ出てるといった、青い線を守ろうとしてくれる人。逆に、右側の人は採用すべきではないです。左上の尖った能力はガンガン伸ばしていきそうだけれど、青い線に足りない部分は全然勉強しなさそうな人。

元の能力が足りないことは問題ではありません。特に新卒エンジニアなんて、どの能力も足りないのですから。この青い線、守るべき「当たり前」のラインを将来的にちゃんと維持できる側の人間になれるかが重要。これが維持できない側になると、一生お荷物になるわけですね。

そして、何を「当たり前」とするかが企業文化だと僕は思います。これは技術なのか人柄的なのか、色々な要素があるはず。この「当たり前」を最初から持っている人だけを採用するわけではなく、足りない部分は社内教育で補えるかどうかを判断して採用するべきです。

ちょくだい：では、開発者体験はメンバー「だけ」で決まるのでしょうか？

先ほどの「扱うことが可能な範囲」と「共通認識として扱える範囲」の図で見てみると、実際に行われる開発は灰色で示したライン。青で示した「扱うことが可能な範囲」の内側に入っていることが多いです。

ちょくだい：灰色の「実際に行われる開発」がどんな形だったら、開発者体験がいいと言えそうでしょうか。

人によりますが、僕は個人的に、案件は自分たちのできるレベルよりも少し難しい方が楽しいと思うんです。できることを淡々とやるよりも、自分たちの能力のギリギリ、これができたらすごいなと思ったものが開発できると嬉しいなと。

メンバーが皆そうした挑戦的な案件を好むチームで、この灰色のラインの開発を行ったとします。実は、最終的にできあがったものが灰色のラインだっただけで、元々の顧客の要望はもっとレベルが高かった、という場合も多々ありますよね。

ちょくだい：なぜそうなるか。自社開発か受託かなど事業形態によって異なりますが、多くの場合、要件定義において「できなさそうなこと」ってあまり盛り込まれないんです。なぜなら、できるかわからない状態で「やります」と言ってしまうと、後々とてもつらくなるから。つまり「ちょっと難しい、けれども面白い要件」が、実際に開発に乗ることはそんなに多くない。

例えばチームメンバーにアルゴリズムが好きな人がいるものの、PMとして要件定義に関わる人にはアルゴリズムの知識がそこまでない、とします。多くの場合、そのPMが把握しきれる範囲に要件をまとめていく傾向があるので、アルゴリズムを扱う案件が降ってくる可能性はかなり低い。アルゴリズムを使った開発は、開発期間が多少延びれば必ず完成させられるわけではなく、「できるかどうかわからない、できたらうれしい」という類のものなので、要件定義をする人たちが「できる、つくれる」と確信を持ちづらく、案件に乗らないんです。そのせいで、完成したシステムは、元々の顧客の要望よりもかなりコンパクトになってしまうし、アルゴリズムが好きなメンバーにとっては「チャレンジングでなく、楽しくない開発」になってしまう。

こうならないようにするには、要件定義からがっつり入り、面白そうな課題を掴むしかありません。専門家の少ないアルゴリズムの分野は特に、です。エンジニアの幸せの1つが「プログラムを組むこと」ですが、何を組むかを自分で決めていかないと大したものはつくれませんから。こういう意識をちゃんと持つように競技プログラマーたちを育ててほしいなと思っています。

ちょくだい：最後の話題です。AI、機械学習ブームのこの時代に、なぜ古典的なアルゴリズムに注目するのか？といった話をします。

僕が今こそアルゴリズムに注目するのは、今注目が集まっている生成AIや機械学習は、それ単体で万能なものではないからです。これらをアルゴリズムと組み合わせると、飛躍的な成果を生み出せます。

ちょくだい：将棋のAI、皆さんご存知ですよね。プロに勝てるAIをつくることができたのは、実は機械学習の力だけではありません。

機械学習では、今の盤面が何点であると点数をつけたり、盤面から次の手を予測したりするのですが、これだけではアマチュアの有段者レベルだと言われています。1年前くらいに調べた情報なので、最新の情報と違ってたらごめんなさい。

一方、画面右側の「探索アルゴリズム」では、相手の打ち手を効率よく予測することができます。古典的な手法ですが、点数の付け方が機械学習よりもずっと雑でも、アマチュア有段者レベルには戦えます。

この2つが合わさり、機械学習で精度高く盤面の点数をつけ、その点数をもとにアルゴリズムで効率よく手順の探索を行うことで、プロに圧勝できるようになったんです。

データとして評価できるものが増えれば増えるほど、古典的アルゴリズムが火を吹きます。

最短経路問題もその1つです。データが何もなかった時代は、単純にAとBの2点間の距離を、平均速度で割り算して時間を計るだけ。それが現代では、道が分かっているのはもちろん、制限速度、天気や渋滞の情報など、データが増えたから、単純な最短経路だけでなく色々なパターンのルートを探索することができます。

ちょくだい：現代では多くの情報がデータ化され、今まで文字だけだったのが画像や音声も機械学習で扱えるようになりましたね。データで表現できる情報が増えたので、アルゴリズムで扱える領域が広がった。

では、アルゴリズムを生かして生活をさらに便利にするとしたら？　コンビニを例に挙げましょう。できる限りすごいものを考えるとしたら、何が思い浮かぶでしょう。僕の考えたのはこれです。

ちょくだい：肉まんを思い浮かべたら、それを察知したコンビニが虚空から肉を召喚します。そして食べる、おいしい！　…でもこんなこと、コンピュータでできるわけありませんよね。家で欲しいものを考えてもコンビニには伝わらないし、虚空から肉まんを取り寄せる技術は存在しません。

妥当なものとしては、無人店舗や仕入れ量の調整、おすすめ商品のレコメンドなどだと思います。ただ、ちょっとこれでは発想が古い。

僕は「技術と魔法」という考え方が好きで。

ちょくだい：画面左側、コンピューターでできるのは、売上や在庫の管理などです。画面右側、魔法でないとできないのは、虚空から商品を生み出すこと。

この2つの間に、最近の高度な技術なら、そして人間ならできること、があります。例えば、手に取った商品が何なのか認識するとか、需要に合わせた商品を入荷するとかですね。

そして、この「高度な技術でできること」についての認識が、2000年より前のところで止まってる。魔法だと思われていることの中にも、最近の高度な技術を組み合わせて応用すればできる場合もあるはず。

プログラムは「入力」「出力」「評価」の3つがあればいい。この3つを揃えられれば、現実的にできるアイデアが固まっていくでしょう。

例えばさっきの「理想のコンビニ」の例にこの観点を加えると、こんな感じ。

ちょくだい：サジェストされた肉まんをクリックしたら、ドローンが届けてくれて、食べて、おいしい。「入力」「出力」「評価」の要素は、それぞれ次のように付与できます。

ちょくだい：こうして、魔法だと思っていたことも、プログラムの「入力」「出力」「評価」の3要素を付与すれば、現実的に実現可能なアイデアに落とし込むことができます。

データとして扱える情報が増えている昨今、それを生かしてさらに便利な世の中をつくっていくために、このように「魔法」を「現実」にする方法を考えていく。すると、新しい高度な技術を扱う挑戦ができるようになり、開発が楽しくなる。こうした動きも、開発者体験向上の糸口になるかもしれません。

以上で僕の講演は終わりです。皆さん、ご清聴どうもありがとうございました。

編集：光松瞳