「肩書きが先、仕事が後」になっていないか
組織が拡大し、誰が何をやるのか分からなくなると、指示系統をはっきりさせたい、責任者を明確にしたいという理由から役職を先に決めたくなります。しかし、「とりあえずマネージャーにしよう」という判断は、仕事の中身が曖昧なまま人間関係だけを固定するリスクを孕んでいます。
経営判断レイヤー（Why）
役職は「役割」を決めたあとでないと危険
役職を与える行為は単にラベルを貼ることではありません。それは、発言力、指示権、評価される前提といった組織内の力関係を一気に固定します。役割が未定義のまま役職を与えると、何をすればよいか分からない、どこまで口を出してよいか分からない、失敗が人格評価にすり替わるという状態が生まれます。これは人の問題ではなく、順序を誤った設計の問題です。
「システム上で役割を定義する」とは何か
ここでいうシステムとは高度なITツールのことではなく、タスク管理ツール、業務フロー図、権限・操作範囲設定など、役割を“見える形”で置ける場所を指します。システム上で役割を定義するとは、誰が、何について、どこまで判断できるかを、人ではなく構造に紐づけることです。
専門実装レイヤー（How）
役割定義で最低限決めるべき要素
役職を与える前に、システム上で次の点を定義します。これらは役職名よりも先に決まっている必要があります。
- 担当する業務単位：プロジェクト・プロセス・判断テーマ
- 判断できる範囲：金額・影響範囲・例外対応の可否
- 成果として期待する状態：数値・状態・アウトカム
- 戻す条件・タイミング：評価期間・見直し条件
役割が定義されていない役職が生む問題
役割定義を飛ばして役職を与えると、次の問題が起こりやすくなります。
- 役職者が何でも判断し始める
- 他のメンバーが判断を放棄する
- 組織変更が人事トラブルに発展する
結果として、組織を整えたはずが動かしづらくなるという逆転現象が起きます。
システム先行で見えてくるもの
役割をシステム上に先に置くと、次のことが自然に明らかになります。
- 本当に必要な役職は何か
- 役職でなくても回る業務はどれか
- 一時的な役割と恒常的な役割の違い
多くの場合、役職が必要だったのではなく、判断の置き場（可逆性のある経営判断の仕組み）が必要だったという結論に至ります。
よくある誤解
誤解①：役割定義は細かすぎる管理になる
役割定義は人を縛るためのものではありません。それは迷いを減らし、責任の押し付けを防ぐための安全装置です。
誤解②：役職を付けないと納得してもらえない
納得感は肩書きではなく、期待が明確か、評価が妥当かで決まります。
この判断で、最後に確認したい問い
この役職は、どの役割を担わせたいのか。その役割はシステム上で説明できるか。役割を外す余地は残っているか。これらに答えられない場合、役職を与えるのはまだ早いと言えます。
まとめ（正解は出さない）
中小企業の組織設計において、役職は最後に貼るラベルです。先に定義すべきは、明確な役割と判断範囲です。業務プロセスや権限委譲の仕組み（システム）は、その役割を柔軟に、可逆的に置くための装置です。役職を与える前に、役割を構造として置けているか。それが、可逆性のある経営判断の核心です。
