# 業務プロセスの To-Be 原則はどう立てるのか：原則の書き方、導き方、再設計の手法 - 著者：小川 修一郎（デザイン研究者／デザインコンサルタント）https://jamjet-iqbal.com/ - 初出：2026-09-30、更新：2026-09-30 - 正規の URL（HTML）：https://jamjet-iqbal.com/notes/to-be-process-principles-literature/ - 英語版：https://jamjet-iqbal.com/en/notes/to-be-process-principles-literature/（Markdown：https://jamjet-iqbal.com/en/notes/to-be-process-principles-literature.md） - 言語：ja - キーワード：to-be-process, business-process-redesign, business-process-management, architecture-principles, design-principles, redesign-heuristics, process-improvement-methods, togaf, ai-augmented-bpm, literature > 業務フロー検討で「あるべき姿」（To-Be）の設計原則をどう立てるかを、学術文献 16 件と TOGAF 標準から整理した。今回の探索の範囲では「To-Be principle」という定着した術語は見つからず、近い概念はアーキテクチャ原則、設計原則、再設計のベストプラクティス、BPM の原則の四つに分かれる。書き方は TOGAF が名前、主文、根拠、影響の四項目と、良い原則の五条件（わかりやすさ、頑健さ、網羅、一貫、安定）を示し、Gregor ら（2020）は目的、実装者、利用者、文脈、機構、根拠を持つ型を示した。Haki と Legner（2021）は文献中の 152 の原則を調べ、目標を原則のように書いたもの、実務の手順、細かい標準を「原則でないもの」として外し、45 の原則を 9 のメタ原則にまとめた。導き方では、手法の段階の枠組み（Kettinger ら 1997、Gross ら 2019 が 98 手法で拡張）が、事業目標と性能目標を現状の分析より前に置く。Reijers と Limam Mansar（2005）は性能目標を時間、費用、品質、柔軟性の四軸で具体化し、軸どうしの引き換えを意識するよう求めた。現状（As-Is）は目的を理解するために調べるが、それだけを案の源にしない（Rosemann 2006）。案を生む手法は、無構造、半構造、構造化の三つに分かれ（Vanwersch ら 2016、61 研究）、構造化の代表が 29 の再設計ベストプラクティス（Reijers & Limam Mansar 2005）と、6 層 19 次元の設計空間（Gross ら 2021）である。実務家調査では、タスク削除を 94% が使っていた（Limam Mansar & Reijers 2007）。ただし多くのベストプラクティスは定量的な裏づけを欠く。AI が加わると、原則はシステムの「枠」（目標と制約）に入り、どこまでをシステムに書き換えさせるかを人が決める（Dumas ら 2023）。原則を書くこと自体が To-Be の質を上げるかを確かめた実証は、今回の範囲では見つからなかった。 ## 現状とあるべき姿のあいだで起きていること 業務フローの検討は、現状（As-Is）を描き、あるべき姿（To-Be）を描き、その差を埋める計画を立てる、という順で語られることが多い。 ところが、現状からあるべき姿へどう進むのかは、手法の本でもあまり書かれてこなかった。 Reijers と Limam Mansar（2005）は、Sharp と McDermott の言葉を引いてこの空白を指摘している。 現状からあるべき姿への進み方は説明されず、休憩のあいだに「そして奇跡が起きる」手順が使われる、という皮肉である[^atamo]。 同じ論文は、再設計を広めた Hammer と Champy の本が 250 頁を超える分量のうち、プロセスの設計そのものに 14 頁しか割いておらず、そのうち 11 頁が事例だと数えている。 [^atamo]: 原文は "How to get from the as-is to the to-be [in a BPR project] isn't explained, so we conclude that during the break, the famous ATAMO procedure is invoked—And Then, A Miracle occurs"（Reijers & Limam Mansar 2005, p. 284）。 この空白を埋める手がかりは、再設計の古典にすでに出ている。 Hammer（1990）は Ford の買掛金処理を例に挙げた。 Ford には「請求書を受け取ったら支払う」という規則があった。 誰も書き留めたことのない規則だったが、買掛金の業務はこの規則に沿って組まれていた。 Ford は、この規則を「品物を受け取ったら支払う」に置き換えた。 発注時に情報を共有データベースに入れ、受け入れ担当が届いた品物を発注と照合し、一致すれば支払いが自動で準備される。 照合する項目は 14 から 3 に減り、Hammer によれば人員は 75% 減った。 実務で **To-Be 原則**（To-Be principle）と呼ばれるものは、この「品物を受け取ったら支払う」にあたる。 あるべき姿の業務がどういう規則に従うべきかを、個々のフロー図より先に言葉で決めたものである。 では、この規則は何を書けば原則になり、どこから導き、どうやって具体的な案に落とすのか。 このノートは、その三つを学術文献と標準から整理する。 ## スコープと方法 問いは「業務フロー検討における To-Be 原則とは何か、どう定めるか、体系的な手法とベストプラクティスは何か」である。 Active mode は academic で、査読論文、学術書、査読版を確認できる会議論文を対象にした。 産業側の資料は補助として、エンタープライズアーキテクチャの標準である TOGAF だけを使った。 探索は source-researcher（profile: scholarly）で候補 40 件を得て、paper-screening-agent で書誌を確定した。 そこから、論点を直接扱い、本文を取得できた文献を中心に 16 件を選んだ。 本文を取れなかった 2 件（Kettinger ら 1997、Grover ら 1995）は、前者は Gross ら（2019）が本文で引く範囲だけを、後者は要旨の範囲だけを書き、その旨を本文中に記した。 全参照の本文取得の経路と結果は `source/review/to-be-process-principles/fulltext-manifest.json` に、主張ごとの該当箇所はコーパスの検証証跡に残した。 ## 「原則」と呼ばれるものは四つある 今回の探索の範囲では、査読文献の中に「To-Be principle」という定着した術語は見つからなかった。 近い概念は四つあり、それぞれ別の研究の流れにいる。 - **アーキテクチャ原則**：組織の情報システムや業務の目標とする姿（target architecture）について、将来の判断の拠り所になる長続きする規則。TOGAF 標準と、エンタープライズアーキテクチャの研究（Haki & Legner 2021）が扱う。 - **設計原則**：人工物をどう作ればどんな目的が達せられるかを述べる、処方的な知識。情報システムの設計科学研究（Gregor ら 2020）が扱う。 - **再設計のベストプラクティス**：既存のプロセスをどう変えると性能が変わるかの経験則。「不要なタスクを除く」など。業務プロセス再設計の研究（Reijers & Limam Mansar 2005）が扱う。 - **BPM の原則**：プロセス管理という活動そのものをどう運営するかの原則。vom Brocke ら（2014）の十原則がこれにあたる。 四つのうち、最後の BPM の原則は、あるべき姿の業務の中身ではなく、改善活動の進め方を律する。 vom Brocke ら（2014）の十原則は、文脈への適合、継続、能力の育成、全体性、組織への定着、関係者の参加、共通理解、目的、簡素、技術の適切な利用で、いずれも BPM の取り組みについての規範である。 これを To-Be 原則と取り違えると、「関係者を巻き込む」のような進め方の約束が、業務の規則の欄に並ぶことになる。 残る三つは、To-Be 原則の別々の面を照らす。 アーキテクチャ原則は、原則をどう書き、どう管理するかを教える。 設計原則は、原則が何を目的に、誰に、どんな仕組みで効くのかを書く型を教える。 再設計のベストプラクティスは、原則から具体的なフローの案を作るときの手持ちの選択肢を教える。 ## 原則は何を書けば原則になるのか TOGAF 標準は、原則を**名前**（Name）、**主文**（Statement）、**根拠**（Rationale）、**影響**（Implications）の四項目で書くよう勧める。 名前は規則の本質を表して覚えやすくし、特定の技術製品の名を入れない。 主文では「支援する」「考慮する」「開かれた」のような曖昧な語を避ける。 根拠には、原則に従うことの事業上の利点に加えて、ほかの原則との関係と、原則どうしがぶつかったときにどちらを優先するかを書く。 影響には、原則に従うために事業と IT の側で要る資源、費用、作業を書き、読み手が「これは自分に何をもたらすか」に答えられるようにする。 TOGAF は、原則の集合が良いかどうかを五つの条件で見る。 わかりやすいこと（組織の誰もがすぐ理解でき、意図が明確で違反が起きにくい）、頑健であること（議論の分かれる場面でも一貫した判断を支えるほど明確である）、網羅していること、一貫していること（一つの原則を厳密に守ると別の原則の趣旨を破る、ということがない）、安定していること（長続きするが、追加や改廃の手続きを持つ）である。 数は、多くの組織が 10 から 20 に絞るとしている。 TOGAF は、原則を読んだ人が最初に「当たり前だから書くまでもない」と反応することが多いと書き、当たり前に見えることと守られていることは別だとして、それでも書くよう勧めている。 Gregor ら（2020）は、情報システムの設計原則の書き方を比べ、一つの型にまとめた。 型の骨格は「実装者 I が、文脈 C において、利用者 U のために目的 A を達する（または可能にする）には、実行者 E が関わる機構 M を用いる。根拠は R である」という一文である。 **実装者**（implementer）は抽象的な原則を具体的な場面に当てはめる人、**利用者**（user）は目的を達してもらう人、**実行者**（enactor）は機構の中で実際に動く人を指す。 この型は、原則が誰の目的のためのもので、誰が動くことで効くのかを、書き手に明示させる。 TOGAF の四項目と比べると、Gregor らの型は文脈と人の役割を加え、TOGAF は影響（費用と作業）を加えている。 二つを合わせると、To-Be 原則の一枚には、名前、主文、目的と対象者、適用する文脈、効く仕組みと動く人、根拠と優先関係、影響の七つが並ぶことになる。 この合わせ方は本ノートの整理であり、両者の文献が組み合わせを検証したわけではない。 では、書式を満たしていれば原則なのか。 Haki と Legner（2021）は、エンタープライズアーキテクチャの文献に現れる 152 の原則を存在論的に分析し、原則とは呼べないもの（nonprinciples）を三種類に分けた。 - **目標や成果を原則のように書いたもの**：原則を採る理由（期待する成果）であって、設計の判断を導かない。 - **実務の手順**：アーキテクチャの業務をどう運営するかの指針であって、設計の判断を導かない。 - **細かい統制の手段**：標準（原則を実行するための規則と手順）や、実装の方法論としてのガイドライン。原則が持つべき長続きする性質と合わない。 これを除き、同じ原則を一つに数えると 45 が残った。 Haki と Legner は、それを統合、データの一貫性、標準化、準拠、再利用、モジュール化、使いやすさ、移植性、集中化の 9 のメタ原則にまとめた。 Haki と Legner は、原則は特定の技術、方法、手順を定めるのではなく、目的に沿った設計判断の土台だけを与えるべきだとしている。 Ford の例に当てはめると、「買掛金の人員を 75% 減らす」は目標であって原則ではない。 「品物を受け取ったら支払う」は、発注、受け入れ、支払いのどの設計判断にも向きを与えるので、原則になる。 ## 原則はどこから導くのか ### 目的と性能目標を先に置く 原則を導く出発点は、組織の目的である。 TOGAF は、各原則を事業目標と主要な推進要因に明確にたどれるようにせよとし、原則の作成に影響するものとして、組織の使命と計画、戦略的な取り組み、外部の制約（市場の要請、顧客の期待、法規制）、現行のシステムと技術、業界の動向を挙げる。 vom Brocke ら（2014）の目的の原則も、BPM が戦略的な価値創出に貢献すべきで、流行だからという理由で行うと失敗しやすいとする。 Rosemann（2006a）は、プロセスモデリングの落とし穴の一つめに、企業戦略とのつながりの欠如を置いた。 手法の段階の順序も、目的を先に置く。 Kettinger ら（1997）の段階と活動の枠組みは、構想、着手、診断、再設計、再構築、評価の六段階からなる。 Gross ら（2019）は 98 の手法の活動をこの枠組みに写して拡張し、構想の段階に主要な事業目標の特定と戦略との整合を、着手の段階に外部顧客の要求の確定、性能目標の設定、新しいプロセスの構想を置いている。 現状のプロセスの文書化と分析は、その後の診断の段階に来る。 Gross らは同じ分析で、再設計（redesign）を名乗る手法は構想の段階の活動を最も少なくしか持たず、再設計後の性能を評価する活動を持つものも 36% にとどまると報告した。 98 手法の内訳は、再構築（reengineering）を名乗るものが 49、改善（improvement）が 33、再設計が 11、革新が 3、最適化が 2 だった。 性能目標は、四つの軸で具体化できる。 Reijers と Limam Mansar（2005）は、Brand と van der Kolk の**悪魔の四角形**（devil's quadrangle）を評価の枠組みに使った。 時間、費用、品質、柔軟性の四軸で、一つの軸を良くすると別の軸が悪くなることが多い。 たとえば照合のタスクを足すと品質は上がるが、処理は遅くなる。 Reijers らは、組織の重要業績指標や再設計の性能目標を、この四軸をより精密にした形で書くべきだとした。 原則の根拠と優先関係（TOGAF の四項目の根拠）は、この引き換えのどちらを取るかを書き留める場所になる。 ### 現状は目的を知るために調べる 現状の分析には役目があるが、それだけを案の源にしない。 Hammer（1990）は、再設計のチームは現状のプロセスが何を達しようとしているのかを本当に理解するまで調べるべきだとした。 ただし、その目的は書類がどこを回るかを知ることではなく、その書類がそもそもなぜあるのかを知ることにある。 チームは「なぜ」「もし〜なら」を問い続け、プロセスの本質と表面を分ける。 Rosemann（2006a, 2006b）は、大規模なモデリングの現場の聞き取りから落とし穴を集め、現状の扱いについていくつかを挙げた。 一つは想像力の欠如で、「現状を理解する、改善策を探す、実行計画を立てる」の三段階だけで進めると、問題の克服に集中し、新しい戦略的な目標に届かない。 Rosemann の結論は「現状の理解は大事だが、新しいプロセスの着想の唯一の源にすべきではない」である。 もう一つは細部への埋没で、細かいモデルほど作成、確認、保守に時間がかかり、早く古びる。 Rosemann は、自動化が目的でない限り、頻度と資源の両方で 8 割の場合を押さえれば足りることが多いとし、詳しさは目的に照らして決めるよう勧めた。 さらに、現状を聞き取るときは「現にこうしている」（as-is）ではなく「こうしているはずだ」（as-if）を書き留めてしまわないよう注意を促した。 人の配置としては、現状を知る人、方向を示す人（目的、期間、制約、成功の測り方を決める人）、着想を出す人の三種類を揃えるべきだとした。 現状から始めるか白紙から始めるかについて、Reijers と Limam Mansar（2005）は、文献には議論があるものの、実務では既存のプロセスを出発点にするのが最も一般的だと書いている。 Grisold ら（2022）は、この区別を**活用型**（exploitative）と**探索型**（explorative）の BPM として整理した。 活用型は既存のプロセスを改善や再構築で良くする内から外への論理で、探索型は事業と技術の機会から新しい価値提案を持つプロセスを作る外から内への論理である。 Grisold らの Five Diamond Method は、全体を束ねる一つのダイヤモンドと、目的、事業、技術、統合の四つのダイヤモンドからなり、発散と収束を繰り返して機会をプロセスに取り込む。 パイロット 1 件と実適用 2 件で評価されている。 ## 原則から To-Be の案をどう生み出すのか ### 手法を六つの決めどころで組む Vanwersch ら（2016）は、現状の洞察から To-Be の案へ進むための手法を、2011 年までの 61 の研究から体系的に集めた。 手法を組むときに決めるべき点を六つに分け、目的、参加者、入力、出力、技法、道具とした。 61 研究のうち入力を論じるものが 93% で最も多く、道具は 51% で最も少なかった。 技法は三つに分かれる。 - **無構造の技法**：ブレインストーミングのような創造技法で、現状から案への手順も、考えるべき案の種類も示さない。 - **半構造の技法**：現状から案への作業手順は示すが、考えるべき案の種類は示さない。 - **構造化された技法**：手順に加えて、考えるべき案の種類を示す。再設計の規則を使う技法や、事例の蓄積を使う技法がこれにあたる。 Vanwersch らは、規則を使う技法について、情報システムの研究者は「BPR のベストプラクティス」の文献を見て、経営科学の研究者は TRIZ の発明原理を見ており、両者がほとんど交わっていないことも指摘した。 ### 再設計のベストプラクティス 構造化された技法の代表が、Reijers と Limam Mansar（2005）がまとめた 29 のベストプラクティスである。 顧客、業務の操作、業務の振る舞い（いつ実行されるか）、組織、情報、技術、外部環境の七つに分け、それぞれが時間、費用、品質、柔軟性にどう効くかを定性的に評価した。 Reijers らは、多くのベストプラクティスが十分な定量的裏づけを欠いていると認めている。 複数を同時に使うと効果が打ち消し合うことがあり、権限移譲と振り分けの組み合わせは多くの場合に最適でないことを数理モデルで示した研究（Seidmann & Sundararajan）も紹介している。 Limam Mansar と Reijers（2007）は、2003 年から 2004 年にかけて英国とオランダの経験豊富な再設計の実務家に調査を行い、よく使われる上位 10 の実践が実際に広く使われていることを確かめた。 使ったと答えた割合は、タスク削除が 94%、統合的な技術（新しい技術で物理的な制約を外す）が 94%、タスクの合成が 89%、並行化、専門職と汎用職の見直し、順序の入れ替えがそれぞれ 88% だった。 顧客や供給者のプロセスとの統合、権限移譲、関与者の数の削減が 76%、一件をできるだけ一人に通しで担当させる割り当てが 53% である。 ただし、実務家による効果の評価は著者らの見込みより肯定的で、著者らはそのずれが調査票の設計から来た可能性を限界として書いている。 Hammer（1990）の七つの原則も、この系譜の源にある。 成果を単位に組織する（タスクを単位にしない）、プロセスの出力を使う人がそのプロセスを行う、情報処理の作業を情報を生む実作業に組み込む、分散した資源を集中しているかのように扱う、並行する活動は結果を統合するのではなく途中で結ぶ、判断を作業の場に置き統制をプロセスに組み込む、情報は一度だけ発生源で捕まえる、の七つである。 Hammer はこれらを、再設計を手探りにしないための、先行企業が見つけた原則として示した。 ### 設計空間で案の幅を広げる Gross ら（2021）は、再設計の手法が To-Be を実際に作る段階をほとんど支えていないという問題から出発した。 彼らは、プロセスについて変えられるものを 19 の設計次元にまとめ、顧客、製品とサービス、業務プロセス、組織、情報、技術の 6 層に分けた **Business Process Design Space**（BPD-Space）を作った。 各次元には、とりうる特性、案を考えるための問い、実例が付いている。 文献レビュー、専門家への半構造化インタビュー、実際の 3 件への適用で作り、評価した。 ベストプラクティスが「どう変えるか」の手を示すのに対し、設計空間は「どこを変えられるか」の地図を示す。 ## 原則を立てても起きる失敗 原則と案が揃っても、それだけで業務は変わらない。 Rosemann（2006b）は、To-Be のモデルを作った直後に満足が広がるが、モデルはモデルにすぎず、実装だけが意味を持つと書いた。 同じ論文は、To-Be を新しい IT だけに頼って描く失敗も挙げた。 IT の導入を待つあいだ何も変えない態度や、IT 以外の解決策を探さない言い訳になるからである。 他社のベストプラクティスの過大評価も落とし穴に入っている。 成功した会社のプロセスが成功の原因だとは限らず、参照モデルは事例と文脈を欠きやすい。 Grover ら（1995）は、要旨によれば、再構築の実施上の問題 64 項目の深刻さを 105 組織の参加者に評価させ、変革の管理が成功の中心だと結論した。 技術の力や計画の問題を解決することは必要だが十分ではなかった。 vom Brocke ら（2014）の簡素の原則も、BPM の取り組みを過剰に作り込まないよう戒めている。 ## AI が加わると原則はどこに置かれるのか Dumas ら（2023）は、AI で拡張した業務プロセス管理システム（ABPMS）の研究課題を示すマニフェストで、**枠**（frame）という概念を置いた。 システムの寿命は、誰かがシステムに初期の目標と制約を与えるところから始まる。 制約には、定められた手順、規範、規制、常識的な規則、ベストプラクティスが含まれ、目標の達成を測る重要業績指標を参照することが多い。 システムはこの枠の中で自律的に動き、新しい知識を得れば枠を組み替えることもある。 そのうえで Dumas らは、枠のどの部分をシステムが書き換えてよく、どの部分は人の指示でしか変えられないかを設計者が決めることを**メタ枠組み**（meta-framing）と呼んだ。 これは研究課題を示すビジョンの論文であり、効果を実証したものではない。 To-Be 原則は、この枠の有力な中身になる。 その場合、原則の根拠と優先関係は、システムが目標どうしの引き換えを選ぶときの手がかりになり、どの原則を人の専権に残すかがメタ枠組みの判断になる。 この対応づけは本ノートの解釈で、Dumas らが原則という語でそう述べているわけではない。 大規模言語モデルとの対話でプロセスモデルを直す試みもある。 Klievtsova ら（2026）は、利用者の自然言語の変更依頼から、文献にある変更パターンを特定し、依頼をパターンの意味に沿って言い換えてから、モデルに適用する方法を提案した。 評価では、一部のパターンはモデルにも利用者にも理解されにくく、利用者の明確な変更の記述が欠かせなかった。 著者らは、うまく扱えるパターンは直接適用し、ほかは追加の質問で入力を改める混合の方式を勧めている。 ## 定め方を手順にすると 文献の知見を順に並べると、To-Be 原則を定める手順は八つになる。 手順の順番と組み合わせは本ノートの整理で、この手順全体の効果を検証した研究は今回の範囲にはない。 | 手順 | すること | 主な根拠 | |---|---|---| | 1 | 組織の目的、戦略、外部の制約、顧客の期待を集め、再設計の目的を決める | TOGAF、vom Brocke ら 2014、Rosemann 2006a | | 2 | 性能目標を時間、費用、品質、柔軟性の四軸で具体化し、どの引き換えを許すかを決める | Reijers & Limam Mansar 2005、Gross ら 2019 | | 3 | 現状を、目的を理解するのに要る詳しさで調べる。as-if を書かない | Hammer 1990、Rosemann 2006a, 2006b | | 4 | 原則を名前、主文、目的と対象者、文脈、機構と動く人、根拠と優先関係、影響で書く | TOGAF、Gregor ら 2020 | | 5 | 目標、手順、細かい標準が原則の欄に混じっていないかを除く。数を 10 から 20 程度に絞り、五条件で点検する | Haki & Legner 2021、TOGAF | | 6 | 原則に沿って案を出す。規則（ベストプラクティス）と設計空間を使い、IT 以外の案も探す | Reijers & Limam Mansar 2005、Gross ら 2021、Vanwersch ら 2016、Rosemann 2006b | | 7 | 案を四軸で評価し、実装と変革の管理まで計画する | Limam Mansar & Reijers 2007、Grover ら 1995、Rosemann 2006b | | 8 | AI に実行や改善を任せる部分があれば、どの原則をシステムが書き換えてよいかを決める | Dumas ら 2023 | ## まだ確かめられていないこと 原則を書くこと自体が To-Be の質を上げるのかを、比較で確かめた研究は今回の範囲では見つからなかった。 TOGAF の四項目と五条件は標準の推奨で、Haki と Legner の事例研究は 3 社で原則から成果への道筋を描いたものである。 再設計のベストプラクティスの効果の証拠も薄い。 Reijers ら自身が定量的な裏づけの不足を認め、使用状況の調査は 2003 年から 2004 年のもので、効果は回答者の評価にとどまる。 現状をどこまで詳しく調べればよいかについても、Rosemann の「8 割の場合」を超える指針は見当たらなかった。 AI の側では、手元の文献はビジョンと手法の提案で、原則を枠として与えた場合に To-Be がどう変わるかを示した実証はまだない。 Ford の「品物を受け取ったら支払う」を AI に与えたとき、その規則を書き換える権限を誰が持つのかは、メタ枠組みという名前を得たところで止まっている。 ## 関連ノート - [問題を立て直す手法の学術地図：アブダクション2から問題構造化まで](https://jamjet-iqbal.com/notes/problem-definition-methods-literature/)：Hammer の規則の置き換えは、問題のフレームを組み替える手法の一例として読める。 - [業務アプリの UI をひとつに決めるまで：案を狭めるもの、比べ方、決める人](https://jamjet-iqbal.com/notes/business-app-ui-decision-industry/)：業務アプリの UI を一つに決めるまでの材料と手順。業務フローの To-Be が決まった後の画面設計にあたる。 - [デザインと新規事業の工程は、どの標準に載るか](https://jamjet-iqbal.com/notes/design-work-process-standards/)：デザインと新規事業の工程がどの標準に載るか。 ## 参照文献 アクセス日はすべて 2026-09-30。 ### 原則の書き方 - The Open Group (2022). *The TOGAF Standard, 10th Edition: ADM Techniques*, Chapter 2 "Architecture Principles". https://pubs.opengroup.org/togaf-standard/adm-techniques/chap02.html （Wayback Machine の 2024-09-11 版で閲覧） - Haki, K., & Legner, C. (2021). The Mechanics of Enterprise Architecture Principles. *Journal of the Association for Information Systems*, 22(5), 1334–1375. https://doi.org/10.17705/1jais.00696 （著者版 https://api.unil.ch/iris/server/api/core/bitstreams/66889670-2b96-4f9f-a1ff-d7a260316b23/content ） - Gregor, S., Chandra Kruse, L., & Seidel, S. (2020). Research Perspectives: The Anatomy of a Design Principle. *Journal of the Association for Information Systems*, 21(6), 1622–1652. https://doi.org/10.17705/1jais.00649 （著者版 https://www.uni-kassel.de/fb07/index.php?eID=dumpFile&t=f&f=4900&token=8829a7e90fbfde2645262e72c8fb56b6a0863e54 ） ### 原則の導き方と現状の扱い - Hammer, M. (1990). Reengineering Work: Don't Automate, Obliterate. *Harvard Business Review*, July–August 1990. https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate （本文 https://folk.idi.ntnu.no/thomasos/paper/hammer_reengineering.pdf ） - vom Brocke, J., Schmiedel, T., Recker, J., Trkman, P., Mertens, W., & Viaene, S. (2014). Ten Principles of Good Business Process Management. *Business Process Management Journal*, 20(4), 530–548. https://doi.org/10.1108/BPMJ-06-2013-0074 （著者版 https://lirias.kuleuven.be/retrieve/c62d2d2a-4763-4e24-be1a-fe9d58425245 ） - Kettinger, W. J., Teng, J. T. C., & Guha, S. (1997). Business Process Change: A Study of Methodologies, Techniques, and Tools. *MIS Quarterly*, 21(1), 55–78. https://doi.org/10.2307/249742 - Gross, S., Malinova, M., & Mendling, J. (2019). Navigating Through the Maze of Business Process Change Methods. *Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS)*, 6270–6279. https://doi.org/10.24251/HICSS.2019.754 （本文 https://hdl.handle.net/10125/60061 ） - Rosemann, M. (2006a). Potential Pitfalls of Process Modeling: Part A. *Business Process Management Journal*, 12(2), 249–254. https://doi.org/10.1108/14637150610657567 - Rosemann, M. (2006b). Potential Pitfalls of Process Modeling: Part B. *Business Process Management Journal*, 12(3), 377–384. https://doi.org/10.1108/14637150610668024 （A と B を収めた本文 https://scholar.archive.org/work/zjgbw4zje5cz7dzt4di67lnsku/access/wayback/http://bpm-training.com/wp-content/uploads/2010/04/Rosemann-2006.-Potential-Pitfalls-of-Process-Modeling.pdf ） - Grisold, T., Groß, S., Stelzl, K., vom Brocke, J., Mendling, J., Röglinger, M., & Rosemann, M. (2022). The Five Diamond Method for Explorative Business Process Management. *Business & Information Systems Engineering*, 64(2), 149–166. https://doi.org/10.1007/s12599-021-00703-1 （本文 https://pmc.ncbi.nlm.nih.gov/articles/PMC8185488/ ） ### 再設計の手法とベストプラクティス - Reijers, H. A., & Limam Mansar, S. (2005). Best Practices in Business Process Redesign: An Overview and Qualitative Evaluation of Successful Redesign Heuristics. *Omega*, 33(4), 283–306. https://doi.org/10.1016/j.omega.2004.04.012 （著者版 https://hreijers.win.tue.nl/H.A.%20Reijers%20Bestanden/BPRpractices.pdf ） - Limam Mansar, S., & Reijers, H. A. (2007). Best Practices in Business Process Redesign: Use and Impact. *Business Process Management Journal*, 13(2), 193–213. https://doi.org/10.1108/14637150710740455 （著者版 https://hreijers.win.tue.nl/H.A.%20Reijers%20Bestanden/impact.PDF ） - Vanwersch, R. J. B., Shahzad, K., Vanderfeesten, I., Vanhaecht, K., Grefen, P., Pintelon, L., Mendling, J., van Merode, G. G., & Reijers, H. A. (2016). A Critical Evaluation and Framework of Business Process Improvement Methods. *Business & Information Systems Engineering*, 58(1), 43–53. https://doi.org/10.1007/s12599-015-0417-x （本文 https://pure.tue.nl/ws/files/15733410/art_3A10.1007_2Fs12599_015_0417_x.pdf ） - Gross, S., Stelzl, K., Grisold, T., Mendling, J., Röglinger, M., & vom Brocke, J. (2021). The Business Process Design Space for Exploring Process Redesign Alternatives. *Business Process Management Journal*, 27(8), 25–56. https://doi.org/10.1108/BPMJ-03-2020-0116 （本文 https://www.fim-rc.de/Paperbibliothek/Veroeffentlicht/1073/wi-1073.pdf ） ### 実施の失敗 - Grover, V., Jeong, S. R., Kettinger, W. J., & Teng, J. T. C. (1995). The Implementation of Business Process Reengineering. *Journal of Management Information Systems*, 12(1), 109–144. https://doi.org/10.1080/07421222.1995.11518072 ### AI との関係 - Dumas, M., Fournier, F., Limonad, L., Marrella, A., Montali, M., Rehse, J.-R., Accorsi, R., Calvanese, D., De Giacomo, G., Fahland, D., Gal, A., La Rosa, M., Völzer, H., & Weber, I. (2023). AI-augmented Business Process Management Systems: A Research Manifesto. *ACM Transactions on Management Information Systems*, 14(1), Article 11. https://doi.org/10.1145/3576047 （著者版 https://arxiv.org/abs/2201.12855 ） - Klievtsova, N., Kampik, T., Mangler, J., & Rinderle-Ma, S. (2026). Conversational Process Model Redesign. *International Journal of Cooperative Information Systems*, 35(1), 2650004. https://doi.org/10.1142/S0218843026500048 （著者版 https://arxiv.org/abs/2505.05453 ）