「作る技術」が便利に簡単になっていけば、エンジニアに求められるスキルセットの変化は当然発生するとは思っていましたが、いよいよそういう新たな差別化の時代が明らかな傾向としても出てきたんだなと思う今日この頃です。
その傾向は、IT出版業界の編集者さんと話をして顕著に感じているのです。
IT出版業界から読み取れる傾向
この頃IT系出版社の編集担当さんと会うことが多く色々と情報をいただいています。
出版社の編集担当さんの情報を、僕は結構アテにしています。
昔、2003年ごろPHP5が発表される前ぐらいの時、SIではJavaが最も勢いのある時代に、担当者さんはPHPがものすごく来そうだと言っていました。
「Javaが勢いがあるのはわかるんだけど、PHPのニーズがものすごいんですよ。」
ってよく言ってました。当時、僕は「いやいやJavaでしょう」って思ってたんですが、その後確かに時代が軽量言語に移ってきて、IT出版の方々は少し先の未来を予測するための強い情報を持っているんだなと実感しました。
さて、IT出版の常識として
不況になると即効性のある実用書しか売れなくなる。
というのがあります、今現在も実用書しか売れていないそうです。（実用書とは、言語入門とかマーケティング本とかです。）
実用書が売れるということだけではなく最近の傾向としては「HowからWhatへ」という関心事のシフトが起こっていると言います。
出版業界の「HowからWhatへ」の変化から読み取れるIT業界の変化の傾向
どうやって作るか？（How）を習得するための実用書よりも、何を作るか？（What）にヒントが得らるような実用書が求められていると聞きました。
ここからIT業界の変化の３つの傾向が読み取れると思っています。
・傾向１）短命かもしれないサービスが中心となりHowにこだわってられない時代になった。
・傾向２）Howはもっていて当たり前になった。かつ、持つべきHowの水準が低くても構わない時代になった。
・傾向３）Whatが、ITエンジニアの差別化要因の第1の要素となった。（または、これからなる）
傾向１「短命かもしれないサービスが中心となりHowにこだわってられない時代になった」
これはWeb系のトップ（経営層）の思考傾向が世の中に反映してきてるのだと思います。
サービスを数週間単位などでリリースするような会社では、特に経営層はHowにこだわりを持つよりもさっさとリリースする方が良いと考えます。
これはエンジニアとしては、醜いコード、醜いアーキテクチャになるので嫌なものですね。後に禍根を残すようなやり方です。
こうやって性急にリリースされたサービスやシステムは、Whatの部分で世の中に評価されれば、その後きっとパフォーマンス問題や、構造の不備などで苦労するんだと思います。
そういった側面もあるでしょうけれど、僕はこの傾向は短命サービスをどんどんリリースすることはアリだと思います。
構造をおろそかにしても良いというよりも、トレードオフが前提なので、構造に初めから時間をかけるよりは別の事やスピードに、リソースを割いた方が良いということです。
SIに比べるとより顕著ですが、サービスは作っても使われない確率が非常に高いものです。使われるものにリソースを注力する方が良いと感じます。
リリース後、苦労する中で本当に有益なコードと構造が得られ、次のサービスの基本アーキテクチャになると感じます。
傾向２「Howはもっていて当たり前になった。かつ、持つべきHowの水準が低くても構わない時代になった」
というのは、技術が簡単便利になったということが第1でしょうけれども、加えて世代層も関連していると思います。
2000年ごろの就職氷河期を生き抜いた危機感のあるITエンジニアが30代の働き盛りとなり、企業の中核メンバーになっています。
オープン化と呼ばれた混沌とした技術の時代が当たり前となったころに育っており、それまでのクチだけITエンジニアは減っていると思います。
そういった人たちにしてみれば、現在のように簡単便利になった言語環境においては、作る技術はどうにでもなる自信があるし、後輩を育てることも可能です。
あとはパフォーマンスやスループット、可用性といった安定運用の部分の能力が差別化ポイントです。
ところが、こういったハイレベルなノウハウは書籍で学ぶより実践で学ぶ方がはるかに得られるものが多いので書籍の売り上げにはつながらないのではないでしょうか？
（この分野でも良くできた本はある程度売れるそうです。しかし狙うターゲットとしてパイが小さすぎるので出版社があまりおいしくないという理由もあるようです）
さてこの記事の本題は、傾向３「Whatが、ITエンジニアの差別化要因の第1優先となった」です。
今まで、ITエンジニアの差別化の一番のポイントは、2つでした。
1．いかに堅牢に保守性高くそれでいて速く作るか？
2．いかに顧客から要件を聞き出し、実現可能な仕様に落とし込むか？
今までは、エンジニアは、堅牢・保守性・生産性に高い関心を持っていました。
別の関心の傾向としてコンサルタントとして上流工程を極めることでした。
上流工程とは顧客から、要望を聞き出し、整理し、ITで実現可能な仕様に落とすことです。
もちろんそれらの価値は依然として高いのです。
しかし、これからの時代、どこかにある要件を実装して終わりというITエンジニアでは、ダメだということになってくるんじゃないでしょうか？
SIなどでは、What（要求）は顧客が出すものでした。
乱暴に言えば「要件が出ない」ことや「要件が変わる」ことをお客さんのせいにしてHowを突き詰めれば済む時代でした。
ところが、最上流工程が一つ上にあがったのです。
Whatが定義でき実現できる人がエンジニアとしては最上流であり、Whatを生み出す方法がこれからの関心事になるんじゃないかという傾向と読み取れます。
How（どうやって作るか？その開発プロセスは？どの言語やどのアーキテクチャを使うか？）に拘っていても、良いもの（世に求められるもの）は作れないくなっています。
What「何を作るか？どうやって、誰に売るか？」を最上流として、そこにエンジニアとしても差別化ポイントがあります。
具体的にいえばエンジニアもマーケティングや、営業系の勉強をする人が増えてきています。
さらにはデザインやSEOもエンジニアが知っておくべき知識領域の中にはいってきました。
作る技術が便利に簡単になっていけば当然発生することだと思っていましたが、いよいよそういう差別化の時代が明らかな傾向としても出てきたんだなと思う今日この頃です。
この話は実は喜ばしいことかもしれません。
10年近く前、SOAが云々言われてた頃は、今みたいな時代を予想して「エンジニアの仕事はなくなる」と思っていました。
でも実際は、無くなったのではなく、よりクリエイティブな方向に形が変わったと言えます。
こんな時代に、どんな準備をしていますか？
