コドモン開発チームがリプレイスを進める背景
コドモンの開発ブログを移転しました。最新の記事はこちらからご覧ください。
こんにちは！コドモンプロダクトチームの市川です。
このnoteでは、コドモン開発チームのリプレイスレポートとして、コドモン開発チームでのリプレイスの様子も記録していきます。今日は、「なぜリプレイスを進めるのか」「どのようにしてリプレイスを進めることになったのか」という背景についてまとめます📝
昨年度までのコドモン開発チーム
コドモンの開発チームは、昨年度まで「ユーザーに機能を届けること」を最優先にしてきました。ユーザーがコドモンを使って少しでも楽になれるよう、とにかくリソースを機能開発作業に全振りし、脇目も振らずに走ってきたわけです。
その甲斐もあってか、コドモンはこども施設向けICTシステムにおいてシェアNo.1（2020年1月株式会社東京商工リサーチ調べ）となっており、たくさんのユーザーに使っていただけています。（万物に感謝🙏）
一方、ひたすら機能開発に邁進してきたため、チーム内の整備はあまり進んでいませんでした。ルールやガイドラインなどが存在せずコーディングのスタイルはそれぞれのエンジニアの倫理観に委ねられており、コードの品質を担保する仕組みも存在しませんでした。
ビジネスが好調だからこそチームメンバーもどんどん増えましたが、ルールやガイドラインのない状況においては、メンバーの増加は”コードが無秩序になっていくリスク”と比例します。そのような状況を踏まえ、今年度に入ってから「腰を据えてコドモンのエンジニアリングを最適化していこう」という方針に転換し、コドモンをエンジニアとプロダクトがともに楽しく成長できる場所にすることをミッションにしたチーム（アーキテクトチーム）が爆誕しました。
ボトルネックを洗い出す
チームを”エンジニアとプロダクトがともに楽しく成長できる場所”にするためにまずやるべきことは、「気持ちよく開発・保守することの妨げになっているもの」を洗い出すことです。アーキテクトチームでは、以下のようなアンケートを実施しました。
その結果、コドモン開発チームの文化やプロセスについて「これは良いところなので続けたい」という声もたくさんあった反面、「もっとこうしていきたい」という声もたくさん集まりました。
赤裸々に書きますが、この回答で挙げられた改善フィードバックの数はなんと134個にものぼりました。プロダクト機能における課題は別で管理しているため含まれず、あくまでコドモン開発チームのプロセスや体制についての改善フィードバックの数です。アンケート時点で開発メンバーは19人だったので、平均7個/人が改善フィードバックとして回答されたことになります。
たくさんの建設的意見を前に、数に圧倒されつつも「皆さん組織やプロダクトをよりよくしていくために真摯に考えているな」と心強く感じ、組織としての改善サイクルを整えていくぞと気合いを入れるタイミングとなりました。
優先度を決める
改善フィードバックを一つずつ噛み締めた後、同じようなものはまとめ、優先度を決めていきます。
まずは大カテゴリとして「開発」「組織」に大きく分け、さらにそれぞれ以下のようにカテゴリを分けました。
開発
アーキテクチャ／標準化／テスト／リリース／案件ライフサイクル
組織
環境／自己研鑽／コミュニケーション／体制／採用／オンボーディング／評価／指標管理
優先度については、課題群自体も、課題群の優先順位も、状況に応じて変わっていくという前提のもと、全課題の優先順位を決めることはせず、「ROIが高そうな課題」もしくは「早く手を打たないとネガティブな影響が複利的に増えていくような課題」を最優先として選択していきました。
数時間にわたるMTGの末、アーキテクトチームとしては、チーム内で役割を「テックリード」と「エンジニアリングマネジメント」の二つに分け、前者がプロダクトのリプレイスを、後者が標準化と採用に注力することになりました。（QAチームやインフラチームも、この改善フィードバック群から対応すべき課題をピックアップしていきましたが、それはまた別のお話…）
そのようにして、私たちはリプレイスを始めました
ある開発チームがリプレイスを選択する際の背景としてはよくある話かもしれませんが、コドモン開発チームのひとつの歴史としてはなかなか重要な分岐点でした。
冒頭にも書いたように、これからコドモン開発チームのリプレイスレポートとして、リプレイスのプロセスや各ステップについても記録を残していく予定なので、また読んでもらえると嬉しいです。