開発ブログの更新が久々になってしまいました。弊社は一時期と比べると開発体制は縮小しながらも、多くの企業との協業等も引き続き進めており、各方面でチャレンジの機会をいただいています。

2023年冬には、弊社の主要サービスである「FiNC」アプリが大幅にリニューアルされました！「生活動線にあるアプリ」として、歩いてガチャを回しマイルを貯めるという体験を中心に、健康管理を楽しく続けられるアプリに生まれ変わっています。

ヘルスケア/フィットネスアプリ「FiNC」が大幅リニューアル 新機能としてデジタルギフト等と交換できる「FiNCマイル」が登場！ 〜食事記録など健康行動を記録した回数で「行動健康ランク」が変動し ランクに応じて交換できる商品が変わるシステムも新機能として追加〜 - FiNC Technologies（フィンクテクノロジーズ） | モバイルヘルステクノロジーベンチャー

詳細はぜひアプリを触ったり、記事をご覧ください。今回はリニューアルに伴い開発サイドで起きた話を紹介したいと思います。

開発の歴史

弊社のサービスローンチ期である 2016 年前後は「マイクロサービスアーキテクチャ」がトレンド化しており、海外では Netflix が大きな成果をあげたことで有名ですが、国内でもメルカリ等 多くの採用事例が続き話題となっていきました。弊社もマイクロサービスを採用し、当時においては比較的先駆者として様々なプラクティスを導入してきました。

開発チームの拡大に伴い、それぞれ開発のしやすさやデプロイ速度を優先し機能や案件に応じて サブスクリプション機能を管理するサービス、チャット機能を管理するサービス、健康プログラムを提供するサービスといったようにサービスはどんどん増えていきます。

気づけば、大小あれどサービス数は 60 以上に..
結果としてそれに詳しい人が不在になる多くの「無人化サービス」が発生することになりました。

いわゆるマイクロサービスのメリットとして挙げられる「開発規模を小さくできる」や「障害の分離」「技術採用の自由度」は一定享受できた反面、近年は組織規模に対して増えすぎたサービスのメンテナンスコストが無視できない状態となっていました。2023年から3代目 CEO / CTO 体制になったこともあり、根本的な課題に向き合う風潮が強まっていきました。

「FiNCが直面した」マイクロサービスのデメリット

【運用面】

• ライブラリ管理、アップデートコスト
  - そもそもどの機能に何が使われているのか把握するのが困難
  -アップデートの抜け漏れ
  - 直近実施した ruby update においては対象のサービスが全てリリースされるまで約 8 ヶ月かかった..（実施決定 -> 割り振り -> 各チームスプリントの合間に対応 -> テスト -> 修正 ->リリース）
• 監視コスト
  - アラートチャンネルのメンバー管理も含む
• 各サービスに散らばる管理画面
  - サービスを跨いだ認可の仕組み作りが非常に難解
  - CS や運用担当者はいくつもの管理画面を駆使する必要がある
• データの一貫性を維持しにくくなる
  - 一貫性や整合性担保のための適切な知識を有することは重要だが、どうしても設計や実装コストは上がってしまう

【学習面】

• ドキュメントがあったりなかったり、形式が揃っていなかったり
• 環境構築するのも一苦労。4, 5 サービス立ててはじめて動かせる機能も
  - 各チーム局所最適でマイクロサービス化を推進したことで、サブスク有料会員や法人会員（法人向けサービスである FiNC for BUSINESS の一部ご利用者も FiNC アプリを使用している）の管理等が分割されている
• サービスを跨いだ共通の決まり事がなく、チーム単位で新しい技術を各サービスに導入。推進派が退職等で不在になると、当該技術の採用の目的や背景が不透明なまま、言語やフレームワークが散らばった状態に

【インフラ・保守面】

• 監視の分散、ダッシュボードの複雑化
• コスト負担
  - Rails というメモリを食いがちなプロセスに加え、コンテナを大量に建てる必要がある -> 必要とされるサーバスペックが大きく、コスト増となる

サービス分散の苦い経験を踏まえ、社内の開発組織・チーム形態に合わせて、モノリスとは言わずとも程よい数・規模のマイクロサービスへの集約を目指すことになり、今回のアプリリニューアルを機に必要機能を既存の 1 サービス内に構築していく「モジュラーモノリス」の選択肢を考えるようになりました。

モジュラーモノリスとは

マイクロサービスのように複数のサービスを別アプリケーションとして完全に分離するのではなく、アプリケーションの内部を「モジュール」という単位で分割したアーキテクチャスタイルを指します。内部的な分割にとどまるため各システムの独立性をある程度保ちつつ、モノリスのように1つのデプロイパイプラインを維持する特徴があります。

分割の実現方法

弊社では Ruby 製のアプリケーションが多く存在しますが、同一アプリケーション内にあるモジュール間での呼び出しをどのように制御するかが一番の鍵となります。モジュール間で意図しない、または無作為な呼び出しが許容されるとさらにアーキテクチャが破綻していくのは明らかです。

そこで今回は Shopify 社が提供している packwerk という gem を利用することにしました。packwerk はパッケージという単位のファイルグループを作ることができ、パッケージ間の呼び出しを静的解析でチェックします。

チェック方法は `bundle exec packwerk check` コマンドを実行するだけで、CI に組み込むこともできます。 検査の結果違反があった場合、下記のいずれかのアクションを取ることになります。

• package.yml に依存関係の設定を追記する
• 違反のあるコードを解消する
• deprecated_references.yml に未解決事項として記録する

packwerk 採用の背景

今回「脱マイクロサービスPJ」が社内で立ち上がったわけではなく、あくまでアプリのリニューアルを機に消せるものは消そう、無作為に増やすのはやめようという背景があったため、最優先すべきことはあくまで「リニューアル開発」でした。そしてリリース日は関係取引先とも握っているため、開発納期は変更不可なものとしてこれらの活動を進める必要がありました。

その中で、採用を決めたポイントとして以下の点が挙げられます。

• 導入事例やデモが割と充実しており、試しに触った際にさほど迷わずやりたいことが構築できた
  - 公式ドキュメント に加え下記の導入事例等 参考にさせていただきました
  ◉ モノリシックRailsアプリケーションを モジュラモノリスへ移行している noteの事例
  ◉ モノリスなRailsにモジュラーモノリスを導入した話 — hacomono TECH BLOG
  ◉ タイミーはどのようにしてモジュラモノリス化を進めたか
• 依存関係の可視化が可能
• モジュールの独立を段階的に実現していくことができる（前述の通り未解決事項を記録しながら進められる）
• 独立サービスとして切り出す方が適切とされた場合、実装構造的に切り出しが容易である

導入してみた感想

結果的に FiNC アプリのリニューアルで新たに「マイル」「景品」「ガチャ」「ランク」等の機能を実装する必要がありましたが、それらは全て既存アプリケーションの 1 モジュールとして実装されました。

1 からインフラ整備がいらないので、開発初期からそれなりに開発速度を出せた中で、取り組みを進めていたリニューアルチームが遭遇した問題や課題を以下に書きます。

• 特殊なディレクトリ構造になるため初見の人には驚かれる（特に※部分。社内周知やドキュメントが必要）

package.yml
app/ # 非packageコード
  models/
  ...
packages/ # packageコード
  my_domain/
    README.md
    package.yml
    deprecated_references.yml
    app/
      public/ # public IF for 同リポジトリサービス
        my_domain/
                # ※ packages直下のmy_domainはあくまでpackage分割ディレクトリとして機能しているので
                #   MyDomain::XXXというnamespaceにするには、さらにmy_domainと切る必要がある。
                #   またpublic classであることを明示するため、導入事例を参考に弊社ではさらに「public」というnamespaceを切る運用にしている。
          xxx.rb
      services/ # privateサービス
        my_domain/
          private_service.rb
      models/ # privateモデル
        my_domain/
          private_model.rb
      controllers/ # API for 非同リポジトリサービス
      ...
    spec/
    ...
  my_other_domain/
    ... # 構造は同じ

• packwerk の README に記載がある通り、いくつかの違反検出が漏れる可能性がある
  - 引数で別パッケージのオブジェクトを受け取っていた場合等

GitHub - Shopify/packwerk: Good things come in small packages.

• パッケージの css を変更しても cdn 経由で取得できる css ファイルが入れ替わらない
  - asset version の検出に含まれていなかったことが原因だった
• パッケージの spec が CI で実行されてなかった
  - 各自手元で該当 spec を実行後 PR 提出や開発環境へのデプロイを行なっていたものの、パッケージの spec が CI 上実行（指定）が漏れていたことに途中まで気づかなかった..
• CI 実行時間が長くなる
  - 1 サービスに複数機能が包括されコード量が増える分、特に spec の実行時間が数十分と長くなる問題があった。そこで、master 以外のブランチでは変更のあったパッケージの spec のみを実行するようにして時間短縮を図った。

これらいくつかの問題や課題に遭遇しましたが（アプリケーションの設定や作りによるものもあると思います）、導入して約半年が経過し概ね期待通りの役割を果たしてくれていると感じます。

まとめ

今回アプリのリニューアルを機に、マイクロサービスに固執せずモジュラーモノリスでのサービス運用を開始した事例を紹介しました。今後もしばらくは増えすぎたサービスの統廃合を平行して進めていく予定です。

サービスを増やすことは必ずしも悪いことではありませんが、適切な設計（これ自体の難易度もかなり高い）と運用組織体制があり、それらが中長期的に継続されることの上に成り立ち得るアーキテクチャであることを数年かけて身をもって体験しました。今後も外部環境も含め、事業・プロダクトの進化に合わせて適宜リアーキテクトを行っていきたいと思います。

我々は “Design your well-being” を掲げ、若手のリーダーシップと突破力、経験豊富なシニアの知見の両方を武器に、人々のwell-being を支えるプロダクト開発を推進しています。採用も進めておりますので、まずはカジュアル面談からでもお気軽にご連絡ください。

募集要項はこちら

モジュラーモノリスへ ~過剰なマイクロサービスの統廃合に取り組み始めた話~ was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

FiNC Technologies (以下、FiNC) の プロダクト本部 企画グループ グループマネージャーをしている Ryusei （@ryusei_i_1025）です。
エンジニア業務をしながらPO業務に従事しております。

2022年は社内施策として、データ分析の民主化を進めてきたので、その振り返りと成功した点、改善点をご紹介します。
見出しだけでも読んでいってください。

分析の民主化により、社内の分析を増やす

分析を民主化し、PDCAの速度を上げたという事例が増え、「データの民主化」「分析の民主化」という言葉がここ数年で、よく使われるようになりました。

「分析の民主化」について、詳細の説明はここでは省きますが、

「分析チームだけでなく、セールス、マーケッターなどビジネスサイドや、PO・PdMが自らデータを可視化し、分析をして仮説の検証や課題の特定を行なえる状態」

を社内では民主化として定義しました。

FiNCでも民主化が必要になり、プロジェクトが始まりました。
まずは必要になった経緯から説明させてください。

民主化をしないと属人化とスピードの低下を招く

2022年からデータの担当は私1人になりました。
とはいっても、私はエンジニアリングがメインなので、兼務になります。
兼務しているので、以下の3つの問題が起きます。

・自分のリソースの取り合いによるコスト
・知識とスキルの属人化
・自分がスピードのボトルネックになる

① 自分のリソースの取り合いによるコスト

兼務している状況では、エンジニアリング業務とデータ業務の優先度を天秤にかけます。
エンジニアリングとデータ業務では、管理部署も別で、優先度が比較しづらくなります。
そういった状況でリソースを取り合うので、優先度調整やコミュニケーションのコストが増えます。

② 知識とスキルの属人化

また1人で担当しているので、データに関する社内の知識を私だけが習得していきます。
タスクも1人で行うので、スキルも属人化します。
知識とスキルの属人化は、業務のブラックボックス化を招いたり、もし私が抜けた場合に、スピードが落ちてしまう危険があります。

③ 自分がスピードのボトルネックになる

