隘路

「ワインを注ぐ量は、ボトルの首のところで決まるのさ。」

システム開発の会社に就職すると、雑用、試験、プログラマー、システムエンジニア、リーダー、マネジャーとステップアップしてゆくのが一般的かと思う。そのせいか、マネジャーと云うのは開発技術に長けていて当然と云う考え方もあるようだが、これには賛同できない。必要な知識、技術、経験が大きく異なるからだ。もちろん、まったく知らなくてもいいとは言わないけれども、間違った経験を積み重ねてしまう弊害があるし、過去の技術や失敗経験を踏襲するような判断をされても困る。それよりなにより、肝心のマネジメント能力が不十分なことの方が問題だと思うのだ。

マネジメント能力を明確に定義することも、客観的に評価することも難しく、現状はおおよそ年齢 (と暗黙の階層) で役割が決まってしまっている。一つ大きな問題だと思われるのは、そんないい加減なところに、あまりにも強力な権限が集中していることだ。マネジメント能力を定義できず、評価もできないにも関わらず、ほぼシステム開発の全権を握っていると云うのは、あまりにも危険な組織モデルではないだろうか? もちろん、権限を行使する人もいれば、適切に委譲する人もいる。このあたりは、それぞれのチーム状況や個性によって異なるかとは思うが、基本的には明示的な権限だけでなく、暗示的な権限もすべて危険なところに一任されている。

どんな技術を採用するか、どんな進め方をするか、どんな成果物を作るのか、どうやって状況を把握するか (あるいはしないか、できないか…)、誰を採用し、誰を除外するのか、誰に仕事を割り当てるか、いつ、どんなイベントを行うのか、それが実行可能なのかどうか、いったいどのぐらいの作業ボリュームがあるのか…。

他にもいろいろあるんだけれども、まったく何も分かっていなくても、齢を重ねただけで、「決めようと思えば決めることができる」のが山ほどある訳 。決めるものではないものでも決めることができる。ボリュームとかね。

どんな技術者でチームを構成していようと、最終的にそこを通る。良い案が理解されずにつぶされたり、悪い案や間違った情報が素通りしちゃったりすることになる。これは、めちゃめちゃリスキーなことではないだろうか?

…しかーし、ここに有効な打開策を思いつかないのだ。もしかして、これはあきらめるしかないことなのかもしれない。

システム開発の問題を解決するべく、いろんな技術や方法論が提案されているけれども、結局のところ隘路をどないかしないことには、事態は改善に向かわないんぢゃないのかと思う、今日この頃…。