優秀な技術者≠技術力

はてなの日記を見ていると、「技術者に対して正しい評価がされない」ということを問題視しているエントリが多いように感じる。これは、はてなで日記を書いている人にプログラム大好きなエンジニアが多いことが要因だと思う。

そもそもとして、SI企業がプログラマ/SEに対して求めていることは技術力ではない。(大げさに言うと)
そこらへんのGapについて納得感のあるエントリがスーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記

いわゆる"業務知識"という名の暗黙知

SI業界が開発するシステムの目的は何か? それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。

http://d.hatena.ne.jp/aike/20080615

仕様書に起こされたものをただそのまま、効率良くプログラミングするだけなら、確かに業務知識の重要性は比較的低いかもしれない。しかし要件をまとめる、仕様を作る、といった部分、さらには提案ベースのものではこれら業務の暗黙知なくして行うことは無理。

特に、企業という観点でSI企業を見た場合、ユーザ企業にとって収益に結びつくような戦略的なシステムであればあるほどシステムと業務は密接であり、それらシステムを提案するということは業務改革のコンサルティングという意味合いも含んでいる。

逆説的なことを書くならば、"業務知識"が付加価値だからこそ「○業界の○用途向けのパッケージなら○×社」みたいな特色があるのであって、"業務知識"が付加価値でなければ、ぶっちゃけどこのSI企業にお願いをしても同じ=安ければ安い方がオッケー、くらいの意味合いとなってしまう。

業務知識に対しての意見が分かれるのは、一言でSI企業と言ってもビジネスモデルの幅も広いし、また業務の幅が広いことが理由だと思う。
受注案件が中心なのか、パッケージを持ち上げてカスタマイズの受注をしているのか、若しくは受注案件であっても直エンドなのか2次請け、3次請けなのかというだけでも業務知識の重みは変わってくる。(もちろん直エンドと比較して、2次請けであれば業務知識は必要とされにくい。)
プログラマ、SE、といったWordだけでは同じ土俵として話が出来ないんじゃないのかなぁ。。

そもそもとして、SI企業で技術力の高さを求められているのか?

もちろん、無よりはあったい方がいい。
しかし、仕事で発揮されてしまうと困る場合も多い。それはどういう状況かというと「設計、プログラムをした人しか理解できない」という状況。
具体的には、あるプロジェクトでA君は「〜という技術を使う設計をすると、非常に効率的にシステムの構築が出来るよ!」と言ったとしても、同じプロジェクトに参加している人がその技術を使いこなしていなければ、それは企業としてはリスクとなってしまう。
ベンチャーとかギリギリの状況でやっている場合だとそれでもGoしちゃうことも多いのだけれど、大きなSI企業ではそのプロジェクトは危ない。
何故なら、そのA君がトラックに轢かれてしまったら、そのプロジェクトは存続不可能になってしまうから。*1


2つ目に、SI企業でも特に大規模な会社となればなるほど、大きな規模のプロジェクトを受注することになる。大規模プロジェクトということは、参加するメンバーの数も多いということだ。そうなると、技術力を要求される人数が多くなるということであり、それは企業にとってはコストとなる。(雇用するためのコストも、経験があるエンジニアの方が高い)
さらには、こちらの方が大きな問題だが、今はIT業界全体で技術者が足りないと言われて久しいが、「必要な人員の数を集められなくなる」という状況になってしまう。
また、下に指摘されるようなことも、一面にはあるかと思う。(個人的には納得感はとてもある)

その前に、そんな知識があるのなら、コンサルになったほうが金も儲かるし、プライベート時間も確保できると思うので、SI業界なんかにこないとおもうけどねぇ。

http://d.hatena.ne.jp/oredoco/20080618/1213784565

人数が足りないと、技術力以前にプロジェクトを遂行できない。



結果として「技術力を必要としない」のではなく、「その企業で多数のエンジニアが理解できる技術レベルで、安定的な開発体制で開発」を行うことのほうがSI企業にとっては効率が良い、と。
もちろん、技術力があった方がさらに効率の良い開発が行える。 期間も短く、リスクも少なく開発が行える。


また、SI企業という観点で見れば、効率が悪くてもそれでも利益が出る見積書で案件を受注すれば良いだけのことなんだよね。

技術力があるメンバーのみで構成されていたら?

これに対しては、「技術力があるメンバーばかりが集まれば解決できるじゃん!」という意見もあるかと思う。
その昔、自身で会社を経営していたとき、その考えで「とんがっている」エンジニアばかりを集めていた。*2
SI企業にいっぱいいるようなふつーのサラリーマンプログラマではなくて、趣味で小さい頃からプログラムばっかりやっていました、というような人たちばかり。

ビジネスモデルもSIではなくてパッケージ開発ということもあったから、尖がっているスキルばかり持っている人たちを集めたんだよね。
何より、「技術大好きで、はっかーぽい人たちの技術力」=お金に出来るという会社を作ってみたかった。

んで、確かに状況によっては非常に効率的だった。お客さんからパートナー企業までみんなビックリする。しかし、それでも上記と同様の問題は発生してしまう。
会社を経営していた頃に、ある開発プロジェクトで社員のH君がとても効率的な設計をした。確かに生産性が向上する方法だ。で、その方法で開発プロジェクトがスタートしたのだけれど、途中でトラブルが発生してしまった。結果としては、H君以外が触れない箇所がたくさんあり、他の人たちは手伝いたくても手伝えないという状況になり、彼だけが家に帰れないという状況になってしまった。

結局のところ、最終的に出た結論は、「プログラム効率がいいからといって、全体で見たら効率が良いとは限らない」ということ。
レベル感の違いはあれど、大規模なSI企業の状況と、本質的には変わらないのかも。

*1:ExtremeProgrammingで言うところの、まさにトラックナンバー

*2:採用は大変だったよ。IRCで声かけたり、紹介ばかり、、って感じで。