人材採用から既存の従業員の研修まで支援する「Track」とは
まずは小川氏がTrackの概要について説明を始めた。Trackには、「Job」「Test」「Training」の3種類のサービスがある。Jobは、新卒採用向けのサービス。新卒の学生にプログラミング課題を解いてもらうことで、優秀な学生を即戦力エンジニアとして採用することを支援する。
Testは、中途採用を支援するサービスだ。採用希望者にコーディング・テストを受けてもらい、受検者全員の能力を企業が判断した上で、本当に優秀な候補者との面接に多くの時間を使えるように支援する。
Trainingは、既存の従業員のスキルアップと、スキルレベルの把握を可能にするサービス。テストで実力を測るだけでなく、教材や動画を提示して学習してもらうこともできる。企業側は、従業員一人ひとりの学習の進捗状況を管理できる。さらに、テストの結果から個々人のスキルレベルを把握し、その結果に応じて一人一人に合わせた学習法を提示できる。
Trackで提供するコンテンツは大まかに言って「クイズ」「コーディング」「ブック」「AI」「アプリケーション」「ビデオ」の6種類。クイズは知識を測る問題で、穴埋め、選択式、自由記述形式に対応する。
コーディングは、プログラミング力を測る問題で、言語不問の競技プログラミングのような問題と、特定の言語に焦点を当てた問題の2種類に分けられる。コーディング問題の画面では左側に問題文を表示し、右上にコードを記入する欄を設けている。そして右下にはコンソールを用意しており、記入したコードの実行結果などを受検者が確認できるようになっている。
ブックは書籍のような構成になっており、ページをめくるごとに新しい教材が現れる。読んで学ぶ教材だけでなく、コードの穴埋めやコードを実行してみるなど、小テストのようなものも組み込める。小川氏は「ページを進めていくことで、知識だけでなく、プログラミングの工程も習得できる教材だ」とその特徴を表現する。
AIは、受検者が考えた機械学習のモデルを評価するもので、機械学習で標準的なKaggle形式に対応している。アプリケーションは、Webアプリケーション作成に必要な知識を学べる教材。Webサーバーなどの実行環境もすべて用意しており、Track上で完結した環境を作っている。ビデオは動画教材だ。
実行環境を揃えたDocker Imageを言語ごとに用意して使い分ける
ここでスピーカーが小西氏に交代し、Trackの大まかなシステム構成の説明を始めた。Trackは、「Track Application」「Contents Server」「Command Execution Server」「Scoring Server」の4種類のモジュールで成り立っている。このうち、ユーザーが目にするにはTrack Application。「Editor」というモジュールを内蔵しており、それがほかのモジュールと連携して、コンテンツを表示している。さらに、Command Execution Serverと連携して、ユーザーが入力したコードの実行結果を表示する。
Contents Serverは、コンテンツの供給と登録、そしてバージョン管理を受け持っている。登録したコンテンツは一度作って終わりとはいかず、何度もバージョンアップを繰り返すことになる。「誤字脱字などはすぐに修正できるが、問題文を修正するときは、受講者に有利不利が発生することがあるので、すぐには修正できないことがある。そこがContents Serverの難しいところ」（小西氏）
Command Execution Serverは、受検者が作成したファイル・セットと受検者が指示した実行コマンドを受け取って、その標準出力と標準エラー出力をWebSocketで返している。Trackでは現在、20近いプログラミング言語に対応しているが、それぞれの言語のコンパイル、実行環境として、言語ごとにDocker Imageを用意して使い分けている。
アルゴリズム問題で計算量の多い問題を多くの受検者に出題すると、計算量の多いプログラムを受検者全員が実行する。その結果、Command Execution Serverの計算能力が追いつかず、スケール・アウトで対応しなければならないのだ。問題の計算量を見積もって、どれくらいのサーバーを配分するかを決めるときに悩むことが多いという。
Scoring Serverは、ユーザーが提出したコードを採点し、得点を決定する。テスト・コードの実行はCommand Execution Serverが担当するが、その結果の解釈、採点はScoring Serverが受け持つ。
ユーザーがコードを保存するたびに、Scoring Serverに採点依頼がやって来て、そのたびにScoring Serverはテストを複数回実行する。その理由は、成功するはずのテストが失敗することがあるからだ。これは実際の開発現場でも起こることだそうだ。
失敗する理由としては、「npm install」のような通信を伴うコマンドが失敗する、Command Execution Serverが何らかの理由で不調に陥ってテストが動かない、計算量が多い問題では実行を指示しても制限時間内に完了しないなどが挙げられる。
各種コンテンツの作り方とは、コーディング問題の作り方を解説
ここで、小西氏は話題をコンテンツの作り方に移した。Trackではコンテンツをすべてテキスト・ファイルだけで作れるようにしている。
この理由として小西氏は、コンテンツを作るのがエンジニアである点を挙げた。Webブラウザに表示するGUI画面を作って、ドラッグ＆ドロップやボタンのクリックなどの操作でコンテンツを作るようにもできるが、エンジニアはそのような操作法にはすぐに飽きてしまう。
ここで小西氏は各種コンテンツの作り方を解説してくれたが、文字数の都合でコーディング問題の作り方の部分だけお届けする。コーディング問題を作るには最初に、動くアプリケーションとそのコードを用意し、そのコードをテストするコードも用意する。テスト・コードはTrackが対応するテスト・フレームワークを使って書くことができる。
ここまで用意できたら、アプリケーションのソース・コードを部分的に削除する。部分的に削除したソース・コードを受検者に提示すれば、欠落している部分を埋めてもらうことが問題になる。
Scoreing Serverは、受験者が送信してきたコードを、問題作成者が用意したテスト・コードでテストし、その結果をTAP（Test Anything Protocol）で出力する。TAPはそれぞれのテスト項目について「ok」あるいは「not ok」のどちらかを返す。okとnot okの数を数えれば、得点が決まる。
部分的に削除したソース・コードと、正しいテスト・コードを用意したら、設定ファイルと問題文を用意する。問題文はREADME.mdという名称のファイルにマークダウンで記述すれば良い。
設定ファイルには、コンテンツを構成するファイルをYAML形式で記述する。編集可能なファイル、編集を禁止するファイルなどを指定できる。受検者には提示しないが、採点時には使用するファイルも指定できる。この設定を利用することで、受検者にはテスト・ケースを10点だけ提示しながら、採点時には20点のテスト・ケースで採点することも可能になる。
コンテンツを作成したら、動作確認が必要だが、ギブリーはローカルで動く動作確認環境「Marine」を用意しており、Docker Imageの形で同社のGitHubレポジトリで配布している。Marineの中身は、先述のTrack Applicationとほぼ同じだ。大きな違いはコンテンツの供給元。Track Applicationでは、クラウド・ストレージからコンテンツ供給を受けるようになっているが、Marineでは、ローカルのファイル・システムにあるファイルを直接読み取って、それを表示する。
現在のところ、MarineにはContents Serverと連携する機能は備わっていない。ただしギブリーは今後、Trackのコンテンツ作成機能を外部に公開することを予定しており、その際には、MarineからContents Serverにコンテンツを登録するなどの機能が加わる予定だとしている。
