見積もりの前提が変わり始めている

古くなったシステムを何とかしたい。

そう考えてはいるものの、以前取得した見積もりが想像以上に高額で、刷新を見送った企業もあるのではないでしょうか。

長年利用されてきたシステムの中には、OSやミドルウェア、開発環境などのサポートがすでに終了しているものもあります。

「いずれ対応しなければならない」と分かっていても、費用やリスクを考えるとなかなか動き出せない。

私自身、これまでシステムのモダナイズや見積もりに関わる中で、こうした難しさを感じてきました。

一方で、最近はAIをはじめ、静的解析や各種自動化などの技術が進歩し、調査や見積もりの方法そのものが変わってきています。

実際の案件に取り組む中でも、以前より広い範囲を調査し、リスクを確認したうえで見積もりや提案を作れる場面が増えてきたと感じています。

そして、もう一つ大きく変わったことがあります。

それは、見積もり段階から、お客様とシステムについてかなり具体的な会話ができるようになったことです。

大規模なシステムほど、見積もりが難しい

例えば、数十万ステップ規模のソースコードを抱えるシステムを考えてみます。

見積もりを依頼されたとしても、限られた期間の中で、そのすべてを人が詳細に確認することは簡単ではありません。

もちろん重要な部分は調査します。

しかし、すべてのコードや依存関係、仕様、潜在的な問題まで把握しようとすれば、それだけでも相当な工数が必要になります。

さらに、見積もりを作成したからといって、その案件を必ず受注できるわけでもありません。

そのため、見積もり段階の調査にかけられる時間や人員には現実的な限界があります。

開発する側からすると、十分に確認できていないところには「実際に着手してみないと分からない」というリスクが残ります。

そのリスクを考慮すると、ある程度の余裕を持った見積もりにせざるを得ない場合があります。

結果として、発注する側からすると「想定していたより高い見積もり」に見える。

以前は、こうしたことが少なからずあったのではないかと感じています。

AIや解析技術によって「リスクの見え方」が変わった

現在は、AIだけではなく、静的解析をはじめとしたさまざまな手段を組み合わせることで、見積もり段階で確認できる範囲が広がっています。

コードの規模を把握する。

システムの構造や依存関係を調査する。

変更した場合に影響が大きそうな部分を洗い出す。

モダナイズする際に問題になりそうな箇所を確認する。

以前は限られた時間の中で人が一つずつ確認していた作業について、より広い範囲から情報を集めやすくなりました。

もちろん、AIにソースコードを渡せばシステムのすべてを正確に理解できるわけではありません。

AIの解析結果自体が間違っている可能性もあります。

そのため、AIの結果だけで判断するのではなく、静的解析などのツール、実際のソースコード、既存資料、そして人による確認を組み合わせます。

その上で、

「この部分は影響が大きそう」

「ここは比較的移行しやすそう」

「ここは事前に技術検証した方がよさそう」

といった形でリスクを整理していきます。

「何が起きるか分からない」という不確実性を少しずつ減らせることで、見積もりの根拠についても説明しやすくなったと感じています。

解析結果を、お客様と一緒に確認する

私たちが特に大切にしているのは、解析結果を自社の中だけで使って終わらせないことです。

調査したシステム構成やソースコードの状況、依存関係、確認できた課題などを可能な範囲で資料として整理し、お客様にも確認していただきます。

その資料を一緒に見ながら、

「私たちは、このシステムをこのように理解しています」

「この機能は、この処理につながっていると認識しています」

「この部分には、こういった課題があると考えています」

と確認していきます。

ここで重要なのは、私たちがコードから読み取った内容と、実際のシステムの使われ方が一致しているかどうかを確認することです。

プログラム上は重要そうに見える機能でも、現在はほとんど利用されていないことがあります。

反対に、コードだけを見ていると小さく見える処理が、実際の業務では非常に重要な役割を持っていることもあります。

解析したからといって、それだけですべてが分かるわけではありません。

だからこそ、解析結果をお客様に見ていただき、

「実際の運用もこの認識で合っていますか」

と確認します。

このやり取りによって、技術的な理解と実際の業務との認識差を、開発が始まる前に見つけやすくなります。

お客様側に存在しなかった資料ができることもある

長期間利用されてきたシステムでは、現在のシステムと設計資料が完全には一致していないことがあります。

改修を重ねる中で資料が更新されていなかったり、そもそも当時の資料が残っていなかったりすることもあります。

そうしたシステムを調査すると、

システムの構成。

モジュール間の依存関係。

利用されている技術。

影響範囲。

注意が必要と思われる箇所。

といった情報を、現在のソースコードなどをもとに整理することができます。

場合によっては、それまでお客様側で整理されていなかった情報を、新たな資料としてお渡しできることもあります。

もちろん、それを過去の正式な設計書そのものと考えるわけではありません。

現在のシステムを解析した結果として、現状を理解するための資料を作るという位置付けです。

その資料をお客様にも確認していただくことで、さらに精度を上げていきます。

これは単に見積金額を出すこととは別の価値だと感じています。

そして、お客様にとっても、

「自社のシステムをここまで確認した上で提案している」