属人化とリソース調整の結果、私がスピードのボトルネックとなります。
データの依頼が来てから、アウトプットのすり合わせなどのコミュニケーションから始まり、フローの中では、私のリソースがスピードのボトルネックとなります。

顧客企業からデータを求められるセールスの方や、施策の振り返りを行いたいPdMやプランナーの意思決定を遅くしてしまいます。

このような問題から、社内での民主化施策を進めていくことにしました。

民主化施策の3つの軸

民主化には3つの軸を意識して進めていきました。以下、3軸を説明したいと思います。

民主化の軸1: スキル獲得

民主化にはまずデータを扱うために、ある程度専門的なスキルの習得が必要です。
FiNCではRe:dashをBIツールとして使用しているため、SQLの習得がメインとなります。

データ分析のためにスキルの獲得は以下を行いました。

・データ取得に必要なSQLの習得、データベースの考え方を学んでもらう
・ハンズオンを行ったり、実案件を通して学ぶ
・スキルレベルやレベルに合ったスキル定義を作り、学習イメージを作ってもらう

1–1 データ取得に必要なSQLの習得、データベースの考え方を学んでもらう

社内の資料を使って、テーブル、レコード、カラムといったデータベースの基本的な知識や、簡単なSQL操作の書き方を学んでもらいました。

アクティブユーザーや食事記録データといった社内でよく扱うデータを使って、小さく始めて、まずはSQLや構造化データのイメージを掴んでもらうのが目的です。

SQL ZOOやProgateなどSQLを学べるサービスもスキルの獲得に有効ではありますが、社内のデータとBIツールに慣れるためにも、実際のデータを使って学ぶのが良かったかなと思います。

1–2 ハンズオンを行ったり、実案件を通して学ぶ

ある程度、基本的な知識が身についたら、実際の簡単な案件でSQLを書いてもらいました。

例えば、
・普段使っているクエリの条件の追加・変更
・すでにあるクエリAとクエリBを組み合わせて、新規クエリを作成
・サブクエリが2,3個で収まるような新規クエリ
といった少し簡単な案件で、実践してもらいました。

クエリを書き始める前に、どうすれば最終的なアウトプットが完成するか、どのテーブルを使って、どの条件で、どのカラムを使用するかなどを細かく言語化してもらうことが重要です。

プロセスをできるだけ自身で考えてほしかったので、私はレビューやクエリのヒントやアプローチの方法だけをお伝えするのみでした。

1–3 スキル定義やスキルレベルを作り、学習イメージを作ってもらう

数ヶ月学習していくにあたり、学習の継続や挫折をしないように学習のロードマップをデザインしていくことが重要だと思います。

弊社では、スキルのレベルとその定義を作成し、ステップバイステップで習得していくイメージを持ってもらうことにしました。
レベル分けすることで、自分の現在地や中間ゴールを認識してもらい、学習の計画を立ててもらうことが目的です。

「〇〇さんは今このレベルくらいなので、このクォーターではこのレベルまでいってみましょう」という会話ができると、目安がない状態で習得を目指すよりも、具体的なイメージがしやすいと思います。

民主化の軸2: ナレッジ拡散とアクセシビリティ

スキルがあっても、社内固有のデータの知識、どのデータがどこにあるかを把握していないとスムーズな業務遂行ができません。
なので、ナレッジ拡散とアクセシビリティという軸で以下を行いました。

2–1 データに関する知識、データの居場所などがアクセスできる状態を整備と周知

まずは暗黙知を形式知に変えるため、データの出し方、テーブル定義などのドキュメントを作成、更新をしていきました。
よく使用されるデータを中心にドキュメントを作っていきました。

ドキュメント作っても、それが周知されない限り活用されないので、先人たちが作ってくれていたポータルページを更新しました。

ドキュメントにしておくことで、私の説明の負担も減り、データ分析者が1人で解決できる状態が増えました。

ただし、ドキュメントは作るだけではなく、根気強く周知していくことが重要です。
SlackでURLをお渡しするのと同時に、「ここを見たら解決するよ」と声をかけ、ポータルページの存在を伝えていくことにしました。

民主化の軸3: データ抽出の環境整備

データを扱う際に、データ基盤が不安定だったり、データが探しづらい状態だと、クエリ作成の難易度が高くなります。
FiNCもそういった状況だったので、少しずつ以下の改善を行っています

・安定したデータ基盤・インフラを整える
・いらないものは捨てる

3–1 安定したデータ基盤・インフラを整える

FiNCでは、データの更新を自動化させるため、Re:dashで自動更新の機能を使用しています。
定刻になると、Re:dashのスケジューラがクエリを自動で実行し、最新の状態にアップデートします。
その時間帯で度々、キューが積まれすぎて、分析者がクエリを実行できないという状況が置きました。
また、負荷の高いクエリが連発されると Re:dashサーバーがダウンすることもありました。

なので、Re:dash内で使用するRDSのスペックを最適化したり、キューが積まれすぎたときに、クエリを停止させるスクリプトを作成し、誰でも復旧ができる状態にしました。まだまだ安定しているとは言えないですが、少しずつ改善を続けています。

3–2 いらないものは捨てる

FiNCでのデータ基盤では、以前は使用していたが、現在使用していないクエリやテーブルが多く存在していました。

似たテーブル、似たクエリがたくさんある状態だと、データを扱う人たちが、使用したいテーブルが探しづらいという課題があったので、定期的に使用していないテーブルの削除を行いました。

結果として、テーブルの調査のしやすさは多少は改善されました。

結果、事業部ごとに1人以上は書けるようになり依頼が減った

始めてから1年弱経ち、結果として事業部ごとに1人以上はSQLを書けたり、ダッシュボードを作成できるようになり、私の負担はかなり減りました。

今はクエリのレビューやデータの調査、たまに依頼を受けるくらいにはなりました。
時間を作って、チャレンジしてくれた方に本当に感謝しています。

実際に、チャレンジしてもらった3名の方に感想をいただいています。

ケース1. プロジェクトマネージャー

得られた成果

「仕様検討や集客分析において、より深く検討でき、なんとなくでの検討はなくなった。」
「社外への説明時に説得力が増し、信頼にもつながっていると思う。」

難しいと感じられた点

「トライアンドエラーで何度もやっても、エラーが出続ける。」
「よく使うテーブル（アクティブ情報や記録データ）などは良いが、あまり出さないデータは、どのテーブルを参照すれば良いかわからず、戸惑った。そういった場面ではデータ出すのが手間に感じてしまう。」

今後の展望

「よりスピーディーに、よりいろんなデータを出せるようになっていきたい」
「同じ職種のメンバーにもどんどん広まっていってほしい。そのために自分も教えられるだけの理解を深めていきたい。」

意思決定の判断材料として、データを扱えるようになり、説得力が増したとのことでした。
構文や書き方が誤っていて、エラーが出続けること初学者にとってはたしかにストレスです。
このエラーが出たらこう解決するというFAQページがあってもいいなと思います。

ケース2. プロダクトマネージャー

得られた成果

「データ分析依頼の連絡や待ち時間の手間が省け、その分、自分で書く時間は増えましたが、総工数は、依頼してた時とさほど変わらない程度になったと思います。」
「初動調査が手軽に行えるようになりました。小さな調査でも依頼をしないといけないので、やや尻込みしがちになる時もありましたが、分析に積極的になり、よりデータを活用する機会が増えたことが良かったと思っています。」
「インシデントやお問い合わせ対応等の初期調査についても自分で行えるようになったので、原因の切り分け等にも役立っています。」

難しいと感じられた点

「データソースのテーブル毎の特性の理解（マイクロサービスによってタイムゾーンが違う等）」
「JOINの種類の理解（ドキュメントを見ても、直感的に理解できず苦労した。実際に結果を見て『なるほど、こう指定したらこうなるんだ』を繰り返し、試して理解した。）」
「『型』の理解。whereで期間を絞る時などに、date型に変換する必要があるかどうか。これも既存クエリを参考に実践しながら理解した。」

今後の展望

「効率的な書き方ができるようになっていきたい。今はまだ抽出手順をそのまま順に書いているだけなので、より効率的な書き方や負荷に優しい書き方などができるようになっていきたいです。」

データに対するハードルが減り、分析だけでなく、問題解決にも活用ができるようになったとのことです。
ここで身につけた知識が、分析以外にも役に立ったというのを聞いて、大変嬉しく思います。
一方、SQLの挙動や型の理解が躓きやすいポイントとのことでした。

ケース3. プロダクト運営、プランナー

得られた成果

「部署で見たい数値やインシデントの影響範囲を短時間で参照できるようになった。エンジニア頼りの体制からの脱却に役立っているはず。」
「 思わぬ副産物としては構造化の練習にもなった。クエリを書く際には最終的に得たい結果を因数分解していくが、どこの数値がどう結果に繋がるかを整理することにもなり、KPIの試算や施策の設計などの場面でも役立っている。」

難しいと感じられた点

「自分の日常業務に頻繁に登場しない関数（LEAD関数などのウィンドウ関数]）の使い方」
「どこまでやって、どこで躓いているのかを明確にした上で、さっさと有識者に聞いてしまうのが自分なりのコツ」
「自分の日常業務で使用するクエリは共通点が多く、既存のクエリがいい教材になった」
「最初は部分を書き換えることから始めると思うので、自分も流用しやすいようクエリにコメントを残すようにしている」

今後の展望

「使いまわせる便利なクエリを残す」
「練習で量産された類似/不要クエリや古いテーブルを参照しているクエリを整理したい」
「人のクエリのレビューができるようになる」

やはり、自部署のデータがすぐに見られることのメリットは大きそうです。
データとかSQLだけではなく、分解して考えるといった思考トレーニングとして役立っているとのことで、予期せぬ成果でした。

Tips: 有志より公式にせよ

民主化のための施策ではないですが、FiNCでは公式プロジェクトとして進めることがうまくいった一つの要因だと思います。

社内でも、数年前に有志で行っていたこともありましたが、いまいちアクセルを踏めてなかった状況でした。
実際に私もそうでしたが、「時間がないから、後でやります」が通りやすくなったり、モチベーションの継続が難しかったりなど、やらない理由ができてしまうからです。
過去のこの経験を踏まえて、公式なプロジェクトとして進めました。

CEOやCTO、VPoEなどに相談しながら、経営会議、全社会などでもプロジェクトの共有をしていただきました。
その結果、担当者が所属している上長、チームリーダーなど、周りの人の理解を得られるようにしました。

さらなるレベルアップと学習コストの逓減へ

まだまだ道半ばですが、よりデータを扱える人を増やしていく活動は続けようと思います。

習得した人たちをさらに引き上げる

基本的なスキルを習得していただいた方がもっと、高度なデータ集計ができるように、引き続きサポートをしていきます。
応用的な関数、クエリのレビュー、パフォーマンスや可読性を意識してSQLを書ける人を増やしていくことを目指します。

さらなる学習のナレッジの蓄積

学習の際につまづいたこと、こんなものがあったら良かったなど、学習を通しての反省を残していったり、教え合う機会を設け、社内での学習の効率化をしていきます。
習得してくれた方たちが、また別の方を教育できる状態を目指します。

データ分析の民主化を成功させる3つの軸 was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

僕はエンジニア1年目なのですが、FiNCのマイクロサービスの最古の巨大サービスのリファクタリングをしてきました。
その内容と学びを一部ご紹介します。

FiNCでは、マイクロサービスを採用しています。
それぞれのチームがサービスのオーナーとなって、担当サービスをプロダクションレディとなるように管理しています。
大抵、マイクロサービスの中には、巨大な神サービスが存在すると思いますが、
僕が所属するチームは、2021年4月にこの最古の巨大サービスの担当になりました。

このサービスは、FiNCの歴史を物語っています。2013年に作られてから、現在までFiNCの中枢機能として、ビジネスを支えてきたサービスです。
現CEOの 南野 (@tentenmitsunori)、CTOの篠塚 (@shinofumijp)、VPoEの鈴木 (@kenjiszk) がコミットしてきた履歴があります。
会社の規模に合わせて、このサービスは大きくなっていく一方で、使われないコードや負債となってしまった部分もあります。
この巨大サービスをリファクタリングするプロジェクトがスタートしました。

