プロジェクトのWikiを作ろう：情報共有の「ブラックボックス」を解消する技術

なぜプロジェクトにWikiが必要なのか？

プロジェクトの運営において、対面でのコミュニケーションは依然として重要ですが、それだけで全てをカバーすることは不可能です。なぜWikiという「ストック型」の共有手段が不可欠なのか、その背景を探ります。

対面によるコミュニケーションの問題点

理想を言えば、チーム全員が同じ場所に集まり、ホワイトボードを囲んで細かな作業のすり合わせを行うのが最も効率的です。しかしそれだけでは、下記のようなリアルタイムな相談や記憶の風化などの問題が生じてしまいます。

• リアルタイムの相談が難しい
  メンバーごとに稼働時間が異なる場合、リアルタイムの会議を待っていては意思決定が遅れることがあります。さらに作業内容に関して意思決定の権限をもつ人は常に膨大なタスクを抱えていることが多く、ふとした瞬間の「ちょっといいですか？」と相談することも難しい局面が多くなってしまいます。
• 記憶の風化
  対面で合意した内容も、何らかの記録として明文化されていなければ、1ヶ月後には「言った・言わない」の論争に発展します。
• リモートワークの普及
  そもそも物理的な距離があるため、「ちょっといいですか？」と聞くことも難しくなります。
  ただしチーム内であれば上長やメンバーが常駐すればある程度解消する余地があります。
  一方で様々なベンダーが集まって作業する大規模なプロジェクトの場合、同じ場所でなおかつ同じ時間で常駐することは作業場所のキャパシティによっては非常に難しく、自分のチームだけの都合で常駐するよう提案することは困難でしょう。

この「ちょっといいですか？」ができないことで、メンバーの手が止まる。この「待ち時間」を、単なる効率低下で片付けていないでしょうか。
10人のチームで、全員が1日30分「誰かの回答待ち」や「資料を探す時間」に費やしているとすれば、月間で約100時間ものリソースが無駄になっていると言えます。あるいはコンサルの現場でメンバーがこの丸一日「ちょっといいですか？」ができないことによって、半端な成果物しかあがらないなんてことがあれば目も当てられません。
私たちが本当に問うべきは、リアルタイムのコミュニケーションの限界ではなく、「情報の蓄積共有を怠ることで、毎日どれほどの見えないコストを支払っているか」という経営・マネジメント上の損失です。

情報のフローとストックの切り分けがなされない

チャットツール（SlackやTeams）は情報の「フロー」（直近の状況報告、資料の即時連携など）には優れていますが、重要な仕様や手順がログの彼方に流れていってしまいます。Teamsの場合、ログを検索して確認することもできますが、メンバーの記憶があいまいになってくる可能性もあり、参照する際にはログを地道にさかのぼっていく必要があります。
Wikiはこういった記録を「ストック」（過去の重要決定事項や大多数のスタッフが確認しておくべき情報などを記録）し、いつでも誰でもアクセスできる「チームの脳」として機能します。

Wikiを作成することで得られるメリット

Wikiを作ることは単なる「ドキュメント作成」に留まらず、手順書という資産になることやナレッジトランスファーの効率化など生産性向上に寄与します。

①手順書としての資産化

個人の頭の中にしかないノウハウをWikiに書き出すことで、作業の標準化が進みます。

• 属人化の解消
  「Aさんがいないとこの作業ができない」という状況が解消されます。
• ミスの軽減
  誰がやっても同じ結果が出るチェックリスト形式のWikiは、品質担保の要となります。

②ナレッジトランスファー（KT）の圧倒的効率化

プロジェクトへの新メンバー参画時、Wikiがあるのとないのでは立ち上がり速度が数倍変わります。

• セルフオンボーディング
  過去の経緯や環境構築手順がWikiにまとまっていれば、新メンバーは自力で学習を進められます。
  また、事務手続きなど本業と関係のない作業はどういった局面でも多かれ少なかれ存在しており（常駐先のメンバーの追加手続きやIDカード、貸与PCの申請、専用ツールの利用アカウント申請、稼働実績の報告・・・などなど）、こういった作業も一度資料化してしまえば「これを読んでわからなければ聞いてください」の一言で片づけることができます。
