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

<< 2024年09月 >>
日	月	火	水	木	金	土
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

2024年09月30日

DX認定制度　−デジタルガバナンス・コード−　～システム開発研究室～

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

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

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

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

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

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

?ビジョンを作成する。
?PDCAを回す(過程で組織作り、人材育成、セキュリティの強化を行う)
?ステークホルダと対話をする。

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

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

■当サイトのDXの定義
　「新たな技術から創造されたビジネスが、新たな顧客体験を生みだし、生み出された体験により新たな価値が生み出される。その価値が競争優位となり、確立することにより市場における優位性を生み出す」
(2024年08月26日)

　その内容から考えると、今回の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

タグ： DX認定制度希少性経路依存性デジタルガバナンスコード情報処理促進法情報処理安全確保支援士

posted by ゼロから始めるシステム開発 at 17:11 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月28日

SSH：公開鍵認証方式でログインする　～セキュリティ研究室～

　こんにちは！
　ナビゲータの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アップデート があったのですが、その後は調子がいいようです。
　具体的な公開鍵認証方式の設定については、後日このサイトで公開します。ご興味がある方はしばらくお待ち下さい。

　では、また！

タグ： Windowsアップデート Copilot Gemini ChatGPT マクロ teraterm PuTTYPrivateKey RSA ssh αサイト WinSCP XSERVER 秘密鍵公開鍵公開鍵認証方式 EVEVProject

posted by ゼロから始めるシステム開発 at 17:21 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月24日

DX認定制度　−DXとは？−　～システム開発研究室～

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

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

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

１．経営ビジョン・ビジネスモデルの策定
２．DX戦略の策定
３．DX戦略の推進
３−１．組織づくり
３−２．デジタル人材の育成・確保
３−３．ITシステム・サイバーセキュリティ
４．成果指標の設定・DX戦略の見直し
５．ステークホルダーとの対話

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

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

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

DX経営に求められる３つの視点
・経営者が、企業価値の向上につながるDX経営を実行するに当たっては、以下の３つの視点を意識しながら、各柱立ての項目について取り組むことが重要である。
・なお、３つの視点と５つの柱との関連性については、「DX経営に求められる３つの視点・５つの柱」の図を参照されたい。

?経営ビジョンとDX戦略の連動
・経営環境が急速に変化する中で、持続的に企業価値を向上させるためには、経営ビジョンと表裏一体で、その実現を支えるDX戦略を策定し、実行することが不可欠である。
・DX戦略の検討に当たっては、経営陣が主導し、経営ビジョンとのつながりを意識しながら、重要なデジタル面の課題について、具体的なアクションやKPIを考えることが求められる。

?As is - To be ギャップの定量把握・見直し
・経営ビジョン実現の障害となるデジタル面の課題を特定した上で、課題ごとにKPIを用いて、目指すべき姿（To be）と現在の姿（As is）とのギャップの把握を定量的に行う必要がある。
・把握した結果を基に、DX戦略が経営ビジョンと連動しているかを判断し、DX戦略を不断に見直していくことが重要である。

?企業文化への定着
・持続的な企業価値の向上につながる企業文化は、所与のものではなく、DX戦略の実行を通じて変革し、醸成されるものである。そのため、DX戦略を策定する段階から、目指す企業文化を見据えることが重要である。

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

■ デジタルガバナンスコード3.0
　具体的に企業がDXの推進により持続的な企業価値の向上を図っていくためには、以下の４点が重要である。
?新たな価値創造のために不可欠な経営資源としてデジタル技術を捉え、DX戦略を描くこと

?デジタルの力を、効率化・省力化を目指したITによる既存ビジネスの改善にとどまらず、新たな収益につながる既存ビジネスの付加価値向上や新規デジタルビジネスの創出に振り向けること

?ビジネスの持続性確保のため、ITシステムが技術的負債となることを防ぎ、計画的なパフォーマンス向上を図ること

?必要な変革を行うため、IT部門、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

タグ： DX デジタルガバナンス・コード ChatGPT Copilot

posted by ゼロから始めるシステム開発 at 16:10 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月23日

DX認定制度−申請内容−　～システム開発研究室～

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

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

■当サイトのDXの定義

