こんにちは！ChatWork CTOの山本です。

チャットワークのバックエンドをPHPからScalaへの切り替えることを決断し、現在は移行に向けての大プロジェクトが進行中です。

バックエンドはScalaにしていく。じゃあフロントエンドはどうするの？ということで、今回はチャットワークのフロントエンド開発における今後の戦略を書いてみようかと思います。

現在のフロントエンドにおける課題

現在のJavaScriptコード量は、ざっと5万行ほどになっています。(OSSライブラリ、言語キーなどを除く。たぶん大規模・・ですよね？)

約5年前の開発スタート時より、素のJavaScriptとjQueryをベースにゴリゴリと書き重ねられ、これぐらいのコード規模になったソースコードはご想像通りメンテナンスコストがかなり高くなってしまっています。。。

バックエンドの刷新に伴い内部APIも一新されるため、どうせ大幅に書き換えるならモダンな技術で刷新することを計画しています。

特にJavaScript関連の技術はここ数年で大幅に進化しており、大規模開発のベストプラクティスも固まりつつあるように感じます。

強力なメンバーがジョイン！

そんななか、今月から強力なメンバーがChatWorkにジョインしてくれることになりました！

JavaScriptエンジニア養成読本の著者の一人であり、HTML5のエキスパートでもある 吾郷 協 (@kyo_ago) さんです。

吾郷さんにはもともとチャットワークをヘビーに使っていただいており、Chrome拡張でハックして独自(魔)改造していたものを本家に入れたい！ということで、さっそくすごいスピードで機能開発を進めてくれています。

現行バージョンの改善は順次進めつつも、モダンな技術をフル活用した次世代バージョンのフロントエンド開発を吾郷さん中心に進めていく予定です。

採用する技術やアーキテクチャの選定はすでにはじめており、まだ確定はしていませんが現段階で考えていることをご紹介します。

TypeScript、はじめます

まず、大きなところとして TypeScript の採用があります。

TypeScriptはAltJSと呼ばれるJavaScriptを代替する為の言語のひとつで、Microsoft社が中心となって開発を行っています。

JavaScriptは柔軟すぎて、小規模なうちはまだいいのですが大規模になるとどうしても保守性が悪くなりがちです。フレームワークの導入なども解決策のひとつではあるのですが、大人数で大規模に開発するには、大規模開発に向いているAltJSを採用した方がいいだろうと考えています。(このあたりは、バックエンドでPHPからScalaへ切り替えた理由と似ています)

AltJSには有名どころとして CoffeeScript、 TypeScript、 Haxe、 Dart、 JSX、 Scala.js などがありますが、「JavaScriptとの相互移行性」、「ツールの充実度」、「周囲の採用事例」、「情報の充実度」からTypeScriptを選択しました。

自動テストの推進、E2Eテストの導入

現在のチャットワークのコードではjQueryベースでDOMと連携するコードが内部設計まで浸透しており、純粋なJavaScriptとしてのテストを困難にしています。

TypeScriptで書き直す段階で出来るだけ内部設計とDOM構造を分離し、JavaScript単体でのユニットテストを行いやすい設計へ移行します。

あわせてブラウザのUIを自動操作してテストを行うE2Eテストも導入する予定ですが、維持管理コスト的にE2Eテストはできるだけ範囲を抑え、ユニットテストベースのテスト環境を充実させたいと思っています。

WebDriverを経由する予定なのでE2Eテスト用のフレームワークは言語に縛られない選択が可能ですが、ユニットテストはJavaScriptで記述する必要があることと、複数人で開発することから言語の分散は抑えたいためProtractor等のJavaScriptベースのフレームワークを検討しています。 （Protractorは AngularJS 用のE2Eテストフレームワークとして開発されていますが、AngularJSを使用しない環境に対してもテスト可能です）

WebDriverベースのJavaScriptフレームワークとしては他にも WebDriverJS や Nightwatch.js、dalekjs、Cucumber.js等がありますが、ユニットテストと近い形式でかけることと、情報やツールサポートの充実度からProtractorを検討しています。

