エンジニアが無能なプロジェクトマネージャから身を守るためには

これまでエンジニアのスキルには、エンジニア自身を形成する基礎スキルと技術スキルの2つの軸があると述べてきた。過去ログを調べるのが面倒な人向けにおさらいすると、基礎スキルと技術スキルは次のとおりだ。

基礎スキル…問題提起、課題抽出、ゴール設定、解決方法のアプローチ、解決の推進力、チーミング、プロジェクトマネジメント力、交渉力、課題解決に対するマインドなど
技術スキル…方法論、アプローチ、手法、プログラム言語、適用時術など問題解決を実現する技能

エンジニアのキャリアを経るに従い、身につけるスキルのウエイトは変わっていく。

基礎スキル　＜　技術スキル　→　基礎スキル　＞　技術スキル

技術スキルの技能は、とてもわかりやすい。手法を身につけ、実践の場で適用し、アウトプットしているかで判別できる。一方、基礎スキルは定性的で、身につけた基礎スキルを発揮しているのかどうか、わかりづらい。例えば、プロジェクトマネジメント力は、プロジェクトマネジメント自体は手法で、技術スキルであるが、それを活用してプロジェクトをキャリーする実行能力は基礎スキルで求められる。

ところで、この基礎スキルと技術スキルには共通項がある。

技術スキルとしてのプロジェクトマネジメントは、プロジェクトをマネジメントするときに必要なプロジェクトのリスクコントロールの方法論である。プロジェクトマネジメントと言えばPMBOKであるが、PMBOKはプロジェクトをコントロールするプロセスの定義とフローになっている。

基礎スキルのプロジェクトマネジメント力は、プロジェクトを推進する能力であるから、プロジェクトのゴールを実現するプロセスをプロジェクトマネジメントの観点からリスクコントロールするためにデザインする。

技術スキルはモデルのプロセスであり、基礎スキルは現実の対象に合わせたプロセスである。

プロジェクトの開発手法の違いでの成功率などは、プロジェクトの特性をろくに考慮せずに適用したことが原因であるが、適用した開発手法のプロセスの理解も知識も十分でないままに実行策としてやってしまったことが直接の原因である。

とは言え、システム開発のプロセスを定義した標準的なモデルが世の中には存在しない。ウォーターフォールもアジャイル開発（多くの手法があるが）も、同じだ。組織によっては、組織の中で標準化をしているところもあるが、あくまでも『組織の中で』である。それらは組織の集合知をまとめたものだから、組織ごとに名前がついていたりするし、実際に適用するときにはもれなくプロジェクトに合わせてテーラリングすることを要求している。

共通項というのは、標準なプロセスと標準なプロセスを適用するためには、プロセスがキーであり、ゴールを実現するプロセスを見極められなければ上手くいく確率を下げてしまう。

プロセスと聞くと標準を押し付けられたり、手続きが多くてやりたくないと脊髄反射するのは、開発手法の選定、テーラリングが間違っているか不十分なのが原因なプロジェクトばかり参画していたからだ。

そうした被害を受けたくなければ、エンジニア自身が技術スキルと基礎スキルでプロセスを学び、プロセスの実行能力をあげる必要がある。それを無能なプロマネに任せていると…。