クラウドでSIがダメになるのではなく、クラウドは、ユーザ企業の要件をさまざまな技術やサービスを組み合わせることが出来るエンジニアを“これからも”要求されることを明示しているだけに過ぎない

クラウドでSIがダメになる本当の理由

この記事を読んでいたら頭の中に？が？？？になったので整理がてらに何がオカシイと思ったか、そのオカシイをどう考えたかを書いてみたら、元記事のほとんどがオカシイになってしまった。

項番	元記事	何にオカシイと思って、どう考えたか
1	「サーバーをクラウドに変えればいいだけですよね。結局、システムの開発は残るし、運用も多少は減るかもしれないけど必要だし、クラウドでSIは大変なことになると言うけど、うちにはあまり関係ないですよ。」	アプリ側の観点で物を言っている。今までは実在するインフラ、運用担当がいたが、クラウドサービスに置き換わるとサービス仕様だけが会話する相手になることを理解してない人が話しているようだ。インフラ、運用がオンプレの人が居るサービスから仕様だけのサービスに置き換わることで、今までインフラ、運用担当が担っていた要件、設計、実装の作業をアプリ側が吸収しなければならなくなるということを理解しなければならない。
2	SIビジネスの本質的課題は、人月積算で金額を決めておきながら、瑕疵担保責任としてSI事業者が完成責任をおわされるビジネス構造にあります。	工数提示をしているので準委任契約の体をしているが、瑕疵担保があるから請負と言っているなら間違い。準委任でも瑕疵担保はある(が一般的に成果物を契約で定義しない)。完成責任を負う成果物の定義が違うことを端折っている。ユーザ企業は契約の成果物を曖昧なシステム一式で求めリスクを転嫁する一方、工数はfixed priceで求めていることが校章をできないSI事業者にとって契約上不利な状況下におかれている。
3	しかし、不確実性の高まるビジネス環境の中で、将来を正確に予測できるはずはありません。こんな事もあるかもしれないと、推測や思いつきでてんこ盛りの要求になってしまいます。また、例え今が正しくても、要件が変わることは避けられません。	要件が膨らむのは予測出来ないからではなく、発注側が何をしたいか事業目標を理解していないことに起因している。だからこれをやりたいと提示できないし、設計や実装を見て初めてユーザ企業はやりたいことを認識するのである。ユーザ企業自身が事業目標の達成の仕方を理解していないために業務要件を提示できないために、システム要件を確定できないことが起因である。
4	そんなやり取りを経て、ようやくできあがった要件定義書にSI事業者は合意を求めるわけです。合意といえば美しい響きですが、「この仕様通りに作ります。もうこれ以上変更しませんよ」という宣言で有り、最後通牒でもあるのです。	請負契約はSI事業者がユーザ企業が提示した要件に対して見積もり前提を置いて対価を提示しているのである。見積もり時点と仕様が変わるなら再見積もりをしなければならない。見積もり前提と要件が変わっても発注の力学が働いて再見積もりをできる環境を変えられない関係に問題がある。
5	これは考えて見れば当たり前の話で、現場ユーザーは、売上の拡大や業務の生産性を向上するなどのビジネス価値向上をゴールと考えているのに、SI事業者は「要件定義書通りのコードを書く」ことがゴールとなり、ここに根本的な不一致が生まれているのです。	ユーザ企業とSI事業者間の個別の関係をゴールの問題にすり替えている。要件定義でユーザ企業が要件を出せないこととSI事業者側が要件を聞き出せないことがコトの真因である。ユーザ企業は要件を出せず、SI事業者側が要件を聞き取ることが出来ないなら、ギャップを最小にできるシステム開発手法を選択しなければならない。
6	要件が変わる、決められない時代、このようなやり方は、本質的に無理があるのです。	要件が変わることもあるだろうけれど、業務要件は中期計画からくるものでそうそう変わるものではない。ここで言いってる要件はシステム要件の内些細なことの部類を言っているように思える。ユーザ企業は業務要件を出せるスキル、SI事業者側は業務要件を聴き、システム要件を抽出できるスキルを身に付けることが求められている。
7	しかし、情報システム部門には、瑕疵担保責任という免罪符があります。しかも、検収・支払いという人質があります。結局は、SI事業者が改修を引き受けることになってしまいます。工数は嵩んでも請負ですから支払いが増えるわけでもなく、利益を減らし、時には赤字になることもあります。	瑕疵はあくまでも納入物の不良に対してである。何でもかんでも瑕疵にならない。また、検収・支払を立てに取ることはSI事象者が中小企業であれば下請法があるので違法になる。要件を提示できないユーザ企業、要件を聞き出せないSI事業者の双方の力量不足を起因としているのだから、双方がギャップを詰められる関係を醸成しなければならない。
8	本来のあるべき姿です。これらを実現しようとすれば、アジャイルや超高速開発、DevOpsは前提となるでしょう。	3項目の姿はユーザ企業に求められるスキルではないか。それをSI事業者側に求めていることがおかしい。ユーザ企業で業務要件を出せないことをSI事業者がリスクと識別しリスクテイクするのであれば、要件を聴きだすスキルと従来と違うシステム開発手法を模索しなければならない。
9	また、頭を押さえられているIT予算の中で、ビジネス環境の急速な変化に対応することやグローバル展開、セキュリティへの対応が、重くのしかかってきます。こういう事態に対処するためには、自前で開発し、所有することを前提としたシステムのあり方だけでは対処できないのです。	これはユーザ側が事業目標と法規制を理解し、どのような方式でシステムを実装するかを最終判断をしなければならない事項である。事業目標と法規制を鑑み、自社所有と判断するならそれを実現できる対価を支払うということなのである。SI事業者は業務要件と法規制を念頭に実現仕様の提示を、ユーザ側は実現仕様で要務要件を達成できるシステムであることを判断しなければならない。
10	また、コストを下げる手段として、あるいは新しいテクノロジーを使ってビジネスの競争力を高めるために、OSSを避けて通ることはできません。	OSSを採用するということは、それまで製品ベンダが担ってきたパッケージのありたい姿への維持をするために掛けているコストを受け取る代わりにライセンス費用を免除するということなのである。また、OSSを導入することによりライセンスに対するリスクが高くなることをユーザもSI事業者も認識しなければならない。ビジネス競争力をコスト圧縮に求める一環でOSSを選択するのであれば、ユーザ側もSI事業者側もOSSのライセンス費用の低減のメリットとOSSパッケージの維持とライセンスリスクのデメリットを理解した上で採否を決める必要がある。
11	このようなユーザー企業の要求を満たす手段として、クラウドは様々な機能やサービスを提供しているのです。だから、クラウドへの期待が高まり、需要の拡大と共に、これらユーザー・ニーズに応える機能やサービスは、さらに充実し、クラウドへのシフトを加速しているのです。	ユーザ企業の要件を満たそうとしているのはクラウドばかりではなく、従来のパッケージも同じである。提供方法をパッケージからASP的なサービスに置き換えただけでしかない。項番1はクラウドであろうがなかろうが関係ない。項番2はユーザ企業がそう望むなら、である。項番3はそれを実現できるシステム開発手法を選択できるなら、である。ユーザ企業は、事業目標を達成できるシステム要件を判断できるスキルを付けなければならない。SI事業者もユーザ企業の業務目標からシステム要件を抽出して実現できるシステム方式をユーザ企業へ適用できるスキルを涵養することを求められる。
12	これまでの人月単価積算型の収益モデルが機能しなくなることであり、受託開発需要が減少しようとしているのです。運用や開発のあり方が変わり、求められるスキルやテクノロジーが変わるのです。何よりも、システムに求められる価値観が変わり、情報システム部門の役割は変わり、ユーザー部門の意志決定権限もますます強まるでしょう。	人月単価積算型の単位が月極めの意味であるのであればクラウドサービスは利用単位に変わったモノなのである。需要が減少するのではなくシステムサービスの質が変わるということなのである。一方、元記事の上述のとおりにシステムニーズが旺盛であるなら単元は小さくなるがボリュームが増えるという仮説を立てることが出来る。ユーザ企業がそう変わるならSI事業者も変わればいい。ユーザ企業のシステム利用の対価に対する価値観が所有から利用へ変わるなら、システムサービスを提供するSI事業者も価値の提供方法を変えなければ他社に置き換わるだろう。