ツールの立ち上げから運用を担っていたツールの専任担当者が離職してしまい、ツールのサポート体制が手薄になった
ツールの立ち上げから、運用を担っている担当者がいました。彼は、ツールで困った際には頼りになるエンジニアで、相談者と一緒にトラブルシュートもしてくれます。ある日、彼は部署移動することとなりました。次の担当者はツールを使用したことがありません。結果、頼れる人がいなくなり、サポート体制が手薄となってしまいました。
ツールを長期運用するという観点からも、運用担当者は重要な存在です。その人が離職するリスクも考え、自分がツールを導入した後のことも考えましょう。
ツールの習得時間を考慮しないスケジュールを作成し、思い通りに進まずに困った
マネジャーならば一度は経験があるでしょう。スケジュール作成時に自動化ツールの効果を過大に考えるケースです。筆者は、作成した自動化ツールの効果をうのみにし、確保するべき工数を少なく見積もってしまいました。結果、メンバーに負担をかけてしまいました。筆者の抜けていた観点を表1に示します。
No. | 作業 | 工数(h) |
---|---|---|
1 | スケジュールの作成 | 10 |
2 | 仕様・設計 | 500 |
3-x | 自動化ツールの操作方法を習得する ⇒ここを過少に見積もっていた |
30⇒実は80 |
3 | 自動化ツールを使ってXXを実施 | 130⇒60に短縮 |
4 | 実装 | 100 |
5 | テスト | 1000 |
表1 スケジュールの例(工数は適当に振っています) |
表1は、スケジュール作成例です。筆者は、本来作業として入れるべき操作方法の習得を少なく見積もっていました。ツールは使いこなしてこそ効果を発揮します。特に、複雑なツールであれば、手作業でやった方が早いこともありますね。筆者は、この習得時間を考慮しておらず、「なぜツールを導入したのに想定通り進まないのだろう」と思ってしまいました。
効果が高いツールほど、習熟に時間をかける必要があります。
自動化することで作業がブラックボックス化し、業務の全体像が分かりづらくなってしまった
ある日、新規メンバーが、顧客に成果物の説明をしていました。成果物の説明中、顧客から突っ込んだ質問がありましたが、質問の対象となった箇所は自動化されており、詳細はブラックボックス化されています。
新規メンバーは慌てます。その人から見れば、ボタン押したら勝手に出る部分としか分かりません。その時は、別の担当者がフォローに回って切り抜けましたが、自動化ツールによって、逆に業務の全体像を見えづらくしてしまうリスクを再認識しました。
今回は、前回に引き続きツール導入に着目し、ツール導入/運用時に生じる可能性のある問題点をケーススタディー形式でまとめました。
ツール導入には、乗り越えるべきハードルがたくさんあります。ケーススタディーの内容を確認し、問題点を認識したうえで、ツールの導入可否を検討してみると良いでしょう。
前々シリーズ「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.