『Homeup!』は、ベーシックが開発・運営するWebマーケティングオートメーションツール。この4月に正式リリースされたばかりの新しいサービスだが、開発チームはその裏側で早くも、Angular.jsからReact.jsへとリファクタリングを進めている。

実装は7月いっぱいで完了し、近々に再リリースされる見込みという。

ベーシックはWebマーケティング、アプリマーケティングなど7つの事業の柱を持つが、過去にもPHPからRuby on Railsへの全面移行やテストの全社的な導入など、新しい開発手法や技術を積極的に取り入れ、絶えず開発環境を改善し続ける姿勢を示している。

こうした取り組みは誰もが理想としては掲げつつも、実行するにはさまざまな障壁があるだろう。

すでに回っているサービスの保守や改善が優先されるだろうし、日々更新される新しい技術にどうやってキャッチアップし、取捨選択するか、知識やスキル、習慣をどうチームメンバーに共有するのかといった課題もある。

ベーシックではこうした課題をどうクリアしているのか。あるいは課題を抱えるリスクを感じつつも環境改善することの意義をどうとらえているのか。こうした疑問に対する答えを紐解くべく、同社の開発2トップであるCTO桜庭洋之氏と斎藤幸士氏にインタビューを行った。

結論から言って、2人の開発環境改善に関する考え方は必ずしも一致していない。しかしその「違い」にこそ、ベーシックの開発チームが進化し続けられる理由があるようだ。

属人化しない移行は本当に可能？実装前の調査は入念に

『Homeup!』は、Webサイトの構築から分析、顧客を育てるところまで、Webマーケティングを一気通貫に行えるサービスだ。今回Reactへの移行を進めているのは、このうちのページを作成するCMSの部分について。

「テキストやイラストを埋め込むといった修正が、各コンポーネントをドラッグアンドドロップするだけで実施できるというお手軽さが、『Homeup!』の一つの売り。簡単に言って、このコンポーネントを切り分けて作るのにはAngularよりもReactの方が適していたというのが、移行の理由です。CMSのブラッシュアップは今後も継続的に行っていく腹づもりなので、早い段階でやりやすい形に内部構造を変えておく必要がありました」（斎藤氏）

移行を進めるにあたってはまず、Reactについてのリサーチに2カ月という時間を掛けた。

『Homeup!』の各部品の作り込みは、同社のベトナム・ハノイにある開発チームが担当している。そのメインプログラマー2人が通常の業務と並行して調査を行った。調査内容は、そもそもすでに動いているものの移行が可能なのか、移行することで本当にメンテナンスは楽になるのか、それを属人化しない形でやれるのか、など。

その後、調査にあたったプログラマー2人を日本のオフィスに呼び寄せ、デザイナーとともに1カ月半という短期間で一気に実装を進めている。

「事前に入念に調査を行ったこと、デザイナーとプログラマーが物理的にも近い距離で作業を進めたことで、スムーズに運ぶことができました。私も含めた6人のエンジニアがそれぞれ1つずつコンポーネントを受け持っており、作業の切り分け、属人化しないという点でも、移行の目的は達成できていると思います」

開発環境ではgulpというビルドシステムを使ってJSXを自動でjsへとコンパイルしている。「本番環境では別の仕組みが必要となるため、その構成を作る段階で、最後に越えなければならないもうひと山があるだろう」と斎藤氏は見通しを語る。

改革は新規サービスから。組織を流動化してスキル格差を減らす

ベーシックでは他にも、開発環境改善の取り組みを多々行っている。分かりやすい例としては、約1年前から取り組んでいるテスト環境の整備が挙げられるだろう。

もともとサービスごと、エンジニアごとにテストに置く比重や手法はバラバラだったが、1年前に全社的にテストコードを書くことを推奨すると宣言。

従来はPHPが主体だったのをテスト向きのフレームワークが充実しているRuby主体へと移行し、単体テストはRSpecを使用。テスト実行からデプロイまでは、Circle CIやwerckerを使った自動化にも取り組んでいる。

「今までテストを書いたこと自体がないチームも多かったので、定期的に社内勉強会を開いたり、ペアプロで一緒にテストコードを書いたりしながら、テストを書くことの意義を説くような啓蒙活動から始めました。目の前のタスクに追われている既存サービスでは、やはりすぐに実行することが難しい。幸いベーシックでは新規サービスが立ち上がる機会が多いので、まず新規サービスから取り入れ、徐々に既存サービスを巻き込んでいくという手順でやっています」（桜庭氏）

テストを組織的に行うことの効果はすでに表れていて、「プログラマーが躊躇なく、今書いているコードを捨てることができるようになった」と桜庭氏。

「従来であれば、仕様の変更に伴いガラッと作り直した方がいいと思える状況でも、すでに動いている部分が動かなくなる事態が怖くて踏み切れないということがありました。テストがあることでそうした心理的な負荷が下がり、思い切った決断もできるようになってきています」

もちろん、テストのスキルは担当するプロジェクトによって差が生じてくる。次の段階として、今期からはアサインするプロジェクトに流動性を持たせる方向で組織改革を進める方針という。

「これまでは1つのサービスをエンジニア1人が見るような体制だったため、人を動かしたくても動かせなかった。今後は最低3人からなるチーム構成にすることで、半年に1回程度の頻度でメンバーの入れ替えを行い、スキルの格差を減らしていこうと思っています」（桜庭氏）

