« DBの複雑さとアプリの複雑さ | トップページ | ドメイン特化基盤がドメインを豊かにする »

2015.11.15

「論理設計」にこだわる利点

 業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。

 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。

1.業務構成
受注登録業務、受注保守業務、受注照会業務

2.データ構成
受注見出しテーブル、受注明細テーブル

3.機能構成
受注一覧機能、受注登録機能、受注保守機能、受注照会機能

 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(event)」や「誰(role)」や「どのように(protocol)」といった項目を含む。「データ構成」の各定義は、「一次識別子(PK)」や「属性項目(attribute)」や「テーブル関連(relationship)」といった項目を含む。

 とくに興味深いのが3の「機能構成」である。それらの論理定義は以下の項目を含む。これらがカバーされていれば論理レベルの機能定義として完成したことになるし、これ以上付け加える必要もない。

・機能ID/機能名
・引数と戻り値
・処理ロジック(機能パターン)
・テーブル入出力レイアウト
・フォーム入出力レイアウト
・印刷出力レイアウト

 「機能構成」は、上述した「業務構成」と「データ構成」とをつなげる要素である。つまり、「そのDB構造に格納されたデータを、その業務体制で維持してゆく。そのために必要な道具立て」として機能構成は周到に構想される。このように1.2.3の要素は密接に関連しているのだが、これらを私は「システム定義の3要素」と呼んでいる。

 ここで気をつけてほしいのが、「機能構成」の詳細項目として「クラス構成」が含まれていない点だ。勘違いされがちなのだが、クラス構成は機能定義の「論理的」ではなく「物理的」な側面である。そのアプリがどんなクラスを含む形で実装されるべきかといった問題については、論理設計ではなく、それに後続する「物理設計(詳細設計)」の段階で悩めばいい。プログラミング言語でゴリゴリ作るかフレームワークやツールを使うかには関係なく、まずは論理定義として上の形式でまとめておこう。

 たいていのプロジェクトでは、どんな実装方式を利用するのかがわかっているのだから、たとえば機能定義をいきなり「クラス構造を含むプログラム仕様書」としてまとめたほうが効率的ではないか――そのように思われるかもしれない。しかしそれをやってはいけない。

 理由はいくつもある。まず、もしそれぞれの案件について、実装方式(言語やフレームワーク)の特性を盛り込んだ形で設計書をまとめたら、機能定義の論理的な役割がわかりにくくなる。特定の方式や流行にもとづかない論理レベルの体系としてまとめておけば、10年たっても資料から設計意図を理解できるし、異なる実装基盤への移行も楽なのである。

 2つ目はスキル育成を効率化するためだ。もし、個々の案件で採用される実装方式を理解できていなければ設計を担えないとしたら、基本設計スキルの育成は簡単ではない。ただでさえシステム設計には高度なモデリングスキルが求められるのに、それに加えてさまざまな実装基盤にまで精通しておかねばならないとしたら、データモデリングなどいつまでたっても学べない。設計スキルといえども長期的には変化するものであるとはいえ、移ろいやすい実装方式を取り込むやり方は賢明ではない。

 3つ目の理由は、設計作業を「分担」せずに済むからだ。

 前々回の記事で基本設計を分担することの無駄や危険性について説明したが、じっさいのところ、「アプリ設計屋」と「DB設計屋」とが分離してしまっているプロジェクトは少なくない。アプリ(機能)と業務とDBのあり方は相互に密接に関連しているにもかかわらずそれらを分担するというのは、音楽作品の「メロディ」と「リズム」を別々の作曲者が作るようなものだ。システム開発だろうが音楽制作だろうがそのような基本要素レベルでの分業を許せば、良質な作品を生み出すことが無駄に難しくなる。

 にも関わらず安易に分業されてしまうのは、じっさいのところアプリ設計の負荷が大きいからだ。たとえば設計書上でクラス構造までを示すようなやり方では、プログラミングと同じくらいの手間がかかる。上掲したような論理レベルでまとめることが許されば、負担はずいぶん軽くなる。結果的に、機能構成と業務構成とデータ構成の3要素を同時に構想できるようになる。それぞれが詳細すぎないので、相互の整合性や全体のバランスもはかりやすい。

 負担が軽くなるとかバランスをはかりやすいと書いたが、それにしても簡単な作業ではない。システム設計の専門性はまさにこの段階で駆使される。機械的にやれる過程ではないし、ある種の適性や地道な訓練も求められる。言い換えれば、このフェーズを分業せずにシノギさえすれば、あとは人海戦術だろうがオフショアリングだろうが好きなようにやればよい。

 とは言うものの、当然ながら論理設計の担当者がそのまま物理設計や製造までを担うのが理想である。夢物語に思えるかもしれないがそうではない。論理設計に最小限度の補完を施せば「そのまま動作する仕様書」として完成する――そんな開発基盤がいくつも登場しているからだ。こういった技術革新は、ソフトウエアの本質が「機械に対する形式化された動作指示」であることの論理的帰結である。

 じつは「論理設計」にこだわることの最大の意義がここらへんにある。

 業務システム開発の世界ではこれまで、仕様書にもとづいて人が手作りすることで、必要なソフトウエアが生み出されてきた。しかし今後は、「形式化された動作指示」にもとづいて機械を直接制御するソフトウエア(ドメイン特化基盤)の利用が普及するだろう。そうなれば「形式化されていない動作指示(ようするにExcelやWordで書かれた仕様書)」を書く手間も、それにもとづいてプログラミングする手間も要らない。形式化された動作指示を書けば、ドメイン特化基盤によってそのまま動作するからだ。まあそれでもプログラミングが完全に不要になるわけではないが、それが必要な処理要件が限定されるので、設計者自身がプログラミングすれば済む。

 そんな態勢が普及して機械に仕事を奪われる前に、論理設計のスキルを身につけておこう。なぜか。ドメイン特化基盤用の「形式化された動作指示」は、原理的に「論理定義」に近づいてゆくからだ。そして、論理設計はクリエイティブな過程であるゆえに、これを脅かすソフトウエアが当面現れそうにないからだ。

|

« DBの複雑さとアプリの複雑さ | トップページ | ドメイン特化基盤がドメインを豊かにする »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「論理設計」にこだわる利点:

« DBの複雑さとアプリの複雑さ | トップページ | ドメイン特化基盤がドメインを豊かにする »