　図1は、バグの発生箇所のイメージ図です。ログファイルの形式は製品によってさまざまで、独自のフォーマットになっていますね。開発者は、ログファイルをもともとの状態で確認することは面倒ですから、変換するツール（スクリプトなど）を作成し、テスト結果をテキトーに判定していました。その結果、テスト対象とは異なるログ変換ツール側にバグが見つかってしまいました。

　テスト対象のバグではほっとしましたが、良かれと思って作成したツールにもバグがあることを再認識しました。

4.2 ケース9：運用ルールがまとまらずツールの利用が定着しない

ツールを導入したが、運用ルールなどの策定に苦労し、結局定着しなかった

　筆者はとあるツールを導入しました。導入自体はすんなり進みましたが、運用ルールがまとまらず、結局、定着せずに終わりました。原因を下記に示します。

　プログラムの計測ツールを導入したと仮定します。このツールは、ソースプログラムを入力すると、行数や複雑度を計算するアプリケーションです。ツールを使用することは簡単です。ツールにプログラムを入力し、実行ボタンを押下するだけでしょう。

　導入を決め、いざ運用しようとすると、以下のような問題点が現れます。

複雑度が幾つならよいのか
関数ごとのプログラムの行数が何行だったらよいのか
出力結果に問題があった場合は、作り直すのか
この指標への対応は、スケジュールが切迫してもやらないといけない絶対事項なのか

　筆者は、上記のような運用ルールをメンバーが満足する形で決定できませんでした。結局、ツールは定着せず、いつの間にかフェードアウトすることとなりました。開発プロセスが変わる可能性のあるツールの導入は慎重に進め、作業の変更点も事前に考えておく必要があります。

4.3 ケース10：ツールの操作方法が難しい

作成した自動化ツールの操作方法が難しく、積極的にツールを活用してもらえなかった

　筆者は、作業を自動化するツールを作成しました。しかし、もともとが面倒な業務であるため、ツール側の操作も簡単ではありません。そのため、このツールでは、幾つかのステップを踏んだ設定をしないとうまく動作しませんでした。

　「このツールを作ったので共有します」と共有すると、最初は「なかなか便利っすね」と言ってくれますが、言うほどは使ってくれません。恐らく、「便利だけど、ツールに振り回されたくない」と思ったのでしょう。結果、筆者が強く勧めない限り使用してくれませんでした。

　世の中には、便利だけれど、操作が難しいツールがたくさんあります。例えば、前述のWeb会議ツールは、「人が1カ所に集まる現実の会議」と「ツールによるネットワーク上の会議」の世界観が大きく異なり、「現実の会議ではこうなるはずなのに、ツールでは、なぜそうならないんだ？」とフラストレーションがたまった方も多いと思います。世界観や使用文化が異なると、高機能や便利さがかえって仇になります。

　筆者が大変だと感じるのは、自動化するためにプログラミングっぽい作業が必要なツールです。下記に例を示します（図2）。