現在スリーエスでは、定期巡回に特化した自社プロダクト「PORTALL（ポータル）」の開発に、一緒に取り組むエンジニアを募集しています！
このストーリーでは、PORTALL開発の裏側や、社会にどのような価値を届けているのか、エンジニア組織と開発の進め方など、これまでお伝えしきれなかった魅力を全3回にわたってご紹介していきます！

第2回となる今回は、プロダクトチームのカルチャー・技術・開発プロセスについてご紹介します。
社会貢献の高いプロダクトを、ユーザーと近い距離で開発することに関心のあるエンジニアの皆さんに、私たちのチームについてより詳しく知っていただければ幸いです。

1. プロダクトチームのカルチャー

私たちのチームカルチャーは、二つの事業が密接に連携している点が特徴です。

■ 介護事業とSaaS事業の連携

スリーエスは、介護事業とSaaS事業という2つの事業を展開しています。

介護事業では、「定期巡回」という介護サービスを提供する事業所を運営しています。
高齢者の在宅生活を24時間365日、切れ目なく支えるためのもので、現在都内5つのエリアで約60名の介護職員が、地域に暮らす高齢者の支援を行っています。
SaaS事業では、「定期巡回」に必要な業務をワンストップで効率化するプロダクト『PORTALL』を、日本全国の定期巡回事業者に提供しています。

なぜ、私たちはこの二つの事業を運営しているのか。
それは、24時間365日在宅生活を支える「定期巡回」という仕組みが、まだ日本全国に普及しきっていないという現状があるからです。
私たちは自社で介護事業所を運営することで、介護現場のオペレーションにおけるエクセレンスの構築を目指しています。
そして、そこで得られた知見やノウハウを『PORTALL』に反映・平準化することで、他社の事業所が定期巡回サービスへ参入するハードルを下げ、運営を安定化させることを目的としています。

このように、介護の最前線で得た一次情報をプロダクト開発に活かすため、2つの事業で密接に連携しています。

■ フルサイクルエンジニアリングとチーム文化

専門職である介護職とソフトウェアエンジニア。
バックグラウンドが全く異なるメンバーが、同じ目線で「ユーザーにとって本当に価値のあるソフトウェア」を作ることを目指すため、私たちはフルサイクルエンジニアリングという開発体制を採用しています。

これは、Netflix社が提唱した開発モデルで、エンジニアが企画・設計・実装・テスト・運用といったソフトウェア開発の全工程を横断的に担当する考え方です。
※詳しくはNetflix Tech Blogの記事『Full Cycle Developers』内の図をご覧ください。

定期巡回サービスは市場として黎明期にあり、運用手法もまだまだ確立されていません。
そのため、エンジニア自身がドメイン（事業領域）に深く入り込み、現場の課題解決からプロダクトへの反映まで、一連のサイクルを推進していく必要があります。
この体制では、エンジニアが日常的に、ユーザーである介護職員と連携します。
時にはサービス理解を深めるために、利用者宅へ介護職員と共に同行することもあります。

こうした活動を通じて、バックグラウンドの異なる様々なステークホルダーと連携する中で、チームとして【他者への尊敬を持った対話】【オープンなコミュニケーション】【ドメイン理解とユーザーファースト】を大切にする文化が根付いています。

2. エンジニア組織と開発の進め方

『PORTALL』の開発は、現在2つのチームで行っています。

• テク二課1班（スクラムチーム・3名）：大規模な機能開発など、不確実性の高いテーマを中心に担当
• テク二課2班（副業メンバー・2名）：操作性の改善など、主に既存機能のブラッシュアップを担当

ここでは、中核となるテク二課1班の開発体制について、詳しくご紹介します。

■ 私たちのスクラム：多職種と共に価値を創造する2週間のスプリント

テクニ課1班では、開発手法としてスクラムを採用しています。

＜スクラムイベントの具体的な取り組み＞
□ チーム体制
・プロダクトオーナー (兼 開発者): 1名
・スクラムマスター (兼 開発者): 1名
・開発者: 1名
＊将来的にはメンバーを増やし、兼任体制を解消していきたいと考えています

一方、開発に関わるステークホルダーは、介護事業部長、介護職員の育成チーム、現場の事業所管理者、介護主任、そして最前線で働く介護職員の方々まで多岐にわたります。
多職種と深く関わりながら開発を進めている点が、大きな特徴です。

□ 開発スプリントの全体像
スプリント期間は2週間（金曜日開始、木曜日終了）です。
各イベントのタイムスケジュールは以下のようになっています。

※印がついているイベントは2週間に1回実施

□ スプリントプランニング
スプリントの開始時に開発計画を立てます。
直近のスプリントのベロシティ（開発実績）を参考に、今回のスプリントで達成可能な範囲を見極め、スプリントゴールを設定。
その後、着手するプロダクトバックログアイテム（PBI）を選択し、具体的なタスク（スプリントバックログ）への分解と、大まかなスケジュールを決定します。
また、開発タスクだけでなく「このスプリントでリファインメントしたいバックログ」「ペアプログラミングのタイミング」「次回スプリントレビューに招待するステークホルダー」などもこの場で話し合い、チームの共通認識を作ります。

以下はプランニング時のアジェンダの一部です。

スプリントゴール、着手するPBIを設定

スケジュールをざっくりと設定

□ 普段の開発
開発はプロダクトバックログやスプリントバックログを基に進めます。
誰がどのタスクを担当するかは、Slackで「これやります！」と宣言する早い者勝ちスタイルや、都度の話し合いで柔軟に決めています。