プロジェクトが始まった経緯

2021年3月に、「あるAPIのパフォーマンスが悪いので直そう」という提言がSREチームからありました。
そのAPIでは、一般ユーザーには不要な、他のマイクロサービスへ毎回問い合わせているなどの問題が表面化しました。
また使われていないAPIが無数にあること、過去の知識が失われて、使われているのかどうかわからないコードをリファクタリングしていくプロジェクトが発足しました。

4月から週次で時間を取って、アプリケーションチームとSREチームでコードリーディングを始めました。
まずは、重要と思われるファイルを1つずつ読み、コード上にコメントを残したり、デッドコードを消したりしました。

プロジェクトで行ったこと

リファクタリングは、僕の先輩であるアプリケーションチームのリーダー主導で進んでいきました。その中で行ってきたことをいくつかご紹介します。

コメントを追加しながらコードリーディング

認証周りなど複雑な処理を行なっているメソッドで、毎回処理を読まなくてもわかるように具体的にコメントを入れていきました。
すぐにリファクタリングできるものは、その場で書き直しますが、影響範囲の大きいものやリファクタリング方針がすぐに決まらないものは一旦コメントを入れたりしました。

コードリーディングはペアプロ的に行うことが多く、情報を全員で出しながら進めていきました。

既存コードの可読性をあげる

例えば、各APIクライアントのclassに散らばっていた依存先のendpointのパスを1つのmoduleにまとめることで、依存関係を可視化しました。
1箇所にまとめ、サービスへの依存関係が明確になり、その後、削除できる依存先がわかるようになりました。

過去に使われていた実装を消す

すでに止まっているビジネスで使用していたAPI、バージョンを切っていたなど確実に使われていないAPIを削除しました。
PR2つで、消えた行数は、46,178行でした。
使われていないコードを消すことで、controller周辺のコードがかなり見通しがよくなりました。

APMを見てAPIを消す

DatadogのAPMを見て、直近1ヶ月でリクエストがほとんどないAPIを探し、関連ファイルを削除していきました。
基本的に「叩かれていないAPI = 使われていないAPI」と判断して良いのですが、中には、数ヶ月1回叩かれることがあり、実は残すべきAPIがあったりします。
実際に、productionへリリースする前に関係者に報告やヒアリングをしたり、staging環境でしばらくエラーが起きないか確認しておくことが重要でした。

unicorn から puma へ

このサービスはRailsを採用していて、元々unicornで動いていました。
以前から社内ではこのサービスのpumaへの移行の検討を行ってきましたが、実施はされていませんでした。
スレッドセーフや、タイムアウトなど1つずつ懸念を潰して、移行しました。

定期実行されているジョブの整理

定期実行のジョブは、消し忘れが多く、不要なものが残っていました。
それらのジョブを消すことで、依存サービスの通信が減らすことができました。
また、マシンリソースの消費を減らすことができました。

得られた効果

消せたコード行数

結果として、12月時点で、1,800以上のファイルを削除、87,000以上の行を削除しました。
不要なディレクトリやコードが消えて、全体的に見通しが良くなりました。

Docker イメージの変化

Dockerfileを書き直し、ずっと手を入れていなかったDockerのイメージを改善しました。
最終的に、脆弱性の指摘の数が 3重要 + 749 その他 から 3 に減りました。
また、サイズが774MBから520MBに減少しました。

マシンリソースの変化

このモノリスサービスに依存している周辺サービスの整理も行うことで、マシンリソース消費が減りました。

リファクタリングは 「No pain No gain」だと思います。
過去1ヶ月、使われていないAPIやジョブでも、数ヶ月に1度実行されることがあります。ただし、それを考慮しすぎると、消せるコードが少なくなってしまいます。
悲鳴が上がっても、少しは許容してもらえるようなハンドリングや調整、理解を得られるとリファクタリングプロジェクトは進めやすいのかなと思います。

新人こそリファクタリングをやれ！

「新人エンジニアこそリファクタリングはやっていこう」というのが僕の意見です。

コードリーディングのメリット

歴史のあるサービスのコードリーディングでは良くも悪くも見本になります。
今よりもアーキテクチャが古かったり、コーディング規則が強くない場合もあるので、アンチパターンを確認することができたり、一方で、今後にも参考になるお手本のようなコードもあります。
さまざまなパターンを学ぶことができました。

PRのdescriptionの重要性がわかる

コードを読んでいると、実装の意図が不明なコードもあります。
コミットを辿り、Pull Requestを見ると、No description だったりします。
Pull Requestが作成された時点では、作成の文脈や合意がチーム内で取れていたりするので、descriptionを書かない選択もあったかと思います。
ただし、将来読んだ人にはその文脈や合意はわからないので、冗長なくらい書くことの重要性を肌で感じました。

Datadogなどのモニタリングツールに慣れる

リファクタリングにおいて、APMやslow queryを見ることになるので、Datadogなどのモニタリングツールの使用は避けられないです。
普段、機能開発をするだけでは監視ツールに触れることが少なかったのですが、リファクタリングプロジェクトを通して、ツールに慣れることができました。

ステークホルダーを見つける

モノリスサービスなので、関係するサービスが多かったです。
エンジニア、ビジネスどちらも必然的に関係者が増えます。
そのサービスに関連する箇所を変更していく過程で、誰が何に詳しいのか、どこに知見や経緯がまとまっているかがある程度わかるようになります。
その結果、その後の業務がしやすくなることもあると思います。

失敗してもちょっとは許してくれるはず！

どうしてもリファクタリング、負債の解消は効果が見えづらいため、実行の優先度が下がってしまうこともあります。
重要性についての合意が取れているなら、リファクタリングにチャレンジしていくべきです。
リファクタリングで少しくらい失敗しても、その姿勢は評価してくれると思います。リスクは抑えつつ、どんどんチャレンジしていくべきだと思います！

まとめ

今回は新米エンジニアがリファクタリングプロジェクトで行ってきたことをご紹介しました。
リファクタリングで負債を解消するというメリットだけでなく、成長や新たな発見ができるといったメリットはあると思います。
これからもリファクタリングを続けて、より管理しやすいサービスにしていきます。
また横展開を行い、知見を他サービスに応用していきます。
新人エンジニアはどんどんチャレンジしていきましょう！

新人こそリファクタリングをやれ！ ~マイクロサービスの最古のサービスをリファクタリングした話 ~ was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

基本的には、FiNCで蓄積してきたヘルスケアサービスの知見を活かし、以下にご紹介するような、ライフログに関わるアプリが多いです。
※リリース日順に掲載

A-RROWG（日本電気株式会社様）

A-RROWG サポート（ご利用の方へ）

Sleep Concierge（帝人フロンティア株式会社様）

センシング技術の活用で毎日の睡眠状態を管理

また、この他にも、法人のお客様に向けた自社パッケージ製品としての開発も行っています。

上記プロダクトは自分でコードを書いているものも、部分的に関わっているものもありますが、すべてFlutterでの開発を行っていまして、せっかくなので今日は、FiNCでFlutterとどう付き合っていっているかの話をしていこうと思います。

ネイティブコードで外部SDKを利用する

Flutter自体の特徴や基本的なメリットなどは、すでに広く知られているものだと思うので、今回はご紹介したアプリに共通する特徴である、外部ハードウェアとの連携のためのネイティブプラグインの取り扱いについてピックアップしてみます。

とは言っても、基本的にはSwiftで開発する時と、ベースの考え方は変わりません。
外部ハードウェアのために組み込んだSDKの存在を直接的に意識する箇所を適切に隔離することを重要視しています。

ネイティブプラグインの責務は薄く

例えば「外部ハードウェアのLEDを点灯させる」のような、単純なLチカ的なSDKへの命令を、FlutterではなくSwiftで開発する場合のサンプルとして書くとこういうイメージです。
※接続フローなどは考慮しない、発光命令部分のみ

同様の処理をFlutterで扱う場合、 HogeSDKWrapperがネイティブプラグインに対してのラッパに切り替わります。

ネイティブプラグイン側はアプリケーションでの用途を意識したHogeDeviceClientの代わりに、SDKの操作に関するインスタンスの管理と、SDKへの命令を型変換して伝搬することのみに徹することが望ましいです。

この場合でも、Swiftでの開発におけるSDKの取り扱いと観点としては同じで、ネイティブプラグインに対しての処理に必要なインターフェースと、自身のプロダクトで行うハードウェア操作に必要なインターフェースでは、型表現からわけて考えたほうが安全な場合が多いと思っています。

DartとSwiftの関係性をざっくり抜粋して書くとこういうイメージです。

ネイティブプラグインのインターフェースをどう定義するかの観点として、今後Dartに直接対応したSDKが提供された場合、ネイティブプラグインのラッパが、そのままSDKのラッパとして差し替え可能な構造を保つことを一つの基準と考えています。

上記のクラスやインターフェースの関係性を、ざっくり図に起こすとこういうイメージです。

HogeClientは、自分が参照しているのがDartのパッケージなのか、ネイティブプラグインなのかの具体には関心がない状態になっています。

ネイティブプラグインのインターフェース

ネイティブとFlutterは、同じアプリの中に所属するクラスのレイヤー分割というよりは、外部のAPIをコールする場合と同じような基準で定義しています。

例えば、今回利用したSDKの中に、iOSとAndroidでデバイス検索の命令フローが統一されてないものがありました。
具体的には、片方はSDKにscanの命令が直接用意されていたのに対して、もう片方はOS標準のBluetoothの命令を利用して検索する必要がある、というものです。

この場合、ネイティブプラグインのインターフェースとしては、スキャンという目的自体を抽象化して扱い、それぞれのOSでのスキャン命令に必要な具体知識はネイティブ領域に隠蔽するようにしています。

そのため、ネイティブ領域はシンプルなSDKのラッパにとどまらず、具体的な処理命令が入ることになりますが、Dart領域でOS毎に区別して処理を呼び分けるよりは安全と考えています。

ネイティブプラグイン内で外部ライブラリなど利用しない

ネイティブ開発を行っている場合は、外部SDKの状態管理なども、RxSwiftをフル活用していたりするのですが、局所的なプラグイン作成のためにネイティブ領域に外部ライブラリを入れることは原則的には避けています。

• 一部の目的のためにアプリサイズが肥大するのを避ける
• ネイティブ領域は可能な限り薄くするということを基本とした場合、外部ライブラリに頼りたくなった場合は何かしら余計なことをやっている可能性を疑う

というような理由が主で、今の所必要になるシーンには遭遇していませんが、あらゆる場合において絶対に禁止するという強さではないので、状況に合わせて選択していければと思っています。

結果的には

ネイティブ部分、特にiOSはデバッグがめんどうな部分はありますが、可能な限りネイティブ領域を薄く、余計なことを避けるように保つことで、Flutterの恩恵を受けることは出来ていると感じています。

Flutterではパッケージが充実していることもあり、自前でネイティブコードが必要になるシーンは減ってきたとは思いますが、一般的ではないSDKを利用する際や、信頼出来るパッケージが見つからなかった場合などはどうしても避けては通れないので、Flutterを選択したらネイティブ開発知識が不要になるかと言うと、そこまで振り切れるものではないと思いました。

また、外部パッケージの選定をする際にも、ネイティブ開発知識があった方が選択の観点もより適切に行えることもあります。
パッケージによっては、例外の考慮や権限まわりの扱いなどが不適切な形で決め打ちになっていたものなどもあったので、そういう懸念も検知出来たほうが望ましいです。

ネイティブ領域も可能な範囲で学習を進め、その上でFlutterの恩恵を最大化するような工夫ができるようにしていきたいですね。

個人的には、Flutterをきっかけに、Android側のライフサイクルなども勉強になることが多かったので、むしろポジティブにとらえています。

さいごに

実際にFlutterを触ってみて、細かいプラットフォームや言語の違いはあるものの、モバイルアプリケーションの開発を行うにあたって、大事にする点が何かということは基本的には変わらないと感じました

適切にライフサイクルを意識し、適切にクラスを切り分け、人間が継続的に理解できる構造を保つことが大事で、ネイティブ開発で学んできた知見を活かせる部分は実際に多かったです。

