ＤＲＩ通信６７号「保守の対策」 ２００２．４．１
政治の昏迷、経済の停滞のなかで、２００２年度がスタートします。皆様いか
がお過ごしでしょうか。
システムは、ともすると野放図に大規模化・劣化し、制御不可能になりがちで
す。厳しい環境下ではありますが、われわれは、これをいかに制御し経営に役
立たせるべきか、コンサルティング現場の中で種々の知見を蓄積・整理しつつ
あります。完成したノウハウというよりも、実際のプロジェクトに適用して完
成に近づけていくべきものかと考えます。本年度も皆様のご配慮・ご支援をよ
ろしくおねがいします。
さて今月の６７号では、２月２８日開催の第７回Ｋ２Ｗ「保守の対策」をまとめます。
これはさきの６４号で第６回Ｋ２Ｗ報告を兼ねた「保守の実態」に続くものです。
無計画に肥大化したレガシーシステムの保守問題は、永遠の課題ですが、Ｋ２Ｗ勉強会
としては、保守問題は一旦きりあげ、広域統合など別の話題をとりあげていきたいと考えています。
「保守の対策」の議論は「巨大化・暗黒大陸・つぎはぎ・属人化・スパゲッティ状態」
のレガシーシステムを抱えた大手Ａ社（詳細は省略）に対するコンサルティング提案を募り、
この紹介をもとに行いました。
■Ａ社への提案
多くの提案において、
・データ管理体制の設置
・現状分析（特にデータモデリング）の実施
・リポジトリ構築・ドキュメント整備
があげられておりましたが、とくにユニークなものとして永棟氏（ＡＩＵ）および市堀氏（平和情報）
の提案を簡単に紹介します。
永棟氏は
・１０年後の全社システムイメージ図作成プロジェクトの立ち上げ
・システム案件レビュー会議の設定
を通じて、将来イメージを共有した上で、行き当たりばったりでない開発・保守管理を
提案されました。
また市堀氏は「手足の改革」と「頭と心の改革」をＲＯＩを考慮して３段階に分けて
推進すべきとのこと。
「手足の改革」ではまずコードドメインを重視したデータ定義管理を行い、次にこれと
ＩＯレイアウトやプログラムの関係を大まかに押さえ、最後に保守案件ＤＢを作り
何時・誰が・どこを・いくらで保守したかを管理する。また「頭と心の改革」としては
まずＰＬＡＮ−ＤＢをマスターし、要件の議論をデータモデルにより行うことを実施し、
これを組織として定着させる、というものでした。
■議論の骨格
これらの提案の後、議論に入りましたが、その骨格は次のように要約できるものでした。
すなわち、遅い・高い・ニーズを満たさない保守の原因は、劣化した・暗黙知の・大規模ソフトに
あるわけで、この解決には
・形式知とするためのドキュメントは如何にあるべきか
・これを誰が如何につくるか
・これをどう活用するか
・どうすれば劣化や必要以上の大規模が防げるか
が課題となる。
■形式知のためのドキュメント
ドキュメントとしては
・業務仕様ドキュメントとして
−データモデル図（ＴＨ骨格図、ＴＨ概要図、ＴＨ詳細図、ＴＨ物理対応部分図）
−データ定義書
−ＩＰＦチャート
−上記対応リポジトリ
・ソフトウエアドキュメントとして
−各種ソフトウエアドキュメント
−ソフトウエアリポジトリ
・プロジェクトドキュメントとして
−保守履歴書
が議論されました。
ＭＩＮＤ−ＳＡ創始者の上野氏は「ユーザが要件を確定／記述できないのが問題だ。
ＳＥは本来システムがどうなっているかさえ分かっていれば良いはずだが、ユーザが要件を確定できないので、
業務を学ばなくてはならなくなる」と問題提起されました。時間の制約から
「ユーザとＳＥの接点となる業務仕様ドキュメントはいずれが作るにしても不可欠なのだから」
として落着することになりました。
・ソフトウエアドキュメントとしては、「完璧なものが要求される。ＲＥＳＣＵＥは有効であるが、
アセンブラーが解析できないため、導入に至らず、自前のエディターで対処することになった」
との報告がありました。
保守経歴書は「有効であるが、ほとんど作成されていない」とのことです。
■業務仕様ドキュメントが作られない
業務仕様ドキュメントの必要性が分かっていながら、作られない・保守されない理由は、
「担当者への即効的利益がない、また文化がないため」とされました。確かに従来は少しでも
早くソフトを作り動かすことが要求され、業務仕様ドキュメントの作成は二次的に捉えられて
いたと言えるでしょうが、次のような背景があったことも事実のようです。
・担当者は、開発時は保守時に比較して、業務課題に専念できる時間が持てるため、暗黙知でも
かなりのコミュニケーションが行われるため、形式知の必要性が必須とまで思われない。
時間とともに記憶は薄れ、また物理差分メンテを重ねたり、担当が変わるなどして形式知の必要を
感ずる時には、もはや手後れとなってしまう。「最初が肝腎」です。
・多くの開発において、本当の業務仕様ドキュメントを作成する方法論がとられていないため、
多くの担当者は、他人から聞いたことはあっても、それが何か、またどんな効果があるかを実際は知らない。
「食わず嫌い」に近い。
■どうやって作るか
業務仕様ドキュメントは、最終的には、業務エンジニア（ＢＥ）が作るとしても、当面はユーザと
ＳＥが協力して作らなければならないようです。その中心はデータモデル図となりますが、次のようなコメントがありました。
・ＩＰＦは読めるが、データモデル図は難しい、説明と教育が必要、とくに凡例は不可欠
・業務別のテンプレートは、図を通じて業務を理解するのに有効である
・ＲＯＩを制御するために、３レベルの図（ＴＨ骨格図、ＴＨ概要図、ＴＨ詳細図）を使い分けると良い
・保守にはＴＨ物理対応部分図が、ユーザにとって入りやすく、また詳細に書けるので良い、ＲＯＩに無理がない
■保守の戦略
これらのドキュメントを作り、保守合理化を実現するには、大量のレガシーシステムを抱えていることもあり、
やはり戦略的に「じわじわと」取り組むしかないということで、次のような指摘がありました。
・シンパを育て、体制を作る
・ＰＭの育成は重要
・ユーザ企業は、納品物の形式を指定すべき、丸投げはいけない
・業務仕様ドキュメントをベースにした方法論教育を行う
・ドキュメントは大量なのでフラットではみれない、構造的に編成すべき
・鳥瞰的ＤＢ構造図アトラスは有効、これをベースに保守の都度精度を上げていく
・「見える」業務仕様ドキュメントから「見えない」ソフトドキュメントにリンクを張る
・ＳＥはＰＭ（プロマネ）、ＤＡ（データ管理者）、ＢＥ（ビジネスエンジニア）に変身すべき
・ソフト業界は生産性の基準のない特殊な業界、ＤＲＩはメーカー等大手に働きかけて、業界を変えるべき
・メンテ歴を残す
« 【第66号】第２のアンバンドリング【第68号】業務アプリケーションの分類 »
