ゼロからはじめるシステム開発

　こんにちは！
　ナビゲータのEVEです。

　本日は、DX認定制度の続きです。
　前回は、デジタルガバナンス・コードについて調査をしました。その調査の結果、DX認定制度は、デジタルガバナンス・コード推進のために、準備できていることを認定してもらう制度のようだという話をしました。そして、デジタルコード・ガバナンスの全体像を示し、その内容とDX認定制度の申請にはリンクが取れていないという話をしましたが、以前読んだ資料を再度読み直したところ、リンクが取れているということを紹介しているページがありましたので、本日は同内容についてご紹介します。

[デジタルガバナンス・コードとDX認定制度申請書]

　DX認定制度 申請要項(申請のガバナンス)という文書の中で右記のような対比図が用意されていました。以前、目を通した文書だったのですが、デジタルガバナンス・コードを理解していなかったため、見過ごしてしまいました。
　見ていてふと思うのは、DX認定書の申請項目とデジタルガバナンス・コードの項目を分ける必要を感じません。多分、デジタルガバナンス・コードの方が先にできたはずなので、申請書はそちらに合わせて項目を作った方が、理解しやすかったと思うのですが、どうなのでしょうか？

[デジタルガバナンス・コードの進め方]

　ここから、デジタルガバナンス・コードに戻りたいと思います。先日、デジタルガバナンス・コードの全体像で右記の図を示しましたが、本日は、右記の図をもうちょっと、詳細に見ていきたいと思います。
　右記のデジタルガバナンス・コードの中身を簡単に言い換えると、以下の流れになると思われます。

　以上の流れをちょっと細かくすると、5つの柱に分解できます。
　その細かく分解された、5つの各柱は、「デジタルガバナンスコードにおける各柱」のように構成されているとしています。
　(1)基本的事項には、�@柱となる考え方と�A認定基準が各柱ごとに記述されています。その内容につきましては、デジタルガバナンス・コード3.0に記載されていますのでご参照ください。
　そして、(2)望まし方向性につきましては、優良事例を選定し、「DX銘柄」や「DXセレクション」の評価・選定基準として、「DXセレクション（中堅・中小企業等のDX優良事例選定）」というページで紹介され、活用されることもあるとのことです。
　そして、基本的事項は、情報処理促進法に基づくものとなっています。この情報処理促進法には、情報処理安全確保支援士に関することも書かれており、私たちは毎年、オンライン講習時に参照するモノとなっています。

[あとがき]
　当サイトは、DXを以下の内容で定義しました。

　その内容から考えると、今回のDX推進の内容は隠すまでもないとは思うのですが、進んで紹介するものでもないような気がします。企業が他社より優位となれるのは、模倣困難性と希少性がそろった場合になります。「DXセレクション（中堅・中小企業等のDX優良事例選定）」でDXの成功事例として紹介されるということは、競争優位の源泉を少なからず脅威にさらしているような気がします。
　その内容をまだ見ていないので、もしかしたらその内容が誰にでも見せることができる陳腐な内容なのかもしれませんし、経路依存性により、他社には真似はできないといった自信があるのかもしれません。
　その点については、後日資料に目を通したいと思います。

　では、また！

■DX認定制度 申請要項(申請のガバナンス)
https://www.ipa.go.jp/digital/dx-nintei/ug65p90000001jbd-att/000086670.pdf

■DXセレクション（中堅・中小企業等のDX優良事例選定）
https://www.meti.go.jp/policy/it_policy/investment/dx-selection/dx-selection.html

■DX認定制度
https://www.meti.go.jp/policy/it_policy/investment/dx-nintei/dx-nintei.html

　こんにちは！
　ナビゲータのEVEです。

　EVE VProjectで使用するαサイトの準備をしています。現在苦労しているのは、セキュアなSSHの接続方法・・・。できれば、公開鍵認証方式でログインしたいのですが、かなり苦戦しています。

[サーバー側へ公開鍵を設定する]
　公開鍵認証方式は、公開鍵と秘密鍵を作成し、作成した、公開鍵をサーバー側に設定し、秘密鍵をクライアント側に設定するモノです。一言で言うと何となく簡単にできそうなのですが、いろいろと困った点が・・・。困った点を列挙すると以下の通りとなります。

1)公開鍵の配置先
2)公開鍵のアクセス権

　1)公開鍵の配置先は、ユーザー毎に設定すると言うことを理解していないことが原因で混乱しました。XServerは、rootによるログインを許可しており、公開鍵の配置先は、＜ルート＞/root/.sshというディレクトリになるのですが、通常ユーザーは、 ＜ルート＞/home/＜ユーザー名＞/.sshとなります。自分が使用している環境は、root権限でのログインを無効としているので、このような事態になりました。
　次に2)なのですが、1)の延長線上の話になるのですが、ユーザー毎に設定するという認識がなかったため、アクセス権を設定しているファイルが違っていました。このアクセス権が適切に当該フォルダ及び公開鍵に設定されていないとログインできません。