ということが見えるため、安心して相談しやすくなるのではないかと思っています。

「足りないもの」を具体的に確認できる

解析を進めていると、いただいたソースコードや資料だけでは、システム全体の構造を説明できない場合があります。

例えば、

あるプログラムから呼ばれているモジュールが見当たらない。

参照されているライブラリが含まれていない。

必要と思われる設定ファイルが存在しない。

といったケースです。

こうした場合、

「資料が足りません」

と漠然とお願いするのではなく、

「この処理から参照されている、このファイルが確認できません」

「このモジュールから呼ばれているソースコードが含まれていないようです」

と、できるだけ具体的にお伝えします。

すると、お客様側でも対象を探しやすくなります。

追加で提供していただいたものをもう一度確認し、システムの全体像を少しずつ埋めていく。

見積もり段階でこの作業を行うことで、私たちだけではなく、お客様自身も、

「自社が何を保有していて、何が不足しているのか」

を把握しやすくなります。

見積もりの段階から、実装方法について会話できる

現状を詳しく把握できるようになると、見積もりの会話も変わります。

単に、

「全面刷新すると○○円です」

という話だけではなく、

「この部分は現在の仕組みを残すことができます」

「ここだけを先に刷新する方法があります」

「この部分については、別の構成にすることもできます」

といった選択肢を提示できる場合があります。

これまでお客様側では検討されていなかった方法を、こちらから提示できることもあります。

ただし、技術的に可能だからといって、それが業務上最適とは限りません。

そこで、

「この方法であれば技術的には可能ですが、業務上問題ありませんか」

「この機能については現在のものを残す選択肢もありますが、いかがでしょうか」

と確認します。

すると見積もりが、

単純に価格を提示する場ではなく、どのようなモダナイズ方法が現実的なのかを一緒に考える場

になっていきます。

この変化は非常に大きいと感じています。

判断が難しいところは、小さく試してみる

それでも判断できない部分については、技術検証を行います。

例えば、検証用の環境を用意して、一部のコードを新しい環境向けに変換してみる。

リスクが高そうな機能について、小さなプロトタイプを作り、動作を確認する。

こうした技術検証では、AIによるコード生成も積極的に活用できます。

ここで作るものは、本番システムとして納品するための完成品ではありません。

「この方式で本当に移行できるのか」

「どの程度の修正が必要なのか」

「どこに問題が出そうなのか」

を確認するためのものです。

AIを使えば、複数の方式を短時間で試せる場合があります。

その検証結果を人が確認し、本番ではどの方法を採用するのかを判断します。

モダナイズには、すでに動いている既存システムという参考材料があります。

そのため、特にリスクの高い部分を本格的な開発の前に小さく試すことで、見積もり段階の想定と実際の開発とのギャップを小さくしやすくなります。

「全部刷新する」以外にも選択肢がある

システムの状態が詳しく分かれば、モダナイズの方法についても複数の案を考えられます。

サポートが終了していてリスクの高い部分だけを先に刷新する。

問題の少ない部分については、現在の仕組みを残す。

複数段階に分けて移行する。

全面的に刷新する。

そして、それぞれのメリット、デメリット、費用、リスクを比較する。

企業によって予算や優先順位は異なります。

必ずしも、一度にすべてを新しくすることが最善とは限りません。

だからこそ、まず現在の状態を理解し、その上で現実的な選択肢を考えることが大切だと思っています。

AIは「完成品を作らせる」ためではなく、「より良く考える」ために使う

AIの利用については、私たち自身も慎重に考えています。

調査や解析。

リスクの洗い出し。

技術検証。

プロトタイプ。

テストやチェック。

こうしたところでは積極的に利用します。

例えば、既存コードを解析して、

どのような処理をしているのか。

どのような依存関係があるのか。

新しい環境ではどのような方式が考えられるのか。

を整理する。

技術検証のためのコードやプロトタイプを生成して、複数の方法を比較する。

こうした用途ではAIは非常に有効です。

一方、本番システムとして提供するコードについては、AIの生成物をそのまま成果物として使用するのではなく、解析結果や実装例などを参考情報として利用し、エンジニア自身が仕様や設計意図を理解した上で設計・実装することを基本としています。

生成AIの業務利用では、知的財産や機密情報、セキュリティなども含めて考える必要があります。政府のAI事業者ガイドラインでも、AI利用時の安全性、セキュリティ、プライバシーや知的財産への配慮などが重要な事項として整理されています。

AIに完成品を任せることが目的ではありません。

人がより多くの情報を持ち、より良い判断をするためにAIを利用する。

私たちは、現在はその使い方を基本としています。

サーバー構築でも、AIは支援役として使う

インフラについても同じです。

AIを使って、

構成を検討する。

設定項目を洗い出す。

構築手順書のたたき台を作る。

設定内容をチェックする。

といったところは効率化できます。

一方、本番環境については、AIが作成した手順をそのまま適用するのではありません。

人が内容を確認し、対象の環境で問題ないかを判断した上で実際に構築する。

構築後の確認も人が行う。

AIによって準備や確認は効率化しつつ、本番環境を変更する判断と実施については人が主体となる。

