信用できない技術者に、相談する人はいないですよね。実際には役に立つ情報もあったかもしれないのに、全体の信用を失ってしまったために役に立つ情報まで読まれなくなるとしたら、それはもったいないことです。ルールを運用するためのヒントこのルールをチーム全体できちんと運用するためのヒントを、いくつか挙げておきます。ヒント(1):「更新され続けるページ」は極力少なくするこのルールを採用する場合、何か機能をリリースするたびに、その機能に関連する「更新され続けるページ」はすぐ更新する必要があります。忙しい時期でもこのルールを守れるように、更新され続けるページは極力少なくしておいたほうがよいでしょう。以下のような情報は、更新し続けるメリットが、更新作業のコストを上回ると思います。用語一覧そのプロジェクト固有の用語一覧。OS・ブラウザの情報など。アプリケーション構成コンポーネント一覧、バッチ一覧、データベース定義書など。開発ルールそのプロジェクトで採用する開発プロセス、開発用ツール、コーディング規約、テスト基準など。手順書システム構築のための手順や、日常的な運用作業の手順など。主要機能の解説そのプロジェクトで特に難しい機能や、わかりにくい機能の理解を助けるための解説記事。ヒント(2):更新し続けられないと判断したら、「更新されないページ」に移す理想的には、「更新され続けるページ」はできるだけ多いほうが良いです。開発が多忙になったり、逆に開発が一段落して開発者の人数が減ったりすると、更新にかけられる時間は減ります。いう場合は、どのページを残すかチーム内で議論して、更新しきれないページは「更新されないページ」に移しましょう。信用できるかどうか」のほうを重視すべきです。以下の階層にある「機能Aの解説」ページを最近更新できてない、と気付いたとします。機能Aの解説この場合、そのページを「更新されないページ」以下の階層に移す、という具合です。「機能Aの解説」ページの先頭(「このページについて」欄)に、更新できなくなった時期とその事情を書いておくと、読み手の助けになるでしょう。機能Aの解説ヒント(3):「更新されないページ」を「更新され続けるページ」に格上げしたいときは、必ず書き換える更新されないページを書いているうちに、分量が多くなり、内容も充実したように思えるので、「更新され続けるページ」に格上げしたくなることがあります。以下のような場合です。ある機能の設計に関するページが、その機能に関するよいまとめに思えるので、主要機能の解説ページに格上げしたい。ある障害の原因を特定するためにソースコードを調査したときのメモが、ソースコードのよい解説に思えるので、主要機能の解説ページに格上げしたい。これらのページを書き始めた目的は「主要機能の解説」ではないため、余分な情報が多く含まれている可能性が高いです。分量が多いほど更新が大変になるので、元のページとは別のページを作り、更新し続ける必要がある部分だけ残して、リライトしたほうがよいでしょう。そもそも、有用な情報をすべて「更新され続けるページ」にする必要はありません。「更新されないページ」のなかに「技術メモ」のようなカテゴリを作り、そのなかに「2017年1月時点の技術メモ」のような形で残しておくという方法もあります。ヒント(4):ルールを守るための責任者を立てる上記のルールを徹底するためには、ある程度の強権が必要になります。チームメンバが以下のようなことを始めてしまったときに、誰かがあるべき状態に戻す必要があります。このような行動は、各人の自主性に任せていてもなかなか防げません。意見の衝突が起こるからです。「自分がよく使うページだから」という理由で、ホーム画面にリンクを書き足す。「誰かが更新すべき情報だ(自分は更新しないけど)」という理由で、「更新され続けるページ」にページを足す。自分が必要だから更新し続けているページがあるが、責任を押し付けられたくないので、「更新されないページ」の中に残し続ける。このような衝突を解決するために、ルールを守るための責任者をチーム内に立てて、その責任者は「このルールを守るためであればどのようにページを編集してもよい」と明言しておくのが良いと思います。メンバから異論がある場合はその責任者を中心に議論し、ときどき細かい運用を見直します。ほとんどすべての編集にざっと目を通す必要があるため、チームリーダが兼務するのが一番良いと思います。それが難しい場合は、簡潔な文章を書くのが得意な人を任命するのがよいでしょう。つくるために、私が個人的に実践している基本的なルールをご紹介しました。幻滅し、無視してしまうのを防ぐこと」です。つくることができる、ということを具体例を挙げてお話ししました。Wiki」として育てるのがよいと思います。このルールを色々アレンジしてみてください。全体の話をしましたが、個々のページを「信用できる」ように書く方法については、以前書いた以下の記事をご参考ください。はてなブログProMuziとも呼ばれる人。いまはBacklogのSREやってます。(1)注目記事リンク無印吉澤(旧)はてなブログをはじめよう!muziyoshizさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。