これからの時代で生き残るために「DX戦略に重宝されるエンジニア」を目指そう
DXプロジェクトのエンジニアは苦労が多い
プロジェクトでスコープ外のタスクが大量に発生して困っていませんか。しかも、年々ひどくなっている気がしませんか。その根本的な理由は、可視化された戦略がないか、もしくは戦略があっても現場に伝わっておらず、組織的に実行できていないかのいずれかであるケースが多いと感じます。
どういうことかというと、例えばこんなケースです。
経営陣から「DX施策として看板商品の顧客ロイヤリティ(サービスに対する信頼や愛着)を最大化する」と指示があり、IT領域についてはCRM(顧客管理システム)とWebサイトのリプレイスプロジェクトが発足した。Webサイトリプレイスプロジェクトにおいては顧客側IT部門担当者とITベンダーを中心にチームが結成され、マーケティング担当や営業担当や意思決定者である経営陣がプロジェクトにアドバイザーとして(工数0.1未満レベル)参画する。
その結果、最も重要なカスタマージャーニー設計や業務プロセス設計が荒くなり、合わせて機能要件も曖昧なままプロジェクトが進行する。そのしわ寄せはエンジニア中心のチームへ降りかかり、Webサイトについては「NPS(ネットプロモータースコア)をいい感じに測れるようにして」との指示をもとに、エンジニアが専門外のマーケティング領域のNPSについて調査し、本やWebで調べた他社事例を参考にしながら業務設計に手を出してWeb機能を作っていく。
その結果、ユーザーテスト時に「このありきたりの機能ではDXとは言えないですね」と指摘されてしまった。
…書いているだけで、なんだか拳を握りしめてしまいますね(笑)。
ジェネラリストよりスペシャリストの誤解
さて、先のケースではスペシャリストよりもジェネラリストの活躍が重要です。スペシャリストも重要ですが、長所が活かされず猫に小判という状態ですね。
では「ジェネラリストを目指した方が良いのか」というと、性格や価値観で目指すべきものは変わると筆者は考えます。これは少し深堀りする必要がありそうです。そこで、ビジネスで求められる「人財の型」を紹介します。
人財の型は大きく分けて6つあります。「I(アイ)」型、「一(イチ)」型、「T(ティー)」型、「Π(パイ、ダブルメジャー)」型、「△(トリプルメジャー)」型、「H(エイチ)型」です(図1)。
あなたはどの型に一番近いでしょうか。一般的にはI型が一番多いと考えられています。2000年初頭頃からは各所で「T型が必要だ」言われるようになってきました。幅広い知見を基盤とした高い専門性が必要という考えです。
もちろん、今の世の中は多様性が尊重され、流行や需要がハイスピードで変化していくため、どの型が正解など、優劣をつける必要はありません。DXプロジェクトで花形として活躍できる可能性が高いエンジニアの型という意味では、筆者はH型人財だと考えます。実際に、DX推進中の各企業で「H型人財が不足してプロジェクトがうまく進まない」といった声をよく耳にします。
先のWebサイトリプレイスプロジェクトのケースに当てはめると、契約締結前のタイミングでマーケティング担当者、顧客側IT部門担当者、ITベンダーのPM、管掌役員といった各メンバーを繋ぐことができるH型人財がいれば、展開は変わっていたのではないでしょうか。
まだ明確にキャリア設計ができていないエンジニアは、この型から「自身の目指す姿」を考えてみるのも面白いかもしれません。
以降では、DXを推進する際に重宝されるエンジニアの共通項を、T型とΠ型とH型で共通する5つの要素を紹介します。
DX戦略に重宝されるエンジニア5つの要素
要素① 視座が高い
視座とは「物事を見る姿勢や立場」のことで、視座が高い人とは、例えば会社員なら自社の社長や業界第一人者の姿勢や立場で物事を捉えることできる人です。
DX戦略は、ビジネスモデルやプロセスを変革する思想を基に打ち出されます。その戦略考案者は大概経営幹部層(社長、CDO、CIO等)やその補佐、外部専門家などです。そのレイヤーの視座をどれだけ具体的にイメージできるかが重要です。
筆者の経験上でも、DX戦略を戦術に落とすフェーズにおいて、視座が高い人と低い人とでは戦術の発想もスキームを組み立てる品質もまるで違うと感じました。
実際に視座の高いエンジニアが重宝されたケースがあります。エンジニアのAさんは、DX戦略の数ある施策のうち、とある外部プラットフォームを活用した事業のアーキテクトリーダーとしてアサインされました。Aさんは必要資格の取得、機能学習、システム検証、モック作成などを順調にこなしていき、ここまでは優秀なエンジニアといった進捗です。
Aさんがすごいのは、それだけに留まらず、実業務上での活用企画を積極的に行ったことです。具体的には、対象業務のアセスメントからライセンス体系の調査と部署毎のITリテラシーを考慮した社内配分を検討し、業務適用企画の推進までを主体的にリードしました。
この結果、AさんはITコンサルタントとして評価され、活躍のステージが広がったのです。このように、キャリア形成面でも視座の高さがその人の成長角度を左右すると言っても過言ではありません。明日からでも視座を上げる練習を始め、大局観を養い、成長のギアをあげることをおすすめします。
要素② 守備範囲が広い
IPAの資料では、DXに対応する人財を図2のように定義しています。
守備範囲が広いエンジニアとは、図2の各ロールを兼務できることではなく、簡単にいえばイメージだけを伝えれば大概1人でやれてしまうエンジニアのことです。
最近、自社で面白いケースがありましたので紹介します。複数あったエンジニア組織を統合し、50名規模の組織が1つできました。受託型開発でかつ先端テクノロジーを扱うチームで、営業フェーズでの検証やPOC(概念実証)も多く、社内DXにおいても横断的にプロジェクトが走っていました。そのため、PM層が従来のプロジェクトマネジメントツールではエンジニアリソースを効果的に管理できず困っていました。このままでは、営業計画や人員配置計画、採用計画にまで支障をきたしそうだとわかりました。
そこで、データサイエンスチームのリーダーを務めるある社員Bが、自分達が欲しいプロジェクト管理システムのモックを開発しました。1人なので、専門外のAWS環境構築からシステム設計/機能設計、Web開発までフルスクラッチのアジャイル開発です。
このシステムは、既存ツールでは難しかったリソース管理と営業情報を一元管理し、誰がどの案件にどれ位の稼働を割いているかという人員リソースの実績、収益状況や予算の予実をBIツールのように数クリックで可視化し、そのまま経営会議に活用できるといったものでした。管理層からすれば間違いなく欲しいツールです。
保守性やセキュリティ、拡張性などを考えると、これが必ずしも良い進め方だとは言えないかもしれませんが、モックひとつでこれまでの認識を覆したBは、まぎれもなく重宝される人財です。Bの仕事の早さと守備範囲の広さ、センスの良さが光る一件でした。筆者個人としても、とてもリスペクトしているエンジニアの1人です。
要素③ 最新技術の活用を研究している
次々に新しい技術が実装されていく現代において、最新の技術情報はとても重要です。しかし、最新情報でも、インプットしただけでは単なる知識です。非エンジニアであればそれで良いかもしれませんが、デジタル人財は「先端技術エンジニア」と呼ばれることもあるくらい、先端技術に精通している必要があります。
これは、現在の先端技術の3年、5年、10年後にくる「活用の知見」を指します。AIでいえば、1950年のアラン・チューリング氏が提案した「チューリングテスト」が起源と言われ、それから70年経って現代のようなビジネス応用が活発になりました。
AIは第一次から第三次まで三度のブームを乗り越えて現在に至るわけですが、現在のブームを下支えしたのはクラウドとビッグデータ活用の観点だと筆者は考えます。
この仮説に立つと、第三次AIブーム初期の2012年頃にディープラーニングに着目し、そのときの本業とは関係なくAWSやその他クラウドを勉強し、GPUについて調べ、統計学からデータ活用の作法を見出した人達が、デジタル先駆者となるのだと思います。
要素④ ビジネスとIT知見のバランスを意識している
筆者がDX事業の新サービスを企画する際や、戦略を戦術に落とし込む際に常に必要とするのは、ビジネスのユースケースを発想できるエンジニアの存在です。
最近気づきを得ました。IoT領域でDXサービスを活用した製造業の工場ラインの生産性を向上するというテーマで、デジタルプロセスを設計する場合のソリューションパターンについて知見が不足していた際に、機械学習とディープラーニングのスペシャリストから「Azure IoT」とMicrosoft社のノーコード・ローコードプラットフォーム「Power Platform」を活用し、生産ラインにおける具体的な変革ソリューション案をいくつか提案されたのです。
どこの会社でもありそうな、重要な方針を決定する会議のメンバーがビジネスやITのどちらかに偏っており、活用可能な知見やリスクをバランス良く検討できていないまま、意思決定がされていく状況です。このような状況では、エンジニアながらビジネスサイドと対等にコミュニケーションができる人はかなり重宝されます。
実際には難しく感じるかもしれませんが、以外と重要なのは発言する勇気だったりします。あなたが思うより、エンジニアの生の現場体験は重要な意思決定に影響を与えることができます。
要素⑤ 経営とITの架け橋になれる
筆者は、経営とITの架け橋になれる人財がいるかいないかでDXの成否は左右されると言っても過言ではないと思っています。
IPAの「デジタル・トランスフォーメーション推進人材の機能と役割のあり方に関する調査」でも、IT業務がわかる役員比率が高いほど、DXへの取り組みの成果が出ている企業の割合が高いというデータがあります。
では、経営陣がITを勉強すれば良いかというとそう単純でもなく、エンジニアの専門性は短期間に習得できるものではありません。そうなると、優秀な助言者が必要です。それはどのような人物像か、ひと言でいえば「参謀」です。DXの実現にはIT領域の参謀が必要なのです。
ベストプラクティスはありませんが、筆者のケースを少しお話しします。筆者はこれまで、営業、エンジニア、プロジェクトマネージャー、ITコンサルタント、ビジネスコンサルタントとキャリアを歩んできました。振り返ると「営業」「経営」「エンジニア」「コンサルタント」という4職種を経験したことが強みになっていると感じています。
その中から、エンジニアが比較的取組みやすいおすすめが2つあります。1つ目は「ITコーディネータ」という資格です。この資格はケース研修が6日間ありますが、良い講師を選べば視座をぐっと上げる方法として効果的です。
実際にエンジニアからコンサルへ転身した部下3名にITコーディネータを取得してもらったところ、全員が口を揃えて「物の見方が変わった」と言います。野村総合研究所でも「人事担当者が評価する資格・検定」として推奨しているようで、念のために言っておきますが、ITコーディネータ協会の回し者ではありません(笑)。
2つ目は、社内外問わず経営層と「ビジネスに関する会話」を沢山することです。これを積み重ねると、今まで現場で感じていた疑問点が点と点で繋がっていくことも多くあります。この点と点の繋がりを上司から話で聞くだけでは経験にはなりません。
* * *
今回は、ビジネスで求められる「人財の型」と、DXを推進する際に重宝されるエンジニアの共通項を、人財の型のうち、T型とΠ型とH型で共通する5つの要素を紹介しました。
「DX戦略に重宝されるエンジニア」とひと言でいっても、プロジェクトによってペルソナが異なりますし、正解はありません。
しかし、本質を捉え、共通項を押さえておくことに決して損はありません。本記事が、エンジニアの皆さまの成長に少しでも寄与できれば幸いです。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- IoTエンジニア、スペシャリストではなく「優秀なジェネラリスト」が人気と判明
- NoSQL/KVSあれこれ:Red Hat JBoss Data Gridとは
- エンジニアのビジネススキルは、いわば「オプション」自分の「やってみたい」と思うところを自由に選ぼう
- エンピリカルアプローチの実例
- ビジネス・プロセス実行
- マイクロサービスとサービス・メッシュ(Istioが求められる背景)
- 三井住友銀行にデザイナー職がいる理由。HCDプロセスを活かしたものづくり
- 【完全保存版!】システムエンジニア(SE)の仕事とは
- 日本と諸外国の懸け橋に。音声認識の分野で挑戦を続けるiProspectのグローバルディレクターNate氏が語る、人生のこれまでとこれから
- 情報処理安全確保支援士制度と試験概要