そこを大事にした上で

Flutterは、チュートリアルやドキュメントも充実しているし、学習コストは抑えつつクロスプラットフォームの恩恵を効率よく受けられる、素晴らしいフレームワークだと思います。

Swiftの強力な型の恩恵を受けていた身としては言語に対する物足りなさを感じる部分などもありますが、最近ようやくnull safe対応が入ったことなどもあり、まだまだ成長過程の、今後にも期待できる環境だと感じました。

We are hiring!

今回は、ある程度簡易的な例として記載しましたが、一定の規模・複雑性のある開発を行う際に、こういうレイヤー管理の話や、様々な設計における考え方がプロダクトの完成度や、保守性に大きく影響してきます。

中長期的にプロダクトを継続するために、こういった複雑化しないための設計の話で盛り上がりたい、そしてそれらを実行するために一致団結して具体的な解決の結果につなげたい。

というモチベーションを一緒に持てる方、そしてそれを楽しみながらやれそうと思ってくれる方、ぜひお話しましょう。

今回ちょっと固めな内容ではありましたが、普段はカジュアルに仕事の話でも趣味の話でも気軽にできるようなチームで楽しみつつチーム開発を行っています。

気軽にランチにお誘いできるようなご時世ではないですが、オンラインでもカジュアルにお話できると嬉しいです。

1000万DLを目指すヘルスケアアプリ開発を担うiOSエンジニアを募集！ by 株式会社FiNC Technologies

Flutterでヘルスケアサービスを作る中で意識しているネイティブプラグインの扱いの話 was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

FAQ刷新による問い合わせの削減

CREチームを立ち上げてからの半年間では、問い合わせ対応を回してバグをなくしていく仕組みづくりを行いました。
次にCREとして取り組んだのはアプリ内FAQの改善でした。
もともとあったFAQは、ユーザー側では検索性能が悪く必要な情報にたどり着きづらい、CS側ではメンテナンスが非常にしづらいという課題がありました。
ユーザーが問い合わせる前に自己解決できるFAQを導入することは、ユーザーとCS双方の負担を減らす効果が高いという仮説のもと、Helpfeelというサービスを導入しました。Helpfeelには強力な検索機能があり、Google Analyticsを使って記事のアクセス分析を行う機能が最初から組み込まれているという点で、導入後もFAQの内容を改善し続けたいというこちらの要望にマッチしていました。
導入の効果は非常に高く、CREチームを立ち上げたことにより最初の半年で前年比1/2程度まで減らせた問い合わせの数が、Helpfeelを導入したことによりさらに1/2になりました。

サービスの安定化に取り組む

FAQの刷新により問い合わせ対応で手一杯だった状態が改善され、時間的な余裕が出てきました。CREでは次に、この時間を使って技術的負債の解消に取り組むことにしました。具体的には以下のルールを実践しました。
バックエンドエンジニアがそれぞれ1週間のうち担当する曜日を1日決めて、その日はエラーレートの高い機能の根本改修やレスポンスの改善、その他負債の解消に全力で取り組むというものです。他のメンバーは問い合わせ対応など、それ以外の業務を引き受けることで担当者をサポートしています。
特定の問い合わせについて対応するメンバーが偏ることを防ぐことができますし、チームを意識することでメンバー内での信頼関係の構築にも繋がりました。
2020年12月時点でCREで管理するサーバーについてはエラーも大幅に減り、ライブラリも常に最新の状態を保つことができています。

サービスが安定化することで、問い合わせがさらに減る

サービスが安定化したことで報告される不具合やインシデントが格段に減り、CREメンバーの心理的負担が大きく減りました。
CSとCREに余裕が生まれ、これまで以上にサービスの改善案が現場から出てくる状態になりました。

現場主導で企画開発できるチームへ

問い合わせが減っても、もちろんCREの仕事が無くなるわけではありません。ようやくユーザーの声を元に、ユーザー体験向上を目的とした開発を行う土台が整ったと言えます。
問い合わせ対応に追われ精神的負担も大きかった状態から、徐々に改善案が出てきて、やりたいことが多すぎるというポジティブな状態になりました。CREができた当時から比べると劇的な変化だと思います。

2020年の成果として、CREとCSの変化をまとめました。

現在はCSとCREで定期的に企画会議を行い、ユーザーからのフィードバックを元に開発するものを決めています。
これまではユーザーの「使い方がわからない」といった内容の問い合わせに対しては単純に操作方法や仕様を伝えていましたが、「ユーザーがわからないと思わないようにする=問い合わせが来ない状態にする」にはどうしたら良いかを改めて考え、改善施策を行っています。
その結果、これまでにFiNCオリジナル体組成計の記録体験の改善や歩数データの取得処理の最適化、Google Fitとのデータ連携対応などをリリースすることができました。この1年で、守りの施策を行うチームから、攻めの施策を行うチームに転換できたことになります。

CREの2021年

これまでのCREは日々発生する問い合わせ対応がメインの業務だったため、開発の優先順位を決めづらく、大規模な開発案件や問い合わせに関すること以外の数値目標を追いづらい状況でしたが、問い合わせ数を減らせたことで、ユーザーの課題に対してより積極的なアプローチができるようになりました。
2021年のCREはより本質的なカスタマーサクセスに向けた目標を追っていくチームにしたいと思っています。現場の感覚だけではなく、ユーザーの行動を分析することで潜在的な課題を明らかにして、ユーザー体験を改善することを考えています。また、マーケティングチームとも連携し、これ
まで以上に数値目標を強く意識した施策を打ち出して、toCアプリでの成功事例をFiNCで作って公開していきます！

ということで

We are hiring!!!

ユーザーに本質的な価値を届けたいエンジニア募集中です！！https://www.wantedly.com/projects/562097

CREの2020年を振り返ります！ was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

始めに

FiNCアプリの「歩数記録機能」は初期の頃から提供している機能で、その時々で様々な改善を繰り返して来ました。そのため、いろいろな問題を抱え込んでしまっている、いわゆる「レガシーコード」のような状態になっていました。
この歩数機能を使った大きな新規開発を行う話が出ていたため、既存のコードが影響して問題が広がらないように、インターフェースの切り分けや関係性の整理などを行いました。
このような問題はよく皆さんも抱えている課題だと思いますので、
今回は、「レガシーコードとどう付き合っていくか」ということについてお話をさせていただきたいと思います。

背景

2020年4月にFiNCアプリホーム画面の大幅リニューアルにより、TOPページに今までなかった歩数、食事、カロリーなどのデータを表示することになりました。下記アプリ画面の上部黒背景のところです。

もともと歩数機能自体は「記録」機能の一つとして存在していて、UX的にもリアルタイム反映できるように作り込まれていました。
今回の新規開発は、このUX的なリアルタイム性も維持しつつ、新たにTOPページにも歩数機能を表示させるという要件となります。

手始めに

チームメンバー質問しながら、歩数コードを一通り調べて情報を整理してみたところ、この図のような構成になっていました：

FiNCアプリにおいて、UIレイヤーにはMVVMを採用していますので、ここにはViewModelが歩数データを扱うFacadeやRepositoryを直接知っていて、歩数機能のView層が密結合となっている状態です。
中でも、歩数をリアルタイムで流しているLocalStepCountFacadeに関しては想定外の挙動をしていることがわかりましたが、View層（StepViewController）でうまく吸収していたために問題なく動いていると言った状況でした。
そのため、コードレベルでこれ以上細かい挙動の問題点を追うことが難しいという判断となりました。
この時点でわかったことを整理してみますと：

• 歩数のレイヤー間での密結合が起こっている。
• レイヤー間の責務分担がちゃんとしていない。
• 歩数のリアルタイム更新を実現するにはLocalStepCountFacadeが必要。
• 新規機能追加時に、にLocalStepCountFacadeをこのまま使うことはできないので、何らかのケアが必要。

このまま拡張していくと問題が更に肥大化するのが目に見えて分かったので、一旦作業を止め、コメントやデバッグ出力をまとめたPRを出してチームメンバーに共有することにしました。

考察

この問題に対して正攻法で対処するには、責務を再考したり、コードを分割したり再構築した上で、きれいなインタフェースを定義し、今回の新しい歩数機能に使ってもらうことになります。端的に言うと歩数基盤を作り直すことになります。
しかし、スケージュール的には大規模なリファクタリングを行う余裕はありません。一方で、歩数のリアルタイム更新を諦めるのはプロダクトのUXを下げるため選択できません。まさに将棋などで言う詰みの状態です。
そこで妥協案を探り出さないといけないという共通認識が出来ました。一旦、既存のコードと新規で作ったものを図に並べてみると下記のように：

レイヤーで区切ると下記のようになります。

ここで妥協案に向けた課題をおさらいします：

• 新規実装(HomeTopStepRepository)でLocalStepCountFacadeを使いたい古い実装で利用されているリアルタイム性が考慮された機能を利用したい。リアルタイム性を考慮した新規実装を行う時間はない。
• 新規実装のメンテナンス性を維持したい
  古い実装を利用しつつも、新規実装にレガシーな依存関係を残してしまうと将来的にもレガシーコードの入れ替えが不可能になってしまう。

妥協案

そもそもHomeTopStepRepositoryが直接LocalStepCountFacadeを知るという、レイヤーを跨いだ依存関係を作らないという前提があります。
となると、もっとも愚直な案としてはその間に仲介となる存在を設けることが考えられます。いわゆるアダプターです。その存在がLocalStepCountFacadeを扱い、LocalStepCountFacadeの例外挙動もここで吸収してもらいます。図にすると、下記のOldLocalStepSourceに該当します。

妥当する前提の産物でもあるので、誤用するケースを避けるのに命名に工夫して、Oldつけたり、deprecatedをつけたりします。
修正ロジックなどをどこに入れるか、それを悩む必要がなく、OldLocalStepSourceにまとめれば良いです。こうすることで問題点を一箇所に集中することができました。
しかし、このままではHomeTopStepRepositoryは間接的にLocalStepCountFacadeを依存しているので、新規実装が旧実装に引きずられていることに変わりありません。いつでも簡単に歩数ソースを切り替えられるようにしたければ、きっちり断捨離をやり切ることが必須条件となります。簡単に言うと依存関係を逆転します。

HomeTopStepRepositoryがLocalStepSourceProtocolというルールを決め、外部に従ってもらいます。これによって歩数ソースを切り替えるインタフェースが自然に出来上がります。

これで、新規実装の整合性やメンテナンス性が崩れない、レガシーコードを扱うという２つの条件を満たすことが出来ました。
当然ここにLocalStepSourceProtocolを適合したモックリポジトリを注入できるので、ここでユニットテストも可能です。

まとめ

今回はFiNCアプリの歩数機能、及びホーム画面の新規機能を例として、レガシーコードの取扱方について紹介しました。レガシーコードは何処のどのようなプロジェクトにも必ず抱えている課題です。十分なケアを払いそのレガシーコードに直面し、無理に作り込みせず、チームメンバーとコミュニケーションを取りながら進めて行くのがFiNC流のやり方です。
また、今回の例では、主に責務の分割や依存性の分析などを通して、良い結果まで導き出せました。主に単一責任の原則（SRP）及び依存逆転の原則（DIP）を基にしたからこそ成立することです。

FiNC Technologiesクライアントエンジニア陣は、大規模アプリケーションの品質やメンテナンス性を如何に維持するため、原理原則、コミュニケーションを常に大事にしています。ご興味のある方はぜひ！

• ヘルスケア×Swift×少数精鋭！技術力で組織をリードするiOSエンジニア by 株式会社FiNC Technologies
• ヘルスケア×Kotlin！技術力で組織をリードするAndroidエンジニア by 株式会社FiNC Technologies
• ヘルスケアアプリ×ウェアラブル端末 ！Flutterでの開発経験者を大募集 by 株式会社FiNC Technologies

レガシーコードとの付き合い方 was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

日課は毎朝の散歩とラジオ体操です。

