駆け出し開発チームでも45万回利用されるシステムを2カ月で作れた話

はじめに

こんにちは、ソリューションサービス部ICTイノベーション部門の安部、江口、谷内です。

私たちのチームでは2022年7月より「脳の健康チェックフリーダイヤル」サービスの機能開発を担当し、世界アルツハイマーデーである同年9月21日に無償トライアルを開始しました。ニュースリリースをはじめ、TVや新聞等の各種メディアで取り上げられたこともあり、現時点で約45万回以上ご利用いただいています。

本記事では開発に至る経緯や、システム構成・開発体制ならびに今後の展望まで、プロジェクトの全体像をご紹介させていただきます。今後の開発のご参考になれば幸いです。

脳の健康チェックフリーダイヤルのご紹介

脳の健康チェックフリーダイヤルは、電話をかけて日付と年齢を発話するだけで、AIが20秒程度で認知症の疑い有無を判定できる無料のサービスです。

サービスの詳細はこちらのURLをご参照ください。

ここから、本サービスの成り立ちなどを少しだけご紹介させていただきます。

プロジェクトのはじまり

「認知症で不安になる本人・家族・企業が少なくなる社会へ」をコンセプトに作ったサービスです。

NTT Com の社内ビジネスコンテストから生まれ、プロジェクト(以下:PJと記述)の中心メンバーの祖父母が認知症になった経験から、認知症で大変な思いをする人が少しでも減るようにという想いが込められています。

サービスコンセプト

高齢の方にも気軽に使っていただけるように、Web上やアプリではなく、電話で利用できることにこだわって制作しました。

脳の健康チェックフリーダイヤルサービスには以下のような特長があります。

  • 事前の登録やダウンロードが不要
  • 自宅の固定電話や携帯電話で利用できる
  • 誰にも知られずに試すことが可能

サービスリリースから多くの方にご利用いただけているのも、手軽に認知機能の変化を確認できる仕組みだからこそだと思っています。

システムの紹介

構成図

脳の健康チェックフリーダイヤルは、電話を受けるクラウドIVRと、そのバックエンドを担うGCPおよび外部APIを中心に構成されています。

ここでは詳細な説明は控えますが、構成図の上側はユーザーが電話をかけてサービスを利用する経路、下側は管理者がサービスの利用状況を確認する経路となります。

認知機能の判定

認知症の疑い有無の判定については、音声から音声特徴量を抽出し、認知機能の変化をチェックする日本テクトシステムズ社のONSEIと連携することで実現しています。

ユーザーが発話した音声を利用し、ONSEIのAPIと連携して認知機能の判定結果を取得します。この判定結果をIVRに音声発話させる仕組みを作り、ユーザーに認知機能の変化をお伝えしています。

ログデータの保存

ログデータの保存には、今後の開発でデータベースの構造を変更する可能性があることや、部分的なログデータを取得・更新することを考慮し、GCPのFirestoreを使用しています。

また、ログ参照用のWebアプリを独自で開発しており、こちらのフロントエンドフレームワークにはReactとNext.jsを使用しています。これらはWebサーバー機能を持つフレームワークの中でもJavaScriptを利用するため学習コストが低く、高速描画が可能なため、採用しました。

画面のデザインやコンポーネントの部分には、ReactのUIライブラリであるMaterial-UIを使用しています。

また、開発メンバー全員でログ参照用のWebアプリを利用しながらシステムの改善点を話し合う取り組みも行っており、実際に一部の不具合の改修や追加機能の開発に繋げることもできました。

アプリケーションの実行環境について

GCPのアプリケーション実行環境としては、Cloud Run, Cloud Functions, Google Kubernetes Engineなど複数の候補がありますが、今回はGoogle Kubernetes Engine(以下:GKEと記述)を採用しています。

今回GKEを選択した大きな理由を、以下にまとめました。

  • コンテナ死活監視による自己修復機能
    • 24時間利用可能なサービスのため
  • ローリングアップデートが可能
    • ダウンタイムなしで継続的なアップデートを行いたいため
  • 自動スケールアウトが可能
    • 通常時とメディア紹介時などでユーザの利用量が数十倍単位で変動するため

