コラム

既存システムを見える化!システムの見える化をするメリットとは?

システム見える化

近年、「デジタル・トランスフォーメーション(DX)」や「2025年の崖」といった言葉をよく目にするかと思います。
あらゆる産業において、新たなデジタル技術を活用して新たなビジネス・モデルを創出・柔軟に改変するDXが求められている一方で、既存システムの「老朽化」「複雑化」「ブラックボックス化」がその妨げとなっているのが現実です。つまり、まずは既存システムを「見える化」する必要があるのです。

システムの見える化とは?

システム見える化とは

システムの多くは複数の担当者の手で維持・運用されていきます。その中で改善や機能追加が行われれば開発当初の仕様から乖離していくわけですが、行った変更が必ずしも設計書に反映されるとは限りません。そしてその状態のまま担当者が変わってしまえば、残るのは「ブラックボックス化されたレガシーシステム」です。
「ブラックボックス化」と言っても、ソースコードを見れば当然仕様はわかります。しかし、複雑なプログラムを読み解くのはかなりの時間がかかりますし、古い技術になればなるほど技術者を集めることが難しくなります。そのため、ソースコードを見なくてもそのシステムがどのようなシステムがわかるよう「見える化」することが大事なのです。
では、それにはどのような方法があるのでしょうか。

仕様の見える化

ウォーターフォール開発の場合、「要件定義」「基本設計」「詳細設計」といった工程を経て開発が進む中で、それぞれの工程に合った粒度の資料や設計書が作成されます。しかし、その多くは時間が経過する中で陳腐化してしまうというのが現実です。
もし最新のソースコードに対応した設計書があったとすれば、システムの仕様を見える化するのに大きく貢献するはずです。ある特定のプログラミング言語に依存していない言葉に汎化された設計書さえあれば、ソースコードを読み解くことに比べて時間的・技術的ハードルは大きく下がることでしょう。

関連の見える化

長年の運用により複雑化してしまったシステムの場合、仕様がわかるだけでは足りないケースがあります。
既存のシステムを改修するには、事前に影響範囲の調査が必要です。プログラム間の関連やプログラムとDBとの関連など、その改修により影響を受ける箇所をあらかじめ調べておかないと、想定外の工数が発生したりトラブルの原因となります。
「プログラム関連一覧」や「CRUD」などがあれば、影響調査は各段に効率化されるはずです。

価値の見える化

システムを長期間に渡り利用していると、「昔は使われていたが時代の流れで不要になった」「必要だと思って実装したが実際にはあまり使われなかった」といった機能が出てきます。
使わないのであれば今は大きな問題はありませんが、新システムに置き換えるという話になった場合、移行対象に含めるかどうかなどが問題になってきます。
対象の機能が他機能と関連が無いことがわかる資料や、アプリケーションログなどから未使用であることがわかれば、有用な判断材料になると考えられます。

システムの見える化をするメリットとは

ここまでの内容で、システムが見える化されることでどのような効果があるのか簡単には触れてきましたが、メリットという観点で改めて以下にまとめます。

現状把握・引き継ぎが簡単に

古いシステムになると、「最新の設計書が存在しない」「担当者が退職してしまった」といった理由で、「誰も仕様がわからない」という状態で運用されてしまうケースがあります。そうなると、運用上のトラブルが発生する場合もありますし、引き継ぎにも時間が必要になります。当然、未来に向けて何か効果的な改善を実施したくても上手くいきません。
システムが正しく見える化されていれば、まず現行業務が正常化されます。また、急な引き継ぎが発生しても、基本的には資料を共有するだけで良くなります。そうすることで、やっと業務を改善するためにシステムを見直す余力が生まれるのです。

生産性や品質が向上

システムの運用・改善、再構築など、何かしらの変更を検討したり、実際に行ったりする場合には、必ず影響調査が必要となります。しかし、既存システムのソースコードを読み解いて影響範囲を調査するのはとても時間がかかりますし、技術的な問題から作業者も限定されます。また、調査に人の手が入るほどミスや抜け漏れも懸念されます。
影響調査に役立つ資料が充実していれば、調査にかかる工数を削減できるとともに、調査の度に都度実施する作業が減るため必然的に品質も向上します。

コストが低下

システムが老朽化すると、バージョンアップやマイグレーション、パッケージへの移行など、システム再構築に向けた何かしらの選択を迫られます。その際にシステムが見える化されていれば、どれを選択するのが適切かを検討・検証するためのコストを低減できます。また、不要になった機能は移行対象から除外したり、利用頻度が低い機能は移行せずに据え置きにしたりするなど、コストを抑えられる選択肢が存在するため、システムについてなるべく明確に把握しておく必要があります。
システムが見える化されていれば、「現在」の調査に大きく時間を取られることなく、「未来」の検討に移ることができるはずです。

再構築時のトラブル抑止

情報処理推進機構(IPA)が発行している書籍「システム再構築を成功に導くユーザガイド(※1)」では、再構築時の「現行踏襲」という要求について以下のように書かれています。

  • 再構築に際して、「現行踏襲」という要求が発生することは多い。「現行踏襲」を実現する上で注意しなければならないのは、「現行踏襲」の「現行」が何か、ユーザ企業とベンダ企業との間でギャップが発生する場合があるという点である。

そして、このギャップがあると以下のような問題を引き起こすと警鐘を鳴らしています。

  • ソースコードに実装されているものとドキュメントに乖離がある場合、どちらの情報で実現したいのかを見極めないと誤った「現行通り」になってしまう。また、システム全ての仕様がドキュメント化されていないことが原因となり、ユーザ企業とベンダ企業の両者が拠り所とする「現行踏襲」にギャップが生じてしまうこともある。ユーザ企業とベンダ企業の間だけではなく、ユーザ企業の中でも、システム部門と利用部門とでは、ギャップが生じるケースもある。
    上記の状態で再構築を行うと、トラブルになりやすい。それに加え、再構築と同時に業務要件の変更や追加を行うと、現行踏襲部分と業務要件の変更や追加をした部分との整合性の確保が難しくなる。その結果、品質保証の難易度が非常に高くなり、一層トラブルが生じやすくなる。