「新たな技術から創造されたビジネスが、新たな顧客体験を生みだし、生み出された体験により新たな価値が生み出される。その価値が競争優位となり、確立することにより市場における優位性を生み出す」
(2024年08月26日)

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

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

　DX認定制度（以下、「本制度」という。）とは、情報処理の促進に関する法律第三十一条に基づき、「企業がデジタルによって自らのビジネスを変革するためのビジョン・戦略・体制等が整った」事業者を経済産業大臣が認定する制度である。
(2023年10月　DX認定制度概要　経済産業省)

“企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること”
（令和４年９月『デジタルガバナンス・コード 2.0 』より）

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

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

《認定項目》
(1) 企業経営の方向性及び情報処理技術の活用の方向性の決定公表媒体（文書等）の名称
┣公表日　　　　年　　月　　日
┣公表方法・公表場所・記載箇所・ページ
┣記載内容抜粋
┗意思決定機関の決定に基づいていることの説明

(2) 企業経営及び情報処理技術の活用の具体的な方策（戦略）の決定
┣公表媒体（文書等）の名称
┣公表日　　　　年　　月　　日
┣公表方法・公表場所・記載箇所・ページ
┣記載内容抜粋
┗意思決定機関の決定に基づいていることの説明

　?@ 戦略を効果的に進めるための体制の提示
　┣戦略における記載箇所・ページ
　┗記載内容抜粋

　?A 最新の情報処理技術を活用するための環境整備の具体的方策の提示
　┣戦略における記載箇所・ページ
　┗記載内容抜粋

(3) 戦略の達成状況に係る指標の決定
┣公表媒体（文書等）の名称
┣公表日　　　　年　　月　　日
┣公表方法・公表場所・記載箇所・ページ
┗記載内容抜粋

(4) 実務執行総括責任者による効果的な戦略の推進等を図るために必要な情報発信
┣発信日　　　　年　　月　　日
┣発信方法
┗発信内容

(5) 実務執行総括責任者が主導的な役割を果たすことによる、事業者が利用する情報処理システムにおける課題の把握
┣実施時期　　　　年　　月頃　～　　　年　　月頃
┗実施内容

(6) サイバーセキュリティに関する対策の的確な策定及び実施
┣実施時期　　　　年　　月頃　～　　　年　　月頃
┗実施内容

以上の内容から分かりますが、申請内容は 定性的 で、基準以上と認められれば、 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

タグ： Youtube 変革中小企業基本法創造定性的 DX認定事業者

posted by ゼロから始めるシステム開発 at 17:07 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月22日

DX認定制度　～システム開発研究室～

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

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

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

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

　DX認定制度（デジタルトランスフォーメーション認定制度）は、日本の経済産業省が推進する制度で、企業がデジタル技術を活用して事業や組織全体を変革（デジタルトランスフォーメーション、DX）し、競争力を高めることを目的としています。この制度は、企業のDXに向けた取り組み状況を評価し、一定の基準を満たした企業を「DX認定企業」として認定します。
　具体的には、次のような基準に基づいて企業が評価されます：

?DXビジョンの設定
　デジタル技術を活用した事業変革のビジョンや戦略が明確に定められているか。
?ガバナンス体制
　経営層を中心に、DXを推進するための体制やリーダーシップが確立されているか。
?投資・リソースの配分
　DXに必要な技術や人材への投資が行われ、リソースの最適な配分ができているか。
?情報セキュリティ対策
　DX推進に伴うリスク（サイバーセキュリティ等）に対する十分な対策が講じられているか。

　この認定制度を通じて、企業はDXに向けた自社の取り組みを対外的にアピールし、信頼性を高めることができます。また、DXをさらに推進するためのガイドラインや支援を受けられる場合もあります。

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

　経済産業省がDX認定制度を始めた背景には、日本企業全体が直面するデジタル化の遅れと、これに対応するための競争力強化の必要性があります。具体的な理由は以下のような点にあります。

?デジタル技術の活用による競争力強化の必要性
　世界的にデジタル技術の進展が進み、企業の競争力はその技術をどれだけ効果的に活用できるかにかかっています。日本の企業は、特に既存のビジネスモデルに依存していることが多く、デジタル技術を取り入れるスピードが遅れています。その結果、国際的な競争に後れを取るリスクが高まりました。
　経済産業省は、企業がデジタル技術を活用して新しいビジネスモデルを構築し、国際市場での競争力を高めるために、DXの推進が不可欠と判断しました。

