この記事は株式会社クロノスの「~2020年春~勝手にやりますアドベントカレンダー」の最終日の記事です。
（本日で完走です！！！！）
はじめに
もう2020年になってしまいましたが、2018年に経済産業省が発表したDXレポートという資料をご存知でしょうか？
今更ですがこのレポートを読んでこれからのITエンジニアはこうした方が良いのではないかと私が感じたこと（あるいはDXレポートがエンジニアにこれを期待しているのでは？と私が感じたこと）をまとめてみます。
なのでたいそうなタイトルをつけてますが、主観がたっぷり含まれる内容になると思います。ご了承ください。異論は認めます。
あるいはごくごく当たり前のことを言っているかもしれません。
前半ではDXとは何かについておさらいし、後半で私見を述べます。
前半に関しては経産省の資料の内容が多いので引用中心になります。
TL;DR
- DXと2025年の崖について知ろう
- 新しい技術を知ろう
- それまであった技術も一応知っておこう
- 先を見据えた行動をしよう
私自身のこと
- もうすぐ5年目になるエンジニア（この業界には未経験で入りました）
- SESで色々な現場に行ったり、請負案件をしたり、新入社員研修で講師をしたりしている
- 要件定義フェーズから運用・保守フェーズまで一通り参画した経験がある
- 仕事はJavaを中心とした業務系Webアプリ開発がメイン
- プライベートだとGoとかPythonとかReactとかVueとかが好き。あとコンテナ。
- 他にも新しい技術なら基本なんでもやってみたい人
そんな感じのエンジニアです。
某記事で言うところの典型的な理想論者だと思いますが
経験的にはSIが長く、技術面では安定的に同じことばかりやってきた期間が長いので
現状にもがくようにして色々勉強中といった身です。
DXとは
デジタルトランスフォーメーション（Digital Transformation）の略。
たまにDeveloper Experience（開発者体験）の略で出てくることもあります。
本稿では主に前者について言及します。
要はデジタル技術を使って生活を豊かにすることです。
身近なところだとスマートフォンやIoTの登場で生活が便利になったり、AIの登場で仕事が楽になったりしましたよね。
2018年に経済産業省がDXレポートというものを発表しており、その中でDXの重要性を説いています。
この資料の中では企業の基幹システムやそれらが抱える技術的負債についても触れています。(参考：「技術的負債とはどういうものなのか？」をテトリスに例えるとこうなる)
以下のページから確認することができます。
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～(経済産業省)
(サマリー版はたった5ページですぐに読めるので、目を通しておくことをオススメします。)
経産省はDXレポートの中でのDXの定義を以下としています。
企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内部エコシステム（組織、文化、従業員）の変革を牽引しながら、第３のプラットフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術）を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリ
アルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上の優位性を確立すること
「DXレポート（簡易版）p4」から引用
ざっくりと要約すると「新しい技術をいい感じに使った新しいビジネスで市場競争を勝ち抜いてね」といった感じでしょうか。
2025年の崖
なぜこんなにもDXが騒がれているのかというと、一つはこの2025年の崖という問題があるからです。
・既存システムが、事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化
・ 経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められる中（＝経営改革そのもの）、
現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている
「DXレポート（サマリー）p2」から引用
DXを実現したくても、既存システムの老朽化や現場からの反対で実現が難しくなっている企業が多いのが現状のようです。
ですが、この問題を克服できない場合、DXの実現ができないだけでなく、2025年以降、毎年最大で12兆円の経済損失が生じる可能性があるとDXレポートには書かれています。
これが2025年の崖と呼ばれるものです。
デカすぎてイメージ湧きにくい額ですが、東京オリンピックが3〜4回開催できるくらいの額らしいです。
放置したときの影響がなんとなく大きく、私達の生活に多少なりとも関わりが出てくる数値だということがわかっていただけるのではないでしょうか？
各シナリオ引用
データの活用ができないことにより組織が本来選択すべき方針決定を誤る可能性がありますし、技術的負債に関しては保守運用でのコストが増大します。
様々な場面でリスクが高まります。
放置シナリオ
ユーザ：
爆発的に増加するデータを活用しきれず、デジタル競争の敗者に
ベンダー：
DXシナリオ
ユーザ：
技術的負債を解消し、人材・資金を維持・保守業務から新たなデジタル技術の活用にシフト
ベンダー：
エンジニアとして
組織にはさまざまな役割の人がいます。
経営者もいれば人事や経理を担当する管理部門があったり、営業部門があったりするかもしれません。
他にも例えば飲食業界なら現場で接客したり、料理を作る人もいると思います。
そのような中、私達エンジニアはこれからどうあるべきでしょうか。
新技術を学ぶ
基本的には私が言いたいことはこれに尽きます。
また、私自身AI・データ分析に関しては知識が少ないため、あまり触れません。
DXレポートで名前が上がっている技術・手法等
DXレポートの中で登場する技術や手法としては
- クラウド（ここは使って当然みたいな感じがする）
- AI・データ分析
- アジャイル開発
- マイクロサービス
が挙げられます。
もちろんこれらはあくまで一例ですが、目安としてこの中で１つ、あるいはクラウドを含めた場合は２つくらいは得意な分野を持っておくことが今後もエンジニアとして生き残るのには良い選択になるのではないかなと思います。
AIであればJDLAの資格を取得したり、クラウドであればAWS認定を取得したりするところから始めるのも良いかもしれません。（最近は特にこれらの資格に関する情報は多いです）
マイクロサービスやアジャイルに関しては私も関心がある分野で、最近以下の書籍を読みました。
非常に勉強になったのでリンクを貼っておきます。
マイクロサービスパターン［実践的システムデザインのためのコード解説］
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
もちろん全ての事例でこれらの技術が採用できるわけではありません。
セキュリティ等の問題でオンプレでしか動かせないシステムもまだあるでしょうし、規模の小さなシステムであればマイクロサービスではなくモノリスで作ったほうが良い場合も多いでしょう。
私達がやっておくべきことは、思考停止でこれらの技術を採用することではなく、引き出しをたくさん用意しておくことです。（アーキテクトなど技術選定の立場にある人は特に）
技術書を開くと、「銀の弾丸はない」という言葉がしばしば出てきますが、全くそのとおりです。
システムというものはその変化の速さや多様さ故、とりあえず動くものはまだしも、最初から設計も実装も完璧なきれいなものを作るのは不可能に近いです。
仮に上手く設計できたとしても、後任者に設計思想が理解されず、崩壊するなんてこともあります。
これらの問題に対処するにはその都度最適なものを選択して対応していくしかありません。
技術的負債を少なくする仕組みを知る
技術的負債を少なくできるかもしれない手法
- リファクタリング
- 自動テスト
- CI/CD
最初から完璧な作りのシステムを提供するのは難しいです。
後から何かしらの変更をすることがほぼ必須になります。
ですが、既にシステムが稼働している場合、
既に動いている機能に関しては変更の影響を受けないようにリファクタリングしなければなりません。
特に規模が大きくなればなるほど影響範囲を把握するのに苦労しますし、場合によっては漏れが発生します。
これらを解決するための方法の一つとして自動テストがあります。
もちろんこの手法も万能ではないですが、手動でテストや影響範囲を調べるのと違って
再現性があること（すぐに何度も実行できる）、観点や実行方法をコードとして残せるところが優れています。
また、そういった形に残せるところが引き継ぎにも役に立ち、属人化やブラックボックス化にも対処しやすくなると考えられます。
少なくともスクショを貼っただけのエビデンスや、実際に行ったか後からわからないテスト仕様書よりは実用的で役立つ部分が多いと思います。（テスト観点を洗い出すために仕様書を用意するのはあっても良いと思います。手動・自動問わずテストケースを考える力は必要です）
また、自動テストに付随してCI/CDを導入して漏れの発見を早めたり、漏れがないことが確認できたときに直ぐにデプロイできる仕組みを作るのも同様に重要です。
これまであったものも一応学ぶ
- オンプレミス
- ウォーターフォールモデル
- モノリシックアプリケーション
これは特に初学者や経験の浅い人に向けた内容です。
最初から先に述べたマイクロサービスやアジャイルなどをやろうとすると難しいかもしれません。
例えばアジャイルであればウォーターフォールのような工程を経ていた方が理解が早いですし、下手をすれば同じことをずっと続ける「なんちゃってアジャイル」のような形になります。マイクロサービスもモノリシックアプリケーションの課題を解決しようとして出てきた手法です。
なので、いきなり最先端を行こうとするのではなく、情報や事例が多かったり、基礎となるものから順番にやっていくのが良いと思います。
ここで勘違いされたくないのは、基礎だけやれば良いということではなく、それらを押さえてからも学び続けることが大切だということです。
長期的な目線で考える
システム開発には当然ながら開発（システムができるまで）と運用（システムができてから）のフェーズがあります。
さて、では開発にかかる期間と運用にかける期間ではどちらが長くなるでしょうか？
また、コストはどちらが大きくなるでしょうか？
正解はありません。ケースバイケースです。
しかし、少なくとも開発時点では発注元は長期間運用したいと考えているはずです。
数年で使い捨てるシステムに何千万も何億もかけようと考える組織はないと思います。
だとすると
開発コスト < 運用コスト
ではなく
開発コスト > 運用コスト
となるシステムが望まれやすいはずです。
（どちらも低コストで済ませられるならそれに越したことはないですが）
そのような前提に立つと、例えば先に上げた自動テストであれば
コードの量が増えるので開発時のコストは上がるでしょうが、運用時にメリットが得られやすいのがイメージできるでしょう。（もちろん手動でこなせるほど単純で見落としも発生し得ないシステム等であればこの限りではありません）
近年はDevOpsなど、開発時も運用を見越したシステムにしようとする風潮が主流な気がしています。
おそらく先に上げた技術もこういった観点から生まれてきたものだと考えられます。
少し違う話
がらっと話は変わりますが、こういった考え方は他の場面でも役に立ちます。
一例としてエンジニアの技術スタックの話をしてみます。
例えばJavaScriptであれば、最近ではVue.jsやReact.jsなどの採用例が増えてきており、フロントエンドのスタンダードに近い状態になりつつあります。（実際はそうでもないという意見もあるかもしれませんが、そうであると仮定します）
でも自分はjQueryで作るのが慣れていて実装にかかる工数も少ないし、他のメンバーもjQueryを触れる人しかいない、といった場合を考えてみます。
こういった場合どうするでしょうか？
これもまた難しい問題です。
おそらく余程前向きなメンバーが集まらない限りはjQueryが採用されるのではないでしょうか。
当人の目的がそのプロジェクトを無難に終えることや、その次の査定で評価されることだけであればそれで何の問題もないでしょう。
ただ、目的がスキルアップやキャリアアップであればどうでしょうか。
目標は達成できそうにありませんので、プライベートや空き時間で頑張ったり、別の機会を待つしかありません。
前者は短期的な目標であり、後者は（比較的）長期的な目標になります。
どちらが良いとかではなく、両方考えるのが重要です。
短期的な目標のみの場合は行き当たりばったりで先を見据えられない人が多く、
長期的な目標のみの場合は理想ばかりで具体的な行動ができない人が多い気がします。
短期的な目標が長期的な目標に繋がる状態が最も良い状態です。
両方が結びつかないのであれば目標設定や環境を変えたほうが良いでしょう。
先の技術スタックの例であれば、先にどんなエンジニアになりたいのか、どんなエンジニアでいたいのかから考えて、そこから重視することを細分化していくのが良いというのが私の考えです。
最後に
当然ですが、先に述べたような知識を身に着けずエンジニアやっていくことも可能だと思います。
システムを塩漬けし続ける組織（負債を改修しない）、レガシーな技術を採用し続ける組織。
そういった環境が快適だったり、特に不都合なく過ごしていけるのであればそれで良いと思います。
ただ、今後少しでもエンジニアとしての寿命や市場価値を伸ばしたかったり、技術面や待遇面等で良い環境でエンジニアがしたいのであれば、これらの技術や手法にアンテナを張ってみてはどうでしょうか。
また、技術的負債や技術について、ユーザー企業の理解が得られないといったこともよく聞く話です。
難しい話ではありますし、私には解決方法はわかりません。
しかしそれ以前に、まずは私達エンジニアやベンダー側が、ITのスペシャリストとして、これらについて向き合ってみるべきなのではないでしょうか。
参考
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
https://www.sbbit.jp/article/cont1/36929