ソフトウェア開発の直接部門と間接部門

ソフトウェア開発の支援をテーマに活動しているため、（対象というとアレですが）対象となるソフトウェア開発企業の方と大量に打合せをします。打合せは、講演の後に声をかけられたことがきっかけであったり、単純に何かご一緒できませんか？というお声がけをいただいたり、こちらからお願いしたものであったり、個別の検討テーマの説明会であったり、古くから懇意にしていただいていたりと多岐にわたります。検討のフェーズもいろいろありますが、そのあたりは別途書くことにして、今回は割愛します。

また、共同検討をご一緒する相手も直接部門（いわゆるライン）の方の場合もあれば、間接部門の方の場合（いわゆるスタッフ）もあります。間接部門と比べると直接部門の名前を挙げてもあまり意味がないのでここでは省略します。間接部門は、各社で位置づけや名前は異なるものの、生産技術部、品質保証部、研究開発センタ、技術センタ、PMO（Project Management Office）、SEPG（Software Engineering Process Group）というような名前が多いようです。他にもありますが、企業を一意に識別できるような特徴的な名前のものもありますので、このくらいで。

直接部門と間接部門の関係はある意味永遠のテーマなのかもしれませんが、企業文化として、お互いを認め合うことが自然にできているというところが存在します。その文化を醸成し、維持されていることにいつもすごいなぁと思います。そうでない場合、組織の構成や権限付与や役割分担等いろいろと工夫や試行錯誤を繰り返されているようです。特にソフトウェアは計測や可視化が難しいためか、直接部門の発言力が強くなりがちで、そのあたりのバランスをとるために品質保証部門を経営陣の直轄組織にしたり、リリース判定の決裁権を与えたり、差し戻し権限を与えたり、プロジェクトの停止権限を与えるところもあるようです。

私なりの感想ですが、まずは部門に関係なくいいものを作る、協力しあう、認め合う、という文化をつくり、それを維持することが最も重要だと思っています（そんなことはわかってるけどどうやってそれをするんだという声が今にも聞こえてきそうですが．．）。次に、直接部門の仕事をなるべく間接部門で引き取り、直接部門が残された仕事に集中できるようにする、明確で理解が簡単な役割分担をする、あたりが重要ではないかと思っています。逆に、特定の個人に対して責任やペナルティを負わせる、両部門でほとんど同じ内容を実施してお互いの抜けを指摘する、等はなるべく避けるべきと思っています。