こんにちは、hachi8833です。

今回は、弊社の社内ドキュメントリポジトリとして導入を検討した以下のサービス/アプリケーションの比較とその結果をお送りします。リストは順不同です。

• Qiita:Team
• esa.io
• Confluence
• DocBase
• Crowi

背景

弊社では従来、PukiWiki（バージョン 1.4.7）を長年社内のドキュメント保存場所として利用してきましたが、次のような問題が生じていました。

PukiWikiのマークアップ言語があまり使いやすくない

好みの問題もあるかと思いますが、PukiWikiのマークアップ記法は今となっては後述のMarkdownと比べて決して使いやすいとは言えません。

注: “␣”はスペースを意味します。

特にPukiWikiを書く頻度が下がると、更新のたびに書き方をググって思い出すこともしばしばです。

ドキュメントが長くなってメンテしづらい

PukiWikiを含む従来のWikiではドキュメントを比較的自由に構成できるので、ともすると長大な目次、長大な本文ができあがってしまいます。こうなってしまうと後から分割するのも面倒ですし、本文以外に目次もメンテナンスしなければいけません。

表示のレイアウトが崩れることがある

PukiWikiを含む従来のWiki記法（残念ながらWikipediaのMediaWiki記法も含め）は、なまじレイアウトをある程度コントロールできるために記法が複雑になり、気をつけて書かないとレイアウトが崩れることがあります。

Markdownについて

GitHubやGitLabで標準採用されたこともあり、近年はMarkdown記法が急速に定着しつつあります。

Rails開発者も、rails newした後真っ先にREADME.rdocをREADME.mdに変更することが普通になりつつあります。

Markdownの最もありがたい点は「レイアウトを意識しなくてよい」ところだと思います。

Markdownはドキュメント作成に特化して記法を大胆に絞り込んだことで、ずっと覚えやすくなっています。そしてレイアウトについてはMarkdownでは原則扱わず、CSSやHTMLタグの直接記述に任せるという潔さが成功の一因だったと感じています。

Markdown記法で属性を扱うのはあまり簡単ではありませんが、無理して属性を追加するより、属性を追加しなくて済むようCSSや運用でカバーするのがよいと思います。

ドキュメントリポジトリに求められる条件

以上のような理由から、PukiWikiの後継となるドキュメントリポジトリ・コラボレーションサービスを検討しました。

必須条件

1. Markdownが使えること

BPSのエンジニアであればGitLabでのMarkdown記法が定着しているので、新しい記法を覚えずに済むのは大きなメリットです。PukiWikiは登場してから長いので、PukiWiki記法を知らない人も増えています。

2. 投資に見合う効果が得られること

こうした要件は組織によって異なりますが、BPSの場合はドキュメントの生産性向上や、検索/共有などの円滑化といった「目に見える」効果を期待しています。料金も重要な要素です。

3. 導入・運用が容易であること

BPSの場合、通常業務になるべく負荷をかけずに導入できるサービス/アプリが求められます。

4. データの保全、バックアップ（インポート/エクスポート含む）が可能であること

当然ながら、データ喪失回避のためのサポートは重要です。また、今後サービスを移行することになった場合のインポート/エクスポートも保険のために必要です。

5. アクセス制御ができること

（更新しました） ドキュメントの公開範囲をある程度自由にコントロールできる機能が求められます。案件にかかわっていないメンバーに見せないようにする機能や、有料ユーザー以外のユーザーに一時的に共有する機能は欲しいところです。

その他あるとよい機能

• 2画面編集（編集とプレビューを同時に行える）
• Slackなどとの連携機能
• スライド機能
• 簡易共有機能

ドキュメントコラボレーションサービスの比較

以上の条件を念頭に、PukiWiki後継となるドキュメントコラボレーションサービス/アプリケーションを比較してみました。限られた時間の中での検討なので、すべての条件を検討したわけではないことをお断りしておきます。

また、価格については変動が予想されるためリンクのみ示しました。

Markdownの支援機能（自動補完など）や、Slackなどのチャットアプリとの連携やAPI機能はどのサービス/アプリにも備わっていました。

Qiita:Team

Qiitaサービスをコラボレーション用に拡張した有料サービスです。

• Qiitaと同様の操作・表示が利用できる
• Qiitaのアカウントが必要なので、現在Qiitaを使っていない社員にとってやや敷居が高い
  • Qiitaに慣れているユーザーには扱いやすいと思います
• 個別のドキュメント作成というニュアンスが強く、複数プロジェクトの扱いが後づけに感じられる
  • やや運用イメージが合わないかも
  • このあたりは今後改善されそうです
• 課金は人数単位（参考: 価格表）

esa.io

esa LLCが提供するドキュメントコラボレーションサービスです。

• アイコンがかわいい
• ユーザーインターフェイスの操作性がかなりよいと感じられる
  • パスの付け方が独特（タイトルの先頭に2階層まで付けられる）
