最近はモニタも大きくて快適なので、Macでも本を読んでいます。
先日、Kindle unlimitedの対象となっていた「IT負債 基幹系システム「2025年の崖」を飛び越えろ」を読みました。「2025年の崖」は経産省のDXレポートでも書かれていることですが、より深く理解できますし、そのためにどうしておくべきかというのを改めて考えさせられました。
- そもそも「2025年の崖」って？
- クラウドへのリフト&シフトも必要だがSoR、SoEに移行が必要
- あなたがシステムエンジニア、コンサルタントであるならば
- あなたがユーザー企業のシステム部門であるならば
- 私の本書を読んだ感想
- Kindle unlimitedならば読み放題に含まれます
そもそも「2025年の崖」って？
IT業界の方々や仕事でシステム導入などをしている方々は知らないとまずいですね。
そもそも自社に影響のあることなのかどうかを知っておくべきです。
経産省のレポートを読んでみよう
少なくとも概要はサマリーだけでも見ればわかります。
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）
いわゆるレガシーシステムの問題（ブラックボックス化）とランザビジネス（維持・運営）により、DXを推進するための要員がおらず、国際競争への遅れや国内経済の停滞を指す言葉が「2025年の崖」です。
クラウドへのリフト&シフトも必要だがSoR、SoEに移行が必要
SoE（System of Engatement） 繋がりのシステム
SoR（System of Records） 記録のシステム（従来の社内システム）
大半の社内システムはSoRです。正確にデータを記録するためのシステムです。
それに対してSoEとは、体験を提供するシステムということになります。
SoEではデータ（記録）を扱わないわけではありません。
ただ、先の略語の通り、システムを作る上で、データ（記録）を中心に考えるか、体験を中心に考えるかが大きく異なります。
そして、エクスペリエンスを提供する部分も含めて、現在の社内システムはモノリス（一枚岩）となっており、他システムとの連携は困難を極め、連携をしたとしてもランザビジネスのコストは跳ね上がるという悪循環に陥ります。
当然、ランザビジネスに関わる人員も増え、新たなことを推進する人がいなくなるという状態に陥るわけです。
そうならなために、SoR、SoEという考え方にSoI（System of Insight/Inteligence）という考え方も加えて、グランドデザインを改めて考えていく必要があるのです。
ちなみにSoEというと、いわゆるマイクロサービス化を浮かべると思います。これは正しいです。マイクロサービスを組み合わせてシステムを作るという流れの移行が必要なのです。これにより１つ１つのシステムはマイクロサービスという形で小さくなり、メンテナンス性は向上すると思います。もちろん弊害もあると思います。
そういった点を、AmazonやMicrosoftなどの事例や米国の事例を踏まえながら解説してくれています。作者は野村総合研究所にお勤めだった方ですので、日本の事情もよくわかってらっしゃいます。「うん、うん！」とうなづきながら読める本になっています。
そして、それを踏まえて今後どうしていくべきかをあなた自身で考えてみるのに良いと思います。
あなたがシステムエンジニア、コンサルタントであるならば
この本に書かれている「2025年の崖」に関することを踏まえて、今から仕事をしていくべきです。未来を想定した仕事の仕方を嫌う人はいません。
それを理由にお客さんへ提案もできれば、真実味や今後も一緒に仕事をしていきたいという思いは伝わると思います。そういう意味ではSIerの営業さんにも知っておいてもらいたいですね。こういったことを踏まえた議論を社内でした上で、お客さんに提案が持っていければ、好感度も信頼度も上がると思います。
あなたがユーザー企業のシステム部門であるならば
こういう視点を頭に入れておき、今後のグランドデザインを社内で提言していくべきです。そして、ベンダの提案にも目を光らせてください。
そうすることで、今から４年ぐらいしかありませんが、あなたの会社を帰ることができると思います。中小企業にどこまで影響あるかわかりませんが、中小企業こそ、システムをうまく使って大化けすることがあると思いますので、あなたの会社にあった戦略を考えてみると良いと思います。
大手企業であれば、おそらく既に「2025年の崖」に向けた対策をとられているのではないかと思います。そこに本書による正しい理解と、あなたなりのエッセンスを加えて、より良い価値を提供できるようになれば、あなたの立場も大きく変わるのではないでしょうか？
私の本書を読んだ感想
マイクロサービス化するには外部に丸投げは非効率で、自社開発にシフトすべき
マイクロサービス化をすることは、外部のSIerに丸投げしていてはうまくいきません。
各社は自社の領域だけしっかり守るだけ守りますが、全体を見てくれる人はいません。そうなるとそれをあなたがやることになります。しかし、システムと違ってあなたは年中無休では働けないでしょう。ワークライフバランスを考えると複数人で賄う必要があります。そして、障害が発生した時、A、B、C、Dのマイクロサービスが繋がっていて、あなたがAのマイクロサービスが原因ということに気がつけば、A社の運用要員だけが対応すればいいですが、わからない場合にはきっとB、C、Dの運用要員にもデータの確認やシステムの確認を依頼することになると思います。
原因がA社のマイクロサービスだったとしても、都度B〜Dの会社も対応せざるを得なくなり、ランザビジネスの費用は上がっていきます。
これでは本末転倒です。結局あなたの会社はランザビジネスに割く要員が増え、DX推進は先の話になってしまいます。
そうならないようにするためにも、足元に開発要員を抱えた方が都合が良いと思います。
テスト部隊も専属で儲けるべき理由
他の理由として、セキュリティ対策は常に求められますし、Windowsのバージョンアップなども頻繁に対応せざるを得ない状況になっていると思います。
そうした際に、素早くテストを、、、それを年に数回も行う必要が出てくるはずです。SoEを意識したら、マイクロサービスのアップデートも頻繁になってくるはずなので、確実にテストの機会は増えます。
それをAのアップデートのたびにB、C、Dもテストを依頼していては、やはりコストの面でも無駄が出てしまいますし、何より開発者がテストをするのは非効率です。開発者はテストの能力に長けているわけではないですから。
上記を踏まえて開発者は開発に専念してもらい、テストはテスト専門の人に任せる形の方が効率が良いと思います。もちろんテスト専門の人は開発者より安価なコストで雇えるのではないかと思います。そういうテスト部隊を自社内に設けて、自動化を推進していくことで効率を上げることができると思います。
SoEは自社開発が向いている
（開発＋テスト＋運用）ｘマイクロサービスの数（ベンダの数）
となってしまうのは非効率なので、
（開発＋テスト＋運用）ｘ１（自社）
という形が望ましいと思っています。
ベンダが変わることと違って、自社開発であればルールの策定もしやすいと思いますし、新技術の共有や人員配置の面でもやりやすさが出てきます。（先のB社の人をA社に派遣などは流石に難しいですね）
逆にルールを策定しても、SIerに依頼するたびにルールを周知し、しかもルールを守っていることの確認も都度しなければなりません。これは費用的にもデメリットになってくるはずです。
さらに、SoEでスピードを求められればなおのこと、注力すべき要員の配置や配置換え、方向転換などもしやすくなるはずです。
また、テストや運用のしやすさなどを考慮して、専属の要員が要件定義段階から参加することで、テスト、運用作業の効率化も計れるはずです。
人員を増やすと間接費は増えますが、融通が聞いてスピードアップや方向転換のしやすさを踏まえると、この形が理想的であると私は考えました。
人によって色々考えはあると思いますが、こういうことを考えられる良い本だと思いますのでオススメです。
Kindle unlimitedならば読み放題に含まれます
この本はKindle unlimitedの読み放題に含まれます。
年末年始の休み期間中に、プログラミングやコアテクノロジーだけでなく、こういった本で知見を広げてみるのも良いと思います。
月額980円で、いつでもやめられます。
今なら３０日間の無料体験がついてきますので、年末年始休みの間に無料体験で本を読みまくって、会社が始まったら解約するというのもありですね。