[クライアント側に秘密鍵を設定する]
　秘密鍵はクライアントのどこに配置しても問題ありません。WinSCPは、RSAファイルをそのまま利用できないため、PuTTY Private Keyに変換しなければなりません。ただ、その変換がうまくいけば、他に苦労することなく当該サーバーにアクセスできます。多分、複数のサイトへ公開鍵認証方式でログインする場合でも問題ないと思います。
　ただ、問題はTeraTerm・・・。まず、ログイン画面からユーザーIDを入力しないとログインできないことを知らなかった・・・。まっ、ログインするのにサイトのIPだけでは無理があります。WinSCPは、ユーザーIDの入力は最初の1度だけで、それ以降入力することがないので、ユーザーIDについて失念をしていました。
　次に、複数のサイトで公開鍵認証方式でログインするのに問題がありそう・・・。TeraTermで複数のサイトへ公開鍵認証方式でログインする場合は、TeraTermマクロを利用するのですが、作成したマクロをTeraTermが認識しない・・・。ChatGPT、Gemini、Copilotどれに聞いてもうまくいきませんでした。仕方がないですね・・・。これについては、TeraTermについて詳述しているサイトで勉強し自力でマクロを作成します。

[あとがき]
　二日間ブログを書けず大変申し訳ございません。パソコンが調子が悪いなどの問題で更新できませんでした。ただつい最近、Windowsアップデートがあったのですが、その後は調子がいいようです。
　具体的な公開鍵認証方式の設定については、後日このサイトで公開します。ご興味がある方はしばらくお待ち下さい。

　では、また！

　こんにちは！
　ナビゲータのEVEです。

　本日は、DXの大まかの概要が分かってきました。現在、DX認定制度について調べているのですが、やはり、DXとは何なのかと言うところを押さえないと説明が難しいので、本日は原点に立ち返り、DXとは何なのかという所から話したいと思います。

[DXとは？]
　いろいろな資料、講習をみてそのベクトルがどっちに向いているのか分からなくなったので、日本がDXを進める上でのその根拠としている資料を探し求めました。
　その結果、デジタルガバナンス・コードがそれらしいということが分かりました。
　その中で重要なのが、５つの柱と3つの視点です。5つの柱なんだか見覚えがありませんか？

そうです。昨日DX認定制度の申請の内容をまとめましたが、その項目がこの5つの柱に相当すると思ったのですが・・・・・。対応はとれていませんでした・・・。
　ただ、調べて分かったのですが、DX認定制度とは、デジタルガバナンス・コードを実施するに当たり、準備ができているかどうかを認定する制度であると、ChatGPTとCopilotが解説をしてくれました。DXができたから認定してもらおうというモノではなく、準備ができたことを認定してもらうための認定制度だったようです。

[5つの柱と3つの視点]


　5つの柱と3つの視点から構成されるDXの全体像は右記のような構造になっています。見にくいですが、水色の部分が、5つの柱で、ネイビーブルーの部分が3つの視点となります。
　3つの柱は、今まで紹介していなかったので、下記に記します。


[あとがき]
　DXを推進にあたってのポイントについて以下のような解説がされています。

現在読んだ範囲なのですが、デジタルガバナンス・コードに記載されている内容を実施すればDXができるというものではなく、革新的で創造的なビジスを創出する上での、体制づくりとか環境作りなどをするためのモノっぽいと言う印象を持ちました。
　まだ、読んでいない資料もあるので、明日また気づいたことがありましたら、報告します。

　では、また！！！

■DX認定制度
https://www.meti.go.jp/policy/it_policy/investment/dx-nintei/dx-nintei.html

■デジタルガバナンス・コード
https://www.meti.go.jp/policy/it_policy/investment/dgc/dgc.html

　こんにちは！
　ナビゲータのEVEです。

　昨日、ブログをアップロードしながら以下のYouTubeの動画を見ていました。何か作業やりながらなのですが、ちょっと違和感が・・・。何かが違う・・・。
　それは、ナビゲータの方と観客とのやり取りでまず一言目が、「DXやったら儲かりますか？」っていう会話から始まるそうです。
　以上の言葉から始まるそのストリーミングの内容は、DXについてブログを書き始めた第1日目に定義した、その内容と大きく乖離がありそうな印象でした。

実は、セキュリティの話をするときにも「儲かりますか？」と言う話が出るらしいのですが、まずは、そこからなのかなって印象です。ただ、セキュリティよりは、儲かる話ができそうです。

[各資料を読んでみて]
　ストリーミングを見て、「？？？」といった印象だったのですが、ダウンロードした各資料には、以下のような文言が付記されています。

なんとなく、最初に当ブログで定義したDXという概念に近いと言った印象です。変革ということばがしっかりと入っており、ここに創造と言う言葉が入れば、中小企業基本法に書かれている内容とほぼ同じになります。中小企業基本法との違いは、システムにより実現するのか、しないのかといったぐらいの違いでしょうか？

[DX認定制度の取得レベル]
　DX認定制度の中身なのですが、すご〜く濃いかと聞かれれば、そうでもないようです。対象が大手ではなく、中小の企業で、現在絶賛人材不足と言っている状況なので仕方がないのかもしれません。取るための認定項目が載っていますので、下記に記します。

