キャディにおけるAIプロダクトの技術的負債解消
最初のゲストスピーカーは、キャディ株式会社 Tech Leadの河合氏。セッションタイトルは「製造業×AI領域における技術的負債解消の取り組み」。
キャディはモノづくり産業を変えるベンチャー企業。受発注事業や図面データ活用SaaS「CADDi DRAWER」の開発、運営を行っている。創業5年目で社員は400人。そのうち約70人がエンジニアである。昨年12月、河合氏は同社に入社と同時にAI Labを立ち上げ、モノづくり業界の新しいプロダクト作りを、Tech Leadとして携わっている。
河合氏が最初に紹介したのは「AI系プロダクトの技術的負債あるある」というトピックだ。技術的負債ができてしまう理由の第一として河合氏は「AIは時間的経過に弱い」と言う。例えば時間の経過と共にデータの分布やユーザーの傾向が変わり、作成したモデルが適用できなくなることがあるからだ。またモデル推論、学習に関連するテストコードが書きにくいことを理由に、前処理やAPI実装に書かれないテストがある、PDCAを回さないプロダクトマネジメントから来る長期間のメンテナンス放置なども、技術的負債の要因となる。
実際、AI Labでも技術的負債が起きているが、河合氏は「私たちは技術的負債を、『負債』と捉えているので、金銭感覚があれば借りても良いし、返却もできる。大きなポイントは未来に向けた負債対策、返却の体制作りを継続すること」と語る。
キャディで行っている対策の第一は、チームを小さく保ち、チーム内PdMを立てること。プロジェクトが大きくなれば、複雑性が増し負債が発生する可能性が高まるからだ。そしてチーム内の「負債を許容するか」「返却するか」については、Tech PdMやTech Leadが判断することにしている。
対策の第二は、Design Docを書くこと。ゴールやノンゴール、ユーザーストーリーズ、サクセスメトリクスなどの項目を記してから開発を始めるという。また作成時点で負債化を防止するためレビューを実施することで、プロジェクトが進んでも方向がぶれにくくなる。
対策の第三は、ワーキングアグリーメントを作成すること。これはローカル実験から本番まで成果となるラインをアグリーメントとして共有するためだ。このような開発体制を作ることも、「技術的負債を生まないようにするためには重要だ」と語り、河合氏はセッションを締めた。
急拡大しても成長速度を失わないatama plusの技術的負債の解消法
続いて登壇したのは、atama plus株式会社 Dev Unit Successの深澤氏。セッションタイトルは「急拡大しても成長速度を失わずにいるための組織と技術の変化」。
深澤氏はヤフーでエンジニアリングマネージャーやソフトウェアエンジニアを経験した後、2019年10月にatama plusに入社。現在、Dev Unit Successとして活躍している。ちなみにDev Unit Successとは、同社オリジナルの役職。組織の拡大や成長支援、開発における構造上の課題解決、内部品質・外部品質の向上などの業務に取り組んでいる。
atama plusでは、学習を一人ひとり最適化し、「基礎学力」を最短で身につけ、その分、増える時間で「社会でいきる力」を伸ばす。そんな新しい学びを数億人の生徒に届け、社会の真ん中から変えていくことにチャレンジしているスタートアップだ。それを具現化したのが「atama＋」。一人ひとりの得意苦手を分析し、学習をパーソナライズするAI教材だ。2022年8月現在、全国の塾・予備校3200教室以上で活用されている。
技術的負債にどうやって向き合うのか。その前に深澤氏が紹介したのが、開発組織の様子である。atama＋をリリースしたのは創業直後の2017年。同プロダクトはさまざまな進化をとげ、2022年の小学生向け英語プロダクトのリリースによって、現在では小中高生に11教科を提供するに至っている。プロダクトの進化とともに組織も変遷。2018年にはインフラチームが設立され、2020年にはatama＋開発におけるLeSS体制がスタート。またアーキテクチャチーム、翌2021年には開発基盤チームを設立している。
「技術的な転換点もいろいろあった」と深澤氏。システムスケーリングへの長期的な投資、管理者向けサイトのReact化、情報セキュリティやWebサイトパフォーマンスのリスクに向き合ったことなどはその一例だ。
atama plusでは、どういったことが技術的課題だったのか。第一に技術的リスクに対する共通認識を作ること。「古びた技術を利用し続けることに対する非効率や情報セキュリティにまつわるリスク、Webサイトシステムパフォーマンスの劣化など、漠然と課題意識は持っていたが、優先順位付けするための共通認識たる水準がなく、対応するための合理性の判断が難しかった」と深澤氏。そこで水準定義を固めながら、さまざまな開発内容との優先順位付けをできるようにしたという。
第二に、プロダクト利用者拡大に伴って超えるべき壁が存在したこと。ユーザー数が数倍～10倍になっても耐えられる、急激な成長への追従が大事だったという。
第三は、これまでのコードベースを生かした良い開発をすることである。しかし、一人ひとりのエンジニアが幅広い範囲にわたって実装を進める方針であったこと、仕様検討背景のドキュメント不足、元来の設計思想を組織に通わせる動きが不足していたことが重なり、現在、これらの課題に取り組み中だという。
「今は漠然としていた技術的課題に対する共通認識形成を明示しはじめたというステータス」と深澤氏は言う。これからリスクの定量化手法、解消方法を確立するとともに、開発体制のスケーリングなどを強く意識し、マイクロサービスなどの新しいテクニックを駆使することで、「よりよい意思決定をして、開発を次に進められる仕組み作りを整えていきたい」と語り、セッションを締めた。
