ナビゲータのEVEです。
3日間お休みをいただきました。休む1週間前から体がだるいという認識はあったのですが、きちんとした対応をしてきませんでした。そのため、急に寒くなったタイミングだったでしょうか？風邪の症状と思われる、頭痛、咳、吐き気をもようし、熱はなかったのですが、つらかったので、3日間お休みを頂きました。
本日は、頭痛、吐き気はないのですが、激しい咳が時々出るのと、粘膜関係から出血があります。もう少し安静にしてから、全快に持っていきたいと思います。
本日は前回の続きで、自分たちがマネジメントしやすいレベルになった、レガシー問題の機能システムをどうやって、機能復元するのかその手法について見ていきます。
[業務機能の復元する上での問題]
ここで、 レガシーシステム のシステム機能が ブラックボックス化 している問題の大きな要因として ドキュメントがない ことをあげています。今まで、ドキュメントがないのは、大手SIベンダーの究極の営業という話をしましたが、レガシー問題を抱えている企業のほとんどがドキュメントがないと答えている状況は、私の推測が外れている可能性を示しているのかもしれません。
[レガシー問題への対応の起点]
以上の問題を 「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」 では、一気にレガシー問題を解決できればいいのだが、費用等の問題でできない可能性に触れています。その場合、以下の起点がレガシー問題への対応への機会ととらえています。
?ソフトウェアおよびハードウェアのサポート切れによるケース
?部門最適やプログラムコピーによるスパゲティ化や肥大化によるケース
?当初作っていたときとビジネスモデルが大きく変化して追従できないケース
[対象システム]
?〜?のいずれかの場面になったとき、レガシー問題への対応を考える起点として考えているのですが、 「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」 の中で、対象のシステムを限定しています。それは、 ウォーターフォール開発 で製造されたシステムです。この文章を読んだとき、「えっ？？？」って一瞬思いましたが、対象が肥大化したレガシーシステムです。作られたのは、多分1990年代以前のものが対象となるので、ウォーターフォール開発に限定して問題ないかもしれません。ただ、その当時、ウォーターフォール開発での開発ばかりではなく、 プロトタイプ開発 や スパイラル開発 もあったような気がしますが、大丈夫でしょうか？
[仕様の復元方法]
ウォーターフォールで開発されたシステムにおいて、どのように仕様を復元するのかその手法に触れています。総合的に情報を収集する必要性を前提条件に置き、以下の方法を挙げています。
?システムの設計情報などの各種ドキュメント類
?ログ・稼働実績
?業務処理に関する有識者や現場の業務知識のヒアリング
この辺になると、ピンとこないんですよね？？？?なんか、ドキュメントがないっていうのに、各種ドキュメント類ってどういうことでしょうか？まっ、残りかすでも集めろっていうことなのでしょうか？
システムを作る立場の人間から、?のログや稼働実績から仕様を復元するというのは、全く理解ができません。
?の有識者へのヒアリングなのですができますかね？当時プロジェクト参加者で既に死んでいる人いませんか？直近のレガシーシステムでも開発されてから20年・・・。聞いたところで一番古いものになると、50年になっています。もしかしたら、レガシーシステムの定義が間違っているのかもしれませんが・・・？
[対応方法]
仕様の復元方法は、読みながら「？」な部分が多かったのですが、読込が足りないだけかもしれません。もう少し後日きちんと読み直すとして、次に、レガシーシステムへの対応方法について見ていきたいと思います。 「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」 では、以下の種類に分けていくことを推奨しています。
?バッチ型 → DFD
?オンライン型 → 業務フロー
?Web型 → 画面編線図
?ゲートウェイ型 → 状態遷移図
既に、今までの作業で詳細な機能システムは分かっているので、以上の分類は簡単にできると思います。その分類の後行うのは、 DFD 、業務フロー、画面変遷、状態遷移といったところに主眼をおいて業務を復元するとしています。
ここでもやはり、しっくりきません。「仕様復元方法」でも感じたのですが、プログラム解析、 リバースエンジニアリング が一切出てこないのです・・・。なんか、上っ面だけ調査して、無駄なことをしているような気がしてならないのですが・・・？
[あとがき]
共通フレームワーク に関する YouTube を見ていて感じましたが、システムを作っていない人も、エンジニアという肩書で多く世の中にいることを感じます。共通フレームワークって何を参考にして作っているか知っています？それは、日本の生産管理を参考にして作っています。
ようは、日本では、モノづくりでうまくいっています。それは、1人で作る工芸品だけでなく、車のように高品質が求められ、かつ大量に作る製品においてでもです。そのため、トヨタ生産方式ではないのですが、生産現場の生産方式をソフトウェア業界に持ち込んで作ったのが、共通フレームワークだというのです。共通フレームワークの本を購入して読みました。はっきり言って中身があるとは思えません。ところどころいいことはかいてありますが、現在でも多くの現場で使用されていない理由がよくわかります。YouTubeで共通フレームワークを解説をしている人も含めて、このプロジェクトに参画している人全員が、実際に、最初から最後までシステムを開発する経験をしていないので、ピントがずれているような気がします。
以上のことから分かりますが、 「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」 ではところどころいいことは書いてあるので、参考にするのはいいのですが、全面的に参考とするのは問題があるかもしれません。
なお、この感想は、あくまで私見です。読み込みが足りないだけかもしれません。他の人がそう言っているのをは聞いたことはありません。
では、また！