?産業の変革に対する対応
　世界中で、人工知能（AI）、ビッグデータ、IoT（モノのインターネット）などのデジタル技術を活用した産業構造の変化が進んでいます。製造業、サービス業など、あらゆる業種がデジタル技術を使って新たな価値を創出しています。
　日本の産業がこれらの変化に取り残されないよう、企業が積極的にデジタル技術を取り入れてビジネスモデルを変革できるよう支援する必要があると認識しました。

?生産性向上と持続的成長の推進
　日本では労働人口の減少が進んでおり、生産性の向上が急務となっています。DXは、業務プロセスの効率化や自動化を進め、生産性を向上させる大きな可能性を持っています。経済産業省は、企業がDXを通じて生産性を高め、持続的な成長を実現できるよう支援するため、DX認定制度を導入しました。

?中小企業の支援
　DX推進の課題は、大企業だけでなく中小企業にも存在します。中小企業は資源や技術力の制約からDX推進が難しいことが多いですが、DXの推進によって市場での競争力を強化することが可能です。
　経済産業省は、DX認定制度を通じて中小企業にもDX推進の重要性を周知し、これらの企業がデジタル技術を取り入れるための環境整備や支援を行うことで、日本全体の産業構造の変革を目指しています。

?企業の信頼性向上とイメージ戦略
　DX認定制度によって企業が認定を受けることで、社内外に向けたDX推進の姿勢が明確化され、信頼性が向上します。これにより、取引先や投資家に対してDXに積極的に取り組んでいることをアピールでき、企業のイメージアップや市場での競争力強化につながることが期待されています。

?国際的な競争環境への適応
　世界ではデジタル化が急速に進んでおり、欧米諸国やアジアの新興企業と競争するためには、日本企業が迅速にデジタル技術を取り入れ、業務やサービスのイノベーションを進める必要があります。経済産業省は、DX認定制度を通じて、企業が国際的な競争環境に適応し、グローバルな市場で成功できるように促進しています。

■まとめ
　経済産業省がDX認定制度を始めた目的は、企業がデジタル技術を活用して持続的な競争力を高め、産業全体の生産性向上と革新を推進するためです。また、中小企業のDX推進を支援し、国内外での競争に打ち勝つための基盤づくりを進めるためでもあります。この制度を通じて、企業の変革と成長が促進され、日本経済全体の強化につながることを目指しています。

　以上のことを読んでいて気になるのは、そもそも企業は常に競争しています。その競争に勝ってこそ市場に残れます。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

タグ： NIST クラウド asp SIベンダー認定制度経済産業省経営情報システム IPA 中小企業診断士 DX セキュリティ

posted by ゼロから始めるシステム開発 at 16:06 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月14日

DXについて書いた理由　～セキュリティ研究室～

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

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

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

　セキュリティバイデザイン（Security by Design）とは、ソフトウェアやシステムを設計する際に、セキュリティを最優先に考慮するアプローチです。セキュリティバイデザインの目的は、開発の初期段階からセキュリティを組み込むことで、システムがリリース後も安全であることを保証することです。
　以下に、セキュリティバイデザインの主要な原則を紹介します。

?最小権限の原則（Principle of Least Privilege）:
　システムやアプリケーションにおいて、ユーザーやプロセスには必要最低限の権限のみを付与する。これにより、万が一攻撃を受けても、被害の範囲を最小限に抑えることができます。

?防御の層（Defense in Depth）:
　システムを複数のセキュリティ層で保護し、ひとつの防御が突破されても他の防御で守るという考え方です。例えば、ファイアウォール、侵入検知システム、データ暗号化などが考えられます。

?セキュリティの早期実装（Security by Design and Default）:
　セキュリティを設計段階から組み込み、デフォルト設定でもセキュリティが確保されている状態にすることです。これにより、ユーザーがセキュリティ設定を変更しない限り、安全が保証されます。

?脆弱性管理（Vulnerability Management）:
　システムの設計段階から脆弱性を特定し、修正することが重要です。これにはコードレビューやセキュリティテストの実施が含まれます。

?セキュリティの可視化（Security Visibility）:
　セキュリティの状態を常に監視し、ログやアラートを使って異常を検出し、対応する仕組みを設けることです。

