ツール普及のための手段の検討

きっかけは？

新しいツールが出てきたとき、読者の皆さんは何をきっかけにそのツールを使われ始めますか？私は次の4つを考えます。

1. 今よりも効率が良い
2. 今まで不便だった事が解消できる
3. 有名な人が使っているからその流れで
4. 周りが使っているので使わないと業務が滞る

1は、今まで不便はしなかったけれど、導入する事でより作業がはかどるものです。例えば、MySQLTunerが挙がります。深いMySQLの知識や変数名を理解しきらずとも、チューニングの際に重要となる指標を確認する事ができます。

2は、作業でとても不便をしていたけれど、導入する事で解消されるものです。例えば、gulpです。複数の違う閲覧環境を相手に、効率よくWebページの実装が可能になります。

3は、ミーハーなのって悪い事ですかね？ひょっとしたら、使っているうちに1か2について発見する事があるかもしれません。私がChefに目を向け始めたのは2012年頃でしたが、それがきっかけでした。

4は、重い腰を上げて...ということでしょうか。とはいえ、珍しい話ではありません。既に、1, 2の目的を満たせると考えた人が、ツール利用を業務フローに組み込んで、チーム全体で使うのでしょう。

なお、1と2は、人によって違う見解になる事もあります。共通する事は、ツール導入の動機であることです。1〜4以外にもあるかもしれません。

ツールを普及させようとするならば、この4つのいずれかを訴えかける必要があります。何も理由が無ければ、使われる事もありません。また、よほどアンテナが高い(※2)人がいないかぎり、普及させたい側から積極的に行動する事が求められます。なぜなら、人それぞれ関心事というのは違っているからです。

どうやって？

では、どのように関心を深めてもらえれば、普及させる事ができるのでしょうか。

1. 「便利！便利！」と社内チャットやブログで呼びかける
2. 業務フローに組み込む
3. ハンズオン

1は、最も始めやすい手法です。便利そうな雰囲気と実際に使った感想を継続的に述べる事で、「おお、これいいかも！」というフォロワーを増やすのです。ただ、現状重視の人が多い環境だった場合、振り向いてもらえない事も多々あります。辛い所です。

2は、強制的に使えるようにしてしまいます。一気に普及はするでしょうし、良さを理解してもらえれば定着するはずです。しかし、導入時における一人一人の心理的抵抗、特にやらされている感が出てしまいやすく、結果として普及しない恐れもあります。心理的抵抗を解消する周到な準備が求められます。

3は、存在を知ってもらって、使ってもらって、そして良さを実感してもらう事で、きっかけの1または2を広めます。そして、ツールを積極的に使ってもらえるような流れを作ります。使った人が「あれはよかった」と触れ回ってもらえれば、1との相乗効果も出て尚良しです。ただし、ハンズオンを開催する人は準備が必要になります。

今回は、3に焦点を当てます。自分で積極的に、そして周囲の心理的抵抗をよりよくクリアするために、私はハンズオンが良いと考えたのです。

ハンズオンの流れ

全体像

それでは、ハンズオンの流れを組み立てて行きましょう。言い換えれば、布教活動をどうするか？です。

私は、自分自身が開発を担当したツールを普及させる際、次の流れを作りました。

1. このツールを使うと何が嬉しいかを定義
2. ハンズオンを受ける人の技術スキルの最低水準を設定
3. 日程調整
4. 告知
5. 資料作成
6. ハンズオン環境の整備
7. 当日
8. 振り返り

では、個別に説明、場合によっては私の取り組みを例示します。

このツールを使うと何が嬉しいかを定義

先ほどのきっかけの1 and/or 2に該当する何かをはっきりします。これがはっきりすると、ハンズオンを受けてもらった人のゴール設定を明確にできます。

私が開発を担当したツールの1つに"hb-agent"という構築・監視設定・ドキュメント作成を自動化するツールがあります。この時は「構築時間を短縮: 数時間→10分」と定義しました。

ハンズオンを受ける人の技術スキルの最低水準を設定

説明や資料を作る際の技術レベル設定の際に必要です。

例えば、コード記述支援用のvimのプラグインのハンズオンをする際に、vimの使い方を全く知らない人か、問題なくテキストの編集ができるかで、話さなくてはならないレベルが全く違うのは想像していただけるかと思います。では、自分自身が紹介したいツールを使うにあたって、どのような知識が必要か？確認して下さい。

当社は、一定の基準の上で職位が決まっています。"hb-agent"のハンズオン実施時は、障害対応時に意思決定ができるほどに独り立ちしている水準の人以上を対象にする事としました。

日程調整

意外に難しいのが日程調整です。

現場のリーダー格の人と調整からはじめていきましょう。また、回数は1回ではなく複数設けます。これは、外出やシフトによって出席できる日が限られる人がいるためです。

会場も早めに確保しましょう。1〜1.5時間、確保します。一度に指導する参加者は、私は1回あたり4〜5人程度を目安にしています。会議室のサイズと、指導する際のマンパワーを考えた末、この程度にしています。

