DX時代のエンジニアはどこからやってくるんですかね？
DXに関するご相談が更に多くなってきました。Twitterにも書いたのですが、DXは第一次産業／第二次産業向けのような印象が強いですが、実際は業務効率化・ビジネスモデル／経営意識の改革を指しているのでITベンチャーであっても創業から5年もすればDXのスパイラルに載せることが求められているんですよね。
DXを紐解いていて気付いたのは、ITベンチャーであっても5年以上経過していたら十分変革対象になり得るということです。
— 久松剛／組織改善EM (@makaibito) July 26, 2020
DXから距離を置いていたはずが、DXビジネスの話に包囲されたので整理してみた話｜久松 剛 @makaibito #note https://t.co/RSs7Kb1ETq
加えて私の経歴として20代は大学教員を目指したり、現職で営業職向け勉強会をしている兼ね合いもあって、DX時代の人材育成についてのお題を頂くことが増えてきました。
そんな近況もあり、今回は既存のエンジニアを分類しつつDX時代を迎えるに当たってのキャリアチェンジ・人材育成についてお話します。
DX前のエンジニア
私が10年ほど在籍していたWIDE Projectでは左手に研究、右手に運用と言われていました。ビジネス業界に当てはめてみるとR&D、事業開発、そして企業運用の3軸に分類されるのではと考えます。
R&DはIT業界ではやや独立した存在で設けられていることが多いように思います。開発メンバーから一部切り出すケースもありますね。
事業開発を見るとCTOやPjM/PdM、QA、SREなど存在しますが、商用のプログラムを開発・運用するという意味合いで捉えて頂ければと思います。
企業運用とは企業体を支えるエンジニアであり、情シス（コーポレートエンジニア）を指しています。
R&D、事業開発、企業運用の3者は高度な次元では独立していることが多かったのがこれまでの一般的な開発現場でした。キャリアをスタートする際に重なることは多々あれど、キャリアチェンジなども比較的レアケースでした。
DX時代のエンジニア
先のコンテンツでDXは成長スパイラルを表現した用語だとお話させて頂きました。組織体をDX向けに組み上げ直して完了ではなく、各要素を絡めながら成長サイクルを回していかなければなりません。
これを想像すると上図のようにR&D、事業開発、企業運用の3要素は近くなると考えます。どのポジション・頂点が偉いという話ではないので予めご了承下さい。
DXで立ち向かうべき大きなテーマの一つが労働人口の減少です。そのため、語弊を恐れずに言えばシステム開発やAI・ロボティクス・IoTなどを始めとしたR&Dが企業運用と近づき、実業務に関わる人員を減らさなければなりません。
もう一つの観点は非エンジニア職エンジニアの台頭です。妙に哲学的な名称になっていますが、所謂バックオフィス・総合職の方々が軽度なプログラムを書くということです。
DX時代のエンジニアのキャリアパス
続いて各セクションに存在するエンジニアについてもう少し詳しく見ていきましょう。
事業開発については3層に分けて考えています。高度専門性開発エンジニア、高度複雑性開発エンジニア、軽度複雑性開発エンジニアです。扱うもののプログラミングの難易度、要求されるコンピュータサイエンスの知識量が違うと考えています。
A)R&D
度々コンテンツでも触れてきましたが、2019年の途中まではR&D領域に企業が積極投資を行ってきました。それが後半にはなくなり、研究開発チームが解散となり、熟練度の低いデータエンジニアを中心に転職市場に流出してきたことがありました。先の内閣府との発表とも時期的に重なるところがあります。
この2019年に需要が落ちたR&Dの意味合いと、DX時代のR&Dの意味合いはそのサービス志向性という観点で大きく異なってくると考えています。以前のR&Dが漠然と「景気も良いことだしAIってのを導入すると儲かるらしい」というイメージで投資していたのに対し、多くの企業が求めているDXのゴールの最たるものは業務効率化であり、少子化時代を乗り切るために企業体を変化させることにあります。この目的に寄り添う投資はあり得ると考えています。ただ無限に椅子があるわけではないのでお気をつけを。
大学研究職への思い入れが強い一人としては、ここでも大学人の活躍を期待したいところです。他コンテンツでもお話しましたが、不景気のトリガとなる事象（リーマンショック、事業仕分け、震災、天災、ウイルス）から半年くらいしてから研究予算に響き始めます。ここの人材をいかに受け止めるかというのも一つのターニングポイントになるでしょう。
B)高度専門性開発エンジニア
プログラミングの難易度が高かったり、要求されるコンピュータサイエンスの知識量の高さが求められるエンジニアです。
Ruby on Railsのようなリッチなフレームワークの登場、忍び寄るNoCodeのように単に動く定形的なシステムであればプログラマに求められるレベル感は年々下がりつつあります。パブリッククラウドのマネージドサービスもレゴブロックのように組み合わせることで気軽に高度なことを実現できるようになりました。
しかしスケールが求められる大型のシステムや、トラフィックが大量に発生するシステム、多量のデータを扱うシステムではソースコードの効率化、プロセス管理、メモリ管理、そして障害対応などになってくるとどうしてもコンピュータサイエンスの知識が必要になってきます。残念ながらこうしたことはプログラミング学校で網羅しているところは少なく、情報系大学・大学院に行くのが良いでしょう。
C)高度複雑性開発エンジニア
要件が複雑なシステムに関わるエンジニアです。CRMなどは好例です。ユーザー部門との折衝やシステムディレクションが重要になってくるものです。マーケティング領域の知識や業務理解も強く求められるポジションです。システム改修に伴う影響範囲がB)より複雑なことも多いのが特徴です。
DXにおいて大きなキーワードの一つが業務システムの内製化です。今まではSIerに投げウォーターフォール型の開発で納品を待っていたものが、内製化しアジャイル型の開発でサイクルを回すことが求められます。このとき、社内でその活躍が渇望されるのがこのC)の人たちなのです。
D)軽度複雑性開発エンジニア
ある程度の定形化されたシステムに従事するエンジニアです。現在の業務で行くとWEB制作におけるWordPressのカスタマイズなどが挙げられます。NoCodeの流れを受けやすい可能性が高く、これらをキャッチアップしたりカスタマイズする業務が増えるでしょう。D)に従事しつつC)へのキャリアアップを狙う流れは継続するものと思われます。
E)非エンジニア職エンジニア
これを読んでおられる社会人の皆さんの会社にもExcelマクロがやたら書ける事務の方に心当たりはありませんでしょうか。弊社でもGASやPythonを書いたり、SQLをselectするくらいであれば申し分なくできる総合職の方が散見されます。
いかんせんITツールを駆使し企業運営をしていくとなると採用人数が追いつかなくなります。勢いキングダムの蕞のように、プログラムを書けそうな人は積極的に書いていく世界になっていくでしょう。
以前、ある会社さんでは社内で適正のある社員を集めてPerlエンジニアとしての教育を試みたと聞いています。これが習得対象がGASやPythonで、対象が自分たちの業務についての効率化であればより実現の角度は上がるでしょう。
これまで、社内業務効率化においてエンジニアの窓口担当が出向き、バックオフィスのリーダーと協議することで進めることが多い会社はあったのではないでしょうか。多くの場合、リーダーが把握している業務課題と、メンバーが把握している業務課題は異なるものです。これは弊社でも実施して感じていることですが、当事者であるメンバーがプログラミングを覚え、自ら解決して周囲に展開する方が課題解決はスムーズなケースが多いです。
ここで課題になってくるのは出来上がったアウトプットの統率です。多くの人がプログラムを書いてよかったね、という話には残念ながらなりません。弊社でも散見され、解決に向けて動いているのですが下記のような問題をクリアする必要があります。
・野良コードの撲滅
・車輪の再開発を避ける
・異常系処理の徹底
多くの非エンジニアがプログラムを書き始めると、把握していないプログラムが社内に存在するようになります。で、だいたい退職時に事件になります。同様にソースコードが使い回されずに無駄な工数が発生したりします。加えて正しくプログラミング教育を受けていないと、正常系は動くのだけども異常系で詰まるプログラムも量産されがちです。
ここは開発経験があるエンジニアをリーダーに据え、事業開発と同様にソースコードをGitHubに集約し、コードレビューをし、共通アカウントに載せ、管理されたサーバ上で実施されねばなりません。彼らを束ねるリーダーもまた、キングダムの蕞と同様に求められるのです。
この流れに私が期待しているのはプログラマへのキャリアパスです。残念なことに一部のプログラミング学校では、受講生の追い込みをかけるために現職の退職を推奨するところがあります。その結果、コロナ禍を越えられない方々が居られます。E)の流れが出たことにより、現職に在籍したままプログラマにキャリアチェンジする。これこそが企業も本人もwin-winな姿だと考えています。適性がなかった場合に戻ることもしやすいですしね。
F)情シス・コーポレートエンジニア
業務効率化の名のもとに導入されるツール、内製化されたプログラム、場合によってはE)の取りまとめもあり得るでしょう。
詳細は先のコンテンツに譲りますが、情シスは最早PCに詳しい人が持ち回りでなるものではありません。そして外注すると高級なものなのです。
どれが偉い？稼げる？という話ではない
例えばR&D。高度で希少な知識を身に着けても、市場性が薄れれば直ちに価値が下落するものです。2000年代前半。私はインターネットの基盤技術を研究していましたが、IT革命に後押しされて非常にバブリーな大人たちがたくさん居ました。研究会を開くとISPやホスティング事業者を中心に見渡す限りの取締役が居ました。「俺達インフラ屋は全世界のライフラインになる。だから俺達の反映は永遠なのだ」と豪語する大人たちは一人や二人ではありませんでした。しかし程なくして彼らの事業をコスト競争が遅います。これは何度でも繰り返し訴えたいことですが、インターネットの基盤たるインフラですらこの体たらくだったので、それより上位レイヤで同じことをやり続けて永遠の反映があるはずがないのです。
仮に全社員が投票することによる社内表彰という観点であれば、E)非エンジニア職エンジニアあたりが持っていく可能性だって十分あります。ジョブ型に移行をトライする流れができつつある今、報酬は事業への貢献度／希少性／市場感で決定されるでしょう。定年という概念が消えつつあり、現役期間だけが延びつつある今、各個人においては自身の柔軟なキャリアチェンジこそがDXなのではないでしょうか。
頂いたサポートは執筆・業務を支えるガジェット類に昇華されます！