脳の健康チェックフリーダイヤルは24時間利用可能なサービスとして提供しているため、ダウンタイムを極力発生させないことが最も重要な観点でした。また、マニフェストファイルベースでリソースを管理することで、環境構築が容易になる、環境間での差分がコード上で確認できるなどのメリットも得られました。

Kubernetesの利用は学習コストが高いイメージでしたが、GKE Autopilotを用いてプロジェクト固有のオペレーション部分のみ設定値を追加して運用することで、短期間で本番環境向けの基盤を構築できました。

開発体制の紹介

すでに多くの方々にご利用いただいている脳の健康チェックフリーダイヤルですが、開発チームは2年目社員2名、1年目社員1名、パートナー社員1名のかなり若いメンバーで構成されています。

本章では、このような開発経験の浅いチームが、2カ月という構築期間の中でサービスリリースを達成するまでに直面した課題と、その解決にいたった成功要因を紹介いたします。

若いチームならではの課題

開発経験に乏しいチームの課題として、真っ先に直面するものは、多くは経験の少なさによるものかと思います。本PJは、2022年9月21日の世界アルツハイマーデーにリリースするという、スケジュールが決まったウォーターフォール型のPJとしてスタートしました。しかし、私たちのチームではウォーターフォールでの開発経験がなかったため、開発プロセスの習熟面に課題がありました。また、チームとしてインフラ構築を中心としたシステム開発の知見に乏しく、メンバー間でも知識に差がある、といったスキル面での課題がありました。

一方で、今回のチームならではの強みもありました。それは、チームビルディングの面と、スクラムでの開発経験値です。今回の開発メンバーは、別案件のスクラムチームのメンバーがほぼそのままアサインされる形だったため、すでにお互いのスキルや開発環境の把握、関係性の構築などが完了している状態でした。また、ウォーターフォール開発には疎いものの、スクラムのフレームワークに対する共通認識は持つことができていました。

そのため、私たちは実際の開発に着手する前段階として、今回のウォーターフォール開発PJを、どうにかして自分達の慣れているスクラム”風”に進められないかを考えるところからスタートしました。

開発プロセスの課題解決につながったこと

スクラム風に開発を進める

ここではスクラムフレームワークに関する説明は省きますが、スクラムは柔軟に変化に適応するための開発手法のため、成果物と納期が明確になっているウォーターフォール型PJには本来適応できません。しかし、本PJのPMがスクラムに理解のある方だったこともあり、開発メンバーからスクラムの様に開発を進めたい旨を伝えると、快く相談に乗っていただけました。結果的に、以下のような取り組みのもと、擬似的にスクラムの様に進めることができました。

  • WBS(進捗管理表)の中項目をプロダクトバックログ(プロダクトの改善に必要なもの)と見立てた
  • PMが定める各項目の期日について理由を確認しつつ、各スプリント(スクラムにおける開発期間の単位。本PJでは一週間)での対応範囲についてPMとの意識合わせを行なった
  • WBSの進捗の遅れに対するステークホルダーとの調整を、PMに柔軟に行なっていただいた

1つのスクラムチームに集中する

スクラム風に進めていくと決定した訳ですが、開発着手直後はそれまで所属していたスクラムチームと兼任する形になってしまいました(PJ立ち上げ時にはよくある話かと思います)。しかし、複数のスクラムチームの兼任は基本的にご法度です。スクラムではスクラムイベントと呼ばれる活動に開発期間の20%以上の時間を費やすため、仮に2つのスクラムチームを兼任すると、実作業時間が80%から少なくとも60%以下に減少します(複数案件による認知負荷の増加を考えると、作業効率も悪くなります)。

開発チームとしてはそういった問題を初期段階から認識していたため、ステークホルダーとの相談により3スプリント目(≒3週目)からメンバー全員が本スクラムチームに専念できました。アジリティ高く兼任問題に対応できた点は、スクラムに対する共通認識を持てている本チームの強みが発揮された場面だと感じています。

スキル面の課題解決につながったこと

メンバー間のスキル格差を埋める

スクラムにおいては、開発メンバー全員がどんなスプリントバックログ(≒開発タスク)にも着手できる状態が理想です。しかし、開発経験が浅い本チームでは、初めて経験するような作業も多く、特定のメンバーしか着手できないようなタスクになってしまう危険性がありました。