弊社では、2020年7月21日（火）に、糖質管理やアドバイスレポート機能など、ワンランク上の健康管理ができる新しいサブスクリプションサービス「FiNC Plus」をリリースしました。

FiNC Technologies、新月額サービス「FiNC Plus」を開始！ 糖質管理やアドバイスレポート機能など、ワンランク上のオンライン健康管理を月額480円で提供 〜1年間無料でお試しできるキャンペーンを2020年8月15日まで開催〜 - FiNC Technologies（フィンクテクノロジーズ） | モバイルヘルステクノロジーベンチャー

弊社ではユーザーに価値あるサービスを継続的に提供するためにアジャイル開発を取り入れているのですが、その実現方法は開発チームに委ねられています。そんな中、このFiNC Plusを開発している「dev2」というチーム(以後分かりやすく「Plusチーム」と呼びます)では、スクラムガイドに則ったスクラムでFiNC Plusを開発し、今でも改善を続けています。

しかし、社内でスクラムの知見はまだそこまで溜まっておらず、スクラムの適応も日々試行錯誤しながら改善しています。スクラムガイドにも「軽量 • 理解が容易 • 習得は困難」とあるように、理論は簡単でも実践がなかなか難しいスクラム。

そこで本記事では、我々Plusチームがどのようにスクラムを適応してきたかを以下のステップで紹介します。

1. なぜスクラムを取り入れたのか
2. 現状のスクラム体制
3. これまでに遭遇したスクラムの壁
   ・専属PO不在のスクラムチーム
   ・プランニングの時間でリファインメントをしてしまう
   ・一方通行のバックログリファインメント
   ・スクラムマスターがPM的なポジションや、POと開発チームとの橋渡しになってしまう
   ・チームメンバー同士の信頼関係の構築
4. 今後の展望
   ・スクラムについてスクラムチームのみんなが理解している状態にして、チームの自己組織的な成熟を支援する
   ・仮説検証を繰り返しながら、どんどん良いプロダクトにする
   ・スクラムをほかチームにもスケールし、社内でのスクラムの知見を増やす

なお、本記事はスクラムについての基礎知識があることを前提としています。

また、弊社の他のチームがどのようにアジャイル開発しているかについては、同じくAndroidエンジニアでキャンプの達人 佐多の↓記事をご覧ください。

FiNCアプリTOP画面大規模リニューアルの開発の裏側

なぜスクラムを取り入れたのか

実は我々Plusチームがスクラムを経験するのは今回が初めてではなく、前身となるチームでもスクラムを取り入れていました。そのため、Plusチームがスクラムを採用するのは自然の成り行きでした。

しかし改めて振り返ると、スクラムはプロダクト開発における責務を3つの役割(PO、開発チーム、スクラムマスター)に分散し、かつチームを自己組織化させることで、チーム外から指示されることなく、チーム内でも特定の管理者に依存せず、チームメンバーが互いに協力し合いながら一丸となってプロダクトの改善をし続ける仕組みになっています。FiNC Plusというサービスを長期に渡り継続的に改善しユーザーに価値を提供し続けるためには、チームメンバーひとり一人の相乗効果が大切になってくるので、そういった点でPlusチームにはスクラムが合っていると感じています。

他にも、スクラムはルールが定義されているため社内の他チームにも展開しやすく、また広く普及しているフレームワークなので本や勉強会が豊富で知見を得やすいのもメリットだと感じています。

現状のスクラム体制

ここでは、Plusチームが現状どのようにスクラムを運用しているか簡単に紹介します。

チーム構成

以下のように、合計14名のスクラムチームとなっています。

• PO 1名
• スクラムマスター 1名
• 開発チーム 12名
  (Android 1名/iOS1名/サーバー4名/QA5名/デザイナー1名)

スクラム経験者であれば、この開発チームの人数を見るとゾッとするでしょう。スクラムガイドでも、開発チームが9人を超えると調整が大変になり有益さも減ると書いてあります。しかし、メンバーの入れ替わりなどによる現在のメンバーのスキルセットを考慮し、このような構成となっています。（メンバーが多い苦悩は後ほど共有します）

スプリント

2週間スプリントを採用しています。前身チームでも同じ周期だったので慣れているのと、モバイルクライアントとサーバーがあり、1週間だとどちらかが遅れるとスプリントから溢れやすくバッファ的な意味でも2週間としています。一方、2週間だと「差し込み」が多くなりがちで、1週間スプリントの場合は「次スプリント(1週間後)でやろう」のように差し込みを減らしやすかったり、仮説検証やチームの振り返りのサイクルが早くなるメリットもあり、1週間スプリントとすることも検討しています。

各種スクラムイベント

スクラムガイドに則り、スプリントプランニング、デイリースクラム(朝会)、スプリントレビュー、レトロスペクティブ の各種イベントに沿ってスクラムを回しています。また、プランニングに入る準備としてのプロダクトバックログリファインメントは隔週で曜日固定としています。

FiNC Plus全体定例

その他、FiNC Plusというサービス全体で部署の垣根を超えて早期のコラボレーションを生み出せるように、分析・CS・マーケなど関係する各部署のメンバーが集って週次で進捗報告をする定例を設けています。KGI・KPIの進捗やカスタマーボイス・問い合わせの共有などもこの場で行われています。

これまでに当たってきたスクラムの壁

ここでは、これまでPlusチームがスクラム開発する過程で当たった壁と、それがどう改善されてきたかを紹介します。

専属PO不在のスクラムチーム

現在はPlusチームの専属POがついていますが、少し前まではPlusチームに専属POはおらず、いっときはPO的な立場の人が3人同時にいました。というのも、FiNCアプリには様々な機能がありそれだけ多くの企画が同時に並行して動いている一方、開発ラインが限られているためです。実際、FiNC Plusの開発中も、クライアント側は「食事アドバイス」というPlusとは別サービスの開発もしていました。

バックログが無法地帯
複数POがいても、誰か特定の人がバックログの管理にオーナーシップを取れていれば良かったのですが、当時はそうした状況でもなくバックログの管理責任の所在が不明瞭でした。結果、Plusチームのプロダクトバックログには「FiNC Plus」「食事記録」「食事アドバイス」などそれぞれのPO管理のチケットが立ち並び、それに加えて今となっては不要なチケットやエンジニア用語で書かれて中身のよく分からないチケット、同じ内容のチケットなどが乱立しており、はっきり言ってカオスな状態でした。

「POさん、バックログはあなたのものです！」
そしてつい最近、開発ラインが増えたことでようやくPlusチームに専属POが1人つくことになりました。そこでまずはPOに「バックログはあなたのものです、あなたが責任を持って管理してください」と伝え、バックログのオーナーシップを専属POにとってもらうことでバックログが整備されるようになりました。 これまでエンジニア用語で書かれていて内容の分からなかったチケットが、実はPlusの品質維持のためにとても重大なものであるとPOが気づけたり、大きな発見がいくつもありました。こうして、改めてプロダクトバックログにあるアイテムを全てPOが目を通し優先度をつけることで、企画だけでなくバグ修正や技術負債対応も含めたPlusチームのロードマップを引き直すことができました。

このように専属POがいることでようやくスクラムの体制が整ってきましたが、一方で、PO/スクラムマスター/開発チームが一つのスクラムチームとしてお互いに協力し合う文化創りはまだまだ改善の余地があると思っています。

プランニングの時間でリファインメントをしてしまう

リファインメントのやり方はスクラムガイドにない
スプリントプランニングは、そのスプリントで「何を」「どのように」開発チームが完了させるかを決める場所です。そしてその判断をするために事前に優先度の高いバックログアイテムの詳細(受け入れ条件や開発規模など)をPOと開発チームで詰める作業があり、これをプロダクトバックログリファインメント(PBR)と呼びます。しかし、PBRの必要性はスクラムガイドにあるものの、その実現方法については一切触れられておらず、自分たちで考える必要があります。

不定期開催のリファインメントで開発リズムが崩れる
これまではPBRの開催タイミングが決まっていませんでした。すると、専属POの不在などもあり、各POがそれぞれ思いおもいのタイミングで開発チームにリファインメントを依頼し、スプリント中の開発リズムが崩れるし開発時間が想定外に減ってしまう現象がありました。

リファインメントが開催されずにプランニングが始まる
あるいは逆にPOがどのタイミングで開発チームに依頼したらよいか分からないままリファインメントが開催されず、優先度が高いという情報のみでプランニングが始まり、プランニングの最中でリファインメントを行ってしまうことも多々ありました。リファインメントはユーザーストーリーの詳細を詰める大事な場なので、「プランニング時間内にちょっとだけ」はできません。

リファインメントの日を固定する
このように、突発的なリファインメント依頼とリファインメント漏れを防ぐために、隔週で固定日にPBRをするようにしました。一方、開発リズムという観点では、リファインメントをする日が事前に分かっているとしても、スプリント中に数時間PBRに向き合わないといけないというのは、やはり開発チームにとってはやりづらさがあります。今後は、このPBRをいかに改善していくかが一つのテーマになりそうです。

一方通行のバックログリファインメント

先ほどはPBRのタイミングについて説明しましたが、PBRの質にも改善したい点がありました。PBRはPOと開発チームとがストーリーチケットについて双方向で議論することで、そのストーリーに対する認識齟齬を無くし開発準備が整った状態とする場です。具体的には以下のようなことを話し合います。

• どんなユーザー体験(ユーザーストーリー)を実現したいの？
• その背後には仮説・背景・課題があるの？
• それを満たすにはどんな方法があるの？
• 受け入れ基準は？
• 開発規模は？

つまり、プロダクトの価値を高めるための方法をPOと開発チームとで話し合い理解し合うとても大事な場所で、そこでは参加者ひとり一人の 主体的な参加が大切です。

しかしこの議論が双方向にあまりされず、スプリントが始まってからどんな実現方法にするかや受け入れ条件について話し出すことが多く、コミュニケーションコストがかかっていました。PBRという会議体はあっても意義のあるリファインメントがあまりできていない状態でした。

そしてこれは、スクラムマスターである私の責任だと感じています。というのも、そもそもこれまでPBRが何のためにあり、何を話す場で、参加者にどんなことが求められているかを共有できていなかったからです。

なんのための会議体で、何が求められるのかを説明する
そこでチームの振り返りの場を使い、PBRについての説明と、POと開発チームとで双方向の議論が望ましいことをチームに伝えました。説明の際には、アジャイル開発におけるプロダクトバックログのリファインメント方法の提案 より、「リファインメントさえやれば良いのか？」というスライドを引用させていただきました。
また、話し合う項目を明確化するため、プロジェクト管理ツールAsanaのチケットの項目に、既存の開発規模などに加え、「背景(課題)」「実現方法」「受け入れ基準」の項目を追加して、PBRの時間でこれらを埋めるようにしました。

これにより一定PBRの質は向上したものの、まだまだ改善できる点はあると感じています。例えばPBRが行われる水曜日はFiNCアプリのリリースがあり、QAは本番リリースする前の最終的なチェックがあるためリファインメントに集中しにくいです。受け入れ基準は特にQAの方々が強い領域でもあるため、開催日を変える必要があるかもしれません。また、まだまだ心理的安全性が低いのか、あるいは私のファシリテーション不足か、全体的に発言が少なめな印象です。PBRの場でいかに詳細を詰められるかでスプリントでの生産性と提供できる価値の高さも変わってくると思うので、この辺りは継続して改善していきたいです。

スクラムマスターがPM的なポジションや、POと開発チームとの橋渡しになってしまう

スクラムチームにはチーム全体を管理する人がおらず、POはプロダクトの価値を高めるために「何を」「どの順番で」取り組むかの責任を持ち、そのスプリントで「何を」「どうやって」完了させるかは開発チームが責任を持って管理する、そしてスクラムマスターはサーヴァントリーダーとして、ティーチング/コーチング/ファシリテーションなどを用いてPO・開発チーム・組織がスクラムで価値を届けられるように支援することに責任を持つ。スクラムではこのようにプロダクト開発に必要な管理をチームに分散させ互いに協力し合うことで、特定の管理者に依存しないチームを目指します。しかし、こうしたスクラムの思想をスクラムチームにもチーム外にもきちんと説明しないと、スクラムマスターがチーム全体の管理者として認識されやすいです。なぜなら、そうした説明なしにはスクラムの中で各メンバーがどう動けば良いか分からず、その上で「スクラムマスター」という仰々しい名前があるので、なんとなくスクラムマスターに相談してしまいやすいためです。実際、Plusチームでもスクラムマスターである私がこうした説明を怠っていたため、スクラムマスターがPOと開発チームのコミュニケーションのハブになってしまったり、開発チームの進捗管理もスクラムマスターが管理するように捉えられ、チームメンバー同士のコミュニケーションを阻害してしまうことがありました。

