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