以上の内容から分かりますが、申請内容は定性的で、基準以上と認められれば、DX認定事業者として認められそうです。ただ、定性的な基準のレベルが分からないので、合格するかどうかは提出してみないと分からないといった所でしょうか？

[あとがき]
　昨日なぜだか寝苦しかったのですよね・・・。昨日は、休むことなく作業をし、夜を迎え、その夜はクーラーをつかわなくても涼しいといった印象でした。ただ、寝れない・・・。なぜだろう？？？疲れているし、寝る環境も整っているのに・・・。
　それにも関わらず、本日は定時(7:00)に起きることができ、作業を開始したのですが、やはり眠い・・・。2度仮眠をとりました。10分程度の短い時間でしたが・・・。
　という状況で、あまり、DXについても読み込めていない状況です。ということで、続きは明日とさせてください。

　では、また！！！

■中小規模製造業がDX（デジタルトランスフォーメーション）を推進するために「中小製造業のDXの取り組み事例 〜製造分野におけるDXの疑問点を解消！〜」
https://www.youtube.com/watch?time_continue=1221&v=Qg7G9kd_At8&embeds_referring_euri=https%3A%2F%2Fwww.ipa.go.jp%2F&source_ve_path=MTM5MTE3LDEzOTExNywxMzkxMTcsMjg2NjY

■【支援者向け】「中小規模製造業者の製造分野におけるDX推進ガイド活用」徹底討論セミナー（2021年1月27日開催）
https://www.youtube.com/watch?v=Ospys7lBnfY&embeds_referring_euri=https%3A%2F%2Fwww.ipa.go.jp%2F&source_ve_path=Mjg2NjY

■DX認定制度
https://www.meti.go.jp/policy/it_policy/investment/dx-nintei/dx-nintei.html

　こんにちは！
　ナビゲータのEVEです。

　今日は、日曜日ということで、セキュリティ関連について書きますといいながら、今日もDXについて書きたいと思います。
　今まで散々DXについて書きましたが、中小企業診断士、IPAの試験ではあまり採用されないようなことばかり書いてきたので、ここで、実際に試験に出題された内容について書きたいと思います。

[中小企業診断士　令和5年経営情報システム]
　令和5年の経営情報システムでは、DXについて、第10、11問と二問出題されています。全く手を付けていない分野を2分野も出題されて、受験中本当に頭が痛かったです。知らないその分野が出題されるということは、以前から分かっていて、その弱点を補っていなかった自分がいけないのは十分分かっているのですが、ちょっと腹がたちます。
　勉強を進めると、お客様、特に管理職以上の方と話す場合は、必要不可欠な情報だと言うことが分かります。管理職以上で、技術的に優れいている方もいるのは知っていますが、どちらかというと少数です。やはり、必然的に、社会的なところから徐々にその必要性を説明していかなくてはいけないと考えられます。
　ということで、今回は、今年出題された第10、11問について、どのようなことがとわれているのか見ていきたいと思います。

[DX認定制度]
　第11問は、ちょっと、読まなければいけない文献が多いので、明日以降に回すとして、本日は、第10問のDX認定制度についてどのような制度か報告したいと思います。
　まず、いつも通り、DX認定制度とはどのようなモノなのかChatGPTに聞いてみましょう！

へぇっ〜って感じなのですが、では、なんで、このようなことを開始したのでしょうか？引き続きChatGPTに解説をしてもらいます。

　以上のことを読んでいて気になるのは、そもそも企業は常に競争しています。その競争に勝ってこそ市場に残れます。DXと言われるそのものは競争の根源であり、この現代において必要不可欠なものです。なんか、このような形で推奨されなければやらないようなこの雰囲気は何なのでしょうか？
　ただ、DXを推進しなくても、今まで世界で戦ってこれたこの現状は、日本企業がすごいということを意味しているのかもしれません。それは、ないか・・・？

[経済産業省ホームページ]
　以上の内容をChatGPTに聞いた後、原本を見ようと経済産業省のホームページを見たのですが、こちらの方も資料でいっぱいです。もしかしたら、明日解説しようとしていたモノよりも資料が多いようです。
　ななめ読みになるとは思うのですが、すべての文章を読んでから感想を書きたいので、本件につきましては、明日また報告をさせていただきます。

[あとがき]
　現在の日本はどうやって企業間で競争をしているのだろうという疑問は、本日のブログを書き終えても残っているのですが、この資料を読んでいて思うのは、国として、DXを進めるにあたり、共通の認識がほしいのでこのような認定制度を設けていると考えられます。
　認定制度を取得する段階において、現在国が進めようとしているDXとは何なのかを知り、知ることにより、SIベンダーと対等な立場で話すことができるようになります。それと、少なくとも間違った方向へ推進をすることはなくなるでしょう？そんなメリットがあるのだと、思います。