?安全なデフォルト設定（Secure Defaults）:
　ソフトウェアやシステムが出荷時に安全な設定であることを保証することです。これにより、ユーザーが設定を変更する前に、セキュリティが確保されます。

?データ保護（Data Protection）:
　データを暗号化し、適切に保護することです。データの機密性や整合性を確保するために、データベースや通信経路での暗号化が推奨されます。

?セキュリティのテストとレビュー（Security Testing and Review）:
　開発過程でセキュリティテストを行い、設計や実装におけるセキュリティ上の問題を早期に発見し修正することです。定期的なセキュリティレビューも重要です。
　セキュリティバイデザインを採用することで、セキュリティに関する問題を事前に防ぎ、システムのリリース後も安全を維持するための基盤を築くことができます。

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

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

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

　では、また！！！

タグ： DX セキュリティバイデザイン ChatGPT WAF ゼロトラス EVE レガシーシステム情報処理安全確保支援士

posted by ゼロから始めるシステム開発 at 12:09 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月13日

PSR　～プログラミング研究室～

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

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

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

　PSR（PHP Standards Recommendations）は、**PHP-FIG（PHP Framework Interoperability Group）**という組織によって作成されました。PHP-FIGは、PHPのフレームワーク開発者や主要なプロジェクトのリーダーたちが集まり、互換性のあるコードを書くための標準を定めることを目的として結成された団体です。

■PHP-FIGの目的と背景
　PHP-FIGは、異なるフレームワークやライブラリが互いに矛盾することなく、スムーズに連携できるようにするため、コーディング規約やインターフェースを標準化することを目的としています。特に、異なるPHPフレームワーク間の互換性や、開発者が様々なプロジェクト間で一貫したコーディングスタイルを保つためのガイドラインを提供しています。

■PSRの普及状況
　PSRは、PHPの開発者コミュニティで広く受け入れられており、多くのPHPフレームワークやライブラリがこの標準に準拠しています。たとえば、以下のような有名なフレームワークがPSRに基づいて開発されています。

・Laravel
・Symfony
・Zend Framework
・Slim Framework

これらのフレームワークは、PSRのコーディング規約やインターフェース標準に従っているため、開発者は異なるプロジェクトでも一貫した規約に従ったコーディングができ、フレームワーク間の互換性も高くなっています。

■業界での影響力
　PSRは、PHPフレームワークやライブラリだけでなく、商業的なソフトウェア開発やオープンソースプロジェクトでも採用されていることが多いです。PSRに従うことで、コードの可読性や保守性が向上し、開発者間の協力がしやすくなるため、特に大規模な開発プロジェクトで重視されています。

■結論
　PSRは、PHP-FIGによって作成され、現在ではPHPコミュニティ全体で広く普及しています。多くの有名なフレームワークやライブラリがこの標準に従っており、PSRに準拠することで開発の一貫性が向上し、異なるプロジェクト間でもコードの互換性が確保されます。

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

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

?PSR-1: 基本コーディング標準
　PSR-1は、PHPコードの基本的なコーディング規則を定めています。これにより、コードの統一性が高まり、異なる開発者間でも一貫性のあるコードを書くことができます。

・PHPタグ: <?php または <?= タグを使用し、短縮タグは避ける。
・文字エンコーディング: ファイルはBOMなしのUTF-8で保存する。
・クラス命名規則: クラス名はStudlyCaps（単語の先頭を大文字）形式を使う。
・定数: 定数は全て大文字で、単語間はアンダースコアで区切る（例：MAX_COUNT）。
・サイドエフェクトなし: ファイルはクラス、関数、または定数の宣言のみに限定し、それ以外の処理（例：出力）は行わない。

?PSR-2: コーディングスタイルガイド
　PSR-2は、PSR-1の補足で、詳細なコーディングスタイルに関する規約を定めています。コードのフォーマットを統一し、可読性を向上させることを目的としています。

