システムはやがて,ブラックボックス化する。大切なのは,そうした状況を踏まえた上で,いかに迅速かつ確実に,必要な情報にたどり着けるかどうかである。

 では,「迅速」と「確実」を実現する上でのポイントは何か。システムと業務の調査を数多く手掛けてきたアビーム コンサルティングの財部透氏(プロセス&テクノロジー事業部 マネージャー)は「目的に応じて必要な情報は何か,それをどの程度まで探ればよいのかを見極めること」と言い切る。その上で「どのように」見える化するのかもポイントだという。この「何を」「どこまで」「どのように」という視点を無視すれば,調査工数が大幅に膨らみ,いくら時間があっても見える化の作業は終わらない。

見える化の目的は大きく三つ

 現場や専門家への取材を重ねた結果,現行システムを見える化する目的は,大きく三つあることが分かった。「再構築」「改修に伴う影響分析/スリム化」「障害調査」である。どれも必要に迫られた見える化であり,目的によって明らかにすべき情報が大きく違ってくる(図1)。

図1●見える化の対象とその失敗パターン
やみくもに現行システムを見える化していては,いくら時間があっても本来知るべき情報にたどり着けない。目的に応じて「何を」「どこまで」「どのように」という観点で臨むことが重要である
[画像のクリックで拡大表示]

 例えば,再構築を目的とする場合は,新システムに引き継ぐべき機能や業務を明確にする必要がある。具体的には,業務フロー,画面,帳票,外部インタフェースなど,主に外部仕様を見える化する。現行システムの業務上の課題も探る必要がある。

 改修に伴う影響分析やスリム化を目的とするときはどうか。この場合は,影響範囲を特定したり,不要なIT資産を洗い出したりする必要がある。そのため「未使用」「重複」「不足」といったソースコード,処理ロジックや参照関係といった,プログラムの内部仕様を見える化する。「ハードウエア,ネットワーク,ミドルウエアといったインフラに関する情報も重要な見える化対象」と説明するのは,アイアイジェイテクノロジーの小川晋平氏(関西支店 支店長)だ。小川氏によると「データセンターへのサーバー移設時では,既存のインフラ構成や状態をきちんと把握しないと,本番稼働がおぼつかない」という。

 障害調査を目的とした見える化では,ソースコードの問題個所,障害の影響範囲,処理が遅いソースコードやSQL,障害発生パターンを明確にする。

 こうした見える化の目的や対象とする情報は,事前に整理することが重要だ。過去に数百件を超えるシステムの見える化に携わった日立コンサルティングの小川誠氏(シニアマネージャー)は,見える化の前に図2のようなアンケートを必ず実施している。事前に見える化の目的や対象となるハードウエアやソフトウエア構成をつかむことで,無理のない現状調査の計画作りにつなげるわけだ。

図2●事前に見える化の目的,ハードウエア/ソフトウエアの構成をつかむ
目的やシステムの状況によって,見える化のアプローチや適用するツールが異なる。日立コンサルティングの小川誠氏は,事前にアンケートを使ってこれらを調査。無理のない見える化の計画作りにつなげている
[画像のクリックで拡大表示]

 前出の財部氏によると,何を見える化するかがはっきりしても,「どこまで」と「どのように」が分からなければ無用な時間を費やしてしまう。「例えば業務フローをとっても,その粒度によって数日で終わる場合も,数カ月かかる場合もある」(財部氏)。システムに関する情報は多岐にわたる上に,その数は膨大だ。そのためにも,事前に見える化のスコープを明らかにし,“干草の山から針を探す”というアプローチは避けなければならない。

失敗パターンに陥らない

 実際,見える化を実施したものの,「どこまで」「どのように」の部分がうまくいかずに失敗するケースは少なくない。(図1の右)

 例えば再構築時では,調査するドキュメント対象を広げすぎたり,業務と連動性のないシステムの調査になったりするのが,よくある失敗パターンである。

 改修に伴う影響分析/スリム化では,全コードを対象にした影響調査,おざなりなソースコードの棚卸し,表層面だけのインフラ調査などが陥りやすいパターンといえる。

 障害調査では,実環境,すなわち“動いているシステム”を対象に見える化する必要がある。そのため机上でのソースコードの調査,テスト環境による疑似的な性能調査では,本来の原因を突き止めることは難しい。

 こうした失敗に陥らないために,現場では工夫が求められる。次回以降では,三つの目的に分けて現場における見える化テクニックを見ていこう。

出典:日経SYSTEMS 2008年11月号 pp.20-21
記事は執筆時の情報に基づいており、現在では異なる場合があります。