©2025 fusions corporation One-stop partner, empowering your management systems A workplace for your business management, supported by ONE software ソフトウェア・デザインに向かおう 世界を（ちょっとだけ）変えるソフトウェアを目指して 株式会社フュージョンズ CEO 杉本啓 PHPカンファレンス関西 2025 2025.7.19 

©2025 fusions corporation 今日お話しすること 1. デザインと設計 デザイン・設計は分離できない。ひとつのデザインの２つの顔にすぎない 2. アーキテクチャ デザインと設計の基礎には、アーキテクチャがある。アーキテクチャは、道具の構造のデザインではな く、道具と状況の関係性のデザインである 3. DX＝アーキテクチャの変化 DXとは、ITが可能にする新たなアーキテクチャが旧来のアーキテクチャを置換していく過程である 4. DXにおけるエンジニアの役割 DXはテクノロジープッシュだから、エンジニアはDXに関して重要な位置にいる。ただし、アーキテク チャをデザインするためにエンジニアはドメインを知る必要がある 5. ドメインに向かう道 エンジニアがドメインに向かう上で、入りやすいパターンがある 6. 私たちはなぜソフトウェアを作るのか アーキテクチャを通じて我々はドメインにつながり事業と社会につながる。事業や社会とのつながりを 通じて、我々が作るソフトウェアの「意味」が了解される 

©2025 fusions corporation Who is this guy? • 経営管理基盤ソフトウェア「fusion_place」を作って売っています。 https://fusions.co.jp • fusion_place は、経営管理ドメインに特化したメタプログラミングシステム： • 独自の多次元データベースエンジンとDBデザインツール • 独自の式言語 • 独自の画面／レポートデザインツール • 独自の Excel 連携ツール • 独自の Web-API • 会計事務所系コンサルティング会社（アクセンチュア／アンダーセン）出身 • 生産管理/会計系基幹システム構築 (スクラッチ開発, SAP R/3等) ～ 会計領域の 制度設計・業務改革 ～ パッケージソフト（連結会計）開発など • 現在は、株式会社フュージョンズのCEO 兼 プログラマ。 実はアーキテクチャの本 

©2025 fusions corporation デザインと設計 ： 一般認識 ありがちな認識： 設計には、ユーザー視点の設計と、構造視点の設計の２つがある （広義の） 設計＝デザイン （狭義の） 設計 （狭義の） デザイン 外観・意匠 ・使い勝手 ・美しさ 内部構造 ・メンテナンス性 ・変更容易性 関心事 担い手（現況） エンジニア ユーザー、 あるいはその代理 としての デザイナ 内部設計 外部設計？ 伝統的設計概念 要件 （したいこと） ユーザー 

©2025 fusions corporation デザインと設計：両者はひとつ ー 使う視点 ー ー 設計／デザイン ー 古代ローマ水道のアーチ橋 ー 作る視点 ー 機能性： 標高差の克服 景観性： 優美である 安定性・耐久性： 自重で安定する 手に入る素材： 地元で採れる 石材で作れる 施工： 当時可能な工法 溶接等不要 アーチという構造が、使う視点から導出されたわけではない。 アーチを組めば崩れないという気づき――作る視点――が先行し、 使う側に受け容れられている―――テクノロジープッシュ 適用範囲： 様々な地形に適用 裏付け知識： 構造力学 2025.7.13 Copilot かく 

©2025 fusions corporation デザインと設計：両者はひとつ ー 使う視点 ー ー 設計／デザイン ー 分散型リポジトリ ー 作る視点 ー 機能性： バージョン管理 利便性： 並列作業可能 高速 ローカルとパブリック の調和 手に入る素材： 低コストの一方向ハッシュ関数 圧縮技術 高速化に関する思い付き： ファイルの履歴ではなく コミットの履歴を記録する 適用範囲： ファイル管理ならなんでも 裏付け知識： ファイルシステム コンテンツアドレッサブル ストレージ（CAS) 一方向ハッシュ関数により、リポジトリを分散させてもコミットが衝突せず、 分散したストレージ上の複数のコピーの同一性をCASで保証できる という気づき――作る視点――が先行し、 使う側に受け容れられている―――テクノロジープッシュ 

©2025 fusions corporation デザインと設計： 両者はひとつ 内部設計・外部設計という２つの独立した設計があるわけではない。 ソフトウェアというひとつの「道具」を、ユーザーの視点からみた見方と、開発者の視点から見 た見方があるだけである。 ユーザー ソフトウェア という「道具」 ドメイン（適用領域） 開発者 内部設計メガネ 外部設計メガネ 人為的な線引き 