・インデント: インデントはスペース4つを使用する（タブは使用しない）。
・行の長さ: 1行の最大長は80文字、100文字を超える場合は例外的に許容。
・名前空間とuse宣言: 名前空間宣言の後には1行空行を入れる。use 宣言はブロックでまとめる。
・クラスとメソッド: クラスの中括弧 { は次の行に置く（オープンブレーススタイル）。メソッド名はcamelCaseを使用する。

?PSR-3: ロギングインターフェース
　PSR-3は、ロギングのためのインターフェース標準です。ログを出力するシステムに対して一貫したインターフェースを提供します。

・主要なメソッド: emergency(), alert(), critical(), error(), warning(), notice(), info(), debug()など、ログの重要度に応じてメソッドが定義されています。
・コンテキストデータ: ログメッセージにはコンテキスト情報を渡すことができ、メッセージの詳細を補足する。

?PSR-4: 自動ロード規約（オートローディング）
　PSR-4は、PHPクラスの自動ロードに関する規約です。名前空間に基づいてクラスを自動的に読み込むための標準化を提供します。これにより、手動でのrequireやincludeの使用を避け、コードの整理がしやすくなります。

・名前空間とファイルパスのマッピング: 名前空間はディレクトリ構造と一致し、クラス名とファイル名は同じである必要があります（例：App\Controller\UserControllerは/App/Controller/UserController.phpにマップされる）。

?PSR-12: 拡張コーディングスタイルガイド
　PSR-12は、PSR-2をさらに発展させ、最新のPHPバージョンにも対応するために拡張されたコーディングスタイルガイドです。変数の宣言方法、インラインコード、関数の引数に関するガイドラインが追加されています。

■まとめ
　PSRはPHPの開発において標準的なコーディング規則を提供し、複数の開発者が同じプロジェクトで一貫性を保ちながら作業できるようにするためのものです。PSR-1とPSR-2は主に基本的なコーディング規約を定め、PSR-4やPSR-12はさらに詳細なガイドラインを提供しています。PSRに従うことで、コードの可読性、再利用性、保守性が大幅に向上します。

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

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

　では、また！！！

タグ： Java JavaScript php PSR オープンアーキテクチャパスカルケースキャメルケースクラスメソッドプロパティ EVE

posted by ゼロから始めるシステム開発 at 17:18 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月12日

JavaScriptの世界標準規約　～プログラム研究室～

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

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

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

?Airbnb JavaScript Style Guide
概要
　Airbnbが公開したスタイルガイドで、特にES6以降のモダンなJavaScriptのベストプラクティスにフォーカスしています。広く使用されており、非常に詳細なガイドラインです。
リンク: Airbnb JavaScript Style Guide

?Google JavaScript Style Guide
概要
　Googleが開発者向けに提供しているスタイルガイド。Googleの内部で使用されており、大規模なコードベースでの一貫性と可読性を重視したスタイルを提供しています。
リンク: Google JavaScript Style Guide

?Standard JS
概要
　設定不要で、簡潔で明確なルールを提供するスタイルガイド。ESLintプラグインとしても使用可能で、ルールのカスタマイズを最小限に抑えたいプロジェクトに適しています。
リンク: Standard JS

?Prettier (Code Formatter)
概要
　Prettierはスタイルガイドというよりも、コードフォーマッタですが、これを使用することでコードフォーマットの一貫性を自動的に保つことができます。スタイルガイドと組み合わせて使われることが多いです。
リンク: Prettier

?ESLint Recommended
概要
　ESLint自体が提供している推奨スタイルガイドで、基本的なルールセットを含んでいます。プロジェクトのニーズに合わせてカスタマイズが可能で、AirbnbやGoogleのガイドと併用することもできます。
リンク: ESLint Recommended Rules

?Node.js Best Practices
概要
　Node.jsの開発者向けに特化したベストプラクティス集です。特にバックエンド開発におけるJavaScriptの使用に関する具体的なガイドラインが含まれています。
リンク: Node.js Best Practices

?Microsoft TypeScript Style Guide
概要
　TypeScriptを使ったプロジェクトに特化したMicrosoftのスタイルガイド。型を使った開発のベストプラクティスが詳述されています。
リンク: TypeScript Style Guide

?JavaScript Standard Style by Idiomatic.js
概要
　Idiomatic.jsによって提供されているスタイルガイド。可読性とコードの一貫性を重視しており、コーディングスタイルに関する一般的なベストプラクティスを網羅しています。
リンク: Idiomatic.js

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

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

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

　では、また！

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

タグ： JavaScript コーディング規約 IPA airbnb ChatGPT Copilot Gemini EVE Google php PSR フレームワークライブラリ

posted by ゼロから始めるシステム開発 at 10:54 | Comment(0) | TrackBack(0) | プログラミング研究室

2024年09月09日

抽象化モデル　～システム開発研究室～

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

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

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

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

?現状システム
　　　↓
?現状システムの抽象化
　　　↓
?新システムの抽象化
　　　↓
?新システム

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

?複雑なシステムを簡潔に表現できる
　高い抽象度のレベルでシステムを捉えることで、全体像を把握しやすくなり、複雑なシステムでも理解しやすくなります。

?設計段階での変更に柔軟に対応できる
　抽象的なレベルでの設計であれば、具体的な実装に影響を与えることなく変更を加えることができます。

?異なるステークホルダーとのコミュニケーションが円滑になる
　技術的な詳細に踏み込まない抽象的なレベルでの議論は、非技術的な背景を持つステークホルダーとのコミュニケーションを円滑にします。

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

?情報損失のリスク:
1)過度な抽象化
　抽象度が高すぎると、具体的な実装の詳細が失われ、誤解が生じる可能性があります。

