【インフラエンジニアの将来】 コードの書けるエンジニアに!!
このところ「これからのインフラエンジニアはプログラミングが出来ないとダメだ!」的な論調をよく目にします。何故なのでしょうか？
クラウドに限らずITインフラの仮想化が進んでいるからなんでしょね。
- 〔インフラが仮想化される〕ということは、
- 〔インフラがソフトウェア化される〕ということ、
- そうなると〔プログラムで操作可能〕になる。
- さらに〔効率が良く、ミスを防げ生産性向上〕に繋がる。
こんなロジックなのだと思います。
では、どの言語を習得するのが良いのでしょうか？
これから、大規模な業務アプリやWebアプリの開発を担うエンジニアになりましょー！ って訳ではないと思いますので、ここは、
ITインフラを操作するうえで、
「出来ることが多く、習得しやすい」
言語が良いとおもいます。
ということで、あくまで私見ですが、以下にまとめてみたいと思います。
まず「出来ることが多いもの」という視点から、言語には「ドメイン固有言語」か「汎用プログラミング言語」に大別さにれるということです。違いを簡単に整理すると以下のようになります。
| ドメイン固有言語 |
特定のソフトウェア向けに用意された言語 |
| 汎用プログラミング言語 | 特定のソフトウェアに依存しない言語 Ruby/Python/PHP/Perl/JAVA/C++/C/etc.. |
ShellやPowerShellなどを既にマスターしている人も多いかと思いますが、痒いところに手が届かない。また、アプリケーション側で対応していない場合もあるのかと思います。
ここは、是非とも汎用プログラム言語を覚えたいですね。
あと「習得しやすい」ということですが、プログラミング言語は「高級言語」と「低級言語」に分けることが出来るということ。違いを簡単に整理すると以下のようになります。
| 概要 | メリット | デメリット | |
| 高級言語 | 人間が記述しやすいよう自然言語に近い記法や構文を取り入れた言語 | 習得容易 | 処理遅い |
| 低級言語 | コンピュータが直接解釈・実行できる機械語や、機械語に近い言語 | 処理早い | 習得困難 |
有名どころの言語を以下になんとなくプロットしてみます。
高級言語
↑
| Ruby Python PHP Perl
|
| JAVA C++ C#
|
| PASCAL COBOL
|
| FORTRAN PL/1
|
| アンセンブリ 機械語
↓
低級言語
ということで、ここは習得しやすい高級言語で行きたいところですね(=ﾟωﾟ)ﾉ
あと、これからクラウドが台頭するでしょうから有名どころのクラウドプロバイダの対応状況をチェックしてみました。
■パブリッククラウド各社のSDK対応状況（2014年6月現在）
| AWS | SoftLayer | Google ComputeEngine |
MS Azure |
|
| .NET | ○ | ○ | ○ | ○ |
| Java | ○ | ○ | ○ | |
| JavaScript (Node.js) |
○ | ○ | ○ | |
| Python | ○ | ○ | ○ | ○ |
| Ruby | ○ | ○ | ○ | ○ |
| PHP | ○ | ○ | ○ | ○ |
| Perl | ○ | |||
| C# | ○ | ○ | ||
| ObjectiveC | ○ |
＜ソースとしたサイト一覧＞
・AWS
https://aws.amazon.com/jp/tools/
・SoftLayer
http://www.ibm.com/developerworks/jp/cloud/library/cl-sce-migration-mappingservices/#N10617
・Google Compute Engine
https://developers.google.com/compute/docs/api/libraries?hl=ja
・Azure
http://azure.microsoft.com/ja-jp/downloads/
以上、.NET/Python/Ruby/Rubyが上記パブリッククラウド全てでSDKが出ています。
※全てのサービスでリリースされているわけではない（ストレージサービスには対応出来てないなど。）
あと、Infrastructure as Code（インフラストラクチャーの構築・運用をコード化）の代表格であるChefがRubyで記述できるということを考えると、コードの書けないインフラエンジニアへの推奨言語No.1はRubyじゃないかと思います。
ということで宣伝になっちゃいますが、
2014年6月よりIT系無料勉強会を開催しております。
2014年6月よりIT系無料勉強会を開催しております。
開催した勉強会は、無料動画として配信し「時間」「場所」に制限されず学べるようにしたいと思っています。
以下のページの「申し込む」ボタンから、当Communityのイベント案内メールが配信されるようになります。
~ITエンジニア勉強会~ engineer'sLearning･Vesper | Doorkeeper
是非、ご登録を(^^)/
2016.02.11 追記
無料で参加可能なプログラム勉強部屋始めました！
【イベント告知】勉強会始めました！ 今回は「クラウド定義の整理！」がテーマです。
【インフラエンジニアの勉強会が
ということから、多数、不安を抱
クラウドを軸に勉強会を立ち上げ
あらゆる得意分野をもったＩＴパ
参加者それぞれの自己成長。そし
第一弾として以下の勉強会を実施
ということから、多数、不安を抱
クラウドを軸に勉強会を立ち上げ
あらゆる得意分野をもったＩＴパ
参加者それぞれの自己成長。そし
第一弾として以下の勉強会を実施
ご興味があれば、ご面識のない方でも気軽にメッセージいただければ嬉しいです(^^)/
[facebook] https://www.facebook.com/masahito.tomimoto
[g-mail] masahito.tomimoto@gmail.com
---------------
[facebook] https://www.facebook.com/masahito.tomimoto
[g-mail] masahito.tomimoto@gmail.com
---------------
今回は「クラウド定義の整理！」がテーマです。
• 日時：2014/06/10(火) 19:１0-21:00（19:00開場）
• 定員：15名
• 会場：多目的空間 レンタルスペースシブヤ
〒150-0002 東京都渋谷区渋谷1-17-3 木下ビル6F
• 参加費： 無 料
• 習得できる知識やスキル
・クラウドの歴史
・NISTのクラウド定義
・現在のクラウド
• タイムスケジュール
時間 内容
19:10 – 19:20 主催者から挨拶
19:20 – 19:40 参加者1人1分自己紹介
19:40 – 20:30 講義 「クラウドの本質を理解する！」
20:30 – 21:00 懇親会（ビールと軽食を準備致します！）
■ 対象者
ご興味のある方であれば、どちら様でも参加歓迎です。
【クラウドサービスの利用動向】 日米間での利用実績は2.0倍!!
総務省発表の 「平成24年版 情報通信白書」にクラウドサービス利用実態の日米比較が掲載されています。平成23年における調査結果は、
日本：33.0％
米国：64.6％
となっており、日米間では、なんと2.0倍の差があることが分かります。
（出典）http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h24/image/n4402010.png
平成21年の結果からみると、その差は徐々に縮まっており、日本もＩＴトップランナーのアメリカのように、過半数以上の企業がクラウドを利用する時代が直ぐそこまで来ているといっても過言ではないと思います。
そして、利用する企業は限られた利用からシステム全体に適応させていくでしょう。
オンプレミスシステムに係る技術者は、将来的にかつての汎用機のエンジニアのようなニッチな存在になるのではないでしょうか？
【インフラエンジニアの将来】 クラウド時代にインフラエンジニアは不要?!
下図はMicrosoftがクラウド（SaaS/PaaS/IaaS）を図解したものです。これを見るとITインフラに関わるわたしは不安を禁じ得ません。
オンプレミスが当たり前だったこれまでは、図の通りミドルウェア以下すべてが我々インフラエンジニアの仕事だったわけですから。。。
あらためて見てみると、IaaSに限ってはミドルウェアとOSが残っているものの、SaaSとPaaSにあたっては全ての領域が“クラウ事業者”に侵食されているではありませんか（≧∇≦）
（出典）http://i.msdn.microsoft.com/dn636908.image01_02-02(ja-jp,MSDN.10).png
※ここでいう、インフラエンジニアとは企業のシステムインフラをインテグレーションするエンジニアのことです。また、ネットワークエンジニアやストレージエンジニアなども内包しインフラエンジニアとしています。
インフラエンジニア ぴ〜んち（≧∇≦）
この図をみて、同じように感じられた人も多いのではないでしょうか？
ただ、これはサーバに対してのみが表現された図ですし、これから数年でオンプレミスサーバがなくなるとは思えません。また、プライベートクラウドという存在もありますので、世にあるシステム全てがこの図にあてはまるわけではありません。
しかし、これから先はクラウドの影響で大きく変わっていくことも確かだと思います。
では、インフラエンジニアを取り巻く環境は今後どうなっていくのでしょうか？
何が消滅し、何が残るのでしょうか？
現在のインフラエンジニアの仕事を整理することで考えてみたいとおもいます。
扱うハードウェア・ソフトウェア
＜ハードウェア＞
サーバ
ストレージー
ネットワーク
セキュリティアプライアンス
端末（PC・タブレット・スマホ）
＜ソフトウェア＞
業務のためのソアプリケーションではなく、システムのためのソフトウェアが基本となるが、汎用的なメール・グループウェアなどのコミュニケーション系を扱うことも多くあります。
■OS系
OS／仮想化
■ミドルウェア系
認証／データベース／アプリケーションサーバ／グループウェア
■管理系
資産管理／配布／セキュリティ／バックアップ／冗長化
■情報系
メール／グループウェア／メッセンジャー／ファイルサーバ
上記製品に関連する顧客企業の変化(新規・更新／追加・変更／更改・移行／廃棄) に応じ、インフラエンジニアの仕事が発生します。
パブリッククラウドの性質を考えると、確実にハードウェア周辺はシュリンクしそうですね。ソフトウェアは無くなりませんがインストール作業など下流の仕事はシュリンクしていきそうです。
やはり、以前 【インフラエンジニアの将来】 キャリアアップするために に綴ったように「上流」そして「マルチ」を旗印にキャリアアップを考えるべきだと感じています。
2016.02.11 追記
無料で参加可能なプログラム勉強部屋始めました！
エンジニアの同一労働同一賃金はおかしい！
同一労働同一賃金とは、性別、雇用形態（正社員、契約社員、派遣社員など）、国籍などに関係なく、同一の職種に従事する労働者に対して同一の賃金を支払う賃金政策のことらしいのですが、
わたしは雇用形態によって賃金を変えるべきだと思います。
同一労働、つまり同じ付加価値を会社に提供しているのであれば、非正規雇用者に対して 会社はリスクを回避している分多く支払う必要があると思うのです。
わたしはＩＴエンジニアの人材サービスに関わっておりますので、このモデルでの説明となりますが、顧客へ100の価値を提供し100の対価を得たとした場合、下図でいうと
正社員・・・「1,労働対価」のみを労働者へ分配、残り全ては会社。
契約社員・・「1,労働対価」「終身雇用リスク」「福利厚生」を労働者への分配、残りが会社。
フリーランスの場合は「5.労基法対応」分もエンジニア側となりますね。
☆→労働者取り分 ●→会社取り分
| 正社員 | 契約社員 | フリー | ||
| 1,労働対価 | 労働対価 | ☆ | ☆ | ☆ |
| 2.終身雇用リスク | 65歳定年までの雇用リスク | ● | ☆ | ☆ |
| 3.福利厚生 | 教育/支援制度/フォローアップ | ● | ●or☆ | ☆ |
| 4.法定福利 | 社会保険/労働保険 | ● | ● | ☆ |
| 5.労基法対応 | 有給付与/安全衛生/勤怠管理 | ● | ● | ☆ |
| 6.マーケティング・営業 | 市場調査/事業企画/顧客開拓/顧客との関係維持/案件開拓 | ● | ● | ● |
| 7.組織維持・管理 | オフィス/経理/財務会計/税務/訴訟リスク | ● | ● | ● |
【インフラエンジニアの将来】 東京オリンピックまでがキャリアアップのチャンス!!
いまキャリアアップのチャンスだと思うのですよね〜
このところ、アベノミクス好景況によりリーマンショック以降抑えられてきた企業のIT投資が回復し、業界は人手不足に陥っています。一部では2015年問題（マイナンバーやみずほ銀の大型案件によるIT技術者不足とその後の人余り）も囁かれていますが、 2020年東京オリンピックまでは人手不足は続くだろうという見方が強いように思います。
そして、この人手不足はエンジニアにとってキャリアアップに最適な時期だと思います。
何故なら、人余りの時期は調達側は理想とする経験・スキル保有者を吟味し選別しますが、調達が困難な時期は選別する余裕がありません。多少の経験・スキル不足でも採用に踏み切ることが多くあります。
このようなパターンで転職に成功した人や、希望する案件に就いた人は多いのではないかと思います。（少なくとも私の回りでは多いデス）
ただし、多少の経験・スキル不足でも採用に踏み切ることが多くあります.
と前述しましたが、人手不足だからといって何でもかんでも採用されるわけではありませんね。ｗ
では、どのようなエンジニアであればキャリアアップに成功するでしょうか？
まずは、こんな記事がありましたのでご覧ください。
「30代・下請け」という状況から上流工程を目指し、見事成功した木下さんの勝因として、下記のようなことが挙げられます。
- 「上流工程に携わりたい」という転職テーマを明確に持っていた
- 複数の強みを自覚できていた
- 非公開求人に応募できた
- 準備（適切なレジュメを作成し、積極的な面接指導を受けたなど）を怠らなかった
- 面接時、経験が少ないことで弱気にならず、信念・迫力を持って強みを的確にアピールできた
アデコ 人材紹介サービス部 コンサルタントの方が、30代上流工程経験なしの、通常では困難だと言える転職を成功させた事例から、上流へ転換するのに何が必要か？綴られた記事です。
私もおおむね同感です。
わたしの経験上も「○○したい！」という思いの強い人が、伸びています。（それも勝手に）
ただ、全てのエンジニアがそういう強い思いがあるかといえば、そうでないほうが多くを占めると思います。
漠然と「要件定義・設計に興味はあるけど」「上流工程にいきたいけど」と思いながら特に行動には移さない人たちです。
そういう人には、上司（人材サービス系の会社であれば担当営業・コーディネーター）に思い切って相談してみることをお勧めしたいですね。
「わたし！ ○○したいと思っているんデス！ (｀ー´)／」
と、強めの意思表示をして向かう方向を共有する（関係者に知ってもらう）のです。
そうすることで、例えば、どこかで希望するポジションの人員が不足した時に白羽の矢が立つことになります。
（そんな当たり前のことどこでもやってるよ！と指摘されそうですが、出来てないところもありますので）
そして必要な準備は何なのかを明確にし、着々と準備を進めるのです。
足りない知識を座学で補い」、職務経歴書を整え そして、
「経験はありませんが、○○の知識は座学で習得出来ております。」
「そして、○○に関連した業務がしたいという強い想いが御座います！」
と相手にアピール出来れば、採用間違いなしだと思います。
【インフラエンジニアの将来】 上流工程を仕事にする為に必要な思考癖
以前、 【インフラエンジニアの将来】 キャリアアップするために
で、インテグレーションに関わるエンジニアのキャリアアップには、これまで以上に “上流” を目指すことが重要なのでは！ という意見を綴りました。
“上流”の対義語は“下流”ですが両者の大きな違いは、仕事の成果である価値を生み出すために上流工程は、思考と知識が、より必要になることだと思います。
例えばサーバ構築を例にいうと、設計するのと、設計書を基に構築するのとでは、前者は「何故その値にするのか？」「何故その手順にしたのか？」などの根拠を言える必要があり多くの知識と思考とが必要となりますが、後者はそのやり方を知っていればよいでしょう。
今回、この“思考”することについて共感するブログ記事に出くわしたので紹介したいと思います。
たとえば、エンジニアなら、過去に自分が開発したシステムにおいて、
なぜ、そのフレームワーク、ツール、ライブラリ、DBを使ったのか？
他に、どのようなフレームワーク、ツール、ライブラリ、DBが候補として上げられたのか？
他の選択肢と比べて、どの様な短所と長所があるのか？
なぜ、他の選択肢ではなく、それを選んだのか？
使う前に、どのように性能評価・検証したのか？
なぜ、ある部分を汎用的に作り、別の部分をハードコーディングしたのか？なぜ、その設計だと、生産性が高く、トラブルのリスクやメンテナンスコストが低くなるのか？
もっと低くできる余地として、どのようなものが考えられ、なぜ、それを作り込まなかったのか？実際に、どのようなトラブルが起こり、それにどのように対処したのか？おもしろいことに、有能な人というのは、そういう具体的な行動を聞き出すと、細部まで鮮明に覚えていて、スラスラ答えます。
徹底的に細部まで、なぜその行動を取ったのか？と問い詰めていくと、打てば響くように答え、持論を展開します。
一方で、無能な人というのは、まずそもそも、細部を覚えていません。理由を問い詰めても、曖昧な答えしか返ってきません。
なぜ、そのとき、そのPCサイトのケータイ版を作らなかったのか？
なぜ、ターゲット顧客を、中高年の男性に絞った商品にしたのか？
なぜ、その設計で、セキュリティー上問題ないと言えるのか？
なぜ、そのとき、普通のファイルシステムを使わずに、RDBをわざわざ使ったのか？要するに、仕事というのは、意志決定の連続であり、どれだけ質の高い意志決定ができるかで、仕事の質が決まります。
わたし自身、少し耳の痛い内容でもありましたが、日々の仕事の細部まで「Why？」と自分に問いかけることは上流工程の仕事にする為に必要であり、それが深まれば仕事の質を高めることに繋がるのだ！、と共感した次第です。
常に「Why？」と問いかける思考癖を身に付けたいものです。
.png){kind=link}