役職を与える前に、システム上で役割を定義する

組織が大きくなり、誰が何をやるのかが分からなくなってくると、指示系統をはっきりさせたい、責任者を明確にしたい、という理由から、まず役職を決めたくなります。

けれども「とりあえずマネージャーにしよう」という判断は、仕事の中身が曖昧なまま、人間関係だけを固定してしまう危うさをはらんでいます。

肩書きが先で、仕事が後。この順序を逆にするのがこの記事の主張です。役職を与える前に、システム上で役割を定義しておくのです。

役職は、役割を決めたあとでないと危険

役職を与えるのは、単にラベルを貼ることではありません。発言力、指示権、評価される前提といった組織内の力関係を、一気に固定する行為です。

役割が決まらないまま役職を与えると、何をすればよいか分からない、どこまで口を出してよいか分からない、失敗が人格の評価にすり替わる、という状態が生まれます。これは人の問題ではありません。順序を誤った設計の問題です。

「システム上で役割を定義する」とは

ここでいうシステムとは、高度なITツールのことではありません。タスク管理ツール、業務フロー図、権限や操作範囲の設定など、役割を「見える形」で置いておける場所のことです。

システム上で役割を定義するとは、誰が、何について、どこまで判断できるかを、人ではなく構造に結びつけることです。

役職名より先に決めておくべきこと

役職を与える前に、システム上で次の点を定義しておきます。これらは、役職名よりも先に決まっていなければなりません。

• 担当する業務単位：プロジェクト・プロセス・判断テーマ
• 判断できる範囲：金額・影響範囲・例外対応の可否
• 成果として期待する状態：数値・状態・アウトカム
• 戻す条件・タイミング：評価期間・見直し条件

役割のない役職が生む問題

役割の定義を飛ばして役職を与えると、次のような問題が起こりやすくなります。

• 役職者が何でも判断し始める
• 他のメンバーが判断を放棄する
• 組織変更が人事トラブルに発展する

組織を整えたはずが、かえって動かしにくくなる。そんな逆転が起きるのです。

役割を先に置くと、見えてくるもの

役割を先にシステム上に置くと、次のことが自然に明らかになります。

• 本当に必要な役職は何か
• 役職でなくても回る業務はどれか
• 一時的な役割と恒常的な役割の違い

多くの場合、必要だったのは役職ではなく、判断の置き場（可逆性のある経営判断の仕組み）だった、という結論にたどり着きます。

役割の定義をめぐる、二つの誤解

誤解①：役割定義は細かすぎる管理になる

役割の定義は、人を縛るためのものではありません。迷いを減らし、責任の押しつけを防ぐための安全装置です。

誤解②：役職を付けないと納得してもらえない

納得感を決めるのは肩書きではありません。期待が明確かどうか、評価が妥当かどうかです。

役職を与える前に確かめたい三つの問い

• この役職は、どの役割を担わせたいのか。
• その役割はシステム上で説明できるか。
• 役割を外す余地は残っているか。

答えられないなら、役職を与えるのはまだ早いといえます。

まとめ：役職は、最後に貼るラベル

中小企業の組織設計において、役職は最後に貼るラベルです。先に定義すべきは、はっきりした役割と判断の範囲です。業務プロセスや権限委譲の仕組み（システム）は、その役割を柔軟に、可逆的に置いておくための装置です。

役職を与える前に、役割を構造として置けているか。それが、可逆性のある経営判断の核心です。