ソフトウェアの世界も色々細分化されてきてるので、そろそろソフトウェアエンジニアとプログラマー職人を分けてくれていいと思う。どんな家建てるかの話をしている人とノコギリとかカンナとかの良さの話をしている人は所々用語が同じなので会話が成立してるように見えるけど、実は噛み合ってないから。
雰囲気にてるので一緒にできそうに見えるけど、見てるもの、目指しているもの、報酬体系、キャリアパスも含めて違うので、アーキテクトとみたいな分岐と同じような感じでプログラマー職人も定義されるといいかもなぁ。価値観の不一致は減るだろうし。採用時にもキャリア相談時にも助かると思う。
ちなみにプログラマー職人と職人名称を付けてるのは、定量的に評価できない、画質や音質とかと同じようにプログラムの良さを官能的な良し悪しを語れる人って職人だと思うので。多分そう言う感じで語ってるプログラマー職人の人達、センス以外のワードでの自身の評価基準の体系化は無理だと思うのです。
オーディオだってカメラだってデジタルだから音質も画質も一意に決まるのかと言ったらそうじゃなくて、職人と呼ばれるエンジニアが官能的に調整評価はしているけど、彼らも自身の良し悪しの基準は定量化はできてない。けど実際その手の良さが分かる評論家からは高評価されたりするじゃないですか。
昔はわからなかったけど、最近プログラマーもそういう領域があるとわかってきた。だからそういう職業分類を設けるのはアリなんじゃないと個人的には思うわけです。エンジニアリング観点のコンサルタントもいるんだからプログラミング視点のコンサルタントとかいてもいいんじゃないと思います。
プログラマー職人の方々の顧客はコードを書いてるエンジニアや開発チームや組織であって、そのコードが実現するプロダクトを購入する、または体験する顧客ではないって時点で、プロダクト開発ではなく、研修講師やコンサルタントの方が近いと思うだよね。なので別形態の業種でいいと思う。ホント。
イメージがイマイチ伝わらないけど、要はプログラマからエンジニアになるパスだけではなく、こういう青線のようなプログラミング特化のキャリアもあった方がこれからのソフトウェアエンジニアのキャリアパスとして色々誤解が少なくていいんじゃないのという話でした。
そういうのはプロダクト志向のエンジニア、技術志向のエンジニアという分類で捉えていた。
どちらも成果物としては突き詰めるとソースコードになるのだけど、マインドセットとしては「作りたいものがあるからプログラムを書く」プロダクト志向に対して、「技術を突き詰める為にプロダクト開発に参加する」技術志向。
前者が目的の為にプログラミングを手段としているが、後者は「手段の為なら目的を選ばない」ヘルシングの少佐みたいなタイプ。
キャリアパス的な観点は、前者はいずれプロダクトマネージャ的なロールを志向するだろうし、後者はアーキテクトやシニアエンジニア的な何かになっていくのだろうから何か特別な名前を付けたり制度を考えたりする必要は無いように思える。