ソフトウェア開発における標準化の必要性と概要設計フェーズの目的

現状、各工程の定義や成果物は開発ベンダーごとに異なっている。同一のユーザー企業でも、担当ベンダーが複数にわたれば、概要設計書や外部設計書の体裁、粒度はバラバラになる。設計書はベンダーごとに分けて保存されることになり、ユーザー企業側がITシステムの全体像を理解するのは困難になる。

さらに、納品される成果物の作成方法や意味について、開発ベンダーからユーザー企業に十分に教授されることはない。これではユーザー企業が設計書を自前で維持、管理するのは不可能に近い。ITシステムのブラックボックス化は、ほぼ必然的に進行することになる。

10年たつと、現行機能は誰にも分からなくなる

この状態が10年以上続くと、開発ベンダーも、放置された上流工程の設計書と現状の仕様との乖離が拡大し、状況を把握できなくなる。当然、設計書は、信頼の置けないものになっている。さらに、現行のシステムが「何のために」「どう動いているか」が誰にも分からなくなっていく。

ユーザー企業は開発ベンダーに対し、「長年担当してもらっているのだから、今と同じ仕様でお願いします」と求めがちだ。しかし、開発ベンダーは、「今と同じ」が一体何であるかを把握していない。それでも、長年の関係から仕事を受けざるを得ない。

当然、最上流に位置する概要設計の品質は誰も保証できないまま、後続の工程が進む。そして最終のテスト工程で現行システムとの整合性チェックを始めた途端、現行機能の保証漏れが次から次へと発覚し、収拾がつかなくなる――。こうした事象があちこちで発生している。

開発ベンダーにとって「現行機能保証」が“悪魔の言葉”になったのも無理はない。

ユーザー企業にも責任はある

念のため申し添えれば、これは開発ベンダーだけに問題があるわけではない。

ユーザー企業は、本来自ら定義すべき業務フローなどの要求事項の定義を開発ベンダーに丸投げしている。また、自ら維持、管理すべき業務フローなどの重要な設計書をメンテナンスせずに放置しているケースも多い（前述したようにユーザーが維持管理するのは難しい）。さらに、自ら本来要求定義を担う立場にない開発ベンダーに対して「長年担当しているのに、なぜ仕様が分からないのか」と糾弾するケースもある。ここまでくると、最近聞く「カスタマーハラスメント」に近い行為になりかねない。

では、ユーザー企業と開発ベンダーはどうすべきか。まず、ユーザー企業側は「無理筋の要求」であることを認識した上で、重要なパートナーである開発ベンダーを失わないようにすべきだ。開発ベンダー側は、致命的なものも含めて現状の課題を最も理解しているのは、プロである自分たちであることを改めて思い出すべきだ。ただ何もせずに傍観するのではなく積極的に既存システムを“見える化”し、ユーザー企業と協力しつつ、ユーザー企業を正しい方向へ導く責任があると筆者は考える。

「自社の標準化ルール」だけでは足りない理由

ユーザー企業の中には、「当社は独自の標準化ルールを定め、それに従った成果物の納入を開発ベンダーに求めている」と主張するところもあるだろう。そうした取り組みは確かに存在するが、筆者の経験から言えば、それだけでは不十分だ。

ユーザー企業の独自ルールに従うことは、開発ベンダーから見れば生産性の低下を意味する。手慣れたやり方でソフトウェア開発をしたい開発ベンダーからすると、これを避けたいのは当然だ。

かつて、筆者が超大規模ITシステムのPM（プロジェクトマネジャー）を務めたとき、もっとも苦労したのが工程と成果物の標準化だった。

日立製作所や富士通、NRI（野村総合研究所）などの工程と成果物を標準化した際の抵抗はすさまじかった。工程が異なれば進捗（しんちょく）管理ができない。成果物が異なれば中身のチェックは到底できない。そもそも各社の流儀を把握するための体制もない。工程と成果物の標準化はPMとして譲れない一線であり、半ば強制的に推し進めたことを覚えている。

各ベンダーからは「見積もり前提が異なる」ことを理由としたコストやスケジュールの見直しなど、さまざまなプレッシャーを受けた。こうした中で着地点を見いだすのに苦労したが、こうして決めたルールを各社に順守してもらうに当たっては、また別の問題が浮上する。

プロジェクト終了後、納品された成果物をユーザー企業自身が維持、管理し続けられるか。開発ベンダー側からの「標準ルール見直し」の継続的な圧力に耐えられるか。新たな人材が業務フローなどの成果物を自ら作成できるように教育できるか。成果物の維持、管理ルールを徹底できるか――。いずれも実現に向けたハードルは高い。

冷静に評価すると、ユーザー企業が単独で、重要な設計情報を長期にわたって保ち続けることは「困難」と言わざるを得ない。

業界として進めるべき標準化の「3つのポイント」

この状況を打破するには、業界全体での標準化が不可欠だ。具体的には、次の3点を一体で進める必要があると筆者は考える。

ソフトウェア開発方法論の標準化に必要な3つの柱

1．設計工程と成果物の標準定義： 設計工程と成果物を、ルールを知っている人なら誤解なく理解でき、同一レベルの成果物を作成できる適正な粒度で定義する。ユーザー企業、開発ベンダーを問わず、その定義に基づいてソフトウェアの設計開発を実施する

2．ツール化による生産性と標準化の両立： 成果物作成の仕組みをツール化する。ツールを活用すれば、生産性が高まると同時に標準化の徹底と教育が自然に進む

3．リポジトリ化とAI活用： ツール化により設計情報のリポジトリ（設計情報を一元的に蓄積・共有する基盤）化を徹底する。リポジトリを活用して設計から開発、テストまでの全工程でAI活用を進め、自動化範囲の拡大と各工程間の設計情報の矛盾点の指摘につなげる。これにより生産性と品質を継続的に向上させる

