分かった。

この2年くらい、いろいろと自分の仕事について考えてきた。
いま、母と電話していて、気づいたことがある。
2年前、私がSI業界をやめて、行政書士になると言い始めた。それは

• いま、自分が勉強していて楽しいものを仕事にしたい
• プロフェッショナルとしての誇りを持って仕事をしたい

という、2つの理由からだ。

当時、ちょうど行政書士の勉強が珍しく続いていたし、SIerでの仕事は目標を失っていた。

「自分の会社の技術というものを持って、それを売って仕事をするのだ」ということをお題目に上司を数年に渡って説得し、ようやっとプロジェクトが出来たのだが、その目的は「開発標準化のためにフレームワークを作る」という口当たりの良いものに変わっていた。つまりは、「自分の会社の技術」というものをビジネスモデルにするつもりがない会社だったのだ。要はミスマッチだったのである。

それがSIerという区分けで正しいのかは分からないが、SEという「エンジニア」の集団である会社は、自らの技術を持って市場に出て行かねばならない。その技術は、エンジニア個々の技術ではなく、会社としての技術でなければならない。

今のSIerにも色々な種類がある。顧客から直接受注するプライマリーベンダーは、名だたる大手のSIerばかりだが、こういった会社にとって技術は重要ではないかもしれない。より重要なのは顧客要件をシステム化につなげるコンサルティング能力であり、システム開発案件でのプロジェクトマネジメント能力である。

コンサルティング能力には「技術力」の匂いがしなくはない。だったら、会社としての技術力を云々するより、コンサルティングファームのように、個々のエンジニアの技術力を最大限に信頼してプロフェッショナルとしての仕事をやらせるようにすれば良いのである。それには個々のエンジニアに非常に高い技術力と、プロフェッショナルとしての信念が必要になるのであって、SIerが多くの人を揃えて、紋切り調にやらせる必要はない。

プライマリーベンダーから仕事を請けるセカンドベンダー以降には、大差がないかもしれない。彼らは技術を持っているかもしれない。ただ、技術を持っているのは個々のエンジニアであって、会社としての能力はプライマリーベンダーに人を出すジョブマッチ能力だったり、切り出されたシステム要件を請け負う小規模なプロジェクトマネジメント能力である。

いろいろな種類があると言ったが、さてこうやって考えてみると、「技術力」たるものを会社が持っていることはほとんどないのかもしれない。

会社が持つべき「技術力」は、個々のエンジニアの技術力からノウハウなどを抽出し、開発プロセスやナレッジデータベースにまとめられるのかもしれないが、正直言うと、ほとんどあてにならない。特に開発プロセスなどは、プロジェクトマネジメント領域のノウハウに過ぎず、それを技術力というのは、何か取り違えている。

要するに会社が持つべき「技術力」とは、製品としてしか表現できないのではないかと思われる。
製品には、パッケージプロダクトもあるし、最近はWebサービスもある。いずれにせよ、そうした製品を作り、販売し、顧客への導入支援をするような仕事の方が、SIerよりは自社の技術（製品）に誇りを持ち、ひいては自分の仕事にも誇りを持つことが出来るようになるのではあるまいか。

さて、そのような自社の技術（製品）を持たない会社に入ってしまった場合、SEのやるべき仕事はプロジェクトマネージャに振られた目の前の仕事を、自分の能力で片付けることであり、目指すべきキャリアはプロジェクトマネージャにほぼ限定される。いや、それが悪いといっている訳ではない。

SEのやる仕事は、流れ作業で出来る仕事はほとんどなく、自分自身の能力や創意工夫が求められる。そこに面白みを感じることは出来る。プロジェクトというもので仕事をするから、その人間関係が良ければそこから得られる満足感もある。プロジェクトマネージャにしても、自分に与えられれた仕事を、様々なメンバーを使い、組織を率いて成功させるのだから、その満足感も非常に大きい。

ただ、この仕事はレバレッジが効かないような気がする。1+1=2～3にしかならないような、そういう仕事である。小分けされた仕事を1人のSEが片付ける。その集合体としてシステムが出来るに過ぎない。いや、プロジェクトでシステムを作るなんていうのは大抵そういうものであって、それは製品を作る場面においても同様だ。ただ、そこで出来た製品をテコにして大きな成果を上げることが出来る（つまりはレバレッジを効かせられる）のは、実際にその製品を使う側である。その製品が自社のものであれば、自社が大きな成果を得る。しかし、SIerの場合、作ったシステムは顧客のものであって、顧客が大きな成果を得る。だから、SIerの場合、どういうシステムを作るか（What）ということについては無関心になりがちで、どうやってシステムを作るか（How）ということにばかり興味が向くことになる。

私が「自分の会社の技術というものを持って、それを売って仕事をするのだ」というお題目を唱えていたとき、私の頭の中には「What」があった。作ろうとしていたのはフレームワークだから、全体としては「How」なのだが、その中で使う「What」に私の興味があった。それが、SIer内部のプロジェクトとして「開発標準化のためにフレームワークを作る」という、完全なる「How」に目的が置き換わったのである。とはいえ、それがSIerたるものだから、「What」を期待した自分が悪いのだろう。

結局、私の興味は「How」ではなく「What」にある。ノウハウとしてではなく製品として結実することにエンジニアとしての喜びを見出すことが出来れば、非常にやりがいのある仕事として感じられるのではないか。そう分かった。