■ 1. 情促法改正とIPAの役割変化
- 内閣総理大臣が主務大臣に加わり、IPA（情報処理推進機構）が省庁横断的なIT政策推進機関へと変貌した
- 従来はIPAに他省庁所管業界へガイドライン順守を求める法的根拠がなかった
- この改正により、ITシステムの品質に関するガイドラインが業界横断で求められる時代が来る可能性がある
■ 2. モノリスシステムとMSAの比較
- モノリスシステムの問題点:
- 高コスト・長期間の開発を強いる
- 小規模な改修でも広範囲に影響が及ぶ
- ビジネス環境の変化にITシステムが追い付かない
- MSA（マイクロサービスアーキテクチャ）の優位性:
- 独立した小さなサービスを部品のように組み合わせて構成する
- 品質保証済みの「部品」を再利用することで開発コストと期間を大幅に圧縮できる
- 市場の変化への迅速な対応が可能となり、DX推進の土台が整う
■ 3. MSAにおける開発規模の概念変化
- 従来のモノリス開発ではステップ数やファンクションポイントが規模の指標であった
- MSA開発では、「部品」は開発対象でもテスト対象でもないため、規模の問い自体が意味をなさない
- MSAにおける開発規模の指標:
- 新たに追加する論理の「分岐数」が規模を測る指標となる
- 分岐数が多ければテストケース数も増えるため、テストケース数が見積もりの根拠となる
- 従来のステップ数・ファンクションポイントに基づく見積もり手法は通用しない
■ 4. MSAによる生産性・品質への効果
- 新規で開発する総量を従来手法の10分の1以下に抑えられ、生産性は10倍以上向上する
- テスト対象がシステム全体でなく限定されるため、テスト工数が削減される
- AIの活用:
- 追加開発分のソースコードを入力することで、全テストケースの洗い出しが可能
- テストデータはAPIの入出力のみであり、辞書を学習させることでAIによる自動作成ができる
- 設計情報をデータ化することで、テスト結果の期待値もAIで自動作成可能
- ホワイトボックステストが品質保証の中心となり、テストケース数は従来より極めて少ない
■ 5. 製造業の品質保証モデルとの比較
- 製造業における品質保証体制:
- 受入検査・工程内検査・最終検査という多段階の検査プロセスを経る
- ISO 9001などの品質マネジメントシステムに基づく体系的な管理体制が整備されている
- MSAにおける類似構造:
- 各「部品」はホワイトボックステストで品質保証される
- 部品を組み込んだ本体も同様にホワイトボックステストで品質保証される
- 上位のマイクロサービスに対しても品質保証済みのものが組み込まれる
- 機能間のブラックボックステストも実施可能
- ソフトウェアと製造業の根本的な違い:
- ソフトウェアは複製コストがほぼゼロであり、物理的な劣化も起きない
- 出荷後でも比較的容易に修正可能という特性がある
- この「後から直せる」特性が「バグがあって当たり前」という認識を生んだ側面がある
■ 6. MSAの落とし穴: 勘違い開発のリスク
- 製造業では1つの部品に仕様確認・設計・製造・検査と複数担当者が関与して相互チェックを行う
- MSAでは開発者1人が設計から開発まで一貫して担うケースが生じやすい
- 疎結合・マイクロサービス単位リリース環境特有のリスク:
- 開発者が勘違いをしたまま設計すると、そのままリリースされる可能性がある
- AIは「論理的な矛盾」の検知は得意だが、「ユーザーが求める真の意図」との乖離（仕様の誤り）は判断できない
- AIによるチェック体制は開発者の勘違いによる開発の歯止めにならない
- 従来のモノリスシステムでは、連結テスト・総合テストを第三者が実施することでこうした勘違いをバグとして検出していたが、MSAではその機会が失われる可能性がある
■ 7. ペアプログラミングの重要性
- 別人格の技術者が同一の勘違いを起こす確率が低いため、ペアプログラミングが有効な対策となる
- Pivotal Softwareも同様のアプローチを採用しており、その有用性を実証している
- 工数面の懸念への対応:
- MSAでは部品活用により開発工数が大幅に削減されるため、ペアプログラミングによる重複工数は全体として小さい
- テスト工数・連結テスト工数も削減されるため、全体的なコスト増は限定的と推察される
- クリティカル度に応じた品質保証方式の設計がPMの重要な仕事となる:
- 一般的なクリティカルなシステム: ベテラン技術者2名で担当
- さらにクリティカルなシステム: 3名の技術者が担当
■ 8. SBOMによる部品管理
- マイクロサービスを呼び出し先として活用する場合、該当サービスが修正された際に自サービス側の整合性確認・更新が必要となる
- SBOM（Software Bill of Materials: ソフトウェア部品表）の整備が品質確保に不可欠
- ソフトウェアの生産方式だけでなく、プロジェクトマネジメント技術の革新も求められる