　以前、ASPと言われたものが、知らないうちに、クラウドなんて名称になっていました。それは、ASPにもいろいろな形態があり、ASPという一言で会話ができなくなってしまったため、NISTが共通の認識のプラットフォームとして、クラウドというカテゴリを作って、提供側、そして利用する側、共通の認識で会話できるように策定したと聞いています。
　それと、同じようなことを、経済産業省がしようとしているのだと思います。

　ちょっと、まだ、考えがまとまりませんので、また明日！

　では、また！！！

■DX認定制度
https://www.meti.go.jp/policy/it_policy/investment/dx-nintei/dx-nintei.html

　こんにちは！
　ナビゲータのEVEです。

　つい最近まで、DXについてまとめていましたが、セキュリティについて解説するといいながら、DXについて書いてきました。ただ、その理由について書いていなかったので、その理由について本日は書きましょう！

[セキュリティ・バイ・デザイン]
　現在多くのプロジェクトで、システム設計・製造時に、セキュリティ・バイ・デザインと言われています。セキュリティ・バイ・デザインとはどんなことを指しているのかChatGPTに解説をしてもらいましょう！

ChatGPTの発言を補足すると、途中からセキュリティを追加することもできるのですが、かなり難しく、かつ費用もかかります。Webシステムの場合、WAFなどの導入などを考えられるのですが、ゼロトラスト的な考え方でいうと、システム自体にセキュリティを実装するのが本来のあり方です。そのため、システムを設計する段階から、セキュリティを考慮に入れて開発したほうがいいのはいうまでもありません。
　私もかつて、Prototype EVEにおいて、2004年にシステムリリース後、システムを停止し2006年〜2009年までセキュリティロジックを追加したという経験があります。その約3年間の改修後感じたのは、最初から作り直したほうがよかったということです。
　その時の経験を踏まえたうえで発言させていただくと、是非セキュリティ・バイ・デザインは実践してほしいです。

[DXとセキュリティ]
　DXを進めるうえで、レガシーシステムが問題になっています。そのため、レガシーシステムを更改することを検討するのですが、その時に機能を踏襲し、更改するのではなく、セキュリティを最初から考慮したうえでシステムを開発しましょうというのが、情報処理安全確保支援士からの提案になります。そのため、今まで長々とDXについて話してきました。余計なことをたくさん書いた気もしますが、現状調査だとご理解ください。

[あとがき]
　以上が、今まで長々とDXについて書いた理由です。すっきりしましたでしょうか？まっ、あまり気にしていないとは思いますが、一度書いたことなので、その理由について書かせてもらいました。
　以前、会社面接において、セキュリティをやりたいと面接官に話したことがありましたが、その時に、セキュリティのどこをやりたいか聞かれたことがありました。その時点では、情報処理安全確保支援士試験に合格しているわけでもなく、情報セキュリティ全体について勉強をしていたので、セキュリティ全般と回答しましたが、ちょっとこの回答に問題があるような気がします。医者を例に考えると分かるのですが、専門分野というのがあります。セキュリティといっても範囲が広く、専門分野を決めていないと、いい加減なコンサルティングになってしまうかもしれません。それを念頭に考えた場合、私の場合は、セキュリティ・バイ・デザインを1つの分野としたいと思います。

　では、また！！！

　こんにちは！
　ナビゲータのEVEです。

　Javaは、テキストの最初に厳格な規約が記載されていますが、JavaScriptや、PHPはそのような規約は今まで見たことがありませんでした。ただ、いろいろ調べていくうちに、JavaScript、PHPには規約ににたようなものがあることに気づきました。JavaScriptについては、昨日調べ報告したので、本日は、PHPについての報告になります。

[PSR]
　PHPの規約として、PSRという標準規約が存在します。それについては、昨日最後にその概要について触れましたが、改めて、ChatGPTに聞いてみました。

PSRは着実に普及しており、オープンアーキテクチャなどを構築する場合、有用な標準規約となりそうです。

[PSRの内容]
　調べた当初は、命名規約を中心に調べていたので、気づきませんでしたが、命名規約は、PSR-1に記載されており、それ以外の規約も用意されているようです。以下がPSRに記載されている規約になります。

PSR-5〜PSR-11については、正式に承認されなかったため、現在欠番となっています。上記については、概要で、もし規約として利用するなら詳細に調べる必要があるようです。

[あとがき]
　JavaScript、PHPとか調べていくと、共通のキーワードが出てきます。具体的な例を挙げると、パスカルケース(PascalCase)、キャメルケース(camelCase)などといった用語です。パスカルケースは、クラスの名をつけるときに使用し、キャメルケースはメソッド名、プロパティ名で利用しています。これは、言語が違っても共通の規約として利用され、どの言語においても一般化されているようです。
　近頃、どの言語も似てきていて、現在どの言語で製造しているのか迷うときがありますが、それでもなお、規約は言語共通で作成したほうが混乱が少ないかもしれません。そのため、開発にはより一層注意深さが必要になってきます。
　PSR-1〜PSR-4、PSR-12については、今後、EVE Projectで規約を整備し、整備完了後、EVE Projectコーディング規約公開の時に解説をさせていただきます。
　なお、既に作ったプログラムは順次修正していき、リリース当時は規約を遵守していない場合があります。プログラムの先頭は、EVE Projectとかはタブを利用しているので、修正が大変そうです・・・。

