Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

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

f:id:tbpg:20150520001217p:plain

概要

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

経緯

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

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

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

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

前提

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

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

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

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

esa.io 導入の流れ

  1. 改善すべき問題点の臭いを嗅ぎ取る
  2. ツールに関する情報収集を行う
  3. ツールの絞り込み
  4. ツールの選定
  5. リスク管理
  6. 社長の承認を得る
  7. レールに乗せる

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 導入時の二の舞 です。
以下を行いました

メニューに戻る

無事ナレッジ可視化の慣習が定着・・し始める

現在はチーム内のみではありますが、 ナレッジ可視化の慣習が定着しはじめました
今の業務内容の都合上、ナレッジが多数公開されるような時期ではないため慣習の定着を断言できる状況ではありませんが、
概ね軌道に乗ったと言っても良い手応えです。

今後の組織改善時に、社内全体のナレッジ可視化・共有に着手する必要がありますが、
クラウドに保存できない情報もあることから esa を用いるか、オンプレで利用できる Wiki などを利用するか未定です。

GitHub Enterprise の esa 版、つまり esa Enterprise があれば多少高くても即決 なのですが。
esa の中の人、 超絶期待 してます。

補足

  • 各フェーズで上長へ相談しつつ改善を行っています

2015/05/20 22:40 追記

ブクマコメントにて、 Qiita:Team のメリットを教えていただいたので追記

  • Kobito を利用可能( Qiita:Team と連携可能なマークダウンエディタ )
  • API を利用可能

親記事