/note/tech

「現行機能保証」はなぜ“悪魔の言葉”になったのか PM歴40年の筆者が解説

要約:

■ 1. 「現行機能保証」が問題化する構造的背景

  • 各開発ベンダーは工程の定義や成果物の様式が異なるため、複数ベンダーが関与するシステムでは設計書の体裁・粒度が統一されない
  • ユーザー企業は設計書の作成方法や意味を十分に教授されず、自前での維持管理が困難となりITシステムのブラックボックス化が進行する
  • 10年以上経過すると設計書と現状仕様の乖離が拡大し、開発ベンダー自身も現行仕様を把握できなくなる
  • テスト工程で現行システムとの整合性チェックを開始した段階で保証漏れが多発し、収拾がつかなくなる事象が各所で発生している

■ 2. ユーザー企業と開発ベンダー双方の責任

  • ユーザー企業側の問題:
    • 業務フロー等の要求事項定義を開発ベンダーに丸投げしている
    • 自ら維持管理すべき重要設計書をメンテナンスせず放置するケースが多い
    • 要求定義の責任を本来負わないベンダーに対し「なぜ仕様が分からないのか」と糾弾する行為はカスタマーハラスメントに近い
  • 開発ベンダー側に求められる姿勢:
    • 現状の課題を最も理解しているのはプロである自分たちであることを認識する
    • 傍観せず既存システムの見える化を積極的に推進する
    • ユーザー企業と協力しながら正しい方向へ導く責任がある

■ 3. 自社独自の標準化ルールだけでは不十分な理由

  • 開発ベンダーにとって、ユーザー企業固有のルールへの準拠は生産性の低下を意味するため忌避される
  • 大規模プロジェクトで複数ベンダー(日立製作所、富士通、NRIなど)の工程・成果物を標準化する際、各社からの抵抗は甚大であった
  • プロジェクト終了後に発生する課題:
    • 納品成果物をユーザー企業が長期にわたり維持管理できるか
    • 開発ベンダーからの「標準ルール見直し」圧力に継続的に耐えられるか
    • 新たな人材が成果物を自ら作成できるよう教育できるか
  • ユーザー企業が単独で重要設計情報を長期保持し続けることは「困難」と評価される

■ 4. 業界全体で進めるべき標準化の3つの柱

  • 設計工程と成果物の標準定義:
    • 工程と成果物をルールを知る者なら誤解なく理解でき、同一レベルの成果物を作成できる適正な粒度で定義する
    • ユーザー企業・開発ベンダーを問わず、その定義に基づいて設計開発を実施する
  • ツール化による生産性と標準化の両立:
    • 成果物作成の仕組みをツール化することで生産性を高めると同時に、標準化の徹底と教育を自然に進める
  • リポジトリ化とAI活用:
    • ツール化により設計情報のリポジトリ化を徹底する
    • リポジトリを活用して設計から開発・テストまでの全工程でAI活用を進める
    • 自動化範囲の拡大と工程間の設計情報の矛盾指摘により、生産性と品質を継続的に向上させる
  • 推進手段として、公的機関を活用しながら業界全体で進めることが第一歩となる

■ 5. 標準化の適用範囲に関する留意点

  • あらゆるプロジェクトを同一に標準化する必要はない
  • 標準化の優先対象: 社会インフラを支えるような極めて高い信頼性が求められるITシステム
  • 標準化が不要なケース:
    • データベース切り替えシステムなど、リリース時に一回使用するだけで次世代に引き継がないシステム
    • 情報分析システムなど、仕様を正確に文書化する必要がなく開発者自身が把握できるレベルの文書化で構わないシステム
  • それ以外のITシステムについては、各企業が標準化の適用範囲を個別に定義すればよい

■ 6. 概要設計フェーズの目的と成果物

  • フェーズの目的:
    • 「次工程である基本設計フェーズが開始できる状態を作る」ことに尽きる
    • MSAにおいて概要設計および外部設計までの工程は現状から大きく変わらない(MSの設計方法は開発ベンダー側の責任であるため)
  • 必要な成果物の条件:
    • 全てのインタフェース(画面、帳票、API、電子メール、表計算データ等)が洗い出され、詳細化できるレベルに整備されていること
    • 取り扱うデータの主要項目となる「データクラス」のレベルが明らかになっていること
  • コード設計の重要性:
    • 顧客番号・商品番号等のキー項目の体系設計(コード設計)はITシステムの寿命に直結する
    • コード設計の失敗や想定外の追加により、システムが不安定化または作り直しとなる事例が多い
    • コード設計はITシステム全体のアーキテクチャ設計時に個別の概要設計の前段階で実施する必要がある

■ 7. 概要設計で押さえるべき4つの形態

  • 業務フロー: 業務処理の流れを記述する(基幹業務系O/L型に適する)
  • 画面遷移図: ユーザー操作に伴う画面の遷移を記述する(Web型に適する)
  • 状態遷移図: システム状態の変化を記述する(ゲートウェイ型に適する)
  • データフローダイアグラム(DFD): データの流れを記述する(バッチ/トランザクション型に適する)