そこで、チームメンバーひとり一人とのヒアリングを開催し、その過程で上記のようなコンセプトを伝えてチームメンバーの主体性を促すようにしています。しかし、スクラムについてのもう少し体系的な話や、「開発チームに肩書きは無くて専門分野に関係なく協力し合う」などのコンセプトはまだチームメンバーにきちんと伝えることができていないため、ここは目先で一番優先的に行いたいことです。

チームメンバー同士の信頼関係の構築

Plusチームでは、職能メンバー同士のコミュニケーションは活発ですが、職能間のコミュニケーションがあまり積極的に行われておらず、そこに見えない壁があり続けていました。特にエンジニアとQAとの関係でその傾向が顕著で、同じチームにいながらもチーム内受託のような、相互扶助の関係ではなくウォーターフォールのように分断された仕事の受け渡し状態でした。スクラムイベントの中でも両者が議論し合うことは担当チケットに関することがほとんどで、「一緒のチームとして助け合い、チームの改善のために議論し合う」ような関係性では正直ありませんでした。

この点にメスを入れるべく、開発チームのひとり一人とヒアリングをしたところ、意外な事実を発見しました。私としては、「QAの方々がチームとしての働き方を望んでいない」と勝手に思い込んでいたのですが、QAの方々もこのエンジニアとの距離感を懸念していることが分かりました。さらに、「意見を言いたくても相手のことを良く分かっていないので相手がどう思うか分からず意見しにくい」と感じている方が多くいることが分かり、この信頼関係の構築の欠如に加えて、彼らのほとんどが派遣契約で契約的な立場からも無責任に発言しにくいという状況も重なり、心理的安全性が低い状態だったことが分かりました。思い返せば、QAメンバーのうち何名かはコロナ禍以後にPlusチームに参画してくれ、最初からリモートのまま特にチームビルディングのようなものが無い状態でこれまでずっときていました。

今の状態は、チームの5つの機能不全の中でも「信頼の欠如」「衝突への恐怖」の段階だと考えており、これらを乗り越えなくては

チームの5つの機能不全 (表示順に基礎をなしており、一つ一つ順に乗り越えていく必要がある)

• 信頼の欠如
• 衝突への恐怖
• 責任感の不足
• 説明責任の回避
• 結果への無関心

現状が分かったことで、今後はこのチームの5つの機能不全をいかに乗り越えていくかも大きな焦点となっています。

今後の展望

スクラムについてスクラムチームのみんなが理解している状態にして、チームの自己組織的な成熟を支援する

Plusチームはこれまでスクラムでいくつもの壁に当たり、いくつかは改善することができましたが、本当のスクラムはまだまだこれからだと考えています。というのも、これまでも触れた通り、「スクラムが何か」ということやスクラムにおいてチームメンバーひとり一人に求められることを、まだきちんとチームメンバーに伝えることができていません。また、チームメンバー同士の信頼関係構築と心理的安全性の向上についてもまだまだ改善できるところがあります。スクラムプロセスになんとなく従っているチームから、スクラムを理解した上で自分たちで協力し合いながら改善していく自己組織的なチームへと変化する上で、最初の第一歩をようやく踏み出すことができたな、という感じです。チーム形成の段階的な推移を示したタックマンモデルではまだ形成期の段階だと思います。このモデルによれば次は混乱期が訪れ、まだまだチームの旅の先は長いですが、スクラムマスターとしてチームの成長を支えていきたいです。

タックマンモデル

• 形成期 (互いに無関心、個人プレー)
• 混乱期 (意見の衝突)
• 統一期 (安定した結果現状維持の罠にはまる)
• 機能期 (チーム一体となって新たなことに挑戦)

仮説検証を繰り返しながら、どんどん良いプロダクトにする

スクラムを採用しているのは、ユーザーに最短で価値を届け、その価値を増やし続けるためです。つまり、どんなにスクラムのプロセスを効率よく回し、素早くサービスをリリースできても、ユーザーにとって価値が無ければ意味がありません。そのため、ユーザーの声やデータをPlusチームのひとり一人が意識し、価値を高めるための仮説検証をPlusチーム全体で考えられるようにしたいと思っています。ユーザーインタビューに開発チームが参加したりするのも良さそうです。また、スクラムに固執しているわけではなく、結果よいサービスを楽しく作ることができれば良いので、チームメンバーの声を聞きながら、場合によっては勇気を持ってスクラムから離れることも考えられると思います。

スクラムをほかチームにもスケールし、社内でのスクラムの知見を増やす

もしPlusチームのスクラムが上手く回るようになったら、このノウハウを社内の他チームにも展開し、スクラムチーム同士で知見のシェアをできるようにしたいです。互いの経験的プロセスを共有することで、より良いチーム作りに繋げていきたいです。ゆくゆくはスクラムチームを超えて組織全体にもスクラムの知見を共有し、会社全体がよりアジャイルに、そしてより自己組織的に動くようになればいいなと密かに思っています。

以上。

ワンランク上の健康管理を！「FiNC Plus（プラス）」をスクラムで開発しました was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」

「インシデント時のお知らせって誰がどうやって出すんだっけ？」

「インシデントの復旧作業って今どれくらい終わってる？」

「あのインシデントって振り返りしたっけ？」

「似たようなインシデント、前も対応したような、していないような」

このような会話に覚えはありませんか？

FiNC Technologies社 (以下FiNC) では今まで

• インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけない
• インシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができない
• インシデントの振り返りが実施されず、インシデント時の知見が共有されない

という問題がありました。

それらの問題を

• 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る
• 何をすべきかわかりやすくする = インシデント時対応のリストを作成し、それに従えば良いようにする
• 楽しく振り返る = ポストモーテム（インシデントの振り返り）の設定を促し、責めるのではなく楽しく明るく振り返る

という方法で改善していきました。

その際に気をつけたことなどについてシェアします！

ブログの内容は後日こちらのイベントで発表予定なのでプレゼンでも聞きたい方は是非ご参加ください〜！

FiNCのSRE/CREチームのエンジニアが現場の運用についてお話しします (2020/08/06 19:00〜)

目次

• 問題1：インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけない
• 問題2 ：インシデント対応の際にすべきことが明文化されていない
• 問題3 ：インシデントの振り返りが実施されず、インシデント時の知見が共有されない
• インシデント対応KPTと今後の改善
• まとめ
• 付録 FiNCのインシデント対応リストの中身

問題1：インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけない

インシデントが起きた際、他のチームと連携しないといけない場合でもチーム内で解決しようとしてしまうことはありませんか？

FiNCではサービスごとにチームが分かれているので、普段はそのチーム内でのチャンネルで会話しています。

そのため、インシデント時にもその中で作業をしてしまいがちで、全員がいるようなチャンネルでシェアせずに、自分のチーム内だけで処理してしまうことがよくありました。

その結果、他のチームの手助けを借りれば早くできたはずの対応に遅れが生じたり、お客様への連絡に遅れが出るようなことがありました。

そのような問題を防ぐために

• インシデント報告チャンネルの統一、周知
• 報告チャンネルは気軽にシェアできるように、報告した人を賞賛する雰囲気づくり

を行いました。

インシデント報告チャンネルの統一、周知

slackで #incidentチャンネルを作成し、インシデントの可能性のあることはそこで @channelをして(そこにいる全ての人に通知が行く) 報告するようにしました。

最初はプロダクトに関わる人しかいなかったチャンネルでしたが、徐々にと広報メンバー、CSメンバーも参加して、今では社員の大半が入っているチャンネルになっています。

報告チャンネルは気軽にシェアできるように、報告した人を賞賛する雰囲気づくり

社員の大半がいるチャンネルだと、特にプロダクトに関わらないメンバーの場合「アプリがなんか調子悪そうだけど自分が全体に通知していいのかな…」とためらってしまうことがよくありました。

そのようなためらいを防ぐために、誰かがインシデントを報告してくれた時に、実際にはインシデントではなかったとしても「これはインシデントじゃないので次回から報告しないでください」と咎めるのではなく、「些細なことでも報告していただきありがとうございます」と、報告してくれた人を賞賛するような雰囲気を積極的に作っていきました。

とはいえ、インシデント報告チャンネルでの報告は、エンジニアである自分や他のメンバーが繰り返し言っても最初はなかなか浸透しませんでした。

その中で鍵となったのが、このようなインシデントに対する取り組みに理解のあるプロダクトマネージャーの協力でした。

インシデント時にはすぐに駆けつけてくれて、積極的に広報/CS/マーケチームなど非エンジニアとの連携をしてくれたり、インシデント報告チャンネルでの報告を積極的に呼びかけてくれることで、「エンジニアの世界の話」と取られがちなインシデント対応への非エンジニアの心理的障壁を取り除いてくれたと思います。

少しでも不具合に感じることがあれば積極的にシェアする雰囲気ができ、実際に影響があるインシデントが起きた時に迅速な対応ができるようになりました。

ポイント

• インシデントが起きた時には全体のチャンネルでまずは周知する
• 連絡してくれた人が賞賛されるような雰囲気作りが大事
• 非エンジニアでインシデント対応に理解のある人がいると、より雰囲気を作りやすい

少し余談ですが、チャンネルの名前はもともとemergencyでした。しかし「緊急かどうかが判断できなくて報告をためらってしまう」ような事例や、「緊急かどうかは主観なのでincidentというチャンネルにすべきでは？」という声からincidentチャンネルに変更されました。

問題2：インシデント対応の際にすべきことが明文化されていない

いざインシデントが起きた時に、何から始めてどこに連絡をすればいいかわからないということはありませんか？

もともと FiNCでは、インシデントが起きた時にまず何をすべきかが明文化されていませんでした。そのため、ありがちだったのが

• エンジニアがいきなり調査を始めてしまって、調査がどこで行われていてどこまで進んでいるか状況が全くわからない
• お客様に（Twitterやアプリ内のお知らせ機能などで）どうやってお知らせするか整備されておらず、お知らせが出せなかったり、遅れてしまったりする

などの問題でした。

そのような問題を防ぐために

• インシデント対応リストの整備
• インシデント時にやることがコマンドで表示できるbotの作成

を行いました。

インシデント対応リストの整備

インシデント対応リストの詳細については付録にて詳しく説明しますが、インシデントが起きた時にはまず

• 全体の責任者、エンジニアの（作業はしない）コミュニケーション担当、エンジニア作業者の3つの役割を明確にする
• 調査用チャンネルの作成
• インシデント状況ドキュメントの作成

を行い

• 全体の責任者は各所への連絡、定期的な状況整理、お知らせの依頼
• エンジニアのコミュニケーション担当は作業はせず、インシデント状況ドキュメントのステータスやタイムラインなどの更新
• エンジニア作業者はインシデントからの復旧

を担当するようにしました。

それによって後から来た人でも、slackチャンネルや状況ドキュメントを見ることによってステータスやタイムラインがわかり、また連絡する人と作業者を分けることによってインシデントの復旧に力を注ぎつつ、お客様への告知も迅速に対応できるようになりました。

インシデント時にやることがコマンドで表示できるbotの作成

実際にインシデントが起きている時は、大抵みんな焦っています。

インシデント対応リストが長く読みにくいものだと、そのドキュメントを読んでいる余裕がなく、対応ルールが無視されてしまう問題がありました。

また、インシデント状況ドキュメントのテンプレートを見つけてきてコピペする作業が大変で、インシデント発生時にはないがしろにされがちでした。