©2025 fusions corporation デザインと設計 • ひとつのモノの中で、使う視点のデザインと作る視点の設計がいつも切り分けられるわけでは ない。もっとも基本的なデザインにおいては、両者は表裏一体である • 切り分けられるように見えるのは、基本的な「デザイン＝設計」がすでに決まっていて、その 枠組みの中でユーザー視点のデザインと構造的な設計を分担しているから 例. 「アーチ」で橋を作ることは決まった上で、意匠の設計と構造の設計が分担される • 基本的な「デザイン＝設計」は、「こうやれば作れる」という視点から伝統的に決まっていて、 明示的な検討対象と認識されない場合も多い 例. 「アーチ」で橋を作ることはローマ人にとって当たり前 

©2025 fusions corporation アーキテクチャ ―見落とされている要素ー 使う視点のデザイン・作る視点の設計に先行して、置かれた状況に対する見立てと構えがある （広義の） 設計＝デザイン （狭義の） 設計 （狭義の） デザイン 外観・意匠 ・使い勝手 ・美しさ 内部構造 ・メンテナンス性 ・変更容易性 関心事 担い手（現況） エンジニア ユーザー、 あるいはその代 理としての デザイナ 要件 （したいこと） ユーザー アーキテク チャ 状況に対する見立てと構え ・技術の利用可能性 ・問題の見立て アーチ橋や 分散型リポジトリ 「見立て」という言葉は @iteman 氏の発案です。 

©2025 fusions corporation アーキテクチャはストラクチャではない アーキテクチャはソフトウェアの大構造とみなされがちだが、本当は、構造自体ではないと思う。 問題領域と解決領域をつらぬく問題の見立てと解決の枠組みがアーキテクチャ ソフトウェアの ビルド （解決領域） タスク指向 Ant アーティファ クト指向 Maven （問題領域） 実現例 アーキテクチャは、モジュール分割など構造の設計に先行している 見立てと枠組み （アーキテクチャ） 「見立て」という言葉は @iteman 氏の発案です。 

©2025 fusions corporation DX＝アーキテクチャの変化 現在進行している「DX」は、ITが可能にする新しいアーキテクチャによる、旧来のアーキテク チャの置換である。 古いアーキテクチャ 新しいアーキテクチャ • ワークシート用紙 • スプレッドシート • 部品調達用の シングルレベル部品表 • 工程（作り方）を加味した マルチレベル部品表 • 発注点方式 • 在庫推移監視方式（先行手配） • 分類にもとづくディレクトリ • 検索エンジン アーキテクチャは、ドメインにおける問題を解決する際にひとびとが適用する 見立てと構え（＝形、フォーメーション）。 それ自体がソリューションではない • 伝票会計 • 伝票レス会計（ダイレクトインプット） • 事前集計 • 検索時集計 次頁 事務計算 部材発注 会計記録 情報検索 多次元集計処理 ドメイン 

©2025 fusions corporation （実践例）多次元集計 経営管理分野では、組織、商品、顧客など様々な軸（＝次元）の組み合わせで、かつ、それぞれ多 階層にわたるデータ集計―多次元集計―が必要である。 多次元 データ集計 （解決領域） 事前集計 モデル 大手の製品 リアルタイム 集計 モデル fusion_place （問題領域） 実現例 見立てと構え （アーキテクチャ） • 重複集計あり・加算以外も可 • 複雑なので、ある程度事前集 計せざるを得ない • 集計階層が深いとデータの組 み合わせ爆発が起きる • よって大量データを持てない • 重複集計なし・加算のみ • 単純なので、リアルタイム集 計で十分 • データ爆発は起きない • 大量データを持てる • 特殊なビットマップインデッ クスと集計範囲絞り込みアル ゴリズム 

©2025 fusions corporation （実践例）現場粒度での予実管理 従来の経営管理システムは財務経理部門の支援が中心でした。未来を予測し制御するためには、 現場の事業活動と予実管理を結びつけ、現場での活動にフィットした案件単位での予算管理を支 援することが重要です。大量データを扱えるリアルタイム集計モデルがそれを可能にします 現場で自由 に案件登録 残月見込を 入力／更新 数値欄をクリックし 伝票明細にドリルダウン 摘要を元に案件番号を付与 フュージョンズ営業資料 から抜粋（２ページ） 

©2025 fusions corporation （実践例）アーキテクチャが変わればドメインも変わる 事業活動は現場で起きます。現場の自律的な経営管理をITで支援し、事業最前線のひとびとの知 識とデータを経営トップにまでつなぐことで、組織全体の経営管理力が高まる。これが現場⼒を 喚起する経営管理の基本的な考えです。 財 務 経 理 現場 従来の経営管理システム 財務経理自身の 業務効率化が主眼 財務会計色の濃い サマリーデータを収集 予算などの入力が役割 入力データの作成プロセ スはスコープ外 要求 提供 財 務 経 理 現場 現場力を喚起する経営管理システム 財務経理自身の 業務効率化は当然 サマリーに加えて 現場活動にフィットした 詳細データを提供／収集 事業部門の自律的 経営管理の促進／支援 要求＆提供 提供 部署・子会社 経 営 層 

