« ユニーク制約の使いどころ | トップページ | テーブル関連の「排他性」をモデル上で表現する »

2014.09.11

ドキュメントの山で遭難しないために

 業務システム開発において、包括的ドキュメントは決定的に重要である。仕様がコードや開発者の頭の中にしか存在しないとすれば、そのシステムは限定された要員にしか保守できない。その結果、ユーザ企業は開発ベンダーにロックインされ、内製であれば担当者の不在リスクと長期雇用を押し付けられる。意図的であれ意図しない結果であれ、開発方針として上等とはいえない。

 では、とにかくドキュメントを整備すれば良いのかというと、そういうことではない。大規模システムではしばしば、峨々たるドキュメントの山が築かれる。これでもかと階層化されたフォルダ構造と、EXCEL,パワポ,WORD,PDFのファイルの山。しかもそれらに含まれる定義要素間の制約関係は目視で維持されることになるため、整合性がじわじわと失われてゆく。また量が多すぎるため、欲しい情報に第三者がなかなかたどりつけないうえ、同じような文書が何度も作られたりする。

 ドキュメンテーションは大事な仕事だが、不整合を含むうえに必要な情報を取り出せないといった本末転倒なドキュメントの山を築いてもいけない。

 このやっかいな問題に我々はどのように対処したらいいのだろう。簡単なことだ。まずは、ドキュメントの重要性を認めるとともに、汎用ツールを使ってドキュメント管理するやり方(複雑なフォルダ階層とオフィスファイルの大集積)の不合理さに絶望しよう。そのうえで、システム開発専用の統合ドキュメント管理ツールを使えばよい。

 拙作のXEAD Modelerはそんなツールのひとつで、OSSとしては唯一のものだ。もともとは自分のために作ったのだが、さまざまな要望を取り入れた結果、今では津々浦々のプロジェクトで活用されている。これを使うことで、すべてを合わせても数メガバイトの単一ファイルに納まる。以下は作成できるドキュメントの一部だ。

・業務フロー(DFD)
・業務定義書(業務マニュアル)
・メニュー階層図
・サブシステム定義書
・データモデル(ER図)
・テーブル定義書
・機能定義書
・ビジネスルール定義書(*1)

 これらの多くが相互に関連している。たとえば業務フローは業務定義の組み合わせとして、サブシステムはテーブル定義と機能定義の組み合わせとして定義される。メニュー階層図は機能定義の内容から導出される。そして、各定義要素が他のどの定義要素と関連しているか(クロスレファレンス)や、CRUD図等の多彩な二次元ビュー(マトリックスリスト)も導出される。

 専用ツールを用いることの最もわかりやすい効果は、大量の情報の中から特定項目に瞬時にたどりつける点にあるが、たどりつけなくても大丈夫。手がかりとなる文字列で走査すればよい。走査して探し出すだけでなく、次図のように特定文字列を別の文字列に一括置換するのも一瞬で完了だ。

「受注」の表現を「注文」に一括置換する
20140911

 こういう当たり前の便利さを一度でも体験すれば、汎用ツールを使うやり方がいかに生産性や品質を損なっていたかを実感できるだろう。汎用ツールがダメというわけではないが、それだけでは無理だ。なぜなら我々は犬小屋程度の工学構築物を相手にしているわけではないからだ。業務システムの複雑さは、ときに高層ビルや飛行機に匹敵する。その設計情報の膨大さに圧倒されずに、定義要素間の込み入った整合性を維持しなければいけない。そのための手段として汎用ツールでは分が悪すぎる。

 じっさいに専用ツールを活用してみれば、上述した以外にもさまざまな効果があることに気づくだろう。すなわち、設計情報が様式化・標準化されるため、設計事例を知的資産として効果的に蓄積できるようになる。汎用ツールで書き散らされるドキュメントの山では、新人が設計スキルを向上させるための教材とはなりにくい。ひとりの設計経験はみんなのため、みんなの設計経験はひとりのため。組織的な設計スキルの向上のためにも、統合ドキュメント管理ツールを活用しよう。


*1.XEAD Modelerの最新版(V1.4.6)からの新機能。システムノード上の「用語とルール」のタブのこと。

|

« ユニーク制約の使いどころ | トップページ | テーブル関連の「排他性」をモデル上で表現する »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: ドキュメントの山で遭難しないために:

« ユニーク制約の使いどころ | トップページ | テーブル関連の「排他性」をモデル上で表現する »