業務効率化の道具箱（14）続・便利なツールと裏腹の「地雷」を踏まないために：山浦恒央の“くみこみ”な話（167）（2/3 ページ）
ソフトウェア開発にとどまらない、PCを使う全ての人が対象となるシリーズ「業務効率化の道具箱」。第14回は、前回に続き、ツールの導入／運用時にありがちな「地雷」をケーススタディー形式で紹介する。
4．続・ツール導入／運用時のケーススタディー
4.1 ケース8：社内作成ツールにバグ
テスト時にログを確認したところ、意図しないデータを発見した。調査の結果、社内のエンジニアが作成したツールにバグがあることがわかった
筆者は、テスト結果を確認する業務をしていました。作業中、ある条件下で発生する不自然なデータを発見します。「ヤバイ、ソフトのバグかもしれない」と思い、調査をしましたが、なかなか原因が分かりません。さらに調査をすると、ログファイルを変換するツールにバグがあることが分かりました（図1）。
図1は、バグの発生箇所のイメージ図です。ログファイルの形式は製品によってさまざまで、独自のフォーマットになっていますね。開発者は、ログファイルをもともとの状態で確認することは面倒ですから、変換するツール（スクリプトなど）を作成し、テスト結果をテキトーに判定していました。その結果、テスト対象とは異なるログ変換ツール側にバグが見つかってしまいました。
テスト対象のバグではほっとしましたが、良かれと思って作成したツールにもバグがあることを再認識しました。
4.2 ケース9：運用ルールがまとまらずツールの利用が定着しない
ツールを導入したが、運用ルールなどの策定に苦労し、結局定着しなかった
筆者はとあるツールを導入しました。導入自体はすんなり進みましたが、運用ルールがまとまらず、結局、定着せずに終わりました。原因を下記に示します。
プログラムの計測ツールを導入したと仮定します。このツールは、ソースプログラムを入力すると、行数や複雑度を計算するアプリケーションです。ツールを使用することは簡単です。ツールにプログラムを入力し、実行ボタンを押下するだけでしょう。
導入を決め、いざ運用しようとすると、以下のような問題点が現れます。
- 複雑度が幾つならよいのか
- 関数ごとのプログラムの行数が何行だったらよいのか
- 出力結果に問題があった場合は、作り直すのか
- この指標への対応は、スケジュールが切迫してもやらないといけない絶対事項なのか
筆者は、上記のような運用ルールをメンバーが満足する形で決定できませんでした。結局、ツールは定着せず、いつの間にかフェードアウトすることとなりました。開発プロセスが変わる可能性のあるツールの導入は慎重に進め、作業の変更点も事前に考えておく必要があります。
4.3 ケース10：ツールの操作方法が難しい
作成した自動化ツールの操作方法が難しく、積極的にツールを活用してもらえなかった
筆者は、作業を自動化するツールを作成しました。しかし、もともとが面倒な業務であるため、ツール側の操作も簡単ではありません。そのため、このツールでは、幾つかのステップを踏んだ設定をしないとうまく動作しませんでした。
「このツールを作ったので共有します」と共有すると、最初は「なかなか便利っすね」と言ってくれますが、言うほどは使ってくれません。恐らく、「便利だけど、ツールに振り回されたくない」と思ったのでしょう。結果、筆者が強く勧めない限り使用してくれませんでした。
世の中には、便利だけれど、操作が難しいツールがたくさんあります。例えば、前述のWeb会議ツールは、「人が1カ所に集まる現実の会議」と「ツールによるネットワーク上の会議」の世界観が大きく異なり、「現実の会議ではこうなるはずなのに、ツールでは、なぜそうならないんだ？」とフラストレーションがたまった方も多いと思います。世界観や使用文化が異なると、高機能や便利さがかえって仇になります。
筆者が大変だと感じるのは、自動化するためにプログラミングっぽい作業が必要なツールです。下記に例を示します（図2）。
図2は、便利だけど大変なツールのイメージです。よくあるツールでは、プログラミングっぽい条件分岐や繰り返しを要求します。
せっかく作業を楽にしたいのに、「XXXの場合は……」「XXX回繰り返す……」というメッセージが画面に出てしまうのでは、初めの一歩を踏み出してもらうにはハードルが高すぎると感じます。
コロナ禍の「強制的なIT化」のような「このツールは絶対に使って」という要求がない限り、楽になると分かっていても使用してもらえない可能性があります。ツールを作成する場合は、使用する側のことも考えることをお忘れなく。
Copyright © ITmedia, Inc. All Rights Reserved.