モダンな開発環境を追求するSMSの技術負債解消の軌跡

介護や医療、ヘルスケア、シニアライフの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エス（以下、SMS）のエンジニアの神谷です。コードを書く以外にも、採用などの組織づくり、開発環境整備など幅広く仕事をしています。

自分がSMSに入社したタイミングでは、開発現場にはよくある、開発環境がアップデートされていない、デプロイのためのコストが高く一度のリリースが大きくなってしまうなど「技術的負債」がたまっており、どのように負債を解消していくかを模索していました。

今回は、技術的負債の解消にどう取り組んできたのかを振り返って紹介できればと思います。少しでも、技術的負債に悩む方々の参考になれば幸いです。

技術的負債の解消に立ちはだかる様々な壁

自分は、iOSのエンジニアからキャリアをスタートしました。スタートアップでエンジニアをはじめたので、基本的にはなんでもやる姿勢で開発と雑用に取り組んできました。サーバーサイドのスキルも身につけながら、よりレベルアップすることを目指して、2019年1月にSMSへ入社しました。

入社時は、介護事業者向け経営支援サービス「カイポケ」の開発・運用をおこなうチームに配属されました。自分が配属される前からチームでは、技術的負債の解消を担っていたものの、カイポケは40個のサービスが集積したプロダクトということもあり、日々の運用だけでも対応する業務は膨大なものになっていました。

その対応に追われて、どうしても負債へのアクションは後回しになっている状態が続いていたのです。

入社したときから、技術的負債の解消に取り組むことは決まっていたのですが、技術的負債に取り組めるまでには超えなければならないハードルが、大きく3つありました。

1. ビッグイベントへの対応
2. リソース確保の仕方
3. 開発環境の古さ

まず、大きなハードルだったのは、2019年の「消費税増税」「元号改定」「介護報酬改定」という3つのビックイベントたちです。

一つひとつのビッグイベントに対応するために、開発のリソースは逼迫。さらに残りのビッグイベントは波状攻撃のように順番にやってきました。日々の運用と、社会環境の変化に対応するための開発とで現場は手一杯でした。

もちろん、何もしなかったわけではありません。「週に何日は技術的負債の解消に使う」と決めて、時間も確保していました。ですが、これもうまくワークしませんでした。週に何日しか時間の確保ができていないと、作業ごとに前回の作業内容を思い出すまでに時間がかかり、効率的に作業が進められなかったのです。

また、開発環境にも問題がありました。アプリケーションのリソースがファイルサーバーに置いてあり、どこのファイルを書き換えたら、どう振る舞いが変わるのかがわからない、手順書通りにやって動かないために、手作業が多いなど、問題が山積みでした。開発プロセスも管理できておらず、カンバンにはWIPのものがたくさんありました。

技術的負債を解消していくためには、組織体制を整えること、開発環境を整えることから始めなければ、とても進まない状態でした。しっかりと負債解消に向けたアクションをとるためには、抜本的な改革が必要だと考えたのです。

そこで、SMSの技術責任者である@sunaotに、負債解消のための青写真を持って提案しました。「ビッグイベントが終わったら、また運用にリソースをとられている間に、次のビッグイベントが来てしまいます。変えるなら今しかありません」といったことを話したと思います。

提案は思っていた以上にあっさりと承認され、ビックイベントの対応が終わった後に、負債解消のためのアクションをすることになりました。

技術的負債解消のためにとった7つのアクション

提案後、技術的負債の解消のために7つのアクションを進めていきました。重複する要素もありますが、実施したのは以下のようなことです。

1. 技術的負債解消を最優先でやるために割り込みから保護してもらう
2. やることをひたすらプロダクトバックログにする
3. 捨てる（あきらめる）機能を決める
4. カンバンからレビュー待ちのレーンをなくす
5. 機能を小さく作っていく
6. データベースからフロントエンドまで、常に結合した状態で進める
7. リリース時期に幅をもたせる

1. 技術的負債解消を最優先でやるために割り込みから保護してもらう

まず、技術的負債解消を最優先でやるために割り込みが起こらなくなるよう、技術的負債を解消する専門の小規模なチームをスピンアウトしてつくりました。カイポケの日々の運用を引き続き担ってくれるチームがいたからこそできたアクションです。これには、今でも感謝しています。そのおかげで、負債の解消に集中するチームができました。

2-3. やることをひたすらプロダクトバックログにする / 捨てる（あきらめる）機能を決める

続いて、とにかく良いプロダクトバックログをつくることに取り組みました。直近でやることが把握でき、タスクの規模感が見えていて、並べた順に進んでいければリリースができ、トカゲのしっぽ切りにできるものは下に置いてある、そんなプロダクトバックログの基本が反映されたものです。

プロダクトバックログをつくりながら、負債の解消を進める上で、リターンとかかるコストをチームで検討します。例えば、お客様が閲覧する画面の構成が変わってしまう開発があったときに、無理に再現しようとするのではなく、優先順位を下げる、といった対応をしていきました。すべてをなんとかしようとするのではなく、あきらめる機能を決めることも必要です。

4. カンバンからレビュー待ちのレーンをなくす

