アプリもサーバも全部作り変えているところ

今井雄太氏(以下、今井):ではここまで皆様、サービスの現在の環境、そこに対してだんだんたまってくる不満とか改善したい点っていうのをお伺いしてきました。

ここから先は完全に仮定の話も含んでくるんですが、誰もが1回は考える「ガラッと作りかえられるとしたら? もしくは作り変えたことありますか?」。

あと「作り変えようと思ったけどやっぱりやめた、ちゃんと検討してやらないほうがいいという判断をした」とかですね。そのへんについてもしエピソードがあればお伺いしたいなと思いますが。

これはどなたか、もし「俺が」っていう方がいらっしゃれば。高橋さん、話したそうだね。

高橋三徳氏(以下、高橋):作り変えたいというか、いままさに作り変えていて、アプリもサーバも全部作り変えようと思ってます。横路さんのお話にもあったように、うちもマイクロサービス的に機能単位で絞ってサービスを作っていて、今その単位でチームを作ろうとしているところで。

アプリはもう本当に書き直さないといけないので、そこは今、死に物狂いでエンジニアをやっています。

今井:お忙しい問題です。

高橋:大変だなって。そうですね

今井:その作り変えにあたってすごい困ってるとか、そういうエピソードって何かあったりしますか?

高橋:設計思想とかコアな設計は、皆で決めるよりやっぱり1人に集中しちゃうなというところがあって、iOSをやっているリーダー的な人が主に設計をしてやってるんですけども、ちょっといろいろあって、いろんなプロジェクトが同時に動いちゃってその人がフン詰まってるっていう感じですね。そこが中々つらいなというとこです。

今井:ありがとうございます。これは多分次のディスカッションのテーマにもちょっと関連するかなと思うんですが、基本的にボトムアップというか、現場に権限・裁量を与えて、設計とか任せたほうがいいケースが多いんじゃないか? って話があったんですが。

今のケースだと設計は実際の現場の人に任せて、それはチームとしてレビューするとかどういうポジションを持って行くプロセスがあるんでしょうか?

高橋:レガシーコード書いた原因は僕だったりするので、僕がやるのはよくないなっていうところですね。スペシャリストが入ってくれたので彼をメインに。

ただ同時に走っちゃうのはなかなか難しいので、ボトムアップする方向でレビューを細かくしながらやってるっていう状況ですね。だんだん皆慣れてくるので、レクチャーがどんどん少なくなっていくっていう状況です。

今井:ありがとうございます。

容赦ない毎年のアップデートで書き直す、何千ものコード

今井:今村さんいかがですか? PHPからRailsに切り替えたっていうお話もありましたけど。

今村雅幸氏(以下、今村):サーバ側は、やっぱりエンジニアってどんな言語を書くかによってモチベーションが左右されたり、今だったら「こう書きたいんですけど」とかって結構いると思うんですけど、そういうの意外と大事だなっていうのがあって。

ちょうど、1番初め立ち上げたときに、前職で書いたフレームワークをそのままで作ったんですけど、やっぱりどうせ転職してくるんだったら「違う言語書きたい」みたいな熱い奴が多かったのでRubyに変えたっていうのがありますし。

実際Webのアプリケーション言語ってほとんど同じようなところがあって、そこであんまり皆嫌がらずに書いたっていうのはありますよね。

Web側は何とかなるんですけど、僕らはアプリのほうも結構力入ってるんで、例えばAndroidアプリとiOSアプリと、もう今とんでもない膨大なソースコード量になっていて。AppleとGoogleは毎年毎年容赦ない感じで、SDKを丸ごとアップデートしてくるんで。

そうなってくると今までiPhoneだったらデバイスが2種類しかなかったりiPadだって1種類しかなかったんですけど、もう今意味わかんないくらいのサイズがでてきて、そもそもタブレット対応してないとダメですよとか、あとiPhoneだったらオートレイアウト対応とか。

しかもさっきのビューコントロールの話じゃないですけど、そもそも設計を全部変えないと何千というコードを全部書き直すようにならないといけなくなって。でもやらないとやっぱり、例えばAndroidで対応しないと明らかにもう周りのアプリの見栄えが変わっていって。

Webだったらあんまり見れないんですけど、アプリだったら明らかに対応してないとわかっちゃうじゃないですか。

そうなってくると、せっかくいいアプリ作っても意味がないのでそこはもう無理矢理プロジェクトを切ってタスクフォース組んで今回は一気に対応します、ってやったりしてますね。

そこはもう意地で、コースを隔離してやってます。

高橋:Swift(iOS・OS Xプログラミング言語)とかって?

今村:Swiftは、やっぱり現場も書きたいって思う瞬間はあるんですけど、さすがに今全部書き直すのはほぼ不可能なんで。ウォッチ対応とか、結局できるところからだけやるようにしました。

今井:ありがとうございます。僕自身がもともとサーバサイドのエンジニアだったので、結構サーバサイドの言語の切り替えとかってすっごい大変な話だなって思っちゃうんですが。

今聞いたお2人はやっぱりサーバサイド側はあんまり言語の切り替えとか、アーキテクチャの切り替えにそれほど大きな苦労はしていなくて、どちらかというとクライアントサイド。

まずスピードを持って作ったもののところに負債がたまっていって、それをどうするかっていうお話だったのかなと、お2人にお伺いして思いました。

インフラエンジニアの役割が変わってきている

今井:ではこちらのお2人にお伺いしていきたいんですが、横路さんからお願いできますか?

横路隆氏(以下、横路):freeeではエンジニアが30名に増えて、しかも会計についてはもうかなり大きなモノリシックシステムになってしまっているので、今スクラッチから作り変えるのは結構難しいし、そこまで価値を生まないかなと思ってて。

