特集【会社の見える化】— 社長視点
社内の情報共有を良くするために、会議を増やす。チャットを導入する。共有フォルダーを整理する。それでも「聞いていない」「どれが最新か分からない」「担当者しか知らない」がなくならないことがあります。
道具を増やしても改善しないのは、情報を伝える手段ではなく、会社の事実をどこに、どの意味で置くかが決まっていないからです。
情報がないのではなく、同じ事実が何個もある
一社の顧客について、営業の顧客台帳、経理の請求先一覧、現場の案件表、担当者のメール署名に、それぞれ名称や住所が保存されているとします。移転の連絡を受けた営業が自分の台帳だけを直せば、ほかの一覧には古い住所が残ります。
この会社には情報が足りないのではありません。同じ事実が複数あり、どれを正しい原本とするかが決まっていないのです。共有を呼びかけても、社員は変更のたびに何か所へ知らせるべきか判断しなければなりません。
案件の金額、納期、担当者、契約状態でも同じことが起きます。会議資料を作るたびに各部署の表から数字を集め、食い違いを人が調整するなら、会議は情報を使う場ではなく、情報を作り直す場になります。
チャットは連絡の通り道であって、原本ではない
チャットは素早い相談に向いていますが、重要な決定を会話の中だけに残すと、後から参加した人は経緯を探せません。「先週の件、決まりました」と書かれても、顧客、案件、決定内容、適用日が構造化されていなければ、別の業務で使えません。
会話から生まれた決定は、該当する顧客、案件、契約、商品などの記録へ反映します。チャットにはその記録への参照を置きます。そうすれば、相談の流れと、現在有効な事実を分けて扱えます。
共有フォルダーも同じです。ファイルを置く場所は必要ですが、「この見積もりが承認済みである」「この契約が現在有効である」という業務上の状態まで、フォルダー名とファイル名だけで表すのには限界があります。
会社を構成する言葉をそろえる
情報共有の土台は、会社が日常的に扱うものを、自分たちの言葉で定義することです。たとえば、顧客、問い合わせ、案件、見積もり、受注、作業、納品、請求、入金。これらがどのようにつながるかを整理します。
「案件」と「受注」を同じものとして扱う会社もあれば、受注前の相談から案件と呼ぶ会社もあります。正解は外部の出来合いのシステムではなく、自社の仕事の中にあります。だからこそ、代表者や業務責任者が大本の設計を理解する必要があります。
会社の実態を表す言葉と関係が決まれば、どの情報を誰が更新し、どの部署が使い、どこから経営数字を作るかを設計できます。逆にここが曖昧なままでは、新しい道具へ古い混乱を移すだけです。
一つの事実を一度記録し、役割ごとに見せる
情報を一か所へ集めることは、全社員にすべてを公開することではありません。顧客の正式名称という一つの事実を、営業は案件画面で、経理は請求画面で使えます。原価や人事情報などは、権限のある人だけに表示します。
社長には、全データの一覧ではなく、経営判断に必要な集計と例外を見せます。現場には、今日処理する仕事と前後の関係を見せます。画面や範囲は違っても、根拠となる記録は同じです。
この構造なら、部署間で数字が違ったときに「どちらが正しいか」を会議で決め直すのではなく、原本の記録と定義を確認できます。修正が必要なら一か所を直し、利用する画面へ反映します。
毎月作り直している資料から始める
最初の題材には、会議のたびに複数の表から作り直している資料が向いています。その資料の数字を一つずつたどり、元の事実はどの業務で生まれ、誰が記録し、どんな条件で集計されるかを確認してください。
たとえば「今月の受注額」なら、見積提出時なのか、顧客の発注時なのか、契約締結時なのかを決めます。取り消しや金額変更をどう扱うかも必要です。この定義をそろえ、元の記録から同じ集計を再現できれば、一つの資料を手作業から外せます。
情報共有の目的は、全員が大量の情報を読むことではありません。必要な人が、必要な時に、同じ事実を基に判断できることです。会議やチャットを増やす前に、会社の事実の置き場所と意味を一つずつ決める。それが、情報共有を仕組みに変える方法です。