「良いサービスを作ること」を、常に全員が考えている組織

私は2016年の3月に、スマートニュースに入社しました。SmartNewsというサービス自体、もともとユーザーとしても好きなサービスでしたし、実際の現場を見ても、シンパシーを感じる所がありましたね。入社してからは、主にSmartNewsのニュース配信を行うバックエンド側の開発を担当しています。

弊社はUSの拠点も含めて60名強の組織ですが、半数以上はエンジニアで構成されています。

エンジニアに限らず、スタッフ全員がSmartNewsというアプリに対して愛情を持っているのが良いですね。普段からチャット上で、「アプリのここが良くないと思う」というディスカッションが自然に発生しています。

売上やユーザー数を伸ばすことも大事ですが、「いかに自分たちのプロダクトが良いものになるか」という視点を大事にしています。エンジニアも、自分のチームの都合ではなく、「全体としてSmartNewsをどう良くしていくか」を意識する人が集まっていますね。

「動けば良い」では終わらないエンジニアチーム

弊社は、30代以上の業界経験が豊富なエンジニアが多いのも特徴かと思います。技術者としてある一定以上の経験を積んできたメンバーが多く、やはり色々な成功と失敗をしてきているんですね。

そのため、「使いたい技術があるから、それをどう上手く使うか考える」というフェーズはみんな通り過ぎていて、「価値のある開発をしたい」という考えを持っています。

一般的に、サービス開発は単にモノが完成したら良い、動けば良いという話ではないですよね。ランニングコストが低いシステムを作ろうとか、利益が出るならもう少しお金をかけてもいいよねとか、そういったビジネス視点の判断ができる事が重要、という意識を持つメンバーが多いです。

SREチームを中心に、新しい技術も積極的に取り入れる

では、冒険せずに一番コストのかからない、慣れた方法しか取らないのかと言うと、そういうことではありません。常に新しいものを取り入れていく事によって、システムはより良くなるので、バランスを大事にしています。

例えば、最近ではDockerが使われることも増えてきています。

何か新しい機能を取り入れたいと思ったときに、Webサーバーや、データ処理をしてくれるバッチサーバーが一時的に欲しいというケースが増えてきて。そのため、Dockerを中心とした開発ワークフローに注目するようになりました。

そういった新しい技術の導入は、弊社のSRE（Site Reliability Engineering）チームが中心になって行っています。

もちろん、新しい技術の導入はサービス開発チーム、私の場合であれば「ニュースチーム」というニュース配信サーバサイドの開発チームの中から生まれることも多々あります。

けれど、基本的にはSREチームが横断的に、技術の検証や開発フローの整備、インフラの構築といったことを、サービス開発チームと連携しながら進めています。

SREのメンバーが常に新しい情報をキャッチアップし、情報共有ツールでそのメリット・デメリットを共有して共通認識を作っています。そして各サービス開発のチームで優先度の高い実際のニーズとの接点を考えながら、共通の基盤構築をリードしてくれています。

実際に、Dockerの導入も、AWSのEC2 Container ServiceをSREチームが試し、使い勝手の良いCLIツールも作り、社内でトライアルをして、という形で進めていきました。

リスクを考慮し、「プランB」も意識した技術選定を

技術やサービスの選定では、リスクを正しく見積もることも重要です。

弊社では、積極的に外部サービスを利用してサービスの構築を行っています。その中で、各サービスのリスク認識を持つこと、そしてもし何か問題があった場合にも、フットワーク軽く対応できるようなサービス設計を日々心がけています。

実際、過去にもサービス提供への影響を考慮して、利用する外部サービスを移行したことが何度もあります。「完全に満足するサービス」というものはなかなかないので、今後もメリットとデメリットを考慮しつつ、柔軟に対応していくつもりです。

▼SmartNewsの画面の一例

また、外部サービスの利用に限らない話ではあるのですが、エンジニアチームの中で常に「退路を考えておく」という考えが強いですね。ダメだったときにどうするかという、プランBを事前に検討することを意識しています。

サービス改善のために多くの取り組みを進めている中で、トラブルをゼロにすることは難しいです。しかし、何かトラブルが発生したときには、しっかりと振り返りをしています。

原因の調査、経緯の整理だけでなく「昨日のトラブルのクリティカル度を、4段階で評価するとどれくらいか」といった形で、実際のユーザ影響を重視した視点で振り返りをしています。

「マイクロサービス」も万能ではない！目的に合わせた手段を

SmartNewsは、細分化すると様々なサービスから構成されています。Webをクロールするサービス、クロールした記事を分析するサービス、そして実際にアプリに届けるサービスなどです。

いわゆるマイクロサービスのような構成なのですが、それに囚われすぎないように、「マイクロサービス」という言葉は使わないようにしています。

マイクロサービスって、目的としてはデプロイサイクルを変えたり、作業の影響範囲を小さくしたいというものですよね。ですが、モノリシックなサービスを分割していくと、徐々にやり辛い面が出てくるな、と過去の経験からも感じていました。

ひとつのサービスをあまりに小さい単位で分割しすぎると、個々のサービスのメンテを安定的に持続できるのか、という問題が起こりがちです。

頻繁に更新されるサービスなら良いのですが、年に一度しか触らないようなものだと、担当者があいまいにならないよう注意が必要です。そのあたりの管理をおろそかにすると、いざ問題が起きたときに、誰も対応できないという事態になりかねません。

今の弊社の規模だと、エンジニア同士がみんな名前を知っているし、誰が何を知っているかが分かる状態です。このような組織の場合は、役割分担しやすい形、かつ妥当な粒度での分割さえできていれば、サービスに分割されたアーキテクチャはうまく機能すると感じています。

それは別に「マイクロサービスだから」ではなくて、チーム構成や作業分担、コミュニケーションの問題だからかな、と思います。

マイクロサービスと言うと、すべての組織のすべてのフェーズで上手くいくような錯覚に陥りがちなんですが、それは違うと思います。組織に合った、適切な粒度にすることが大切です。

リモートワークは取り入れず、対面でのコミュニケーションを重視

また弊社では基本的に、リモートワークは取り入れていません。もちろん個人の都合によって出社時間を変えたり、柔軟性はありますが、基本的にオフィスに来て同じ空間で仕事をしましょう、ということを大事にしています。

チャット上でのテキストの会話だと、ニュアンスが正しく伝わらなかったりしますよね。口頭ならすぐ分かる話なのに、テキストだと無駄に議論が伸びてしまったり。それを避けるために、基本的に出社してコミュニケーションを取っています。

オフィス自体にも工夫がされていて、執務スペースとは離れた場所に、敢えてニューススタンドやカフェスペースを置いています。コーヒーを待っている間に会話をしたり、コミュニケーション不全が起きないような設計が意識されているんですね。

SmartNewsを全世界へ。今後もチャレンジを続けていく

今は海外展開にも力を入れているので、USのエンジニアチームとのコミュニケーションもより密にしている段階です。チャット上でもっと英語を使うとか、実際に会う機会をもっと増やすといった形で進めています。

今後の課題は、日本以外でも、当たり前のように同じクオリティーのサービスを提供していくことです。例えば、日本版で実装した機能をその次にUS向けにも提供する、ということではなく、同時に出せるようになっていければと思います。

そういった改善を続けながら、USに限らず、全世界で使っていただけるようにチャレンジを続けていきたいですね。（了）