気象庁と国土交通省は14日、危険な大雨などの際に早期に避難してもらうため、新たな防災気象情報を5月28日から提供すると発表した。大雨や河川氾濫など4種類の災害について、新設の「危険警報」を含む5段階の警戒レベルに統一した。
5月28日から新たな防災気象情報を提供 5段階の警戒レベルに統一 | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
これまでの防災気象情報は、災害ごとの警報や警戒情報の表記が複雑で、危険度や切迫度、取るべき行動が分りにくいとの指摘があった。気象庁の「防災気象情報に関する検討会」の提言を受け、5段階の警戒レベルに応じた避難の判断をしやすくしたという。
5月28日から新たな防災気象情報を提供 5段階の警戒レベルに統一 | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
住民に対する避難情報は、自治体が判断して出す仕組みに変わりはない。自治体は新たな防災気象情報を参考に「緊急安全確保」や「避難指示」などを出すことになる。
5月28日から新たな防災気象情報を提供 5段階の警戒レベルに統一 | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
気象庁は大雨の頻度が高まる6月までの運用開始を目指してきた。同庁によると、改正気象業務法などが施行される5月29日が正式な運用開始日としているが、28日午後から新たな形式で情報を発表するという。自治体や住民に新たな防災気象情報の周知徹底を図る方針だ。
5月28日から新たな防災気象情報を提供 5段階の警戒レベルに統一 | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
警戒レベルごとの取るべき行動と災害発生に至る時間推移のイメージ（気象庁の資料から）
5月28日から新たな防災気象情報を提供 5段階の警戒レベルに統一 | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
⇧ 上記の図だと、「災害発生」時は「災害」の規模に依らず一律「レベル 5」の扱いということになってしまうのだが...
「雨量」などが絡む「災害」については、ほぼほぼ「時系列」で「危険度」が変化していくと思われるのだが、
- 「河川の氾濫」に因る「災害発生」の予測
- 対応するレベルの割り当て
の見積もりの精度をどのように担保するのかは気になりますな...
- 地形
- 雨量
共に「変化」していく気はするので、
- 災害発生前
- 災害発生
- 災害発生後
の大まかな「時系列」の分類をした場合、「災害発生後」に「危険度」が上がっていくケースもあると思われるのだが、いまいち、「時系列」と「レベル」感の対応が分からないのですよ...
そもそも、
- 土石流
- がけ崩れ
- 地すべり
といったような「土砂災害」は、「災害発生」の予兆を見極めるのが困難と思われるので、「時系列」と「レベル」感の対応が「ファジー」にならざるを得ない気がしてしまいますが...
適切な「レベル」の判断が可能なように「仕組化」されているのかは気になりますな...
つまり
『これまでの防災気象情報は、災害ごとの警報や警戒情報の表記が複雑で、危険度や切迫度、取るべき行動が分りにくいとの指摘があった。』
という「課題」を解決できているのかが分からない...
成果物のフォーマットがファジーだとレビューの負担も増える気がするが...
相も変わらず、「ソフトウェア開発」には課題が多いと思われるのですが、
⇧ 上記の書籍の『第6章 ステークホルダー管理』の「COLUMN コラム：合意形成の落とし穴を知る」の話で、「製造業」の「業務システム」の話で、「データ」の「項目」の内容が「業務領域」によって異なるとあり、「ソフトウェア開発」において、
- フェーズ
- タスク
- 成果物
との関係が気になったので、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
📌 ソフトウェア開発フェーズとデータ設計と成果物
| 開発フェーズ | タスク | 概念対応（対策） | 詳細 | 成果物 |
|---|---|---|---|---|
| 1. 要件定義 (Requirements Definition) | データ項目の意味を確認する | コンテキスト依存性 | 各コンテキスト（部門やシステム）でのデータ項目の意味を文書化し、システム全体の要件を定義します。 | 要件定義書 |
| 異なるコンテキストを識別する | コンテキストマッピング | 異なる部門やシステムにおけるデータ項目の意味や役割を示すマップを作成。コンテキスト間の差異を明確化します。 | コンテキストマップ | |
| データ要件を文書化する | データ項目の解釈の多様性 | 各データ項目がどのように解釈され、使用されるかを詳細に文書化します。 | データ項目定義書 | |
| 2. 設計 (Design) | データモデルの設計 | コンテキスト固有の意味 | 各コンテキストに対応したデータモデルを設計します。ER図やクラス図などで表現されることが多いです。 | データモデル図 |
| コンテキスト別の変換ルールを設計する | コンテキストマッピング | 異なるコンテキスト間でデータの意味が異なる場合、変換ルールを定義します。これに基づいてデータの変換が行われます。 | 変換ルール定義書 | |
| エイリアスや名前空間を使用する | コンテキスト依存性 | 異なるコンテキストで使用するエイリアスや名前空間を表にまとめ、データ項目の区別を明確にします。 | データ項目マッピング表 | |
| データ辞書を作成する | データの意味論的変化 | 各データ項目の意味、形式、用途、解釈に関する情報を詳細に記載した辞書を作成します。 | データ辞書 | |
| API設計（コンテキスト別） | コンテキスト固有の意味 | 異なるコンテキストに応じてAPIを設計し、その仕様書を作成します。これにはエンドポイント、リクエスト/レスポンスなどが含まれます。 | API仕様書 | |
| 3. 実装 (Implementation) | データ変換ロジックを実装する | データのコンテキスト変換 | 設計した変換ルールに基づいて、データの変換ロジックをコードとして実装します。 | 変換ロジック実装コード |
| 変換ルールに基づくデータ処理を実装する | コンテキストマッピング | 異なるコンテキスト間でのデータ変換を実際に処理するコードを実装します。 | 変換処理コード | |
| エイリアスや名前空間の実装 | コンテキスト依存性 | 設計段階で決定したエイリアスや名前空間をプログラムコードに実装します。 | コード（データ項目名） | |
| コンテキストごとのインターフェースを実装する | コンテキスト固有の意味 | コンテキストに応じたインターフェース（API、サービス）を実装します。 | インターフェースコード | |
| 4. テスト (Testing) | データの変換が正しく行われるか確認する | データのコンテキスト変換 | 変換ルールが正しく適用されるかをテストケースを作成し、テストを実行。テストレポートを作成し、変換の正確性を確認します。 | テストケース/テストレポート |
| コンテキストごとの解釈が一致しているかテストする | データ項目の解釈の多様性 | 異なるシステムや部門間で、データ項目の解釈が正確に一致しているかをテストします。 | テストケース/テストレポート | |
| データモデルが意図通りに動作するか確認する | コンテキスト固有の意味 | 設計したデータモデルが正しく動作しているかを確認するテストケースを作成し、実行します。 | テストケース/テストレポート | |
| システム間でのデータインターフェースの整合性を確認する | データ項目の解釈の多様性 | システム間でデータが正しく送受信され、解釈に誤りがないかをテストします。 | インターフェーステスト結果 | |
| 5. 運用・保守 (Operation & Maintenance) | 運用中のデータ整合性を監視する | ドメイン間のデータ整合性 | システム運用中のデータの整合性を監視し、問題が発生した場合はレポートとしてまとめ、対応策を講じます。 | 運用監視レポート |
| データガバナンス方針に従ってデータを管理する | ドメイン間のデータ整合性 | 運用中に発生するデータの不整合を監視し、ガバナンス方針に基づいてデータ管理を行った結果をレポートとしてまとめます。 | データガバナンスレポート | |
| データ項目の解釈を定期的にレビューし更新する | コンテキスト依存性、意味論的変化 | 時間の経過とともに変更されたデータ項目の解釈を反映させた更新履歴を管理し、定期的にデータ辞書やマッピング表を更新します。 | データ辞書/マッピング表 更新履歴 |
✅ 解説
-
要件定義フェーズ：このフェーズで作成する主要な成果物は「要件定義書」や「データ項目定義書」です。データ項目が異なるコンテキストでどう解釈されるかを確認し、文書化します。
-
設計フェーズ：設計段階で作成する成果物には「データモデル図」や「API仕様書」があります。コンテキストごとに異なるデータの意味を正しく扱えるように設計します。
-
実装フェーズ：このフェーズでは「変換ロジック実装コード」や「インターフェースコード」などのコード成果物が作成され、設計で決まった仕様が実際に反映されます。
-
テストフェーズ：テストケースやテストレポートが作成され、実際にシステムが意図通りに動作するかが確認されます。特に、コンテキストごとのデータ解釈や変換のテストが重要です。
-
運用・保守フェーズ：運用監視レポートやデータガバナンスレポートが作成され、システムの運用中に発生するデータの整合性やガバナンスの問題を監視・対応します。
⇧ 解説で「変換ロジック実装コード」や「インターフェースコード」などがどんなものなのか説明が無い状態で唐突に出てきており、「情報」の「分類」が杜撰であることは、誠に遺憾であるのだが、「AI」の限界といったところでしょうかね...
で、結局のところ、「ソフトウェア開発」に限った話では無いとは思いますが、「成果物」が「ドキュメント」の場合に、「フォーマット」について整理されていないので、必要な「情報」の「分類」、「整理」を実施するところからしなければならなくなり、「暗中模索」な状況に陥ること、あるあるですと。
一般的な「ソフトウェア開発」において、「ドキュメント」の「項目」の「粒度」や「内容」なども整理されていないですしな...
要するに、「本質的」な「情報」の検討に取り掛かるまでに多大な労力を費やすことになってしまう状況でありますと...
まぁ、そもそも、
⇧ 一般的な「ソフトウェア開発」の
- フェーズ
- タスク
- 成果物
についての「情報」が「錯綜」しているので、致し方ないのかもしれないが...
手前味噌で恐縮ですが、
⇧ 上記の記事の時に触れたのだが、英語圏においては、
- 要求
- 要件
は「requirements」という同じ単語になるらしい。
ややこしいのが、
⇧ 上記サイト様にありますように、
- 要求
- 要件
は意味合いが異なるということですかね...
英語圏の人は、「文章」の前後の「文脈」などから、
- 要求
- 要件
のどちらについての話をしているのかについて判断しているんですかね？
話が脱線しましたが、「ドキュメント」の「フォーマット」が「ファジー」だと、余計な部分に「脳」の「リソース」が費やされることになり、「レビュー」の負担も増える気がしますと...
とは言え、「ソフトウェア開発」の「情報」が整理されていないので、「開発プロジェクト」毎に「独自」の「ルール」を定義するしか無さそうであり、「ドキュメント」を読み解く「認知負荷」は高くなるという悪循環は続くわけですな...
このあたりの必要な「情報」が整理されていない話についても、
⇧ 上記の記事で触れておりましたな...
つまり、「開発プロジェクト」が変わる度に、「開発プロジェクト」毎に「独自」の「ルール」を定義している割合が多いと、「独自」の「ルール」を理解するための「コスト」が発生することになりますと。
そもそも、
- 十人十色（じゅうにんといろ）
- 百人百様（ひゃくにんひゃくよう）
といった言葉があるように、人それぞれ経験してきた事柄は異なるので、抱える「認知バイアス」も様々であるのだから、統一できる「ルール」は統一して欲しい気はする。
まぁ、それが出来ていないから、多くの「開発プロジェクト」において「認識齟齬」の雨霰が日常茶飯事といった状況が常態化しているのだとは思いますが...
面倒かもしれないが、
ダブル・ミーニング（英語: double meaning）とは、2つ以上の解釈が可能な意味づけのこと。詩などで、一つの語に2つ以上の意味をもたせること。日本語では掛詞（かけことば）と（伝統的に）呼ばれている
⇧ 上記のような状態にある「用語」が無いかは確認して、「可視化」しておかないと、「トラブル」に発展する「リスク」を潜在化させることになり得ますかな...
冒頭の書籍の話の例で言うと、
| No | ユーザー | システム |
|---|---|---|
| 1 | 製造部門 | 生産管理システム |
| 2 | 財務部門 | 財務会計システム |
で、
- 製造日
- 製造数量
- 直接材料費
の「データ項目」の意味が異なるとあり、
- 製造業の一般的な話
- 製造業の製造物のカテゴリ毎に異なる話
- 製造業の企業毎に異なる話
などの「粒度」感が分からないのだが、このあたりの「情報」が共有されて「可視化」がされていないと、「機能開発」や「データ分析」などで支障が出ること間違いない...
「ゴール」を定義するための「インプット」としての「情報」がハッキリしないと、「ゴール」が見当違いなものになる「リスク」が高くなりますと。
結局のところ、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記の話に行き着くのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