そういう役割分担をしています。

テストやチェックには積極的にAIを使う

テストやチェックについては、AIや自動化を活用できる領域が多いと感じています。

コードを一次的にチェックする。

テストケースを検討する。

問題になりそうな箇所を洗い出す。

異なるAIや解析手段を使い、複数の観点から確認する。

こうした作業を人による最終確認の前に行うことで、問題をある程度絞り込めます。

これまでであれば、

人がテストする。

問題を見つける。

修正する。

もう一度テストする。

という工程を何度も繰り返していました。

もちろん、現在も人による確認は必要です。

ただ、その前に機械的にできる確認を行っておけば、人は本当に確認が必要な部分に時間を使えます。

AIによって人によるテストをなくすのではなく、

AIを使うことで、人がより重要な確認に集中できる状態を作る。

そのように考えています。

ソースコードをAIで解析するときは、情報の扱いにも注意する

AIによるコード解析では、もう一つ重要なことがあります。

それは、AIに入力する情報の扱いです。

ソースコードには、企業独自の技術情報や機密情報が含まれている可能性があります。

そのため、どのサービスを利用するのか、入力したデータがどのように取り扱われるのか、契約上問題がないのか、といった点を確認する必要があります。

AI事業者ガイドラインでも、AIの利用にあたってセキュリティやデータ、権利関係などを適切に扱うことの重要性が示されています。

AIを積極的に利用することと、情報管理を緩くすることは別の話です。

業務で利用するからこそ、利用する環境や情報の範囲についてルールを決めた上で活用することが重要だと考えています。

見積もりそのものが、システムを理解する機会になる

ここまでを振り返ると、現在の見積もりは、単に金額を算出するだけではなくなってきていると感じています。

システムを調査する。

解析結果を資料として整理する。

お客様に確認してもらう。

認識の違いを確認する。

不足しているソースコードや資料を特定する。

複数の実装方法を考える。

必要な部分についてはプロトタイプで技術検証する。

その結果をもとに見積もりを作る。

こうしたプロセスそのものが、システムを理解する機会になります。

開発会社だけが理解を深めるのではありません。

お客様自身にとっても、

「現在、自社のシステムはどうなっているのか」

「どこに問題があるのか」

「今後どのような選択肢があるのか」

を整理する機会になります。

そして、双方が同じ資料を見ながら認識を合わせることで、

「この会社は本当にシステムを理解しているのだろうか」

という不安も減らせるのではないかと思っています。

以前の見積もりが高くて諦めたなら、もう一度調べてみる価値はある

こうした変化を実際の案件で感じているからこそ、以前システム刷新の見積もりを取得し、金額を理由に計画を見送った企業には、一度あらためて現在の状態を調べてみる価値があると思っています。

もちろん、

「AIを使えば必ず安くなる」

ということではありません。

詳しく調べたことで、むしろ新しい問題が見つかる場合もあります。

大規模な改修が必要だと分かることもあります。

ただ、以前とは調査、解析、技術検証、テストなどに利用できる手段が変わっています。

単に、

「全面刷新するとこの金額です」

と提示するだけではなく、

「ここにはこの問題があります」

「この部分は残せそうです」

「ここだけ先に変更する方法もあります」

「この方法なら別の進め方も考えられます」

といったところまで含めて検討しやすくなっています。

数年前に取得した見積もりが、現在も唯一の答えとは限りません。

まずは、お互いに現在地を知るところから

現状診断をしたからといって、そのまま全面刷新へ進む必要はありません。

まず、現在のシステムがどのような状態なのかを知る。

そして、解析した内容を開発会社だけで持つのではなく、お客様と共有する。

こちらの理解と、お客様の認識が一致しているかを確認する。

その上で、

全面的に刷新するのか。

段階的に刷新するのか。

一部だけ対応するのか。

現在の仕組みをしばらく残すのか。

を一緒に考える。

AIを使うことそのものが目的ではありません。

目的は、これまで見えにくかったものをできるだけ見えるようにし、お客様と開発側の認識を合わせ、不確実性を減らした上で、現実的な判断ができるようにすることです。

AIや解析技術が進歩したことで、以前よりシステムを深く調査できるようになりました。

ただ、それ以上に大切なのは、調査して分かったことをお客様と共有し、一緒に確認しながら次の選択肢を考えられるようになったことなのかもしれません。

実際にモダナイズ案件に取り組む中で、私たちはそこに大きな変化を感じています。

現在のシステムについてご相談ください

以前に見積もりを取得したものの、金額やリスクの大きさから刷新を見送った場合でも、現在は調査や解析、技術検証の方法が変わっています。

「以前の見積もりが高く、そのままになっている」
「サポートが終了したシステムを何とかしたい」
「どこまで刷新する必要があるのか分からない」
「全面刷新ではなく、段階的な方法も検討したい」
「まずは現在のシステムの状態を整理したい」

といった段階でも、お気軽にご相談ください。

現在のシステムやソースコード、既存資料などを確認しながら、現状を整理し、どのような対応方法が考えられるのかをご一緒に検討します。

お見積もりのご相談も承っています。

［現在のシステムについて相談する］