　では、また！！！

　こんにちは！
　ナビゲータのEVEです。

　本日は、初めて知ったJavaScriptのコーディング規約についての話です。
　IPAの試験でも出題されることがあるのですが、プロジェクトをスムーズに進行させる方法として、コーディング規約を厳守するということが挙げられています。その点について、以前ブログで書きましたが、非常に重要です。その理由については、「プログラマのすすめ　〜食えるプログラマの条件〜　[システム開発研究室]」で確認して頂くとして、その時は、プロジェクト内を想定していましたが、今回は範囲を世界的なレベルまで広げます。
　日本のシステム業界は、中国を中心に、インドなどいろいろなエンジニアの方が活躍してます。その人達と連携をするなら、世界に広げるべきでしょう！

[世界標準]
　じゃ、世界標準とはどのようなものなのか、調べてみると、そんなものがないことが分かりました。以前紹介した、「Airbnb JavaScript Style Guide」は、アメリカの1企業が作成し、同企業の業種は、宿泊予約プラットフォームの運営になります。同企業はアメリカ企業らしく社内でシステム開発し、その開発時の規約を公開したところ、その内容が社会に受け入れられ、世界の多くのプロジェクトで利用されているらしいです。
　世界標準を探しているのに、以上の内容では納得できないので、標準化団体から出ている規約がないか、ChatGPTに調べてもらいました。

以上について、ChatGPTだけでなく、Copilot、Geminiにも聞いてみましたが、ほぼ解答は同じでした。標準化団体からの標準規約はないようです。

[どれを選択する]
　どれを選択するかは、プロジェクトリーダーの判断に委ねられるようです。じゃ、EVE Projectではどれを選択するのかということになりますが、今後、Google Mapを作る機会などがあるような気がするので、Google社の規約を標準とします。ただね・・・。以前話した通り、ここのオブジェクト指向言語の記述の仕方、私が嫌いというか理解できないような記述になっているのですよね・・・。これから理解しなければとは思うのですが、それを規約とするのは今までいやだったのですが・・・。ただ、標準化団体からでているものがないので、グローバル企業である、Google社の規約を今後利用していくことにしました。

[あとがき]
　しらべたら拍子抜け・・・。じゃ、PHPの方は？っということで、PSRについて調べましたが、こちらは、非公式ではありますが、PHPのフレームワークやライブラリの開発者、ユーザー、コミュニティのメンバーが参加する協議体のようです。そのまま利用することができそうですね？
　では、明日は、PHPから、PSRについてご紹介したいと思います。

　では、また！

■プログラマのすすめ　〜食えるプログラマの条件〜　[システム開発研究室]
https://fanblogs.jp/bahamuteve/archive/195/0

　こんにちは！
　ナビゲータのEVEです。

　　昨日は、EVE Projectだったらレガシーシステムをどうするのかという話をし、IPAからでている文書との相違点は、リバースエンジニアリングの部分かもしれないという可能性について触れました。
　そして、今回の全体像について、私自身も話していませんし、IPAからも出ていないので、本日は、このような作業の進め方の全体像についてお話ししたいと思います。
　本日話す内容は、EVE Projectが考えるやり方であり、IPAからこれから出てくる文書がその通りのやり方で出稿されるかどうか不明です。もし、知りたい方がいましたら、直接IPAにお聞きになってください。

　では、本題に入りましょう！

[抽象化モデル]
　これから紹介する方法は、レガシーシステムを保有し、かつ、IBMにさえ無理ですと言われたシステムに対して、かなり前に提案したことがあるやり方になり、タイトルにある通り、抽象化モデルと言われる方法になります。
　DFDに基づくやり方という意見もあり、EVE Projectは、昨日お話しした通り、「プログラムなんてどうでもいい！データが全てだ」といっているので、そうした観点から言うと、このやり方を選択するのは当然の流れかもしれません。
　具体的に、大きな流れで解説すると、以下のようになります。

　❶は、EVE Projectでは、現状調査にあたります。そして、❶の細かく現状分析した結果を❷で抽象化します。その作業と同時並行的に❸では、新システムの抽象的なモデルを作成します。そして、❷と❸を比較することにより、何が不足し、何が増えたのか確認し、その確認した内容が、意図した通りだった場合、❶で作成した資料と同一レベルの資料を❹で作成するという流れになります。この後に、❶と❹を比較検討するというフェーズがあるかもしれません。
　この方法を採用することにより、段階的に改善や変更を繰り返しながらシステムを具体化していくことが可能になります。
　このやり方について、Geminiは、以下のようなメリットがあるといっています。

最初ChatGPTに聞いたのですが、プロトタイプ開発を念頭においているようで、使えないと判断し、Geminiの意見を採用しました。レガシーシステムでプロトタイプ開発はちょっと、難しいかなと判断しました。
　引き続き、デメリットについて確認していきましょう！

