» 【第99号】ドキュメンテーションの進化

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第99号】ドキュメンテーションの進化

DRI通信99号「ドキュメンテーションの進化」 2004.12.1
いろいろあった今年もあと1月を残す時期となりました。北海道では雪とか、風邪に気をつけて元気にお正月を迎えましょう。
「部分最適でなく、全体最適」が注目されてきましたが、アウトソーシング環境の場合は、発注側がよほどしっかりしなければなりません。SIerは個別アプリのQCD(Quality, Cost, Delivery)が課題ですから、全体最適には取り組みません。発注側のCIO、経営企画、システム企画が協力して全体問題−データ流通と最適化、そのための可視化−に取り組む時代が来ているのではないでしょうか。
弊社が幹事を務めている、DOA+コンソーシアムでは12月6日(月)田町Granparkにて、1周年記念講演会を行います。1年目の活動報告、2年目の活動計画のほか、DOA先進企業、協和発酵の中山嘉之さんのご講演、さらに懇親会があります。ご都合のつく方は多数ご参加ください。
■ ドキュメンテーション
ドキュメンテーションと言っても、システム・ドキュメンテーション、それもOSやワープロソフトなどでなく、業務アプリケーションシステムのドキュメンテーションに限定して、これがどのように進化したかを考えることにいたします。操作マニュアルは当初より必須でしたので、これは除き、システムの構造を示すドキュメントに限定します。あまり細分しても難しくなりますので、やはり5段階に分け、その形式を論ずるものとします。


■SDMM
根拠はかならずしも明示できませんが、40年近くこの道を歩んできたものの特権として、次ぎの5段階に分け、これをSDMM(System Documentation Maturity Model)と言うことにします。
? 事後ドキュメンテーション
? 設計ドキュメンテーション
? モデルドキュメンテーション
? 電子化ドキュメンテーション
? 実装独立と実装従属の分離
?は、ドキュメントのない時代から、1歩前進した段階です。ソフトは、プログラマという人間は読むことができますので、ドキュメント無しでもコミュニケーションできます。このため、大工が掘立て小屋を作るように、ドキュメント無し、あるいはこれに若干のコメントを挿入して許された時代がありました。しかしプログラムが何本か集まって、システムと呼ばれるようになると、ドキュメント作成のニーズが顕在化し、ドキュメントを作ることになります。しかしはじめは、個人プレー的な開発であり、レコードフォーマットを除いては、多くは設計に使うためのドキュメントというより、事後のメンテナンスや引継ぎのためのものが作られました。
?は、ドキュメントを先行して作成し、これにもとづいてソフトを作る段階です。システムが複雑化し、個人プレーから、チームプレーに移行するために、設計ドキュメントが必要になります。しかしまだドキュメントの形式は試行錯誤段階であり、大幅に自然言語に依存するかなり属人的なものでした。そしてユーザに対する要件定義なのか、プログラマに対する製造仕様なのか、はっきりしないドキュメンテーションだったかと思われます。
?は、仕様をより客観的に記述するために、モデル化により、図や表を活用することになり、「設計=ドキュメンテーション」となってきます。自然言語は、目的や備考的なものの記述に限定されてきます。設計の工程が定義され、工程と作成ドキュメントの関係がはっきりして、エンジニアリングとしての形態を整えてきます。
?は、設計工程へのコンピュータの利用です。?においても、ワープロやEXCELは使われていたわけですが、リポジトリと呼ばれるデータベースに蓄え、設計情報の意味や関連を把握し表現することになります。「人間の把握することは機械も把握しなければならない」からです。しかしこれも開発が一段落し保守フェーズに入ると、体制が崩れドキュメントの劣化が起こりがちになりますので要注意です。高品質を保証するための整合性は、メタ構造の中に仕組まれるようになってきます。
?は業務にかかわる仕様とITにかかわる仕様を分離して表現する段階です。開発タイミングが違うと、そのときのベストITが導入され、業務の個性も手伝って、同一企業内に多様なIT環境が生まれます。しかし、この間にもデータ流通が必要なため、どうしてもIT独立に仕様を把握する必要が発生します。また、ユーザはITにかかわる仕様は十分理解できませんし、また何時変わるか分からないので、これを理解することは無駄な努力になりがち、ユーザはITにかかわらない、ユーザに優しい業務仕様のドキュメントを求めるようになります。さらに、ユーザにとって同じ意味のものは、同じLook & Feelであってほしいと考えます。そこで図や表の表現に標準規則が導入されてきます。こうして、RFP(Request For Proposal)は業務の仕様を中心に、ユーザの理解できる形式で作られるようになります。一方、ITにかかわる製造仕様は、IT環境の標準化によって単純化を図るようになります。
こうして、実装独立の業務仕様と標準化されたソフト化仕様にもとづくMDA(Model Driven Architecture)あるいはプログラミングレスへの道が開けるものと思われます。ただし、それまではソフト本体の保守とドキュメントの保守が存在し、この同期を人間がとらなければならないため種々の問題が発生しがちになります。
DOAにもいろいろありますが、先進的なものは?を試行錯誤中のように見えます。話題のUMLもUML2.0となって、漸く?に足を踏み入れた段階かと思われますが、13種類ものドキュメントを用意するなど、整理不十分(メタメタデータに関してOne Fact in Many Places)に見えますが、いかがでしょう。
■気になること
・ユーザ要件を素早く固めるために、アジャイル開発として、プログラムを作りながら開発する方式のメリットが強調されたりしていますが、ユーザの希望通り動けばそれでいいではないかと、?以前の「ドキュメント無し」への逆戻りが起きないよう留意してもらいたいものです。
・XMLで書いたから「ドキュメントを残した」という認識もあるようですが、私には「コーディングを人が読めるからドキュメントだ」と言っているように見えます。少なくともXMLでは、?レベルではないと思います。
・ERP導入に当たって、これを理解するためにドキュメントはきわめて重要ですが、ユーザにとってきわめて分かりにくく、暗黙知化の原因になっているようです。?のレベルが不十分のまま、?に入ったため、?が不完全なのだと思われます。
・最近は大手SIerが手配師化し、方法論/ドキュメント形式を外注のプロマネに任せてしまうため、ドキュメンテーションに退歩が発生しているとか耳にします。事実だとすると問題ですよね。実装独立の、電子化された、モデルドキュメンテーションによって、ユーザとSIerがコミュニケーションできる時代が待たれます。