そのツール導入、ちょっと待った…!?成功確率UPの法則

はじめに

はじめまして。BizOpsのマネジャーをしています、杉山と申します。私たちの役割の一つに、ビジネス側のツール導入をサポートし生産性を上げていくことがあります。ですが大体、新規ツールの導入はうまくいきません。
「導入したら思ってたのと違った」「逆にやることが増えて便利にならなかった」「数カ月後には、もとの運用に戻ってツールは放置」・・・こんな状況に見覚えないでしょうか？今回は、3年ほど奮闘した中で得た新規ツール導入の成功確率を上げる方法を紹介します。

そもそも何が原因なのか？

なぜツール導入は失敗するのか。大きく分けて3つの原因があります。

1つ目が、要件や期待値が揃っていないことが原因となるもの。ツールを利用する企業と提供企業、または社内で利用者と設計者が違う場合に発生しやすいです。営業やカスタマーサクセスと私たちBizOpsといった関係も、利用者と設計者が違うケースですので、多く失敗してきました。
2つ目は、運用課題の見積もり不足です。いざ運用したら、すごく面倒だったり、運用変更に対応できない人が出たり、想定外の使い方をする人が現れたりします。人は想定外に弱く、慣性に抗えない生き物です。運用課題を解決できず元の運用に戻ってしまうのです。
最後が、組織長、要はトップが本気ではないケースです。根性論は好きではないのですが、悲しい真実です。組織というのはトップの影響を大きく受けます。トップがツール導入の優先度を低くすれば、多くのメンバーは一生懸命やるはずがないです。もちろん、その下のリーダーやマネジャー層も真面目に取り組みません。また、関心がないが故にリーダーやマネジャー層に任せて、同じようなツールが沢山になってしまったり、運用が定着する前にツールがどんどん変わってしまうなんてこともあります。

成功確率UPのために試してみたこと

要件定義書やRFPを作成する

開発組織であれば当たり前なのですが、既成ツールの導入であっても要件定義書やRFPを作りました。これを使ってステークホルダー間の前提を揃えていきます。
特に1つ目の原因に対して有効です。といっても、実はエンジニア向けの要件定義書のような細かいものでなくても大丈夫です。目的は、基本的な部分をすり合わせることだからです。私たちがビジネス側と一緒に使っている項目で必須にしているものを紹介します。

1. 目的・目指す状態：当たり前過ぎますが、これが揃ってないことがほとんどです。
2. 現状と1に対する課題：笑うくらい課題に思ってることもずれてます。
3. 関係者とその役割：導入時に「やってくれると思ってた…」を防ぎます。
4. スコープになるプロセス：今回の導入で、絶対変えるものと変えなくても良いものを明確にします。めんどくさいですがツール導入で変更になる前後の業務プロセス（または業務フロー）を書き起こします。その中で、変更したいところをMust/Wantのように優先順位をつけて整理します。
5. スケジュール：いつまでに？は問いやすいのですが、逆に技術的な問題を加味した、実現可能なタイムラインの認識も揃えます。
6. 達成指標：1の目的を満たした状態を数字（例：業務時間削減X時間など）で設定します。1が定量で出せているなら必要ありません。

一足飛びやカエル飛びのツールを採用しない

Ops側からすると、あれもこれも自動化したり変更したりしたくなるのですが、それを止めることにしました。要件定義の4に関わっているのですが、業務プロセスを大きく変更しすぎると、反発があったり、誰も対応できず元に戻ることがしばしばありました。少し背伸びするくらい、利用者が良くなるイメージができるくらいの変更に留め、ツールもTooMuchにならない物を選ぶようにしました。
要は、チャットを使ったことがない人にいきなりチャットbot使ってくださいと言っても無理なのです。そのため、まずはチャットから始めましょう、という感じです。

運用設計は3つのポイントを抑える

原因の2つめにヒットする運用の解決策です。特に運用開始時に工夫した3つを上げています。

1. テスト運用する：これも当たり前なのですが、飛ばしがちです。試して、問題がなければ導入というやり方を徹底しました。
2. 運用目標と進捗をチェックする場を用意：入力率やアクティブユーザー数などの運用開始後の目標を設定しました。最初の3ヶ月くらいは設定しておくと、運用を試行錯誤するきっかけになります。また進捗をチェックする会議体などもセットしておきます。
3. 利用者が多い場合は成功体験を意図的に偏らせる：チャンピオンなんていい方もしますが、ロイヤルユーザーを意図的に作りにいきます。誰かがうまくいくと、それを真似したくなるものです。この心理を利用する作戦です。利用者が多い場合や、利用者と設計者が違う場合に有効です。

トップが本気になるまでやらない

これは、私がOpsの立場であるという前提での話ですが、ツール導入の相談が利用組織のトップからではない場合は、一旦、全部見送ってみました。この結果、2つのことが起こりました。

1. リーダーやマネジャー層が説得してくれて、再度トップ経由の依頼がくる。
2. 他社や他組織の成功事例を聞いて、トップ経由の依頼がくる。

特に2は、他社事例の持ち込みや、成功体験を偏らせるなどでOps側からも仕掛けられます。また、トップからの依頼であれば、その後の協力もスムーズに得られます。

おわりに

ツールの導入は便利になる一方で、導入時の労力も、それなりにかかってきます。かけた労力が無駄にならないよう、しっかり運用定着までもっていきたいものです。
最後まで読んでいただき、ありがとうございました！少しでも、みなさまのツール導入が成功するヒントになれば嬉しいです。