177
159

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

社内Wikiを改善して、開発体験をより良くする

Last updated at Posted at 2024-05-11

はじめに

◆この記事は何?
社内Wikiの改善方法について紹介する記事です。

◆この記事のねらい
社内Wikiを改善することで、チームの生産性や品質を向上させ、開発体験をより良くするのがねらいです。

先に結論

  • 「ルール」ではなく「ポリシー」を設ける
    • Working集」と「アーカイブ集」をつくる
    • ページごとに目的を書く
  • 大切な思考法
    • 中途半端なドキュメントは中途半端な文化を生む
    • 誰でもできるは誰もやらなくなる

社内Wikiのよくある課題

皆さんの社内Wikiで次のような課題を感じたことはありませんか。

  • 情報が散乱
  • 更新中のページがそのまま
  • メンテナンスされていない構造

多くの人が作成・編集できる社内Wikiは、改善の意志がないと上記のような状態になりがちです。

最悪の場合、開発体験の低下につながります。

良い社内Wikiとは

良い社内Wikiの必要条件は以下の通りです。

  • 開発体験を向上させる
    • 結果的にビジネス価値を生む
  • 必要な情報にアクセスしやすい
    • 逆に不要な情報はアーカイブされている
  • 未来を見据えて改善され続けている

組織によって条件は変わると思いますが、概ね上記のような内容が挙がるかと思います。

「ルール」ではなく「ポリシー」を設ける

まず社内Wikiを改善するためにポリシーをつくります。

社内Wikiは「ルール」よりも「ポリシー」の方が改善は進みやすいです。

  • 「ルール」
    • 必ず守る具体的な指示
  • 「ポリシー」
    • ガイドラインとしての推奨事項

◆「ルール」よりも「ポリシー」が良い理由

  • 社内Wikiは想定外や例外が発生しやすい
  • 多くの人が関わるため、新しい「ルール」はハレーションが起きやすい
  • 仮に守っていなくても、そこまで大きな問題になることは少ない

柔軟性を持ちつつ、明確な方針の下で組織として活動していくために、ポリシーを設けます。

次に、実際に効果があったポリシーを3つ紹介します。

①「Working集」をつくる

Working集は「更新中のページ」や「どこに配置すべきか分からないページ」のための場所です。

目的は、

  1. 中途半端なドキュメントの混在を防ぐ
  2. 全体の構造を綺麗に保つ

です。

Working集は、想定していなかった例外をキャッチできるようになります。

例えば、次のような運用ができます。

  • 「とりあえずWorking集からページを立ち上げておく」
  • 「アドホックなイベント用ページをWorking集で立ち上げる」

②「アーカイブ集」をつくる

「アーカイブ集」は、「役目を終えたページ」や「削除を迷うページ」のための場所です。

「役目を終えたページは削除する」というポリシーも考えられます。
しかし、社内Wikiでは「自分が作成していないページは削除して良いかわからない」状態になりがちです。

そのため、削除の判断に迷う場合も「とりあえず移動できる場所」として用意しておきます。
心理的にもハードルが下がり、結果的に全体の保守性が高くなります。

③各ページに目的を書く

「各ページに目的を書く」というポリシーは有効です。

目的を書くことで、「このページは本当に必要か?」と再評価できるようになります。
量も自然に必要十分になっていきます。

ページごとの目的を記載することで、ページの配置位置を適切に導くことができ、Wiki全体の構造を綺麗に保ちやすくなります。

「中途半端なドキュメントは中途半端な文化を生む」

中途半端なドキュメントが一つあると、次々と中途半端なドキュメントが生まれていきます。

そして、それらは次第に「中途半端な組織カルチャー」になっていきます。

早い段階で中途半端なドキュメントを無くしておく、また上記の「Working集」などを活用して「中途半端であること」を明示することで、「中途半端な文化」を予防します。

「誰でもできるは誰もやらなくなる」

誰でもできることは誰もやらなくなる傾向があります。
社内Wikiがその代表例です。

よって、推進担当を一人設けるのが有効です。
「ドキュメントオーナー」という役割も考えられます。

「エンジニアのためのドキュメントライティング」では次のように解説されています。

ドキュメントの責任は全員にある、と考えられることが多くあります。それゆえに、誰も責任を負ってないとも言えるでしょう。そこでドキュメントの課題への対応、ドキュメントの変更に対するレビュー、必要であればドキュメントの更新に責任を持つドキュメントオーダーを明示的に任命することで、責務を明確にしてください。責務の明確化は、ドキュメントが古くなることの防止に役立ちます。

誰でもできる仕事は誰もやらなくなるので、私は積極的にやるようにしています。
そのほうが、組織が良くなり、結果的に自分のためになるからです。

おわりに

この記事では、社内Wikiの改善方法について紹介しました。

ポリシーをつくること、そしてその背景にある思考法についてご紹介しました。

もし他に効果的なポリシーや思考法があれば、コメントで教えていただけると幸いです。

参考

GitLabに学ぶ 世界最先端のリモート組織のつくりかた

割れ窓理論

177
159
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
177
159

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?