• スライド機能がある
• チーム内のドキュメントはすべて内部で共有するポリシーのため、内部でアクセスを制限できない
• 課金はユーザー単位（参考: 価格表）

Confluence

Atlassianが提供する総合的なチーム向けドキュメントサービスです。

• 歴史が長く、実績が多い
• 非常に多機能、かつ多くのプラグインで機能を拡張できる
  • プラグインをあまりたくさんインストールすると不具合につながることがある
• JIRAなどの同社の他サービスとの連携に強い
  • 高機能な分、導入教育などにコストをかける必要がある
• Markdownがネイティブでは装備されていない（プラグインで利用できるが、2画面プレビューなどが使えない）
• 価格は人数単位（参考: クラウド版の価格表）
  • クラウド版以外に、ソースコード提供を受けてオンプレミス設置できる契約もあり

DocBase

株式会社クレイが運営するドキュメントコラボレーションサービスです。

• 割と地味だが、必要な機能(タグなど)はひととおりある印象
• スライド機能はなし
• グループを複数作成でき、ドキュメントはグループ内限定で公開される
  • チーム全員に見せたり、リンクを渡して見せることもできる
• 価格は人数単位（参考: ヘルプ: 価格改定のお知らせ）

Crowi

旧: 株式会社クロコス（現在はヤフー株式会社に合併）で開発されたWikiです。

• 今回検討した中で唯一オープンソースベースのMarkdown Wiki(Node.jsベース）
• Docker Hubが使える
• チーム内のドキュメントはすべて内部で共有するポリシーのため、内部でアクセスを制限できない
• 機能はこの中では最も少ないが、単にPukiWikiを置き換えるのであれば選択肢としてあり

結論

検討の結果、BPS社内の一部チーム限定でDocBaseをしばらく使ってみることにしました。選定のポイントは以下でした。

• 必要な機能がひととおりある
• グループを複数作成し、ドキュメントの公開をその中のみに限定できる（チーム全員に見せることもできる）
• 必要であればアカウントがない人にもリンクを渡して見せることができる
• 価格が今の社内/チームの規模に対して手頃

esa.ioとどちらを選ぶかで最後まで迷いましたが、グループ限定の公開機能の有無が分かれ目となりました。DocBaseには残念ながらスライド機能はまだありませんが、今後のアップデートに期待したいと思います。

Confluenceは社内に経験者がいるのと、高機能かつ価格的にも魅力的だったのですが、準備と導入教育を十分に行わないと機能を活かしきれないことから、今回は見送りました。

弊社の場合、既にSlackの導入が成功を収めているので、Slackによるリアルタイムコミュニケーションと、GitLabやRedMineなどによるプロジェクトごとのドキュメントの中間に位置するような静的なドキュメントの管理・共同編集が行えるプラットフォームを求めていましたが、DocBaseを含め、今回検討したサービス/アプリはその点についてはおおむね条件を満たすことができたと思います。

今後欲しい機能

Googleドキュメントのようなコメント・レビュー機能

今回検討したサービス/アプリには、Googleドキュメントのような文字単位のコメント・レビュー機能を備えたものはありませんでした。

ドキュメント単位のコメントだと細かな点を指摘しにくく、指摘された場所を探すのが面倒になりがちです。

Googleドキュメントのコメント・レビュー機能はドキュメントに直接記入でき、自動的にメールが送信されてすぐ確認でき、承認してすぐ反映できるのが大きなメリットです。

また、ドキュメントに直接コメントする方法なら、「何行目のxxは〜だと思います」といった記述なしで修正内容を直接記述できるのも無視できません。ちょっとしたことのようですが、Slackのおかげでメールタイトルみたいなものを入力しなくてよくなったように、修正内容だけを入力しても大丈夫なつくりになっていると、利便性が大きく向上すると思います。

ユーザー管理の一元化

個別にユーザー管理しなければならない社内サービスが増えると、地味に負担になります。

Active DirectoryやLDAP連携といった方法も考えられますが、昨今であればGoogleアカウント（G Suite）ベースでユーザーを管理できると助かります。

G Suiteベースなら画像やドキュメントもGoogleドライブに配置することもできそうですが、URLを指定して画像や添付ファイルをページに埋め込むにはGoogleドライブ側で「リンクを指定して共有」（リンクを知っていれば誰でも見えてしまう）にしないといけないという問題が立ちはだかっています。これについてはGoogleドライブのフォルダアクセス権を反映してURLを限定共有できるよう、まずGoogle側で対応してもらう必要がありそうですね。

今後、こうした点が改良されたMarkdownベースのソリューションが出現すればまた移行するかもしれません。

追伸: 導入後

現在は社内の1チーム内で限定的に運用中ですが、ドキュメントが毎日のようにモリモリと作成・更新されています。やっぱりMarkdownで書けるのはうれしいです。

さらに追伸: 現在は社内標準となりました。