コーディング試験はなぜ重要かを真剣に考えてみた（ノンバイアス）
目次
はじめに
こんにちは。ハイヤールーの代表をしております、葛岡（@kkosukeee）と申します。この記事はアドベントカレンダー23 日目の記事です。
株式会社ハイヤールーではコーディング試験が簡単にできるための SaaS ソリューションを展開しています。本記事は弊社の宣伝ではなく、コーディング試験がなぜ大事かということを私なりにバイアスをかけず誰でもわかるように説明したいと思います。
本記事がこれからコーディング試験の導入を考えようと考えている人、コーディング試験の重要性について懐疑的な人にとって少しでも有益な情報となりますと幸いです。
そもそもコーディング試験ってなに？
コーディングテストはエンジニア採用において、候補者のプログラミングスキルやエンジニア知識、システム設計力、実装力などを問うテストです。エンジニアを採用する際によく実施される能力テストのようなもので、一般的にはアルゴリズムを解いてもらうコーディング課題、設計力をみるためのシステムデザイン課題等が一般的です。
ビッグテック等がコーディング試験をやっていることを元に、日本でも多くの会社が取り入れており、ホワイトボードを用いたものから、ウェブサービスを用いたものまで様々な選択肢があります。筆者の経験では、現地に出向き、エンジニアと一緒にLeetCodeに出てくるようなアルゴリズム問題を問いたり、Instagram の一部を設計して下さいといったような正解のない質問に対して議論を膨らませるもの等がありました。詳細は以下を参考にして下さい：
なぜコーディング試験が大事なの？
コーディング試験が普及する一方で、「コーディング試験は本当に有効なのか？」、「アルゴリズムなんて仕事でそんなに書かないのに技能に関係あるのか？」等といった疑問視する声も一定数あります。確かに私自身これまでメガベンチャーでエンジニアとして仕事をたくさんしてきましたが、実際にアルゴリズムを書いたり、Instagram 規模のシステムを設計した経験は非常に少なく、そういった声が出ることに対して一定数理解しています。
ですが私はコーディング試験のサービスを運営しているからバイアスを掛けているのではなく、この手のコーディング試験は有効で、逆に例えば特定のフレームワークを使ってアプリケーションを作る等、職能に基づいた試験はあまり有効ではないと思っています（ちなみに弊社は職能に特化したコーディング試験も用意しています）。以下見解を挙げた上それぞれ説明します：
- 技術の移り変わりは激しいので、特定のフレームワークを覚えても**スキルの賞味期限は思いの外短い。**よって不変的な知識の理解力やスキルの方が重要である
- 昨今は便利なツールの普及により、プロダクトをイチから作ることはそう難しくない。だが同様に作られたプロダクトは皆どんぐりの背比べとなりどれも差別化が難しい。圧倒的な技術的優位性を埋めるのは根幹部分にあり、それには原理を深く理解する必要がある
スキルの賞味期限
Golang, React どれもキャッチーに聞こえます。いずれも弊社が採用しているテクノロジーです。これらの技術は昨今注目を浴びているため、採用する際等もエンジニアを魅力できる武器の一つです。では PHP, Bootstrap, jQuery と聞くとどうでしょう？Golang や React と比較すると、それほどキャッチーではないかと思います。これは PHP や Bootstrap や jQuery が死んだためと言っているのではありません。代替できる最新の技術が次から次へと生まれ、その都度流行りは変わるということを伝えたいのです。事実 PHP に関していうと、現在でも過半数のウェブサイトは PHP で設計されていますし、Facebook 規模のサイトでも採用し、運用しているくらいです（厳密には派生した Hack）。
例えば弊社に応募した候補者に、職能に特化した Golang を用いてサーバーサイドのアプリケーションを作ってもらう試験を出したとします。期待通り、Golang を用いてサーバーサイドのアプリケーションを作れたため採用しましたが、その後別プロジェクトで Python を使うことになり、日々の業務で Python を書くことになりました。この時点で職能に特化した試験の意味はなくなりました。なぜなら候補者の地頭や適応力を見たのではなく、その時点での Golang でのアプリケーション構築できる能力を評価したためです。
逆に Golang のサーバーサイドの知識を問う試験ではなく、コンピューターサイエンスの授業で出てくるようなアルゴリズムとデータ構造に関する知識に関する試験を実施したとします。この場合仮に Python を書くことになろうが、PHP を書くことになろうが、アルゴリズムやデータ構造はそれらの言語でも共通する基礎となる不変的な知識であり、そこに対する知識の有無で、新しい言語を習得する速度は大きく異なります。このため適応力を測ることができるのです。
仮に同じテクノロジーをずっと使い続ける会社においての採用であれば職能ベースで技術力を測定して採用する手法でも良いでしょう。ですが、殆どの会社において使う技術やフレームワーク、コードベースは移り変わります。そのため大事なのはその時点での特定の技能を測るのではなく、地頭や適応力といった、移り変わりの激しい環境についていけるかを測るべきなのです。そしてそれを測るには、従来のアルゴリズムやシステムデザイン等の試験が一番測りやすくなっているため、今でも幅広く使用されているのです。
ツールを使うことはできても作ることはできない
二点目は昨今の便利な世の中、プロダクトを作ることにおいて、様々な選択肢があることから、ツールを作る必要性より、ツールを使いこなす必要性のほうがプロダクト作りにおいて必要になってきています。例えばあるサービスを作ることにおいて、イチから自分でデータセンターを作り、ネットワークを引き、コードを書いてリリースなんてことはしません。AWS や GCP 等のクラウドベンダーのデータセンターを借り、そこに自分の作ったアプリケーションをリリースするというのが一般的かと思います。
実際に弊社もイチからなにか技術を開発してサービスを作ったと言うよりかは、既存技術を用いて、それらのアプリケーション層（ここではある特定の問題に対してその技術を適用する層を指す）を工夫し、顧客に価値を届けるというケースがほとんどです。逆にそうしないと時間がかかりすぎていつまで経っても顧客に価値が届けられません。ですが、これは AWS や GCP 等が複雑なロジックを隠蔽し抽象化、民主化したインターフェースに則ってツールを使っている状態であり、同様の手順を踏めば全く同じものが作れてしまいます。そうなると差別化できるのはプロダクトではなく、それを提供する料金や営業力となってしまいます。これは技術的な優位性がない状態です。
一方で全てではないですが、ビジネスにとってコアな部分に関しては自分たちでできるだけ低レイヤーなところから実装したとします。たとえばペタバイトクラスのデータを日々扱う大規模なアプリケーションを運用しているとした時に、AWS や GCP 等のツールを使うという選択肢ではなく、自らそのユースケースに最適化されたデータセンターを構築するとします。もちろんツールを使うのと比較すると圧倒的に時間はかかりますが、それでもデータセンターが完成した際には AWS や GCP では実現できなかった規模のレイテンシーの低下や、更にはランニングコストのカットができるかもしれません。このようにコアコンピテンシーになるような部分においてツールを使うのではなく作ることによって圧倒的な技術的優位性が生まれ、結果として競合と比較し圧倒的に安い価格を実現できたりするのです。
MySQL 等、普段使い慣れているツールにおいても裏側は B-tree のインデックス等、アルゴリズムやデータ構造がたくさん使われています。ツールを使うことはできるが作ることはできないエンジニアと圧倒的な技術的優位性を生み出す、本当に価値のあるエンジニアを見分けるにはより原理に近いところまで理解しているかを問う必要があり、ここでもアルゴリズムの問題やシステムデザインの問題等が活きてくるのです。
これらの見解から私はコーディング試験の会社を運営しているからではなく、やはりビッグテックが行っているようなアルゴリズムの形式やシステムデザインの形式は有効であると思っています。一方で職能に特化した形式が全く意味がないのかというとそうではありません。適応能力が高くても、原理を理解していても、新しい技術やフレームワークを理解するのには時間がかかるものです。ですが、中長期的な目線で見るとある特定の技術ができるか否かよりかは、基礎になるような不変的な技術（ほとんどのケースで原理に近い）を正しく理解しているかを見るほうが、生み出す価値が異なるということがいいたかったのです。
（追記）
ちなみに弊社では codeserver や VScode web を使わずOnline IDE をイチから作っています。それ以外にもシステム設計の課題を解く、ドローイングツールもイチから作っています。これはこれらの技術が、技術力を可視化する上で中長期的に価値を生むと判断したため、ある程度の時間を投資して作りました。このようなツールを作ることができるエンジニアは多くなく、見分けるには原理を理解していることが必須だと思っています。
さいごに
最後まで読んでいただきありがとうございます。本記事では疑問視されるアルゴリズムやシステムデザインの問題をコーディング試験に出題することに関して私なりの見解を書きました。社内でもまずはドキュメントを読もうだったり、一時リソースの重要性は口酸っぱく言っています。私の好きな Elon Musk がよく口に出す、First Principleに親しいところがいくつかあると思っています。圧倒的な技術的優位性を生みたい方、コーディング試験のみかたを少し変えてみてもいいかもしれません。
次の記事は@s__shintaniによる「イベントソーシングを用いた通知サービスの設計」になります。次回もお楽しみに！