基本的には、一つのバックログに全員で取り組むスウォーミングを実践していますが、効率を考えて並行作業を行うこともあります。
エンジニア間で密にコミュニケーションを取りながら、スプリントがスムーズに進むよう心がけています。

介護事業所での開発風景

□ デイリースクラム
毎日16:30から15分程度のデイリースクラム（夕会）を実施していて、その日の進捗・困っていること・共有事項などを率直に話し合います。
議題は「実装の進捗状況」「プルリクエストはいつ頃出せそうか」「設計やUIデザインの相談」といった開発に関するトピックから、「セールスやCSの業務状況」「社内業務の負荷状況」まで様々です。
開発と直接関係ないことでも、チームや各メンバーの状況を透明化し、お互いをサポートできるよう共有するようにしています。

デイリーボードの一部。カンバン形式でスプリントバックログの進捗を管理

□ リファインメント
週に2回、各1時間程度、チーム全員でリファインメントを行っています。
ここでは、プロダクトバックログのユーザーストーリーや受け入れ基準、UI、実装方針などを具体化していきます。
POだけでなく開発者も主体的に参加し、バックログの優先順位を調整した後、手分けして内容を具体化。
チーム内で認識を合わせた上で、プランニングポーカーによる相対見積もりまで行います。

プロダクトバックログの一覧。優先順位をつけてバックログを管理

プロダクトバックログの一部。ユーザーストーリー、受け入れ基準などを定義

□ スプリントレビュー
スプリントの最終日には、ステークホルダーを招いて成果物のレビュー会を実施します。
管理者や介護職の方々に、開発した機能のデモを見て実際に触ってもらい、フィードバックをもらいます。

好意的な反応は開発チームの励みになりますし、エンジニアにはない現場視点でのフィードバックをもらえることも多くあり、毎回とても有意義な場になっています。
ここで得られたフィードバックは、優先度を判断しながら次以降のスプリントに活かされていきます。

スプリントレビューの様子。介護職の皆さんに参加してもらい、フィードバックを頂いています。

□ レトロスペクティブ（振り返り）
スプリントの最後には、チームでスプリントを振り返る時間を設けています。
FigJamを使い、付箋を貼り出しながら良かった点や改善点について議論し、次のアクションを決めます。
最近はKPTだけでなく、より多角的に振り返りができる「Sailboat」などの手法にも挑戦しています。常にチームとして改善を続けるためのプロセスです。

FigJamの振り返りボード。付箋を使いながら議論します。

■ 働く環境について

エンジニアが勤務するオフィスは飯田橋にあるものの、都内にある複数の自社介護事業所を中心に開発を行っています。
ユーザーである介護職の近くで働くことで、日々の業務や課題に対する解像度を上げることを目的としています。
介護職の皆さんと気軽にコミュニケーションを取ったり、プロダクトに関するフィードバックを直接もらえたりする環境は、とても貴重です。
働き方は柔軟で、フルフレックスタイム制を導入しており、プライベートのスケジュールによって、リモートと出勤のハイブリッド勤務も可能です（実際に、沖縄に帰省してリモートで勤務したメンバーもいます）

3. 私たちの技術スタック

現在の技術スタックは、2022年のプロダクト開発当初の選定がベースとなっています。
前述の通り、開発当初からフルサイクルエンジニアリングの思想があり、開発者の担当領域が広範囲にわたることが、技術選定の大きな指針となりました。

□ 言語選定
フロントエンドとバックエンドで一貫した開発体験を提供し、学習コストとコンテキストスイッチを最小化するため、TypeScriptを採用しました。

□ フロントエンド / バックエンド
フロントエンドにはNext.jsを採用。
API通信にはGraphQLを利用し、スキーマから型を自動生成することで、型安全な開発を実現しています。

□ インフラストラクチャ
AWSとGCPのマルチクラウド構成となっています。
これは、要件に合わせてパフォーマンスとメンテナンスコストのバランスを最適化した結果です。
一部リソースの管理にはTerraformも導入しています。

4. 今後の展望と未来の仲間へのメッセージ

プロダクトの今後の展開として、大きく2つのフェーズを見据えています。

Phase1：定期巡回を全国に広げ、『PORTALL』の価値を最大化する
「どんな人でも、自分の人生を決められる世界」というビジョンと、「住み慣れた家で暮らし続けたい」という多くの人々の想いを実現するため、まずは在宅のライフラインである ”定期巡回” を全国に普及させることが不可欠です。
そのために、『PORTALL』が提供する価値のカバレッジを広げ、一つひとつの機能を磨き上げていくことが必要です。

Phase2：介護を本当に必要とする人へ、適切にサービスを届ける仕組みを構築する
定期巡回の供給量が十分になったとしても、それだけでは課題は解決しません。
介護を必要としている高齢者に、適切なサービスが、適切なタイミングで届けられる社会の仕組みを構築すること。それが私たちの次の大きなテーマです。

スリーエスで働く開発メンバーは、必ずしも最初から介護業界の知識や経験があったわけではありません。
「社会や人に貢献するプロダクトを作りたい」
「ユーザーと近い距離で開発がしたい」
そのような想いを持ったメンバーが集まっています。

この記事を読んで、少しでも私たちのチームや事業に関心を持っていただけましたら、ぜひ一度カジュアルにお話ししませんか？
あなたからのご連絡をお待ちしています。