本文へ移動
お問い合わせ

2019.03.02 / ITベンダー・SI事業者

「灰色のサイ」を暴走させないためのエンジニアをどう育てるか

「灰色のサイ(グレーリノ)」という言葉がある。発生する確率が高い上に、影響も大きな潜在的リスクのことを指す経済用語だ。草原に生息するサイは体が大きくて反応も遅く、普段はおとなしい。しかし、一旦暴走し始めると誰も手を付けられなくなることに由来する。不良債権や不動産バブルなど、そこに危険の予兆があることは誰もが知っているのに、その存在に慣れてしまい軽視しているのが「灰色のサイ」だ。

SIビジネスにも2匹の「灰色のサイ」が潜んでいる。それは、「少子高齢化」と「内製化」だ。

「少子高齢化」という「灰色のサイ」は、提供できる人数で収益が決まる工数ビジネスが限界を迎えることだ。もちろん提供できる人材に高い技術力や他社と差別化できるスキルがあれば、例え提供できる人数が少なくても収益は確保できる。しかし、そうでなければ、収益の拡大は期待できない。

なぜ、軽視してしまうのか、いや軽視したいのか、それは、いま仕事が回っているからだ。まだ大丈夫、何とかなると思いたいからだろうか。

確かに最近、稼働率の高い企業は多い。当然同じ給与を払い稼働率が上がれば利益も増える。しかし、将来人手が確保できなければ、売上を立てることはできず、自ずと収益は下がってゆく。

もともと利益率は高くないので、工数需要が少しでも減れば人件費をまかなうことも難しくり、昇給は押さえられる。そうなれば、人件費は安いが若くて優秀な稼ぎ手の人材から、次の可能性を求めて離れてゆくだろう。その結果、社員の高齢化がすすみ原価率が上がる。技術力で差別化できないエンジニアであれば、当然他社との競争に晒され、単金を上げづらい。一方で、高齢化する社員にも昇給が必要となると、ますます原価率は上がり利益確保は厳しくなる。そんな「灰色のサイ」が存在している。

「内製化」という「灰色のサイ」は、工数需要そのものを減らす動きだ。このブログでも度々取り上げているように、「デジタル・トランスフォーメーション」や「攻めのIT」に多くの企業が取り組もうとしている。これは、これまで主流を占めていた「コスト削減のためのIT」ではなく、「売上増大のためのIT」だ。ITやデジタルテクノロジーを駆使して、事業の差別化を図り、競争力を向上させようということ。そんな自社の競争力の源泉たるITのスキルや人材を外に丸投げすることはない。自社の収益を左右する製品開発同様に社内に人材を抱えスキルを蓄積してゆこうとするだろう。

もちろん、人材は限られているから、アジャイル開発、DevOps、クラウドを積極的に採用し、生産性とスピードを追求することになるだろう。そうなれば、要員が不足したとき外部にリソースを求めたとしても、同様のスキルを持っている人材でなければ対応できないことになる。

工数需要そのものが減少することに加え、求められるスキルも変わる。そんな「灰色のサイ」が暴走すれば、もはや「いままでのやり方しかできない人材」に需要はない。

このような2匹の「灰色のサイ」を暴走させないためには、これに対応できるエンジニアの確保、育成を急がなくてはいけない。

求められるエンジニア像

いま、時代は経営環境の不確実性の高まりやビジネス・スピードの加速に直面している。ITがこれに対応するためには、ビジネスの最前線である現場の要求に即応できなくてはならない。そのためには、開発と保守/運用を分業して対応する余裕はない。要求仕様を事前に確定させ、外注手配や見積依頼、契約手続きなどに時間をかけていると経営環境が変わってしまうケースもある。そのため「臨機応変」に現場の要求に対応できなくてはならならない。

このような「臨機応変」を求められるシステム需要が増加する一方で、従来の「企画・設計・開発・保守・運用」が分離・分業できるシステム開発の需要は将来的に減少する。このようなシステムは、生産性向上や効率化のためのものが大半を占めているため、計画が立てやすく投資対効果も計測しやすいため、PMによる管理も可能だ。しかし、「臨機応変」を求められるシステムになると、個々の案件規模は縮小し、アーキテクチャの選定、インフラの構築、設計、開発、運用を小規模なチームで短いサイクルで回しながら完成度を高めることで変化に対応しなければならない。これに対応するには、クラウドについてのノウハウやアジャイル開発・DevOpsといった開発から本番運用に至る一連のサイクルを一人または少人数でこなす必要があり、従来型のPM(プロジェクト管理者)では、役割を果たせないことが想定される。