IPAがこの方法を採用しているかどうか、現時点不明ですが、本日以降にIPAから新たに文書が出てきて、抽象化モデルだと分かったら、以上のようなリスクを考慮した方がいいようです。

[あとがき]
　以上の方法、実は、IPAの1次試験で出題されています。IPAの試験を受験する人がいましたら、試験に役立ててください。ただ、ここでは、抽象化モデルと書いたのですが、試験でなんて呼称されていたのか思い出せません。過去に出題されています。もし、見つけたら、なんて呼称するのか正式な名称を教えてください。

　DXについて長々とお話ししてきましたが、実は、ここまでは、IPAも中小企業診断士もあまり試験に出た実績はありません。ここ以降なんですよね・・・。試験に出るの・・・。試験にも出ないこと長々と書いてしまいました。
　セキュリティから始まった、DXの話なのですが、ちょっと、間隔をおいてから、試験に出そうなところと、セキュリティの絡みについてお話ししたいと思います。
　ただ、書き終えてみて、2018年当時の日本のシステム業界について知ることができました。これから、情報処理安全確保支援士として、多くのお客様のところに訪問しますが、参考としたいと思います。

　では、また！！！

　こんにちは！
　ナビゲータのEVEです。

　今日の開始は予定通り、プログラム修正から始めました。Xでつぶやきましたが、現在、PHPのプログラムを、PSR-1ガイドラインに基づいて修正しています。JavaScriptについては触れていませんでしたが、今後「Airbnb JavaScript Style Guide」に基づいて記述する予定です。どちらも、今まで規約らしい規約を見た記憶がないのですが、世界標準みたいなモノが、あったようです。今後気をつけるのと同時に、修正できるところから徐々に修正していきます。
　なんて、作業をしながら、XServerに開発環境を構築しようとしたのですが、キーが変更になったと、クライアントツールにメッセージが表示されました。作業をする場合、必ず、SSHを利用しているのですが、公開鍵暗号方式でログインをしているので、この場合のキーとは公開鍵になります。WinSCPでは、このメッセージが出たのは初めてです。ちょっと、心配になったので、XServerを再初期化後運用方法を変更しました。キーを先に作成し、サーバーに公開鍵を設定し、クライアントに秘密鍵を設定するように仕様を変更しました。これもまた、やり方を知らなかったので、時間がかかってしまいました。まっ、今後は安心して利用できるのでしょうか？運用を開始してからの鍵の変更は難しいですし・・・。
　その辺は今後考えるとして、本日のブログでは、私だったらどんなアプローチでレガシーシステムに対応するのか書きたいと思います。

[現行の超大規模システムをマネジメントが容易な規模（機能システム）に分割整理]
　2024年9月2日に書いた「現行の超大規模システムをマネジメントが容易な規模（機能システム）に分割整理」までの内容はできれば実施したいと感じています。ただ、ちょっと、やり方は違うくなりますが・・・？

コンセプトは、自分たちがコントロールできる単位まで分解すると言うことだと思うので、ここはやり方は多少違いますが、マネした方が良い点だと思います。ただ私の場合は、機能システムへ再分類するというその作業はここでは省略します。2024年9月2日では、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」の内容を以下のような流れで紹介しています。


[サブシステム分解後]
　ちょっと、流れ的には違っていますが、対応しやすい単位に分解するという目的を達成する作業という意味では同じです。それ以降なのですが、チョット違います。私の場合は、昨日、書きましたが、サブシステム毎に、プログラム解析、またはリバースエンジニアリングを実施し、データ構造を解析します。
　この「ゼロからはじめるシステム開発」で何回か書かせて頂いているのですが、プログラムなんてどうでもいいのです。バグがあっても、汚くなっていてもなんでもいいと考えています。ただ、データの完全性が保証されるならという前提条件はあるのですが・・・・。
　前提条件のデータの完全性を保証しようとした場合、プログラムにバグがあることは許されません。そのようなケースがあるので、プログラムは正確に作ることを心がけます。
　ここでは、データの完全性が保証されていることを確認しながらデータ構造を解析します。

[あとがき]
　ごろごろ寝っ転がりながら、いろいろ考えたのですが、辛辣な意見を昨日言ったにもかかわらず、違うのは、リバースエンジニアリングを実施するかしないかだけの違いのようです(辛辣の言葉で発言して申し訳ございません)。「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」もこれが最後ではなく、続きがあるのですが、検討の結果多分、その部分も私の考え方と同じになりそうだという結論になりました。
　「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」にも作業の全体像が書かれていないので、明日は、その全体像についてご紹介し、本作業の流れを押さえていきたいと思います。

　では、また！！！

　こんにちは！
　ナビゲータのEVEです。

　昨日のブログですが、ちょっと、刺激的な内容になってしまいました。書き直そうかなとも思いましたが、共通フレームワークの下りとかは、YouTubeで見たときの印象で、その時は過激な内容を避けたのですが、今回の「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」を読んでみて、書いたほうがいいと感じ書かせてもらいました。
　日本では情報システム以外でもそうなのですが、権威主義的な対象物に対して、何も声をあげない傾向にあります。以前のブログで書きましたが、そんな世の中が、失われた20年とか、30年を作ったのかもしれません。

