糊になる人、潤滑剤になる人

プロジェクトを大人数でやっていると、モジュール単位であったり、コンポーネント単位であったり、ブロック単位であったり、何らかの単位で、それぞれのインターフェースが存在することになる。というか、そうやって分割して複雑度を下げて設計することが望まれている。そんなときにそのインターフェースであったり、個々の要素の責務を決めてあげる仕事がアーキテクトの仕事になるわけだけれども、結局のところ、界面を決めるというところでモジュールとモジュールの糊になる部分を担う人がアーキテクトだと仮定してみる。（それだけじゃ全然ないけれど）


でも、実際に作り上げるものではなくて、それらを作っている人たちは、上手くコミュニケーションができずにいることが多い気がする。「あっちのモジュール担当の人にお願いしたいけれど、大変そうだし、言いづらいな」とか「今忙しそうだから声かけるのは気が引けるな」とかだけではなくて、原因には、もっと政治的なものまで含まれていたりする。


そんなときに、情報を上手く滑らせて横流ししてくれたり、なんとなく各担当の意見を吸い上げて、意見をすりあわせたりする、潤滑剤みたいな人がいるだけで、全然物事の段取りが変わってくる気がする。バリバリに設計や実装をしているわけではなく、マメに何かを整理しているわけでもなく、いつもフラフラしていて、雑談ばっかりしていて、でも、いろいろ気にかけて動いてくれる、少しアンテナの高い、ちょっとウザイかもしれないくらい人。誰かに尊敬されているわけでもなく、かっこいい仕事をするわけでもなく、具体的な成果が出るわけでもなく。でも、その人がいないと、全体が回らないような人。むしろみんなから言いように言われてしまいやすい人。そうゆう人が実は必要不可欠だったりする。かっこいい名前の役職の人ばかり注目されるけれど、そんなスーパーマンみたいな人は忙しくて下々の気まで回らない。



これをマネージメントプロセスの仕組みでいろいろと解消する方法はあると思うけれど、結局はどの切り口で分けたのかが変わるだけで、分けた部分には、そうゆう役割が何かしら必要になる気がする。本当はプロジェクトのリーダーやマネージャーがやるべき仕事なのかもしれないけれど、みんながみんな、できるわけでもないので、そうゆう潤滑剤の役割に名前をつけたい。


リーダー、マネージャー、アーキテクト、そして、潤滑剤の人。残りはメンバー。（もっと役割ある人はいっぱいあるけれど）

潤滑剤の人、その名は「オイルマン」。
エンジンの主役のシリンダーとピストンの部分も潤滑剤がなければ、全然力を発揮することはできない。
そんな感じの人。エンジンオイルだとかっこいいので、もっと地味でもいい。ドアにつける油でもいい。


う〜ん、ださいネーミングだけど、そんな人が必要なんです。
糊もいいけれど潤滑剤の人が欲しいのです。
かっこいい仕事じゃなくて、緩い仕事をしてくれる人が欲しいのです。


潤滑剤っていうと変な方向を想像してしまいがちだけれども、こんな本がありました。