©2025 fusions corporation DXでのエンジニアの役割 アーキテクチャの創出はテクノロジープッシュだから、エンジニアはDXに関して重要な位置にい る。ただし、アーキテクチャをデザインするためにエンジニアはドメインを深く知る必要がある 新しいアーキテクチャ 技術的な可能性の検討と、ドメインへの身体的な理解を踏まえた検証 長期サイクルの実地適用と短期サイクルの脳内シミュレーションの双方を 高回転で繰り返す中で、新しいアーキテクチャが生まれる ドメイン（適用領域） での適用 技術知識 機会 評価 

©2025 fusions corporation ドメインに向かう道 ドメインの問題に口を出すことには、エンジニアとして最初はためらいがあります。ためらいを 克服して進んでいくには、仕掛けが大事です ① 現実のプロジェクトでのユーザー 側責任領域への踏み込み ② 外部と内部の境界上の設計 （テーブル駆動方式） ③ 開発ツールの作成 ④ 個人的ソフトウェア作品 どのドメインを選ぶかは、実はそれほ ど重要ではありません。 あるドメインで培った設計力は他のド メインでも役立ちます。 重要なのは、使う視点から道具を見る 力を身につけることです。 しかし、まずは、いずれかのドメイン に身を浸さなければ、そうした力は身 につきづらいのです。 《仕掛け》 次頁 

©2025 fusions corporation テーブル駆動方式： 支払期日決定処理 「テーブル駆動方式」は、ビジネス・ルール、すなわち、業務上のさまざまな判断のための規則 をデータテーブルとして表現する方式です public static LocalDate 支払期日決定(LocalDate 納品日, 支払条件 支払条件) { return switch (支払条件) { case 納品後7日以内 -> 納品日.plus(7, DAYS); case 納品後2週間以内 -> 納品日.plus(14, DAYS); case 納品月末払 -> 月末日(納品日); case 月末締翌月末払 -> 月末日(納品日.plus(1, MONTHS)); case 月末締翌々月末払 -> 月末日(納品日.plus(2, MONTHS)); case 二十日締翌月二十日払 -> (納品日.getDayOfMonth() <= 20 ? 納品日.plus(1, MONTHS) : 納品日.plus(2, MONTHS)) .withDayOfMonth(20); }; } 「データモデリングでドメインを駆動する」p.165-171 非テーブル駆動のコード例 

©2025 fusions corporation テーブル駆動方式： 支払期日決定処理 前頁のコードの裏にあるビジネスルールは、下図のようなデータテーブルで表現可能です 属性 締め条件 支払リードタイム 支払条件 期日指定方法 指定日付 期間単位 期間数 納品後７日以内 即日 ー 日 7 納品後２週間以内 即日 ー 日 14 納品月末払 月末日 ー 月 0 月末締翌月末払 月末日 ー 月 1 月末締翌々月末払 月末日 ー 月 2 二十日締翌月二十日払 指定日付 20日 月 1 

©2025 fusions corporation テーブル駆動方式： 支払期日決定処理 データテーブルは列挙型（やDBのテーブル）で実装できます（だから「テーブル駆動」方式） public enum 支払条件 { 納品後7日以内 ( 期日指定方法.即日, null, 期間単位.日, 7), 納品後2週間以内 ( 期日指定方法.即日, null, 期間単位.日, 14), 納品月末払 ( 期日指定方法.月末日, null, 期間単位.月, 0), 月末締翌月末払 ( 期日指定方法.月末日, null, 期間単位.月, 1), 月末締翌々月末払 ( 期日指定方法.月末日, null, 期間単位.月, 2), 二十日締翌月二十日払 ( 期日指定方法.指定日付, 20, 期間単位.月, 1); final 期日指定方法 締め_期日指定方法; final Integer 締め_指定日付; final 期間単位 支払LT_期間単位; final Integer 支払LT_期間数; … } // 期日指定方法と期間単位は別の列挙型です。コードは割愛しています。 Javaですみません m(_ _)m 

