DADCの全体像（図1）が固まり、センター長、プロジェクトリーダー、アドバイザーが決まり、検討テーマが選定された（図2）。経産省でも専門家会議がスタートした。そのうえでの10月22日のオンラインコンファレンスは、DADCの始動を告げるイベントだったことになる。
ちなみに上述の①～③の選定テーマを、強いて図3のDADCの資料「現在進めている取り組み」に当てはめると、①は「相互運用性を高めるアーキテクチャ」、②は「社会インフラのアーキテクチャ」③は「ガバナンスアーキテクチャ」に相当するだろうか。
IPAのシステム設計施策の遷移とビジネスフレームワーク
絵に描いた餅で終わるのではないか？ 民間からプロジェクトに参加する人の能力はどうか？（過去のプロジェクトで人件費を目当てに参加する企業もないではなかった）等々、DADCの先行きを懸念する声がないわけはない。スタートしたばかりなのでその評価は措くとして、ここで気がつくのは、ITシステムの設計・開発にかかわる工学的アプローチの転換だ。
IPAがITシステム設計の工学的アプローチに取り組んだのは、2004年10月に設置されたソフトウェア・エンジニアリング・センター（SEC）にさかのぼる。当時の資料によると、「エンタープライズ系ソフトウェアと組み込みソフトウェアの開発力強化、国際競争力の向上」がSECのミッションとして掲げられていた。
それまでの「ソフトウェアライフサイクルプロセス」（SLCP：Software Life Cycle Process）の呼称が「ソフトウェア開発ライフサイクル」（SDLC：Software Development Life Cycle）に変わり、「上流工程」という言葉が急浮上した。プログラミング工程より、要求定義や概要設計、さらに「システム化すべきかどうか」「既存システムとの整合性はどうか」など、入り口が重要という認識が高まった。
関連して、同じ頃から耳目にする機会が増えたのが「PDCA」と「As-Is/To-Be」だ。PDCAはPlan（計画）-Do（実行）-Check（評価）-Action（改善）の頭文字を取ったもので、「Cから始めるPDCA」とか、CをS（研究・学習）に置き換えた「PDSA」というような派生語も登場した。
一方のAs-Is/To-Beは、現状（As-Is）を正確にとらえ、あるべき姿（To-Be）を設定することを指す。To-Beを定めるために、3C分析（Customer、Company、Competitor：顧客、自社、競合）分析やSWOT分析（Strengths、Weaknesses、Opportunities、Threats：強み、弱み、機会、脅威）といったビジネスフレームワークが注目・推奨された。以後、As-Is/To-Beはシステム設計における工学的アプローチの絶対則のように考えられてきた。
As-Is/To-Be絶対視への異論もあったが……
ただし、当時から、As-Is/To-Beを絶対視することに異論がなかったわけではない。業務フローや書類ベースのAs-Isでは細々した現場の実情が反映されない／To-Beは希望的観測に陥りやすい、先々を見通したブレークスルーではなくAs-Isの改良・改善にとどまる、等々だ。さらに3C/SWAT分析に時間をかけているうちにビジネス環境が変化して、システムが出来上がったときは役に立たなくなっているかもしれない、という指摘もあった。
As-Is/To-Beが工学的アプローチの絶対則のように考えられたのは、それまでのシステム設計・開発が前例踏襲で属人性が強く、ドキュメントもない（あっても現状と不整合）。結局はマンパワーと4K（経験、勘、根性、神頼み）に依存するケースが少なくなかったためだ。現在もそうかもしれない。
IPA/SECはそれを承知で上流工程の重要性を訴え、繰り返しのレビュー、プログラミング工程の見える化、数値情報に基づく品質評価といった工程ごとに、具体的は手法を示して見せた。西暦2000年（Y2K）問題をクリアしたとはいえ、業務システムではバッチ型集中処理システムが幅を利かせ、エンベデッドシステムの価値がようやく理解された当時、非常に有用なアプローチだったと言っていい。
SECはその後、「ソフトウェア高信頼化センター」と名前を変え、現在は「社会基盤技術センター」に改組・改称されている。ちなみにDADCは社会基盤技術センターの下に置かれた特定テーマのための専門部会という位置づけだ。
続きは⬇️
