リクルートでフロントエンド改革に挑む--開発工数25％削減の裏側にある汗と涙

フロントエンドの業務範囲変革

太田智彬氏（以下、太田）：はじめまして。太田と申します。さっそく始めていきます。僕のタイトルは「リクルートのフロントエンド変革に挑んだ話」になります。

名前が、太田智彬と申しまして、フロントエンドをやっています。最近、休日はRailsとかPHPのLaravelとか、Vue.jsをやっていることが多いです。略歴は、フロントエンドエンジニアやテクニカルディレクターとして、Web制作会社で3年半くらい働いたあとに、2015年2月にリクルートテクノロジーズに入りました。

何冊か本を書いていて、最新だと、『Think IT』というところで、ES2015の連載をやっていて、なんと古川さんにもレビューいただいているので、よければ見てみてください。

話は変わり、フロントエンドの業務範囲変革に挑んだ話をしていきたいと思います。

ことの始まりは、2015年2月。入社したての僕が、上長から「進学支援サービスのフロントエンドをいい感じにしてよ」とダイナミックなミッションを与えられたところから。さらにですね。「結婚情報サービスのやつと、車のやつもよろしくな」と。あと、「教育支援サービスのあれとあれも忘れんなよ」と、言われました。

当時2年前の話なんですけど、Gulpとかcoffee scriptとかSassなどが全盛だったので、このあたりを入れとけばいいのかな、くらいの気持ちでいたんです。これが甘かった。事業に入り込んで状況を把握したとき、いい材料がまったく見えてきませんでした。

まず、開発フローですね。フロントエンドは、各社パートナーさんとの混成チームで、Gitでソースを管理しています。バックエンドは、外部SIerさんに入っていただいていて、Svnで管理されています。

フロントエンドはHTML、CS、JSをコーディングして、まさかのZip納品をしており、それを外部SIの方がマージしてくれる。さらに、Model、Controller周りもSIerさん、バックエンドチームで開発していただくという流れになっていました。

この開発フローがさまざまな問題を引き起こしておりまして。1個目が、バックエンドチームがViewとかCSSとかJSを修正することがあるんですけど、その変更がフロントエンドに伝わらないことです。

これによって、「SassとかCoffee Scriptを使うと、デグレが発生するので使えません」「フロントエンドがViewを見れる状態にないので、CSSの影響調査をすることができません」という状況が起きる。これによって、詳細度の打ち消し合戦とか、class.yymmdd_classNameとか、CSSが肥大化していきます。

あと、IE9以下のとき1ファイルで4096個以上のセレクタが読めない仕様があるので、それによってデザイン崩れが起きる。軽微障害とかが多発していました。さらに、フロントエンドチームがエンハンスの度にHTMLを本番からダウンロードし、それを元にテンプレートにHTMLをコーディングする、ということをやっていたので、結合テストのタイミングで表示パターン不足などが多発していました。

さらに、システム連携にも問題が発生していました。UI系JavaScriptはフロントエンド、値の受け渡しとかが入るJavaScriptはバックエンドと、管理者がバラバラです。今でこそ、Webパックなどがあるのでグローバル変数が外にそのまま出てしまうことはないと思うんですけど、当時はけっこう古いソースだったので、グローバル変数の衝突などがガンガン起きていました。

さらにですね、Viewに修正が入るたびにマージが発生するので、修正工数が肥大化して、開発効率が悪化していました。

「大草原不可避」ということでですね。ただ、笑ってばかりもいられないので、問題点を整理しました。

壁を突破するためにやった3つのこと

その結果、フロントエンドがViewを見れる状態にないので、CSSの影響範囲とかがわからないとか、バックエンドの修正部分が伝わらないといったことは、リポジトリ共通化で解決できそうだなと。

Viewに修正が入るたびにマージが発生するとか、エンハンスのたびに本番からHTMLをダウンロードとか、JavaScriptの管理主体がバラけているということは、フロントエンドがViewをコーディングすることで解決できそうだなと。