もちろん、特定の分野で高度な技術を有し、グローバルにも貢献できる存在であれば、フルスタック・エンジニアを目指す必要はない。しかし、いずれにしろどちらかの選択を迫られることになるだろう。

また、エンジニアの役割を「システムを完成させること」に置くのではなく、「お客様のビジネスを成功させること」と位置付け、旧態依然とした「工数としての労働力」としてではない、「ビジネスと技術をつなぐ専門家」にしなければならない。

時代の要請に応えるスキルをエンジニアに身に着けさせるには、「彼ら自身にやらせてみること」しかない。過去の成功体験のバイアスを持ち続けている管理者は、時代が変化したという現実を受け入れなければならない。そして、新しい取り組みにチャレンジさせる勇気を持たなければならない。管理者の使命は、まさに「従来エンジニア像の創造的破壊」を推し進めることだ。

育成のための取り組み

技術的難しさは、やがてクラウドや人工知能に置き換えられてゆく。そうなれば、「工数としての労働力」は、必要とされなくなるだろう。行き着くところ、お客様に必要とされる存在とは「企画や設計ができ、お客様とビジネスについて話ができるエンジニア」である。彼らをコンサルタントと区別することはもはや意味がなく、そういう人材こそ、お客様に求められるエンジニアであり、今後のビジネスを牽引する大きな原動力になる。

では、このような人材はどのように育ててゆけばいいのだろうか。

「勉強し続ける文化」を育てること

次々と登場する新技術に好奇心を持ち続け、勉強し続けるための習慣を身につけさせることが重要である。退社後は一切技術に触れないようでは、フルスタック・エンジニアとして生き残る事はできない。しかも、技術が変化するスピードは速いため、新たな知識やスキルを習得するための教科書を手に入れることは、実質的に不可能である。そのため、自らがコミュニティに参加し、積極的に貢献しながら学習しなければならない。オープンソースやクラウドサービスの普及により、学習コストは劇的に低下しており、意欲があれば決して難しいことではない。

しかし、会社が極限まで稼働率を上げることを追求していては、社員には新技術を学習する意欲も余裕も生まれない。彼らが自発的に学ぶことを奨励し、その機会を与えることが重要である。また、エンジニアにとって成長機会は大きな喜びであり、その機会を与える企業への定着率も自ずと高まるだろう。こうした取り組みが、ビジネスを支える優秀な人材を育てるために必要である。具体的には次の施策を行う。

  • 社内ハッカソン、Meetup、LTなど習得した技術を使って開発を実践する。そして、技術を共有するためのイベントを開催し、エンジニア間の横のつながりを作る
  • 会社費用による社外コミュニティへの参加を承認し、新しい技術の現在地をエンジニア自らが肌で感じられるようにする
  • 新技術を学習する環境は自前で準備せず、社外のオンラインコンテンツを採用していつでも受講可能とする
  • 新技術を試用できるパブリッククラウド上の砂場環境を提供するとともに、エンジニアにとって必要十分な開発環境を整備する
「原理原則」を学ばせること

特定の技術の使い方だけに習熟することを求めず、「なぜそのように動作するのか」、「何のためにそのような仕組みが生まれたのか」という原理原則を理解させることも重要だ。特定の技術には流行廃りがあり、なにより全ての技術に習熟することは不可能だ。しかし、原理原則を学んでおくことで新たな技術を習熟する時間は短縮され、必要とあればすぐに実践で活かすことができる。また、様々な技術の目利きもできるようになる。具体的には、社内有識者が講師となり、ITシステム構築に関わる原理原則を学習する研修体系を整備してオンラインで学習可能とし、有識者が持つナレッジを伝承する

「幅広い分野」を学ばせること

心理学やマーケティングなど、IT技術以外についても学ぶ機会を与えることが重要だ。ITビジネスがサービスへシフトする中で、今後はユーザーがそのサービスをどのように受け止め、どういう行動をとるかを理解した上で技術的な実装を行う需要が高まる。さらに、プレゼンテーションやコミュニケーション、交渉や説得と言った顧客応対スキルも必要となる。つまり、エンジニア自身が「技術とビジネスをつなぐ役割」を果たさなければならない。具体的には、次の施策を行う。

  • 開発エンジニアだけではなく、新規事業や共創の推進に必要となる人材タイプとスキル領域を定義する
  • 中途採用や他部門からの異動により、推進組織に各人材タイプのロールモデルとなる人材を配置する
  • 社外のオンラインコンテンツを採用し、各人材タイプに必要となるIT技術以外のスキルを学習できる環境を整備する

