勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

AI駆動開発時代に「要求開発」が再浮上する(かも)

最近考えていること。AI駆動開発時代に、「要求開発」を見直してもいいんじゃないかと考えたこと。

「要求」は引き出すものではなく、開発するもの

『情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである』。これは、かつて「要求開発」という上流工程の方法論が提唱した中心的なコンセプトである。

agnozingdays.hatenablog.com

従来の「要求分析」や「要求定義」という言葉は、あたかも要求がユーザーの中に最初から存在しており、それをヒアリングして文書化すればよいという錯覚を与えがちである。しかし実際には、作ってみないと分からない部分が多く、何度もトライ&エラーを繰り返すわけにもいかない。そこでシステムを作る前に、ビジネス価値を入力として「要求を創造・開発する」というプロセスが必要だ、というのが要求開発の根本的な考え方である。

要求開発では、ビジネスの全体像をモデリング(可視化)し、それを中核にステークホルダー間で要求に関する協議と合意形成を進める。このアプローチは非常に芯を食っていたが、その後に台頭したアジャイル開発やプロダクト開発の進展の陰に隠れ、大きなトレンドにはなりきらなかった。
しかし、AI駆動開発が現実のものとなった今、私は「改めて要求開発のアプローチが必要なのではないか」と強く感じている。

AI時代は「コンテキストの正確性」で勝負が決まる

AI駆動開発によって、設計や実装といったソフトウェア開発の中核プロセスは爆速で実行できる時代に入りつつある。それに伴い、「上流工程がより重要になる」という議論が様々な場所で交わされている。

しかし、肝心の上流工程について、従来型の要件定義のフォーマットを埋める作業として語られていることに違和感を覚える。AIを使えば立派な要件定義書を瞬時に作成できるが、「その要件は、本当に正しいのか?」という本質的な問いが残されたままなのだ。

企業情報システムにおいては、精度の高い要求を開発するために、要求開発のアプローチを再考すべき時期に来ている。そこには以下の3つの理由がある。

1. 要求はそもそも「最初から定義できるもの」ではない

現代のシステム開発では、「業務や既存システムを隅々まで理解している設計者がもういない」「業務全体が巨大化しすぎて、全体像を把握している人がいない」という事態が頻発している。要求は、多数の利害関係者の頭の中に、ぼんやりとした形でしか存在していない。存在しないものをAIが引き出すことは不可能である。

2. 「コタツモデル」による集合知の形成が必要である

無矛盾の要求を定義するためには、ビジネスオーナー、業務担当者、開発者が知識を持ち寄り、共に議論する必要がある。要求開発ではこれを「コタツモデル」と呼ぶ。各自の暗黙知をモデリングによって可視化し、構造化することで、初めて欠落を補完し、真の合意形成に至ることができる。

3. 「なぜ作るのか」というコンテキストの強度が結果を左右する

システム化の目的と手段の連鎖を明確にし、それが常に追跡可能(トレーサブル)であることが、今後の開発品質に直結する。AIに無数のトレードオフの中から最適な選択をさせるためには、単なる機能要件の羅列ではなく、「なぜこのシステムが必要なのか」という圧倒的なコンテキストの量と正確性が必要不可欠だからである。
AIがコードを生成するスピードが上がるほど、「何を、なぜ作るのか」を人間同士がモデリングを通じて合意する「要求開発」の領域が、プロジェクトの成否を分ける最大の要所となるはずである。

「要求開発」をモダナイズして再公開する

上記のようなことを思いながら、公開中止されてしまった「要求開発」の復刻について考えている。当時の資料はネット上では非公開になってしまっているが、CC-by-2.5であったし手元にはおおむね揃っている。生成AIなどを使って再整理、モダナイズして公開すれば、良い議論ができるんじゃないかと考えている今日この頃。