💪

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

2022/05/28に公開約2,900字

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~

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

参考:

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. まとめ

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

Discussion

ログインするとコメントできます