« 良単価・準委任で契約するためにできること | トップページ | 取引先にEDI用Webサービスを提供する »

2014.03.10

ドキュメント不整合問題の様相

 業務システムはいったん完成すれば終わりというものではなく、事業に合わせて変化・発展していかねばならない。その過程で開発者は、システムのあり方を把握するための包括的ドキュメントとシステムの実際のあり方を整合させるという課題に直面する。「仕様書とプログラムの不整合」はそういうった問題のひとつである。私が提唱する「3要素分析法」の枠組みを使って、ここらへんをじっくり眺めてみよう。

◆不整合はどこで生じるか

 まず、問題の様相を理解するために、基本設計書と仕様書(詳細設計書)とアプリケーションのそれぞれに含まれる要素と、それらの対応関係を見よう。まとめると図1のようになる。

図120140310_1

 まず、この議論の起点となる「基本設計書」には、私の言う「業務システムの3要素」が概念上含まれる。すなわち、業務モデル(どのようにシステムが利用されるか)、データモデル(データベースはどのような形をしているか)、機能モデル(UIやデータ処理の様式はどのようか)の3つである。

 それらのモデルを起点として、それぞれが具体化されてゆく過程がシステム開発に他ならない。業務モデル(a1)は、業務マニュアル(a2)として実装され、さらに訓練済ユーザ(a3)として実装される。機能モデル(b1)は、プログラム仕様書(b2)を経てプログラム(b3)として実装される。そしてデータモデル(c1)は、テーブル定義書(c2)を経てデータベース(c3)として実装される。

 ちなみに、アジャイルソフトウエア開発宣言に含まれる「包括的ドキュメントよりも動くソフトウエアを」は、これらのうちの6つの要素(a1,a2,b1,b2,c1,c2)よりも「動くプログラム(b3)」を優先すべしという主張である。この図で見ると、ひどく突飛な主張であることがわかる。

 唐突だが、将来の一定期間内に大地震が起こる確率と、同一期間内にシステムの保守担当者がいきなり職場に来なくなる確率を考えてみてほしい。間違いなく後者の確率が高い。事故、病気、忌引、離職など、理由はいくらでもある。サーバをクラウド上に置くことは有効な防災対策のひとつだが、保守担当者の急な交代に備えることのほうが、BCP(Business Continuity Planning, 事業継続計画)の観点で緊急度は高い。

 そのためには、システムのあり方を階層的・包括的に把握するためのドキュメントの整備が不可欠だ。たとえば生産管理システムを把握するための手がかりがコードだけだとしたら、そのシステムはメーカーにとって決定的なITリスクになっている。担当者の急な交代に対応できないばかりか、システムの保守性や発展性がひどく損なわれている。そんなメーカーと誰が取引したいと思うだろう。

 このように説明すると、アジャイル好きな技術者は決まってこのように反論する。「新たな価値観を提示しただけであって、包括的ドキュメントを作らないと言っているわけではない」と。しかし現実には、包括的ドキュメントの整備を怠ることの言い訳として「アジャイル」の用語が悪用されることが多い。

 ようするに、アジャイルでやろうがやるまいが、図1の9要素は開発成果物として等しく重要である。それが業務システムのあり方を見える化しておくということだ。いっぽう、成果物間の「不整合」が水平方向に並ぶ要素同士、および垂直方向に並ぶ要素の間で起こり得る。これらの多彩な不整合をすべて解消することなど可能なのだろうか。

