【CTOインタビュー】開発言語をPHPからRubyに切り替え、コードを全直し。その理由とは？――あしたのチーム・林田幸一さん
1100社を超える中小・ベンチャー企業への人事評価制度の構築・運用実績を持つあしたのチーム。面倒な評価業務の直感操作を可能にし、働き方改革を実現するクラウドサービス「コンピテンシークラウド™」は、「Ruby bizグランプリ 2017」でグランプリ（大賞）を受賞した注目のHR Techサービスです。
今回は、そんなあしたのチーム最高技術責任者（CTO）の林田幸一さんにインタビュー。Rubyのメリットや、独自のエンジニア体制等について伺いました。
目次
PHPからRubyに切り替え、複雑な権限管理システムを構築
林田さんがあしたのチームでの使用言語をPHPからRubyに変えた際のご経験についてお伺いしたいと思います。まず、Rubyに変えた経緯についてお聞かせ下さい。
あしたのチーム 執行役員 最高技術責任者（CTO）林田 幸一氏（以下、林田）：あしたのチームが手掛けているサービスにコンピテンシークラウドというサービスがあります。このサービスはこれまでに4回リニューアルしていまして、3回目のリニューアルまではPHPで作っていました。
フレームワークすら無い時代のころだったので、最初の開発時は素のPHPで書いていました。ある時、それをCakePHPで作り直すことになりまして。ところが、その時に設計書が1枚も無い状態で開発側にプロジェクトをボンと投げてしまい……。それが原因でプロジェクトは大失敗、結構大きな損失を出してしまいました。
Rubyに切り替えたのはこの失敗がきっかけです。
PHPで作っていたものを全部作り直したのですか？
林田：そうですね。PHP時代の要求仕様の一部だけ踏襲しましたが、コードもテーブル構成も参考にせず、要求仕様をゼロから作りました。 当時いたPHPプログラマーと2人体制で始めて、最終的には7人くらいで半年かけて書き直しました。
Ruby技術文化を踏襲し、Ruby on Railsの設計から外れず、Gemなどで拡張せずに基本に忠実に、書き直していったので、作業量は膨大になりましたが綺麗な設計・コードになりましたね。同時に自動テストやCIを導入して社内のエンジニア文化を統一し、Rubyに会社文化を適応させることもできました。最終的にはテーブル設計もPHP時代と同じになったため、移行可能となり、全データ移行することができました。
そもそもPHPで失敗したのは、要件定義と基本設計を疎かにしていたからです。PHPを使い続けていたとしても、再要件定義のために労力は割かなければならなかったでしょう。ですからこの点に関して言えば、Rubyに変えたことによるストレス、というものはあまり感じませんでした。
書き直すための言語としてRubyを選んだ理由とは何でしょうか？
林田：やはり生産性が高い、汎用性が高いプログラムが書ける、というのが一番大きかったです。 それとRubyは運用面でも大きなメリットがあります。Rubyには「名前命」という文化があったり、「可読性にこだわるプログラマー文化」あり、そのおかげでコードの可読性が高くなっています。また、Ruby on Railsの基本ルールも外れない設計をしていたため、後からプロジェクトに加わったエンジニアでもコードをすぐに理解しやすい。
実際、コンピテンシークラウドの開発ではRubyに助けられた側面もあります。 人事システム開発で一番手間がかかるのは権限管理の部分です。画面毎さらには項目毎に閲覧権限や編集権限など非常に細分化された権限表を用意しなければなりません。
たとえばコンピテンシークラウドの評価シートは社員が自ら記入した行動目標と数値目標を元に上司など評価者がそれぞれ点数評価する方式を採用しています。この場合、「被評価者自身が自分の点数を閲覧してもよいことにするか」、「どの評価者がどのくらいの点数をつけたか社員が確認できるようにするか」、「被評価者に各々がつけた点数を評価者同士で確認できるようにするか」など様々な閲覧権限の組み合わせを考慮する必要があり、システムが非常に複雑なものになるのです。
しかも閲覧権限への要望は会社によって細かく違います。ですから最初から全項目、全ユーザーの権限管理が可能なシステムを作らなければならない。もしRuby（動的言語）じゃなかったら、こんなに複雑なシステムを作るのは大変だったと思います。
Pythonを使いコメント添削と感情チェック機能を開発中
林田さんはPHPの他にどのような言語を使用していますか？
林田：今、コンピテンシークラウドの一部システムを機械学習で自動化する試みを進めていまして、その過程でPythonを使っています。私たちはコンピテンシークラウドを導入していただいた企業に対して、お客様が記入した評価目標を見て、その内容を添削するサービスを提供しています。たとえば、せっかく書かれた目標でも、「いつ」「どうやって」「どのように」という内容が抜けていると、目標達成までの具体的な行動に結びつきません。弊社では評価（査定）をするためだけの目標ではなく成長を促す目標にするため、「いつやる予定なのですか？」「具体的にどのような行動を行いますか？」などの添削コメントを寄せます。
ただこれが物凄く大変な作業で……１週間で１万件くらいこなさなければならない時があります。
その作業は全てスタッフの方が担当しているのですか？
林田：そうです。添削は1人あたり15～20分はかかります。さらにこれを1社で何十人分、何百企業も片付けるため、社内のリソースをかなり割くことになるんです。
ですから、もし添削の自動化さえできればリソースは省力化され、大きな生産性の向上が見込めます。これが今Pythonで取り組んでいるプロジェクトのひとつです。
もうひとつ進めているのが、評価コメントに対する「感情チェック機能」の導入です。
評価シートを見ていると、評価者が4点満点で2点をつけているのに、コメントにはポジティブな内容が記入されているケースがちらほら見られます。 評価点とコメントがあべこべになっている状態は好ましくありません。高い評価の時は褒めて欲しいし、低い評価の時は適切な指導をして欲しい。そのため、AIが点数とコメント内容を自動判定して、高い点数の時は「褒めてあげて下さい」と提案する機能を導入するつもりです。
人事制度・評価の工夫が実り、1年でエンジニア数は15倍に
社内のエンジニア体制はどのようになっていますか？
林田：正社員のエンジニアは15人在籍しています。 マネージャー陣はもうRubyを書き始めて7年になるベテランです。それと新卒で採用したエンジニアが5人くらいいます。
プログラマーが増えたおかげで、今は開発の6割を内製化できているという感じです。人が増えたことでRubyの文化圏が崩れないよう、コーディングスタイルをお互いに擦り合わせるなど慎重に進めています。
業務委託契約、リモート勤務の方はどうでしょうか？
林田：業務委託は4人います。リモート勤務は、人事制度としては7月から解禁されていますが、いまのところ社員では1人もいませんね。
エンジニアの採用や人事評価ではどのような点に気をつけていらっしゃいますか？
林田：人事評価で言うと、基本は弊社サービスである「ゼッタイ！評価®」をベースとしておりますが、「エンジニアは全く別人事制度にする」という号令のもと、スキル評価導入・リモートワーク導入・フレックスタイム制導入など、エンジニアだけの人事評価を導入しています。
それと人事評価について言えば、今年の4月からエンジニアは本部の人事評価システムを通さないということになりました。この他にもエンジニアのデスクは自習室スタイルのものにする、新オフィスでは絨毯で裸足・サンダルOKにするなど色々と規則を緩めました。
こうした取り組みが実ったのか、1年前にはPHPエンジニア1人だった体制から、現在ではRubyエンジニアを含めて15人の体制になりました。実は「人を15倍にした採用・評価制度」というテーマで本を出さないか、というお話も頂いており、準備をしている最中です。
エンジニアとデザイナーの働き方改革として、海外カンファレンス参加で年間優秀者3名を海外のカンファレンスや研修に例えば、RubyConf(US:NewOrleans)、Google I/O(San Francisco, CA)、F8 Facebook Developer Conference(San Francisco, CA)、TechCrunch Disrupt(New York, NY)に最大４日間参加することができる制度を設けました。また、社内のエンジニアとデザイナーはGithubにオープンソースとしてアップし、そのスター数が100 を超えた場合、オープンソースとして社会に貢献したとみなし、10万円を支給します。
クリエイティブ事業本部のキャリアパスは、以下のような形です。人事制度を扱っている会社ですので、エンジニアとデザイナーを分け、キャリアパスを丁寧に作っています。
言語選定の基準は、言語の性能より結局は「好き嫌い」？
林田さんが今後に注目している言語はありますか？
林田：新言語で言えば、Goですね。
文法がシンプルで、Rubyと違って型付け言語、さらにメモリが省力というのも魅力的です。
CTOの業務でご多忙かと思いますが、そのなかでどのようにして新言語のトレンドにキャッチアップしているのですか？
林田：新規事業を始める時に、あえて新言語を使うことで勉強せざるを得ない状況にしています。「無理やり使う」という感じですね。
新規事業の進行過程はスクラッチアンドビルドの連続です。そのスピード感のなかで、問題なく開発できる言語を探し出す。すると、Ruby on Railsも結構早いけどGoもやるな……という形で理解が深まっていきます。
ただもちろん性能面や技術面で選定していることも確かですが、本当のところを言うと、言語ってどういう使い方をしても意外と目的は果たせるんですよね。Rubyも「遅い、遅い」と言われていましたが、工夫すればそうでもなくなりますし。だから、最終的に選定の理由というのは、言語の好き嫌いという部分が大きいんじゃないかと思います。
企画/編集：FLEXY編集部