その対策として、本チームでは意識的に情報発信の手段を増やし、その頻度を高めています。具体的には以下の内容に継続して取り組んでいます。

  • タスク着手時にSlack上で作業状況を実況するスレッドを立てる
  • 後続タスクを進める上で必要になる情報、ノウハウがあればNotion上に開発備忘録としてまとめる
  • スプリント内でマージされたコードに対して、スプリント最終日に全員でコードリーディングを行う
  • 定期的に全員でアプリケーションのリファクタリングを兼ねたコードリーディングを行う
  • 毎週不安のある技術要素などについて勉強会を行う

これらの活動は、時間的コストがもちろんかかるのですが、特に経験の浅いチームにおいては、最終的に費用対効果がプラスになると感じています。チームメンバー全員の理解の助けになることも勿論ですが、何かしらのアウトプットを伴うことで、タスクに着手したメンバー本人の理解度も向上し、結果的に後続タスクの実施速度も上がるためです。

実際に達成したベロシティ(タスクの重さの相対的な見積もり値)の推移を見てみると、スプリントが進むにつれ大きくなっていく結果になりました。

これには、スキル共有や自発的なアウトプットにより、PMに管理されなくても開発メンバーが率先して動くことができる、自己管理型のチームとして動けたこともプラスにはたらいていると感じています。

経験値のあるメンバーを最大限活かす

一方で、若手メンバーだけでは解決できない技術課題があったことも事実です。システムのセキュリティ対策や、根が深いエラーの調査など、対応難易度が高いタスクについては、経験を積んでいるパートナー社員の方に集中的に対応していただく機会が多かったです。

これは経験値のあるメンバーに丸投げするという話ではなく、各スプリントのベロシティを最大化するためにどのように行動するのが最適かを、開発メンバーが自律的に判断して出した結果になります。スキルを持つメンバーに技術難度の高い課題にフルコミットしてもらえるように、チームとして柔軟に動くことが出来た点も、短期間でのリリースに繋がったと感じています。

まとめ

私たちのチームでは、開発経験の浅いチームによくあるであろう課題について、以下のように取り組みました。少しでも参考になる取り組みが見つかれば幸いです。

  • ウォーターフォールでの開発経験がない
    • スクラム”風”開発のためのステークホルダーへのはたらきかけ
      • 1つのスクラムチームに集中するためのはたらきかけ
  • システム開発のスキルに乏しい
    • 開発メンバーの自発的なアウトプットの仕組み作り
    • チームのベロシティを最大化する意識付け

脳の健康チェックフリーダイヤルの今後

脳の健康チェックフリーダイヤルは、少しでも多くの方に、より早く使っていただきたいという思いから、まずは最小限の機能でリリースをしています。

一方で、より「認知症で不安になる本人・家族・企業が少なくなる社会」の実現を目指して、現在も開発を続けております。その内容を一部、ご紹介させていただきます。

サービス機能の拡充

認知症の一層の早期発見・早期治療を促していくため、認知症の一歩手前の状態「軽度認知障害」、もしくは「MCI(Mild Cognitive Impairment)」といわれる状態を検知する仕組みを検討しています。こちらの仕組みを実現し、脳の健康チェックフリーダイヤルへ組み込むことを目指して、日々開発に取り組んでいます。

また、データの収集/分析の機能を組み込み、「データ利活用」ができる仕組みとすることで、より社会貢献につながるサービスを目指しています。

パートナー企業様との協業

このサービス単体で何かを成し遂げるには限界があるため、利用者の悩みを解決できるようなパートナー企業様との協業を、本格的に実施していきます。

とてもありがたいことに、2022年9月21日のニュースリリースの段階で、この取り組みに対して多くのパートナー企業様に共感・賛同いただきました。「認知症で困る本人・家族・企業が少なくなる社会」の実現に向けたさまざまな分野での取り組みを加速するため、認知症に関する社会課題解決にともに取り組んでいただけるパートナー企業様を引き続き募集しております。

おわりに

今回は「脳の健康チェックフリーダイヤル」サービスの開発の裏側をご紹介しました。

今後はサービスをより多くの人に使って頂けるよう、パートナー企業様と連携しながら、日々改善に取り組んでいく所存です。2023年3月末まで無料で利用可能の予定ですので、皆様も是非ご自身やご家族などの健康増進にご活用ください!

最後までお読み頂き、ありがとうございました。

© NTT Communications Corporation All Rights Reserved.