ということは、リポジトリ共通化と、フロントエンドによるViewコーディングができれば、これはすべて解決するんじゃないかと。

今のフローとしては、まずリポジトリを共通化します。次に、フロントエンドによるViewコーディングを行います。つまり、まとめるとこうなるということですね。

しかし、10年以上歩み続けてきたフローを変えるというのは、並大抵のことではなくて。例えば、「フロントエンドがViewを触るのは、責任範囲が曖昧になるのではないか？」とか。「コミュニケーションコストが増えるから意味がないのでは？」とか。「ブランチの運用はどうする気だ？」とか。「誰だお前は？」とか。

（会場笑）

忌憚なき意見を大量にいただきまして、けっこう大変でした。が、この壁を突破しました。それをどう突破したか、のポイントは大きく3つあります。Win-Winの関係作りと、バックエンド経験のあるフロントエンドエンジニアの採用、そしてフィジビリですね。

1個目の、Win-Winの関係作りです。まず、当たり前なんですけど、人はメリットがないと動きません。自分の立場からすると、前述の問題点が解消されるという大きなメリットがあるんですけど、SIerさんの立場に立つと、「フロー変革」イコール「障害リスクやパワーがかかる」という大きなデメリットが見えてきます。

それで、SIerさんにとってフロー変革をやるメリットはなんなのかと。会話を重ねていくなかで、SIerさんが抱えている課題が見えてきました。まずは、マージ作業へのプログラマーのモチベーション低下。そして、修正フローの辛さですね。納品、取り込み、納品、取り込みという感じです。それと、業務時間の長さですね。

なので、この前述したSIerさんの課題を解決することのメリットが、フロー変革による障害リスクや、かかるパワーのデメリットを上回るという状態を作ってあげて、相手のWinを明確化する。これを1回やりました。

次に、バックエンド経験のあるフロントエンドエンジニアの採用をやりました。これは、まずバックエンドがきれいなMVCになっていれば、これはJavaやPHPの前提なんですけど、JSPやSmartyの知識があれば、大半の作業はできますよね。つまり、バックエンド経験がなくても、さほど問題はありません。

ですが、長年の運用で、Viewにロジックが含まれている箇所が多数存在していて、ModelやControllerまでソースが追えないと、「これってどうなってるんですか」というのをバックエンドの方に聞かざるをえないので、コミュニケーションコストが増大してしまいます。

さらに、ローカル開発環境の構築手順というのは、基本的にはWindows前提で作られています。なので、Macを使いたい場合は、独自でアパッチ周りのパスを書き換えたり、いろいろなトラブルシューティングを自分で行ったりする必要があります。なので、バックエンド経験は外せないなと。かくして、バックエンド経験のあるフロントエンドエンジニアのパートナーさんを採用するに至りました。

最後の壁の突破法の「フィジビリ」という言葉なんですけど。まず、フィジビリというのは、「フィジビリティスタディ」の略で、事業計画が実現可能であるか否かを評価するために事前に行われる調査・研究を指す言葉です。

リクルートでよく使われるんですが、簡単に言ってしまえば「試験的に小さくやってみましょうよ」という話ですね。今回の件に当てはめると、次のエンハンスで改善フローを試験的にやってみましょうよ、という話に言い換えられます。

これで、「一気にすべてを変えるわけではありません」とか。「うまくいかなかったら、改善点を洗い出して、少しずつよくしていけばいいですよね」とか。あと、「まったく改善見込みがないんだったら、そもそも元のフローに戻しちゃえばいいですよね」とか。そういう会話をして、心理的ハードルを下げていきました。

定量データの指標を探す

こうして、ようやく、フィジビリの実施に漕ぎ着けたのであった……かに見えたんですが。

「なるほど、今までの話は聞かせてもらったよ」と。「定性で良さそうなのはわかったんだけど、結局それってどのくらい効果出るの？」「やる意味あるのか？」と。

そうです。定量データが足りていませんでした。基本的に、決定者の立場からすると、QCBですね。品質やコスト、生産性いずれかの定量データがないとGOを出しにくいです。

