2025年6月11日、PC周辺機器の接続規格であるPCI Express(PCIe)の仕様策定団体・PCI-SIGが、「PCI Express 7.0(PCIe 7.0)」の最終仕様をリリースしました。PCIe 7.0の最終仕様ではデータレート(ビットレート)が最大128GT/s、双方向転送速度が512GB/sとなっています。
最大512GB/sの双方向転送速度でAIの帯域幅需要をサポートする「PCIe 7.0」の最終仕様がリリースされる - GIGAZINE
また、PCIe 7.0はPAM4(4値パルス振幅変調)信号とPAM4Flit(フロー制御ユニット)ベースのエンコーディングをサポートしており、電力効率が向上しているほか、以前の世代のPCIeテクノロジーとの下位互換性を維持しています。
最大512GB/sの双方向転送速度でAIの帯域幅需要をサポートする「PCIe 7.0」の最終仕様がリリースされる - GIGAZINE
新たにリリースされたPCIe 7.0の最終仕様は、16レーン構成でデータレートが最大128GT/s、片方向転送速度が256GB/s、双方向転送速度が512GB/sとなっています。データレートと転送速度は前世代であるPCIe 6.0の2倍です。
最大512GB/sの双方向転送速度でAIの帯域幅需要をサポートする「PCIe 7.0」の最終仕様がリリースされる - GIGAZINE
また、PCI-SIGは2030年以降に使用されるPCIe 8.0の策定も開始したことを発表しました。PCIe 8.0はPCIe 7.0の2倍のパフォーマンスを誇り、データレートが256GT/sに倍増し、双方向転送速度が16レーンで1TB/sに達する可能性があるとのことです。
最大512GB/sの双方向転送速度でAIの帯域幅需要をサポートする「PCIe 7.0」の最終仕様がリリースされる - GIGAZINE
⇧ 上記によると、「パフォーマンス」が倍々になっているということだが、実際にユーザーが利用したことを想定した例でベンチマークを取得して可視化して解説するなどして欲しいところですな...
「理論上」の「パフォーマンス」ではなく、実際に使用時の「パフォーマンス」がどれほどになるかが分からないと、「性能試験」の際の「指標」が定まらないので困るのよね...
ソフトウェア開発の目的って何だっけ
「ソフトウェア開発」をする目的というと、「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の公開しているドキュメントによると、
信頼性の高いソフトウェアを効率的に開発
「エンタプライズ系ソフトウェア」は、企業の業務システムや情報システム、銀 行、証券、病院、鉄道など大規模かつ社会基盤を支える情報システムなどに含まれ、それらのシステムの機能を中心となって実現するものです。
これらのソフトウェアは、それによって提供されるサービスの陰に隠れて、国民の目には見えにくいものの、国民生活や社会経済活動を支える重要なインフラとなっています。エンタプライズ系ソフトウェアでは、一般に、発注者がソフトウェアの要求を提示し、受注者がその要求に提案する受発注の契約形態によって開発されます。
⇧ とありますと。
このあたりの「本質的」な話は、「エンタープライズ系」以外の「ソフトウェア開発」にも当てはまる部分があるとは思いますが、
- 業務の効率化
に集約されると思われますと。
潤沢に時間を消費することが許されるような世界線の話であれば、「業務の効率化」は重要視されない話になるのだが、人類の歴史を振り返ると「利便性」を向上させる方向に進んで来ている気がしており、「業務の効率化」についても可能であるならば取り入れていきたいという前向きな風潮はあるように思われますと。
で、「システム化」を導入するとなると、何某かの「ソフトウェア」による「制御」が必要となることが多いように思われますと。
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の公開しているドキュメントによると、
⇧ 上記によると、「システム開発」は、大きく分けて、
- 組込み系
- エンタープライズ系
- 統合系
の3つに分類されるようだ。
一般的な「業務系」の「ソフトウェア開発」となると、「2. エンタープライズ系」に該当することになる気がしている。
「ソフトウェア開発」には、当然のことながら「コスト」がかかることから、「費用対効果」、所謂、「コストパフォーマンス」の話が絡んでくることになりますと。
「資本主義社会」の文化圏が「多数派（majority）」で生活する我々にとって、何某かの「組織」に属することが多いとは思うのだが、「組織」の維持には「コスト」がかかりますと。
で、「コスト」を上回る「利益」を得ることが出来なければ、「組織」は維持できませんと。
となると、「利益」を得ることができる方法を把握する必要があるのだが、「情報」の整理のために「フレームワーク」が利用されることがあり、
⇧ 上記サイト様によりますと、「プロダクト・ポートフォリオ・マネジメント（PPM：Product Portfolio Management）」がメジャーらしい。
「プロダクト・ポートフォリオ・マネジメント（PPM：Product Portfolio Management）」を元にしたのが、「ポートフォリオ分析（PA：Portfolio Analysis）」らしく、以下のような対応関係になるようだ。
⇧ 上図の右上（「第1象限」）の「重点維持項目」が存在することが重要であると。
⇧ とあり、相応の「コスト」をかける必要があると。
「ソフトウェア開発」の「ドメイン駆動開発（DDD：Domain Driven Development）」の文脈においても、
⇧ 重点的に「コスト」をかけるべきなのは、
- 競合他社との差別化
- 業務ロジックの複雑さ
とあり、「1. 競合他社との差別化」については、「プロダクト・ポートフォリオ・マネジメント（PPM：Product Portfolio Management）」の文脈を一部当てはめることができますと。
まぁ、「ソフトウェア開発」の「工程」との対応で考えると、
- 競合他社との差別化
- 要求分析
- 業務ロジックの複雑さ
- 要件定義
- 基本設計（外部設計）
- 詳細設計（内部設計）
- 実装
といった感じになって来るのかな？
勿論、「実装」が期待通りの「要件」を満たすことができているか「動作確認」のための「テスト」は必要なんだが...
ソフトウェア開発の工程と成果物の対応についてハッキリしないのが諸悪の根源か
で、昨今「アジャイル開発」の「スクラム」という手法で「ソフトウェア開発」をすることが主流となっているように思われるのだが、「スクラムガイド」の内容が「ファジー」過ぎるので、何の知見も持たない「開発者」が「スクラム」を実践する際に非常に困る...
このあたりの「スクラムガイド」は結局のところ、「ソフトウェア開発」において役経つ「情報」は皆無であるという話は、
⇧ 上記の記事で触れている。
で、そもそもとして、「ウォーターフォール開発」においても、
本サイトには、信頼性の高いソフトウェアを効率的に開発するための豊富なノウハウやヒントが、体系的に掲載されています。具体的には、ソフトウェア・ライフサイクル全般にわたり、発注者と受注者との間で開発ソフトウェアに関する認識の共有化を図ったり、ソフトウェア開発において「みえる」「はかれる」定量的な開発管理を可能にしたり、ソフトウェアの信頼性や生産性を高めたりするための、問題解決の手法やガイドラインなどです。
⇧ 上記にあるように、「ソフトウェア開発」の構造は「ファジー」であって、「透明性」が有って無いようなものという状態であったようだ。
つまり、
- 工程
- タスク（作業）
- 成果物
の対応関係が「ブラックボックス」化してしまっている。
結局のところ、「ソフトウェア開発」が「標準化」されていないのよね...
そして、「デジタル庁」が公開しているドキュメントによると、
情報システムの設計・開発は、大まかに捉えると以下のような流れになります。
なお、工程の名称は、事業者によって呼び方が異なります。同じ名称でも、事業者によって捉え方が異なることがあるため、注意が必要です。工程の捉え方を間違えていると、適切な時期に求めたレベルの成果物ができていなかった、というようなことが発生します。
⇧ 上記にあるように「工程」の定義が統一されていないから、「タスク（作業）」についての各々の「認識」もバラバラであり、「認識齟齬」の雨霰となるわけだ。
ここまで来れば、お分かりのように「成果物」についても「統一」されていないので、各々で「品質」が一定しないことが頻発することになる。
ただ、思うのは、「経済産業省」の管轄する「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」が、「ソフトウェア開発」の「標準化」に関する情報を公開していれば、ここまでの惨状にならなかった気はするんだが...
一部の「スーパーエンジニア」は別として、「認識齟齬」を無くす仕組みを導入するには、開発チーム内で「情報」の解釈を「共有」できるように「標準化」が必要なのは納得できることだと思う。
欲を言えば、複数の「ベンダー」が関係してくるような「プロジェクト」レベルにおいて、「ソフトウェア開発」の構造を「標準化」できるのが望ましいですと。
要件定義業務と機能一覧のフォーマットの雛形が欲しいというか標準化して欲しいのだが...
で、本題。
結論としては、
といった、日本のITに関する課題を解決することを主たる目的として設立されたであろう組織においても、
- 業務
- 機能
の対応を表す「業務機能一覧」のフォーマットの雛形に関する情報が公開してくれていない...
「デジタル庁」が公開しているドキュメントでも、
A. 機能に関する事項
「機能」とは、情報システムが外部に価値を提供する一連の動作のまとまりのことです。
基本的に「入力」・「演算(処理)」・「出力」で構成されます。ボタンを押したら画面に情報が表示されるのも、夜間にバッチ処理で帳票が大量に印刷されるのも、それぞれ１つの機能です。
情報システムが提供する形は様々ですが、それらを「機能」として一覧化して整理するために用いるのが、「情報システム機能一覧」と呼ばれるドキュメントです。
「情報システム機能一覧」は、業務で求められる要件を情報システムで実現するために何が必要かを「機能」で表現したものであり、その概要や処理方式等を併せて記載し、情報システムの設計・開発を行う事業者に、情報システムに求められる要件を正しく伝えます。
⇧「業務」との対応が分からないのよね...
「処理方式」の値の全量も説明が無いですし、無駄にページ数の多いPDFで肝心の情報が抜け漏れしている何とも中途半端なドキュメントになってしまっていて、誠に遺憾である...
「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」の公開しているドキュメントだと、
システム化機能一覧表.pdf
⇧ とあり、「デジタル庁」が公開しているドキュメントよりは、若干、まともな感じで整理してるのかもしらんが、結局のところ、
- 新業務フロー
- 詳細業務フロー
- 業務
- 機能
- 処理区分
の分類のルールなどがサッパリ分からない...
用語についても、
- IPA
- 処理区分
- リアル
- バッチ
- ?
- 処理区分
- デジタル庁
- 処理方式
- オンライン
- ?
- 処理方式
といった感じでバラバラなのよね...
しかも、「処理区分」乃至は「処理方式」の値の全量が不明瞭というね...
中途半端な形であるというのは「デジタル庁」が公開しているドキュメントと変わらないところが誠に遺憾である...
分類のルールをハッキリ定義した情報を公開してくれていれば、「ソフトウェア開発」の現場もカオスになることを避けられる可能性はあったとは思うのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
