システムエンジニアの技術的な不満を誰が拾えばいいのか


マトリックスの形態のプロジェクトを取っている組織なら、その組織のメンバは所属するマネージャへの指揮命令系統とプロジェクトの指揮命令系統の2重のラインを持つことになります。組織=プロジェクトや組織=業務なら組織のマネージャとプロジェクト・業務のマネージャが同一になるのでそうしった指揮命令系統のラインの負担が増えるような課題は生じないことになります。


まぁ、でも人的リソースを機動的に配置しようとするとマトリックス組織になってしまうし、組織=業務であっても繁忙期は応援を他の部署から貸し借りするような文化があると前述のようなことは起きるわけです。


マトリックスの組織のときに生じる課題は指揮命令系統のようなラインの他にシステムエンジニアのアサインや評価に関する課題も出てきやすいです。それは従事するプロジェクトのマネージャと組織のマネージャが同一でないから。直接にプロジェクトへの貢献を目で見ることは限りがあるし、面談でも限りがあるからです。


あと、システムエンジニアですから技術についてもメンバと組織のマネージャとのギャップは生じやすいです。その生じた技術のギャップの結果はその組織から退場する、つまりやめてしまうということになります。これはそれまで掛けた育成の時間もコストも組織の視点から言えば勿体無い話です。


じゃあ、技術に聡いマネージャを置いたらいいじゃん、と思うわけですがそうすると、マトリックス型の組織だと1人のシステムエンジニアは、組織のマネージャ、プロジェクトマネージャ、技術のマネージャの3人のマネージャを相手をする必要があるということになります。組織=業務の形態の組織なら組織のマネージャとプロジェクトマネージャは同一になるので1人少ないですが。


これ、システムエンジニアの育成についてどう責任分担すればいいのでしょうね。人事権を持つのは組織のマネージャですね。プロジェクトマネージャはそのプロジェクトの中での指揮命令です。技術はシステムエンジニアの育成になるのでしょうか。


体力のある組織なら3つに分けたいのであればお好きにどうぞ、でもそれを相手にするシステムエンジニアはちょっと大変なのでそこは考慮が必要ですね。3つのコミュニケーションを取る分のコストはかかりますからね。


じゃあ減らすかというと、3つのうちどれをまとめるかという話になります。そんな単純でいいのかってのはあるけど。


そうすると結局、プロジェクトの形態を組織とどう整合性を取るかというプロジェクトと組織の話になってしまうんですよね。それって組織の事業に依存するすんですよ。事業が組織の形態となるんですね。プロジェクトごとにチームを編成するならマトリックスにならざるを得ないです。


そうなってしまうなら、組織なり技術なりプロジェクトのロールを兼務できるスキルセットを持っているマネージャを経営層は選べよ、ってことになります。


経験から言えば、マネージャが技術のしくみを理解できて、システムエンジニアの希望をよく聞いて、組織の目標とシステムエンジニアに動機付けをするのがベターですよ、としか言えないんですよねぇ。そのばが目標管理なんですけどねー。