• 教育コストの削減
  既存メンバーが何度も同じ説明をする時間を削減し、より本質的な議論に時間を割けるようになります。
  特に属人化が激しい状況では、作業者自ら手順について説明する時間を割くことが非常に難しいです。
  ここで作業のイメージをつかむことができれば、新メンバーは圧倒的なスタートダッシュを切ることができるでしょう。これが習慣化されれば、それと同時に属人化も少しずつ解消していくことになります。

事務手続きや環境構築は、プロジェクトの「成果」を直接生み出すものではありません。
ここで私たちが直視すべき問いは、「優秀なエンジニアや高単価なコンサルタントに、なぜ『本業以外』のコストを支払わせ続けているのか？」ということです。Wikiによるセルフオンボーディングの確立は、単なる親切心ではありません。チーム全体の稼働時間を「付加価値を産むコア業務」へ100%シフトさせるための、シビアなリソース最適化戦略なのです。

なお属人化が非常に激しい状況では、作業者自ら手順書として記録することは難しい可能性も高いため、場合によっては他のメンバーが作業を見ながら記録を付けて手順書化してあげたりするなど柔軟な対応を検討しましょう。

③「情報のシングルソース」の確立

「最新の仕様書はどれ？」という混乱をなくします。「Wikiを見れば必ず正解がある」という信頼感が、チームの心理的安全性を高めます。

どんなWikiにするのか？（失敗しない分類と整理のルール）

Wikiを作っても、中身が散らかっていては誰も読みません。
設計段階で「整理軸」を決めておくことが重要です。

担当領域やフェーズによる分類

作業者によって担当領域が明確に分かれている場合は、他の担当領域のメンバーが参照しやすいようその区分に従うのが最も直感的でしょう。
これはプロジェクト全体としてナレッジの蓄積が急務とされている場合、Wikiという形式で構築していくことで課題の解決につながります。

図1. Wikiの構成イメージ（プロジェクト全領域）

担当領域の詳細化

自分のチーム内など限られた領域に閉じる場合、まずは手順書などを中心に細分化する余地もあります

• 現在の業務（※図中では便宜上割愛）
  今プロジェクトで発生しているすべての作業を指します。
• 過去の業務
  プロジェクトのフェーズによっては毎日実施していた作業でも、次のフェーズに進んだ段階で廃止される作業も発生します。そういった業務のために「過去に実施されていた作業」 を配置します。
  Wikiでは「アーカイブ」という扱いになり、現在のメンバーが誤って参照するのを防ぎます。
• 定常業務
  日次や週次など、定期的に繰り返されるルーティンワークです。
  • 日次作業（毎日やること）
  • 週次作業（毎週やること）
  • 月次作業（毎月やること）
• 非定常業務
  不定期、または必要に応じて発生するスポットワークです。
  • 事務手続き
    入館申請やアカウント発行など、必要な時に行うことです。
  • 会議関連
    会議というイベントに紐づくものです。
    さらに下に会議メモと 「会議補助（プロジェクターの起動手順など）」とする構成です。
    会議は週次や日次などさまざまな会議が存在しますが、手順書との混在になる可能性を考慮してここでは非定常作業としております。
    ただし会議に関連する資料の物量によっては定常業務と同じ段階に上げるなど、プロジェクトで求められる業務の物量によって調整する余地もあるでしょう。
    会議によって必ず議事録が求められるものもあれば、事前に記入した表に対して決定事項を追記することで業務負荷にならないようにする運用がなされることもあります。ここはプロジェクト内部のあるべき姿によって様々です。

図2. Wikiの構成イメージ（プロジェクト担当領域）

実際のWiki活用イメージと構成例

具体的なイメージを持つために、構成例を検討してみましょう。
今回は、プロジェクトの担当領域に絞って検討する場合を考えてみます。

手順書ページの書き方

手順書は、「誰が読んでも再現できること」がゴールです。

• キャプチャ（スクリーンショット）を多用する
  テキストだけの説明は誤解を生みます。操作画面の画像に赤枠で指示を入れるだけで、理解度は飛躍的に高まります。
• 箇条書きを基本とする
  可能な限り長文は避け、ステップバイステップ（Step 1, Step 2…）で記述します。

OneNoteの活用

OneNoteの場合、1つの文書の中に複数の階層を組み込むことができます。
一つのページに対して組み込めるサブページは2階層までなので、それ以上の階層になるようであればページを変更するなど工夫しましょう。