たゆまぬ改善が必要な理由は1つではない

ベーシックが技術の置き換えや開発環境の改善にここまで手間を惜しまないのはなぜか。

まず桜庭氏が挙げたのは、「それがエンジニアのモチベーションにつながるから」という理由だ。

「IT技術の進化のスピードは非常に速い。そうしたものに全く触れずに10年前のフレームワークで保守管理だけしているのでは、精神的に楽しい仕事とは言えないですよね？そのため、仮に直近の実用性は抜きにしたとしても、新しいものに触れる機会を設けているという側面があります。それがモチベーションとなって、結果としていい仕事につながっていくと考えているからです」

一方で斎藤氏は、「必要に迫られて新しいものに取り組んでいるという部分もある」と話す。

「これまでにないサービスを世に出そうと思ったら、それができる環境を選ばないといけない。『Homeup!』の例でいえば、『Homeup!』を使って作ったサイト上の行動履歴は全て見られるという仕様を謳っているため、ログデータ全てをデータベースに保存する必要があります。調べていくと、AmazonのDynamoDBであればコスト的にもパフォーマンス的にもできそうということが分かったので、知識や経験はありませんでしたが、それを選択するという決断をしました」

2人が挙げた理由は対照的だが、考え方を1つに収束する必要はないというのがベーシックのスタンスだ。

「技術的な指向性は基本的には統一した方がいいと思いますが、一方で収束し過ぎるのは良くないとも考えています。全社的にAngular1本でいくと決めていたら、今回のReactへの移行という選択肢はなかったわけだし、ベトナムの部隊に先に調査してもらうという手段も取れなかった。提案をするのは必ずしも自分たち開発トップである必要もなく、別のレイヤーにいる社員も自由に発言できるのが良いと考えています」（桜庭氏）

ちなみにこうした2人の指向性の違いは、これまで歩んできたキャリアの違いに由来するようだ。

斎藤氏がプログラマーとしてのキャリアをスタートさせたのは23歳と比較的遅く、SIerから始まって研究所の研究補助職を経て、IPAの未踏ソフトウエアに採択されたことがきっかけで起業も経験している。あえて分類すれば、目的志向の強いエンジニアといえるかもしれない。

対して桜庭氏は中学生からプログラミングに親しみ、学生時代から2ちゃんねるのファイルアップローダを運営するなどしていた生粋のプログラマー。2トップのこの違いは、多様性を受け入れるベーシックの土壌を象徴的に示している。

多様性を認める土壌にこそ進化の秘訣がある

桜庭氏がベーシックに入社したのは約5年前。その前に所属していた会社も同業種だったが、ベーシックは比べられないほど経営がうまくいっていた。「その違いが何なのかが知りたかった」というのが、入社の動機だった。

「今ではその答えははっきりしています。以前いた会社はターゲットとするユーザー像がぼやけていたのに対して、ベーシックはユーザーを知る、想像する、考えることを突き詰めていたということです」（桜庭氏）

ひと言で言えばそれは、「マーケティングをきちんと行っているかどうか」。つまり、ベーシックが『Homeup!』などのプロダクトを通じて世の中に提供しようとしている価値そのものということになる。

「掲げているミッションはマーケティングの大衆化です。これからWebにまつわる何かをやる時には、必ずマーケティング支援の仕組みが重要になる。ですが現状、誰でも簡単に使えるものは世の中にありません。誰でも使えるというところを実現しようとすれば、必然的にその裏側に求められる技術レベルは高くなります。絶えず新しい技術を取り入れ、環境を刷新しているのはそうした志の表れでもあるんです」（斎藤氏）

「同時に組織にとって一番重要なのは、誰かが思いついたものをすぐに作れる環境があることだと思います。技術の置き換え、チャレンジというものには、その根底に何かを効率的にしたい、より良くしたいという思いがあるはずです。それを続けることが組織としての『作る力』を生む。良いアイデアがあったとしても、本当に良いかどうかは世に出してみないと分からないですし、大半は失敗に終わります。だからこそ、数を打てるような体制が重要なのです」（桜庭氏）

最後に、現在採用も行いながらチーム拡大に着手する中、2人が考える理想のエンジニア像についても聞いた。

「自分がかつてスタートアップにいたということもあり、スタートアップに飛び込めるようなエンジニアが理想です。自分の役割を限定することなく、サービス立ち上げ時の設計から始まり、どうやってスケールさせるかについても考えられたり、それこそマーケティングもできる。そういう気質のある人と一緒に働きたいですね」（斎藤氏）

「頼まれてもいないのにとことんパフォーマンスを追求したり、作業効率を求めて自動化したり、フロント系なら遊び心でアニメーションを入れてしまったり……。仕事をする上では好きなことだけやっていればいいわけではないですが、モチベーションの種を自ら埋め込めるようなエンジニアは、周りにも良い影響を与えてくれるだろうと思います」（桜庭氏）

掲げられた理想はやはり異なるものだったが、2人は「初めて聞いたけど、そっちの言う理想像もいいね」とお互いに認め合っていた。異なる個性を許容しあえるところにも、ベーシックが進化し続けることができる理由はあるようだ。

取材・文／鈴木陸夫（編集部）　撮影／竹井俊晴