システム開発の現場改善記 - esa.io 導入編

f:id:tbpg:20150520001217p:plain

概要

esa.io 導入の過程について

経緯

世の中のシステム改善の情報はよく見かけるが、
自分も改善しようとした時に、どのようにしたらいいか分からない 。
実際の改善をするまでの 細かな過程などを参考にしたい 、という相談を受けました。

同じような情報が欲しい、という方が他にも居るかもしれないので
私の業務の改善実績を公開することにします。
需要がありそうなら、シリーズ物として地道にアウトプットして行こうかと思います。

ポイントとして、私自身は優秀なハッカーや優れたマネージャーなどではなく、
ありふれた開発者の一人 に過ぎません。
私の性格については、引っ込み思案で内向的。
どちらかという消極的で、お世辞にもコミュニケーションが上手なほうではありません。
勉強会に行って、 懇親会でほとんど発言せずにしょんぼり して帰ったり、
RubyKaigi のオープンスペースの昼食が怖くて、 豪華なお弁当を放棄してぼっち飯を食べにいく くらい
の人見知りだったりもします。
こと業務に関しては、 妥協が嫌いで局所的に積極性を発揮する ときがあります。
そんな私でもできることがある、という点をお伝えしたかったのです。

現状、業務上の情報を社名公開でアウトプットする許可は貰っていないので、
社名などは伏せさせていただきます。
大分先になりそうですが、会社の業務の中で開発ブログを公開する計画はあるので、
楽しみにしてくださる方はお楽しみに！

前提

私は現在とあるシステム開発会社に在籍しています。
この会社はシステム開発会社ですが、実質親会社のシステム部門です。
開発するシステムは主に親会社向けのシステムです。
※まれに、親会社のお客様向けのシステムを開発することもある

改善に関しては、まず上長に承認を得た上で、
社長の承認を得る必要があります。
上長は、 説明に納得できれば大抵承認してくれます 。
社長の承認を得るには、導入のメリット・費用対効果の裏付けとなる資料が必要 です。
効果は大枠で納得できるものであれば良く、厳密な金額まで落とし込む必要はありません。

親会社まで大きな影響を及ぼす決定事項については、親会社の社長・役員の承認も必要になります。

※1. あくまで私の環境での成功例です。1例として参考になれば幸いです。
※2. 社内の esa の情報は公開できないのでキャプチャ等は無しです。ごめんなさい。

1. 改善すべき問題点の臭いを嗅ぎ取る

今の会社に入社し、すぐにチームの ナレッジが暗黙化 されており、 技術の情報・プロジェクトの情報・手順書
などの資料がほとんどないという点に気づきました。

わずかに存在する資料も Excel であったりテキストファイルであったり、
ネットワークフォルダ内にあったり、リポジトリのなかにあったり、
フォーマットや置き場が統一されていませんでした。

ナレッジ管理についてチームメンバーに確認したところ、
私の入社前、チーム内では Confluence にナレッジを蓄えることに挑戦したが、 継続しなかったそうです 。

Cofluence が使いにくいと感じたこと
チーム内にナレッジを可視化する習慣がなく、始めてみたものの継続しなかった

などが原因です。
以降、ナレッジは各自の頭の中と、断片的に存在する資料のみになっていたそうです。

2. ツールに関する情報収集を行う

まず、 Web でどんなナレッジ管理ツールが存在するか調査しました。
各ツールが持つ機能をリストアップしました。

3. ツールの絞り込み

少人数で開発をしているため、 運用で楽をできるクラウドのサービス を軸に選ぶことにしました。
また、 Web の文書作成は Markdown が標準的になってきているため、 Markdown のサポートを必須 としました。
運用が定着しなかった Confluence は候補から除外し、以下が候補になりました。

Qiita:Team
DocBase
esa.io

無料利用期間を利用し、すべてのツールを試しました。

4. ツールの選定

どのツールも基本的な機能はほとんど変わらず, 必須と思われるような機能は横並びで備えています 。
価格帯もほぼ同じ です。

多少機能面で差がある箇所については

esa.io は

カテゴライズが容易
スライドを簡単に作成できる
テンプレート機能
ゆるい雰囲気
とても使いやすい UI

などが特徴的。

DocBase は

チームでの利用に特化した機能
メモの埋め込み
固めの雰囲気

などが特徴的。

Qiita:Team は悪くないのですが、 Qiita:Team しかない機能というのは
見当たりませんでした。（見逃しているかもしれないけど）

最終的に、

機能面の特徴や UI の使いやすさ
ドキュメントを記述する敷居を下げる工夫
- ゆるい雰囲気
- WIP システム
運営のユーザーサポートの質の良さ
言葉には言い表しにくい使い心地の良さ

を決め手に esa.io の利用を決定しました。
敷居を下げる工夫、については Confluence の導入失敗から得た反省点を元にした選定基準です。

Tbpgr Blog - esa.io に feedback を送ったら爆速で取り込まれた話
Tbpgr Blog - esa.io と DocBase を比較してみた

5. リスク管理

esa は 2 人( たぶん )で運営されており、まだサービスがスタートしたばかり。
そのためサービスがなくなってしまった場合のリスクについて社内で説明する必要がありました。
この点については、投稿データが他のツールと同様 Markdown 形式であり、
Export 機能も用意されているため、万が一の際の移行コストは小さく問題ないことを確認できました。

6. 社長の承認を得る

説明のための資料を作成し、プレゼンテーションを行いました。
メリット、デメリットの説明と運用コストを上回る利益があることを説明しました。
また、良さを伝えるために実際に どのように運用に役立っているか を
実務のオペレーションを見せつつ 説明しました。

特に反対もなく承認を得ることができました。

資料の内容

運用に関するナレッジが暗黙化されている状態による損失
運用に関するナレッジが共有されたことによって防ぐことができる損失に関する説明
技術に関するナレッジが共有されたことによって新たなに生み出される価値に関する説明
esa のサービスが終了した場合のリスクに対する対応方法があることの説明

7. レールに乗せる

さて、ここまでやって運用が定着しなければ Confluence 導入時の二の舞 です。
以下を行いました

先導者として、 すべての機能を試し、便利なものはどんどん実導入 して事例を作った
- 後続者は真似するだけなので敷居が下がる
- 「このツール便利！」を可視化
REAMDE ページに esa.io に関する情報を提供している外部サイトのリンクを追加
- esa に関わる情報をより収集しやすくする
率先してナレッジを可視化 。他メンバーの 10 倍の記事を作成
- プロジェクトの情報
  - 自分が関わるプロジェクトの情報はすべて可視化
- Confluence のナレッジを移行
- 技術情報
- 手順書
Emoji を多用し、 ゆるさ・楽しさ を演出
- Qiita - Tbpgr - esa.io に emoji 見出しの投稿テンプレートを作成する
スライド機能 を実務で活用し 便利さ を実演
- Qiita - Tbpgr - esa.io で、 Markdown を使ってスライドショーを作成し、内部公開する
- Qiita - Tbpgr - esa.io で、 Markdown を使ってスライドショーを作成し、外部公開する
同時に導入した Slack に通知を流し、記事が追加されていることを通知
- Qiita - Tbpgr - esa.io の通知を Slack で表示するため、 Webhooks の設定を行う
Template を増やし、投稿の敷居を下げる
- Tbpgr Blog - esa.io で新たな概念を追加する手順
esa へのフィードバックを積極的に送り、 esa をより使いやすいツールにしてもらう
- esa はフィードバックが早く、フィードバックを受け入れてもらえる頻度が高い！