そのため、最初は対応方法がわかるエンジニアがフォローしたりしていましたが、そのうちに「インシデントが起こった時に最初にやるべきことがbotで通知されれば、焦らなくて済むのでは？」ということでslackのコマンドを作り、botが最初にやるべきリストを出してくれるようにしました。

そのおかげでインシデント報告がされた時にみんながそのコマンドを実行し

• 対応時にやることリストがすぐわかって認知コストが下がる
• 対応時の手間が減る

ことで正しい対応が迅速にできるようになりました。

このbotはAWS Lambdaで作られていて、Terraformでコード管理されているので今後も少しずつ改善される予定です。

ポイント

• インシデントが起きた時に役割分担と、何をするかを事前に明文化して周知しておく
• インシデントが起きた時にやるべきことを思い出すコストを極力下げる

問題3：インシデントの振り返りが実施されず、インシデント時の知見が共有されない

インシデントの振り返りがされず似たようなインシデントが繰り返された経験はありませんか？

もともと FiNCではインシデントを振り返る会議があったのですが、インシデントの原因の究明と対策の場というより、責任の追求の場になってしまっていました。

そのため、会の雰囲気は暗く、徐々に参加する人が少なくなり、会も開催されなくなっていきました。

そこで、従来の責任追及の場としての振り返りではなく、原因を突き止めて再発防止の対策を行い、知見を共有する場としてのポストモーテム (注1) を開催するようにしました。

ポストモーテムはインシデントの後に設定され、誰でも参加できます。
またポストモーテムの最初には以下の条文が読まれます。

ポストモーテムの目的はインシデントの原因を解明し再発を防止すること、またインシデントが起きた時の初動を早めるための準備をすることです。

人の責任を追求することはせず、責任を追求するような発言があった場合にはお互いに注意をします。

言い訳をする必要はありません。よくなかったこともうまくいったことも他人事のように発言しても問題ありません。

良い振り返りは賞賛されるべきものです。楽しく振り返りましょう！

責任追及をするのではなく、楽しく振り返るということを意識的に心がけることで、実際に気持ちの良い雰囲気でポストモーテムが実施されるようになりました。

ポストモーテムも、インシデント対応のやり方と同様に、最初から浸透していたわけではありません。

最初はSREチームが主導してファシリテーションをしたり、話しやすい雰囲気作りをしていました。

そのうちにポストモーテムを設置するようお願いすることなく、各チームで主体的にポストモーテムを設置して振り返るような習慣がついてきました。

主体的にポストモーテムが開かれるために必要だった要素としては、繰り返しになりますが、責めない雰囲気、楽しく振り返るという雰囲気の浸透とポストモーテムのテンプレートを整備して、それを見れば振り返れるようにすることで、開催の障壁が低く保たれたことが良い要素だったかなと思います。

現在では、直接システム起因で発生したインシデントだけではなく、運用オペレーションのミスで起きたインシデントであっても運用オペレーションのチームでポストモーテムを主体的にするなど、エンジニアに限らずプロダクトに関わるメンバー全体に浸透してきています。

ポイント

• インシデントの振り返りは責めない雰囲気、楽しく振り返るという雰囲気を作る
• 振り返りの際にやることはテンプレートにしておく

インシデント対応KPTと今後の改善

インシデントへの対応方法も浸透してきて、ポストモーテムも数十回ほど実績ができてきたので、全体を通しての振り返りとしてKPTを実施しました。

Problem1
ポストモーテムで出たアクションのトラッキングが甘くて改善が実行されたりされていないことがある。

TRY1
ポストモーテムで出た改善タスクは、定常的な開発タスクと同じく当社ではAsanaで管理しているので開発スプリントのタスクに入れて、月に一回のインシデント対応KPTで進捗をトラックしていく。

Problem2
ポストモーテムで出た知見が全体にシェアされる仕組みがない。

TRY2
週次のエンジニア会議にて知見をシェアする場を設け、ポストモーテム後には全体のチャンネルにも知見をシェアする。

などの改善策が出てきました。

その他、前述の障害対応太郎をもっと便利にするために、TerraformでAWS Lambdaをコードで管理してアップデートしやすくする、などが出てインシデント対応方法全体としても改善されました。

今後も、インシデント対応やポストモーテムを月に一回ほどの頻度で振り返っていき、良いポストモーテムは週次のエンジニア会議で表彰するようにしていく予定です。

まとめ

FiNCにおけるインシデントの対応や振り返りについてまとめてみました。

• 気が付きやすく、シェアしやすくする
• 何をすべきかわかりやすくする
• 楽しく振り返る

という改善点が皆さんの会社でのインシデント対応の参考になれば幸いです！

ブログの内容はこちらのイベントでも発表しますので、もうちょっと突っ込んだ内容を聞きたい方は是非ご参加ください！

FiNCのSRE/CREチームのエンジニアが現場の運用についてお話しします (2020/08/06 19:00〜)

注1) ポストモーテムは検死という意味の単語で、インシデント後に原因究明、再発防止のために根本原因、トリガー、解決方法、タイムラインなどについて記録する文書です。FiNCでは振り返り会という意味で使うこともあります。FiNCにおけるポストモーテムのフォーマットはGoogleのSRE本 を参考にしています。

[付録] FiNCのインシデント対応リスト

付録としてFiNCのインシデント発生時の対応リストを公開します。

こちらもポストモーテムのフォーマット同様にGoogleのSRE本を参考にさせていただいています。

第一報を行う
#incident チャンネルで起きているインシデントについての第一報をする (@channelを必ずつける)
どんな状態が起きているのか今わかっている範囲での影響範囲について報告する

まずは今わかっていることを簡潔にまとめつつ、全体に知らせることが最優先です。必ずSlackのchannelメンションで全体に通知します

インシデント責任者を決める
インシデント責任者（主に企画部の誰か）
実際のインシデント解消業務は行わず、影響範囲を判断して作業責任者と連絡を取りながら関連部署に報告する
指示用のslack channelができたら、 #incident にも進捗報告する

コミュニケーション担当者（エンジニア側責任者。主に技術開発部の誰か）を決める
実際のインシデント解消業務は行わない。incident状況ドキュメントを記入しタイムラインの更新をし続ける

作業担当者（主に技術開発部の誰か）を決める
実際のインシデント解消業務を行う

次にインシデント責任者、コミュニケーション担当者、作業担当者を決めます。
作業をいきなり始めることで、インシデントのステータスがわからないような状況を防ぎます。

インシデント対応リストを作成したタイミングでは、エンジニア責任者とエンジニア作業者の二つの役割しかなかったのですが、エンジニア責任者が全てのコミュニケーション（対エンジニアに加え、広報、CS、マーケティングチームなど）を担当するとパンクすることがわかったので、改善され今のような形になりました。

指示用のslack channelを決める
作業担当者が今何を行なっているかなど、当該インシデントに対するあらゆる対応内容を流すためのchannelを作成する

全体の #incident チャンネルにはサマリーだけを流し、1つのインシデントの状況が1つのチャンネルで終えるように専用のチャンネルを作ります。

そうすることによって、エンジニアの作業ログによって重要なメッセージが埋もれたりすることや、同時にインシデントが起こってしまった時の混乱を防ぐ効果があります。

また、リモートでのインシデント対応が多いため、ビデオ会議を繋いで作業や連絡を取ることもあります。

インシデント責任者は責任をもって以下のリストを進める

1. インシデントの深刻度を判断しエスカレーションをする
インシデントレベルの分類をみてS_Serious / SS_ Critical の場合にはエスカレーションを行う

2. お客様への告知の連絡をする
アプリ内でのお知らせの記載
お客様に影響があるケースでは、公式Twitterによる告知も行う
1時間以上のサービスの停止や、toBサイトの長時間停止などの場合、公式サイトでのお知らせ掲載

状況に応じて広報やCSチームと連携を取りお客様に対する告知文を用意します。
連絡網は事前に整備され、投稿文言のテンプレートは事前に用意されています。

3. タイムラインを終了ステータスまで随時更新する。
終了後も作業があればインシデントドキュメントのタイムラインに追記する
待機/解散の判断をする

完全に収束するまでタイムラインやステータスを更新します。
インシデント対応の終了を判断し宣言することは、特にリモートでのインシデント対応の場合に作業者や関係者の疲れを軽減させる意味でも重要です。

以上がFiNCのインシデント対応リストです。

こちらもぜひ参考にしていただければ嬉しいです。

【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜 was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

こんにちは。つよぽそです。FiNCでは2020年からCREチームを作ったので、CREチームがやってきたことを紹介しようと思います。

何故CREチームを作ったのか

CREとは

CREはCustomer Reliability Engineering（顧客信頼性エンジニアリング）の略で、googleが提唱した専門職です。※googleの記事はこちら

FiNCが抱えていた課題

FiNCでCREを作ろうとしたきっかけとして、下記の課題感がありました。

• Customer Support(以下CS)からのエンジニアへの問い合わせが大量にあり、エンジニアが自主的に拾っていく状況だった。
• 新規機能の開発で手一杯な状況であり、問い合わせに対する返信も滞りがちになっていた
• CSの使用する管理画面や業務フローも整備されておらず、作業効率が悪かった
• エンジニアが問い合わせに対して本質的な改善に動く余裕がなかった

カスタマーサクセスの実現

実際、CS対応がほぼ個人の善意と責任感に頼る状態だったため(それでも皆んな頑張って積極的に対応してくれていた)エンジニアもCSも限界に近い状況になっていました。何よりお客様に迷惑をかける状況になりかねないって危機感がありました。そんな状況を鑑みて、健全なサービス運営をしていくためにはCREの存在は必要不可欠だと訴えていました。そこで更に後押しとなったのが弊社でカスタマーサクセスの実現が全社で取り組むべき課題として、経営レベルで重要なテーマになった事です。FiNCのvalueでもあるcustomer’s smileを実現させるためよりカスタマーサクセスと向き合っていこうという方針になったため、お客様の課題と向き合えるチームが必要だとなり2020年1月中旬にCREを組成できる事になりました。

CRE結成

最初にやったこと

CRE結成時のメンバーは僕とPMのみでした。他の開発メンバーがジョインするまでに最初にやったことは、CREが何をするチームか定義することでした。その中で決めた事は大きく2つの方針に分けました。

• 守りの施策
• 攻めの施策

守りの施策

まず、守りの施策ですが、お客様からの問い合わせに迅速に対応できる体制を作ることに焦点を当てました。問い合わせに迅速に対応する事でお客様の不安を取り除きアプリからの離脱を最小限にするための施策です。

• 問い合わせの多い案件を分析しCSだけで対応が完結するような管理画面の作成
• エンジニアの問い合わせフローの整備
• 問い合わせ状況の可視化

この両面とも当時は全く整備されていない状況でした。管理画面がないことによってCSからのエンジニアへの質問や対応依頼が大量に来る状況だったし、そもそもチケット化もされていない状況でslackでの質問で全てのやり取りをしていたため質問が流れてしまうという状況も発生していました。なので、asanaのformを利用してチケット化することと、チケットをボードで進捗管理することで問い合わせの可視化を行いました。また、問い合わせを分類し、問い合わせに対してCSのみで完結するよう管理画面の開発を効果の高いものから開発していける体制を作りました。

攻めの施策

攻めの施策はそもそもの問い合わせ数を減らすためにアプリの改修を行うことです。そしてアプリの体験を良くしていき、お客様にFiNCのファンになってもらう事を目指しています。

• 問い合わせの多い不具合の根本解決
• 問い合わせの多い原因を分析し、そもそも問い合わせが来ないようにプロダクトを改善する事

CREチームの最終到達点としては迅速に問い合わせに対応出来ることではなく、そもそも問い合わせが来ないサービスであることだと定義しています。したがって、一番するべきことは問い合わせの原因を解決し問い合わせが発生する状況をなくすこと、また不具合ではなくとも問い合わせが来る原因を突き止めUXを向上させることでお客様が迷わずわかりやすい設計をしてあげる事です。その両面とも効果を最大化させるためにチケット作成段階から明確に優先順位を付けれるような体制を整えました。CREで対応しきれないことは各開発チームに修正依頼をだして対応してもらうような依頼も積極的におこないました。

