プロジェクトエンジニアリングを調べたら

プロジェクトエンジニアリング（PE）ってのを聞いて、こりゃなんだっけか？　と思って軽くぐぐったりしていると、すこし興味深い記事に。
最終回 なぜエンジニアリング会社は優秀なPMを育てられるのか | 日経 xTECH（クロステック）
ちょっと前の記事でもあり、何気に見過ごしていたのだろう。

でも、エンジニアリング業界ってのがこの世にはあって・・・（そうそうプラントとかやるところらしいけど・・・・）、そこでは、プロジェクトマネージャを中心とした体制を引いているよう。しかもチームとしてだけどね。

プロジェクトエンジニアって職種があるのもちょっと新鮮。（新鮮って、本来逆で、先達のことを知らずこのIT業界にいて、単に知識がないだけなので、あっちにしたら迷惑ね）
で、何に興味を引かれたかというと、プロジェクトの体制を組むときに、プロジェクトマネジメントチームってのが独立して、存在するってところかな。普通、IT業界のSI型だと、PM（×１）、サブPM（×３）、リーダ（×６）とか・・って感じでしょ。でも、根本的に違うのは、サブPMとかって、下手すると設計担当と兼務していたりするわけで、設計チームの代表でもありながら、プロジェクトマネージをするってところかと。
プロジェクトマネジメントチームを独立して編成し、PM、PE、PMOみたいな形で、実際の設計や製造、テストなどを実施するチームと、相対する形で存在させる。
開発チーム（たとえば、ソフトウエアエンジニアリングチーム）は、設計リーダや製造リーダ、QAリーダ、テストリーダ等がいて、メンバを持つ。開発を統括する人をこれまでは、PMといっていたが、SWEチームの統括者として定義する。で、各リーダーに対してPMチームが張り付く、二人三脚で実施する。進捗や課題解決、問題調整など。
たとえば、設計そのものに責任を持つ人と、設計上の問題をプロジェクトとして可視化し報告する人、全体の情報をフィードバックしたりする。

そんな人を増やしてどうするの？とかいうけど、実際そうなっているでしょ。サブPMだか、サブシステムLの下には、本当に実施上のLがいたりして。ええ、じゃあ、単価の高い人を一杯育てるの？とか思うかもしれないけど、実装をする人たちではないので、そんな無茶な人数にはならんだろう。

マネジメントチームがあらゆるプロジェクト上の問題を把握し解決する。その間にも、設計者や開発者は自分の役割にある程度は集中できる。
コストを別にしてというか、やりくりの部分をとりあえず棚に上げて、実際どういうフォーメーションが正しいのか、それを考えたほうがいいとおもう。

今、ここまで書いて思ったのは、そういうマネジメントチームがうまくできれば、発注側に生息するPMOと言う名のコンサルとかを減らすことできるんじゃね？って。役割を何重にも兼務出来る人ってそれほどいるわけじゃないので、その人たちがボトルネックにならないように（ここでは、いろんなものを背負ってしまうサブPM＝設計L＝テストL）のような人。

要員のボトルネックを解消するだけでプロジェクトはかなり機能すると思ったりするなあ。

理想的なこと言いすぎかなあ。