このページについて
この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。
想定する環境
この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント（仕様書や手順書など）を書けるようになっている環境を想定しています。
私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。
ルール：「更新され続ける」ページと「更新されない」ページをはっきり分ける
ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、このルールが徹底されている Wiki ほど「信用できる」と感じました。
具体的な実現方法はいくつかありますが、例えば、Wiki のホーム画面の上半分を「更新され続ける」ページへのリンク、下半分を「更新されない」ページへのリンクにします。以下は、ホーム画面の例です。
# 更新され続けるページ - [[用語一覧]] - [[サービス仕様]] - [[インフラ構成]] - [[アプリケーション構成]] - [[開発ルール]] - [[手順書]] - [[主要機能の解説]] # 更新されないページ - [[ミーティング議事録・資料]] - [[ユーザーストーリーごと（または機能ごと）の設計]] - [[リリース履歴]] - [[運用作業履歴]] - [[障害履歴]] - [[技術検討メモ]] - [[現在はメンテナンスされていないページ一覧]]
誤解を避けるために強調しておくと、これはWiki を「信用できる」ページと「信用できない」ページに分けよう、という話ではありません。信用できないことがはっきりしているなら、そのページは消したほうが良いでしょう。
そうではなくて、これは「完全に信用できる」少数のページと、「条件付きで参考にできる」多数のページに分けよう、という話です。以下では、説明のために、もう少し具体的な話をしてみます。
「信用できる」とは？
この記事で言う「信用できる」という形容詞は、「信用できる技術者」を指すときの「信用できる」と同じような意味だと思ってください。
私が知っている信用できる技術者を思い出すと、大抵以下のような長所を備えています。
- 専門分野について正確で詳しい知識を持つ
- わからないことは素直にわからないといい、必要な調査やテストを行って、あとからそれを補う
同様の状態を Wiki で実現したものが、この記事でいう「信用できる Wiki」になります。
「更新され続けるページ」については、そこを読むだけで正確な情報を知ることができて、読み手はソースコードを読んだりする時間を節約できます。
一方、「更新されないページ」については、過去のある時点では事実だった（あるいはその書き手が事実だと信じていた）情報ですが、現在では正しいかわからない情報です。その場合も、読み手は、条件付きでその情報を参考にすることで、調査にかかる時間を節約できます。
逆に「信用できない」とは？
上で挙げた信用できる技術者の長所をひっくり返すと、以下のように、信用できない技術者になります。
- 専門分野について、曖昧な知識しか持たない
- わからないことについても「○○に違いない」と断言する
大抵の Wiki は放っておくと、信用できない技術者に似た、信用できない Wiki になってしまいます。例えば、こんな感じです。
- 仕様ページに書いてある仕様が、その後の機能追加の際に更新されなかったために、現在の仕様と違う
- ローカル開発環境の構築手順書が、ゼロから動作確認されなかったために、他の人が試すと動かない
こうなると、普通の人は「ソースコードを読むしかない」、「実際に試してみるしかない」と判断して、その Wiki を避けてしまいます。信用できない技術者に、相談する人はいないですよね。
その社内 Wiki には、実際には役に立つ情報もあったかもしれないのに、全体の信用を失ってしまったために役に立つ情報まで読まれなくなるとしたら、それはもったいないことです。
ルールを運用するためのヒント
このルールをチーム全体できちんと運用するためのヒントを、いくつか挙げておきます。
ヒント(1)：「更新され続けるページ」は極力少なくする
このルールを採用する場合、何か機能をリリースするたびに、その機能に関連する「更新され続けるページ」はすぐ更新する必要があります。忙しい時期でもこのルールを守れるように、更新され続けるページは極力少なくしておいたほうがよいでしょう。
例えば、以下のような情報は、更新し続けるメリットが、更新作業のコストを上回ると思います。
- 用語一覧
- そのプロジェクト固有の用語一覧。主に、新メンバへの説明用。
- サービス仕様
- 顧客に提供するユーザーマニュアルや、サポート対象 OS・ブラウザの情報など。
- インフラ構成
- ネットワーク構成図や、システム構成図、IP アドレス一覧など。
- アプリケーション構成
- コンポーネント一覧、バッチ一覧、データベース定義書など。
- 開発ルール
- そのプロジェクトで採用する開発プロセス、開発用ツール、コーディング規約、テスト基準など。
- 手順書
- システム構築のための手順や、日常的な運用作業の手順など。
- 主要機能の解説
- そのプロジェクトで特に難しい機能や、わかりにくい機能の理解を助けるための解説記事。
ヒント(2)：更新し続けられないと判断したら、「更新されないページ」に移す
理想的には、「更新され続けるページ」はできるだけ多いほうが良いです。ただ、開発が多忙になったり、逆に開発が一段落して開発者の人数が減ったりすると、更新にかけられる時間は減ります。
そういう場合は、どのページを残すかチーム内で議論して、更新しきれないページは「更新されないページ」に移しましょう。Wiki のページ数よりも、「その Wiki は信用できるかどうか」のほうを重視すべきです。
例えば、以下の階層にある「機能Aの解説」ページを最近更新できてない、と気付いたとします。
- 更新され続けるページ
- 主要機能の解説
- 機能Aの解説
- 主要機能の解説
この場合、そのページを「更新されないページ」以下の階層に移す、という具合です。「機能Aの解説」ページの先頭（「このページについて」欄）に、更新できなくなった時期とその事情を書いておくと、読み手の助けになるでしょう。
- 更新されないページ
- 現在はメンテナンスされていないページ一覧
- 機能Aの解説
- 現在はメンテナンスされていないページ一覧
ヒント(3)：「更新されないページ」を「更新され続けるページ」に格上げしたいときは、必ず書き換える
更新されないページを書いているうちに、分量が多くなり、内容も充実したように思えるので、「更新され続けるページ」に格上げしたくなることがあります。例えば、以下のような場合です。
- ある機能の設計に関するページが、その機能に関するよいまとめに思えるので、主要機能の解説ページに格上げしたい。
- ある障害の原因を特定するためにソースコードを調査したときのメモが、ソースコードのよい解説に思えるので、主要機能の解説ページに格上げしたい。
しかし、元々これらのページを書き始めた目的は「主要機能の解説」ではないため、余分な情報が多く含まれている可能性が高いです。分量が多いほど更新が大変になるので、元のページとは別のページを作り、更新し続ける必要がある部分だけ残して、リライトしたほうがよいでしょう。
また、そもそも、有用な情報をすべて「更新され続けるページ」にする必要はありません。「更新されないページ」のなかに「技術メモ」のようなカテゴリを作り、そのなかに「2017年1月時点の技術メモ」のような形で残しておくという方法もあります。
ヒント(4)：ルールを守るための責任者を立てる
上記のルールを徹底するためには、ある程度の強権が必要になります。
例えば、チームメンバが以下のようなことを始めてしまったときに、誰かがあるべき状態に戻す必要があります。このような行動は、各人の自主性に任せていてもなかなか防げません。意見の衝突が起こるからです。
- 「自分がよく使うページだから」という理由で、ホーム画面にリンクを書き足す。
- 「誰かが更新すべき情報だ（自分は更新しないけど）」という理由で、「更新され続けるページ」にページを足す。
- 自分が必要だから更新し続けているページがあるが、責任を押し付けられたくないので、「更新されないページ」の中に残し続ける。
このような衝突を解決するために、ルールを守るための責任者をチーム内に立てて、その責任者は「このルールを守るためであればどのようにページを編集してもよい」と明言しておくのが良いと思います。メンバから異論がある場合はその責任者を中心に議論し、ときどき細かい運用を見直します。
この責任者は強権が必要で、かつ Wiki のほとんどすべての編集にざっと目を通す必要があるため、チームリーダが兼務するのが一番良いと思います。それが難しい場合は、簡潔な文章を書くのが得意な人を任命するのがよいでしょう。
まとめ
今回は、信用できる社内 Wiki をつくるために、私が個人的に実践している基本的なルールをご紹介しました。
このルールの目的は、「読み手が Wiki に期待するレベルを適切にコントロールすることで、読み手が Wiki に幻滅し、無視してしまうのを防ぐこと」です。Wiki のページを「完全に信用できる」少数のページと、「条件付きで参考にできる」多数のページに分けることで、読み手にとって信用できる Wiki をつくることができる、ということを具体例を挙げてお話ししました。
もしも、自分が後から参加したプロジェクトに「信用できない社内 Wiki」があったらどうするか？ 元から使われている Wiki を大きく書き換えることもできないので、その場合は特定のページ以下を「信用できるサブ Wiki」として育てるのがよいと思います。このルールを色々アレンジしてみてください。
今回は社内 Wiki 全体の話をしましたが、個々のページを「信用できる」ように書く方法については、以前書いた以下の記事をご参考ください。
