システム内製化の強み
システム開発では、最初に要件定義書を作り、次に設計書を作り、それをエンジニアがコードへ変換する方法が一般的です。
しかし、この方法では同じシステムを異なる形式で何度も表現することになります。
経営者や現場担当者の言葉
↓
要件定義書
↓
設計書
↓
プログラムコード
↓
非コーダー向けの操作説明書
工程が増えるたびに、翻訳作業と確認作業が発生します。
さらに、仕様を変更した場合には、要件定義書・設計書・コード・説明資料をそれぞれ修正しなければなりません。
この二重、三重の管理が、システム開発費用を押し上げる大きな原因になっています。
当社は、AI時代には要件定義そのものをコードで表現し、コードを唯一の原本として管理する方法が広がっていくと考えています。
「コードを原本にする」とはどういうことか
コードを原本にするとは、要件を整理せず、いきなりプログラムを書き始めることではありません。
会社の業務構造と判断ルールを、コード上で直接表現するという意味です。
- ディレクトリの配置で、会社・部署・業務の境界を表現する
- クラスで、人・物・取引・出来事を表現する
- プロパティで、記録すべき情報や状態を表現する
- メソッドで、実行可能な業務処理を表現する
- ドックストリングで、設計目的・判断理由・制約・例外を説明する
- テストコードで、具体的な処理例と期待結果を表現する
例えば、請求書を発行する条件が、
「検収が完了していること」
「金額が100万円以上の場合は代表者の承認を得ていること」
であれば、次のように表現できます。
from decimal import Decimal
class 請求:
"""
検収が完了した取引だけを請求対象とする。
金額が100万円以上の場合は、
代表者の承認を必要とする。
"""
検収済み: bool
金額: Decimal
代表者承認済み: bool
def 発行できる(self) -> bool:
if not self.検収済み:
return False
if self.金額 >= Decimal("1000000"):
return self.代表者承認済み
return True
このコードには、請求に必要な情報、判断条件、例外、処理結果が表現されています。
ドックストリングを読めば、人間もその設計意図を確認できます。AIに読ませれば、経営者や現場担当者向けの説明文へ変換することもできます。
さらにテストコードを用意すれば、
- 未検収なら発行できない
- 50万円なら代表者承認なしでも発行できる
- 120万円なら代表者承認が必要になる
という具体例まで、実行可能な要件として残せます。
要件定義書からコードへの翻訳が不要になる
従来の開発では、要件定義を行う人とコードを書く人が別になっていることがあります。
要件定義書を書いた人の意図をエンジニアが読み取り、コードへ翻訳します。認識に違いがあれば、質問、回答、文書修正、再確認が必要になります。
コード自体を要件定義の原本にすれば、この翻訳工程を大幅に減らせます。
業務上の概念をクラスとして配置し、必要な情報をプロパティとして定義し、許可された操作をメソッドとして記述します。判断理由や例外は、そのコードに最も近いドックストリングへ残します。
要件と実装が同じ場所に存在するため、「設計書には書いてあるがコードには反映されていない」という状態も起きにくくなります。
修正費用も圧縮できる
業務ルールは、システムを実際に使う中で少しずつ明らかになります。
現場から、
「この場合は承認者が違うのではないか」
「作業完了と請求可能は別の状態ではないか」
「この取引先だけ例外処理が必要ではないか」
という気づきが出ることがあります。
文書とコードを別々に管理している場合は、影響する要件定義書と設計書を探し、文書を修正し、合意を取り直し、その後でコードを変更します。
コードを原本にしていれば、該当するクラス、プロパティ、メソッド、ドックストリング、テストを確認し、同じ場所で設計と実装を修正できます。
もちろん、会計・請求・在庫・権限など、会社の資産を変化させる処理は、テストや承認を経てから本番環境へ反映しなければなりません。
しかし、仕様を修正するたびに複数の原本を更新する必要はなくなります。
非コーダーにコードを読ませる必要はない
コードを原本にすると聞くと、「経営者や現場担当者はコードを読めない」という疑問が出てきます。
しかし、非コーダーが原本を直接読む必要はありません。
AIを利用すれば、コードから次のような資料を作成できます。
- 経営者向けのシステム全体説明
- 現場担当者向けの業務手順
- 会計専門家向けの処理条件
- 部署間の業務フロー
- 権限と承認経路の一覧
- システム構成図
- 操作マニュアル
これらの資料は、それぞれが独立した原本ではありません。コードという一つの原本を、利用者に合わせて見やすく変換したものです。
コードを変更した場合は、変更後のコードから資料を作り直します。
これにより、古い設計書や操作マニュアルだけが残り、実際のシステムと内容が食い違う問題を減らせます。
AI時代には要件定義とプログラミングの境界が薄くなる
従来は、人間が要件定義書を書き、それを読んだエンジニアがプログラムを書く必要がありました。
生成AIは、人間が説明した業務ルールから、クラス、プロパティ、メソッド、ドックストリング、テストコードの案を作れます。
反対に、既存コードを読み取り、非コーダー向けの説明資料を作ることもできます。
つまり、AIが人間の言葉とコードの間を往復できるようになったことで、要件定義書を独立した原本として維持する必要性が小さくなります。
今後は、
人間が業務上の判断を行う
AIとともにコード上へ構造化する
動く状態で確認する
必要な資料をコードから生成する
という開発方法が日常化していくと当社は考えています。
有力候補となるプログラミング言語がPythonである
当社は、コードを要件定義の原本とする時代において、Pythonが有力候補になると考えています。
Pythonは、クラス、プロパティ、メソッドなどを比較的簡潔な構文で表現できます。
ドックストリングをコードの近くへ記述できるため、何を処理するのかだけでなく、「なぜその構造にしたのか」という設計意図も残せます。
Pythonを使う目的は、単に少ない文字数でプログラムを書くことではありません。
自社の業務を、人間とAIの双方が理解しやすい構造で表現することです。
会社、部署、業務、担当者、承認者、取引、会計上の出来事をコード上へ配置し、その関係を人間が確認できる状態にします。
圧縮されるのは、プログラミング費用だけではない
コードを原本にすることで圧縮できるのは、コードを書く費用だけではありません。
- 要件定義書を作成する費用
- 設計書へ変換する費用
- 要件定義書とコードを照合する費用
- 仕様変更時に複数の文書を修正する費用
- 非コーダー向け資料を一から作る費用
- 古い文書と現在のコードの違いを調査する費用
- 関係者間の認識違いを修正する費用
こうした翻訳・確認・二重管理にかかる費用を圧縮できます。
要件定義そのものをコードで表現するとは、要件定義を省略することではありません。
要件定義と設計と実装を、同じ原本の上で行うことです。
AI時代のシステム開発では、コードは完成品だけではありません。
会社の業務構造、判断基準、設計意図を保存する、最も正確な原本になっていくのです。