本記事は「Silbird Advent Calendar 2017」の9日目の記事です。
https://qiita.com/advent-calendar/2017/silbird
Silbirdでは社内のドキュメントについてQiita:Teamを3年間利用していましたが、2017年10月よりCrowiを利用しています。
そこで、なぜCrowiに移行することになったのか、良かった点悪かった点をまとめていきます。
前提
- Webサービスの開発・運営事業を行っている
- 30名程度の規模の会社
- 3年で生まれた記事377記事
- 記事を書くのはほぼ固定のメンバー3～4名
- エンジニア、プランナー、デザイナー、イラストレーター、バックオフィス（うちエンジニアが10名程度
Qiita:Teamの主な用途
- エンジニア、プランナー、デザイナー向けの初期セットアップマニュアル
- エンジニア向けTips
- 各サービスの仕様書
- 運用マニュアル
- 勉強会の参加レポート
移行の理由
発端
サービスを運用する上で、施策や改修することの目的を理解することはとても大事だと考えています。
リリースを控え社内でテストをしているサービスを見ていると、サービスや施策の意図から少しずれたページデザイン、実装、画像がいくつか散見されました。メンバーにヒアリングを行っていると、下記問題のために仕様の意図・目的についての共有が十分ではないのではないかという懸念が生まれました。
- GoogleDocsのスプレッドシートを使っておりフリーフォーマットであるが故に、人によって書き方が異なる
- 意図、目的がどこに書いてあるかわからない、または口頭でのみ伝えられていて資料には記載されていない
- 仕様書がGoogleDriveの深くに眠っているため、担当者以外がどこにドキュメントがあるか知らない
仕様や企画意図・目的については制作担当者だけでなく、社内でテストを行うメンバーも含めてすぐにアクセスできる場所にある必要があるため、仕様毎に目的と関連する資料へのリンクを記載したシンプルな資料をドキュメント共有サービス上に記載することで解決できないかと思い立ちました。
その時社内で利用していたサービスがQiita:Teamです。
Qiita:Team運用上の問題
目的の正しい理解と共有のために社内ドキュメントサービスを利用するところまではよかったのですが、その時社内でのQiita:Teamは問題を抱えていました。
簡単に言うと日頃から利用されるサービスではなく、何かあった時にたまに見るものであり、記事の投稿を行っているメンバーもほぼ固定されていました。
つまり、社内のメンバーがすぐにアクセスできる場所ではなかったのです。
これはQiita:Teamに問題があるというよりも運用に問題があったと考えています。
今までの経験上なにかのツールを導入するときは、普及するエバンジェリストの存在が不可欠と感じていますが、Qiita:Teamにおいてはその存在の欠如により社内に浸透しなかったことが大きな要因だったと思います。
加えて費用対効果に縛られすぎて、エンジニアを中心としたQiita:Teamのアカウントを積極的に記載するメンバーにのみ配布し、全メンバーに配布しなかったことも問題としてあげられます。
書こうと思い立ってからアカウント発行を依頼して書き始めるのではなく、メンバー全員がいつでも自由に参照と書き込みの権限を持っている状態がスタートラインでありここは大きく反省すべき点でありました。
Silbirdでは現状がうまくいっていなければ積極的に変化を起こそう。ある程度まで考えてメリット・デメリットを踏まえてやる価値があるのならやってみよう。やってダメならまた別のアプローチを考えよう。という少し体当たりな考え方があったことと、他のMarkdownドキュメント共有サービスにも興味があったので移行することを決めていくつかのサービスを調べてみました。
移行先に期待すること
Qiita:Team運用上の問題も踏まえて、移行先に期待することは下記としました。
- 社内のメンバー誰でも読み書きができること
- しかしできればコストも抑えたい
- アクセスが用意であること
- 気軽に投稿できること
- Markdownでかけること
- GoogleDrive+Docsのようにフォルダ階層を意識して関連する過去のドキュメントへのアクセスが容易であること
- エンジニア以外も利用することからタグの運用はハードルが高いとの懸念
上記条件を整理していて真っ先に浮かんだのはesaです。
実際に試してみてポリシーやUI、書き心地もよくすばらしいサービスでした。Qiita:Teamはメンバー数が増えていくにつれてユーザー一人あたりの金額が増えていくところが気になっていましたが、esaは¥500/1ユーザーと非常にわかりやすい価格であったことも好印象でした。
Qiita:Team(2017/12/09時点)
esa(2017/12/09時点)
そしてCrowiを発見
しかし他にも調べているうちにCrowiにたどり着きました。「これ良さそうじゃない？」と社内に話題を出してみたところ弊社にいる闇のアルバイト(通称:忍者)1がさらっとAWSLinux上に構築していました。2
実際に利用してみて、使い勝手が必要十分であること(多機能であることは重要視していない)、OSSなので利用しているうちに気になったところはフィードバックや貢献が行えること、なにより無料であることが決めてとなり導入しました。
Crowiを使ってみて
SilbirdでCrowiを使い始めて二ヶ月が経過して見えてきたこと。
既存の問題に対するAnswer
-
エバンジェリスト不在問題
→ ここは提案をした自分がしっかりとやる、人を巻き込む、当たり前のことだけどやれていなかったという反省でしかない_(:3」∠)_ -
社内メンバー誰でも読み書きができること
→ クリア -
しかしできればコストも抑えたい
→ 無料。クリア -
アクセスが容易であること
→ Google認証で快適 -
気軽に投稿できること
→ 自分のユーザーページが存在し、メモ書きから始められる。また書き方がわからないときなど社内Slackに専用チャンネルを設けることで即座に回答がもらえるフォロー。 -
Markdownで書けること
→ クリア -
GoogleDrive+Docsのようにフォルダ階層を意識して関連する過去のドキュメントへのアクセスが容易であること
→ リストビューというビューがあり皆層状に表示・アクセスが可能。クリア
よかったこと
- ドキュメントのテンプレート機能を利用して仕様の目的が明示的に記載されるように
- 重要な記載事項についてはテンプレート化を行うことによって、記載漏れを防ぎ、また作成される場所についても指定できるためミスが生まれる余地が大幅に軽減された
- 投稿数、ユニークユーザーが増加
- 自分のページが存在するためQiita:Teamより投稿のハードルが下がったのか、タスクメモを書く人、自分用のドキュメントリンク集を書く人、ポエムを書く人、日報を書き始める人、様々な種類の投稿が見られるようになった
Qiita:Teamからやや不便になったこと
- Qiita:Teamが技術に特化したドキュメントだったこともあり、プログラムコードを載せる場合の書き心地は低下。(主にコードブロック)
- タブや画像挿入時の挙動がQiita:Teamを含む有料のドキュメントサービスに比べて安定していないためテーブルなど操作性がやや低下
今後の課題
社内のドキュメント共有サービスとしては一定のスタートは切れたと考えていますが、ここで油断してエバンジェリストを放棄するとまた同じ道を辿ってしまうので、引き続き利用状況の確認と、効果的な使い方をしている例の共有を行っていきます。
同様にCrowiを利用することが目的化しないように、Crowiを書くことに時間がかかって本来の業務の時間が十分にとれないなど、導入の目的を再周知しながら進めていきます。
おわりに
Silbirdと同じようにドキュメント共有サービスの選定や、使ってほしいのに使ってもらえない、といったことに頭を悩ませている会社様の一助になれば幸いです。
SilbirdでのCrowiの使い方やおすすめプラグイン等も紹介したかったのですが、長くなってしまうことと本題からそれてしまうので要望やネタがまとまったら別の記事でお目にかかれればと思います。
最後に、会社としてQiita:Teamを利用することはやめてしまいましたが、Qiita自体は良いサービスだと考えているのでこれからはQiita:TeamではなくQiitaとして利用していきます！