« ドメイン特化基盤の柔軟性を高める | トップページ | ER図レビューの3つのポイント »

2016.06.26

「外部設計・内部設計」の危うさ

 「外部設計」という用語がある。業務システム開発の世界では昔からあって、「ウォーターフォール方式(WF)」で工程を区別するために使われている。「外から見える部分の設計」という意味のexternal designを訳したものと思われるが、これがなかなかのくせ者だ。

 建築に喩えることを許してもらえるなら、「外から見える部分」は壁の色だの玄関の形だのといった「見た目」であって、そんなものを高層ビル建築の上流工程で提出しても「これだけでは不十分」とつっかえされるのがオチだ。ユーザから見える「フォーム」や「帳票」のデザインをまとめただけの上流工程成果物が役に立たないのも同様であって、この意味で建築とシステム開発は似ている。

 「外部設計」のタイミングで優先的になされるべき仕事は何か。それは「見た目」ではなく「骨格」の構想と決定である。高層ビルの設計で言えば基礎や鉄筋の構造に相当する。これらの多くはユーザの目に見えないが、初期段階でこれを明確にしておかねば建設プロジェクトは先に進みようがない。

 にもかかわらず、システム開発においてそれらを丁寧に扱った「外部設計」にはなかなかお目にかからない。「外部」が「見た目だけ」の意味でなかったとしても、そのように都合よく解釈されて運用されることが避けられない(何が都合が良いかというと、システムの見た目をまとめるだけならものすごく簡単なのだ)。たかが呼び方の問題と思われるかもしれないが、用語が人の発想にどれだけ影響を与えるかを侮ってはいけない。

 必然的に、「外部設計」に続く「内部設計(internal design)」では、「見た目どおりに動くための内部構造」が検討される羽目になる。ところが、外部設計においてシステムの骨格が明らかにされていないため、フィージビリティ(実現可能性)が曖昧なままに内部構造が「辻褄合わせ」される。

 それでうまくいくことがないわけではないが、まずうまくいかないし、失敗の原因もわからない。ビルならば施工中に倒壊して、建築士に効果的なフィードバックが返る。ところが悪いことに、ソフトウエアはデスマーチでがんばればなんとか動いてしまうので、システム設計者がなかなか反省できない。激しく反省するのは管理部門で、赤字に懲りて監視態勢を強化する。かくしてExcelの管理資料ばかりが増えてゆく。

 ユーザからの見た目が重要でないと言うつもりはない。なんのかんの言ってもフォームや帳票のデザインは、システム設計に関して素人であるユーザが納得感を得るための貴重な手がかりである。私が言いたいのは、それらを含め、より重要な要素を設計工程の初期段階で統合的に確立すべきということだ。「外部設計・内部設計」の語感では、重大な要素の検討が後回しにされやすい点こそが問題である。

 ではなぜ、そのような危うい用語(外部設計・内部設計)が定着してしまったのか。それは、この用語が成立したのが、DOA(データ指向アプローチ)が提唱される以前だったからだ。DOAは「データの保管様式をシステム設計の基礎とせよ」を基本テーゼとする主張だが、それ以前において主流だったのはPOA(プロセス指向アプローチ)、すなわち「アプリの入出力をシステム設計の基礎とせよ」であった。大規模なDBを核とするソフトウエア開発向けにそれでは無理があることは今では明白なのだが、残念なことに業務システム開発の黎明期にはその発想がなかった。

 じっさい、「アプリの入出力をシステム設計の基礎とせよ」の発想では、開発者の関心は必然的にユーザの目に見える要素のデザインに向かう。結果的に、アプリの動作を背後で支える「データの保管様式」の検討は後回しにされる。ようするに「外部設計・内部設計」の用語は、POAの発想と表裏一体なのである。

 上述したようにDOAでは「データの保管様式をシステム設計の基礎とせよ」と考えるのだが、キャリアの初期にDOAの洗礼を受けて育った技術者として断言するが、データの保管様式だけを明らかにすれば安泰というわけではない。上流工程ではデータの保管様式に加えて、アプリの基本構造や業務態勢までが決定されなければいけない。それらを私は「業務システム設計の3要素」と呼んでいるのだが、これこそ業務システムの「アーキテクチャ(意図された構造)」に他ならない。

 アーキテクチャを決定する工程は「外部設計」ではなく「構造設計」とでも呼ぶべきではないだろうか。そして、これに続く工程は「内部設計」ではなく「制御設計」くらいがいい。「内部設計・外部設計」ではなく「概要設計・詳細設計」と呼ばれることもあるが、これだと「どこまでが概要でどこからが詳細か」が曖昧である。いっぽう「構造設計・制御設計」と呼べば、工程の役割感がより明確になる。

 すなわち、「構造設計」では、データの保管様式(DB構造)、アプリの分割様式(「見た目」はこれに含まれる)、および業務態勢(どんな業務上の役割が求められ、それぞれがどのように仕事をこなすか)が検討される。「制御設計」においては、先行工程で決定された「骨格」にもとづいてシステムが適切に動作するための制御仕様が検討される。「静的仕様を決めてから動的仕様を詰める」と言い換えてもいい。

 このように分けても工程の区分として曖昧な部分はどうしても残る。たとえばDB構造は基本的に「構造設計」での検討課題とみなされるが、ある種のフィールド定義は「制御設計」の過程で付加される。まあそれでも、「システムの骨格を決定すること」の難しさや重大さが先行的に対処されるという点で、安心感が「外部設計・内部設計」とはまるで違う。

 なお、今でも「WFかアジャイルか」の議論がネットで盛り上がることがあるが、二択問題のように単純ではないし、「どんなソフトウエアを対象とするか」でも話は違ってくる。少なくとも、業務システムのように複雑巨大なDBを核とするソフトウエアを相手にする場合なら、「設計・実装される対象を小さく切り出してイテレーションを繰り返す」を旨とするアジャイルの一本槍では無理がある。

 まずは「構造設計」において、DB構造を含めたシステム全体のあり方(グランドデザイン、アーキテクチャ)が決定されるべきだ。これは、高層ビルの施工開始以前でふつうに決定されているように、業務システム向けであっても実装を始める前に実施可能である(専門性や訓練が必要なことは言うまでもない)。そのうえで「制御設計」では、部分的に実装し動作させながら仕様を探るアジャイル方式やプロトタイピング方式を積極的に取り入れたい。

|

« ドメイン特化基盤の柔軟性を高める | トップページ | ER図レビューの3つのポイント »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/63830945

この記事へのトラックバック一覧です: 「外部設計・内部設計」の危うさ:

« ドメイン特化基盤の柔軟性を高める | トップページ | ER図レビューの3つのポイント »