僕のタイトルは「リクルートのフロントエンド変革に挑んだ話」になります。名前が、太田智彬と申しまして、フロントエンドをやっています。最近、休日はRailsとかPHPのLaravelとか、Vue.jsをやっていることが多いです。略歴は、フロントエンドエンジニアやテクニカルディレクターとして、Web制作会社で3年半くらい働いたあとに、2015年2月にリクルートテクノロジーズに入りました。IT』というところで、ES2015の連載をやっていて、なんと古川さんにもレビューいただいているので、よければ見てみてください。話は変わり、フロントエンドの業務範囲変革に挑んだ話をしていきたいと思います。ことの始まりは、2015年2月。入社したての僕が、上長から「進学支援サービスのフロントエンドをいい感じにしてよ」とダイナミックなミッションを与えられたところから。「結婚情報サービスのやつと、車のやつもよろしくな」と。あと、「教育支援サービスのあれとあれも忘れんなよ」と、言われました。scriptとかSassなどが全盛だったので、このあたりを入れとけばいいのかな、くらいの気持ちでいたんです。事業に入り込んで状況を把握したとき、いい材料がまったく見えてきませんでした。フロントエンドは、各社パートナーさんとの混成チームで、Gitでソースを管理しています。バックエンドは、外部SIerさんに入っていただいていて、Svnで管理されています。フロントエンドはHTML、CS、JSをコーディングして、まさかのZip納品をしており、それを外部SIの方がマージしてくれる。Model、Controller周りもSIerさん、バックエンドチームで開発していただくという流れになっていました。この開発フローがさまざまな問題を引き起こしておりまして。1個目が、バックエンドチームがViewとかCSSとかJSを修正することがあるんですけど、その変更がフロントエンドに伝わらないことです。Scriptを使うと、デグレが発生するので使えません」「フロントエンドがViewを見れる状態にないので、CSSの影響調査をすることができません」という状況が起きる。これによって、詳細度の打ち消し合戦とか、class.yymmdd_classNameとか、CSSが肥大化していきます。あと、IE9以下のとき1ファイルで4096個以上のセレクタが読めない仕様があるので、それによってデザイン崩れが起きる。軽微障害とかが多発していました。フロントエンドチームがエンハンスの度にHTMLを本番からダウンロードし、それを元にテンプレートにHTMLをコーディングする、ということをやっていたので、結合テストのタイミングで表示パターン不足などが多発していました。システム連携にも問題が発生していました。UI系JavaScriptはフロントエンド、値の受け渡しとかが入るJavaScriptはバックエンドと、管理者がバラバラです。今でこそ、Webパックなどがあるのでグローバル変数が外にそのまま出てしまうことはないと思うんですけど、当時はけっこう古いソースだったので、グローバル変数の衝突などがガンガン起きていました。笑ってばかりもいられないので、問題点を整理しました。壁を突破するためにやった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を出しにくいです。ここでまた振り出しに戻り、必死に指標を探す日々がまた始まりました。そんななか、一筋の光を見つけます。