キャディにおける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倍になっても耐えられる、急激な成長への追従が大事だったという。
第三は、これまでのコードベースを生かした良い開発をすることである。しかし、一人ひとりのエンジニアが幅広い範囲にわたって実装を進める方針であったこと、仕様検討背景のドキュメント不足、元来の設計思想を組織に通わせる動きが不足していたことが重なり、現在、これらの課題に取り組み中だという。
「今は漠然としていた技術的課題に対する共通認識形成を明示しはじめたというステータス」と深澤氏は言う。これからリスクの定量化手法、解消方法を確立するとともに、開発体制のスケーリングなどを強く意識し、マイクロサービスなどの新しいテクニックを駆使することで、「よりよい意思決定をして、開発を次に進められる仕組み作りを整えていきたい」と語り、セッションを締めた。
プロジェクト化して技術的負債の返済を進めるカミナシ
最後に登壇したのは、株式会社カミナシ 執行役員CTOの原氏。セッションタイトルは「激撮！カミナシ技術的負債返済プロジェクト！～目撃者は語る～」。「ウケ狙いのタイトルをつけましたが、内容は真面目なものになりました」と語り、原氏のセッションは始まった。
カミナシの企業ミッションは「ノンデスクワーカーの才能を解き放つ」。日本の労働人口の半分以上はノンデスクワーカーが占めている。そのノンデスクワーカーの作業を効率にするためのサービスを2年前より提供している。社員は全員で60人ほど。そのうちエンジニアは10人を超える。そんなカミナシに原氏は2022年4月に入社。前職はAWSでコンテナサービスのチームに所属していた。
技術的負債について原氏は「実装当時に最適解と考えられたものが、時間の経過と共に最適とは評価され得なくなったものと捉えている」と説明する。ビジネスを取り巻く状況や、システムに関わる組織・チームの規模や役割、新たな技術的な選択肢が登場するなど、時間の経過と共に最適は変化していく。「この変化の結果と最適の差分が技術的負債になる」と原氏は言う。つまり、継続的改善を前提でシステムを作る限り、優秀な人材を集めても必ず技術的負債は発生するのだ。
また原氏は「技術的負債を生み出しているのはエンジニアリングだけではない」と語る。ビジネスモデルそのもの、プロダクトのバリュープロポジション、一つひとつの機能要件、仕様など、いたるところに不確実性が潜んでいるからだ。つまり技術的負債は手抜きの結果ではない。
技術的負債を返済するのは、最適を再評価しないシステムは継続的開発における生産性を低下させることになるからだ、また高い生産性を維持し続けるためにも技術的負債を返済する必要はある。技術的負債は本来、通常の開発プロセスの中で継続的に返済し続けなければならないものなので、「プロジェクト化が必要になるまで放置すること自体は誤り」と原氏は言う。
原氏が入社した4月下旬からプロジェクト化の検討を開始。全社説明をして、5月末より5週間、機能開発を止めてビジネスロジックを触らないリファクタリングを一気に行い、7月より第二弾が進行している。
検討時点で行ったのは、技術的負債と認識していることをアクションに繋げられる粒度でリスト化し、各アイテムを放置した際の技術・ビジネス両面での想定リスクや返済で期待される効果について言語化した。そして各アイテムのリスクや心のつらさ、対応コストなどを複合的な要素を基にざっくりと優先順位を決めていった。4月末からリストを基に本格的に技術的負債の返済プランを検討開始。「通常業務と並行して片付けられるのかを検討したが、難しいことがわかりプロジェクト化することにした」と原氏は言う。
経営メンバーには「過去数カ月間で純粋な機能開発に使った時間」というファクトに基づいて説明。エンジニアリングの多くの時間が顧客問い合わせに基づく調査や不具合修正などの対応に使われており、大きな新機能が出せていなかった。だが、意思決定できたのは「ビジネスそのものが伸びていたことも大きい」と言う。6月末までの5週間、機能開発と不具合修正をすべて止めて、負債返済プロジェクトにリソースを充てることで経営内で合意したという。
負債返済プロジェクト第1弾では、アプリケーションコードの必要以上の複雑さを取り除くためリファクタリングを実施。エンジニアリングメンバーの精神衛生が良くなり、「ビジネスロジックにも手を入れていこうという機運も生まれた」と言う。現在、進めている第2弾では機能開発と並行して負債返済を実施している。「通常業務と負債返済の時間の比率は5:5のルールを定めている」と原氏。優先度の高い重要な技術的負債群が片付き次第、通常業務の時間を増やしていくルールにしている。年末までに「中長期的な価値を犠牲にせずに、業務の6割の時間を純粋な機能開発に充てられるチームへ」を目指して鋭意、取り組んでいるという。
「技術的負債も機能開発などと同じリストのバックログアイテムとして管理し、着手の優先順位をつける。そして技術的負債の詳細と対応案をバックログアイテムに落とし込み、放置による影響や、対応で期待される効果、そして可能な限りその測定方法を言語化し切ることが、エンジニアリングの責任です。皆さんも技術的負債に悩んでるかと思いますが頑張って取り組んでいきましょう」（原氏）
参加者からの質問にも直接回答！ 盛り上がったパネルディスカッション
3人のセッションが終わり、パネルディスカッションが始まった。モデレーターはゆめみ／SELECKの取締役の工藤氏。同氏は2011年にゆめみに入社。OMO／デジタル新規事業などのプロジェクト推進・ディレクターを経験後、デジタルサービスの立ち上げや運営の支援に従事。2019年にはマーケティング担当として取締役に就任。2022年にはSELECKの取締役にも就任した。ここからは、パネルディスカッションの様子をレポートする。
――最初のお題は「負債、もしくは将来的に負債になり得るリスクに対して、共通認識を取るためのコミュニケーション・指標はありますか」。深澤さんはこの課題に対してどのように解決しようとしていますか。
深澤：当社はビジネスと開発の距離が非常に近い文化が形成されているので、一体となって価値を提供していこうということが根付いています。その上で、お互い歩み寄りをしています。例えば、技術的バックグランドではない人たちが「Reactについて勉強したいがいい本がないか」「どんな可能性があるのか」などを聞いてくれるため、発展的な会話に繋がりやすいです。また同じミッションに向かって、時には技術的課題、時には新規開発に取り組むことについて密なコミュニケーションを取るようにしていますね。
また指標については、定性的・定量的の両面から検討したリストを整備しています。例えばメンテナンスコストの高さを大中小で分類し、この機能はメンテナンスコストが高いつけど、価値提供につながっているのでリファクタリングで改善しよう、という風に整備しています。
技術的負債に取り組むか否かの判断基準とは
――河合さんは「負債を許容するか返却するかはPdMもしくはTech Leadの判断」と言っていましたが、深澤さん自身はどのような判断基準を持っていますか。
深澤：事業会社にいるので、負債の返却は儲かるかどうかが判断の全てだと思います。負債を返却して技術的に素晴らしい環境になったとしても、そのサービスが儲からなければ意味がありません。最終的にはこの機能が直ると開発スピードがどのくらい上がり、それによって新機能が開発でき、いくら儲かるというところまで算出するのが、技術的負債に対する責任だと思います。
河合：組織面では私も納得です。持ちつ持たれつだと思うので、組織の軸と個人の軸の2つを持つ必要があると思います。
――原さんでは「ビジネスが伸びているから負債返済のプロジェクト化を意思決定しやすかった」という話がありましたが、そこまでうまくいっていない場合、どうしていたでしょうか。
原：事業がうまくいっていない場合には、負債返済というよりは使われていない機能を捨てるなど、スリムアップをすることの方が必要かもしれないですね。
――プロダクトがうまくいっていない場合に、手を入れる必要があるが、ビジネスとして続いてしまっているので難しいというようなこともあると思います。その場合、どのように判断すれば良いでしょうか。
深澤：個人的な考えですが、新しい機能をつくる時に、不必要なオーバーヘッドを技術的負債で返済しても良いと思っています。このスコープの中で何が最適か、どのスコープでどんな成果を上げたいかを定義した上で、今障害になっているものを優先度を上げて対応していくことが大事なのではないでしょうか。
――プロダクトの機能が変わったときは、負債として捉えるということですね。将来性やスピード感によっても、負債のパラメータは変わると思うのですが、いかがでしょう。
河合：非常に面白い質問ですね。大人な回答ではないところで言うと、ミニマムなモックを作ってPDCAを回していくのは当たり前ですが、ビジネス側とのコミュニケーションは難しいので、あえてコミュニケーションを取らずに、エンジニアの都合で技術的負債を解消するという手があります。2日ぐらい合宿を行って集中的に直す、一部をOSS化するなどの方法が考えられます。
原：自分自身も1人のエンジニアとしての視点でみたときには、技術的負債をプロジェクト化した先で解決したかったのは、エンジニアが開発が楽しいと思える環境と状況を取り戻すことでしたね。
河合：根源的なWillを忘れてはだめですよね。
技術的負債を取り組むエンジニアを適切に評価するには？
――河合さんに質問です。ワーキングアグリーメントをエンジニアチームに定着させるためのコツについて教えてください。
河合：ひたすら言うことでしか定着できないと思います。これは評価制度の問題もあります。ビジネスに貢献した方が評価されるので、負債を解消しようという方向にはなかなか向かわないからです。チームでは「これは絶対にやめよう」と言っていくことが大事ですね。
原：当社も評価制度を定義する必要があると思っています。ビジネス側からの成果が見えやすい新機能開発だけではなく、運用を支えているエンジニアや、サービスのライフサイクル全体に貢献しているエンジニアこそ、評価されてほしいと思っています。
――では、どのようにして負債の返済に取り組んでいるエンジニアを評価すればよいのでしょう。
深澤：デプロイの成功率、開発のリードタイムなど、KPIに類するものをエンジニアリングでも用意して、定量化すると良いのではないでしょうか。それらを計測した上で、改善につながる施策かどうか、課題の整理をする。開発のスピードが上がると、ビジネスを加速することにも間接的に寄与しますからね。
河合：評価やお金に関連しない気持ちの部分も大事にしたいと思います。AI LabではスモールWillシートを用意し、「この人のやったWillがすごく良かった」という声を可視化し、こんなに活躍しているんだということをビジネス側に伝えています。
――充実した議論になってきましたね。ここで新しい質問です。エンジニアメンバーの入れ替わりや新規加入によって発生する負債については、どのように取り組めばよいでしょうか。
河合：ワーキングアグリーメントを読み合わせし、ルールで縛ることでしょうか。
原：当社が機能開発を止めてリファクタリングに取り組んだのは、まさにこの状況があったからです。GoのAPIサーバがあったのですが、当時の意思決定の背景や経緯がドキュメントとして残されていなかったこともあり、1行を書き換えるために5～6個のファイルを書き換えないといけないという複雑な設計になってしまっている箇所がありました。このようなことを今後、起こさないためにはドキュメントとして残すことが必要だと思います。
ドキュメントを書くのが苦手というエンジニアは、その筋力をつけていくしかありません。ドキュメントを書くことを促すために、私は良いドキュメントを書いた人は、社内のオープンな場所で紹介するようにしています。
深澤：ドキュメントも大事ですが、変化の少ないところについては、コーディング規約を定めたり、自動検出するテストなど仕組みを作ったりすることも大事だと思います。変化の大きなところは自然言語で書いて、柔軟性を持たせる。当社ではそういう仕組み化に取り組んでいます。
大企業とスタートアップ、技術的負債への取り組み方への違いとは
――みなさん、前職では大企業で働いた経験をお持ちです。スタートアップと大企業では、プロダクトの運用、負債への考え方、取り組み方について何か違いはありますでしょうか。
河合：キャッシュフローが異なります。大企業では資金があるので、プロジェクト化して負債の返却ができます。スタートアップは資金調達や上場などを目指し、ユーザーにサービスを提供していかねばなりません。崖から落ちないように飛行機を作っていくような感じです。そこが大きな違いだと思います。
原：同感ですね。前職では「これをやると会社が潰れる」という心配はなかったです。カミナシでは、「技術負債返済のプロジェクト化の意思決定が、結果として会社を潰すことにつながってしまったらどうしよう」という不安は今でもあります。
深澤：体力の違いだけではなく、大企業では標準化も進んでいます。もちろん標準化が障壁になることもあるのですが、標準化があるから楽にできたということも多々あります。開発を行いながら、標準化も進めていくのは、悩みながらの作業となります。だからこそ、スタートアップは技術的負債が溜まりやすい。その分、エキサイティングな環境なんですよね。
――最後は良い締り方で終えることができました。皆さん、ありがとうございました！
左下：キャディ 河合俊典氏、右下：カミナシ 原トリ氏
