正しいとか、コミュニケーションの分断とかいう前に、自分からやることもある

自分はプロジェクトチームや組織の構成を考えるとき、全体の役割分担つまり分掌を考える。役割分担を列に配置すると、行に権限分掌、ロールを当てはめる。組織構造のレイヤーに当たる。前者はピラミッド構造の柱、後者は、階層に当たるイメージだ。

どうしてチームの構造を考えるときに、分掌や権限文章を考えるかというと、機能漏れが怖いからだ。このとき、きっちり分け切ってしまうと本当の縦割りになってしまうので、隣接する役割を若干被るようにデザインするか同一テーマに主従を持たせておく。

こうしたプロジェクトチームのデザインは、プロジェクトのオーナが本来するもので、オーナ自身でできない場合は、デレゲートした役割のプロジェクトマネージャが行うものだと考えている。

ここでプロジェクトオーナが出てくることに違和感を覚えたら、プロジェクトを俯瞰することに馴れていないかもしれない。

それは仕方がないことかもしれない。

SIerのアプリやインフラのプロジェクトチームの一兵卒なエンジニアであれば、視界に入るのはアプリのプロジェクトだったり、インフラのプロジェクトだろうし、アプリもインフラもやるプロジェクトであったとしても、委託先を含めた自社のプロジェクト体制しか知りようがないからである。

サービサーで自社開発、内製化していればプロジェクチームの体制を知る機会はあるが、体制図を作るほどの規模ではないと作らないこともあるので、結果的に、SIerのエンジニアと同じように視界に入るメンツしか知りようがない。このとき、プロジェクトに関わる外注業者は抜けやすい。

ここまで体制図で俯瞰することに関して、プロジェクトチームや組織の権限分掌を絡めて述べているのは、チームや組織の中でのコミュニケーションラインを明確にするツールが体制図しかないからである。チームのスキル表もあるがあれはあくまでもチームの中で持っているスキルやスキルレベルを可視化するものであって、外注業者までは入ってこないし、分掌で担う責任を明示するものでもない。

分掌を分けるとき、ただ分ければいいというものでもない。プロジェクト、組織の特性や外注業者の有無により、線引きはその都度変わってくる。さらに言えば、プロジェクトの最中にチームの洗い替えや分掌の再定義もして当たり前なのである。

そこに必要になるのが組織づくりの軸であり、プロジェクトや組織の意思決定なり、特性を考慮しなければならない。それは体制図を作るプロジェクトオーナや代行するプロジェクトマネジャーの仕事である。

エンジニアに頭の隅に記憶の欠片として残して欲しいことは、自分の担っている役割の視点以外、つまり、お金を出しているプロジェクトオーナから見たときにどのようなプロジェクトの体制になっているかを知って欲しいということである。

全体を俯瞰(しようと情報蒐集したり、把握したり)するスキルは、システムデザインをする際やプロジェクトでのWBSの分解時のスケジュール的な制約を意識するときにとても役に立つからである。

まあ、それを一人ひとりのエンジニアに求めるのではなく、プロジェクトオーナやプロジェクトマネージャ(もしくは配下のチームリーダ)が分掌を説明しろということなのだが、肝心のロールが働いていないことが多いのも事実なのだが。

 

経済学の名著50冊が1冊でざっと学べる

経済学の名著50冊が1冊でざっと学べる