はじめに
こんにちは、最近オーディオミキサーを買い換えたら「リモートMTGの音質が良くなった」と褒められMTGしたがりなAI Labの河合です。
先日、YUMEMI様が主催するSELECK LIVE!にて、「スタートアップと技術的負債」というイベントに登壇させて頂きました。 登壇者は、株式会社カミナシCTOのトリさん（@toricls）、atama plus株式会社の深澤さん(@qluto)。 モデレータは、株式会社ゆめみ取締役の工藤元気さん（@Genki910biz）でした。 非常に豪華なメンバーでエンジニアリングにおける負債と事業についてディスカッションする事ができました。ありがたい限りです。
本記事は、イベントの中でCADDiから発表した内容を補足しつつ、パネルディスカッションを振り返る形で、イベントレポートとさせて頂ければと思います。
イベントURL： https://yumemi.connpass.com/event/255925/
河合セッション
他2人の登壇者のテーマと少し違いを出すため、私のセッションでは主に「機械学習」をテーマにした技術的負債のお話をしました。
AIプロジェクトでありがちな技術的負債
そもそも、AI、機械学習の分野には「機械学習は高利のクレジットカードである」という言説があります。
これは、2014年のNIPS(現在のNeuralIPS、機械学習業界における著名な学会)にてGoogleより発表された論文から来ています。 タイトルはそのまま『Machine Learning: The High-Interest Credit Card of Technical Debt(*1)』です。
2022年においても、機械学習や統計モデルの技術活用はさらに進む裏側で激しい技術的負債化と戦っているのがAI業界であるとも言えます。
私のセッションの入りとして、私がよくあると感じる機械学習の負債についていくつか例をお話しました。
- 時間が経つと再現不可能になるモデル、データ、バージョン管理
- モデル推論、学習に関連するテストコードが書きにくい事をいいことに前処理やAPI実装に書かれないテスト
- 複数の機能がwrapされた便利な機械学習ライブラリを使う事が多い反面、method単位のtestが書きにくくなっています
- そういった背景から、モデルの周辺コードのテストがサボられるケースがあります
- テストのないコードはそれだけで負債と言えます
- データドリフトが考慮されない、監視されないデータ分布
- 機械学習プロジェクトの最も難しい点の1つに、入力データの分布への対応があります
- 分かりやすくTo Cで言えば、数ヶ月前とユーザの購買行動が変わってしまうシーン等がそれに当たります
- これらに対応するには本来分布を監視すべきなのですが、一定以上のシステムが必要故劣後されがちです
- 最初は精度が良いモデルでも半年後に負債となって襲いかかってくる事がよくあります
- PDCAを回さないプロダクトマネジメントから来る長期間のメンテナンス放置
トリさん、深澤さんが、より広い技術的負債のお話をしてくれると考え、AI文脈に絞っています。そうあって欲しくないのですが、結構身近なあるあるの課題です。
*1 At: SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop)
D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips,
Dietmar Ebner, Vinay Chaudhary, Michael Young (Google, Inc)
https://research.google/pubs/pub43146/
CADDi AI Labにおける技術的負債
CADDi AI Labは、昨年12月に設立し9ヶ月のチームですが、素早い開発速度を求める反面でいくつかの負債も抱えています。
これらは、「プロダクトの変化」や「データ分布の変化」に機械学習のシステムが追従出来なかった結果として起こった後発的な負債と言えます。
イベント中、トリさんが良い事を仰っていたのですが、「プロダクトに導入された技術は時間と共に必ず負債化」します。 機械学習は効力も大きい分、その反動も多くなるので時間の経過を考慮した開発が必要になってくるなと私も痛感しています。
スライドにもある通り、技術的負債はまさに「負債」です。 ネガティブな印象はなく、金銭感覚があれば借りても良いし返却もできます。 本質的には、負債額の把握、返却への皮算用、未来に向けた負債対策、返却の体制作りなどの継続が大事になると認識しています。
CADDi AI Labにおける対策
CADDi AI Labでは、技術的な負債を借りるため、後々負債にならないよう、いくつかの施策を打っています。
- 小チーム制とチーム内PdM、Tech Lead
- PJが大きくなり人が増えれば複雑性が増し負債が発生する可能性は高まるのでチームは小さく保っています
- 小チーム内の事はメンバー同士の手が届く状態にしています
- チーム間での「負債を許容するか」「返却するか」はTech PdM / Tech Leadが判断しています
- 判断にはビジネス上の意義や他チームの状態など様々な要因が絡むためです
- ドキュメントの記載
- 機械学習エンジニアもDesign Docや実験ドキュメント、Model Cardを書いています
- Design Docには以下の内容を必ず記載しています
- Goals
- Non-goals
- User Stories
- Success Metrics
- Biggest Hypothesis
- Functional Requirements
- Results
- 実験ドキュメントはGitHub上で管理し、lexicoを使って社内から閲覧できる状態にしています
- lexicoは全社共通のドキュメントサーバとして利用しておりGoogleアカウントによる認証が付いています
- 基本的にフリーフォーマットですが実験を他者に引き継げる状態を期待しています
- Model Cardはproductionにdeployされるモデルについて以下のような内容を必ず記載しています
- これらはレビューにより負債化を防止したりもしています
- プロジェクトが進んでも方向がブレにくくなるだけでなく、チームとして技術的負債をそもそも生みにくくする体制、知識共有の役割を果たしています
- Working Agreement
- ローカル実験から本番まで「成果」となるラインをAgreementとして共有
- Test群においてもチーム内で定義
- 必須の項目は「時間を掛けてやる」ことを明言しています
イベント内では実際のWorking Agreementのスクリーンショット等も共有してます。
「バージョン管理の行われていない」「Productionに出るにも関わらずTestのない」状態は成果と呼ばない事を明言しています。 また、それらを守るために「改修を2回劣後させたら報告すること」をルールとし、時間を作る事もWorking Agreementの取り組みの一環として実施しています。
イベント中には言っていませんでしたが、今もまさにWorking Agreement追従のためにスプリントを丸々使って改修を行っているメンバーが居ます。
パネルディスカッション
イベント後半では、登壇者によるパネルディスカッションを実施しました。
ビジネス職であるCEO等に技術的負債の返却をどう説明するかという議論から始まり、事業貢献として金額に換算する話や良いエンジニアを採用し確保し続けるために必要であるという話をしました。 トリさんから「（立場上言いづらいと明言した上で）やっぱり汚い環境で仕事したくないじゃないですか」といった本音トークも出てきて、非常にエモーショナルな会になったなと思います。 私も基本的には「事業が成功するために技術的な負債を借りるべき」と考えていますが、それによって起こるやり辛い環境を解消したいというエンジニアの性のような部分も大事にすべきだといつも思っています。
また、「ドキュメント化は一種の筋力」という言葉も非常に刺さりました。 CADDiにおいてもまだまだ未熟ではありますが、未来の技術的負債を減らすためにベースを強くしていきたい所です。
既にある技術的負債の解消を進める取り組みとして、CADDi AI Labが実施しているSmall Winシートも共有しました。
技術的負債というものは、返しても目先は事業的には前に進んでいないため会社から評価されにくいものですが、技術者からは確実に大きく評価される事だと思いますし、その事を忘れずしっかり評価者に伝えるためにもお互い書くようにしています。
こういった仕事の評価をどう上げていくか、登壇者皆さん頭を回している事が良く分かり非常に良いディスカッションとなりました。
おわりに
本記事では、「スタートアップと技術的負債」というイベントのレポートとその補足を行いました。
ここまでお読みいただきありがとうございました。
CADDiでは、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひこちらより面談をお申し込みください。 また、Tech Blogや勉強会等のイベントについてはSNSで随時発信しておりますので、Twitterのフォローや、connpassのメンバー登録をぜひよろしくお願いします。