カンバンに存在したレビュー待ちのレーンを外しました。レビュー待ちやコンテキストスイッチの無駄を作らないように、お互いすぐに声をかけてレビューしたり、ペアプログラミングを行うことを進めていきました。チーム編成も、リアルタイムでコミュニケーションができるメンバーを中心に構成しました。

5-6. 機能を小さく作っていく / データベースからフロントエンドまで、常に結合した状態で進める

全てのレイヤーを作り終えてからテストを行い、不具合が見つかれば差し戻すというサイクルで開発が行われていたため、改善していく必要がありました。新しい体制では、アジャイル開発のプラクティスを取り入れ、1週間のイテレーションで開発を進めていきました。レイヤーごとにすべて開発してから結合・検証するのではなく、インフラからユーザーインターフェイスまでのレイヤーを跨いで、スライスするように開発していきました。データベースからフロントエンドまで常に結合した状態で進めることで、テストをしやすい状態も作って、素早く検証できる環境をつくりました。

7. リリース時期に幅をもたせる

「いつリリースできるの？」と聞かれたときに二点見積もりの手法を使うようにもしました。最短かつ無事故で開発が進んだ場合と、トラブルがあったとしてもプロフェッショナルとしてここまでにはリリースしなければ、という場合の幅をもたせたリリース時期を回答するようにしていました。不確実性を減らしながらリリース時期の幅は徐々に狭めていき、ステークホルダーとの信頼関係構築に配慮しました。

開発プロセスや技術スタックもモダンな環境に引き上げる

こうしたアクションを積み重ね、チーム内で密なコミュニケーションをとりながら、細かい開発を重ねて軌道修正を早く行うことで、「チームで完成させる」という意識を持ってもらうようにしました。開発環境を整える上で他にも実施したのが、技術スタックの改善です。技術スタックを考える上での基準は、以下の3つ。

1. デファクトスタンダード
2. オープンソース
3. メンテナビリティ

多くの企業で使われるデファクトスタンダードであり、オープンソースになっていてソースコードを自分たちで読むことができ、コミュニティが育っていて技術のメンテナンスが頻繁にされているというポイントを満たしていること。

インフラは既にAWSに移行済みでしたし、技術スタックの一部は元々使っていたものを踏襲しながら、上記の基準に合わせて入れ替えていきました。現在の技術スタックは以下のようになっています。

• Spring Boot

• Kotlin 1.4

• Amazon EC2

• Amazon Aurora

• Amazon ElastiCache

技術的負債の解消のために重要な3つのポイント

ここまで、技術的負債を解消するためにとってきた行動を紹介してきました。行動を振り返ってみて、技術的負債の解消のためには3つのポイントが重要だったと考えています。

1. 負債のコンテクストがわかる仲間を集める
2. 返却するとどんな嬉しいことがあるのかを丁寧に説明する
3. 小さなチームで、プラクティスを少しずつ取り入れる

まず1点目が、「負債のコンテクストがわかる仲間を集める」です。技術的負債の解消のために、外部からスペシャリストを招くこともありますが、状況把握までかなり時間がかかってしまうことが考えられます。

「負債はどこにあるのか」「この負債はどういう経緯で発生したのか」をすでに知っているメンバーで構成すれば、背景を理解した上で解消に取り組んでいきやすいと考えています。

2点目が、「負債を解消すれば、どんな嬉しいことがあるのかを丁寧に説明する」です。これは、開発チームだけでなく、社内の様々なメンバーにも伝えることが大切です。

技術的負債の解消は、外から見たら何をやってるチームなのかがわかりにくいにもかかわらず、結構コストをかけていることが多いかと思います。「アプリを昼間にデプロイできるようになる」「1日に何回も変更可能になる」などの技術的負債解消によるメリットを周囲のメンバーにも丁寧に説明していくことが、周囲からの理解を得ながら進めるためには重要です。

3点目に大切なのが、「小さなチームで、プラクティスを少しずつ取り入れる」です。開発環境を整備するために、いくつかのプラクティスを取り入れましたが、一気に取り入れるのではなく、メンバーが納得感を持てるように一つずつ試していきました。関わる人数を少なくしてコミュニケーションコストを減らし、一気に変えるのではなく納得感を醸成しながら進めていくことも重要です。

2周目の負債解消は“強くてニューゲームのはじまり”

技術的負債の解消に取り組んだ結果、フレームワークの刷新、スティッキーセッションからの脱却に成功。さらに、インフラ構成の自由度も上がり、細かな変更を素早く、安全にリリースできるようになりました。そしてこれからは、“強くてニューゲーム”のはじまりです！

技術的負債の解消も、1周目はQAチームが別チームだったために、リリースできるかが最終的な段階までわからず、ヒヤヒヤしながら進めることになっていました。2周目はテストに強いメンバーをチームに入れて、テストまでをチーム内で行える体制にしています。これで、より技術的負債の解消の速度が上がるはず。

まだ、技術的負債の解消のための環境整備は、現時点では自分のチームだけでしか実装できていません。今後は、この成功体験を横展開し、全社的に広げていきたいなと思っています。