2)詳細化の難しさ
　抽象的な概念を具体的な設計に落とし込む際に、新たな問題や矛盾が生じる可能性があります。

?コミュニケーションのギャップ:
1)抽象度の違い
　異なるステークホルダー間で、抽象度の認識が異なり、コミュニケーションが円滑に進まない場合があります。

2)専門用語の誤解
　抽象的な概念を表現する際に、専門用語を用いると、非専門家には理解が難しい場合があります。

?設計変更のコスト
1)上位レベルへの影響
　抽象度の高いレベルで設計を変更すると、下位のレベルにも影響が波及し、修正コストが増大する可能性があります。

?複雑なシステムへの適用
1)モデルの複雑化
　極めて複雑なシステムの場合、抽象化モデル自体が複雑になり、管理が難しくなることがあります。

?抽象化レベルの決定
1)最適なレベル
　どのレベルで抽象化するのが最適か、判断が難しい場合があります。

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

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

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

　では、また！！！

タグ： EVE IPA リバースエンジニアリングレガシーシステム情報処理安全確保支援士セキュリティ中小企業診断士 DX プロトタイプ開発 ChatGPT Gemini DFD 抽象化モデル IBM

posted by ゼロから始めるシステム開発 at 16:52 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月08日

EVE Projectだったらどうする？？？　～システム開発研究室～

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

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

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

■現状調査
大きい分類から小さい分類に分解していく(全体システム　→　システム　→　サブシステム)

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


現行ITシステムの全体把握
┗システムの粒度
┣社会システム
┣全体システム　→　?@全体システム構成図
┣機能システム　→　?A機能システム一覧
┃　　　　　　　→　?E機能システムの階層構造の確認  ←━━━━━━━━━━━━━━━━━━━┓
┃　　　　　　　→　?F機能システム間、機能システム・外部接続先間の連携の整理                ┃
┃　　　　　　　→　?G外部接続先のグルーピングと機能システムと外部接続先間の連携の集約化    ┃
┗サブシステム　→　?Bサブシステム一覧(サブシステムの論理的な整理)                          ┃
→　?Cサブシステム構成図                                                    ┃
→　?Dサブシステムの機能システム単位へのグルーピング━━━━━━━━━━━━┛

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

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

　では、また！！！

タグ：完全性リバースエンジニアリング秘密鍵公開鍵公開鍵暗号方式 ssh XSERVER AirbnbJavaScriptStyleGuide PSR-1ガイドライン php

posted by ゼロから始めるシステム開発 at 11:38 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月07日

Only you can do that!　～システム開発研究室～

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

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

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

　現在目にしているレガシーシステムはあなた以外に更改することができず、他の誰かに任せれば失敗します。社外のSEや、あなた以外のエンジニアは、ゴミ、カス、アホです。

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

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

　では、また！！！

タグ：レガシーシステム共通フレームワーク

posted by ゼロから始めるシステム開発 at 14:22 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月06日

現行ITシステムの概要仕様を復元する　～システム開発研究室～

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

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

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

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

?ソフトウェアおよびハードウェアのサポート切れによるケース
?部門最適やプログラムコピーによるスパゲティ化や肥大化によるケース
?当初作っていたときとビジネスモデルが大きく変化して追従できないケース

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

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