告知

おおっ、先に告知！？と思われるかもしれません。これは、日程を決めてしまったほうが、ハンズオンをやるにあたっての覚悟を持てるからです(笑)。なお、心配な方は後述する「ハンズオン環境の整備」の後でも良いでしょう。

お知らせの際は、私は次の情報を盛り込むようにしています。

• 概要
  • どんなツールのハンズオンなのか。そして、これをやるとどんな事が良くなるか・解決するか。
• 日時
• 開催場所
• 持ち物
• 出席登録方法
  • グループウェアを使って参加者自身で登録してもらうのが手っ取り早いです
• 質問等の連絡先

回によって、人の集まりがよくなかった事がありました。その時は、理解があったチームリーダーに、シフトが空いている時間にチームメンバーの受講日程を設定し、受けてもらうよう強く促してもらってもいました。

資料作成

肝心な所です。私は、ほぼ全てのハンズオンにて、以下の目次に沿って資料を作成しています。全ての説明が1〜1.5時間で終わるように組んでみましょう。それ以上ですと、参加者が疲れてしまいます。

• 目的とゴール
• 注意点
  • ハンズオン時にやってはいけない事があれば説明します
• ツールの説明
  • 何ができるツールか
  • どのような構造になっているのか
  • どのような操作が必要なのか
• ツールを使う流れ
  • 作業手順を説明
• ハンズオンでやる事
  • どの作業手順を学ぶのか
• ハンズオン
• 実務上の注意点
  • 実際に利用する場合に気をつけないといけない部分があれば説明します
• まとめ

注意点として、ハンズオンの手順は 必ず自分で流してみる ことです。もしミスがあると、ハンズオン当日に混乱が生じてしまいます。

ハンズオン環境の整備

インストール型のツールの場合、既にインストールされている状態を作っておくと、操作説明に集中しやすくなります。そのために、ハンズオン当日用の個々人向け Vagrant, Docker イメージを組みます。また、イメージを組んでおけば、ハンズオン後に自習をされる方が気軽に学び直す環境を提供できる事にもつながります。

当日

十分に準備をしたら、あとは説明だけです。1〜1.5時間、しっかり時間を使って説明しましょう。また、質問は随時受けられるようにしましょう。疑問が解消されることで、より理解が深まる事が多々あるからです。

振り返り

ハンズオン当時に問題が出た場合は、素早く改善を行いましょう。資料の見直し、イメージの組み直し、進行の方法、色々あるかと思います。また、受けられた方のその後を、あまりプレッシャーにならない程度に追いかける事も大切です。ハンズオンの効果があったのか、検証する事ができるからです。

実際に取り組んでみた結果

今まで何回か実施してきているのですが、いずれも受講後は好評でした。初めてハンズオンを実施した"hb-agent"というツールの普及は半年かかりましたが、その後は2〜3ヶ月で普及するようになりました。その中で、同僚から評価が高かったのは次の点でした。

• 繰り返す際の効率が上がる
• 単一でも時間がかかる仕事(ドキュメント作成や設定ファイルの作成)から解放される
• ミスが減らせる

そうですね、想定していたゴールにたどり着けていると考えて良いと自分自身で振り返っています。それ以上に嬉しいのは、同僚同士でツールの良さを伝えてくれたり、社内GitLabにIssue, Merge Request(Pull Request)を入れてくれたりする方がいる事です。ハンズオンはあくまできっかけ作りに過ぎず、もし本当に必要なツールならば自分自身でがんばり続ける必要は無く、自然と広がる事を実感しました。

副次的な効果もありました。プログラムを書けるようになると、反復・定型の作業を容易に自動化することを知ってもらうきっかけをつくることができたのです。最近は、プログラミング部の活動で多くの同僚がプログラミングの力を鍛えているようです。

おわりに

ここまで、ツール普及のためのハンズオンの話として、「ツール普及のための手段の検討」「ハンズオンの流れ」そして「実際に取り組んでみた結果」の3点をお伝えしました。目的とゴールをはっきり持つ事、そしてそれが伝わればあとは自然と普及する事を知っていただけたのではと思います。

「何でこんな便利なツールがあるのにみんな使わないんだ！」とか「作ったのに使ってもらえない...」と嘆きたくなる事は私にもあります。ただ、手をこまねいていてはどうにもなりません。そして、いきなり全員というのはやはり難しいです。そんな時は、身近にいる自分と考え方が近い同僚をうまく巻き込んで、その人から参加してもらうのはどうでしょうか。少しずつ、輪が広がるはずです。

最後に。取り組まれた方は、取り組んでみた後の 1ヶ月、半年、1年という区切りで振り返ってみて下さい。

それでは皆様、ごきげんよう。

備考

• ※1: 当社のInfrastructure as Codeの取り組みの詳細は、同僚の @rrreeeyyy さんがOSC(オープンソースカンファレンス)で発表した話をご覧ください。

• ※2: 当社はアンテナが高い同僚が比較的多いと感じますが、それでも言えば単に振り向いてくれる訳ではありません。