仮説検証に潜んでいた技術的負債とは
コドモンは「子どもを取り巻く環境をテクノロジーの力でよりよいものに」をミッションに、幼稚園や保育園・学童・小中学校といった施設で働く職員の業務を省力化し、子どもと向き合う時間と心のゆとりを作り出すICTサービス「コドモン」や、保護者とこども施設のコミュニケーションを支援するモバイルアプリケーションなどを開発、提供している。メインプロダクトである「コドモン」は2014年にβ版、2015年に正式版をリリース。現在全国300自治体で採用され、1万3000もの施設に導入されるなど、着実に成長を続けている。ミッションに基づき、他にも保育者向け研修サービス「コドモンカレッジ」、採用・保活支援サービス「ホイシル」、全ての先生を応援する優待プログラム「せんせいプライム」、保育施設向けECサイト「コドモンストア」などの事業を展開している。コドモンの社員数は219人で、プロダクト開発チームは約40人のエンジニアと15人ほどのデザイナーやPdMなどで構成されている。
2020年まで、コドモンでは早くたくさんの機能をつくることを最優先に開発してきた。2019年にコドモンに入社した西銘氏もバックエンドやフロントエンドの開発に携わっていたという。しかし、技術的負債を多く抱えていたことから、2020年より既存のプロダクトを保守しながら、機能単位でのリプレースを加速させるなど、プロダクトを刷新していくフェーズを迎えている。そのような中で、西銘氏は技術的負債の返済に向き合ってきたという。
「技術的負債の返済も長期的にプロダクトを良くすることにつながる」と西銘氏は言う。もちろん、プロダクトを良くすると一口に言ってもさまざまな方法がある。「ユーザーにとっての本当の価値」を仮説検証して積み上げることもその一つである。
例えば「ダッシュボード画面のデザイン変更」という要望があったとする。一般的な仮説検証の流れでは、コードの改修は表示関数を修正すれば良いという前提で、ユーザーが喜ぶデザインはAとBのどちらかという仮説が成り立ち、検証を行い、その結果をプロダクトに反映する。だが、コドモンの場合は、「表示関数を修正すれば良い」という前提がそもそも成り立たず、「前提じゃなかった前提」を追加で修正・検証しなければならない状況が課題としてあったという。つまりコドモンでは本題の仮説検証に至るためには、1～2ステップ多い状況になっていたのだ。この既存プロダクトの「前提じゃなかった前提」こそが、コドモンにおける技術的負債というわけだ。
コードの改善からSREまで、負債に向き合うことで得たスキル
技術的負債を返済することは大事であるとはいえ、それに向き合いたいと思うのは「リファクタ大好きな一部のエンジニアぐらい」と西銘氏は言う。多くのエンジニアはユーザーにとっての本当の価値に向き合いたいと思うのは当然だ。だがこのまま放置すると、いくらエンジニアの人数が増えても、ユーザーのための課題解決に使える時間はあまり増えないことになる。さらに「本来向き合いたい課題に向き合えないつらさで、より多くの仲間が退職してしまうリスクも高まってしまうと考えました」（西銘氏）
エンジニアの仕事を「不確実性を削減し、プロダクトを確実なものとして作り上げていくこと」と捉えている西銘氏は、コドモンでどんな働き方をすると、不確実性を削減できるかを考えたという。「向き合うべき課題は技術的負債の返済だと思い、積極的に負債に取り組むことにしました」（西銘氏）
では技術的負債に向き合うことで、エンジニアとして何を得られたのか。西銘氏は「仕事」と言い切る。有名な「仕事の報酬は仕事」という言葉の意味を、技術的負債の返済を通して実感したといい、その経緯について次のように語る。
技術的負債を解消するため、まず西銘氏が取り組んだのはレガシーコードの改善である。コード修正によるリスクの低減とコードの複雑さを下げるためだ。「リリース環境に放置されていた野良コードのGit管理化とたくさんの処理が依存していた神クラスの解体を行いました」（西銘氏）
地味ながら丁寧な調査や慎重なリリースが求められる作業を繰り返してやりきった結果、可読性と変更容易性が大きく改善し、開発者体験が向上したという。
このことにより、当時のマネージャーからDX（Developer Experience：開発者体験）改善に注力してみないかと声をかけられ、西銘氏はDX改善という新しい仕事に取り組むことになった。
DX改善に取り組む中で、西銘氏は開発者の全員が行うリリース作業によるリスクに着目するようになったという。「開発者がコードを修正してリリースするまでにトイル（手作業）の手順が多数あったため、その削減に取り組むことにしました」（西銘氏）
トイルの削減のため、西銘氏は開発用、アプリ版リリース用、Web版リリース用と3つに分かれたリポジトリの統合に着手。そしてそれに伴うビルド、デプロイ運用を整備し、リリースフローをGitHub Actionsを用いて自動化することを行ったという。その結果、リリース作業の均一化、工数の削減が実現。「開発組織にGitOpsの文化を根付かせるきっかけとなりました」（西銘氏）
現在はCI/CDをはじめ、自動化できるモノはみんなで自動化する文化ができているという。
このようにリリースフローの整備というDevOpsに近い仕事に携わったことで、SREチームから「DevOpsの経験があり、アプリも触れるので、SREチームでプッシュ通知基盤の改善に携わってみてはどうか」という仕事の誘いが来たのである。この誘いを受け、現在西銘氏はSREチームで、負荷によるリスク低減や大きくなった開発組織が動きやすいよう、サービスの疎結合化を意識してプッシュ通知基盤の改善や既存サービスの負荷調査に取り組んでいるという。
最初はレガシーコードの改善に愚直に取り組み、プロダクトの深い知見を蓄積。それが次のDX改善という新しい仕事につながり、DX改善では、CI/CDツールの活用により、開発作業におけるビルド集約やリリースの自動化というスキルを習得した。これまでの経験から誘われたプッシュ通知基盤の改善では、DockerやAmazon ECSを用いたコンテナ設計のスキル、さらにはTerraformを使ったIaC（Infrastructure as Code）によるインフラ構築のスキルを身につけることができたという。
SREチームのメンバーとして日々の業務に取り組むことで、システム監視についての知見を深め、Datadogによるダッシュボードの作成やアラート設定ができるようになったり、データ分析ツールや負荷テストツールを使った負荷調査なども一人で実施できるようになったりしたという。「このように技術的負債に向き合ったことで、仕事の幅が広がり、その副産物としてスキルの幅も広がりました」（西銘氏）
技術的負債を返済すると、プロダクトの次の理想像が見えてくる。「その理想像への障壁はまた新たな負債である。そうして新たに見えてきた負債もまた返済していく。この流れを繰り返していくことでプロダクトは成長する。プロダクトが成長すると、ユーザーにより安定したプロダクトを届けるために自分が挑戦できる機会と手段が増えていく。こうして得た機会と手段に挑戦し続ける姿勢（技術的負債に向き合い続ける姿勢）が、結果的にスキルの幅の広がりにもつながったのだと西銘氏はいう。
それでもつらい負債返済に押しつぶされないために
もちろん、技術的負債に向き合うことは「めちゃくちゃ大変だった」と西銘氏が言うように、簡単なことではない。たくさんの機能のコードが混在した神クラスの解体という対応を例に当時の苦労を語る。ファイル内検索で同じ名前の関数や変数が大量にあるなど可読性が低く、影響範囲が非常に大きいその神クラスに、当時の開発メンバーは皆んな頭を悩ませていた。そんな状況を突破したいという一念で、複数の担当チームと古株メンバーに対して慎重に影響調査を実施。影響範囲を抑えるために20回以上に分けてリリース作業を行ったという。このような苦労はあったものの、3カ月かけて神クラスを解体。この負債を返済したことで、神クラスについて頭を悩ますことが無くなった開発部のメンバーから感謝され、非常に盛り上がったという。一つの課題にずっと囚われていた組織、プロダクトが、その課題について語らなくなった現状を見て組織とプロダクトの確かな進歩を感じ、苦労に見合った結果がついてきたという。
一方で反省点もある。「一人でやっていてつらくなった時があった」と西銘氏は振り返る。ユーザーの価値に直接つながらないため、何のためにやっているのか目的を見失いやすいからだ。その結果、トラブルが起きた時にモチベーションを保つのが難しかったという。そこで得た学びは、「周りを巻き込んでいくこと」と西銘氏は言う。チームで対応すると自分にはないスキルや知見を持った人と働けるため、互いにスキル、知見を深めやすい状況が生まれる。スキルや知見が増えると、プロダクトや組織に還元できることも増える。「もし周りの理解が得られなければ、課題の数値化、言語化から始めてみると良いのでは」とアドバイスする。
「プロダクトや組織も大事ですが、プロダクトや組織のためにも負債返済で自分がつらくならないようにしましょう」（西銘氏）
コドモンでは一緒に働く仲間を積極的に募集しています。本記事でご興味を持たれた方は、リクルートページをご覧ください。