最新のフレームワーク導入

現状のチャットワークではjQueryと独自で構築したUIライブラリをベースに、独自のフレームワークで実装されています。(一部、Backbone.js を採用している箇所もあります)

現在の実装方法は前述の通り内部実装がDOMと密接になりすぎてテストが困難となっているため、双方向バインディングをサポートしたフレームワークを導入することでDOMと内部実装を分離し、JavaScript単独での検証を行いやすい実装にしていきます。また、そうすることで厳密な型指定が可能となるため、静的型付け言語の恩恵をより受けられるようになります。

具体的に何を採用するかはまだ検討中ですが、静的型付け言語での静的解析が可能な範囲を増やすためにフレームワークは極力薄いものを採用したいと考えています。 現在検討している範囲では AngularJS は静的型付け言語との相性が高くないこと、React.js はコンパイル回数が増えることから、この2つはやや採用する可能性が低くなっています。

デザイン戦略の強化

そして、技術から少しそれてはしまいますが、外せないのがデザイン戦略です。

いかにフロントエンドやバックエンドの技術を刷新したとしても、使っていただくユーザーにサービスとして価値をつくり出せなければ意味がありません。

社内ツールとして一人プロジェクトからはじまったチャットワークは、自分たちが便利なものをつくろうという発想で開発が進められてきました。5万社を越える多くの企業様でご利用いただく規模になったいま、あらためてチャットワークというサービスの価値を問い直すことが必要になってきています。

これからのチャットワークを考えていくにあたり、この1年をかけて “チャットワークとは何なのか” “何がチャットワークの価値なのか” “ユーザーは誰なのか” ということを徹底的に見直してきました。

このデザイン戦略の強化にあたっては、Webとデザインに関わる多数の講演や執筆を行っている 長谷川 恭久 さんにデザイン戦略の顧問となっていただき進めています。

今年の7月に発表したロゴリニューアルがそのひとつの成果ではあるのですが、これからロゴや見た目のデザインだけではなく、機能面においてもより洗練されたものへと進化させていきます。

チャットワーク・セカンドステージに向けて

というわけで、バックエンドに続きフロントエンドでもコードを全面刷新していきます。デザイン面でもロゴやテーマカラーの変更にはじまり、ユーザーインターフェイスの総リニューアルも計画しています。

さらには、モバイルアプリにおいても現在の Titanium Mobile ベースのアプリケーションから、ネイティブ言語で完全に書き直したバージョンの開発が終盤にさしかかっている状況です。

なんでそんなに一気に全部刷新するんだ？と思われるかと思います。実際、私もそう思います。

はじめからScalaで、TypeScriptで、モバイルもネイティブで、大規模を想定して開発しておけば良かったんじゃないの？と思われるかもしれません。

これは成長していくWebサービスを4年半やってきて実感としてわかったことなのですが、最初の立ち上げ期から成長していくまでと、一定の規模になってからさらなる成長を目指す時期とで、必要としてくるアーキテクチャ・とるべき戦略は全く違ってきます。

例えると、はじめは小さな店舗でお店をやっていたのがどんどんと大きくなって、改築をくりかえすなか限界が来て、新しくしっかりした高層ビルを建てて引っ越そうということに近いかもしれません。

高層ビルを建てるときには、大きな重量を支えるためにしっかりとした地下の基礎工事が必要です。これは建物を建ててしまった後からはできません。

お察しの通り、コードをすべて書き換えるということには膨大な工数がかかります。ですが、ここで基礎をしっかりとつくっておくことで、ビジネスの現場を支えるインフラとして信頼していただけるサービスに成長させていけると考えています。

もうすでにその基礎工事は進んできており、来年にはまったく新しくなったチャットワークVer.2をお披露目できるかと思います。

これからのチャットワークの変化にぜひご期待ください！

(開発に参加したい！というエンジニア採用も絶賛募集中です！)