?システムの設計情報などの各種ドキュメント類
?ログ・稼働実績
?業務処理に関する有識者や現場の業務知識のヒアリング

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

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

?バッチ型　　　　 →　DFD
?オンライン型　　 →　業務フロー
?Web型　　　　　　→　画面編線図
?ゲートウェイ型　 →　状態遷移図

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

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

　では、また！

タグ：リバースエンジニアリング DFD スパイラル開発プロトタイプ開発ウォーターフォール開発ブラックボックス化レガシーシステム Youtube 共通フレームワーク

posted by ゼロから始めるシステム開発 at 13:07 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月02日

レガシーシステムの課題のソリューション　～システム開発研究室～

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

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

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

　レガシーシステムの課題は、企業がDX推進において、?@自社ビジネスに適合したITシステムの設計が難しいことと、?A既存システムの変革がリスクやコスト面で困難なことが挙げられます。

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


現行ITシステムの全体把握
┗システムの粒度
┣社会システム
┣全体システム　→　?@全体システム構成図
┣機能システム　→　?A機能システム一覧
┃　　　　　　　→　?E機能システムの階層構造の確認  ←━━━━━━━━━━━━━━━━━━━┓
┃　　　　　　　→　?F機能システム間、機能システム・外部接続先間の連携の整理                ┃
┃　　　　　　　→　?G外部接続先のグルーピングと機能システムと外部接続先間の連携の集約化    ┃
┗サブシステム　→　?Bサブシステム一覧(サブシステムの論理的な整理)                          ┃
→　?Cサブシステム構成図                                                    ┃
→　?Dサブシステムの機能システム単位へのグルーピング━━━━━━━━━━━━┛

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

　では、また！！！

タグ： IPA レガシーシステム ChatGPT P2M

posted by ゼロから始めるシステム開発 at 11:54 | Comment(0) | TrackBack(0) | システム開発研究室

2024年09月01日

レガシーシステムの課題とソリューション　～システム開発研究室～

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

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

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

?自社のビジネスに沿ったITシステムのあるべき姿を描くことが難しく、新たなシステム開発技術の適用方法も明確になっていないこと
?既存のITシステムをリスクとコストをかけて変革することが難しいこと

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

■1つ目の理由
1)既存ITシステムが大規模化し、マネジメントが困難になるレベルになっている
2)開発時から繰り返し機能拡張をすることで超大規模化したシステムになっている
3)一般にマネジメントは、そのITシステムの規模に対し指数関数的に困難
→　このレベルのマネジメントできるSEの数が少ない　→　経験がない？　→　失敗する例が多い
4)P2M（Program & Project Management）レベルのITシステム開発向けの考え方が確立していない
→　超大規模システムをコントロール可能な状態に分割し、全体をマネジメントする能力

　以上の状況から、多くの企業では自社の大規模化したITシステムの変革難易度の高さ故、ごまかしながら使っているのが現状である。

■2つ目の理由
1)企業のITシステムのブラックボックス化が進んでいることである
→設計書をメンテナンスしないままに変更が加えられてしまっているもの
→当初想定したアーキテクチャのポリシーに反した変更（コピー＆ペーストなど）が行われてしまっている
2)「処理」の仕様を復元することはできるが、「業務」の仕様を復元することができない
3)現行システム要件のうち必要な要件を明確にしないと、正しい構築ができない

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

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

? 現状の超大規模システムを分割し、コントロール可能な粒度に整理する（今回公開分）
　現行の超大規模システムをマネジメントが容易な規模（機能システム）に分割整理
新しい開発方式を踏まえた品質マネジメント方式（今後作成）
? 現行ITシステムの概要仕様を復元する（今回公開分）
　ブラックボックス化されているITシステムの概要仕様を復元するステップを示す
? DXの要件を満たすITシステムのあるべき姿を描く（今後作成）
　デジタル技術を活用してビジネスを変革するためにDXの要件を満たすITシステムのあるべき姿を描く
? 新しい開発方法でITシステムの変革を進める（今後作成）ビジネス要件できめられた目指す姿と優先度に従って、アジリティ、スピード、品質を向上させる考え方を用いてITシステムを変革する

以上の詳細な内容を、「 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

タグ：レガシーシステム DX

posted by ゼロから始めるシステム開発 at 10:56 | Comment(0) | TrackBack(0) | システム開発研究室