» 【第67号】保守の対策

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第67号】保守の対策

DRI通信67号「保守の対策」 2002.4.1
政治の昏迷、経済の停滞のなかで、2002年度がスタートします。皆様いか
がお過ごしでしょうか。
システムは、ともすると野放図に大規模化・劣化し、制御不可能になりがちで
す。厳しい環境下ではありますが、われわれは、これをいかに制御し経営に役
立たせるべきか、コンサルティング現場の中で種々の知見を蓄積・整理しつつ
あります。完成したノウハウというよりも、実際のプロジェクトに適用して完
成に近づけていくべきものかと考えます。本年度も皆様のご配慮・ご支援をよ
ろしくおねがいします。
さて今月の67号では、2月28日開催の第7回K2W「保守の対策」をまとめます。
これはさきの64号で第6回K2W報告を兼ねた「保守の実態」に続くものです。
無計画に肥大化したレガシーシステムの保守問題は、永遠の課題ですが、K2W勉強会
としては、保守問題は一旦きりあげ、広域統合など別の話題をとりあげていきたいと考えています。
「保守の対策」の議論は「巨大化・暗黒大陸・つぎはぎ・属人化・スパゲッティ状態」
のレガシーシステムを抱えた大手A社(詳細は省略)に対するコンサルティング提案を募り、
この紹介をもとに行いました。


■A社への提案
多くの提案において、
・データ管理体制の設置
・現状分析(特にデータモデリング)の実施
・リポジトリ構築・ドキュメント整備
があげられておりましたが、とくにユニークなものとして永棟氏(AIU)および市堀氏(平和情報)
の提案を簡単に紹介します。
永棟氏は
・10年後の全社システムイメージ図作成プロジェクトの立ち上げ
・システム案件レビュー会議の設定
を通じて、将来イメージを共有した上で、行き当たりばったりでない開発・保守管理を
提案されました。
また市堀氏は「手足の改革」と「頭と心の改革」をROIを考慮して3段階に分けて
推進すべきとのこと。
「手足の改革」ではまずコードドメインを重視したデータ定義管理を行い、次にこれと
IOレイアウトやプログラムの関係を大まかに押さえ、最後に保守案件DBを作り
何時・誰が・どこを・いくらで保守したかを管理する。また「頭と心の改革」としては
まずPLAN−DBをマスターし、要件の議論をデータモデルにより行うことを実施し、
これを組織として定着させる、というものでした。
■議論の骨格
これらの提案の後、議論に入りましたが、その骨格は次のように要約できるものでした。
すなわち、遅い・高い・ニーズを満たさない保守の原因は、劣化した・暗黙知の・大規模ソフトに
あるわけで、この解決には
・形式知とするためのドキュメントは如何にあるべきか
・これを誰が如何につくるか
・これをどう活用するか
・どうすれば劣化や必要以上の大規模が防げるか
が課題となる。
■形式知のためのドキュメント
ドキュメントとしては
・業務仕様ドキュメントとして
−データモデル図(TH骨格図、TH概要図、TH詳細図、TH物理対応部分図)
−データ定義書
−IPFチャート
−上記対応リポジトリ
・ソフトウエアドキュメントとして
−各種ソフトウエアドキュメント
−ソフトウエアリポジトリ
・プロジェクトドキュメントとして
−保守履歴書
が議論されました。
MIND−SA創始者の上野氏は「ユーザが要件を確定/記述できないのが問題だ。
SEは本来システムがどうなっているかさえ分かっていれば良いはずだが、ユーザが要件を確定できないので、
業務を学ばなくてはならなくなる」と問題提起されました。時間の制約から
「ユーザとSEの接点となる業務仕様ドキュメントはいずれが作るにしても不可欠なのだから」
として落着することになりました。
・ソフトウエアドキュメントとしては、「完璧なものが要求される。RESCUEは有効であるが、
アセンブラーが解析できないため、導入に至らず、自前のエディターで対処することになった」
との報告がありました。
保守経歴書は「有効であるが、ほとんど作成されていない」とのことです。
■業務仕様ドキュメントが作られない
業務仕様ドキュメントの必要性が分かっていながら、作られない・保守されない理由は、
「担当者への即効的利益がない、また文化がないため」とされました。確かに従来は少しでも
早くソフトを作り動かすことが要求され、業務仕様ドキュメントの作成は二次的に捉えられて
いたと言えるでしょうが、次のような背景があったことも事実のようです。
・担当者は、開発時は保守時に比較して、業務課題に専念できる時間が持てるため、暗黙知でも
かなりのコミュニケーションが行われるため、形式知の必要性が必須とまで思われない。
時間とともに記憶は薄れ、また物理差分メンテを重ねたり、担当が変わるなどして形式知の必要を
感ずる時には、もはや手後れとなってしまう。「最初が肝腎」です。
・多くの開発において、本当の業務仕様ドキュメントを作成する方法論がとられていないため、
多くの担当者は、他人から聞いたことはあっても、それが何か、またどんな効果があるかを実際は知らない。
「食わず嫌い」に近い。
■どうやって作るか
業務仕様ドキュメントは、最終的には、業務エンジニア(BE)が作るとしても、当面はユーザと
SEが協力して作らなければならないようです。その中心はデータモデル図となりますが、次のようなコメントがありました。
・IPFは読めるが、データモデル図は難しい、説明と教育が必要、とくに凡例は不可欠
・業務別のテンプレートは、図を通じて業務を理解するのに有効である
・ROIを制御するために、3レベルの図(TH骨格図、TH概要図、TH詳細図)を使い分けると良い
・保守にはTH物理対応部分図が、ユーザにとって入りやすく、また詳細に書けるので良い、ROIに無理がない
■保守の戦略
これらのドキュメントを作り、保守合理化を実現するには、大量のレガシーシステムを抱えていることもあり、
やはり戦略的に「じわじわと」取り組むしかないということで、次のような指摘がありました。
・シンパを育て、体制を作る
・PMの育成は重要
・ユーザ企業は、納品物の形式を指定すべき、丸投げはいけない
・業務仕様ドキュメントをベースにした方法論教育を行う
・ドキュメントは大量なのでフラットではみれない、構造的に編成すべき
・鳥瞰的DB構造図アトラスは有効、これをベースに保守の都度精度を上げていく
・「見える」業務仕様ドキュメントから「見えない」ソフトドキュメントにリンクを張る
・SEはPM(プロマネ)、DA(データ管理者)、BE(ビジネスエンジニア)に変身すべき
・ソフト業界は生産性の基準のない特殊な業界、DRIはメーカー等大手に働きかけて、業界を変えるべき
・メンテ歴を残す