登山のたとえ話しの続きですが、性能改善の失敗にはいくつかのケースがあります。①麓の樹海から抜けられない、②山頂を目指したが途中で断念、③ヘリコプターをチャーターしたが着陸できず、④手前の低い山に登って満足した、等々。

 

 情報の入手が困難だからといって、手ぶらで登山しようというのは無謀です。

 

 登山をするのはお客様自身で、無事に頂上に到達するためのお手伝いをすることが私たちの役目です。しかし、私がメーカにいたときには④に誘導することが多かったかもしれません。

 

前回の図８に示した通り、オンライン業務は問題が山積みです。

 

 前回の性能データ（PDL）の誤差の件もあるので、性能評価プロセス（第２回－図３）の測る化から一つ一つ確認をしながら進めることにしました。規模が大きいため、性能データを取得する環境を作ることも、またそのデータを検証することも大変です。そして、想定外のことは色々起きるものです。例えば、

 

退避している性能データ（SMF）に抜けがあった
大規模な基幹システムなので、最初は信じられませんでした。実行されているはずのジョブの情報が見当たらず、おかしい、不思議だと悩み、データを調べ続けた結果、データの退避に不備があり歯抜けになっていたことが判明しました。20年も気づかなかったのでしょうか。

性能データ（AIM課金統計情報）の時間が9時間ずれている
データの相互確認で不備が見つかり、原因を調査していたら時間がずれていることが判明。初めてのケースでとても大変でした。

正常に動作しないツールがある
性能データは、今でも毎年少しずつ機能が追加されています。そのため、ごく稀に見える化ツールが正常動作しないことがあります。EXCELなどの制限にも注意が必要です。

性能データに何かおかしい数字がある
利用者が細部のパラメタまで調整したとしても完璧な性能データはありません。よくあることです。

必要なときにすぐにデータを取得でき、見える化のツールも一通り動くようになればひと安心です。この検証に一週間かかりました。

 

さて、前述のAIM課金統計情報を分析すると、１トランザクションごとの処理時間（レスポンス時間）とCPU時間がわかります（図１０）。

性能評価プロセスの問題抽出、原因分析を始めると、暫定的な改善案も出てきます。プログラムの動作環境の改善（バッファサイズの最適化など）はお客様主体でできるので並行して進めていくことになりました。逆に、データベースやプログラムの改善は手間がかかるので後回しとなりました。

 

 暫くすると、様々なバッファにおいて不足回数を0にすることに注力し、本来の目的が見えなくなる「手段の目的化」が始まりました。

 

 更に、バッファを拡張したことによりCPU使用量が増加するという逆効果の現象も発生しました（バッファを大きくしすぎてメモリサーチが増えたため）。まさに、山頂が見えない麓の樹海を地図もなくさまよい歩いている状況です。

 

 そこで、あらためて課題設定をするために問題の整理をしました（図１１）。

 「できることから始めよう」と号令をかけることがあります。性能改善のシーンでは目標を達成しないと意味がないことも多く、下手をするともぐら叩きの状態に陥ることがあります。目の前に山があるからといって、何の準備もせずにまずは登り始めるのは無謀です。

 

 目標（山頂）を確認し、問題点を整理して課題を設定することがまさに地図を作ること、解決策を立案することが登山のルートを決めることに相当します。性能評価プロセスを着実に実行することが重要だとあらためて感じます。

 

                                                                                                                                                                    以　上