クラウドに向かないシステム
クラウド（Public IaaS）に向かないシステムはどのようなものか考えて見ました。
- DBなど膨大なI/Oを発生させるシステム
これはクラウドの “仮想レイヤ” “シェア” がパフォーマンス低下の要因になってします。
この問題に対してIBMが買収したSoftLayer等のプロバイダは、ベアメタルサーバ（専有物理サーバ）が選択できるようになっています。
http://techtarget.itmedia.co.jp/tt/news/1309/12/news02.html - ミッションクリティカルなシステム
ダウンしては困るシステム。じゃ~自前でクラウドプロバイダ以上に堅牢な仕組みを構築・維持できるのか？という問題もありますが、OS以下がブラックボックス（SLAだけ）では不安。理解しておきたい。分からないのであれば選択出来ない！というのは分るような気がします。
また、メンテナンス時間などプロバイダの都合に合わせざるを得ないのもネックになりますね。 - 予算管理の強い組織のシステム
特に官公庁など予算の影響が強い組織では従量課金は不都合が発生する場合があるでしょうね。また従量課金は、携帯電話の「パケ死」のように知らないうちに異常な通信かなんかが発生し膨大な請求が来るんじゃないか？的な心配を抱くユーザーもいるのではないでしょうか？ - 人が余っている組織のシステム
言うまでもなく、配置換えや解雇も出来ずシステム運用要員が余っている組織では、自分たちでやったほうが良いでしょう。ただ、この理由でクラウドに移行できないのであれば、余った要員の転用について考えた方が良いとは思いますが。。。
先日、AWSのインテグレーションを本筋にしている知人が「クラウドと余剰人材転身案とをセットで提案すれば必ず売れる」ってマジメな顔で言っていましたｗ
IT業界の多重下請構造は問題なの？③
初回の、SI業界の多重下請構造は問題なの？① では、以下のような
「多重下請構造における問題点」を洗い出しました。
●健康保護の問題
●間接業務の増幅
●不当な利益
●人材マネジメント不全
●価格から抱く期待とのズレ
また、SI業界の多重下請構造は問題なの？② では、
「何故こんな構造になっているのか？」について考えてみたところ
「日本の現労働法下で必然的に作り上げられた人材供給システム」
ではないのか、という一つの答えを導き出しました。
次は、
「理想の構造とは？」
「では、何をどのようにすれば良いの？」
について考えてみたいと思います。
■理想の構造とは？
やはり理想は多重ではないシンプルな構造が何かと良いですね。
・[大手Ａ社]に[下請けA社]が間を挟まずに “派遣契約” で人を出す。
※派遣法では派遣先である[大手Ａ社]にも労務管理義務が発生するため。
・[大手Ａ社]から[下請けA社]が案件の一部を間を挟まずに “請負契約” で請負う。
※[下請けA社]のエンジニアの労務管理は[下請けA社]が実施する。
※さらに、必要であれば[下請けA社]に[孫請けA社]が “派遣契約” で人を出す。
どちらか、もしくは両方で問題点はすべて解決されまーす！
と、、ここまで来て気がついたのですが、ここまで考えたことは、おそらく既知の事柄で、労働局は、この状態にしたくて “2重派遣の禁止” や “偽装請負撲滅” 等の運動に勤しんでいるのでしょう。。。
しかし・・・・状況は改善されていませんね・・・
それではということで、解決に向け少し大胆に考えてみました。自分で見聞したわけではないのですが、アメリカのエンジニアは主にユーザー企業に雇われており、新システム構築などの山場（沢山のエンジニアが一時的に必要）を終えると、次の現場へと雇用されていくとききます。もしこれが本当なら理想のモデルと言えるのではないでしょうか？
「会社はプロジェクトが終了すればエンジニアを解雇でき、エンジニアは不満や、不安なく解雇を受け入れ、次のプロジェクトは比較的簡単に見つかる。エンジニアはそんなワークスタイルを良しとしている。」このアメリカ型モデルが実在すると仮定すると、日本との相違点は次の3点だと思います。
・労働法の解雇規制が緩い。
・エンジニアは次の仕事が見つかる。
・組織への所属欲求が低い。
さて、このようになるには何が必要なのでしょうか？
まず、エンジニアを①解雇可能な労働法が必要でしょう。但し経営の怠慢は牽制されるようなバランスのとれた法律でなければならないのはいわずもがなですが。。つぎに、エンジニアが「次のプロジェクトにもありつけるだろう！」という安心感がを醸成できるようなような②包括的なジョブマッチングの仕組み。があれば良いのではないでしょうか？
（最後に）
以上、妄言をつらつらと書きましたが、「労働者は会社に従属するもので、会社は社会からの落伍者を出さないよう教育訓練など義務を負うといった、これまでの構造が、産業が複雑になったことや、働く側の価値観が多様化していることから、合わなくなってきているような気がします。
現在も、労働者に関する問題においては、ハローワークや職位業訓練などにおいて、国策として多大なリソース（人・物・金）が割り当てられています。 また、前述したように、派遣法に関する議論や、 “2重派遣の禁止” や “偽装請負撲滅”など、労働法という根本原因を無視した表層的な問題是正の取り組みがなされているように感じます。一度、ゼロベースで考えてみる必要があると思います。（そのような専門委員会があるのか分かって言ってる訳ではありませんがｗ）
・仕事と労働者を効率的且つ包括的にマッチング可能な情報システム。
・産業や働き方の多様性も十分考慮された関連法規。
・社会からの落伍者を出さないセフティーネット。
これらのあり方について、また今度、自分なりに考えてみたいと思いました。
IT業界の多重下請構造は問題なの？ ②
前回、IT業界の多重下請構造は問題なの？① では、
多重下請け構造の問題点を洗い出してみました。つぎは、
「何故こんな構造になっているのか？」
「理想の構造とは？」
「では、何をどのようにすれば良いの？」
を順をおって考えてみたいと思います。
■何故こんな構造になっているのか？
多重下請構造は、大きな会社から、従業員数名の小さな会社まで、数多の会社が商流上で関連している状態です。ここには「①大手に一括して発注される」「②請負元エンジニアだけでは足りない」といった特徴があるように思います。
①については、ユーザー企業のシステム部門にプロジェクトを統括するマネジメント力・技術力がないことが要因だと思います。あるデータでは、アメリカと日本ではエンジニアの所属先の比率が正反対だということを示しています。
ユーザー企業 ベンダー
アメリカ 7割 3割
日 本 3割 7割
つまり、ユーザー企業は十分な技術者を抱えられていないことから、望むシステムをワンストップで、そして責任をもって一括請負い可能なベンダーを必要としているといえるかと思います。
次に②についてですが、一括受注した案件のなかには自社リソースでは提供不可能なもの（例えば顧客がIBMのハードを希望しているが当該ハードウェアのノウハウを持っていないなど）と、もう一方で、提供可能だが要員不足で対応できないものとがあります。
後者については、注文を受けて初めて生産を始める受注産業であるシステムインテグレーションは、大勢のエンジニアを抱えていると経営上のリスクになります。案件が無い時に人件費が負担になるということですね。
また逆に案件を多く受注したときに不足するエンジニアを調達するためにも、エンジニアを外部調達する仕組みが必要だと言えると思います。
また逆に案件を多く受注したときに不足するエンジニアを調達するためにも、エンジニアを外部調達する仕組みが必要だと言えると思います。
健全な経営をしようと思ったら非稼働率が10%（10人のエンジニアが在籍する会社であれば1名が空いている状態）くらいが適当かと思います。それを前提に考えると数十人単位で人を集めるには沢山の会社が関係することになるのは当然といえますね。
つまり、この多重下請け構造は、日本の現労働法下で必然的に作り上げられた人材供給システムであるといえるかと思います。
この仕組みのおかげで、必要な時に必要な数の人員が調達可能となり、エンジニアも仕事にありつけるという効用を業界にもたらしているといっても過言ではないのではないでしょうか？
また、エンジニアが独立するのに、低資本で開業可能な為、簡単にスピンアウト出来ることも会社を多くしている要因の一つだと思います。
※特定派遣の廃止が濃厚のようです。この下請構造に蔓延る一部のよろしくない会社の排除が趣旨とみましたが、根本である雇用制度を無視して廃止を行っても偽装請負に形をかえるだけのような気がします。また、偽装請負撲滅も同時に敢行した場合は、日本企業のＩＴ化への悪影響、また一部のＩＴエンジニアに仕事が回らずＩＴ業界を去るといったマイナスも考えられると思います。
この件については、またどこかで考えを整理し意見を述べたいと思いますが、産業の特性に応じた雇用制度の多様性も検討したほうが良いように思えます。
次は「理想の構造は？」について考えてみました。
IT業界の多重下請構造は問題なの？ ①
ことあるごとに「多重下請」が批判的に論じられていますが、一体何が問題で、どうあるべきなのか？について自分なりの意見を纏めてみました。
最初に今の構造の問題点を洗い出し、その後にその原因について考察してみたいと思います。
■問題点
仮に日本にいる全てのエンジニアが200人だとし、大手2社に50人ずつ、その他10社に10人ずつ所属する【下請け構造】をモデルに考えてみます。
【下請構造】
[大手Ａ社]－50人
┗[下請けA社]ー10人
┗[孫請けA社]ー10人
・
・
[大手Ｂ社]－50人
┗[下請けB社]ー10人
┗[孫請けB社]ー10人
・
・
①安全衛生の問題
通常、所属会社の違うエンジニアが集ってプロジェクトチームが出来ます。その状態では往々にして会社を跨いだ指示命令系統が出来る。つまり、[大手Ａ社]のPMが、[下請けA社]のエンジニアに直接指示命令するケースがあるが、これは法令違反です。（労働基準法）
エンジニアの健康保護の責任はその所属会社にあるので、勤務時間と切っては切り離せない指示命令は所属会社の上司がするものです。
しかしながらプロジェクトの現場では実質不可能に近い。
つまり、労働者の健康保護を目的とした機能が不完全になることがあるということです。
②間接業務の増幅
単純に会社数が増えれば、間接要素（オフィス、税務・会計、システム、エンジニア以外の人件費...）も増える。会社の数が少なければ少ないほど統合メリットが出て効率は良いと言えると思う。
・
③不当な利益
通常、報酬（売上）は価値に見合っているべきだと思いますが、例えば、[大手Ａ社]の仕事を[下請けA社]が受注し[孫請けA社]のエンジニアが作業するようなケースがある。
この場合[下請けA社]が問題となる。ただ、[下請けA社]は価値を生み出していないというのは言い過ぎで、[孫請けA社]より営業工数を掛けて営業しているから[孫請けA社]には取れない仕事が受注できたともいえると思う。また[下請けA社]は契約上のリスクも負っている。しかし直接的な業務といえば伝票を起こしているだけと言っても過言ではない。この位置の会社がマージン取り過ぎということが往々にして起こっているように感じる。
④人材マネジメント不全
例えば[孫請けB社]のエンジニアが、現場で困っているとしよう、現場で相談出来るよ内容であれば問題ないのですが、中には[大手Ｂ社]のプロマネからのパワハラ、不明確な指示など直接言えない内容で困ることも多くある。通常は所属会社の営業が問題の種を早期発見し未然に沈静化する。しかし下請け構造が多重で複雑になると、時間がかかったり、話しの要旨が伝わらなかったりでコミュニケーション不全に陥り問題が悪化することがある。突然「やってられませーん！」と言って離反するメンバーが出ることも。。
⑤価格から抱く期待とのズレ
[ユーザー企業]→[大手Ｂ社]→[下請けB社]→[孫請けB社]→[ひ孫請けB社]のような多重構造を想像してほしい。それぞれの会社が20%の粗利をとると[ひ孫請けB社]へは50万しか入ってこない。もちろん[ひ孫請けB社]も粗利をとるため全額エンジニアには渡らない。[ユーザー企業]は100万の価値を期待する。しかし実際には[孫請けB社]は50万そこそこの価値しか提供できない。といった構図が出来あがりしばしば顧客不満足につながることがある。
私が感じる問題点は以上となります。
次は、「何故こんな構造になっているのか？」について考察してみたいと思います(^^)/
※何かお気付きの点やご意見など御座いましたらコメント頂けると幸いです。
（メールでも結構です！ masahito.tomimoto@gmail.com）
また、宣伝になっちゃいますが、
2014年6月よりIT系無料勉強会を開催しております。
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がカバーする範囲も限定だったことでしょう。
システムを定義・設計するシステムエンジニア、ソフトウェア開発を行うプログラマー、導入したシステムの運用・保守をするカスタマーエンジニアがいたとのこと。このころアプリケーション以外のOS やハードウェアなどのシステム管理はメーカーのエンジニアが自分たちで行っており、システム管理者と呼ばれていたようで、今のようなインフラエンジニアと呼べる職種は存在しなかったように思います。
②ネットワーク時代
この時代の特筆すべき事として「インターネット」と「ダウンサイジング」とがあるかと思います。
1995年のインターネット商用利用解禁を機にビジネスに求められるＩＴの範囲が拡大、企業はホームページを持ち、PCが1人1台配られオフィスアプリケーションを利用しメールでコミュニケーションするのが当たり前の世界に変貌。
またソースコードで配布されるUNIXの導入、Windowsに代表されるハードウェアとOSの水平分業、またその上に乗るパッケージソフトが充実など、オープン化した背景もあり、汎用機でシステムを維持管理するのは大変高価。またベンダーにロックインを嫌ってダウンサイジングの機運が高まった。
その結果、メーカーに頼らずシステム管理ができるようになった。このシステム基盤の管理を行うのが今のインフラエンジニアだと捉えています。
ＩＴの適用範囲拡大に呼応し、システムも複雑になりましたが一人のエンジニアがサポート出来る範囲は限られるため（中には全てを熟すスーパーエンジニアもいたとは思いますが）サーバエンジニア、ネットワークエンジニア、セキュリティーエンジニア、サポートエンジニアなる職種が出現。そしてこれらをひっくるめてインフラエンジニアと呼ぶようになったように思います。
③モバイル・ビックデータ時代
そして近年では、スマートフォン・タブレットのビジネス利用が浸透し、ＩＴの役割はコスト削減や業務効率化の枠を超えソーシャルやビックデーターなどに代表される新たな価値創出の重要手段となりました。このことからビジネスに求められるＩＴの範囲は更に拡大し、システムはより複雑になって来ていると思います。
ここまでを纏めると下表のようにまとめられると思います。
適用範囲 複雑性
①大型汎用機時代 低 低
②ネットワーク時代 中 中
③モバイル・ビックＤ時代 高 高
ここまでを見ていると、今後も益々拡大・複雑化したシステムを支えるため、更に職種も細分化されるように思いますが、注視しなければならないことがあると思っています。
それは技術革新による「抽象化」の視点です。
各種便利なツールが登場した結果、エンジニアは細部にまつわる知識が薄くても取扱うことが可能となり、生産性も向上しました。また、より多くのもの（機能）を扱うようになりました。
例えばGUIの登場によりコマンドを知らなくてもOSやアプリが操作可能になり、配布ツールの登場により多数のマシンを個別対応しなくてもよくなりました。反面、冗長化・仮想化などの新たな機能が当たり前のように求められるようにもなりました。
そしてこの抽象化は、昨今のクラウドの台頭によりさらに顕著になっているように感じます。パブリッククラウドを基盤にするのであれば、もうサーバやストレージ等のハードウェアに触ることもなくなるのですから。。
話の本題であるインフラエンジニアの将来に話を戻しますが、インテグレーターの本質的価値は、顧客の要望に対し実在する技術でインテグレーションし、その要望に応えることです。顧客視点でどのようなエンジニアを求めるかを問うてみれば、例えばネットワークのデザインもでき（上流）、CiscoのコマンドもYAMAHAやSONICのその他多種の機器に慣れ親しんだ（ディテール）エンジニアより、ディテールの知識はなくてもネットワークもサーバーもストレージも、良質なコミュニケーションで要望を引き出してくれ、クラウドやツールなど便利な手段を駆使し、要望も満たすことの出来るエンジニアが求められるのではないかと思うのです。
以上のことから「上流」そして「マルチ」を旗印キャリアアップを考えるべきだと感じています。
2014.03.14更新
---------
IPAがこのような報告書発表してたんですね(^^)/
クラウド時代の人材育成検討委員会報告書
http://www.ipa.go.jp/jinzai/itss/activity/itss_cloud_houkoku20110519.pdf