[Only you can do that!]
　2024年8月28日の「DXとSIベンダー」のあとがきで書きましたが、アメリカのSEは、「自分たちだけが信じることができ、それ以外の人間たちには任せておけないという雰囲気で仕事をしている」らしいです。この話、聞いたモノなので、正確かと聞かれれば詰まる部分もあるのですが、ただ、本来日本の職場でもこうでなければいけないのだと思います。
　ようは、以下の状況だと考えてください。

　そう考えれば、昨日の「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」」のような公的な文書を読んだとき違った印象を持つことができるかもしれません。実は現在私はそういう思考で目を通しています。
　まっ、それを口に出していうと嫌われるのは知っていますけどね(笑)。私も実名でやっていないからこのような内容を書けるという部分はあります。アメリカ人なら実名でもいうんでしょうね？

[あとがき]
　昨日は、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」の問題点を辛辣な口調で書き、本日はなぜそんなことを書いたのかその理由を述べました。ただ、非難だけなら誰でもできます。そして無責任です。
　できれば、無責任な人間にはなりたくはないので、明日私だったらどんなアプローチでレガシーシステムと向かい合うかということを書かせていただきます。
　あなたから見たら、ゴミ、カス、アホな私がもっともらしいことを書くので、もしよろしければお付き合いください。今日は、短くなりましたが、この辺で！

　では、また！！！

　こんにちは！
　ナビゲータのEVEです。

　3日間お休みをいただきました。休む1週間前から体がだるいという認識はあったのですが、きちんとした対応をしてきませんでした。そのため、急に寒くなったタイミングだったでしょうか？風邪の症状と思われる、頭痛、咳、吐き気をもようし、熱はなかったのですが、つらかったので、3日間お休みを頂きました。
　本日は、頭痛、吐き気はないのですが、激しい咳が時々出るのと、粘膜関係から出血があります。もう少し安静にしてから、全快に持っていきたいと思います。
　本日は前回の続きで、自分たちがマネジメントしやすいレベルになった、レガシー問題の機能システムをどうやって、機能復元するのかその手法について見ていきます。

[業務機能の復元する上での問題]
　ここで、レガシーシステムのシステム機能がブラックボックス化している問題の大きな要因としてドキュメントがないことをあげています。今まで、ドキュメントがないのは、大手SIベンダーの究極の営業という話をしましたが、レガシー問題を抱えている企業のほとんどがドキュメントがないと答えている状況は、私の推測が外れている可能性を示しているのかもしれません。

[レガシー問題への対応の起点]
　以上の問題を「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」では、一気にレガシー問題を解決できればいいのだが、費用等の問題でできない可能性に触れています。その場合、以下の起点がレガシー問題への対応への機会ととらえています。


[対象システム]
　❶〜❸のいずれかの場面になったとき、レガシー問題への対応を考える起点として考えているのですが、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」の中で、対象のシステムを限定しています。それは、ウォーターフォール開発で製造されたシステムです。この文章を読んだとき、「えっ？？？」って一瞬思いましたが、対象が肥大化したレガシーシステムです。作られたのは、多分1990年代以前のものが対象となるので、ウォーターフォール開発に限定して問題ないかもしれません。ただ、その当時、ウォーターフォール開発での開発ばかりではなく、プロトタイプ開発やスパイラル開発もあったような気がしますが、大丈夫でしょうか？

[仕様の復元方法]
　ウォーターフォールで開発されたシステムにおいて、どのように仕様を復元するのかその手法に触れています。総合的に情報を収集する必要性を前提条件に置き、以下の方法を挙げています。

この辺になると、ピンとこないんですよね？？？❶なんか、ドキュメントがないっていうのに、各種ドキュメント類ってどういうことでしょうか？まっ、残りかすでも集めろっていうことなのでしょうか？
　システムを作る立場の人間から、❷のログや稼働実績から仕様を復元するというのは、全く理解ができません。
　❸の有識者へのヒアリングなのですができますかね？当時プロジェクト参加者で既に死んでいる人いませんか？直近のレガシーシステムでも開発されてから20年・・・。聞いたところで一番古いものになると、50年になっています。もしかしたら、レガシーシステムの定義が間違っているのかもしれませんが・・・？

[対応方法]
　仕様の復元方法は、読みながら「？」な部分が多かったのですが、読込が足りないだけかもしれません。もう少し後日きちんと読み直すとして、次に、レガシーシステムへの対応方法について見ていきたいと思います。「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」では、以下の種類に分けていくことを推奨しています。

既に、今までの作業で詳細な機能システムは分かっているので、以上の分類は簡単にできると思います。その分類の後行うのは、DFD、業務フロー、画面変遷、状態遷移といったところに主眼をおいて業務を復元するとしています。
　ここでもやはり、しっくりきません。「仕様復元方法」でも感じたのですが、プログラム解析、リバースエンジニアリングが一切出てこないのです・・・。なんか、上っ面だけ調査して、無駄なことをしているような気がしてならないのですが・・・？

