受託開発のゲージに押し込まれコードを産み続けるエンジニアにはプロダクトマネジメントはできない

プロダクトマネジメント、特にプロダクトオーナとして完成イメージを持ってプロダクトを作ると言う点において、全てのエンジニアが共通して持つことが必要なスキルだと思うのです。

もう、必要とされているのはプロジェクトマネジメントができるのは当たり前で、プロダクトマネジメントをできるエンジニアが必要とされているのです。

もし、エンジニアとして生き残りたければ。ワーカーとしてではなく。

エンジニアが一番理解できるポジションにいると言う意味

エンジニアは顧客が業務課題をITで解決するための策をシステムとして提供します。見方を変えると、要件をどう実現するか一番理解しているのはエンジニア自身であると言うことです。

これ、すごく大事なことなのですよ。

なぜかですって。

顧客の業務課題の解釈力が求められるし、それを様々な制約に縛られながらも実装し、顧客が手に入れたいタイミングでリリースしなければなりません。その完成イメージと工程を描けるのがエンジニアだからです。

え、今までのシステム開発と同じじゃないかですって。同じですけれど違います。言われたまま作るのではなく、専門家としてプロダクトを適正な状態で実現するからです。

理解も発想もできないし、しようともしない

これは今までの受託開発に携わるエンジニアには発想できません。指示待ちエンジニアにもプロダクトマネジメントは理解できません。

なぜなら、自分自身でシステムの完成イメージを持つことをしないから。

ゲージの中に押し込まれ、出て来た仕様書を啄んでプログラムを産むだけの存在になっている、ちょっと表現はアレですが、でも、あながち外してもいないでしょう。

じゃあ、リーダクラスはどうかと言えば、ゲージに押し込んだエンジニアに仕様書を配って、そのあとのコードを集めている業者そのものです。

エンジニア自身が自発的にシステム全体の完成イメージを持とうとし、自分の理解のために全体構成図を描こうとする人はどのくらいいるでしょうか。

プロジェクトがあったとしてそれを書くのはアーキテクトかプロジェクトマネージャだけです。なぜなら、プロジェクトマネージャは完成責任があるし、それをデザインするのはアーキテクトだからです。

他のエンジニアは分業が当たり前、自分の目の前の仕事だけをこなすことが当然と思っているのですから。

受諾でプロダクトマネジメントは存在しなかったか

そんなことはない、と思うのです。少なくとも純粋なプロダクトマネジメントとは遠いかもしれませんが、プロジェクトマネージャやアーキテクトは受託開発のエンジニアの中では一番プロダクトマネジメントに近い存在です。

ソリューション開発と言うジャンルもあります。これはパッケージをカスタマイズしてソリューションとして提供する形態のビジネスです。

これもパッケージを最適に使うため＝フィット率をあげる＝アドオンを極力せずにカストと業務を変える方向に持っていこうとするならば、やはり完成イメージをもち、適切なシステムを構成しようとするのは、受託よりはよりプロダクト（もともとのパッケージがプロダクトなので）の概念を持っていなければソリューションビジネスが成り立たないので。

ただ、ソリューションビジネスもパッケージソフトウェアを利用するビジネスなので、大元のパッケージを作り上げ、売ると言うところはすっぽりと抜けているけれど。