1年分の障害パターンを壁に張り出す
問題個所をどうしても特定できない。せめてヒントだけでも見える化したい──そんな悩みを抱えている現場は少なくない。クレジットカード決済システムを運用するNTTデータの新村哲也氏（決済ソリューション事業本部 カード＆ペイメントビジネスユニット カードネットワーク担当 課長）とNTTデータネッツの須崎正志氏（第七開発担当 第三開発担当 部長）も同様だ。月間のトランザクション数が2億6000万件を超える同システムは，多数の企業システムと連携。「見える化すべき対象が広すぎる」と新村氏は打ち明ける。
そこで新村氏らメンバーは，システムそのものを見える化するのでなく，システムが引き起こした過去の障害パターンを見える化した（図1）。
障害パターンは，過去1年に発生したものを会議室の壁一面に張り出している。システム名や発生日時，原因はもちろん，迷惑をかけた企業や担当者名を具体的に書き込んだ。「生々しさを出して，当時の記憶をよみがえらせることを狙った」（新村氏）。
他のシステムへの影響の有無や影響時間，社数，電文数，取引数なども明記した。これにより，トラブルの傾向によって，どのシステムにどの程度の影響が及ぶのかを見える化した。
「もし障害が起きても，いきなり膨大なシステムの個別調査に入るのではなく，過去の失敗から当たりをつけて，迅速な障害調査，対処が可能になった」と，新村氏は障害パターンを見える化した効果を強調する。
システム開発とその運用を，ベンダーにアウトソーシングするとどうなるか。IT部門とシステムの接点が薄れ，システムがブラックボックス化しやすくなる。これを回避するには，見える化マネジメントが必要だ。
納品物のマネジメントがその一つ。ベンダーには，プロジェクト完了時に納めてもらうドキュメントをきちんと明示する。そうしないとユーザー企業側に現行システムを把握できる資料が全く無くなる。現行システムとドキュメントの不整合を減らすために，むやみやたらと改修するのも避けるべきだ。当社では数年間分の変更要求をまとめて改修し，ドキュメントを修正している。
障害の発生を見える化するマネジメントも必要になる。例えば，1サーバー1アプリケーションという構成がよい例だ。障害が発生したときの調査が迅速に進めやすくなる。
データの持ち方も見える化の観点からマネジメントを利かせたい。最近は，システムごとに別々のベンダーに開発・運用を委託するケースもある。しかし各システムが互いにデータをやり取りしていると，一方のシステムの修正がいたるところに及びかねない。当社では，これを防ぐために各システムの間に中間サーバーを置き，データの一貫性を確保している。システム同士でデータを直接やり取りさせない疎結合の連携は有効だ。
体制面でも見える化に気を配る。例えば運用はベンダーに委託するが，監視は自社で行っている。社内から現行システムを見えるようにする唯一のインタフェースを絶つことを避けるためだ。
当社では担当者が2人しかいないのでノウハウが個人に蓄積しやすい。担当者が異動したら，途端にシステムはブラックボックス化する。そこで，各利用部門から2人程度，システム担当者として加わってもらっている。一定期間後は自部門に戻るが，そのノウハウを全社的に伝播できる。（談）
