レガシーシステム ～ となりのプログラマー

ＩＴ業界で聞く『レガシーシステム』とはなにかのお話です。今回から「となりのプログラマー」にシリーズ名が変わりました。前回のＣＴＯ１年振り返りからの続編でもあります。

「経営層」という言葉を文中で使いますが、適宜「なにか決める人」くらいに置き換えていただけますと幸いです。さほどエンタープライズな話ではありません。

レガシーシステムとは

「いまだ本番稼働中であるけれども構成要素がだいぶ古いシステム」を指して言います。古いバージョンのプログラミング言語やフレームワークで構成されています。

辞書どおりの意味「遺物」で使われることはまれですが、担当者の退職を起源とするレガシーシステムはそこそこ存在します。

エンジニアはレガシーシステムが嫌いだ

エンジニアは新しいものが好きだからレガシーシステムが嫌いという見立ては短絡的でしょう。実際問題としてレガシーシステムの周辺には様々な困難と危険があるのです。

・数々の暫定対応が重ねられて来たため無用に複雑
・現在のビジネスを投影した形になっていない
・仕様は文書化されていないが、実装から仕様を理解することも難しい
・近代的ベストプラクティスは適用できない
・変更のコストを見積もることが難しい
・変更のリスクを評価することが難しい

例）ジュニアエンジニアの危険
コストを過小評価⇒自己責任論による長時間労働⇒システムを修理した人以上の評価は無し⇒退職

例）ベテランエンジニアの危険
バッファを取って工数を多めに見積もる⇒リスクを声高に叫ぶ⇒会社からうとまれる⇒リストラ

事情が複雑なので図を書いてみます。レガシーシステム由来の技術的な難しさではなく、自己解決が難しい問題について人間関係も絡みつつプレッシャーが掛かってくる、というのが問題のように見えます。

そしてこの問題が認知されるのが、レガシーシステムが壊れるタイミングではなく、開発チームが壊れるときというのが恐いところです。

それでは、新しいシステムへ移行しよう

上の図では開発チームがすでに壊れていますので、開発チームが疲弊しきる前に移行の決断をしたいものです。しかし、その必要性を経営層に理解してもらうためには越えなければならない壁があります。

簡単な図を書きます。要点は①レガシーシステムが生み出し続ける作業を知ってもらうこと②その作業が「非本来的」なものだと認識してもらうこと、になります。非本来的作業とは、その人の職能を無視していて生産性や創造性を奪う性質のもの、という意味です。

さらにもう１つの壁があります。新システムへの移行を決断しそれを完遂したとして、その効果が遅れてやってくるということを事前に共通認識としなければなりません。さもないとプロジェクトが不当な評価を受けるかもしれませんよ。

２つの壁は越えられそうでしょうか？実際問題、根回し段階からかなり困難なプロジェクトとなりそうですよね…。

実際的な戦略

必ずしも正面からぶつかる必要はありません。実際的に考えましょう。いくつかの戦略を紹介します。

①機能開発と同時進行させる
フロントエンドとバックエンドが分離できているのなら、フロントでUIの刷新をしつつバックエンドの移行を進めましょう。BFF層を作ってみるのも良いでしょう。移行期間中も目に見える成果物が生まれ続けるのが良いです。
レガシーシステムがフロント・バック・インフラまで一緒になったフルスタック型のフレームワークを使っていると痛いです、この戦略は採用できません。

②自動化テストと監視体制構築のプロジェクトに変える
新システムへの移行には前段階としてE2Eテストや監視を充実させる必要があると思います。それをプロジェクト化してしまうことで、新システムへの移行を成果物が出てくるプロジェクトに変えることができます。実際、自動化テストや監視ダッシュボードなどは見た目にとても説得力があります。

③事業仕分け戦略
そもそもこのシステム要るんですか？の問いかけからスタートして、レガシーシステムを「ただのお荷物」に降格させる戦略です。外部のSaaSを利用するなどそのシステムを代替する方法があるのではないでしょうか。
もしすこしでもこれが成功しそうなら、この戦略が第一選択になるでしょう。注意！移行後の成長戦略をあわせてデザインしておかないと開発チームがお荷物になってしまうかもしれません。

余談

誤った戦略
あなたがレガシーシステムのおかけで潰れた会社を10社以上知っているコンサルタントなら別ですが、技術的負債とか技術的流行語でステークホルダーを説得しようとするのはやめましょう。腹落ち無しのうわべの合意でプロジェクトが始まって、中途半端に終わるのが目に見えています

いきなりレガシー
古い技術をつかってシステムを作りますといきなりレガシーになります。会社の立ち上げメンバーが使い慣れていた技術を使ってアプリケーションを作った場合などです。この辺りの技術選定の話はまた別の機会に。

おわりに

最後までお読みいただきありがとうございました。

あと、ひとつ大事なことを付け足します。

あるシステムがレガシーシステムと呼ばれるようになるまで多くの開発者が関わってきたと思います。この記事は彼らの仕事を批判するものではありません。そのようなことはあってはなりません。

会社を大きくしようとか世の中を楽しくしようとか、そういう当時の開発者たちの思いやりに立ち返りながら、それを現代のコンテクストのなかで再解釈し、再び実装して前に進もうというのがレガシーシステムマイグレーションの目的です。