5年で5000を超えるコンテンツを揃えたギブリーが語る、人材採用・育成支援サービスの裏側

【9-A-3】Trackのプログラミングコンテンツ作成を支える技術

各種コンテンツの作り方とは、コーディング問題の作り方を解説

　ここで、小西氏は話題をコンテンツの作り方に移した。Trackではコンテンツをすべてテキスト・ファイルだけで作れるようにしている。

　この理由として小西氏は、コンテンツを作るのがエンジニアである点を挙げた。Webブラウザに表示するGUI画面を作って、ドラッグ＆ドロップやボタンのクリックなどの操作でコンテンツを作るようにもできるが、エンジニアはそのような操作法にはすぐに飽きてしまう。

　ここで小西氏は各種コンテンツの作り方を解説してくれたが、文字数の都合でコーディング問題の作り方の部分だけお届けする。コーディング問題を作るには最初に、動くアプリケーションとそのコードを用意し、そのコードをテストするコードも用意する。テスト・コードはTrackが対応するテスト・フレームワークを使って書くことができる。

　ここまで用意できたら、アプリケーションのソース・コードを部分的に削除する。部分的に削除したソース・コードを受検者に提示すれば、欠落している部分を埋めてもらうことが問題になる。

　Scoreing Serverは、受験者が送信してきたコードを、問題作成者が用意したテスト・コードでテストし、その結果をTAP（Test Anything Protocol）で出力する。TAPはそれぞれのテスト項目について「ok」あるいは「not ok」のどちらかを返す。okとnot okの数を数えれば、得点が決まる。

TAPの出力例。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にコンテンツを登録するなどの機能が加わる予定だとしている。