業界全体での標準化を実現するためには、公的機関を活用しながら進めることが第一歩となる。マイクロサービスを前提とした開発方法論の標準化や、既存ITシステムの現行機能分析手法の標準化、既存システムからマイクロサービスへの移行方式の共通化など、現状の課題を解決しつつ、ユーザー企業を巻き込みながら進める必要がある。筆者自身も標準化の実現に向けて動くつもりだ。読者の皆さんも、できることから始めていただければと思う。

「全てを同じように標準化する」必要はない

ここで注意したいのは、あらゆるプロジェクトを同一に標準化する必要はないという点だ。

例えば、データベース切り替えシステムは、ITシステムにとって極めて重要な仕組みではあるものの、リリース時に一回使うだけで次世代には引き継がない。情報分析システムをはじめとする仕組みも、仕様を正確に文書化する必要はない。開発者自身が把握できるレベルでの文書化で構わない。

つまり、標準化を考える上でITシステムの特性は極めて重要だ。まず標準化の対象とすべきは、社会インフラを支えるような、極めて高い信頼性が求められるITシステムだ。これらのシステムでは、厳格な規定の明確化や継続性が重要となる。それ以外のITシステムについては、各企業が標準化の適用範囲を個別に定義すればよい。

いずれにしても、ソフトウェア開発の標準化を進める公的機関が機能することを心から願っている。これを担える機関が、論理的には一つ存在することは確かだ。この件について進展があれば、本連載で報告したい。

概要設計フェーズ――目的は「基本設計が開始できる状態」を作ること

ここから、極めて重要なITシステムを念頭に置き、MSAを想定した具体的な工程の話に入りたい。まずは概要設計フェーズだ。

概要設計および基本設計工程のうちの外部設計までの工程は、現状から大きく変わるわけではないと筆者は考える。なぜなら、マイクロサービス（MS）を前提としてどのように設計するかは作り手である開発ベンダー側の責任になる。従って、上流のユーザー要件を作り手の事情で捻じ曲げるのは本末転倒だからだ。

ただし、MSを採用すれば、ソフトウェア開発の生産性と品質が桁違いに向上する。また、AIが扱える形式のデータを確保する観点でもMSAは欠かせない。各MSがAPIを通じて正規化されたデータを提供するため、AI活用の土台が自然に整うからだ。

そのため、開発ベンダーが担う基本設計フェーズの後半に位置する内部設計工程で、MSを最大限活用するという観点から技術的制約を洗い出し、必要に応じて概要設計に立ち戻って仕様を見直す進め方が肝要になる。こうした手戻りを繰り返す中で、「概要設計の段階で守っておくべき制約」が整理され、概要設計の成果物の標準化の精度が向上するはずだ。

概要設計フェーズの目的を明確化する

概要設計フェーズの目的は明快だ。「次工程である基本設計フェーズが開始できる状態を作る」ことに尽きる。

具体的には、外部設計が開始できる状態であることが必要だ。全てのインタフェースが洗い出され、詳細化できるレベルの成果物がそろっていなければならない。本稿におけるインタフェースとはシステムが外部とやり取りする入出力の接点および、連携仕様の全てを指す。具体的には画面、帳票、API、電子メール、表計算ソフトウェアのデータなどのデータ授受などを含む。

さらに、取り扱うデータの主要な項目となる「データクラス」（注1）のレベルが明らかになっている必要がある。例えば、顧客情報とその主要項目レベルは明確化すべきだ。

コード設計の失敗は、システムの寿命を縮める

特に重要なのが、顧客番号や商品番号といった「キー項目」だ。キー項目の体系設計は「コード設計」とも呼ばれる。

ただし、既存システムからの再構築案件では、コード設計は既に定義済みのケースが多い。その場合は、それを前提に設計を進めることが重要だ。ただ、新要件あるいは既存の課題を克服するためにコード設計を今一度やり直す場合もある。

コード設計の失敗がITシステムの寿命を縮めると筆者は考えている。コード設計の失敗、あるいは想定外のコード設計を追加することで、ITシステムが不安定になる事例や、作り直しを余儀なくされる事象は数多い。これについては、別の機会に詳しく述べたい。

コード設計は、個別の概要設計の前段階、ITシステム全体のアーキテクチャ設計時に実施する必要がある。これは本稿で扱うテーマを超えるが、極めて重要だ。筆者自身、このレベルのアーキテクチャ設計を経験した。しかし、それを体系的に整理して伝えられる状況にはなく、今後の検討課題となっている。いつか筆者あるいは他の識者によって整理されることを願う。

概要設計で押さえるべき「4つの形態」

概要設計で特に重要なのは、定義すべき全ての業務機能を明らかにすることだ。

以前にも触れたが、ITシステムの特性に応じて、設計情報は4つの形態に整理する必要がある。

概要設計の最重要設計情報――ITシステム特性別の4形態

業務フロー： 業務処理の流れを記述する。基幹業務系（O/L型）に適する

画面遷移図： ユーザー操作に伴う画面の遷移を記述する。Web型に適する

状態遷移図： システム状態の変化を記述する。ゲートウェイ型に適する

データフローダイアグラム（DFD）： データの流れを記述する。バッチ／トランザクション型に適する

いずれも、概要設計において最も重要な設計情報だ。MSを意識しながら、これらをどう設計するのか。次回から具体的に踏み込んでいく。

次回予告

今回は、ソフトウェア開発方法論の業界標準化の必要性を論じた上で、概要設計フェーズの目的と成果物について整理した。次回は、概要設計の4つの形態それぞれについて、MSAを意識した具体的な設計手法を解説する予定だ。