大規模SIは少数精鋭で乗り切れるのか？
まず現状の認識は以下の通り
1.20-30代の就業人口の減少これは大前提になる。
また情報共有も進むためよりブラックな会社が
人を集めること自体のハードルがあがる。
結果として、人員を集めるということがより厳しくなる。
これはITに限らず、労働集約的産業全体の課題でもある
2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は
勉強している人としていない人の格差は広がっている。
ゆとり云々とは別に、社会的なプレッシャーから、
むしろ勉強しないと勝ち残れないという強い意識のある集団と、
ゆるふわほんわか草食集団の差が非常に非常に広がっている
3.資源の拡大要するに、割とハード・リソースに余裕が出てきている
まず、クライアントサイド。
要はなんでもできる状態になりつつある。
jsあたりはほぼ無法地帯の感もある。
一時、jsでOSみたいのまでいけるぜ、というデモもあったが
技術的には凄いのだが・・
あれはPM辺りが見ると、ヤバイ予感が走ったはず。
サーバーサイドもアーキテクチャはかわる。
特にミドル層はかなりの選択肢が出てくる。
徐々に分散処理の要請も出てくるだろうし、
DB自体もそう簡単に決められる状況でもないという風になるだろう。
これは、うまくコントロールしてアーキテクチャを決めないと
あっさり迷走する確率があがるということでもある。
さて、以上の状況でどうなっているかというと
全体的に大規模SIが成功しにくくなっている感がある。
特に地方周りはもう最低レベルを割って、
エマージェンシーコールが鳴りすぎて、
電池切れで沈黙の春ですか？的な状況。
それなりに人がいる都心でも、どこも必死に人材を集めている感じがする。
そーなるとどうなるか？ということで
おそらく、大規模SI自体が、いまのやり方ではできなくなる可能性が高い
上記の条件だと、
まず数100人月クラスのSIではまともに動かす方が大変。
まず人が集まらない状況で、アウトプットにばらつきが出始めると
管理工数は異常に膨らむ。で、歩留まりを見始めるとすげー赤字予算になる。
ハードの合わせでの、収益確保もクラウドのコストプレッシャーは強いため
むしろ利幅はほとんどとれない。
もともとクラウドの登場でSI自体の位置づけが微妙だったわけだが
最近の社会情勢は、それ以上に従来型のSIには厳しくなっていると思う。
なので、選択肢はそれほどないはず。
では生き残る流れとしては何があるのか、というと。
1.ASP万歳アタック路線この道はいつか来た道ですね。
なんか意味不明カスタマイズの嵐とともに、
そもそもASPってなんだっけって？参加者全員が
疑問に思う結論になるパターン。
しかし、ASPベンダーもがんばってはいるので、
「いままでとは違う」スタイルで乗り切るかもしれない。
駄目な気がするけど。
この辺はもうよくわかりませんね。某外資系パッケージのASPとか
なにがしたいのか、自分には理解できません。はい。
2.E/U自衛路線
人はE/Uサイドである程度確保する。
情報子会社は外販とかしてる場合じゃなくて
自社のSIちゃんとやれコラァ的な感じになる。
「え〜、だってオヤビン、いままで外注管理でいいって。
数字悪くなったら、うちのサービスなんか適当に外販しろとか言ってたじゃん〜」
状況がかわった。ちゃんとつくれ。的な。
3.少数精鋭SI
人がいねーなら少ない人数でどこまでやるのか？という選択をチョイスする
いわゆるセカンドティアや、業務系SI屋はこの選択をせざるえない。
さて、そこで、かりに成功する路線があるとすると
路線は2+3だと思うのよね。
いやSI自体ないだろ、って意見はあると思いますが
どっこい需要は根強いので、供給サイドが準備できればマーケットは成立する。
そのための成立条件を考えてみる。
というかそれが自分たちの行き残る道でもあるし、
なんとなくだけど技術的にも光がある気がする。
言ってみれば、少数精鋭SIで大規模をカバーするための条件は？
という考察だ。
条件1 品質確保優先をどうするか？をクリアする
まず大規模SIで最大の課題は品質であると思う。
これを維持するために、膨大な人を投入しているといっても過言ではない。
勿論、不要な政治的資料のために人がいるという説もあるが、
それはもはや論外なので削除する前提。
それでも少ない人数での最大の課題は品質であることは間違いない。
これは以下の条件2+3が見たされた上でかつ、
「何かの仕組み」を入れていく方法しか選択肢はないと思う。
これはDSLだったり、一種の形式手法だったり、TDD的な考え方の導入だったり
いずれにしろ模索されるものだと思う。
条件2 要件定義・基本設計でどこまで仕様を拾えるか？という問題の対策
要件定義・基本設計で例外系が拾えてない仕様は
確実に後戻りが起きる。仕様の見直し、実装手戻りは品質には致命傷になる。
ここをどうするか？ということが問題。ここはマンパワーの話ではない。
これは、まずは如何に「知っている人」を固定できるか？につきる。
要件定義・基本設計は業務知識・経験に完全に左右される。
したがって人の経験の問題である。おそらく4-5人でよい。
経験知のない人間では手戻りは必ずでてしまう。
特に業務系例外系は、経験則が有効なことがおおい。
碁の定石に似ている。「いわゆる双方よし」に落ちつく感じだ
定石を知っているひとと、今から作るひとではそれは差があるでしょう。
掘りすぎても駄目だし、無視しまくると業務が回らない
利害関係者の調整も大変だ。なので「うまい落としどころ」を
設計しなくてはならない。
ここはE/UとSI屋の共同戦線しかないような気がする。
SI屋的には4-5人を特定の業種・業界で回せる「営業」が肝になる。
E/U的には如何に人を育てておくか？という人事戦略に直結する。
人が財産であるのであれば、IT資産とは何か？ということはもう一度考えて欲しい。
特にE/Uさんに考えて欲しいことはシステムは本当に
御社のコア・コンピテンスではないのですか？ということです。
「うちの本業はITではない。」
よく聞く話です。特にトップに多い。
本業をやるために必要なことは何かを考える時期だと思います。
次に、プロジェクト全体の進め方にもなるが、
手戻りの少ない方法が選択されるはず。
個人的にはアジャイルのディシプリンを組み込んだ
WF的なやり方がいいのではないか？とは思う。
いずれにしろ、アジャイルだWFだという従来のやり方ではなく
新しいスタイルが必要になると思う。
やはり従前のやりかたは「少数精鋭で大規模を捌くため」の仕組み
とは違う気がしている。
条件3 実装コストを如何にさげるか？という条件
これはもうはっきりしていて如何にコード量を減らすか？につきる
如何に書かずにすますのか？如何に「適切に自動化するか？」
如何に「システムそれ自体にチェック機能を入れておくか？」
ということになると思う。
できるだけコードは減らそうという社会的コンセンサスはあるとはいえ
上記のように「何でもできる環境」は普通にコードは増える。
現状のITの環境はむしろコード量は増える圧力の方が強いと思う。
なので、そこをどう前向きに制限するかに尽きるでしょう。
コードを減らす、ということをもう少しちゃんと考えてみたい。
・余計な部分は括弧一つであろうと書かない。
最前なものはコードすらない、という形だと思う。
関数型言語が歓迎されているが、その大きな理由のひとつは
余計なコードが減る、というのは衆目の一致するところ。
・直感的な記述ができる。
直感的というのは、一つは学習コストが低いということ。
これは文法や言語仕様が必要にして十分でなければならない
ということです。
もう一つの意味は、「必要なこと以外の余計なことをかかない」と同義ですが
「記述法に選択の余地がない」ということです。
書きたいビジネスロジックがある場合に、素直に書けるということが必要です。
・システムでやれることはやってもらう。
これは余計な型は宣言しない方がうれしい、ということもあるし
逆にSyntax検査でやれる基本は全部コンパイラでチェックして欲しいということ。
同時に、IDE等のサポートが充実していることも必要でしょう。
なお、個人的にはある程度の強い型システムを
備えていない環境は使われないと思っている。
条件4 運用を如何におこなうか？というハードル
さてこれだ。これは多分、分化する気がする。
今までの運用というと割と陰に隠れていて、
どういうスキームになっているのかわからないところがあったが、
これがクリアになることが条件だ。
まず「運用設計」という部分に人を割くことができなくなるはず。
少人数でSIをするのであれば、運用・特にインフラ部分に
時間的・人的なリソースをつぎ込むことは無理だ。
では一足飛びにクラウドか？というと、現状のクラウドでは足回りが足りない。
現状でイイ線いっているのはAmazonぐらいだが
まだまだユーザー側にノウハウが足りないと思う。
Amazon側もSI基盤として、技術はあるがエンタープライズに向ききれていない気がする。
（あるけど宣伝が下手だということもあるかも）
逆にいままでのDCやメーカー系SI屋では、
エンタープライズには姿勢は向いているが、技術がない。
かなりのSIノウハウはあるが自動化の技術がないので、
・・人手になる。
ここは意外に選択肢が見つかるような気がしている。
・・・・・・・・・・・・・・・・・
まぁこんな感じでハードルはある。が、光明もなくはない。
きちっと整理すれば、現状の大規模SIも相当人数は
削減できるはず。いや、しないとまずい。
アジャイルとかそういう話ではなくて、
少ない人数で普通の中規模を、また従来よりも少ない人数で大規模を
どうするか？ということの答えは早急になんらかの
回答が必要だと思う。