[あとがき]
　共通フレームワークに関するYouTubeを見ていて感じましたが、システムを作っていない人も、エンジニアという肩書で多く世の中にいることを感じます。共通フレームワークって何を参考にして作っているか知っています？それは、日本の生産管理を参考にして作っています。
　ようは、日本では、モノづくりでうまくいっています。それは、1人で作る工芸品だけでなく、車のように高品質が求められ、かつ大量に作る製品においてでもです。そのため、トヨタ生産方式ではないのですが、生産現場の生産方式をソフトウェア業界に持ち込んで作ったのが、共通フレームワークだというのです。共通フレームワークの本を購入して読みました。はっきり言って中身があるとは思えません。ところどころいいことはかいてありますが、現在でも多くの現場で使用されていない理由がよくわかります。YouTubeで共通フレームワークを解説をしている人も含めて、このプロジェクトに参画している人全員が、実際に、最初から最後までシステムを開発する経験をしていないので、ピントがずれているような気がします。
　以上のことから分かりますが、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」ではところどころいいことは書いてあるので、参考にするのはいいのですが、全面的に参考とするのは問題があるかもしれません。
　なお、この感想は、あくまで私見です。読み込みが足りないだけかもしれません。他の人がそう言っているのをは聞いたことはありません。

　では、また！

　こんにちは！
　ナビゲータのEVEです。

　昨日は、IPAが作成した、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」に書かれている課題について紹介し、その課題に対して、どんなアプローチにより解決しようとしているのか、その概要についてまとめました。
　本日は、その詳細について調査していきたいと思います。

[現行の超大規模システムをマネジメントが容易な規模（機能システム）に分割整理]
　昨日IPAが考えるレガシーシステム刷新の課題をChatGPTに100文字にまとめてもらいました。

以上の問題をIPAでは、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」の中で、大きい概念から徐々に小さくしていき、最終的に自分たちがコントロールできるところまで分解した上で、その分解したモノに対して対策を立てようとしています。その手法は、ブラックボックス化、超大規模化、P2Mというキーワードの課題に対してアプローチをし、解決することを目的としているようです。
　そのアプローチ方法を一覧化すると以下のようになります。


[現行ITシステムの仕様復元]
　多分以上までは、システムエンジニアを複数人入れることにより成果物として作成することができると思われます、しかし、果たして、以上の成果物から、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」後半に書かれた内容で、再構築できるのかどうか本日の考察ではイメージできませんでした。
　本件について、もう少しお時間を頂いて考察させてください。なお、以上に書かれた内容は私の理解であり、かつ、省略している部分があります。レガシーシステムで本当に悩まれている方は、原本をお読み頂き対応して下さい。
　続きは明日書きます

　では、また！！！

　こんにちは！
　ナビゲータのEVEです。

　金曜日まで2018年におけるDXの課題について見てきました。その中で、レガシーシステムが大きな問題を抱えており、その問題を解決しないと、DXが実現できないといった印象を持ちました。本日は、そのレガシーシステムに焦点を当てて考えて見たいと思います。

[レガシーシステムの課題の再認識]
　そのレガシーシステムの問題に対して、IPAから「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」をリリースしています。その内容は、DXを進めることの重要性と、その重要なDXを進める上でレガシーシステムが大きな壁として立ちはだかっている状況に警鐘を鳴らしています。その状況について、2019年に発表したDX 推進指標を、同年に287社の企業が自己評価したものをIPA が分析した結果によると、DX指標の上位5%企業は自社のIT資産の評価・分析は行ったうえで、評価・分析の結果を踏まえて不要資産の廃棄などの具体的な施策につなげているが、残りの95%の企業はDXにまったく取り組んでいないレベルにあるか、 DX の散発的な実施に留まっているに過ぎない段階であることを報告しています。その状況の分析により、以下の2つの課題があるとしています。


特に❷が解決することができない理由として、2つの理由を挙げています。

現行仕様が不明となっているITシステムの部分再構築のプロジェクトは問題化しやすく、ITベンダーの問題プロジェクトの多くがこのケースであるといわれています。いわゆる「現行機能保証」を求められるとプロジェクトの難易度が高くなるということが、失敗事例として語られています。

[IPAからのソリューション]
　以上の課題に対して、IPAから以下の内容でソリューションを提供しようとしています。

以上の詳細な内容を、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」に記しており、本問題を解決してほしいとしています。

[あとがき]
　「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」は、「DX実践手引書 ITシステム構築編（完成第1.1版）」の別冊という扱いです。読み方としては、「DX実践手引書 ITシステム構築編（完成第1.1版）」をまず読み、次に「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」を読むという順序になりそうです。本編約200ページ、別冊約50ページと読み応えある内容になっています。本編は、実際にDXを進めるうえでの話しなので、明日は、IPAがこの問題をどのように解決しようとしているのか、「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」中心に話を進めたいと思います。

　では、また！

■DX実践手引書 ITシステム構築編
https://www.ipa.go.jp/digital/dx/dx-tebikisyo.html