「SIerに本当に必要なもの」を手に入れたい

富士通の打ち出した方針をきっかけに色々と盛り上がっていますね。
以下のエントリには中堅SIerに勤めている身としては思うところがたくさんあります。引用しつつ少し議論してみたい。

ただし、一方でより本質的に重要なことは、クラウドの普及により、要件の定義から実現、運用までの期間が大幅に短縮できるようになったり、基盤構築など多くの仕事が自動化されることで、上流から下流まですべてを担当できるような真のソフトウェア技術者の役割がシステム開発で重要になってきているというところにあると思います。

ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して

ちょっと前提の議論だけど、クラウドの普及で減る時間は、基盤の設計・導入コスト(ミドルウェアまで含む)が中心でその上で動くパッケージについてはクラウド云々ではないよね。もちろん、サービスそのものがクラウド上にあるようなものをそのまんま利用する、ということであれば別。
従来型のSI(箱を買って設定するところから)では業務要件の定義が終わる=サイジングが終わることによって初めて基盤が動き出せた、という意味ではクラウドを利用することで「とりあえず作っとくか」的なスピード感は出るし、要件決まってからでも導入の時間が少ないというだけでもかなり早い。でも、要件定義自体は短くならないよなあ。あと、運用についていうとお決まりのセット作っておけばあとは毎回コピーで済む気がするのでそれは楽だね。
というわけで、基盤構築が省力化・自動化されるとアプリだけ作ればいいからかえって楽じゃん!と発想するのがSIerというものです。業務要件をシステム化することこそがSIerの仕事!みたいな。
でもなあ、そういう仕事がどんどんパッケージに置き換わってくる未来しか僕には見えなくて、SIerの仕事はシステム化の開発部分だけを担うパターンはもうなくなっていくんじゃないかと思ってます。

少なくともグルーバルな意味でのエンタープライズ開発のコンテキストにおけるプログラマーとは、顧客の要件を素早く実現する方法を提案して、そのまま構築し、場合によってはテスト自動化やデプロイメントまで担当する人のことを指します。そういう意味では当然上流も下流もありません。

ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して

という話はごもっともなんだけど、日本のエンタープライズ開発において、顧客の要件ってのはプロダクト(サービス)の開発じゃないことが大半なんだと思う。実のところ、それって日本に限った話じゃないから、SOAが持てはやされて、また、失敗してきたんだと思う。Rationalのいろんなモノだっていかに開発現場がそういった「プログラマー」的な話から程遠いかを示しているし、人月の神話だって日本発じゃないんだよね。
日本において、プログラマーってのが下流工程の担当者をしばしば指しているのは、日本のSIerの役割分担がその業界の階層構造を元にしていることの表出であり、実際の役割を名指ししているわけではないと、SIerにいると思うことがあります。上流工程で自分の知識不足を補うために、名うての「プログラマー」を「SE」として雇うことなんて日常的な話です。技術を知らないと設計なんか出来なくなる?今だってそうだと思う。

のだけど、そうともいえない世界になっちゃっているのはなんでなんだかな。

企業の図体が出かければでかいほど、そういうところが目に見えてきちゃう。富士通の今回の話は、そこを自覚したことによって改善しようとするこのだって期待したいのだけれどもね。

「スキルからロールへのシフト」である。同社が新たな時代に向けて再定義したロール、すなわち「役割」に応じた職務は、「ビジネスプロデューサ」「フィールド・イノベータ」「コンサルタント」「サービスインテグレータ」の4つ。

富士通が説くSIにおける人材革新のツボ - ITmedia エンタープライズ

これらの言葉が、なんだかむなしく響くのはSIerでやっている人には共感してもらえるんじゃないかと思う。

さて。

伝統的に、日本のSI業界ではその構造から実装、構築の作業を軽視する傾向があったわけですが、いい加減にこのような考え方でシステム開発を続けることは品質やコスト、スピードの面でもう限界に達していると考えられるのではないでしょうか。

ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して

という意見ですけれども、僕の知る限り、失敗したプロジェクトはこのとおりの問題がよく発生しているんだけど、成功しているプロジェクトのいくつかは(ここで大半と言いたいんだけどいえないこのもどかしさ)、きちんとやっているわけです。
ここで失敗を起こさないためには、上流工程できちんとした設計を行うことが大事ですし、きちんとした設計を行うためにはきとんとした要件定義ができなければならないのですから、構築コスト(期間)が減少した今、その浮いたリソースを上流工程に割く方向にシフトしていく、というのはあながち間違ったことではないと思います。

僕が受託業務開発は先細りだと思っているけどそれは、実装の部分が早く安く品質よく、になっていくことによる仕事としてのボリュームの減少が起きるという予想から。そうすると、従来プログラマーアメリカ的意味でも、日本的な意味でもどっちでもいい)として仕事をしてきた人ももっと上流の立場でやらなければならないかもしれない。

これは、上流しか出来ないSEにとっての危機だし、上流の仕事がしたくないプログラマーにとっての危機でもあるんですよね。いずれにしてもSIerにおけるSEの仕事は変わっていかなければならない。いい意味でも悪い意味でも役割分担の出来ていたかつては、上流のSEと、アドバイスの出来るプログラマーはいいコンビだったけど、どちらの立場をも同時にやらなければならなくなったとき、脱落する人はたくさん居るんだと思う。そこをごまかすために「コンサルタント」的な職種を作るのはよいんだけど、そんなコンサルタントの作るものは地獄を召喚するだろうね。

ソフトウェア技術者を重視する時代は、SIerの世界では多分来ない。でも、ソフトウェア技術者しかSEという仕事ができない時代は遠からず来るんじゃないかと思ってたりします。

でも、それとプロジェクトを回す記述というのも別の話。SIerの仕事がどう変わっていくのか、もうちょっと考えていきたい。