AI時代のナレッジ設計 コード以上に重要なコンテキストをどう残すか
後半のテーマは、開発現場におけるナレッジマネジメントのポイントと課題だ。廣井氏はまず、現在メルカリの開発現場で起きている3つの変化を紹介した。
（1）技術領域と職務領域の越境
従来のAndroidエンジニア、iOSエンジニアといった専門領域での縦割りから、プロダクトエンジニアとしてフルスタックに責任を持つ形へのシフトが進んでいる。加えて、エンジニアがプロダクトマネージャーと共に機能要件の検討に関わるなど、職能の壁を超えた協業も広がっている。
（2）HITL（Human in the Loop）からHOTL（Human on the Loop）への移行
HITLのアプローチでは生産性向上が限定的にとどまるとされている。そのため同社では、プロセスの中に人間がいないと回らない状態を解消し、人間がいなくても回る自動化されたループを社内のさまざまな業務に広げることを目指しているという。
（3）「Build First, Discuss Early」のアプローチ
以前は仕様駆動開発を採用していたが、仕様を精緻に書く難しさや手戻りが課題だった。現在は、不完全でも先に動くものを作り、実物を見ながら認識のずれを早期に修正し、仕様を反復的に更新しているという。メルカリでは、AIによって作り直しのコストが下がり、従来は10人ほど必要だった開発を2〜3人で進められるようになったことで、 この進め方が可能になったという。
これらの変化を踏まえ、廣井氏は、開発におけるナレッジマネジメントを成功させる3つのポイントを提示した。ただし、これらはいずれも完成された取り組みではなく、同社にとっても今後の大きな課題だと、廣井氏は付け加えた。
（1）Intent（意図）を残す
コードから挙動は読み取れても、「なぜその実装になっているのか」という判断の背景は、意識的に言語化しなければ失われてしまう。将来の開発者やAIがコンテキストを理解するためには、例えば「障害中のサービスへの呼び出しを止める処理は、リソースの浪費や障害の連鎖を防ぐためだ」という意図を記録しておく必要がある。
（2）不要な情報を掃除する
開発速度が上がればリリース数が増え、それに伴って廃止される機能や不要なドキュメントも増える。古い情報が残れば、AIへ与えるコンテキストを汚染し、回答の信頼性を損ねてしまう。そこで、記録量を増やすだけでなく、不要になった情報を継続的に整理・削除する自動化の仕組みが必要になる。例えば、フィーチャーフラグで機能をオフにしたら、対応するドキュメントが自動的に無効化されるといった仕組みだ。
（3）AIへのコンテキスト提供の設計
スキルをはじめとする各種コンテキストを、エージェント間、メンバー間、チーム間でどのように共有するかも、大きな課題だ。 その際、情報圧縮や、推論過程での中間情報の欠落、人間とAIで読みやすさの基準が異なる点など、AI特有の癖を理解することも欠かせない。さらに、モデルの進化に伴い、AIの特性は絶えず変わるので、変化に継続的にキャッチアップする必要もある。
一方、AI以前から変わらず重要なのが、Single Source of Truth、すなわち「信頼できる唯一の情報源」の確立だ。しかし現状では、ナレッジの運用ルールはドメインごとに異なっている。例えば金融領域とマーケットプレイス領域とでは求められる厳格さが異なるため、一律のルールを敷くことが難しい。さらにJiraなどの開発タスク管理ツール内にも仕様に近い情報が残るなど、情報の散在も課題だという。情報の権威性や、正式情報へ昇格させるプロセスについても、活発な議論が交わされている最中だ。
最後に斉藤氏は、参加者が明日から実践できることを廣井氏に尋ねた。廣井氏は、次のアドバイスで講演を締めくくった。
「Intentは、開発の現場における重要なキーワードになっている。なぜその判断をしたのかを残すことが、これまで以上に重要だ。皆さんもぜひ明日からNotionを試してみてほしい」（廣井氏）
Notion Labs Japanからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひお問い合わせください。