◆開発基盤を使って不整合を解消する

 じつはこれらの不整合の一部は、技術的な工夫によって解消できる。不整合というものはあくまでも異なる要素の間で生じる。もし2つの要素を統合できるのであれば、それらの不整合は解消される。ある種のソフトウエアを利用することで、異なる要素をひとつに統合できる。すなわち、「仕様書駆動」の開発基盤を使えば、まず図1のb2とb3、およびc2とc3を統合できる。

 どういうことか。従来のやり方では、まず仕様書を書いて、これにもとづいて別途プログラミングしていた。そのために仕様書とコードの間の不整合がしばしば生じたし、あまつさえコードと実行モジュールとの不整合さえ生じた。

 ところが、「仕様書駆動」の開発基盤においては、専用のエディタを用いて仕様書(b2,c2)を書けば、その内容にもとづいてシステムが動作する。つまり、仕様書が文字通り「実行可能な仕様書」であるため、仕様書と実行モジュール(b3,c3)の間で不整合が生じ得ない。プログラムを新規開発するには新たに仕様書を書くことが強制されるし、プログラムを修正するには仕様書を修正することが強制されるのである。

 なぜこれが可能になったかといえば、開発基盤の適用領域(ドメイン)が意図的に狭められているためだ。狭くても需要の見込めるニッチを対象とすることで、必要なデータ処理機能を類型化できる。結果的に、様式化された仕様を介してアプリケーションの動作が制御可能になる。業務システムはまさにそんなニッチのひとつである。

 なお、上述したように不整合は図の垂直方向にも起こり得るが、「仕様書駆動」の開発基盤においてはその一部についても解消される。テーブルとプログラムの整合性を開発基盤が監視してくれるからだ。結果的に状況は図2のようになる。水色の矢印は不整合の心配がなくなったことを意味している。

図220140310_2

◆モデリングツールを使って不整合を解消する

 残された不整合を見よう。まず、基本設計書に含まれるモデル(a1,b1,c1)間の不整合だが、これはモデリングツールを用いることで解消できる。これらのモデルは独立した次元でありながらも、互いに精妙な牽制関係を持っている。それらの整合性を維持するにはどうしても専用のモデリングツールを利用する必要がある。Excelあたりでモデルを書いていては無理な話だ。

 さらに、気の利いたモデリングツールを使えば、業務モデル(a1)と業務マニュアル(a2)を統合できる。たとえばXEAD Modelerで書かれた業務モデルは、ブラウザに読み込ませるだけで業務マニュアルとして示される(Chrome専用のサンプル)。業務マニュアルはどうせ作る必要があるものだから、その種のツールを活用して楽をしたほうがいい。結果的に状況は図3のようになる。

図320140310_3

 不整合がだいぶ解消されてきたが、大きな溝がまだ残っている。2つのツールをまたぐ部分での不整合だ。これについて、これらのツールをひとつに統合すれば解消できると発想されやすい。しかしこれはまずうまくいかない。

 理由は明らかで、モデルと実装とが1対1に対応しないからだ。どのように対応するかは、実装方針や採用される開発基盤によって異なる。ようするにモデルには「実装独立」の側面があって、それをゼロにしてしまうと、実装方針を変えるたびにモデルを作り変えなければいけない。モデリングツールと開発基盤を統合することが可能だとしても、モデルが実装上の属性を抱え込むことになって、結果的にモデルの実装独立性が損なわれる。

◆「業務マニュアル」が連動の鍵になる

 これらのツールを統合できないのであれば、残った不整合の解消は無理なのか。じつは各要素を「連動」させるためうまい方法がある。その鍵となるのが「業務マニュアル」だ。

 上述したように、業務マニュアルは業務モデルから自動生成できる。そこで、システム実行時にユーザがF1キーを押すなどすれば、自動生成された業務マニュアルが表示されるようにしておく。そうするとユーザは、業務マニュアルの内容がシステムの最新仕様に追随していることを求める。

 いっぽう、業務マニュアルを最新仕様に追随させるためには、データモデルや機能モデルとの整合性をモデリングツール上で維持しなければいけない。つまり、開発基盤上で仕様変更が起これば、それに業務マニュアルを追随させるためにモデルを修正することが強制されるのである。

 残る不整合についても、業務マニュアルを活用することで対処できる。「ユーザの訓練体制」を確立することで、業務マニュアルは「全要素を連動させるためのカナメ」になる(図4)。業務マニュアルはシステム開発において軽視されがちな要素だが、それこそが不整合を全面的に解消するための鍵だ。

図420140310_4

|

« 良単価・準委任で契約するためにできること | トップページ | 取引先にEDI用Webサービスを提供する »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: ドキュメント不整合問題の様相:

« 良単価・準委任で契約するためにできること | トップページ | 取引先にEDI用Webサービスを提供する »