同社 開発部 エンジニアマネジメント責任者 兼 エンジニア採用責任者 是澤太志氏（右）
顧問就任直後、前時代的な開発環境を目の当たりに
2017年2月、Rubyコミッターとしてbigdecimalライブラリのメンテナンスなどで活躍している村田賢太氏がSpeeeにジョインした。今やSpeeeといえば「Rubyの会社」という答えが返ってくることも珍しくないが、ここまでの状況に変化したのは、クックパッドで技術部長を務めていた井原氏が2015年8月、顧問に就任したことが大きい。
「クックパッドには5年間在籍し、技術部長としてエンジニア組織の強化と技術力向上に努めてきた。クックパッドを退職して、2015年1月に起業。すると『顧問に来てくれないか』という話をいくつかもらった。Speeeもそんな1社で、共通の知人から紹介された。技術が組織の成長に大事であること、自分たちが技術を十分に活用できていないことを理解し、その状況を何とかしたいと思っていること、それらがあれば基本、僕は断らない主義なので、受けることにした」
当時の開発現場を見た井原氏は、「古くさい開発をしているなと感じた」という。「モノの作り方や開発環境が整備されておらず、すごくもったいないなと。だから経営者にも遠慮することなく思ったことをガンガン伝えた」と振り返る。
一方、開発責任者の1人としてエンジニアを率いてきた是澤氏は、井原氏を開発部の顧問として招聘することを経営者から聞き、意外に感じたという。なぜなら「経営陣は技術力をそれほど重要視していないように見えていた」からだ。Speeeでは創業以来、開発責任者が事業部ごとに言語を選定しており、PHPかJavaのいずれかを使っていた。開発手法も特に決まっておらず、アジャイルとウォーターフォールが混在している状況だった。「コードレビューはなく、テストコードも書かない。フレームワークはFuelPHPを改修した独自フレームワークで、技術的にも筋が良くなかった。だからエンジニアもだんだんつまらなくなってしまう状況だった」と是澤氏は明かす。「Rubyで開発してみたい」思いは持っていたが、「社内では『すでにあるものを壊す必要はないのでは』という声もあり、そういう制約の中でやっていくんだと半ば諦めていた。自分自身も組織として技術力を高めることに関しては手を抜いていた」と、当時を振り返る。
言語はRubyに統一し、評価制度や組織も変革
そんな閉塞的な状況が、井原氏の顧問就任とともに一変する。
元々、同社にも言語を統一したいという考えはあった。事業によって使用する言語が分かれていると、状況に応じてエンジニアをチーム間で移動させるといった、柔軟なマネジメントができないからだ。そこで、井原氏を交えて熟考を重ねた結果、メイン言語にはRubyが採用されることになった。「特にRubyにこだわっていたわけではないが、僕が持っている技術的資産や人脈を有効活用するにはRubyとRailsが最適だったから」と井原氏。また、是澤氏も「Rubyはコミュニティも強いし、何よりRailsに興味を持っている若手エンジニアが多かった」とその理由を明かす。ちなみにメイン言語はRubyだが、ScalaとGoもサブ言語として採用している。
井原氏の就任により変わったのは、技術だけではない。組織も大きく変わった。
まずは評価制度の刷新に取り組んだ。勤続年数で給与が決まる年功制ではなく、大きな成果を出せば大きな対価を得られる成果主義に移行した。評価項目は事業への貢献度とエンジニア個人の能力の2つのみ。だが井原氏は「僕は、エンジニアの能力評価にはあまり意味がないと思っている」と話す。エンジニアが能力を高めるのは、目標を達成するため。つまり、企業の中で活動するのであれば、最終的には業績へ貢献しているかどうかという尺度に集約されるからだ。
では、どうすればエンジニアの能力が業績に貢献しているかどうかを、測ることができるのだろうか。井原氏は「売り上げをゴールにするから難しいのであって、売り上げに貢献するためにエンジニアができることを数値化し目標にすればいい」と語る。例えば「0.1秒以内にWebサイトがロードされれば、これだけの売り上げが上がるはず」という仮説をマネージャーと合意の上で立て、エンジニアがそれを達成できれば評価する、ということである。目標設定の方法を刷新し、OKR（Objective＆Key Result）の考え方を導入したのだ。
さらに「達成すべき目標は最初に決定するが、どのような方法で達成するかはエンジニア個人に任せている」と井原氏。技術の平準化をするよりも、得意なところをもっと伸ばす方針に変えた。このような評価制度を採用することで、エンジニア個人の責任範囲も明確化され、正当に評価される仕組みができるというわけだ。
