会社には、殆んどの場合に部署・組織があります。多くの社員が居るわけですから、それぞれの役割を整理して明確にするために部署を作り、一定の単位で運営していくことが必要になります。一般に部署の最小単位は、少なくて２－３名、多くても１０－２０名というのが多いのではないでしょうか。また、最小単位の名称は、課や係、あるいはチームやユニットと呼ばれることが多いと思います。
ところで、部署名の命名というのは意外に難しいものです。上位の組織、例えば、営業本部、システム事業部といった組織は比較的容易なのですが、課や係となってくると少し難しくなってきます。というのも、部署の命名は組織の分け方によって決まるところが多いのですが、組織単位が小さくなってくると、組織の分け方をきっちりとしたルールに基づいて行うことが難しくなってくるからです。
例えば、システム開発を１５人でやっており、企画業務が１名、管理業務が１名、総務業務が１名、残りの１２名が実際の開発を行っているとしましょう。そして、１２名の開発者は、会計ソフトを開発しており、基本設計が４名、法人用展開開発が４名、一般パッケージ向開発が４名と仮定します。
このように各人ごとの分担が綺麗に分かれていれば組織名の命名は比較的容易です。企画係３名、基本設計係４名、法人開発係４名、パッケージ開発係４名などとすれば良いわけです。ところが、実際はそうは簡単にはいきません。業務が、個人別にきっちり分かれていたら良いのですが、そういうことは少ないからです。基本設計している人の中には、時間の半分を法人やパッケージ開発している人も多いでしょう。法人開発部が忙しい時は、しょっちょうパッケージ開発部から応援をしているかもしれません。そうなってくると、部署名が足かせになってくる場合があります。基本設計係に所属しているんだから、法人用展開の仕事をするのはおかしいと考える人も出てくるのです。
本来、組織は柔軟にリソースをやりくりすることでパフォーマンスを大きく上げることが出来ますが、部署名に役割を書いてしまうと、そのような不具合が発生します。ただ、これは一概に悪いとは言えません。例えば、もう一つの命名方法として、企画係３名、第１設計開発係４名、第２設計開発係４名、第３設計開発係４名、とする方法もあります。これにより、先に書いたような不具合は減りますが、一方、どの設計開発係で何をやっているかが周りから見えなくなったり、本人たちの役割があいまいになって仕事に対する責任感が減ってしまいます。法人開発係、などと明記した方が、最終責任はその部署がとる責任感が出てくるものです。
このように、組織名というのは、はっきりしすぎるとリソースの融通が効きにくくなり、曖昧にすると責任感が薄くなるという相反する特徴があります。ですから、仕事の内容や社員の動向を見ながら、実態をうまくコントロールできるような組織名にしましょう。