※当サイトの記事には、広告・プロモーションが含まれます。

ドメイン駆動設計とかルール駆動開発とかあれど、結局のところ業務のタスクの把握が重要よね

gigazine.net

オーストリアの連邦経済エネルギー観光省(BMWET)が、アメリカの企業であるMicrosoftから脱却してドイツに拠点を置くNextcloudの製品に乗り換えることを明らかにしました。Nextcloudはオープンソースソフトウェアであることが最大の特徴です。

オーストリア省庁がMicrosoftから脱却しオープンソース代替品のNextcloudを採用 - GIGAZINE

同じオーストリアでは、オーストリア軍がMicrosoft OfficeからオープンソースLibreOffice切り替える動きがあります。目的は、機密性の高い軍のデータを外国の組織がアクセスできる外部クラウドではなく自国のサーバーに保管することにより、デジタル主権を維持することです。

オーストリア省庁がMicrosoftから脱却しオープンソース代替品のNextcloudを採用 - GIGAZINE

オランダに拠点を置く国際刑事裁判所は、Microsoft Officeからオープンソースの「openDesk」に切り替える予定。背景には、国際刑事裁判所に対するアメリカ政府の圧力があったと報じられています。

オーストリア省庁がMicrosoftから脱却しオープンソース代替品のNextcloudを採用 - GIGAZINE

⇧ 考えてみると、

  1. AWSAmazon Web Services
  2. Microsoft Azure(旧 Windows Azure
  3. Google Cloud(旧 GCPGoogle Cloud Platform)
  4. OCI(Oracle Cloud Infrastructure)

といった「クラウドサービスプロバイダー」は、全て「アメリカ」が発祥なのよね...

国内のデータを厳格に保護するとなった場合、

  1. オンプレミス環境
  2. 国内クラウドサービスプロバイダー環境

などへの切り替えが必要になるとは思われるのだが、「オンプレミス環境」は、即時の「スケールアウト」などが難しいのよな...

ドメイン駆動設計とかルール駆動開発とかあれど、結局のところ業務のタスクの把握が重要よね

ネットの情報を漁っていたところ、

qiita.com

rheb.hatenablog.com

⇧ 上記サイト様で「ルール駆動開発」なるものの存在を知りました。

で、「ソフトウェア開発」の手法としては、「ドメイン駆動設計(DDD:Domain Driven Design)」とかもあるのだが、いずれにしろ、「業務」の「タスク」の把握が重要という気はしますと。

よく「製造業」の「ソフトウェア」を開発するような「プロジェクト」だと、実際に現場に赴いて「業務」についてヒアリングするという話を聞きますが、然もありなん。

そうなってくると、最低限、

  1. 業務フロー
    1. 登場人物
    2. 業務タスク
    3. I/O(Input/Output)
    4. 関連する業務タスク(業務の依存関係)

あたりが把握できていないと厳しいですと。

必要な情報が把握できていなければ、「ソフトウェア」の要とも言っても過言ではない「データモデリング」も上手くいかないですからな...

このあたりは、「業務要求定義」の領域の話になって来る気がするので、「独立行政法人情報処理推進機構(英: Information-technology Promotion Agency, Japan、略称: IPA)」の公開しているドキュメントによると、

www.ipa.go.jp

⇧「ビジネス要求定義」の「現状把握」に該当するんかな?

同じく、「独立行政法人情報処理推進機構(英: Information-technology Promotion Agency, Japan、略称: IPA)」の公開しているドキュメントによると、

www.ipa.go.jp

⇧ 上記の開発フローで言うところの、「利害関係者要件」に「業務要求定義」は含まれるんかな?

まぁ、「独立行政法人情報処理推進機構(英: Information-technology Promotion Agency, Japan、略称: IPA)」のドキュメントが整理されていなさ過ぎて、情報が錯綜していて非常に困るのだが...

ネットの情報を漁っていたところ、

mag.executive.itmedia.co.jp

⇧ 上記サイト様で紹介されている「ビジネスアナリシス知識体系ガイド (BABOK:Business Analysis Body Of Knowledge)」によると、「要求」は分類されているということらしい。

とりあえず、「ソフトウェア開発」のフローについては、標準化して欲しいよね...

一度、「作業分解構造(WBS:Work Breakdown Structure)」のようなもので、開発ですべき作業を「可視化」して欲しいのよね...

ちなみに、「アジャイル開発」の「スクラム」だと、「透明性」が謳われる割には、具体的な方法についての指標が示されていないので、非効率極まりないのよ...

最近、

www.publickey1.jp

GitHubは、日本時間10月29日未明から開催中の年次イベント「GitHub Universe 2025」で、Visual Studio CodeにおけるGitHub Copilotの新機能として、AIが仕様作成を支援する「Planモード」を発表しました。

VS Code、Copilotが仕様作成を支援する「Planモード」が追加 - Publickey

⇧ 上記の「機能」について発表があったらしいのだが、そもそもの開発フローが整理されていないと、結局のところ、作業の抜け漏れが発生しますからなぁ...

毎度モヤモヤ感が半端ない…

今回はこのへんで。