これまでの開発資産を未来に向けてどう継承するか

1. 困っていませんか

新たな開発案件が来るたびにソースファイルだけをいじってビルドしてリリース。昔作った設計書は陳腐化。開発メンバー部署異動も何度かあったが、引継ぎ資料もなく、全体がわかる人不明。どこから手を付ければよいかわからない状況。こういう開発の現場は多いのではないでしょうか？

2. IT業界の技術継承の仕組みが足りない

伊勢神宮のように20年に1回必ず作り直すことが決まっていて、予算・人材確保・技術伝承の仕組みがあればよいが、ITの世界はこれです、といったルールはない。ハードウェアの保守切れにあわせて5～10年に1回作り直すかどうか、というのが一般的。

ITの場合は技術革新が激しく10年でざっと主要言語技術が変化する。モダナイゼーションの種類を言語視点で分類すると、以下のようになると思う。

区分	主要言語技術	年代
(1) MF・オフコンのレガシー系資産	アセンブラ/COBOL/FORTRAN等	1980～
(2) オープン系の資産	VB/C/Java/Perl/COBOL/COBOL等	1990～
(3) Web系の資産	VB.NET/Java/Python/Ruby/HTML/C#等	2000～
(4) クラウド系・モバイル系の資産	Java/Python/HTML5/GO/kotlin/Swift等	2010～

量子化コンピューティングの時代がこの先くると思うが、日常に入ってくるのはしばらくあとになると思われる。

参考:

• 以前のJUASの2008年の企業IT動向調査報告によると、基幹システムの平均寿命は13.6年
• 一方、JUAS 企業IT動向調査報告書　2022 P43 にはシステム開発の工期・予算・品質遵守が全て悪化傾向である、とのコメントあり

3. 何を未来に継承すべきか

ここでは、塩漬け対象物件ではなく、いままさに顧客の要望をもとに進化成長中である (4) クラウド系・モバイル系の開発資産をどう継承するか、検討していくことにする。

継承項目	ある・なし	将来ないと困るもの
企画書/ビジネスプラン	ある	あればよし
開発ガイドライン	なし	〇
要件定義書/外部仕様書類	ほぼなし	〇
内部仕様書類	ほぼなし	〇
開発ソースファイル	ある	〇
データ言語(DML/DDL)	ある	〇
動作するもの(ロードモジュール)	ある	〇
オンプレVM環境(旧AP)	ほぼなし	保守サイクル次第
ビルド手順・リリース手順	ほぼなし	〇
初期セットアップ情報	ほぼなし	〇
テスト仕様書/テストツール	ほぼなし	〇
テストデータ	ほぼなし	あればよし
テストエビデンス	ほぼなし	あればよし

4. 継承のステップ

4.1. アーキテクチャをどうかえるか

1. 要員の調達がし易いか いまは python かJava
2. ミッションクリティカルな言語か　java?
3. 基盤サービスの選定 AWS ? GCP?
4. デプロイ・運用方法は？ gitlab?+ ansible
5. テストはどうする？AIテスト自動化？Autify？Magic Pod？mabl?

方式	BEFORE	AFTER
クラウドリソース	AWS EC2	AWS EC2
AWS EC2基盤	apache, tomcat	nginx, tomcat
通信インターフェース	HTTPS	HTTP/3
ブロントAP	swift	swift
バックエンドAPI	自前	openAPI
バッチ	Shell	Shell + AWS Batch

4.2. ないものをどう作るか

drwawio, PlantUML,MermaidJSで可視化。
要件定義、ユースケース、画面遷移、シーケンス図、ER図、メッセージ一覧

• ドキュメントからリバース
• ソースからリバース
• 動作ログからリバース

4.3. アプリケーション変換

• Java2python
• バッチ
• flutter
• swift

4.4. 基盤サービスへの組み込み

• DBデータデータ投入
• Apache/Tomcat組み込み

4.5. テスト

• モダナイゼーションテスト
• リグレッションテスト

4.6. 正常性確認

• 動作確認(goss)

4.7. リリース

• 品質判定
• 公開リリース

5. まとめ

この文章を書くきっかけ。設計書がない開発案件は、これまで色々見てきましたが本当にない。どこまで仕様書を整備し、品質・性能担保していくか、落としどころを決めるところが一番の肝だろう。どこまで実行するかの線引きが一番難しい。