gothedistance.hatenadiary.jp
blog.imalive7799.com
d.hatena.ne.jp
ちょっとDevOpsと関係ない所で話になっている。
一括請負と、委任契約とかそういう話になっていますねえ。
でも、本筋は、「顧客が直接システムを開発する」のではなく、「顧客が使っているサービスをプロバイダが開発する」って形になってるって事で。
業務のシステム運用保守部分に当たる所が、別に会社として成立し、そこが開発してサービス化してるんですよね。
ビジネスが変わってく所というよりも、システム資源を余所からライセンス買って動かすという所で。
実は、顧客のビジネスそのものはそんなに変革していなくて、顧客が業務進めるのに、自社開発するか、パッケージ買うか、というのの選択肢に、そういう開発での部分コミコミでサービス買うかという形になっていってます。トレーニングとかもお金払って受ける感じで。
昔Oracleがシステム開発屋にやってたようなのを、もう少し業務寄りなサービスでやってるようなイメージでも持って頂くと。
で、会社がさくっとライセンス買って、エンドユーザは直接サービスプロバイダに文句言うと。
ここらへん、実際に取引相手我々でも変わってます。
ま、頑張って社内でやってるところは大抵ビックデータやる訳なんですけど。不毛な気もしますが。
DevOps製でのサービスが展開されていない日本で、さて。
多分、AWSとかがもう少し一般的になれば、その次のそこの上でのサービス出す企業ってのも出て来るのでしょうけど。
社内に開発者を抱えているのは、今までの意味での顧客ではなく業務特化型のサービスプロバイダです。
今の日本の顧客がやるってんなら、社内に多重構造を持っているのをバラしてフラット化してから、という話にもなる気がしますが。例えば分社化って方法がありますけど、それは他社に売るためがメリットという訳ではなく、そもそも社内請負専門とかって、そりゃ儲からんでしょうという事もありますから分社化って意味があるんですよ。それが行われないと関係会社からしか仕事がないから色んな社内雑務を引き受けて部署ひとつ分の仕事にしてしまう、というような不都合が起こってます。
ただ、ここらへん踏み込んで発言するコンサルの人ってあんまりいないような気はしますね。
顧客が内製でDevOpsで開発してくのもいいけど・・・・・・
その開発にはSIerとしては、「出向」するパターンになりますよね。
でも、正直そういう歪な会社-仕事関係って誰も幸せにならない気がします。客先常駐もですね。
なんか、DevOpsって、うっかりすると開発と運用を掛け持ちさせられそうで怖いんですよね。