図3. OneNoteでの活用イメージ

クラウドストレージの活用

一つの文書にまとめることにこだわらないのであれば、クラウドストレージ上でWikiを作ることもできます。
フォルダで階層を組んで個別に文書を設置する場合、掘り下げる階層に制限はありません。
ただし階層が深くなりすぎて検索性が落ちないように配慮しつつ構成を調整する必要があるでしょう。
さらにこの方法であれば、GoogleDriveに留まらず、OneDriveやDropboxなどのデータ格納ができるクラウドサービスにも活用することができます。

図4. GoogleDriveによる活用イメージ

図5. 個別の手順書ファイルの作成イメージ

運用を成功させるためのルール

Wikiは「作った時が完成」ではなく、「運用が始まってからが本番」です。
放置される「廃墟Wiki」にしないための工夫が必要です。

更新履歴の徹底管理

「いつ、誰が、何を変えたのか」がわからないドキュメントは、信頼性を失います。
多くのツールには履歴機能がありますが、重要な変更についてはページ上部に「Last Updated: 202X/XX/XX – 仕様変更に伴い追記（担当：○○）」といったメモを残すと親切です。
また大幅な変更が必要な場合は事前に管理者と相談し、具体的に変更したいところをすり合わせておくことで、「ここはいつのまにこんな記載になったの？」といった混乱を与えずに済みます。

「気づいた人が直す」文化の醸成

Wikiの管理者を一人に決めすぎないことが大切です。
「ここは古いな」と思ったら、気づいた人が即座にアップデートする権限と空気感を作ります。
また質問されたら、口頭で答えるだけでなく「Wikiのここを更新しておいたから確認して」と誘導することで、Wikiを情報の中心に据えます。
細かい作業の流れを確認しながら説明する必要がある時は、すぐにWikiにある手順書を見せながら説明することで、Wikiが重要だと感じる文化をさらに醸成させることにつながるでしょう。

メンテナンスデーの設定

月に一度、30分程度で良いのでリンク切れの確認や運用されていない作業、作業自体の重複確認などの「Wikiの掃除時間」を設けます。
特にクラウドストレージで管理する場合、設定したリンクが期限付きであることもあります。
そのまま放置してしまってリンク切れになってどこにあるかわからないとなってしまうと、Wikiが機能しなくなってしまうので、こういった事態を避けるためにもメンテナンスをするようにしましょう。
また本業の業務が忙しくなってしまってメンテナンスが追い付かないとなってしまうような時は、リスト形式にして1つだけでもいいから確認しつつ、確認した期間が著しく古いものを優先的にチェックするといった工夫も有効でしょう。

導入ステップ

ここで想定される導入ステップについてまとめてみましょう。

1. 目的を決める
   対象範囲はプロジェクト全体か、まずは担当する業務に絞って広げていくか、どんな内容を中心に取り上げていきたいかなどの目的を決めます。
2. ツールの選定
   プロジェクト全体であれば専用のツールを検討することはできるか、チーム単位で検討するのであればまずは使えるアプリの中から選定するかなどを決めましょう。
   Wikiとしてナレッジを蓄積すること自体が急務でない限り専門のツールを導入することはハードルが高いですが、そんな時は使えるツールから選定します。
3. 最小限でスタート
   最初から完璧を目指さず、まずは「よく聞かれる質問」への回答を1ページ書くところから始める。
4. 発生頻度の高い業務を中心に蓄積
   無理して全て収集しようとせず、発生頻度の高いものや問い合わせが多い業務など優先度が高いと感じるものから蓄積していきましょう。
5. 運用ルールの整備
   利用者が増えてくるとメンバーによって思想が異なってくるので、メンテナンスの頻度や更新履歴の管理方法などお互いがストレスなく活用できるルールをすり合わせて活用範囲を拡張させていきましょう。
   すり合わせが進むことで、チームの共通言語として作られていきます。

最後に

プロジェクトWikiを作成することは、最初は手間に感じるかもしれません。しかし、長期的に見れば、情報の検索コスト、教育コスト、そしてコミュニケーションエラーによる手戻りを劇的に削減してくれます。
Wikiを作ることは、単なるドキュメントの整理ではありません。それは、プロジェクトにおける『情報の不透過性』『属人化リスク』『時間的損失』という3大悪に、チーム全体で立ち向かうための構造改革と言えるでしょう。