【エンジニア】新しいツールを社内で浸透させるには段階を踏もう
会社に新しいツールの導入の導入を推進している方：会社に新しいツールの導入したが、みんなが使ってくれるようにするにはどうしたらいいんだろう？
既に会社に新しいツールを導入した方：会社に新しいツールの導入したが、なかなか使われない。どうしたらいいんだろう？
今回はこのような疑問に対して解説していきます。
【エンジニア】新しいツールを社内で浸透させるには段階を踏もう
エンジニアとして仕事をしていると、いろんな要因で、社内に新しいツールを入れるべく、その推進をお願いされることがあります。
その際、新しいツールを社内で浸透させるには、段階を踏んで運用していくようにしましょう。
なぜなら、いきなり新しいやり方に切り替えると、ユーザは動揺するし、そもそも新しいやり方に変えること自体をめんどくさがるからです。
具体的には下記の順で導入していきましょう。
- まずは自分だけで一人複数役で検証してみる
- パイロットプロジェクトで試してみる
- 全体展開は、まずは一部機能のみ展開する
- 全展開する
まずは自分だけで一人複数役で検証してみる
ツールを使うのは、自分だけでは無いですよね。
また、いろんな役職の人が、いろんな役割の人が使うわけですよね。
なので、ツールの導入までに、それら全ての役割役職が触るべくユースケースを全て検証しておきましょう。
例えばタスク管理ツールを導入したとして、以下のように行います。
- 複数PCを用意します(作成者用とリーダー用で2つ)
- リーダー役のPC:リーダーの目線で、そのツールで作業タスクを生成、担当者に通知
- 担当役PC:担当役としてそのタスクを受け取り、タスクを遂行、完了後に結果通知
- リーダー役のPC:打ち上げられた作業結果を確認する
みたいな感じです。
このように、社内にある役割や役職に考慮して事前に操作をしておくことで、実際にやってみないとわからないことがある程度明確になります。
先程の例で言うなら、
- 作業者:作業タスクの指示がきたが、具体的な内容を書く欄がないので、何をすればいいか分かりにくい
- リーダー:作業者が作業の進捗を報告する際、報告の仕方が、0から100の数字で入力するようになっているので、人によって入れ方がばらけそう。なので、進捗を25%ごとに4段階で入力させるなど、もう少し統一性が欲しい
などです。
このように、自分以外のメンバーに展開する前に、自分で必ず役割と役職ごとのツールの使い勝手の検証しておきましょう。
パイロットプロジェクトで試してみる
自分で役割、役職ごとに検証が完了したら、今度はいよいよそのツールを他者に展開する時です。
でも、展開するのはまずは限定的にしましょう。
具体的にいうと、パイロットプロジェクトを1つ決め、そのプロジェクト内のみ展開するようにしましょう。
いきなり前展開しても、もしそのツール運用が至らなかったら、全社的に混乱を招いてしまい必要があるからです。
その分、限定的な公開なら、何かあっても対処が可能です。
なので、まずは、パイロットプロジェクトを選定した上で、限定的にツールを使ってもらい、そこで出た課題を全てつぶし、全社展開しても大丈夫かどうかの感触を得た上で全体的にツールを展開するようにしましょう。
全体展開は、まずは一部機能のみ展開する
いよいよ、ツールを全社的に展開した際、それでも、最初に展開するのは、全機能でなく、一部の機能とすると良いでしょう。
なぜなら、ここでも、いきなり前展開してしまうと、いろんな不具合や要望が来て対処しきれないからです。
例えば、進捗管理ツールを例にするなら、まずは、確実に作業を支持でき、そのステータスを確認できる、などで良いのではないでしょうか(あくまで例です)
そこに、例えば現在どれだけ作業したかを、実際の成果物ベースで見れるようにする機能など、そのような細かい機能は最初から一気に展開しなくても良いのではないでしょうか。
全展開する
ツールを前展開した際も、それにより疑問や不具合が確実に出てきますので、速やかに対処するようにしましょう。
失敗談：いきなり新しいやり方で刷新し、ユーザが離れた例
自分が実際にツールを導入した際に失敗したのが、上で言うと、2のパイロットプロジェクトでのお試しの際に、いきなりツールの全機能を展開してしまい、パイロットプロジェクトメンバーが混乱してしまったことです。
もともとのやり方に対して、いきなり全てを刷新してしまうと、さすがに人が混乱します。なので、パイロットプロジェクトである時も、いきなり全てを変えるのではなく、少しずつやる必要があったと反省しました。
段階的に導入する余裕がない場合は、社内サポート体制を充実させよう
これまで、新しいツール導入の際は、段階を踏んで導入するとよいことを解説しましたが、社内事情により、このように段階を踏んでツールを導入する余裕がない場合があります。
その場合は、社内のサポート体制を充実させましょう。
なぜなら、部署により、ツールの得手不得手があり、いろんな質問や改善要望が多発するためです。
質問や改善要望は速やかに対応しないとユーザが離れます
ユーザも、新しいツールを使うには抵抗があります。今までのやり方とやり方が変わることでストレスが溜まるし、そもそもユーザも別の仕事で忙しいからです。
このような中、せっかくツールを使ってくれたのに、そこで出た意見をツール推進者がすぐに反映しなかった場合、ユーザとしてはどう思うでしょうか。
きっとそのツールから離れてしまいますよね。なので、ツール推進者としては、ユーザからの意見は即反映できる体制を整えておきましょう。
部署により質問や改善要望は異なります
ユーザによる質問や改善要望は、部署によって内容が全く異なります。例えば、自分が実際にツールを展開した際はこんな感じでした。
- ソフトウェアチームなら、ある程度いろんなツールに使い慣れているので、操作方法の質問はあまり来ず、むしろ改善要望が多い
- 購買や営業のような間接チームからは、そもそもツールを使うので精一杯なので、操作方法に関する予報が最初に圧倒的に来る。そのあとで、ちょっとした改善要望が来る
このように、部署によって質問や要望の内容が大きく異なるので、それらを全て上した上でサポート体制を整えましょう。
ツール導入によるメリットを説明しよう
ツール導入の際は、導入によるメリットをユーザにきちんと説明するようにしましょう。
「今まではこうでしたが、ツールを導入することで、これからはこんなメリットがあります」
みたいな感じで。
ツールを変える必要がないと思っている人や変えるのがめんどくらいと感じるユーザもいるので、ここはしっかりと。
ツール選定時に、ツールベンダのサポート体制を確認しよう
これまで、ツール選定後の話が中心でしたが、そもそも、ツール選定の際は、ツールベンダ(ツールを作成した会社)のサポート体制を確認しておきましょう。
なぜなら、実際にツールを使うと、使う人数が増える毎に、疑問点や要望が多くなり、都度ツールベンダに質問やサポートをする機会が多くなるからです。
体験談：「その質問はサポート外です」と言われて困った
製品開発の傍ら、新しいツールを導入しましたが、推進者である自分でもわからないことが多かったため、ツールベンダーのサポートに問い合わせる機会が増えました。
その際、ツールの操作方法等は、速やかに回答くれるのですが、少し慣れてくると、ちょっと突っ込んだ内容(例えばツールのデータベース等)をいじらないといけないような改善要望が出てきます。
その際、データベースについて質問すると、
「データベースについてはサポート外です」
と、言われてしまいました。他のツールでは、データベースも含めてサポートしてくれるメンターが多いのに、です。
このように、「てっきりすべての質問にサポートしてくれると思ったのに」などと、実際ツールを購入してから思っても遅いので、ツール購入する前に、ツールベンダーのサポート体制や、サポート内容についてあらかじめ確認するようにしておきましょう。
ツール保守費も高いと後から不満がでるので注意
先ほど体験談で語った通り、自分が導入したツールは、ツールベンダーのサポートはいまいちでした。
にもかかわらず、そのツールベンダは外資なので、保守費用が国内企業に比べたら圧倒的に高かったのです。
なので、意図した回答が返って来なかったり、国内企業よりも保障費が高いと言うこともあって、ツール保守費について上層部から不満が出てきました。
ツール導入の際の稟議では、何も問われなかったのに、です。
このように、ツールやツールベンダの対応に対し、ユーザに不満があると、後からでも保守費について文句を言われますので、ツールベンダーのサポート体制をきちんと確認しておきましょう。
ツール選定でサポート内容を確認した上で、社内展開は段階的に
と、いうことで今回はこのくらいにします。
ツールを導入する際は、費用とか導入期間に目がいってしまいがちですが、
- 社内のサポート体制構築
- ツールベンダのサポート内容確認
- 段階的にツール導入
これらを意識してツール導入し、社内にそのツールを浸透させるようにしましょう。
今回は以上です。