こんにちは。レッドハットコンサルティングチームの木嶋です。
「アプリケーションモダナイゼーション（以下、モダナイゼーション）」について解説する連載第8回目の今回からは、6Rのうちのリファクター (refactor) に焦点を当てます。 リファクターは『既存の振る舞いを保ちながら、内部構造を改善する』行為です。これ自体はユーザーに目新しいものはなにも生み出さないので、一見ただの「作り直し」に見えてしまいます。
実はこの内部構造の改善は、最終的に開発者の時間の使われ方や組織全体のコスト構造を大きく変えます。見た目以上に「経済の話」なんです。
6Rとは
本シリーズ1回目の記事をご参照ください。
シリーズ1回目では、リファクターを以下のように説明しています。
アプリケーションのコードやアーキテクチャを抜本的に見直し、クラウドネイティブ化やマイクロサービス化といった変化に対応するものです。中長期的な開発・運用の柔軟性を重視します。
クラウドネイティブとは、クラウドコンピューティングのメリットを最大限に活用し、アプリケーションを迅速かつ高頻度で構築・デプロイ・運用するための設計およびアプローチのコンセプトです。 一般的にコンテナベースで実装されたマイクロサービスアーキテクチャという設計パターンで実装されます。
本記事では、このシリーズ定義の「リファクター」を開発者（Dev）視点で見直し、なぜ今リファクタリングが効果を持つのか、その根拠を整理していきます。
はじめに
さまざまな組織が市場での競争力を獲得するため、顧客への価値提供をより早く、より確実に実施したいと考えています。 たとえば住宅ローンなどの金融商品では、顧客がローンを必要として相談し、申し込み、銀行側で内容を確認・審査し、承認されてはじめて、顧客は必要な資金を受け取ることができます。
このように、顧客が「必要だ」と思った瞬間から価値を受け取るまでの一連の流れをValue Stream (価値の流れ) と呼びます。
当然ながら、顧客にとってこの Value Stream は短ければ短いほど嬉しいものです。 しかし実際には、Value Stream に含まれる業務の側面を見ると、手作業や部門間の引き継ぎ、多数のExcelファイルや調整作業といった、さまざまなムダやボトルネックが潜んでいます。
これらをデジタルの力で効率化することを、一般に「デジタルトランスフォーメーション (DX)」と呼びます。
では次に、この DX を支える “裏側” に焦点を当ててみましょう。
業務の効率化を実現するには、その仕組みを実際に作り上げる人たちが必要です。つまり、開発者です。開発者は、業務側が必要とする仕組みを設計し、開発し、テストし、デプロイし、業務の現場に届けます。
実はここにも、もう一つの Value Stream が存在します。
業務の要件定義から設計、実装、テスト、デリバリーまでの流れ。これがもう一つのValue Streamです。
この2種類の Value Stream には、次のような関係があります。
- Operational Value Stream (OVS): 実際の業務が顧客に価値を届ける流れ
- Development Value Stream (DVS): 業務が必要とするデジタル機能を開発して届ける流れ
この関係性から、次のように言うことができます。
Operational Value Stream の改善スピードは、Development Value Stream の軽さ・速さによって決まる。
DVSに時間がかかる理由
しかし現場に目を向けると、この Development Value Stream の1サイクルは決して軽くありません。 小さな改修でも1〜2週間、大きな機能になると数ヶ月、基幹系の入れ替えとなれば3年、5年というプロジェクトも珍しくありません。
このサイクルタイムが長くなるほど、OVS 側で「こう変えたい」というアイデアを試せる頻度は下がり、市場の変化に合わせて学習するスピードも落ちていきます。
DVSが遅い顧客向けシステムでは、より俊敏な競合サービスへ顧客が流れてしまうきっかけにもなります。
社内業務システムでは、待ちきれない現場が Excel や Access、VBA、RPA といった “影のIT（シャドーIT）” を増殖させてしまうこともあります。
ではなぜDVSが遅くなってしまうのでしょうか。
さまざまな組織で調査をさせていただくと、開発工程で行っていることは、プログラムを書くことだけではないことが浮かび上がっています。
例えばとあるプロジェクトは、「開発」工程の時間の使い方を分析した結果、プログラムを書くことに実際に使える時間は、割り当てられている時間のおおよそ1/3程度であることがわかりました。 さらにプログラミングをしている時間の中で、本当に欲しい新機能のプログラミングに割り当てられる時間は、さらに1/3です。
では他の時間は何をしているのでしょうか。分析してみると、開発者が日々行なっている作業は大きく次のように分類されます。
プログラミングではない作業
既存実装の調査
必要な機能に対して、どこにどう手を加えれば良いかを判断するために、関連するコードや設定、データフローなどを読み解く作業です。
トラブル対応
「動かしたら別のところが壊れた」「昨日まで動いていた処理が動かない」といった現象を追いかけ、原因を探し、対処する作業です。
プログラミングの作業
緊急のバグ修正
障害時にはOps (運用) が復旧後、暫定対応などの「パッチ」を開発することがあります。これは全てに優先して実施されるため、新しい機能の開発中にも対応が必要です。
新しい機能のために「過去の構造を修正する」作業
本当は新しい機能を作りたいのですが、その前に「過去の実装で手を入れないと進めない部分」を修正する必要がある場合があります。
こうした作業はどのアプリケーションでも一定は発生しますが、いわゆる「スパゲッティコード」状態であればあるほど頻繁に発生したり、頻度も工数も増大する傾向があります。
そして、この “構造に起因する時間のロス” こそが、DVS（開発のバリューストリーム）を重くし、結果として OVS（業務側のバリューストリーム）のスピードをも左右してしまいます。
良い設計の経済学
では、こうした問題が発生するのは人為的ミスなのでしょうか。
実は、そうではありません。
問題の多くは、開発者個人の能力や努力ではなく、良い設計の基準そのものが時代と共に大きく変化したことに由来します。 かつては「正しい判断」だった設計方針が、今では開発速度を下げる構造になってしまっている。そうした“歴史的な前提の違い”が、現場の時間配分に歪みを生んでいるのです。
かつて「プログラミング」が広まってきた頃は、CPUやメモリー、ディスクスペースといったコンピューティングリソースが非常に高価でした。 総務省の情報通信白書 (2015年版) では、1985年ごろのディスクスペースは1GBあたり50000ドル程度だったことが記録されています。
私自身も、約20年前に所属していた組織でTB単位のストレージを導入した際に、1,000万円を超える見積もりが出ていたことをよく覚えています。
当時の「良い設計」とは、限られたコンピューティングリソースでも効率よく動かせる設計でした。
そのため、アプリケーションが動きさえすれば十分であり、「より速く、より軽く動かす」ために、開発者がどれだけ時間を費やしても、それ自体がコストメリットのある投資でした。 これは、当時のアプリケーション規模が現在と比べて小さかったことにも支えられていました。
しかし現在は状況が大きく異なります。 複雑で巨大化したアプリケーションを維持・更新する上では、「人をあまり使わなくてすむ設計」こそが良い設計と言われています。その背景には、
- コンピューティングリソースが劇的に安価になったこと
- 一方で、開発者の時間 (人的リソース) が相対的に高価になったこと
というコスト構造の逆転があります。
この状況に適応するために、オブジェクト指向、ドメイン駆動設計 (DDD)、そしてその流れを継いだマイクロサービスアーキテクチャが普及していきました。
これらの手法が広く採用されているのは、コードを理解しやすくし、変更しやすくし、人的リソースの節約につながるという経済的合理性があるためです。
「DVSに時間がかかる理由」で触れた調査やバグ対応に追われる状況は、まさに当時の当たり前で設計されたシステムを、今の当たり前の規模とスピードで運用しようとした結果生まれた副産物です。
当時は妥当だった設計判断も、アプリの巨大化や人件費の高騰という世界的な変化を経て、維持するだけで高コストになってしまったのが現在のレガシーシステムと言えます。
ただし、すべてのシステムが今の当たり前に合わせて再設計されるべき、というわけではありません。 求められる更新頻度やビジネスの変化スピードによって、リファクタリングの必要性も、取り組むべきサイクルも異なります。
ここで重要なのが、OVS（業務の価値の流れ）とDVS（開発の価値の流れ）の関係です。 どれほど OVS にスピードが求められるかによって、DVS を軽くするための投資＝リファクタリングの重要度が決まります。 市場変化の速い領域ほど OVS に求められる改善速度が高まり、その時間的レバレッジを支えるために、DVSへの構造的投資（リファクタ）は戦略的な必要投資になるのです。
リファクタリングがDevにもたらす具体的なメリット
ここまで見てきたように、リファクタリングは「新機能を作る時間を少しでも増やすための構造投資」です。 では、その投資がうまくいったとき、開発者にはどのような変化が起きるのでしょうか。 代表的なものをいくつか挙げてみます。
変更すべき場所をすぐに特定できる
機能ごとに責務が分かれ、命名やレイヤ構造が整理されていると、「この変更はこのコンポーネント」と当たりが付けやすくなります。
結果として、既存コードを読み解く時間や、影響範囲調査に費やす時間が減ります。
バグ調査・トラブルシュートが短時間で済む
責務の境界や依存関係が明確になることで、「この不具合はどの層で起きていそうか」「どのコンポーネントまでは正常か」といった切り分けがしやすくなります。
夜間・週末の障害対応や、原因調査に追われる時間を減らすことができます。
新機能に着手するまでの「助走距離」が短くなる
既存の構造を理解し、壊さないように慎重にコードを読んでからでないと実装に入れない、という状況が減ります。
小さな変更を安全に積み重ねやすくなるため、短いサイクルでのリリースにも適した状態になります。
レビューやペアプロがやりやすくなる
設計意図や責務の分割がコードから読み取りやすくなると、レビューアが「何を見ればよいか」を判断しやすくなります。
特定の個人だけが理解している「暗黙知の領域」が減り、チームとして品質を支えやすくなります。
新メンバーの立ち上がりが早くなる
ドメインごとにモジュールが分かれている、テストが揃っている、といった状態は、オンボーディングにも効いてきます。
新しく参加した開発者が、短期間で安全にコードを触れるようになることで、チーム全体の開発余力が増えます。
これらの効果を合計すると、「もともと開発に割り当てていた時間のうち、1/9 しかなかった“新しい価値を生むためのコーディング時間”」を少しずつ広げていくことができます。
リファクタリングは、単に「きれいなコードにする」ためではなく、この 1/9 をどれだけ広げられるかを意識した、Dev視点の経済的な投資と言えます。
まとめ
今回は、開発者視点からリファクタリングを“良い設計の経済学”の観点で捉え直し、設計の良し悪しが DVS（開発の価値の流れ）のスピードにどれほど影響するのかを見てきました。
ただし、リファクタリングの価値は開発だけに留まりません。
日本の大規模システムでは、むしろ DBコネクション枯渇・バッチ処理の逼迫・スレッド増加 といった “キャパシティ課題（インフラ負荷）” が引き金になるケースの方が多く見られます。
本来はアプリケーション構造や運用基盤の改善で解消できる問題を、長年夜間対応、手動運用、再起動ナレッジといった人手オペレーションで肩代わりしてきた結果、その場しのぎのコストが恒常的な負荷となり、リファクタリングが「恒久的なリスクと運用コストの削減」という文脈で必要になるのです。
次回はこのような運用 (Ops) 側文脈を、同じ良い設計の経済学というレンズで紐解いてみたいと思います。
