こんにちは。プロダクト開発部・請求関連チームの友野です。2025年3月に入社しました。
入社してから間が空いてしまいましたが、本記事はいわゆる入社エントリーというやつで、コドモンとの出会いや入社前に考えていたこと、今のチームのことなどお伝えしていきます。この記事を通してコドモンという会社や取り組みを知って、興味を持ってくれたら嬉しいです。
中堅SIer、シリーズAスタートアップ、そして現在
簡単に経歴を交えながら自己紹介します。
2011年に新卒で金融系SIerに入社し、以来ソフトウェアエンジニアとしてのキャリアを歩んできました。主に、受託開発のプロジェクトでアーキテクチャ設計やアプリケーション基盤の設計・実装に携わってきました。寄付金管理や支払承認管理、ガス料金シミュレーションなど金融系とその周辺領域を中心に複数案件を担当し、気が付けば9年ほどの時間が経っていました。
年を追うごとに、受託開発ではなく、エンジニアリングで事業に直接的にコミットしたいという考えが強くなり、契約管理SaaSを提供する、当時創業3年目のスタートアップに転職しました。トレードオフ・スライダーをスピードに全振りした組織とプロダクトが織り成すカオスな環境に揉まれる中で、将来を見越して変更に強いプロダクトに進化させるべく、MVCアーキテクチャから「オニオンアーキテクチャ + ドメイン駆動設計」へシステムを止めずに刷新するという、難しくもあり、楽しくもある刺激的な日々を過ごしていました。
実は、この経験から来る考えが、コドモンでのチャレンジを決めたひとつのきっかけでもあります。
というのも、いつからか自分自身のミッションとして「エンジニアリングで事業を加速、進化させる」ということを掲げており、
- モデリングによって問題を特定／認識する
- アーキテクチャ設計によって課題解決と生産性の維持、向上を図る
ことで、市場や要求の変化への対応を通じて事業成長への貢献に挑戦していきたい という思いが根底に芽生え、次に転職するならこの思いを全うしたいと心に決めていました。
この思いが、コドモンの現状や解決したい課題とマッチしていたわけです。
コドモンとの出会いと入社の決意
元々、私はコドモンユーザーでした。長女が3歳で転園した先の認可保育園でコドモンが導入されていたのが初めての出会いです。
それまでは、複写式の連絡帳で後日控えをもらい、欠席連絡は電話、支払いは現金という環境だったこともあり、ユーザー体験の良さに感動したのを今でも覚えています。
当時は一人のユーザーとして、その素晴らしいプロダクトをただただ応援していました。
同時に、育児を通じて、自分の残りの人生で子の世代に何が残せるだろうかとぼんやり考え始めていました。
コドモンは「子どもを取り巻く環境をテクノロジーの力でよりよいものに」というミッションを掲げています。
さらにミッションのその先に「子どもの育ちや学びを社会全体で支えられる世の中へ」というビジョンを見据えています。
学びを循環させ社会を形づくる活動は、人間の本質的な営みの一つと考えている自分にとって、このミッション／ビジョンは共感するばかりです。
その後ちょっとした縁があり、ミートアップ*1で、コドモンが抱える技術的な課題やリアーキテクチャへのチャレンジなど赤裸々に話を聞きました。
コドモンはローンチから約10年を迎えるプロダクトでして、少なからず、技術的な課題や負債が蓄積しつつあります。
まだまだ伸び代がある事業領域のプロダクトを、アーキテクチャレベルから見直してミッション実現に一歩でも近づけたいという気持ちが、話を聞く中で徐々に、しかし確実に高まっていくのを感じました。 自分自身の次のキャリアパス、経験とスキルを活かせる（であろう）フィールド、なにより次の世代をより良くする挑戦があるーー。入社する決意が固まった瞬間でした。
チームで挑む
登降園から請求という幅広い課題領域
現在、請求関連チームという、園児の登降園管理と保育施設（以降、施設とします）の請求業務を主に担当するチームに所属しています。登降園管理と請求業務、一見するとあまり関係がなさそうな2つの領域を1チームで？と思うかもしれませんが、実は密接に関連しています。
例えば、毎日の送り迎えの記録から、施設の利用時間を算出して保育料として請求する基本的な流れに加えて、一時利用や延長保育があれば月次の請求に漏れなく反映させる必要があります。つまり、登降園時の打刻がインプットとなり、毎月の請求業務につながるという関係です。
さらに請求業務には保育料請求だけでなく、一定条件を満たした施設から各自治体に補助金を申請する業務も含まれます。登降園管理も請求業務も、保育活動に直接的な影響を与えずとも、施設運営には必須の機能群といっても過言ではありません。
この2つの領域は、システム観点から見ても興味深いものがあります。登降園打刻は日本全国で広くご利用いただいており、朝夕の時間帯にピークタイムを迎えるtoCサービスのような特性がある一方で、請求業務は期日に振替処理を確実に行うというtoBサービスのような特性があります。異なる特性それぞれに注意を払う難しさと同時に、乗り越える楽しさを最近は感じています。
この先に保護者をはじめとした利用者の安心と、施設職員の事務作業省力化と本質的な保育活動のための余白づくりがあるのだなと想像すると、やりがいも増すばかりです。まさに「子どもを取り巻く環境をテクノロジーの力でよりよいものに」、です。
めちゃくちゃペアプロしてます
チーム活動の一部も紹介します。
コドモンでは開発プロセスにXP（エクストリームプログラミング）を採用しており、日常的にペアプログラミングをしています。
資産の共同所有、関係性構築、知識共有による学習促進などを狙いとして、プロダクトコードの開発はそのほとんどをペアで行います。言い換えると、組織でプロダクトを作り、組織そのものも強くする、といった感じです。持続可能性を高める重要なアプローチのひとつだと思います。
これまでの経歴では、初期の設計方針すり合わせだったり、何か問題が発生したときなどの必要なシーンのみペアプロ／モブプロをしていたので、業務時間の多くをペアプロするのは正直不安要素が大きかったのですが、結論、自然にペアプロ／ペアワークが始まる文化に多く救われています。
特に、幅広い課題領域を理解する上で、有識者とモデリング、設計、実装ができるのは中途入社者からすれば最高のオンボーディング支援です。そしてこれが当たり前の文化なので、押し付けがましくもありません。
「ペアプロは疲れる」これは事実ですが、適宜休憩を取ること、残業はほぼしないことでメリハリをつけてスピード感と持続可能性を獲得しています。
これから挑戦したいこと
大きく分けて2つあります。
リアーキテクティングの加速
コドモンは部分的にマイクロサービス化が進んでいるものの、メインプロダクトは依然としてモノリスな構成です。長い年月を経て積み上げられてきた既存機能群が今の顧客利用価値を作り出しているのをリスペクトする一方で、現構造のままではこれからの保育にまつわる環境変化への追従が難しくなる可能性があります。
プロダクトコードを紐解き、アーキテクチャの見直しを通じて保守性／変更容易性を獲得することで、こども家庭庁・各自治体の施策への対応やユーザーフィードバックの取り込みを加速させます。クリーンアーキテクチャを採用すれば良い、という話ではなく、コンテキストそれぞれの品質特性と制約の両面から取り得るアプローチを模索していきます。
また、フレームワークレベルで独自実装が多く残っているため、デファクトスタンダードなフレームワークやデザインパターンを適用することで、副次的にAIに適合しやすいプロダクト状態への進化も目標のひとつです。
暗黙的なドメイン知識の自己ドキュメント化
ペアプログラミングを推奨する文化は、SECIモデルにおける共同化と表出化*2を加速させます。この文化は非常に強力である一方で、当事者間の共有に留まるケースもままあります。もちろん、定期的なペアのローテーションや全社で利用しているナレッジ共有ツール上にドキュメントを残す動きもあるので、無策ではありません。
次のステップは、ドメイン知識をプロダクトコード上に直接反映して、結合化／内面化*3を促すことだと考えています。具体的には、プロダクトのコード自体で知識を表現する、すなわち、型の活用です。
知識を型で表現することで設計思想や制約をコードレベルに適用し、暗黙知をプロダクト全体で形式知へと昇華させる狙いです。
これにより、新たなメンバーのオンボーディングのみならず、ナレッジの活用と獲得のサイクルを構築し、開発効率と品質を一層向上させていきます。
さいごに
先日、ありがたいことに、コドモン導入施設数が22,000施設を超えました。
その一方で、ミッション実現のためには、やるべきことやりたいこと、伸び代もたくさんあります。
施設運営の基盤を整備して、次の世代の子育て環境をより良くしていく仲間を切に求めています。
少しでも興味を持っていただけた方は、ぜひカジュアル面談でお話しましょう！
