エンジニアとマネジメントの曖昧な境界線

プロジェクトが完了したのでプロジェクトのふりかえりを共有するから出てきて欲しいと招待を受けたので、のこのこと会議室に入り陣取る場所はスライドを映すスクリーンの下手あたりがなんとなく好きなのでそこに。

ファシリテーション役の人は、なぜか棘のある口調で話すのが気になるけれど理由は知らないからスルーしておく。まぁ、そのうち何かわかるかもしれないし。

このプロジェクトマネージャにはこのプロジェクトの途中でなんどかアドバイスをした。なので、プロジェクトマネージャもワタシに対して好意的な対応をしてくれる。一応、そんな間柄ではある。なんというか、メンターとメンティーの関係に近いかもしれない。そう思っているのはワタシだけかもね。

「(厳格に評価すればこのプロジェクトは失敗に分類されるプロジェクトなんだよなぁ)」と思いながら、プロジェクトのふりかえりを聴く。厳格に言えば、と限定しているのはQCDのQは計画どおり、スコープも当初と仕様変更を吸収してリリースした。ただ、スケジュールについては、あるタスクの対応をするためにスケジュールを1ヶ月延長したためだ。

スケジュールを延長した理由が自責だから。1ヶ月延長することについては先方の了解済みで、プロジェクトへの影響はないから総合的な判断を求められれば「成功」したプロジェクトとしてもいい範疇だ。だから、厳密に言えば、と線引きしているのだ。

このプロジェクトも他のプロジェクトと同じようにプロジェクト期間中はあんなことやこんなことやあったようだ。だから、途中で何度か相談にのったわけで。でも、プロジェクトマネージャは周りを頼ってもやりきったんだから十分褒めてあげなければやっていられないだろう。

そうしたあれやこれの中で気になったのは、マネジメントとプロジェクトマネージャとの役割分担について、だ。

そのプロジェクトマネージャはマネジメントとプロジェクトマネージャは役割が違うのだから、プロジェクトマネージャがマネジメントに問いかけたことはマネジメントで処理するべきで、プロジェクトマネージャがそれをやらないといけないなら「マネジメントは存在価値がわからない」と主張していた。

そうした主張を聴きながら頭の中にイメージしていたのはプロジェクトの体制図だ。ツリー型のヒラエルキーを象徴するようなアレである。そうした図は、末端がチーム単位で、そのチームごとの分掌を明記していることが多い。それは、プロジェクトを遂行する上で、作業分担上の抜け漏れを防ぐためである。

その図をイメージしながらプロジェクトマネージャが言っているマネジメントとプロジェクトマネージャの役割の線引きについては、エンジニア、担当のレベルならそうした職務上の役割のバウンダリを設ける考えでもいいと思う。

ただ、担当のシステムエンジニアより上の、SEリーダ以上になったら、横並びでみたときのそれぞれのリーダ同士の役割分担で抜け漏れがないように注意を払うことがプロジェクトを成功させるために必要なことだ。だいたい、そのための体制図なのだから。

では、プロジェクトを成功させる責を負うプロジェクトマネージャとビジネスの責を負うマネジメントの関係ではどうだろう。マネジメントがプロジェクトマネージャの上に置くか横並びにするかはどっちでもいいけれど、お互いの所掌はあるけれど、お互いにカバーし合うことが必要なのは同じなのである。

チーム単位で分掌するのは、その中で担う仕事をちゃんとやりなさい、ということであって、チームの責を負う時点でチームがプロジェクトの成功に向けて何ができるかを考え行動することが仕事に変わる。

プロジェクトが成功するために自分が分掌する範囲を超えてどこまで気を揉むか、それはその人の能力、キャパによるところが大きい。その越えるのりしろ部分の幅が大事なのではなくて、のりしろの幅を持つこと自体が大切なんだ。

それを表現するなら曖昧なグレーゾーンをお互いに持つことがプロジェクトを成功させる1つの要因となるんだ。これを限られた時間で簡単に伝えるのは難儀であるし、聞くプロジェクトマネージャが理解するのもハードルがあるだろう。だって今はそう思っていないのだから。

時間と経験で消化してくれることを期待したいけれど。