自律性を高める小さなチームの開発スタイル

はじめまして。株式会社エス・エム・エスの土屋匠です。

弊社では医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会の情報インフラを構築しており、シニアライフ事業領域では高齢社会が直面する「高齢社会の生活にまつわる困りごとの解決が困難になる」という社会課題に対し、「多様な選択肢と質の高い意思決定情報の提供」を通じて解決を目指しています。

私はこの4つの領域のうちシニアライフ領域のエンジニアとして、介護で悩む人向けコミュニティ「安心介護」とケアマネジャー向けコミュニティ「ケアマネドットコム」の2つのコミュニティサービスの開発を担当しております。2サービスとも直近ではサイトリニューアルを行い、新しいアーキテクチャのもと課題解決に取り組んでいます。

今回は私たちのチームカルチャーや開発スタイルの一部について紹介したいと思います。

小さなチームでプロダクト開発をリード

シニアライフの事業領域はIRで公開されている情報にあるように、他の事業分野と比較すると売上規模が小さく加速度的な成長を目指しているフェーズの事業が数多く立ち上がる部署です。横断的な部署とプロジェクトを組み連携しながら進めることもありますが、1名で事業立ち上げのプロダクト開発をリードしたり1つの開発チームで複数のサービス開発を担います。

チームメンバーには

  • オープンソースのコードを読み、そのプロジェクトにIssueを立てPull-Requestを投げる
  • 海外経験あり英語ドキュメントを難なく読んでしまう
  • 先見性を持って最新のデザインツールやフレームワークの提案や導入をする

など、多種多様な視点で集まったナレッジがプロジェクトの課題解決の後押しとなっています。 私たち開発チームの技術スタックと開発で使用するツール類の一部を紹介します。

f:id:bm-sms-product-dev-saiyo-pr:20220317180834p:plain

カルチャー1「成長を加速させる当事者意識」

機能開発は誰にとってどんな目的の機能を提供するのかを明確にした上で、細かい仕様や技術選定などは個人に判断を委ねています。よくトップダウン型のチームだと開発チームの技術スタックや課題解決の質がトップの能力や経験に引きずられてしまうのですが、 個々の能力が最大化された状態のチームであるためには制約は少なく、ゴールのありたい姿だけを共有するようにしています。

時には細かい仕様の落とし込みなど実装する際にチームでの議論が必要になりリリースまでのリードタイムが長くなってしまうこともありますが、話し合うことでチームの全員がその意思決定に対して腹落ちして前に進むようにしています。

その甲斐あって、私たちは当事者意識を持ち主体的に働いており、個々の能力の最大化が個人のさらなる成長にも寄与しています。

カルチャー2「心理的安全性で改善が活発化」

私たちは失敗を許容できるチームでありたいと思っています。たとえば、サービス運営をしていると多かれ少なかれ不具合が発生しますが、それは失敗してもいいということではなく同じことを繰り返さないようにその失敗から学び成長できると捉えています。

チームでは誰が言ったかは重要ではなく、正しいことを正しいと言えてその実現に向けて愚直に取り組むことを大事にしています。 開発者が自身で改善Issueを立てることがあり、そこからプロダクト改善がスタートすることもあります。これはとても良い習慣で、誰かに遠慮したりせず常に物事の対象がプロダクトに向いています。

カルチャー3「生産性が高い非同期コミュニケーション」

同期的なコミュニケーションはZoomまたはGoogle Meetで2週間に1度の定例ミーティングで行っています。これは全員が持ち回りで前後2週間のタスクを共有します。この定例ではプランニングも兼ねているので、緊急度・重要度の判断軸に当てはめて事業戦略とすり合わせながら開発タスクを決めています。

それ以外のコミュニケーションは非同期で取ることがほとんどです。通常は同期的なコミュニケーションの比重が高いほうが一般的かもしれませんが、私たちのチームは非同期コミュニケーションの比重が高いのが特徴です。非同期コミュニケーションはSlackやGitHub上で全員が目にできる場所でオープンにしようと心掛けています。

課題共有や解決のアプローチなどはすべてGitHub Issue/Pull-Request/Wikiに残します。それをドキュメントと呼ぶには程遠いですが、思考や作業のプロセスを時系列にトレースして振り返ることができるようになっています。

プロダクトの開発フェーズ

2サービスとも直近のリニューアルでペルソナやユーザーストーリーからコア機能の再定義を行いました。現在は一定のアーリーアダプターが付いており、ユーザー自身の課題を解決するためにプロダクトを利用してもらっています。

そのようなフェーズですので、あらためてユーザーからのフィードバックを得て改善を進めており、プロダクトの細部に至るまで使い勝手を改善することや機能仕様を見直すことが第一に求められます。 もちろん必要があれば新機能の開発なども進めますし、定期的にビジネス側とKPIのすり合わせを行い、日々のプロダクトの利用状況を可視化することも大事な開発タスクとして取り組んでいます。

施策立案からリリース後の検証

まずはユーザーの声に耳を傾け、定量的なデータの分析を行い、ユーザーの課題を洗い出します。洗い出した課題に対してビジネス上のインパクトや課題の重要度・緊急度を鑑みて優先度付けをした上で高いものから順に仮説を検証していきます。もちろん解決策が疑う余地もなく有効である場合にはそのまま機能を作り込みにいくこともありますし、逆に解決策を作り込んで提供するにはリスクが高い場合には人手のオペレーションで試してみたり外部ソフトウェアなどのツールを利用して検証します。

プロダクトのフェーズからも分かる通り、改善スピードをあげて対応していくことが重要なのでリリースのタイミングは基本的にコードレビューと検証環境で動作確認が通ったら順次リリースしていきます。これは実装コードと対になるユニットテストやインテグレーションテストが通っていることが前提です。もちろんユーザーやビジネス上のクライアントへの影響がある場合には事前のアナウンスや日程の取り決めを行いリリースします。

リリース後の検証も定量的なデータを分析して評価します。日常的にモバイルやPCからサイトにアクセスして使われるコミュニティサービスという特性上、ある程度の母数のあるユーザーにすぐ届くので、ユーザーの反響が定量的なデータに反映されやすく、事業の手触り感を得やすいのも特徴の1つです。

開発者体験(DX:Developer eXperience)の向上

新しいアーキテクチャでの開発をスタートして以降、開発者体験の向上にも力を入れています。たとえば、言語・フレームワーク・ミドルウェア・ライブラリのバージョン管理を導入していますが、単に脆弱性に対するセキュリティアップデートだけの用途ではなく、開発者が生産性が高く気持ちよく開発することができる環境をつくるためでもあります。

具体的にはDependabotで依存ライブラリのバージョンアップを毎日行っています。Breaking Changesを含むメジャーバージョンへのアップグレードも発生しますが、利用の技術スタックの最新動向を知る機会と捉えて積極的に対応しています。

直近だと Ruby / Rails / Vue.js へのアップグレードを終わらせ、今後は AWS CDK のアップグレード対応を視野に入れています。そしてこれらの保守対応は事業施策と同じテーブルにあげて優先度付けされ対応していくので、プロジェクトで利用する技術スタックは比較的最新のバージョンに保たれています。

さいごに

私たちは小さなチームですが、その分フットワーク軽く自律的な行動ができるひとが集まっています。今後もシニアライフには様々なアーリーフェーズの事業が立ち上がることから、技術を武器に社会課題の解決に貢献したい仲間を求めています。 事業の初期段階からプロダクト開発をリードしたいひとがいましたら、一緒にワクワクするようなプロダクトをつくりにいきましょう。