土台にあるもの
地味な作業を、
軽く見ない。
知識管理の仕事には、目立たない作業がたくさんあります。ファイルの見出しを揃える。用語の表記を統一する。分類の根拠を書き残す。こうしたことは、成果として見えにくいですが、後から検索が機能するかどうかに直接関わります。
Echo Flux System は、その地味な準備作業こそが、知識を本当に使えるものにすると考えています。派手な解決策よりも、確かな下準備。それが私たちの出発点です。
観察を先に、手を動かすのは後から
何が問題かを決める前に、今の状態をよく見る。思い込みで進めない。
使う人の言葉から設計する
外部から答えを持ち込まず、チームの中にある言葉と思考の流れを大切にする。
終わった後のことを考えて進める
プロジェクトが終わっても、決めたことの理由が残るようにする。
ビジョン
チームの知識が、ちゃんと届く世界。
優れた知識を持っているチームが、それを見つけられないせいで同じ失敗を繰り返したり、退職した同僚の経験を再現できなかったりする。そういう状況を、Echo Flux System は少し残念だと思っています。
技術的な解決策は年々増えています。でも、どんなツールも、中に入っている情報の質を超えることはできません。Echo Flux System がやりたいのは、ツールの前の段階で、チームの知識を「ちゃんと届く状態」にすることです。大げさな目標ではなく、地に足のついた積み重ねとして。
核となる考え方
仕事を支える、いくつかの信念
構造は、押しつけるものではない
分類の枠組みは、外から当てはめると使われなくなります。実際に知識を使う人の思考の流れに沿って作られたものだけが、自然に機能し続けます。
成果は文書に宿る
会話の中で決まったことは、伝わらないまま消えることが多い。書かれたものだけが、時間を越えて機能します。整理の根拠も、例外なく文書に残します。
小さなスコープで確実に
全部一度に変えようとすると、たいてい途中で止まります。範囲を絞って、その中を丁寧に仕上げる方が、長期的には早く進みます。
ツールより素材
検索システムの性能は、それに与えられる情報の質を超えません。まず素材を整えること。それがツール選定より先に来ます。
実践への翻訳
考え方が、実際の作業にどう現れるか
理念は言葉では整えやすい。それが本物かどうかは、日常の作業の細部に出ます。
監査のとき
見つけたことを、そのまま書く
問題を大げさにも小さくもせず、現状をそのまま報告書に書きます。都合の悪い発見も省きません。
設計のとき
答えを持ち込まず、引き出す
ワークショップでは正解を提示しません。チームの中にある言葉と論理を丁寧に引き出して、それを設計に反映します。
納品のとき
「なぜ」を必ず添える
成果物だけを渡しません。なぜその設計になったか、どんな判断をしたかを文書に記録して一緒にお渡しします。
人を中心に置くこと
知識管理は、
最終的に人の問題です。
どんなに整ったシステムも、使う人が理解できなければ意味がありません。Echo Flux System が分類設計をチームと共同作業で行うのは、その人たちが使いやすいものを作るためです。
また、整理の作業自体が、チームの知識について話し合うきっかけになることもあります。ワークショップを通じて「そういえばそこが曖昧だったよね」という気づきが生まれることを、Echo Flux System は大切にしています。
一人ひとりの使い方を尊重する
同じチームでも、知識の探し方は人によって違います。その違いを踏まえた設計を目指します。
対話の中から設計を作る
ワークショップは情報収集の場ではなく、一緒に考える場です。その違いが、成果の使われ方に影響します。
意図を持った改善
新しければいい、
というわけではない。
知識管理の分野では、新しいツールや手法が次々と登場します。Echo Flux System はそれらを否定しませんが、「新しいから導入する」という判断には慎重です。
何かを変えるときは、なぜ変えるのかを説明できる状態で変えます。既存の方法の中に良いものがあれば、それを続けます。改善は積み重ねであり、入れ替えではないと考えています。
実際の判断基準
今の課題に対して、本当に必要か
既存の良い部分を壊さないか
使う人が理解して継続できるか
なぜ変えるかを言葉にできるか
誠実さと透明性
都合の悪いことも、ちゃんと言います。
報告書は飾りません
調査で見つかった問題点は、そのまま書きます。依頼者にとって聞きづらいことでも、省くことはしません。それが次の判断に役立つからです。
合わない場合は正直にお伝えします
ヒアリングの結果、Echo Flux System のサービスが今のチームの状況に合わないと判断した場合は、その旨をお伝えします。無理に進めません。
費用と期間は最初に明示します
プロジェクトを進める前に、費用・期間・スコープを書面で確認します。途中での大幅な変更は、原則として合意なしには行いません。
協働について
Echo Flux System は、外から答えを持ち込みません。
ナレッジベースの設計は、外部の専門家が単独で行うより、実際に知識を使うチームと共同で行う方が、使われる成果になります。
Echo Flux System がワークショップを重視するのは、そのためです。2回のワークショップを通じて、チームの中にある暗黙の分類感覚を引き出し、設計に反映します。外部の視点と内部の知識を組み合わせることで、どちらか一方だけでは作れないものができます。
外部の視点を持ち込む
社内にいると見えにくい構造上の問題を、外から観察することで発見します。
内部の知識を引き出す
チームの思考の流れ・使っている言葉・暗黙のルールを、対話の中で整理します。
二つを合わせて設計する
観察と対話から得たものを組み合わせて、チームが実際に使える構造にします。
長期的な視点
プロジェクトが終わった後のことを、先に考えます。
Echo Flux System が関わるプロジェクトは、期間が決まっています。2週間、4週間、6週間。その間に何かを作って渡したら、後は依頼元のチームが続けていきます。
だから、「終わった後も機能するか」を常に考えながら設計します。担当者が変わっても、なぜその構造にしたかが分かるように。新しいコンテンツが追加されても、どこに入れるかが判断できるように。そういう設計を目指します。
長続きする成果のために
設計の意図を文書に記録して渡す
判断基準を例示付きで示す
引き継ぎの時間を必ず取る
修正サンプルを参考例として渡す
あなたへの約束
この理念が、依頼者にとって何を意味するか
プロセスの面で
-
ヒアリングから始め、スコープを一緒に確認します
-
費用・期間・成果物を書面で事前確認します
-
途中で発見した問題は、都度共有します
成果物の面で
-
報告書・設計書は、読んで判断できる形で書きます
-
設計の意図と判断の根拠を必ず添えます
-
引き継ぎの時間を取り、次の担当者も動ける状態にします
次のステップ
この考え方が合いそうなら、話してみてください。
理念に共感していただけた方に、Echo Flux System のサービスは特によく合うと思っています。まずは現状を聞かせてください。
お問い合わせはこちら