その代わりに機能ごとにチームを分けて、アーキテクチャも完全には分けられないんですけどそこも分けていって。

それにあたって今インフラエンジニアが30名のうち2名なんですけど、各機能ごとに要件があったとき、例えば「OCRやりたい」って言ったらOCRサービスを動かすサーバを立てるとか、そういった要求に逐次対応してるんですけど、実はそういうのって今後はアプリケーションエンジニアの仕事なんじゃないかなっていうのがあるので。

どっちかっていうとインフラエンジニアは、各ファンクションごとのアプリケーションエンジニアが運用まで含めて見られるように、社内サービスの依存関係の解決をサポートする簡易社内PaaSのようなものを提供できるチームにして行きたいなっていうのはありますね。

それについては課題も多いし、やることは山積みなので、そういうのは数年かけてやっていきたいなと思います。

今井:ありがとうございます。今インフラエンジニアの役割が変わってきてるっていうのすごいおもしろいお話だったのかなと思ったんですが、これから作られるっていうお話ですけど、簡易社内PaaSって例えばどんな機能ですか? 

横路:例えば、課金と認証サービスっていうのはどのサービスからでも叩かれるんですけど、そういったものをうまく抽象化して、ただ入れるだけで使えるとか、ボタン一発で他の依存システムを上手く起動して利用できるようにするとか、簡素なHerokuプラグインみたいな感じで社内の他のシステムを使えるイメージです。

今井:ありがとうございます、すごくイメージがつきました。

メンテナンスの時間が難しいカップル達の事情

今井:では椎名さんお願いできますか?

椎名アマド氏(以下、椎名):さっき結構ネイティブの話をしたんで、ここはサーバっていうかバックエンドの話なんですけど、うちは1番最初は全部EC2インスタンス1台だけでやっていました。その中にMySQL置いてて、そのあとMySQLをEC2インスタンスにして、それからRedisも別でEC2立ててみたいな。そこから今度はMySQLをRDSに変えた。

そのあとRedisの中身が肥大化していって、今度はRedisの中のチャットデータをDynamoDBに移管しました。バックエンド、結構コロコロ最近変えてるんですね。それは僕らとしてはやっぱりEC2自分らでやるよりAWSさんのマネージドのサービスに乗っかったほうが、人件費やセキュリティなどいろんな面で効率的だなって思ったからですね。

これからも多分それは続いていきます。、直近ではAuroraとかの様子は見ていたりして。もし、今プレビュー版ですけれど本リリースで結構いい感じだったら、それはもはやRDSのから乗り換えたいなっていう思いとかはあります。

ただそういうのにあたって悩みになってくるのは、特にマスターデータベースを定期メンテだとしても、うちのサービスって全然落とせないんですよね。朝4時に5分メンテするとか言っても、朝4時ってカップルによってはお互いベッドの中で「会いたい」ってチャットを送り合ってる時間なので。

(会場笑)

そのタイミングでPairyの代わりにLINEで送り合って、そのままユーザーが戻ってこない、なんて可能性もある。だから結構そこらへんがシビアで、バックエンドを考えるにあたって、いつメンテをしていいとか、絶対にしちゃダメとか、課題になってますね。

今井:クリティカルですね、ミッションクリティカル(笑)。平日の午前中とか、ダメなんですか?

椎名:うーん、ギリですね。そういうときも「今夜何時に待ち合わせる?」みたいな会話があったり。カップルにとってのコミュニケーションインフラになっている限りはどの時間でもすごく慎重に考えないといけないです。

今井:ありがとうございます。結構この質問、何かわりとガラッとっていうのが最初にあってわりと「ビッグバン的にドーンと取り換えた」みたいなエピソードが出てくるかな、もしくは「考えたけどそんなん絶対できない」みたいな話が出てくるかなと思ったんですが、結構皆さんサービスとかライブラリをすごく小さく管理されていて。

サーバ側・もしくはサーバ側の一部から切り替えて行くとか、アプリのネイティブ側のコードの問題はあるにせよ、キレイにコンポーネント化していて、そのおかげでシステムのアーキテクチャ的な柔軟性はすごく高い運用されているのかなというのが私の感想です。

各社それぞれの技術環境や負債への取り組み

今井:ちょうどご用意した質問というのは以上です。ラップアップしますと3件ですね。

皆様の今運用されているサービス自体のご紹介とその技術的な関係ですね。主に言語とフレームワーク等のお話をいただきました。このときは主にスタートアップする時に「人をいかに集めやすいか」もしくは「学習コストがいかに低いか」みたいなところが皆様の選定の背景だったのかなと思います。

次、今の環境への不満や改善したい点を教えて下さいということで、いわゆる技術的負債みたいなところに、今の質問を設定させていただいたんですが、ここに関して言いますと、今回特に目立ったのはネイティブアプリ側ですね。

特にここがやっぱり人のイシューというか、人の問題といっちゃあれですけど、そのチームとしての課題みたいなところが見えてきたのかなと思っていて。

ネイティブアプリは最初人とかすごい少ない人数で開発を始めてしまうので、それによってパートナーのコントローラーとかリファクターが必要な大きなアプリケーションができ上がってしまうっていうのが、ここで出てきた出来事になってきたお話だったのかなって思います。

一方Freeeさん、横路さんのケースだとサーバ側のアーキテクチャをマイクロアーキテクチャみたいなかたちにされ切って。あと高橋さん、SpotLightさんですね、マイクロアーキテクチャみたいな感じになっていると、サーバ側の構成変更みたいなことはすごく柔軟にできてきているのかなというのが感じたことです。

「ガラッとやったことありますか、やりたいですか? ・やりたくないですか?」という最後の質問に対しては、結構柔軟になってるんでそもそもガラッとってあんまりないよね、みたいなのがここで見えてきたお話かなと思います。