受託調査＆研究補助→ユーザー企業コンサル→通信事業者コンサル→Web企画構築→金融SE→研究・コンサル→パッケージベンダ・マーケ→パッケージベンダ・技術渉外のおいらが来ましたよ。
こんなことをいっては「上流」にいる方々には失礼かもしれませんが、IT業界は上流にいるほど得になるような構造になっています。それぞれのプロジェクトについて自分のところで十分な経費を確保してから下流に流しますので、下流にいるほど仕事がきつくなります。それをうすうす感づいているから、若い人は少しでも上流に行きたがります。PGをしばらく勤めたらSEに、SEを少しやったらコンサルに。産卵まぢかの鮭でもあるまいに、自分の技術レベルも分からないまま、やみくもに次のステップを目指そうとする。
実はプログラムを書かなきゃいけない仕事ってやったことないんだけど、Web企画構築の時はベンチャーで大手ISPに提携を申し入れ「お前らに顧客データを預けられるか」と指摘されサクッと今風にいうOpen-IDモドキを設計してRubyでサンプルコードを書いて口説き落とすついでに特許申請し、金融SEの時は腐った仕様書を書き直して元請と戦ってPGが不慣れなJavaでのXMLの扱いで行き詰まればサンプルコードを書いて渡し、渉外として技術の仕事から離れてからも大学でOSカーネルの授業を受け持って、今だって面白いプロジェクトを見つければソースを追っかけることもある訳で、結局のところJob Descriptionがどうなっているかではなく、本人の志とか心がけの問題だろ、とか思うわけですよ。
で、残念なことに下請けとして搾取されて余裕がないと勉強する時間も心理的余裕もない訳で、上流に行く機会があれば行けばいいんだし、仕事でコードを書かなくなったって看板に負けないよう自己研鑽しろよ、自分の立場が少々変わったからって下流にいた時代を忘れずに下請けをいじめず、時間さえ許せば周囲に頼んでいる仕事を自分だってできるんだ程度に技術も押さえ、PGとはPGのコトバで会話できるようになっていなければ、それって立場は上流コンサルかも知れないけど単なるガキの遣いだろ、とか思う訳だ。
頭は空っぽのSEとかPGって僕も見たことあるし、困ったことにバブル世代とかに多いんだけれども、一般化するのは良くないよね。あと、その原因が企業のアウトソーシング戦略にあるというのは一面の事実ではあるけれど、経営者だって馬鹿じゃない訳で、アウトソーシング戦略に向かわざるを得なかった時代状況とかを考えなきゃならない。
著者の指摘するVBで再びPGとSEの分離した1993年から1998年くらいまでって、世の中はバブル崩壊で経費節減まっしぐら、ちょうどバブル絶頂期に流行り始めたオープンシステムで他社製オフコンのリプレースを続けつつ、如何に自社でロックインした金城湯地を守るか、みたいな議論が日経コンピュータとか賑わせていた時代ですよ。
市場のパイ全体が急激に縮小する中、従来の延長線上でやっていける世界は従来のエンジニアを使いつつ、売上を維持するには他社の市場を攻める必要があって、そこは費用対効果の高いオープンシステムを提案する訳だけれど、自社にエキスパートが足りないと外から引っ張ってくるしかない、けれどどこまで経済が落ち込むか分からない中、なかなか新規にプロパーで雇うことも難しく、みたいな状況だったんじゃないかと推察するんだが、当時ぼくは中学生とか高校生で、親父の持って帰ってくる日経コンピュータや日経オープンシステムを読み漁っていた耳年増に過ぎなかったんで、本当のところはよく知らない。
ともかくPMOができてプロジェクトの採算管理が厳しくなった数年前までの10年近く、大手ベンダから話を聞くとメインフレームは漸減傾向ながら黒字、UNIX系はトントンで、PC系は恒常的な赤字みたいな赤裸々な現実があった訳だ。別にPCが儲からないというよりは、もともと人件費や販売管理費が高い上に、ソフト開発の見積もりの甘さをハードの高い利鞘で補っていたことの矛盾が顕在化したり、オープン系は競合が多く競争価格に落ち着くから単価を上げにくいとか、そういう事情もあったのだろう。いずれにしてもオープン系は儲からないけれど、他社に客を取られるよりは請けた方がマシ、みたいな戦略的な判断もあったんだろうし、いずれオープン系で儲かる体質の会社にしなきゃ生き残れない、みたいな展望もあったに違いない。
という訳で、オープン系への移行過程に於けるSEとPGの分化、PGスキルの専門分化って、90年代から2000年代にかけての技術動向や経済情勢、SIerの経営状況を踏まえないと理解できないし、攻めのコスト削減で戦略的アウトソーシングに舵を切った訳ではなく、スキル的には高くないCOBOL/RPG/JCLしか使えないPGを食わせつつ、縮小しつつあるパイから拡大しつつある市場へ踏み出す上での苦肉の策だったんじゃないの？という気がする訳で、あまりSIerの経営者を責める気にはなれない。
にしてもだ、僕が大手SIerのプロジェクト建て直しでナンチャッテ金融SEをやった2001年ごろ、ちょうど現場で技術的な決定を下す課長補佐クラスはバブル入社世代だった訳だが、彼らは本当に酷かった。Webアプリの仕様書を起こすのにTCP/IPがパケット通信であることや、HTTP通信がステートレスであること、CGIでできること、できないことといった超基本的なことを理解していない。プロトコルのシーケンス図も無茶苦茶。仕方なく動くように全て書き直すんだが、そうすると元の仕様書を起こした係長クラスが面子を潰されたと頑なになり、押し問答で何時間も会議が終わらない。途中から技術開発部門から事業部に異動してきた、趣味でプログラムを書く別の課長補佐が取り持ってくれたお陰で僕の提案した仕様変更があっさり通るようになったが、あの膠着状態が続いていたらカットオーバーできなかったのではないか。閑話休題。
プログラムって自分で書いてみると難しいって分かるし、僕ははっきり自分に向いていないと思ったから足を洗ったけれども、ひとに仕事を頼むんだったら、苦手であっても何を頼んでいるか理解くらいしている必要はあるだろう。特に最近は昔と違って新しい技術が次々と出てくる訳で、PGやSEの生産性だけでなく学習曲線や適正も的確に把握していなければ、正しい工数見積もりなどできるはずがないし、部下のキャリアパスを考えてやることもできないのではないか。マネージャとして、下請けとしての苦労を充分にしたことのない僕が書いてもキレイゴトになっちゃうけど、仕事でごりごりコードを書くかは別として、sample codeを一通り眺めて、tutorialのwalk throughくらいやってからでないと、直感的に工数を理解できないし、プロジェクトが行き詰まった時の解決策も出てこないと思うんだよね。
という訳で若い技術者は自分のスキルを卑下することなく、上流を目指せるならガンガン目指せばいいし、時間やココロの余裕を持って自己啓発できるに越したことはない訳だけれど、コードを書かなくても構わなくなってからも、自分の関わっている技術の全体像を把握できる程度に、ちゃんと技術を勉強し続けたほうが、結果的に高いパフォーマンスを出せるんじゃないかな。で、PGにはPGのコトバで語り続けて欲しいし、願わくば技術者が技術を極めることで報われる世界を、日本のどっかにつくれるといいよね。日本の製造業だってそうだけれど、素晴らしい技術者に、安心して技術に打ち込める環境を提供できない会社って、どっかで伸び悩むんじゃないかな。