オフショア人材との差別化

新興諸国には積極的にIT人材の育成を図っている国もあり、知識やスキルという点では、既に日本のエンジニアとの差はない。開発作業だけなら、コスト面で圧倒的に有利なオフショアへシフトするか、同等の単金で仕事を受けるしかない。

しかし、日本のエンジニアにはオフショア人材にないメリットがある。それは、「業務の現場に近い」ということである。日本のビジネス文化や習慣を理解し、お客様と日本語で業務について話ができること。

「インフラやプラットフォームが分かり、開発が分かり、運用が分かり、そして、お客様と業務について話し合い、交渉できる」

これからはそんなエンジニアこそが必要になる。つまり、日本の高賃金に見合う仕事ができるエンジニアでなくてはならない。自分の専門分野に固執し、それを出ようとしないエンジニアは、残念ながら役割を失ってしまうだろう。

このようなエンジニアについてのビジョンを社内で共有し、そのための取り組みを加速させるべきだ。「灰色のサイ」はいつ暴走するか分からない。いや、もしかしたら、あまりに近くに居るのでその暴走に気付いていないだけなのかも知れない。

ITビジネス・プレゼンテーション・ライブラリー/LiBRA

LiBRA 2019/3月度版リリース====================

  • ITソリューション塾が2月より新しいシーズン(第30期)に入りました。それに伴い、下記プレゼンテーションを更新しました。
  • 動画セミナーの一部を新しい内容に更新しました。

=========================================

動画セミナー*会員限定*

  • 【改訂】サイバー・フィジカル・システムとデジタル・トランスフォーメーション
  • 【改訂】ソフトウエア化するインフラとクラウド・コンピューティング
  • 【改訂】IoT

総集編

【改訂】総集編 2019年3月版・最新の資料を反映しました。

ITソリューション塾・最新教材ライブラリー

*ITソリューション塾が2月より新しいシーズンに入りました。それに伴い、下記プレゼンテーションを更新しました。

  • 【改訂】サイバー・フィジカル・システムとデジタル・トランスフォーメーション
  • 【改訂】ソフトウエア化するインフラとクラウド・コンピューティング
  • 【改訂】IoT
  • 【改訂】AI

ビジネス戦略編

  • 【改訂】フィジカルとデジタル(2) p.4
  • 【改訂】デジタル・トランスフォーメーションを加速するサイクル p12
  • 【改訂】業務がITへITが業務へとシームレスに変換される状態 p.10
  • 【新規】差し迫るSI/SES事業の限界 p.24
  • 【新規】顧客価値とは何か p.195〜199
    • 事例:RPA導入における業務の流れ195
    • 提案と価値とは何か196
    • 提案が成功する3つの要件197
    • ソリューション営業は通用しない198
    • 「共創」ビジネスの本質199

*ノートに解説も合わせて掲載しています。

サービス&アプリケーション・先進技術編/IoT

  • *変更はありません

サービス&アプリケーション・先進技術編/AI

  • 【新規】「情報」を意味する3つの英単語の違い p.4
  • 【更新】一般的なプログラムと機械学習を使ったプログラム p.22

クラウド・コンピューティング編

  • 【新規】クラウドによる新しいIT利用のカタチp.17
  • 【新規】クラウドへの移行を成功させるための7原則 p.100
  • 【新規】クラウドへの移行が難しい場合 p.102

サービス&アプリケーション・基本編

  • *変更はありません

サービス&アプリケーション・開発と運用編

  • *変更はありません

ITの歴史と最新のトレンド編

  • 【新規】依存集中型から自律分散型へ p.22

ITインフラとプラットフォーム編

  • 【新規】ソフトウェア化とはどういうことか (1) p.60
  • 【新規】ソフトウェア化とはどういうことか (2) p.61
  • 【改訂】「インフラのソフトウエア化」の意味・仮想化の役割 p.62

テクノロジー・トピックス編

  • *変更はありません

ブログ記事一覧へ