©2025 fusions corporation テーブル駆動方式： 支払期日決定処理 テーブル駆動方式のロジックは業務上の処理パターン（支払条件など）に依存せず、それを分解 した要素（締め条件や支払リードタイム）に依存します public static LocalDate 支払期日決定(LocalDate 納品日, 支払条件 支払条件) { LocalDate 適用締め日 = 適用締め日決定(納品日, 支払条件.締め_期日指定方法, 支払条件.締め_指定日付); LocalDate 起算日 = 適用締め日.plus(1, ChronoUnit.DAYS); return 起算日 .plus(支払条件.支払LT_期間数, 支払条件.支払LT_期間単位.chronoUnit) .minus(1, ChronoUnit.DAYS); } // 起算日に1を足し、そのリードタイム日数後の日から1を引くのは、月末日をうまく扱うためです 

©2025 fusions corporation テーブル駆動方式： 支払期日決定処理 通常のロジックとテーブル駆動方式では、ロジック分割の軸が直交しています 属性 締め条件 支払リードタイム 支払条件 期日指定方法 指定日付 期間単位 期間数 納品後７日以内 即日 ー 日 7 納品後２週間以内 即日 ー 日 14 納品月末払 月末日 ー 月 0 月末締翌月末払 月末日 ー 月 1 月末締翌々月末払 月末日 ー 月 2 二十日締翌月二十日払 指定日付 20日 月 1 通 常 の ロ ジ ッ ク 分 割 の 軸 テーブル駆動方式でのロジック分割の軸 

©2025 fusions corporation テーブル駆動方式： 支払期日決定処理 テーブル駆動方式はシンプルですが、「アーキテクチャ」と言えます • 問題に対する「見立て」「枠組み」を表現している • 内部設計から生まれ、外部設計ともなり得る • 内部設計上のメリットがある ⚫ コードの見通しが良くなる ⚫ 条件分岐が減ってテストが容易になる • 外部設計上のメリットもある ⚫ ユーザーが自由に処理パターンを追加できる ⚫ 処理内容の見通しが良くなる • 作り手であるエンジニアがみずからの裁 量でデザインででき、適用することで、 テスタビリティが高まるなど直接的なメ リットがある • 外部設計として公開することで、ユー ザーのシステム理解も深まる。またユー ザーにとってシステムが便利になる • エンジニアの「ドメイン観」を示すこと でユーザーとの対話の端緒を開く ドメイン駆動方式は、 エンジニアがアーキテクチャに取り組むための エントリーポイントとして役立つ 

©2025 fusions corporation 私たちはなぜソフトウェアを作るのか ソフトウェアは道具です。私たちが作る道具は、使われることによってドメインを変え、社会を 変えていきます ローマ水道橋 Git Maven fusion_place アーチ構造 分散型リポジトリ アーティファクト 指向のビルド構造 多次元での検索時 集計モデル 空前の規模の水道網の建設を可能にし、潤沢な水を都 市にもたらして衛生的で快適な生活を実現した 開発活動をコンフリクトなく並列的に進められるよう になり、オープンソースだけでなくソフトウェア開発 全般を促進している アーティファクトという概念を導入することで、ライブラリ の共有とバージョン管理を可能にし（Mavenリポジトリ）、 ビルドを超えてソフトウェアの再利用を下支えしている 多次元DBで大量の詳細データを扱うことを可能にし、 経営管理システムが経理・企画のみならず現場部門に 浸透していく端緒を作った 事例 コアアーキテクチャ ドメインと社会にもたらす変化 

©2025 fusions corporation 私たちはなぜソフトウェアを作るのか アーキテクチャとは、道具であるソフトウェアを、それ自体としてではなくそれが使われる環境 すなわちドメインとの関係性の中に置いて眺める「見方」です。そして、ドメインは、ビジネス や社会を含むさらに広い環境に私たちの仕事を接続してくれる通路です。 社会 ビジネス 業務機能 プロセス 情報処理 ソフト ウェア 技術 アーキテクチャの視野 アーキテクチュラルな見方をして初めて、ソフトウェアの存在理由が明らかになり、私たちの仕事の 意味が了解されてきます。 フレデリック・ブルックスの言葉通り、ソフトウェアを作る仕事には、本質的な複雑さが含まれてい ます。私たちの仕事の難しさはこうした本質的複雑さに根差していて、除去できません。出来るのは、 難しさとそれに起因する労苦を除去することではなく、私たちの仕事の意味を知ることです。 ドメイン 

©2025 fusions corporation 調和 ＞ 効率化・高速化 ソフトウェアデザインに向かおう 

©2025 fusions corporation ご清聴ありがとうございました fusion_placeは株式会社フュージョンズ及びその供給元の商標又は登録商標です。 本資料(添付資料を含む)に掲載されている情報は全て、株式会社フュージョンズ及びその供給元の知的財産です。コンテンツの複製、 社外への公開、社内利用への転用等の二次利用は全て、株式会社フュージョンズ及びその供給元の許諾を必要とする旨、ご理解をお願いします。 visit https://fusions.co.jp