ナレッジを効率的に共有するためには、構造化することが不可欠です。上手に文書化されたコードは一つの側面に過ぎません。タスク、計画、報告書、プロジェクトのプレゼンテーションも同様です。初期のスケッチから仕様書、デプロイメントのヒント、ナレッジのルートマップ、トレーニング資料、テストサンプル、運用手順、プロジェクトの組織、会議のメモ、正式なモデル、開発手法など、他にもたくさんあります。

開発者にとって有益な情報であるばかりで、管理職が求める情報をなかなか見つけられなかったり、あるいはその逆にならないために、ナレッジをすべてきれいに整理するにはどうしたらいいでしょうか？多くの人々が、異なる情報要求を同時に満たすにはどうすればいいでしょうか？

リッチなハイパーリンクページを持つWikiは、同じ情報への複数のナビゲーションパスを提供するのに役立ちます。タグとキーワードは検索を加速させます。しかし、Wikiは基本的に階層的なページのセットとして構成され、その構造はナビゲートするためにもよく使われます。

どのような構造が最も効率的でしょうか？

プロジェクトに関するあらゆる情報を整理し、構造化する時間を節約できます。

持続可能で、プロジェクトが進むにつれて新しい情報カテゴリーをきれいに保存できる構造から始めましょう。このチーム（または同僚）は、いったいどこに、あなたが探している種類の情報を保存しているのだろう、と考えるのはやめましょう。あらゆる種類のプロジェクトで共通のテンプレートとなる、きれいで再現可能なプロジェクトナレッジ構造を提供しましょう。

プロジェクトに参加するとき、あるいはプロジェクトが豊富で複雑なために認知負荷（Cognitive Load）の過負荷を引き起こし、生産性を上げるためにナレッジを常に更新しなければならなくなったとき、プロジェクトに関する情報を検索する際にかなりの時間節約を実現できます。

あなたのプロジェクトのwikiにページを追加する時、以下の”Organum”構造を参考にしてください。この構造は方法論Praxemeから借用したもので、そのEnterprise System Topologyは設計から提供までのプロジェクトに関するすべての情報を整理する手段によってサポートされています。ここでは、90%のITプロジェクトに十分な簡略化されたOrganum が提案されています。

Get Started:

(図のマインドマップに従う)

プロジェクトのトップページには、短いプロジェクト概要、連絡先リスト、マイルストーンと進捗状況の要約、絵のようなスケッチや アーキテクチャ図、クイックリンク（最近の活動、FAQ、さまざまなプロフィールのルートマップ、略語など）を掲載するのが一般的です。

以下では、知識を4つのカテゴリーに整理する：

1. すべての外部ソースの ”リポジトリ(Repository)”： クライアントの仕様書／初期声明／契約書、プロジェクトで使用されたサードパーティ製品やライブラリへのリンク、ドキュメント、テストデータのサンプル、標準、規制、方法、ヒント、市場データ、技術、パターンなど。
2. ビジョン/戦略からコード（へのリンク）に至るまで、すべてのプロジェクトの成果物をホストする ”プロダクト(Products)” セクション、スケッチ、モデル、API設計メモ、API仕様へのリンク、コーディングプラクティス、命名規則、利用可能なツールなど。
3. ”運用(Operations)” セクションは、アプリケーションの設定、ビルド、テスト、デプロイ、運用に必要なすべての知識を保持します。ここでは、ステージング環境を文書化し、管理者、開発者、テスター、オペレーター、エンドユーザー向けにマニュアルやチュートリアルを提供します。
4. 誰が何をするのか（プロジェクト組織とマネジメント）、なぜするのか（決定事項、ミーティングノート、品質計画、リスクとその軽減策）、いつするのか（更新計画、タイムライン）、リソース／予算を記述した ”組織(Organisations)”。また、このセクションには、チームやステークホルダー、クライアントに対するプロジェクトのすべてのプレゼンテーションがアーカイブされます。

言い換えれば、この4つのカテゴリーがそれぞれ次のようなものになります:

1. 始める前に持ち込むすべてのナレッジ。主に、内部的なもの（TOGAFのEnterprise Continuumなど）であれ、外部的なものであれ、一般的なものであれ、コメント付きのポインタとして；
2. ”What”（現在）：最新の記述、仕様、声明；
3. ”how”（現在）：最新の手順とプロセス；
4. “who””why””when”（時系列／履歴付き）、すべての共同作業（会議メモ）とコミュニケーション活動（プレゼンテーション）。

異なるセクションのコンテンツ間や、外部のプラットフォーム／情報源へのハイパーリンクが多数存在することは言うまでもありません。

備忘:

• ナレッジ・リポジトリの第一の目的は、時間の節約です。
• wikiにおける純粋な階層的プロジェクトページは避ける；すなわち、子ページ(もしくはグループページ)へのパスだけを保持し、情報を含まず、多くてもサブページのリストを含む'空の'ページを作るイメージです。どのようなレベルの情報に関しても、伝えるべきことが常にあり、きっと役に立つガイダンスやリンクを提供することができるはずです。
• Wikiページにキーワードでタグを付けること、そして他の場所にタグのクラウドを提供することを決して忘れないでください。
• あなたのWikiには、すべてのページと添付ファイルの更新の完全な履歴が組み込まれていることを決して忘れないでください！そのため、バージョン/変更のインベントリを維持するために時間を費やすのではなく、会議のメモ、主要なリリース（過去とその先）、または重要な決定のような真の時系列的なもののために時間を費やしてください。
• あなたのコンテンツをハイパーリンクしてください。ページ階層は、あなたの記憶構造に過ぎません。ナビゲーションは、トップダウンだけでなく、あらゆる方向へのナビゲーションを助けるハイパーリンクが最も効率的です。
• 情報へのリンクは、情報そのものと同じくらい有用であるため、今後はコピーや複製を避けて、リンクしてください。
• Organumは、プロジェクトWikiだけでなく、ソフトウェアプロジェクトに関係するあらゆるものを対象としています。このグローバルな情報の一部は、ソース管理およびソースコード文書化（GitHub / GitLabなど）、プロジェクト管理（JIRAなど）、バグ追跡、モデリング（Modelio、Enterprise Architect、Megaなど）、そしてもちろんAPI管理（Swagger、Postman、多くのベンダーなど）に特化したサーバーでホストする方がよいでしょう。これらの情報は重複せず、ふんだんにリンクしてください。プロジェクトのwikiは、プロジェクトに関するすべてのエントリポイントになります。