IT業界の多重下請構造は問題なの? ①
ことあるごとに「多重下請」が批判的に論じられていますが、一体何が問題で、どうあるべきなのか?について自分なりの意見を纏めてみました。
最初に今の構造の問題点を洗い出し、その後にその原因について考察してみたいと思います。
■問題点
仮に日本にいる全てのエンジニアが200人だとし、大手2社に50人ずつ、その他10社に10人ずつ所属する【下請け構造】をモデルに考えてみます。
【下請構造】
[大手A社]-50人
┗[下請けA社]ー10人
┗[孫請けA社]ー10人
・
・
[大手B社]-50人
┗[下請けB社]ー10人
┗[孫請けB社]ー10人
・
・
①安全衛生の問題
通常、所属会社の違うエンジニアが集ってプロジェクトチームが出来ます。その状態では往々にして会社を跨いだ指示命令系統が出来る。つまり、[大手A社]のPMが、[下請けA社]のエンジニアに直接指示命令するケースがあるが、これは法令違反です。(労働基準法)
エンジニアの健康保護の責任はその所属会社にあるので、勤務時間と切っては切り離せない指示命令は所属会社の上司がするものです。
しかしながらプロジェクトの現場では実質不可能に近い。
つまり、労働者の健康保護を目的とした機能が不完全になることがあるということです。
②間接業務の増幅
単純に会社数が増えれば、間接要素(オフィス、税務・会計、システム、エンジニア以外の人件費...)も増える。会社の数が少なければ少ないほど統合メリットが出て効率は良いと言えると思う。
・
③不当な利益
通常、報酬(売上)は価値に見合っているべきだと思いますが、例えば、[大手A社]の仕事を[下請けA社]が受注し[孫請けA社]のエンジニアが作業するようなケースがある。
この場合[下請けA社]が問題となる。ただ、[下請けA社]は価値を生み出していないというのは言い過ぎで、[孫請けA社]より営業工数を掛けて営業しているから[孫請けA社]には取れない仕事が受注できたともいえると思う。また[下請けA社]は契約上のリスクも負っている。しかし直接的な業務といえば伝票を起こしているだけと言っても過言ではない。この位置の会社がマージン取り過ぎということが往々にして起こっているように感じる。
④人材マネジメント不全
例えば[孫請けB社]のエンジニアが、現場で困っているとしよう、現場で相談出来るよ内容であれば問題ないのですが、中には[大手B社]のプロマネからのパワハラ、不明確な指示など直接言えない内容で困ることも多くある。通常は所属会社の営業が問題の種を早期発見し未然に沈静化する。しかし下請け構造が多重で複雑になると、時間がかかったり、話しの要旨が伝わらなかったりでコミュニケーション不全に陥り問題が悪化することがある。突然「やってられませーん!」と言って離反するメンバーが出ることも。。
⑤価格から抱く期待とのズレ
[ユーザー企業]→[大手B社]→[下請けB社]→[孫請けB社]→[ひ孫請けB社]のような多重構造を想像してほしい。それぞれの会社が20%の粗利をとると[ひ孫請けB社]へは50万しか入ってこない。もちろん[ひ孫請けB社]も粗利をとるため全額エンジニアには渡らない。[ユーザー企業]は100万の価値を期待する。しかし実際には[孫請けB社]は50万そこそこの価値しか提供できない。といった構図が出来あがりしばしば顧客不満足につながることがある。
私が感じる問題点は以上となります。
次は、「何故こんな構造になっているのか?」について考察してみたいと思います(^^)/
※何かお気付きの点やご意見など御座いましたらコメント頂けると幸いです。
(メールでも結構です! masahito.tomimoto@gmail.com)
2014年6月よりIT系無料勉強会を開催しております。
以下のページの「申し込む」ボタンから、当Communityのイベント案内メールが配信されるようになります。
~ITエンジニア勉強会~ engineer'sLearning・Vesper | Doorkeeper
是非、ご登録を(^^)/
クラウド運用管理、物理環境との違いは?
クラウド時代の運用業務はどうなるか?ものすごく簡潔に纏められた記事。
-----
1回で分かる:クラウド運用管理、物理環境との違いは?
http://techtarget.itmedia.co.jp/tt/news/1403/05/news06.html
ーーーーー
まー結論は、物理の時とあまり変わらない。
ただ、コスト管理はなかったかな!
これまでは5年ほど利用することを見込んで、ドカッと投資。
どのサーバが、どのビジネスに利用されどのくらいの費用対効果があったか?など測定は困難だったのが、クラウド時代は可視化されるようになるのだというのが大きな気付きです(^^)/
【インフラエンジニアの将来】 メーカーエバンジェリストの見解!
先日、Microsoftのエバンジェリストである知人に会い、インフラエンジニアの将来について意見を伺いました。
以下、同氏の見解を備忘録目的で以下に記します。
▼最近では、開発環境(VisualStudio)上からクラウドの仮想マシンの立ち上げやスケールなどの操作が簡単に行えるようになった。
▼そして、仮想マシンのサイズ(パフォーマンス)も年々大きくなっているため、例えばロードバランサを絡めた複数台のサーバーなどの複雑な構成のシステムの需要も減りつつあるように思う。
▼また、あらゆる技術の進化によりインフラ部分を開発者でも操作出来るようになってきている。
▼小規模なシステムは上記の理由から、インフラエンジニアの出番がなくなっていくと思うが、それなりの規模のシステムは開発の片手間で出来るようにもなるように思えない。
▼現在、プロジェクトの現場では、開発側とインフラ側の乖離があるように思う。よってインフラのことが分かっている開発者、逆にアプリの都合を分かっているインフラエンジニアが少ないので、将来的には開発側の都合も理解したインフラエンジニアが重宝されるのではないかと感じている。とのこと。
【インフラエンジニアの将来】 キャリアアップするために
私が思う結論を先に言っちゃうと、これからのインフラエンジニアは
「上流」そして「マルチ」を旗印にキャリアアップを考えるべきだと感じています。
その理由を述べる前に言葉の定義をしておきます。ここで言うインフラエンジニアとはハードウェアやソフトウェアを調達(これからはクラウドプロバイダのサービスを調達)しユーザー企業のシステムインフラをインテグレーションするエンジニアのことです。またネットワークエンジニアやストレージエンジニアなども内包しインフラエンジニアとしています。
まず、ITインフラの変遷を振り返ってみたいと思います。
ざっくりと、①大型汎用機時代 ②ネットワーク時代 ③モバイル・ビックデータ時代 に大別することが出来ると思います。
①大型汎用機時代
当時はビジネスに於けるITがカバーする範囲も限定だったことでしょう。
システムを定義・設計するシステムエンジニア、ソフトウェア開発を行うプログラマー、導入したシステムの運用・保守をするカスタマーエンジニアがいたとのこと。このころアプリケーション以外のOS やハードウェアなどのシステム管理はメーカーのエンジニアが自分たちで行っており、システム管理者と呼ばれていたようで、今のようなインフラエンジニアと呼べる職種は存在しなかったように思います。
②ネットワーク時代
この時代の特筆すべき事として「インターネット」と「ダウンサイジング」とがあるかと思います。
1995年のインターネット商用利用解禁を機にビジネスに求められるITの範囲が拡大、企業はホームページを持ち、PCが1人1台配られオフィスアプリケーションを利用しメールでコミュニケーションするのが当たり前の世界に変貌。
またソースコードで配布されるUNIXの導入、Windowsに代表されるハードウェアとOSの水平分業、またその上に乗るパッケージソフトが充実など、オープン化した背景もあり、汎用機でシステムを維持管理するのは大変高価。またベンダーにロックインを嫌ってダウンサイジングの機運が高まった。
その結果、メーカーに頼らずシステム管理ができるようになった。このシステム基盤の管理を行うのが今のインフラエンジニアだと捉えています。
ITの適用範囲拡大に呼応し、システムも複雑になりましたが一人のエンジニアがサポート出来る範囲は限られるため(中には全てを熟すスーパーエンジニアもいたとは思いますが)サーバエンジニア、ネットワークエンジニア、セキュリティーエンジニア、サポートエンジニアなる職種が出現。そしてこれらをひっくるめてインフラエンジニアと呼ぶようになったように思います。
③モバイル・ビックデータ時代
そして近年では、スマートフォン・タブレットのビジネス利用が浸透し、ITの役割はコスト削減や業務効率化の枠を超えソーシャルやビックデーターなどに代表される新たな価値創出の重要手段となりました。このことからビジネスに求められるITの範囲は更に拡大し、システムはより複雑になって来ていると思います。
ここまでを纏めると下表のようにまとめられると思います。
適用範囲 複雑性
①大型汎用機時代 低 低
②ネットワーク時代 中 中
③モバイル・ビックD時代 高 高
ここまでを見ていると、今後も益々拡大・複雑化したシステムを支えるため、更に職種も細分化されるように思いますが、注視しなければならないことがあると思っています。
それは技術革新による「抽象化」の視点です。
各種便利なツールが登場した結果、エンジニアは細部にまつわる知識が薄くても取扱うことが可能となり、生産性も向上しました。また、より多くのもの(機能)を扱うようになりました。
例えばGUIの登場によりコマンドを知らなくてもOSやアプリが操作可能になり、配布ツールの登場により多数のマシンを個別対応しなくてもよくなりました。反面、冗長化・仮想化などの新たな機能が当たり前のように求められるようにもなりました。
そしてこの抽象化は、昨今のクラウドの台頭によりさらに顕著になっているように感じます。パブリッククラウドを基盤にするのであれば、もうサーバやストレージ等のハードウェアに触ることもなくなるのですから。。
話の本題であるインフラエンジニアの将来に話を戻しますが、インテグレーターの本質的価値は、顧客の要望に対し実在する技術でインテグレーションし、その要望に応えることです。顧客視点でどのようなエンジニアを求めるかを問うてみれば、例えばネットワークのデザインもでき(上流)、CiscoのコマンドもYAMAHAやSONICのその他多種の機器に慣れ親しんだ(ディテール)エンジニアより、ディテールの知識はなくてもネットワークもサーバーもストレージも、良質なコミュニケーションで要望を引き出してくれ、クラウドやツールなど便利な手段を駆使し、要望も満たすことの出来るエンジニアが求められるのではないかと思うのです。
以上のことから「上流」そして「マルチ」を旗印キャリアアップを考えるべきだと感じています。
2014.03.14更新
---------
IPAがこのような報告書発表してたんですね(^^)/
クラウド時代の人材育成検討委員会報告書
http://www.ipa.go.jp/jinzai/itss/activity/itss_cloud_houkoku20110519.pdf
OpenStackDaysに行ってきました!
会場が御茶ノ水ソラシティカンファレンスセンターということもあり、この手のカンファレンスの中では小ぶりな感はあるものの、2年目の開催で講演会場も満席でしたので注目の高さがうかがえました。
「OpenStackクラウドを最大限利用するには」という講演を聞きました。
瞬時にサーバー・ストレージ・DB等のリソースを構成でき、状況に応じて調整出来きる点。また、管理するツールも多数リリースされOpenStackを基にエコシステムが、成熟段階にあることも分かりました。
ただ、OpenStackに限られたことではありませんが、複雑化するシステムインフラに仮想化に加え今度はクラウド管理と、管理要素が増え、益々複雑化するシステムをユーザ企業がオンプレミスで維持・管理することを考えると、大規模でないと活かすことが出来ないのだろうと感じました。
エンタープライズシステムとクラウドの相性 は悪い!
何故、エンタープライズシステムのクラウド化が遅かったのかを考えてみました。
【そもそもクラウドの価値ってなんだっけ?】
NISTの定義が前提とはなりますが、
クラウド(IaaS)導入ががもたらす主な価値として「アジリティ」「スケール」「アウトソース」「コスト」をあげることができるかと思っています。
従来のオンプレミスに比べ、圧倒的にシステム調達・構築時間が短縮、変化に柔軟・俊敏に対応できること。⇒「アジリティ」
需要の変動に対して自社では実現不可能なほどの大規模なプロビジョニングができます。⇒「スケール」
そして、耐震・空調などの設備・サーバやストレージ等のハードウェア(場合によってはOSやミドルウェア)を、自ら調達・維持管理しなくてもよい。専門家にお任せ出来ること。⇒「アウトソース」
また、規模の経済性が働き、コストを抑えて調達・維持管理できるということだと思います。⇒「コスト」
【WEB系システムと比較してみる】
そこで、先行して導入が進んだソーシャルやゲームなどに代表される、「WEB系システム」と、やっと導入事例が出始めた「エンタープライズシステム」との性質の違いを、上記クラウドの価値が享受できるか?という観点で比較してみました。
Enterpriseシステムには、WEBシステムのように、利用者の反応を見てサービスを変えることや、利用者が短期間で急増する等のことは少なく、比較的、予測や計画がしやすいのではと思います。利用するのが企業の社員が中心なので、1年で数十倍になる、」なんてことは考えにくい。
結果、エンタープライズもクラウドのメリットは享受出来るが、WEB系システムほどではないな~というのが率直な感想です。
如何でしょうか?
日本におけるクラウド普及のカギとは?
【Iaasは今後どの様に普及する?】
今、わたしの一番の関心事である。クラウドコンピューティング(IaaS)は今後、どの様に普及するのでしょうか?
アメリカは日本の数年先を進んでいる!とは、よく耳にしますが、だったら先が分からず困ったときは、アメリカを見れば解決!ってことになりますよね。
しかし、参考には出来ても物事そんなに単純には行きません。アメリカでヒットしたものが日本で同じように普及するわけではない。 それは多分、国民性や社会構造など「環境」が違うからなのでしょうね。この環境というフィルタを通して考えなければ見誤る可能性があると思います。
【クラウドにおける環境の違い】
昨年、AWS Summitで、アメリカのITエンジニアは主にユーザー企業に所属しているということを知りました。
http://www.ipa.go.jp/jinzai/jigyou/global-report.html
日本はITエンジニアの7割がSIベンダーに所属、残る3割がユーザー企業に所属しているのに対し、アメリカは全く逆で、7割がユーザー企業に所属、残る3割がSIベンダーに所属しているそうです。
この事実を知ったわたしは、日本でのクラウド普及には、クラウドプロバイダーと、既存SIベンダーとの連携が重要だと思うようになりました。
【SIベンダーも儲かるクラウド】
普及のカギは「既存SIベンダーも儲かるクラウド」にしなければならないと思うのです。
何故なら、エンジニアの分布からも分かるように、日本のユーザー企業はSIベンダーに頼っている。ということが言えると思います。
ユーザー企業のIT責任者は、既に信頼のあるSIベンダーが推奨する(責任をとってくれる)システムでないと導入出来ないというわけです。
つまり、アメリカのように、ユーザー企業が自己責任においてクラウドへ移行という訳にはいかなそうです。また、日本のユーザー企業IT部門が、ガバナンスを取れるようになれるとしても相当な時間を要するのではないかと思います。
そんなSIベンダー側の多くは、クラウドとどう向き合っていくのか?いまだ決定打のない状態なのではないかと思います。
例えば、「AWSは顧客にメリットをもたらすことは間違いない」とは理解しつつも、セルフサービス(=既存SIベンダーの存在を否定)を標榜するサービスをどう自社のビジネスに取り入れるのか?これはSIベンダーにとっては難しい問題だと思います。
SIベンダーは、自分たちが主導権をもって顧客に提供出来るクラウド。そんなクラウドプロバイダを求めており、その辺りが整ったとき、クラウドはキャズムを超え一気に普及するのではないか? なんて思います。