ここでまた振り出しに戻り、必死に指標を探す日々がまた始まりました。

そんななか、一筋の光を見つけます。LOCですね。Lines Of Code。

「いやいやいやいや、今さらかよ」と。

「コピペばっかりだったら、LOCなんか簡単に増えるじゃん」と。

ちなみにLOCっていうのは、編集コード行数のことですね。汚いコード書けば、LOCなんか増えるじゃんと。わかります。それは、わかるんですけど。

だがしかし、ですね。LOCとして、Xパーセント削減しているのは事実ですよね。コード品質とか、コミュニケーションコストとか、案件難易度とか、運用上の都合とか、厳密に考え出したらキリがないですよね、と。「厳密な指標を出すことばかりを気にして、考え続けてたら、一生なにも変えられずに終わりませんか？」ということです。

前提つきでも指標があればいいんです。「LOCベースで、Xパーセント効率化できます」。これだなと思いましたね、私は。

具体的な定量データなんですけど、git logで、過去数年分のnumstatを抽出して、MySQLに入れて、それを集計しました。理論上、拡張子が、.jsp、.css、.jsであれば、それはマージに費やしたLOCです。フロントエンドは、HTMLではなく、JSPをコーディングするようになるので、マージLOCはゼロとなります。

つまり、.jsp、.css、.jsの拡張子を、全拡張子で割ると、これがバックエンドのコスト削減率であるということが言えます。例えば、.jsp、.css、.jsのLOCが20,000行で、全体のLOCが100,000行だとしたら、だいたい20パーセントの削減率であるということが言えますよねと。ということは、年間の開発費が1億だとした場合、年間2,000万の工数を新たに創出できるということになります。

これで、ようやく「じゃあ、やってみるか」という言葉をいただいたので、フィジビリに移行することができました。そして、フィジビリで結果が出たあとは、事業側も全面的にバックアップしてくれ、順調に対象案件を拡大していきました。

開発工数を25パーセント削減

1年後の現在なんですけど、今では、案件の90パーセント以上を「Viewを直接コーディングする」というフローで行っています。フロー改善前と比較すると、開発工数をだいたい25パーセント削減できています。これは、LOCじゃなくて、同規模案件の工数で比較しています。

さらにですね。定量データ以外にも表れた定性の効果というのがあって。それは、例えば結合テストをせずとも、最終結果が見れるとか。似たような話なんですが、バックエンドが用意してくれているseedのデータがあるので、さまざまなパターンがすぐ見れるとか。あとは、影響範囲がわかるようになったので、リファクタを部分的に適用できるようになったとか。

ただ、いまだに解決できていない問題もあります。相互成長できない問題というのがあって。バックエンド経験のあるフロントエンドの人は、CSS周りが弱いです。逆に、そうでないフロントエンドの人は、バックエンドが弱いです。なので、お互いの弱い部分を教えあえばチーム力の底上げができるのではないか、という仮説でした。

バックエンド経験のあるフロントエンドの人は、期待通りCSS周りに強くなっていきました。ただ、バックエンド経験がまったくないフロントエンドの人は、やはりハードルが高くて、思ったように習得が進んでいません。

つまり、Viewをコーディングできる人材が思うように増えていっていません。これは、けっこう自分の中での反省で、バックエンド入門みたいな、最初の一歩を踏み出せるような学習コンテンツをきちんと用意すべきだったなと、今にして思います。

Wrap upなんですけど。壁の突破法は3つあって、Win-Winの関係作り、バックエンド経験のあるフロントエンドエンジニアの採用、それとフィジビリ。あとは、定量でLOC効率化の指標を出したと。フィジビリで改善見立てが出たあとは、ちょっとした投資とか、いろいろ全面的にバックアップしてくれました。

今回は、けっこう正攻法で攻めたんですけど、いろいろなやり方があると思っています。いいアイデアがあったら、やってしまって、怒られたら、あとで謝る。ぜんぜんあるとは思うので。これは便利な言葉だなと。

「俺たちの闘いは続く」。

ご静聴ありがとうございました。

（会場拍手）