このような状況に陥らないためにも、システムの見える化はとても重要だと言えるでしょう。

※1 編集・発行元
独立行政法人情報処理推進機構(IPA)
タイトル:「システム再構築を成功に導くユーザガイド 第2版〜ユーザとベンダで共有する再構築のリスクと対策〜」
書籍紹介:https://www.ipa.go.jp/archive/publish/secbooks20180223.html
PDF:https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000057294.pdf
(ページ番号:P15-P16)

システム見える化の流れ

システム見える化の流れ

これまでご紹介した通り、システムの見える化にはいくつかのアプローチがありますが、やはり最新の「設計書」があるのはとても魅力的なことです。
そこで今回は、現行システムのソースコードを機械的に解析し、システム設計ツール「Verasym System Designer(VSSD)」上に設計書を自動生成する「システムの"見える化"支援」サービスについてご紹介します。
世の中には、ソースコード中のコメントを抜粋してドキュメント化するツールはいくつかありますが、コメントは必ず書かれているわけではありませんし、書かれていても内容が必ずしも正しいとは限りません。つまり、生成されるドキュメントの正確性はコーディングした担当者に依存するわけです。
一方、「システムの"見える化"支援」サービスはコメントを使用せず、ソースコードの構文を解析して日本語化することで設計情報を生成します。そのため、担当者に依存しない正しい設計情報となるのです。

「リバースエンジン」でソースコードを機械的に解析

「システムの"見える化"支援」サービスでは、独自ツール「リバースエンジン」でお客様のソースコードやデータベースの情報(DDL)等を機械的に解析し、VSSDで閲覧可能な形式の設計情報を自動生成します。解析可能な言語は複数あり、以下の言語に対応しています。
・PL/SQL
・VB6
・VB.NET(WinForms)
・C#(WinForms)
・Delphi
・Oracle Forms Developer
・Oracle Reports Developer
・Java

システム設計ツール「VSSD」にインポート

VSSDは、システム設計に必要な20種類以上の設計書を統一されたフォーマットで作成でき、設計変更時の影響参照や変更反映を簡単に行えるなど、設計を便利にする機能が数多く搭載されたシステム設計のための専用ツールです。
リバースエンジンで解析した設計情報をVSSDにインポートすることで、これまでExcel等で作成してきたものと同様な設計書として閲覧・編集できるようになります。
「システムの"見える化"支援」サービスで自動生成できる設計書は以下の通りです。
・画面定義(レイアウト、画面項目、イベント、処理、問合せ、更新項目、等)
・クラス定義
・テーブル定義
・ビュー定義
・ドメイン定義(項目定義)

無償サンプルを確認

お客様からご提供いただいたソースコードを数本見える化し、VSSDの体験版で閲覧できるようにしたものを無償でご提供することが可能です。
汎用的なサンプルではなく、お客様が実際に運用されているシステムがどのように見える化されるのかをあらかじめ確認できるため、見える化後の運用をよりイメージしやすくなります。

システムを見える化したあとの方針は?

「どのように見える化するか」だけでなく、「どのように活用するか」「どのように維持していくか」ということもまた大切です。一度見える化するだけして放置してしまっては、またブラックボックス化するだけです。適切に維持し、効果的に活用していきましょう。

正規の手順で設計してから開発する

新規開発時は上流工程を経て下流工程へと段階を踏んで設計した後、プログラムに仕様を反映していくと思いますが、リリース以降の修正は設計書の修正は行わずに実施してしまうケースもあるのではないでしょうか。
特に、設計しなくても開発できるような軽微な修正の場合はダイレクトにプログラミングしたくなる気持ちもわかりますが、それでは正しい設計書が残りません。また、簡単だと油断して思わぬミスをしてしまう危険性もあります。
このような問題を防ぐため、見える化したあとには本来あるべき姿に立ち返り、「設計」⇒「レビュー」⇒「開発」という正規の手順を踏んで開発されることを強く推奨します。

定常業務での活用

使われない情報は価値が下がり、維持されなくなります。そのため、見える化した情報は日々の業務の中で積極的に活用してくことが大切です。
VSSDにインポートされた設計情報はExcelに出力することも可能ではありますが、そのままVSSD上で管理することでより多くの機能の恩恵を受けることができます。設計修正時の影響範囲の調査や、機能追加時に役立つモックアップの自動生成機能など、システム設計ツールならではの機能が多数搭載されているため、上手に使うことで大きな効果が期待できます。

定期的な見直し

情報を有効に活用するためには、活用しやすい状態に保つ必要があります。利用者がわかりづらい表現になっていたら修正したり、足りない情報があったら補ったりするなど、定期的に見直しを行うことで、いざという時に信頼できる情報となってくれることでしょう。

まとめ

新しいシステムや機能の開発など、利益を生むものに対しては投資を惜しまない企業は多いですが、既に作り終えているシステムの見える化といった「直接的に利益を生まない作業」に対しては、多くの企業で費用を出し惜しみする傾向が見られます。
しかし、ブラックボックス化した状態でシステムを運用することはトラブルが発生するリスクがありますし、見える化することで大きなメリットがあるのは先述の通りです。
「システムの"見える化"支援」サービスでは無料トライアルも実施しております。まずはお気軽にお試しいただき、どのような「見える化」がされるか体験してみてはいかがでしょうか。