役職と役割の違い、そして役割に着目したほうが仕事が楽しくなる説

新年一発目のポエムです。

日常的に、役職と役割まわりでモヤモヤする (ごっちゃに考えてしまう)ことが多い気がしたので、自分の思考整理のために言語化しておきます。

役割とは何か

そもそも「役職、役割って何なのよ」という所から考えていきます。

まず組織では大きなビジョン、ミッションを掲げていることが多いと思います。「なぜ、何のために我々は存在するのか」みたいなやつですね。そして、As-Is (現状)とTo-Be (理想状態)のギャップである大小様々な課題を解決することで利益を作り、成り立っています。

そしてそのビジョン、ミッションというのは、

• 経営

• 事業

  • 営業

  • マーケティング

  • 開発

  • デザイン

• バックオフィス

  • 人事

  • 経理

• ...

のような様々な専門領域ごとにも存在し、各領域で様々なボリューム、難易度の解くべき課題が存在しています。1時間で終わるタスクのようなものから、3ヶ年計画みたいなものを掲げ、地道にチューニングしながら推進していくようなものもあるでしょう。それを何かしらのチームを形成し、メンバーで分担して課題解決に当たっていくことが多いと思います。

よってまず役割というのは

• どのミッション、もしくはどの課題の解決 (成果創出)を担当するか、そして責任を持つか

を領域、難易度 (シンプルな難しさや達成にかかる時間軸の長さなども含めて)ごとに表現したものだと理解しています。

「単月の売上xx円達成」「xx日までにxxの開発を完了させる」みたいな具体的なものもあれば、「xxの価値提供を可能にする体制とプロセスを構築する」みたいな抽象的なものもあるでしょう。組織に存在するすべての役割が言語化、明文化はされているわけではなく、暗黙的に誰かが担っているようなケースも多いかもしれません。

役職とは何か

前述の通り、組織は専門領域ごとにチームで活動することが多いと思います。そして課題は大小様々存在するので、それに対応する役割も様々です。

おそらくこの状態でも、組織活動自体は可能だとは思います。ただこれは例えば大規模なシステムを作る際に、各クラスやモジュールに

• module_a

• module_b

• module_c

• ...

のような命名で処理を連携させるようなもので、誰が何の責務を担っているのか訳がわからなくなります。コミュニケーション複雑性がめっちゃ高くなります。命名が大事と言われる所以ですね。

なので、

• User

• Client

• Product

• ...

のようにどのような責務を担当するクラス、モジュールなのかを明確にしてシステムを組み立てるように、

• CEO

• CTO

• xx部長

  • 事業部長

  • 開発部長

  • 営業部長

  • ...

• xxマネージャー

• xxリーダー

のようにチーム間コミュニケーションのインターフェース部分 (主に役割の責任者に当たる部分)に役職という形で名称をつけてコミュニケーションの複雑性を軽減するパターンを取ることが多いのではないかと思います。

つまり役職とは

• チーム活動を前提とした組織活動において、コミュニケーションインターフェースを明確にし、コミュニケーション複雑性を軽減するためのラベリング

とでも言えるのではないでしょうか。そして役職には必ず、何かしらの役割、責任が紐付いているべきです。

Userという名前のクラスがユーザに関わる処理を有しているのと、module_aが実はユーザに関わる処理を有しているのでは、だいぶ読み手の体験や認知負荷が変わってくるんじゃないでしょうか。めっちゃ実装詳細まで読み込んで初めて、「お前...本当はUserだったのか...」となると思います。

同様に何のラベリングもされていない普通の社員が大きな目標を達成するためにリーダーシップを発揮しようとしたら、実際に必要なケイパビリティを有していたとしても、最初は「本当にあの人について行っても大丈夫かな？」となると思います。信頼残高を蓄積する所からスタートしなければいけません。

一方、xx部長みたいなラベルを持った人がリーダーシップを発揮したら、「まあxx部長が言うなら、、」といったチート状態でスタートできると思います。まあそれで必要なケイパビリティを有していなければ、信頼を損なうというトレードオフもあるんですけど。

役職ではなく、役割に着目したほうが仕事が楽しくなる説

役職はコミュニケーション複雑性を軽減するためのラベリングであり、そこには役割が紐付いていると述べました。そして一般的に見ても、CEO、CTO、VP of xx、みたいにかっこいいラベルをつける組織も多いですよね。

ここで注意したいのが、

• 組織によって、優先して解くべき課題やコミュニケーションスタイルも様々なので、同じ役職名でも役割は組織ごとに異なる

• 役職に紐づく役割を明確にしすぎると、その枠から抜け出しづらくなり、それが個人の成長機会を奪うリスクがある

という点です。

例えば、CTOってエンジニアなら憧れのような感情を抱く人も多いのではないでしょうか。しかし、その組織が注力している課題、事業フェーズによって

• 誰よりもコードを書き、プロダクト推進のリーダーシップを取っている

• コードは書かず、組織をスケーラブルにするための組織課題に向き合っている

など、その役割は様々です。

よって、誰よりもコードを書くことに自信があるCTO経験者が、組織をスケーラブルにするという経営役割をCTOに期待している組織に転職したら、お互い不幸になるみたいなケースが起こってしまいます。

また役職は強い先入観を作り出すリスクもあります。ラベリングの持つ力は結構強いです。

例えば、エンジニアリングマネージャーという役職に就いたら、なんとなくマネジメントに関係ない役割はやりづらい印象あったりしませんか。これは役職に着目した思考です。とにかくマネージャーらしく、1on1しまくって、ちゃんとみんなの評価をしないと、、みたいな。

実際はエンジニアリングマネージャーという役職には、「エンジニアチーム全体の成果を最大化する」みたいなミッションが紐付いたりするはずです。なので、その達成に必要だと思ったら「まず誰よりもコードを書いて背中を見せていく」みたいな活動も全然アリだとは思うんですよ。これは役職ではなく、役割に着目した思考です。

このように役職の有無に関わらず、役割、「どのミッション、もしくはどの課題の解決 (成果創出)を担当するか、そして責任を持つか」に着目して仕事に向き合うほうが、個人としては仕事って楽しいと思うんですよね。まずは「いかに役割を広げていけるか」にこだわっていくのが個人の成長にもつながりますし、良いのではないでしょうか。

ただし、役割を広げ続け、チーム間コミュニケーションの中核を担うようになったメンバーには役職が適切に付与されるべきだと思います。でないと、組織としてコミュニケーション複雑性が高い状態を維持することにもなるので。しっかりとバランスを取っていきたいですね。

まとめ

とりあえず、

• 役割はどのミッション、もしくはどの課題の解決 (成果創出)を担当するか、そして責任を持つかである

• 役職っていうのは組織のコミュニケーション複雑性を下げるために、インターフェース部分にラベリングしたもの、そこに紐づく役割は組織ごとに異なる

• 役職というラベリングに固執すると、環境が変わると対応できなくなったり、無意識的に自分の成長の足枷みたいなリスクになりがち

• 役割を広げることに集中しましょう

みたいな話でした。今年もよろしくお願いいたします。