サイトアイコン Tech Direct BLOG

コデアルリニューアルと技術的なトピック

codeal

コデアル株式会社、リードエンジニアの川原 (@ooharabucyou) です。

2018年5月2日(水)、コデアル (https://www.codeal.work/) の外観を大きくリニューアルいたしました。

リニューアルの概要

今回のリニューアルリリースでは、主にデザイン面での変更がなされました。

Before

 

After

リニューアルの経緯

コデアルサービス開始当初2015年8月15日は、デザイナーのディレクションが存在しませんでした。私自身はデザインセンスなどは全くといっていいほど存在せず、デザインに注力する人間が社内にいませんでした。

とにかくサービスを公開する！ということが重視されていたので、見た目に関しては angular material に任せ、そのガイドラインに従うという体制をとっていました。とはいえ、とにかく少ない人数の中、改修スピードが重視されていたので、そのガイドラインから外れることも随分やってきました。モックを作りInVisionに設置された資料を元に開発するという体制自体はこの時点で存在していたのですが、全体的に一貫したルールが整備されることはなく、なにかを作る度に不整合が出たりする状態になっていました。

サービス自体に関しても、エンジニアだけでなく、デザイナー・マーケッターといった、サービス作りをする人たちに広げていくという必要性がでており、コデアルのCI（コーポレート・アイデンティティ）を含めて見直そうということになりました。これには「サービス名を変える」「ロゴを変える」「デザインを変える」といったことが全て包括されています。

このCI変更に関しては、CEO愛宕のブログをご覧ください。

新Frontendに利用した技術

2015年に開発開始した旧来のFrontend画面は、Ruby on Rails と AngularJS (1.6, 利用開始当初は1.2) を利用してきました。今回のリリースでは、アプリケーションの構造や、フレームワークを見直して1から作り直しています。

旧来の構成

当初は、AngularJS 単体の SPA を作り、ストレージとCDNだけで運用するという構想もあったのですが、SEO対策上の理由で行えておりませんでした。

一方で、新しいFrontendでは、以下の構成にしました。

Frontend のサーバ運用面倒くさい & 早く開発が回せるようにするという思いでこうなりました。Nuxt.js と AWS Lambda を使った理由は後述しております。

今のところは一部画面で旧来のFrontendに関しても並行で利用するために、旧来の構成中にあるnginxの設定により新Frontend / 旧来Frontend を振り分けるようにしています。本当は、CloudFront の Behavior を定義して管理したかったのですが、デフォルトだと25個までしか定義出来ないのと、パスのパターンに正規表現を利用することができないため、避けることにしました。

旧来Frontend の利用がある程度なくなったら、旧来Frontend の環境を縮退させ新Frontend環境のみで動作させる構成に切り替える予定でおります。

リニューアル第1段階。今の状況です。NAT、Batchなどは省略しております。


リニューアル第2段階。Frontendの環境がシンプルになります。

なぜNuxt.js か

2015年当時に比べると、Google Bot による動的ページの解析精度は上がってきていますが。しかし SPA における SEO対策には不安があります。特にコデアルのプロダクトオーナー愛宕はかなりそのことを気にしているようでした。そこで、最初の表示だけサーバサイドのほうでレンダリングを行い (Server Side Rendering, 略してSSR)、次のページ遷移からSPAのように振る舞うアプリケーションを目指したいということになりました。

新Frontend構築プロジェクト開始時は、シンプルに vue.js 2.x と vue-server-renderer を組み合わせるつもりで作っていたのですが、これがなかなか骨の折れる作業でした。各ライブラリのバージョン揃えや、ルール作りなど、悩ましいことだらけです。

vue.js SSR のドキュメントを読むと、こんなことが書いてあります:

これまでに議論されたすべての側面を適切に構成するプロダクション向けのサーバーレンダリングに対応したアプリケーションの開発は難しい作業です。幸いにも、これをもっと簡単にすることを目指す優れたコミュニティプロジェクト Nuxt.js があります。Nuxt.js は、Vue エコシステムの上に構築された高レベルのフレームワークで、ユニバーサル Vue アプリケーションを作成するための非常に合理的な開発エクスペリエンスを提供します。

なるほど。では使おう。ということで、使い始めることにしました。試作的に使い始めた当初は、まだバージョンがRC版で、情報も今ほどは見かけていない状態でした。バグもちらほら。。一方、今ではバージョンが1.4となり、プロダクションレベルでも大いに利用できそうです。

Nuxt.js には、SSR を実装するために必要なモジュールが全て入っていて、直ぐに開発を開始できます。Vuex, vue-meta, vue-router など、それぞれ、どの様にコードを配置するべきか、という標準も示しているので、迷いがかなり少なくて済みました。

なぜ AWS Lambda か?

コデアルというサイトは、瞬間的なアクセスが急にあがることは殆どありません。また、今のところは日本へ展開しているビジネスのために、日本時間で夜間中や早朝のリクエストは殆どありません。

年に1度あるかないかというTVなどでのメディア公開時に関して言えば、大量にアクセスがやってくるのですが、それはCDN (Amazon CloudFront) によって守られたという実績があります。これはサービス特性かもしれないですが、トップページさえ守れれば大丈夫そうです。

そんな背景もあり、ECSによって管理される常時起動のサーバを2つのAZに用意しておくのは、かなりコスト高だなぁと思っておりました。

また、旧来Frontendでは開発環境 (ConoHa 1GB 900円/月) に Docker を用意して、nginx-proxy を使いブランチごとに環境を用意する仕組みを作っています。しかし、この方法では残念ながら同時起動できるコンテナ数には限りがあります。同時並行で6ブランチほど開発していると最初のほうに作ったブランチの環境は消えるような挙動を入れていました。たまたま消えた環境がテスト対象だった場合、テスターから開発者に連絡が行きます。これではレビューやテスト作業がなかなか捗りません。なんだかんだでお手入れが必要な常時起動の環境もなるべくメンテナンスしたくないです。

そこで、AWS Lambda 上で1ブランチ = 1環境 (本番、開発、各作業ブランチ別に環境が立ち上がる。) という状態を作りました。手法的には、こちら。(ちなみに、Nuxt.js を serverless で動作させる方法はこちら。) 同時に存在する開発環境の制約は AWS Lambda や serverless で利用している CloudFormation の制約ということになります。 開発本線にマージされると、AWS Lambda からは環境が削除される仕組みも入れております。これにより、10ブランチぐらいが同時並行に開発されていたとしても、全ての作業ブランチがマージされるまでの間、動作確認が問題なくできておりました！

常時起動の開発環境よサヨナラ！これはなかなかうれしいものです。

また、幸運なことに最近 node.js 8.10 Runtime がリリースされました。これは Nuxt.js 1.x を動作させるための要求水準で、必要な項目でありました。node.js 6 で動作させるためには、Nuxt.js の 古いRC 版の利用が必要で、古いバージョンを使い続けるか、Lambdaのアップデートを待つか、Lambdaを使うこと自体を諦めるかすごく悩んでおりました。

1ヶ月ほど運用してみて、コスト感を再度みなさまにお知らせしたい思います。

開発の進め方

計画・開発・ふりかえりのサイクル自体は今までどおり2週間1スプリントのスクラム開発で行いました。そして、リニューアルにあたって、フルタイムなエンジニアとして木村さんを採用しました。今までフルタイムが私１人で、あと2名が副業という体制だったので、どうしてもやれる量に限界がありました。木村さんからは、生産性的な問題の解消だけでなく、技術的なフィードバックも多くもらうことができ、本当に助かっております。

また、デザインのやり方も大きく見直され、開発としては Zeplin で共有される情報を元に開発する体制になり、円滑にデザイナーとの協業ができる体制になりました！この辺をしっかり整備してくださった、デザイナー @tsubotax, @nikoko45 さんに感謝です。

コデアルなので、リモートワークも取り入れてました。平日は14:00に、zoom による Daily Scrum を実施してました。 (今まで副業の方メインなので出来なかった) 木村さんは新入社員だったこともあり、最初のころは週1日はオフィスで、週2日はどこかしらで集まり開発していました。今ではこの頻度は減らしつつあります。

デザイナーに関しては、初めて物理的にお会いしたのはプロジェクトが開始してから1ヶ月以上立ってからくらいには仮想的な状態でした。

開発中のものが、すぐに確認できる環境

前述の通り、AWS Lambda に各開発ブランチごとの環境をデプロイする仕組みを作っているので、作業中の状態は社内の人間であれば、すばやく・誰でも確認することができます。これにより、エンジニア・デザイナー・CS (Customer Success) チームそれぞれからのフィードバックを直ぐにもらえる体制を実現しました。

「開発中のものがすぐに確認できる」というのは、コデアルに関わっている当初から意識している設計で、今回も同じような環境を構築しました。

新Frontendのリリースにかかった時間

新しいアーキテクチャを作るにあたって、CS (Customer Success) チームから上がってくる要望を修正していく合間に、新しいFrontendの在り方の実験をおこなってきました。その間、そもそものブランドの定義見直し、デザインコンセプト・ガイドラインの作成、モックの作成、リニューアル範囲の決定などが行われました。具体的な次期としては、2017年10月〜2018年2月ぐらいになると思われます。

2018年3月くらいより本格的にコードが記述されていき、4月中旬〜後半はずっとテストやデザインの微調整作業が行われてきました。ここが弊社の辛いところですが、今の所QAエンジニアは不在です。従って、テストケース作成を自分が8割ほどやり、あとは受け入れテストを実施するCS担当の米瀬さんがQAもやるというあまり良くない体制となっています。米瀬さんは、ゲームのデバッカーか何かか? と思うほど、おもしろいバグをついてくれる素晴らしいテスト要員なのですが、本来の業務を超えてやってもらっているので、なかなかいつもツラいです。

コデアルではQAを手伝ってくれる人を募集しております。もちろん副業という形でOKです！

そして問題なくテストや修正をパスし、5月2日リリースとなったわけです。コーディング作業ベースでいうと、3人 (1人は副業で週10時間以内の稼働) で1.5ヶ月でした。計画なども全て含めて考えると半年くらいは動いています。

今後の改善

今回のリニューアルリリースでは「求職者様」向けの画面に着目しました。また、応募後のメッセージ機能に関しては、まだ現行のFrontendのものが表示されております。色味などは修正していますが、根本的な使い勝手には課題があります。したがって、次回以降は以下に着手します。

引き続き手伝っていただける、デザイナー、QAエンジニアを募集しておりますので、よろしくお願いいたします。

モバイルバージョンを終了