CRE結成6ヶ月の成果

CRE結成から約半年、今ではPM1名、バックエンドエンジニア4名、iOSエンジニア1名とチームのメンバーも増えてきました。※androidエンジニアもジョイン予定。CREを作ってどういう効果があったのか紹介したいと思います。

定性的な効果

業務フローを整備したことで、CSのメンバーも安心して問い合わせをエンジニアに聞くことができるようになりました。問い合わせをCREで一次受けすることで、エンジニアも自分達の開発に集中できるようになりました。朝会等の定例ミーティングをCSのメンバーも招いて行うことでCSとエンジニアの壁もだいぶなくなってきています。またCSと協力しVoC(Voice of Customer)を全社にシェアすることで、CREだけでなく企画、デザイナー、開発者、QA全員がお客様を向いて開発するようになりました。

定量的な効果

実際、効果の高そうな問い合わせを無くしていく作業をしてきた成果か2019年から比べて1/2近く問い合わせ件数が減りました。当然、エンジニアにくる問い合わせ自体も減っています。※数値は見せれないがDAUは上昇しています

所感

CRE結成から約半年経ちましたが、この半年はまさに土台作りのフェーズでした。愚直に効果の高いものから問い合わせに繋がるようなバグを無くしていくことと、問い合わせが回る仕組みを作る事でした。正直、どこまで効果が出るのか不安でしたが、目に見えて問い合わせ数が減ってきたのは嬉しい驚きでした。地道にしっかりとバグを無くしていく事はそのままアプリのクオリティーに繋がるのだと強く実感した半年でした。※CREも各開発チームも対応をしてくれて本当に感謝しています。

CREで将来やりたいこと

CREは現状ようやく土台が整ってきた状態です。これからやっていきたいこととしては、よりお客様の本質的な課題を発見し、それを解決する機能開発を増やしていきたいと思っています。さらに未来はお客様の行動を分析できるようにし、各開発チームがユーザー行動を詳細にトラッキング・分析して自律的に改善できるようにする、そもそもユーザー体験の悪い状態の機能をリリースさせない体制を作りあげたいです。今は地道な作業の積み重ねなチームですが、CREは安定していけばいくほど技術的な要素が高くなってくるチームだと思っています。

We are hiring!!

弊社でお客様の課題と向き合いたいエンジニア募集中です！！

https://www.wantedly.com/projects/444990

カスタマーサクセスの実現のためCustomer Reliability Engineering(CRE)チームを立ち上げました was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

FiNCの篠塚(@shinofumijp)です。4月からCTOを拝任しました。
本記事では1月から行ってきた「アーキテクチャレビュー」という取り組みについて紹介します。

FiNCではマイクロサービスを6年前から採用しており、順調にサービスも成長したおかげで、現在では稼働しているマイクロサービス数は50を超えるほどになりました。
マイクロサービスの採用により、限られた範囲での開発においては速度を落とさずスケールすることが可能という恩恵を得られましたが、一方でサービス数の増加は安定性、メンテナンス性をはじめとした様々な問題も生みました。その1つにアーキテクチャ全容の理解が困難になるという問題があります。例えば「ユーザが食事を投稿した際に食事アドバイスのプッシュ通知を送る」という機能1つをとっても、アドバイス管理サービスが食事投稿のイベントを検知するためにイベントを購読し、同サービスがアカウント管理サービスやユーザのライフログデータを管理するサービスなどからユーザデータを集め、そして非同期のジョブキューに通知サービスのAPIを利用するジョブを積みワーカーが実行する、といった構成で実現しています。

こういった複雑さは特にSREのようにマイクロサービスエコシステム全体を支えるチームとしては日々の業務に支障を与えるほどになりました。

加えて、スタートアップ企業の開発には往々にしてあることですが、標準化の仕組みが追いつく前に新規開発を急いだり、サービスを運用する中でエンジニアの入れ替わりもあったため、理解している人がほとんどいないアプリケーションも生まれてしまいました。

開発に関わっていないアプリケーションでは具体的には以下のものが不明となっていました。

• アプリケーションの責務
• 他のアプリケーションとの関係性
• アプリケーションの影響範囲、依存先と依存元
• アプリケーションに求められる安定性やレイテンシ、スループット等のパフォーマンス要件

これらが原因となって、開発速度の低下、予期しない障害を生んでしまう、障害時の対応が長引く、といったことが起きていました。

プロダクションレディマイクロサービスとの出会い

このような状況下でFiNCのアプリケーションアーキテクチャの理解を深め、より安定してスケール可能なアーキテクチャを検討することを目的として「アーキテクチャレビュー」を行うことにしました。
アーキテクチャレビューのアイディアはプロダクションレディマイクロサービスより拝借しました。同著にはUberのSREエンジニアがマイクロサービスを高い水準で標準化するために社内で行ったことがまとめてあります。

アーキテクチャレビューの進め方を参考にしたのはもちろん、FiNCには元々「プロダクションレディ(= アプリケーションがプロダクション環境で稼働するために満たすべき要件)」という概念がなかったことの気づきや、マイクロサービスにおけるアプリケーションエンジニアとSREの役割を見直す機会にもなりました。
元々FiNCではアプリケーション運用、特にインフラ要件周りはSREが担当しており、いわゆるDevとOpsが分かれている状態でした。しかし、日々開発の進むアプリケーションに対してSREだけでプロダクションレディへの対応を行うのは不可能なため、アプリケーションエンジニアにもマイクロサービスエコシステムを理解し、プロダクションレディへの対応まで担ってもらえるように、サービス開発の心得の啓蒙や権限移譲をはじめとした開発体制の変更も行いました。

アーキテクチャレビューの進め方

準備

サービスの選定
全部で50を超えるマイクロサービスがあり、時間の制約上全部のサービスをレビューするわけにもいかないため、レビュー対象とするサービスを選定しました。

選定の基準として課金機能を有している、リクエスト数が多いものなど、ビジネスに影響を大きく与えるものを中心に30個程度に絞りました。

テンプレートの準備
アーキテクチャレビューはアプリケーションのドメイン知識を有している、担当のアプリケーションエンジニアを中心に行います。アプリケーションエンジニアの準備の手間を削減するためにテンプレートを用意し、あわせて事前準備する項目とレビューを通して確認する項目を分けるようにしました。

事前準備が必要な項目

• アプリケーションの責務
  主に何をやるサービスか、何はやらないか、類似サービスがあればその境界など
• APM(Application Performance Manager)のURL
• 依存関係の図
  Datadog(後述)のServicesをキャプチャして利用
• パフォーマンスとスケーラビリティのボトルネック
  思い当たる場合は記載
• 単一障害点
  思い当たる場合は記載
• 起こりうるインシデントや機能停止
  思い当たる場合は記載
• 主要メトリック
  決まっている場合は記載、決まっていない場合はアーキテクチャレビューを通して決定
• プロダクションレディチェック
  プロダクションレディマイクロサービスに記載されているチェック項目をFiNCの基準でレベル分けして、満たせているものと満たせていないものを確認した。あらゆるアプリケーションが満たすべきレベルには包括的なドキュメントの用意や、デプロイパイプラインの整備と自動化など。努力目標のレベルには障害の自動的な検出と復旧や、単一障害点の排除などを分類した。

アーキテクチャレビューを通して確認する項目

• アーキテクチャ図
• トラフィックのパターン
• プロダクションレディへのロードマップ

実施内容

参加者にはサービスを担当するエンジニアとSREの出席は必須とし、その他のエンジニア、企画職の人に対してもオープンにして実施しました(本筋とは逸れますが大人数のスケジュールを押さえるのでスケジュールの調整が地味に大変でした・・・)。

アーキテクチャレビューはテンプレートに沿って進めます。まずアプリケーションの責務を確認した後に、主要な使われ方の処理の流れをホワイトボードを用いて説明します。FiNCではDatadogという監視サービスを用いており、サービスの依存関係を表示する機能もあるので併せて利用しました。ただ、ユーザのサービス利用とどのように関係しているかといったドメイン知識と結びつけた情報や、処理の流れといった動的な情報はトラッキングされた情報からはわからないため、ホワイトボードでアーキテクチャを図示しながら解説しました。

次に、処理の流れの中で、依存先がダウンしていた場に何が起きるのかを確認します。例えば、データの不整合が発生するか、リトライすることで結果整合は保たれているか、自身を呼び出すサービスが連鎖してダウンすることはないか、などを確認しました。特に、ログイン情報を管理するサービスや、ユーザ名などの個人情報を管理するサービスへの依存が多くなってしまうので、これらのサービスを利用している場合にはリクエストがスパイクする可能性、ダウンすることで起き得る二次災害や大惨事、回避する方法の検討を慎重に行いました。

続いて現状のメトリックを確認します。エラーレート・負荷に異常なスパイクが発生していないか、日次や週次や月次で負荷が上がることはないか、ある場合は依存関係含めたオートスケールは適切に設定されているか、などを確認しました。また、アプリケーション全体の中でのサービスの果たす役割を考えた上での注視すべきメトリックを確認しました。非同期ジョブが中心のサービスであればワーカーのスループットと個々のジョブの完了時間、ユーザのアカウント作成後のチュートリアルを担当するサービスであれば完了率や完了にかかるまでの時間など、インフラレベルのものとサービスレベルのものをそれぞれ確認しました。

最後にラップアップとして上がった問題を優先度付けして、プロダクションレディにするためのTODOとロードマップを作成しました。具体的に出てきたTODOの例としては、監視できていない主要メトリックの取得、ダッシュボードの作成、APIのタイムアウト時間の見直し、依存先がダウンしている場合に遅延実行を行う仕組みの実装、キャッシュの利用、効率の良いルーティングの利用などが出ました。

実施後

アーキテクチャレビューで出てきたTODOは緊急のものはすぐに対応し、それ以外のものはチケット化して開発スケジュールに入れて対応しました。またFiNCには月に1日、新規開発を止めてメンテナンス及び負債解消を行う日があるのでその日も使って対応をしました。

アーキテクチャレビューを複数のサービスを対象に行ったことによって共通した課題も発見することができたので、サービス毎に解決するのみでなくライブラリを作ったり、インフラレベルで解決することも行いました。

アーキテクチャレビューを振り返って

アーキテクチャレビューの質は参加者に大きく依存します。例えば、アプリケーションエンジニアがアプリケーション知識を幅広く有し、よく理解している場合には議論も深まりました。分散システムやアプリケーション運用の経験が長いエンジニアがいたおかげで、アプリケーションに応じた起こりうる機能障害のシナリオや有効な回避策の提案もあり、参加者全員の学びにつながることもありました。

得られた恩恵

認識していなかった依存関係、トラフィックパターン、将来起き得る問題の把握や、マイクロサービスエコシステムの中における自サービスを見直すきっかけとなりました。新規実装時のアーキテクチャの相談も共通の前提がある上で行われるようになり、不安定化につながる依存を避ける方法の検討をするなど、分散システムを意識した設計と実装が行えるようになりました。

またアーキテクチャレビューで使用したドキュメントも開発ガイドとして保存したことで、新しく開発に参加したエンジニアのキャッチアップの助けにもつながりました。

今後

アプリケーションアーキテクチャは今後も変更されていきます。また、ユーザ数やユーザの利用方法に応じて、トラフィックのパターンやスケーラビリティの課題も変わってきます。そのためアーキテクチャレビューは定期的に行う予定です。
高い水準で安定したアーキテクチャやアプリケーション運用を行っていくためには多くの課題があります。SLI/SLOの設定と運用、適切なアラートシステムとロギングシステム、単一障害点の排除、自動化された障害検知と回復、などなど。
FiNCではSREと協働してこれらの課題の解決し、ユーザによりよい体験を届けるサーバーエンジニアを募集しています。

https://www.wantedly.com/projects/444990

追記

2020–06–30
本記事で紹介したアーキテクチャレビューの取り組みについて、FiNC主催のオンラインミートアップでより詳細に紹介します。
https://finc.connpass.com/event/180590/

アーキテクチャレビューはじめました was originally published in FiNC Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.