1月に公開されたIPA/SECさんの「システム再構築を成功に導くユーザーガイド」と、最近読んだ「レガシーソフトウェア改善ガイド」を踏まえて情報システムの再構築戦略について再整理してみる記事。再構築における、リファクタリング／リアーキテクティング／リライト／リホスト／リビルド／リプレースなどの各戦略について考えてみたことなど。
- システム開発における上流工程の課題を解決するユーザガイドを公開
- コードがレガシーになる原因のほとんどは、人間に関係している～『レガシーソフトウェア改善ガイド』より (1/2)：CodeZine（コードジン）
- 作者: クリス・バーチャル
- 出版社/メーカー: 翔泳社
- 発売日: 2016/11/14
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
再構築戦略の再整理
実際にはこれ以外にも手法があるのかもしれないけれど、「システム再構築を成功に導くユーザーガイド」と「レガシーソフトウェア改善ガイド」を元に頭の整理をしてみると、再構築戦略というのはだいたい以下に分類できるような気がする。資料や書籍、記事によって言葉の定義が異なるので以下オレオレ定義に則って記載。
- 現行システムを活かすパターン
- 現行システムを廃止して新たなシステムを構築するパターン
- ⑤現状のソフトウェア設計(もしくはコード)を前提として、新たなプログラミング言語で書き直す(ポーティング型のリライト)
- ⑥現状の要求仕様を前提として、設計から見直しを行いシステムを書き直す(リビルド又はビッグリライト)
- ⑦出来合いのパッケージなどに置き換えを行う(リプレース)
この整理で各戦略について考えてみたい。
①HW更改
主な情報ソースは「システム再構築を成功に導くユーザーガイド」。
- 原則としてハードウェアの変更のみを実施する。派生的にOSおよびミドルウェアのバージョンアップがされる場合がある
- 原則としてアプリケーションの修正を行わないが、OSやミドルウェアの変更にともなって修正が発生する場合がある
- 品質保証はアプリケーションの修正箇所を除き、疎通確認や新HWでの動作確認のためのサイクルテストなどを中心に実施
いわゆる最もお手軽な再構築の類。一方で過去に見聞きしてきた経験から次のような落とし穴はあるような気がする(実はあまり経験が無い)
- 開発資産と本番環境が適切に管理されていないため、本番にしか存在しないコードや設定がある
- 新規ハードウェア上に想定手順通りに環境を構築しても動かない等
- OSやミドルウェアのバージョンアップの影響調査にヌケモレがあり追加的な修正が発生する
- バージョンアップ後のOSやミドルウェアに潜在的なバグが存在することが発覚し、回避のための修正が発生する
- 例えばこんな事件も昨今あったわけで・・・(リリース直前にHWを最新のものに変更してトラブルになったと記憶)
- ニュース - ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン：ITpro
というわけで、追加的に発生する問題対応の期間バッファとリソースバッファをしっかりと確保するのが重要という認識
②リホスト
主な情報ソースは同じく 「システム再構築を成功に導くユーザーガイド」。
- ハードウェアの変更を行うが、技術基盤の活用によりアプリケーションの変更を極力回避する。
- 「アプリケーションの変換の確からしさ」「アーキテクチャ変更に伴う非互換の対応」「OSやミドルウェアの機能差異を補完する追加の作りこみ」という観点で、現新比較テスト（正しく変換されたか）とサイクルテストなどを中心に品質保証を行う。
一時期はこの手法が「レガシーマイグレーション」という呼び名でもてはやされた時期もあったような気がする。成功すれば費用対効果の高い更改になる再構築の手法ではある。特にホストからオープンシステムに移行する際にはよく検討される印象。一方で、「システム再構築を成功に導くユーザーガイド」でも記載されている通りHW/SWの老朽化対策としては有効だが、維持コストの削減効果はほとんど無い(保守性が改善されるというような効果は無い)というのが最大のデメリットだろう。
また、そもそも論で「アプリケーションがどの程度の歩留まりで変換移行できるか」がキモであり、歩留まりが想定より低かった場合大炎上もしくはプロジェクト失敗となるので、変換移行のフィージビリティを事前に十分に確認するというのがポイントだと考えている。「こうすればできるはずだ」ではダメで「ほとんど完璧に移行できるが、念の為テストをしなければいけない」くらいのレベルでないと戦えないと考えている。
③リファクタリング
他の再構築手法と並べて比較するのがちょっと違うかもしれないが、情報ソースは「レガシーソフトウェア改善ガイド」。もちろんリファクタリングについて論じている書籍は有名どころをはじめとしていろいろあるが割愛。
親身に忠告するのだが、リファクタリングは常に、組織の目標を念頭に置いて行う必要がある。言い換えると、誰があなたに給料を払っているのかを忘れてはいけない。リファクタリングは、それがビジネスに長期的な価値をもたらすと、あなたが証明できるときにだけ行うべきだ。
レガシーソフトウェア改善ガイド 第3章 リファクタリングの準備、より
ちょっと観点は違うけど、以前に本ブログでリファクタリングの目的について取り上げた事もある。目的が明確で、利害関係者から承認されていないリファクタリング＝芸術品作り、にならないように注意する必要もあるだろう。
たとえリファクタリングの直接的な結果として、何も新しい機能が生じないとしても、ビジネスにとって何の価値も生みださないということにはならない。しかし期待されるビジネスの価値を、プロジェクトが始まる前に、できるだけ明白に、かつ具体的に示すことが重要だ。たとえば、あなたが示す価値の提案は、次のようなものになるかも知れない。
このリファクタリングプロジェクトの目標は、
- 新機能Xを、将来は実装できるようにすること
- 機能Yの性能を、20%向上させること
これは、ただ単にリソースを割り当ててもらうため上役たちを説得する材料になるだけではない。プロジェクトの範囲を定め、あなたとあなたのチームが、所定の軌道から外れないようする基準としての役割も果たすだろう。
レガシーソフトウェア改善ガイド 第3章 リファクタリングの準備、より
- 同書では上記の計画のための「調査的リファクタリング」の実施と、合意形成について触れているので参考になる。
④リアーキテクティング
こちらも情報ソースは「レガシーソフトウェア改善ガイド」。コーディングレベルではなく、ソフトウェアの構造を見直す(メソッドやクラスよりも高いレベルで行う)リファクタリングのことを指す。たとえば同書で挙げられている例は次のとおりである。
- モノリス的なアプリケーションを複数のモジュールに分割
- Webアプリケーションを複数のサービスに分散する
こちらも基本的にはビッグバン的なソフトウェアの再構築を回避するための戦略なのだけれども、一方で「リアーキテクティング＋リライト」という作戦に展開することもあるので注意が必要。
⑤ポーティング型のリライト
主な情報ソースは戻って「システム再構築を成功に導くユーザーガイド」。あと 「レガシーソフトウェア改善ガイド」では「ブラックボックス的リライト」と書かれていたりもする。
- 機械的に行うか人海戦術でやるかは別として、既存の設計ドキュメントやソースコードをインプットに割と機械的に新規言語に焼きなおす戦略。ソースコードレベルでは全て刷新となるが、ソフトウェア設計は現行のものを踏襲する点がポイント。
- 設計作業は原則として行わない為、要件定義や設計といった工程工数の発生を抑制できる。
- 実装作業のインプットとしては、既存の設計書を元にする方法と、既存のソースコードを用いる、および両方を使用する戦術が取れる。ソースコードをインプットとする場合、既存の設計書が存在しない、または適切にメンテナンスできていない場合でも再構築を実施することができる。
- 振る舞いがまったく同じソフトウェアを完成させるのがゴール。極端に言えばバグも移植されるのが正しい状態である。
- テストは通常のソフトウェア開発と同様に実施する必要があるが、特に現新比較テスト（正しくポーティングされたか）が重要である。
高難度な再構築戦略なのだけれども、既存システムの保守状況に問題があっても（理論上）実行可能という点と、リビルドに比べるとコストが低減できるかもしれないという点で、割と消去法で選択される印象がある。あと、うまくやれば人海戦術で対応できる場合がありオフショア開発などを活用して大幅なコスト削減が出来るというのもメリットだろう。
ただ、見聞きする範囲で以下のような事態が発生すると、際限なくトラブル化していく傾向があるような気がする
- 同じものを作るのではなく、同時に機能改善やレベルアップを実施しようとしてしまう
- システムや業務に対するノウハウ蓄積が不十分で、修正方法や影響範囲の検討が出来ずに炎上。
- また改修することによって現行システムと挙動比較をすることによって品質保障することが出来なくなり、何が正しいのかわからなくなってしまう罠。
- 再実装やテストの段階で根本的な現行システムの誤りを発掘してしまう
- ベンダーとしては発見した誤りを見過ごすことは出来ないが、利害関係者が「どう直せばいいのか」を策定することが出来ずに爆発。
とにもかくにも、「現状と出来るだけ同じもの」を目指すべきであり（それすら100点を取るのは難しい）それ以外のゴールを設定した瞬間、めちゃくちゃにプロジェクト難易度が増加してしまう点については注意したいところ。
⑥リビルド／ビッグリライト
「システム再構築を成功に導くユーザーガイド」におけるリビルド、「レガシーソフトウェア改善ガイド」ではビッグリライトと書かれているもの。要はイチからシステムを再構築する最もハイコストになる戦略である。加えて最も難易度は高い。成功すれば様々な現行システムの問題を解消できるハイリスクハイリターン戦略。
あなたが「大いなるリライト」（The Big Rewrite）に挑戦するなら、他の選択肢をすべて試した後のことだと思いたい。あなたはコードベースのリファクタリングを試みたが、行き止まりに達した。レガシーソフトウェアをサードパーティ製ソリューションで置き換える方法についても、実現可能かどうか調べたが、あまりにも多くのカスタマイズが必要になって、ゼロから書くより仕事の量が多いことが分かった。リライト（書き換え）から逃れる手段はないと、あなたは結論を下した。それは鳥肌が立つような状況だ。
レガシーソフトウェア改善ガイド 第6章 ビッグ・リライト、より
- 設計工程も含めて、ソフトウェアを完全に作り直す戦略のこと。一般的には、要件定義や設計作業も含めて再度実施し直すこととなる。
- リライトではないソフトウェア開発プロジェクトと異なり、最初からカバーするスコープ範囲が非常に広い点が問題となりやすい。「既存システムがカバーしていた範囲すべて」＋「既存システムで解決できていない業務上の問題点」＋「既存システムの保守・アーキテクチャ上の問題点」の解決を図ろうとするため、通常のソフトウェア開発よりも難易度は高い。およびゴール設定を慎重に行わなければ、完成させることも難しい。
- 通常のソフトウェア開発に加えて、考古学的なアプローチが必要になる。要求を発掘して、推測して、確定する能力がいるのだ
- 関連して、作り直しという観点ではJoel on Softwareの「あなたが絶対すべきでないこと PART I」が非常に良い考察になっているのでオススメしたいのだが、とりあえずはこの記事「はてなは「絶対すべきでないこと」をやらかしたのか？」を参照するのでも良いかも。はてながダイアリーの作り直しで炎上した時の議論に関するものである。「絶対にすべきではないこと＝プログラムをスクラッチから書き直すことに決める」という話である。
- もちろん、作り直さなければいけないときもある。とはいえ高難易度プロジェクトであることを認識し、通常のソフトウェア開発よりも慎重に計画を実施し、リスクを特定しながら推進する必要がある。という意味では冒頭紹介の IPA/SECさんの「システム再構築を成功に導くユーザーガイド」をしっかりとチェックして推進すべき。無料だし。
あと 「レガシーソフトウェア改善ガイド」でさらっと書かれているチームのモチベーションに関する点も重要なポイントだと思っている。要は、チームのモチベーション維持が難しいのだ。
これによってプロジェクトが停滞するだけでなく、しばらく続けていると飽き飽きしてしまうのだ。もちろん開発者は、たいがいコードを書きたくてしょうがないのだが、リライトの場合、その仕事の大部分が、レガシーソフトウェアの謎めいた振る舞いを解き明かし、それをどう扱うのが最良の策かを議論するために費やされてしまう。
レガシーソフトウェア改善ガイド 第6章 ビッグ・リライト、より
⑦リプレース
これは再構築を論点にしたドキュメントでは当然触れられていないのだけれども、きちんと考えるべき戦略のひとつ。システムを捨てて、コモディティ化したパッケージソフトウェアなどに変更してしまうというもの。
- こちらの記事などをまずは参考に。ＥＡのメリハリと実装ソリューション by 中山 嘉之
- もちろんオーダーメードなシステムに比べると様々なところがレベルダウンすることになるので、利害関係者との調整がポイント
- 「以前は出来た」「前はこうだった」の切捨てをどこまで出来るかが成否の要となる
- 一方で大いにコスト削減が実現できるチャンスでもある。再構築そのものはビジネス的な価値を生みにくいので、コスト削減を旗印に攻めていくのが定石ではある
で、どの戦略をとるべきなのか
そもそも、どのような再構築戦略を検討する方法そのものがIPA/SECさんの「システム再構築を成功に導くユーザーガイド」に細かく論じられているので、これを確認するのが一番よいだろう。結論ありきで雑に再構築戦略を選択すると死にやすいので、戦略ごとのメリットとデメリット、リスクと対策を通常の情報システム新規構築よりも慎重に整理すべきだ。とりあえず複雑骨折または炎上してから手元にやってくるのが一番悲しい……
あと再構築後は、もう再構築しなくて良いようなアーキテクチャを目指すべき（参考：リフォーマブル・プラットフォーム・アーキテクチャ｜株式会社メソドロジック、あとマイクロサービスアーキテクチャの文脈でも語られているような形とか）という話もあると思うのだが、それはまた別の機会に。