1.2.1 モデリングワークフロー ABCD
ニーズと設計を適切に行い、低コストで売れるシステムを製造するためには、スローガンを叫ぶだけでは実現できません。必要なモデリングスキルを落ち着いて学び、実践する必要があります。 ソフトウェア開発はインクリメンタル(漸進的)かつイテレーション(反復的)に進められます。各イテレーション周期において、以下のいくつかの事項を順に検討する必要があります。
A - ビジネスモデリング(business modeling):改善すべき目標組織と、その組織が次に最も改善すべき問題を特定します。
B - ニーズ(requirements):組織の問題を改善するために導入される情報システムが持つべき、全体的な振る舞いを記述します。
C - 分析(analysis):機能ニーズを満たすために、導入される情報システムがカプセル化する必要があるコア領域メカニズムを抽出します。
D - 設計(design):品質ニーズと設計制約を考慮し、コア領域メカニズムを選択された非コア領域にマッピングして実装します。
本書では、上記のABCDをソフトウェア開発の4つのモデリングワークフローと呼びます。 本書の方法論とUML表記法を採用した場合、そのABCDは大まかに図1-5のようになります。読者はまずざっと見ておけばよく、図の内容については後で詳しく解説します。
図1-5 4つのモデリングワークフロー(本書の方法論+UML)
ソフトウェア業界で使われる様々な派手な用語は、真のイノベーションであろうと偽のイノベーションであろうと、基本的に上記のABCDで分類することができます。例えば:
プロダクトマネージャー、ニーズエンジニア、ニーズアナリスト:A + B + Cの一部。
ビジネスアーキテクト:A(この場合の「ビジネス」は「組織」の意味)、またはC(この場合の「ビジネス」は「コア領域」の意味)。
システムアーキテクト:C + D。チームがシステムアーキテクチャを改善すると言う場合、実際にはB-ニーズを改善したいと考えていることがよくあります。
ドメイン駆動設計:C + D。一部のチームは「ドメイン駆動設計」を学ぶと主張しますが、実際にはA-ビジネスモデリングの問題を解決したいと考えています。
ミドルプラットフォーム(中台):C + D
マイクロサービス:C + D
デザインパターン:C + D
…
読者の皆様からの随時追加・更新を歓迎します。
はい、承知いたしました。ご提供いただいた中国語のテキストを日本語に翻訳します。
1.2.2 用語について
「ワークフロー(workflow)」は、RUP(Rational Unified Process)の初期バージョンから引き継がれたもので、後のRUPバージョンでは「ディシプリン(discipline)」に変更されました。 私の見解では、「ワークフロー」も「ディシプリン」もどちらも最適な言葉ではありませんが、現時点ではより適切な選択肢がないため、一時的に「ワークフロー」を使用します。 4つのワークフローの名称、「ビジネスモデリング」「ニーズ」「分析」「設計」は、これまでの様々な方法論の用語を踏襲していますが、これらの用語も厳密ではありません。 例えば、「ビジネスモデリング」の末尾には「モデリング」がありますが、他の3つにはありません。では、他の3つはモデリングではないのでしょうか?もし他の3つにも「モデリング」という語尾を付ければ、無駄な言葉の羅列になってしまいますし、「ビジネスモデリング」の「モデリング」を削除して「ビジネス」だけでは、意味が異なってしまいます。 さらに、「ビジネス」という言葉自体が曖昧な用語であり、これについては後で詳しく説明します。 より適切な名称は次のようになるかもしれません:
A - 組織改善
B - システム責務
C - コア領域ロジック
D - 実装 しかし、熟慮を重ねた結果、やはり以前の用語を踏襲することにしました。 読者がABCDの内容を真に理解していれば、呼び方が何であっても大きな問題はありません。Aを「アニャー」、Bを「アワン」、Cを「アコッコ」、Dを「アガーガー」と変えても構わないでしょう。
ここまで読んで、読者は本書における「ニーズ」と「設計」という2つの用語が2つの用途で使われていることに気づくかもしれません。 一つは、モデリングによって得られた結果を表現する場合です。例えば、「ニーズと設計は一対一に対応していない」というように。もう一つは、モデリングのワークフローを表現する場合です。すなわち、「B-ニーズ」ワークフローと「D-設計」ワークフローのことで、「私は今、ニーズ作業をしている」というように使われます。 以下の言葉が理解の助けになれば幸いです: ニーズを得るために必要なモデリングワークフローは「A-ビジネスモデリング」と「B-ニーズ」であり、設計を得るために必要なモデリングワークフローは「C-分析」と「D-設計」です。
また、本書における人員に関する用語についても説明します。これらの用語の多くは意味が曖昧です。本書では特定の場面でこれらの言葉を踏襲していますが、ここでその意味を説明します。 (1)開発者 この用語の意味は現在曖昧になっています。ある人は非常に狭い意味で「コーダー」と同義で使い、ある人は非常に広い意味でソフトウェア開発チーム全員を指します(もちろん、「ソフトウェア開発チーム」とは何かというのも曖昧です)。 本書の著者が「開発者」という言葉を使用する場合、その意味は次の通りです: ABCDワークフローのいずれかの作業に従事するソフトウェア開発チームのメンバー。後述するように、「テスト」作業もABCDワークフローに含まれるため、テスターも開発者の一員です。 チーム内で管理業務に従事する役割は、開発者には含まれません。 (2)モデリング担当者 「開発」は本質的に「モデリング」であり、「モデリング担当者」という言葉がカバーする人員は「開発者」と同じです。 本書の著者が、ある人物がUMLまたは類似の表記法を使用する場面を記述する際に、「モデリング担当者」という言葉でその人物を呼ぶことがあります。 (3)プログラマー 本書の著者が「プログラマー」を使用する場合、その意味は「実装担当者」、すなわちDワークフローに従事する人員です。 (4)プロダクトマネージャー、アーキテクト その他、本書では「プロダクトマネージャー」や「アーキテクト」といった用語も登場するかもしれませんが、これらは通常、特定のソフトウェア開発チームのある場面を記述する際に使用されます。プロダクトマネージャーは通常ABワークフローに従事する人員を指し、アーキテクトは通常CDワークフローに従事する人員を指します。 本書の著者は、知識を解説したり問題を議論したりする際には、できる限り厳密な用語を使用し、「プロダクトマネージャー」や「アーキテクト」といった意味が曖昧な用語を積極的に使用することはありません。
1.2.3 避けられない思考
イテレーション周期において、良い結果を追求するならば、A→B→C→Dの順序で推論を進めることは必須であり、各開発チームは常にそうしています。いくつかのシナリオを見てみましょう: 開発チーム甲は、メンバー全員が『ソフトウェア方法』を真剣に学び、熱心に問題を解き、UMLとモデリングツール(例えばEnterprise Architect、EA)を導入し、本書の改善ガイドラインに従って改善した結果、非常に良い結果を得ました。 開発チーム甲のA→B→C→Dは容易に見て取れます。
開発チーム乙は、『ソフトウェア方法』を聞いたこともなく、UMLやEAも使用していません。彼らは技術部長が独自にまとめた「ソフトウェア工学方法論」と記号を使用していますが、これもまた有効に機能しています。 開発チーム乙のA→B→C→Dも容易に見て取れますが、形式は開発チーム甲とは異なります。
開発チーム丙は、「アジャイル」や「ドメイン駆動設計」という名の偽イノベーションを喜んで受け入れています。これらの偽イノベーションは投資が少なく、効果が早く現れ、敷居が低く、大量生産が可能で、儀式感に溢れています。開発チームは楽しく賑やかに議論し、場当たり的な対応をしています。 ここにA→B→C→Dはあるのでしょうか?おそらく少しはあるかもしれませんが、ごくわずかです。この賑わいは単なる見せかけに過ぎません。真に機能するA→B→C→Dの推論は、コーディング中に頭の中で漠然と行われているのかもしれず、その推論の質は推して知るべしです。
開発チーム丁は、ABCができないし、見せかけもしたくないので、Dに直行して直接コーディングすると考えました。 この場合、A→B→C→Dは存在するのでしょうか?存在します。開発チーム丙とほぼ同じで、真に機能するA→B→C→Dの推論は、コーディング中に頭の中で漠然と行われているので、同様にその推論の質は推して知るべしです。幸いなことに、偽イノベーションの見せかけのコストは省かれています。 ★さらに巧妙なのは、一部の開発者が「アジャイル」の名の下に意図的にこれを選択することです。目的は、自分たちのABC能力の不足を隠蔽することです。彼らは、直接Dに飛び込み、コーディング環境に向かいながら頭の中で漠然とA→B→Cワークフローの補習を行うことを好みます。なぜなら、そうする方が「プレッシャー」がはるかに小さいからです。 ★この時、表面上のタスクはコーディングであり、A→B→Cの推論はついでに行われるおまけのようなものであり、どの程度までできたかを厳しくとがめることはできません。もし、A-ビジネスモデリングを行うという明確なタスクが設定されていれば、成果物に対する要求は高くなり、ごまかしが効かなくなってしまうでしょう。
開発チーム戊の物語(純粋なフィクションであり、当てはめないでください)は少し異なって見えます。彼らの会社は好機に恵まれ、ある分野(例えば、プレハブ料理)のインターネット大手となりました。プレハブ料理関連のプロジェクトの開発と保守において、開発チーム戊のリーダーは、現在のフロントエンドフレームワークであるVueやReactなどがまだ物足りないと感じていました。——むしろ、自分の履歴書のために積極的に「物足りない」と感じ、社内プロジェクトを立ち上げ、独自開発のフロントエンドフレームワーク「閃電五連鞭」を開発しました。数年後、流行が過ぎたのか、歴史的使命を終えたのか、プレハブ料理市場は冷え込みましたが、代わりに「閃電五連鞭」フレームワークは偶然にも全世界の開発者に熱狂的に支持され、会社の存続の柱となりました。 ここにA→B→C→Dはあるのでしょうか?逆転しているように見えるでしょうか? もう一つ特別な例として、プログラマーの張三が自分で使うために何かを作っている場合を考えましょう。張三はコーディングツールしか使えず、UMLや類似の知識も学んでいません。 張三の場合もA→B→C→Dの推論は存在するのでしょうか? 最後の2つのケースも、答えは同じで、特に変わった点はありません。詳細については後で詳しく説明します。 要するに、すべてのソフトウェアプロジェクトにおいて、意図的に手を抜かない限り、開発チームはA→B→C→Dの推論プロセスを経ています。それは無意識に、あるいは明示的に行われるかもしれません。推論プロセスは厳密かつ合理的かもしれませんし、欠陥だらけかもしれません。多くの人が分担して行うかもしれませんし、一人が行うかもしれません。推論の成果物の形式はUMLモデルかもしれませんが、他の形かもしれません…。 これは複雑な数学の穴埋め問題に似ています。答えが974/2025だとして、受験者がこの正解を埋めることができたなら、試験の過程でどこかの時点で正しい推論を行ったに違いありません。このような穴埋め問題の答えを当てずっぽうで正解するのはかなり難しいからです。意図的に手を抜かない限り、学業不振の生徒でさえ推論を試みます。ただ、優等生が一発で正解するのに対し、学業不振の生徒は何度も何度も「アジャイルに探索」を繰り返してようやく正解したり、試験終了まで正解できなかったりするだけです。 本書は読者に厳密かつ効率的な推論方法を教えることを目的としています。もちろん、それを習得するには、多大な努力と汗を必要とします。
1.2.4 ABCDを理解していないことの弊害
1.2.4.1 思考の逆転
ソフトウェア開発者が上記の「A-ビジネスモデリング」「B-ニーズ」「C-分析」「D-設計」ワークフローの概念を理解していない場合、次のような現象が起こります: ある開発者に「何をしているのか」と尋ねると、「設計をしています」「ドキュメントを書いています」と答えるかもしれません。 実際には、その時彼の頭の中では、組織のプロセス(A-ビジネスモデリング)について考えているのかもしれませんし、システムの機能や性能(B-ニーズ)について考えているのかもしれませんし、システムにカプセル化すべき領域の概念間の関係(C-分析)について考えているのかもしれません。しかし、彼はそれらすべてを「設計をしている」「ドキュメントを書いています」と答えます。 つまり、彼の頭の中では、ソフトウェア開発作業が単純に「コードを書くこと」と「設計をすること(ドキュメントを書くこと)」の二つの部分に分けられているのです。もし彼が「コードを書いていない」のであれば、それはすべて「設計をしている(ドキュメントを書いている)」とみなされます。 では、彼はどのように自分が「コードを書いている」のか「設計をしている(ドキュメントを書いている)」のかを区別しているのでしょうか?おそらく、Visual Studio、Android Studio、Eclipse…などで書かれたものが「コード」と呼ばれ、Word、wiki、Visio、EA…などで書かれたり描かれたりしたものが「ドキュメント」と呼ばれているのでしょう。 この時、誰かが「コードこそが設計だ」というスローガンを唱えれば、さらに厄介なことになります。なぜなら、元々私は「設計」を「コード以外のあらゆるもの」だと考えていたのに、今「コードこそが設計だ」と言われれば、推論すると「コードこそが(ソフトウェア開発の)すべてだ」ということになってしまうからです。 「コードこそが設計だ」というような煽りがなくても、開発者は「設計」(注意:ここでの「設計」は本書で厳密に定義されたDワークフローではなく、「コード以外のすべてのもの」を指します)や「ドキュメント」を「コード」のより概要的または具象的な表現形式と見なします。異なる「設計」や「ドキュメント」は「コード」の異なるビューを表し、開発者が異なる視点からコードを観察できるようにします。図1-6を参照してください。
図1-6 誤解:ドキュメントは単なるコードのビューに過ぎない
このような誤解は、「普通」の開発者だけが持つものではありません。Martin Fowlerが著したUMLのベストセラー『UML精粋』では、UMLには草稿、設計図、プログラミング言語という3つの使い方があるとし、UMLモデルをコードのビューと見なしていますが、これは誤りです。Martin Fowlerは一部のコミュニティでは神様のように崇められていますが、彼が書いた他の書籍『リファクタリング』、『エンタープライズアプリケーションアーキテクチャパターン』、『分析パターン』などからわかるように、彼の研究は「C-分析」と「D-設計」ワークフローに集中しており、「A-ビジネスモデリング」と「B-ニーズ」ワークフローにはあまり関与していません。彼が「A-ビジネスモデリング」と「B-ニーズ」ワークフローについて述べていることについては、慎重に扱うべきです。
さらに危険なのは、「ドキュメント」を「コード」のビューと見なすことが、思考の逆転をもたらすことです。まず思いつきでコーディング(Dワークフローに早送り)し、その後コード(D)からA、B、Cワークフローの内容を逆算することで、他のワークフローが見せかけだけの形骸化してしまうのです。
以下は、私が経験した思考の逆転の対話例です:
★対話1 私:「これはシステムのユースケース(読者が「ユースケース」を理解していなければ、とりあえず「機能」と解釈してください)であるべきではありません。」 開発者:「はい、そうです!もう書いてあります。実行して見せましょう。このシステムは確かにこのユースケースを提供しています。」 システムにこのユースケースがあるべきかどうかは、「A-ビジネスモデリング」から推論し、ビジョン、ビジネスシーケンス図などのステップの推論を経て、あるべきだと判断されれば持つべきであり、なければ持つべきではありません。コードを書いたからといって、それがあるべきだということにはなりません。
★対話2 私:「この二つのクラスの関係は汎化ではなく、関連であるべきです。」 開発者:「汎化です。信じなければコードを開いて見せますよ(あるいは、リバースエンジニアリングでクラス図を出して見せますよ)。」 汎化関係であるかどうかは、ドメインロジックから判断すべきです。ドメインロジックがそうでないなら、そうではなく、コードもそのように書かれるべきではありません。先に「人間は豚の一種である」(これはコンパイラのチェックを確実に通過します)とコードを書いて、その後書かれたコードを使って「人間は豚の一種である」と証明するべきではありません。
★対話3 私:「AがBをアグリゲーション(またはコンポジション)するのは、あまり正しくありません。」 開発者:「正しいです。私のコードを見てください。Aがアグリゲートルートで、他のオブジェクトが呼び出すときはまずAを探し、データの保存とアクセスもこれを単位としています。」 対話2と同様に、アグリゲーション(またはコンポジション)関係であるかどうかは、ドメインロジックから判断すべきです。ドメインロジックがそうでないなら、そうではなく、コードもそのように書かれるべきではありません。
ABCDワークフローの概念と、各ワークフローで考えるべき内容を理解していれば、私たちはもはや「ドキュメントを書いています」といった言葉を口にしないでしょう。「ドキュメントを書いています」という言葉は、単に「私が書いているものはコードではない」または「ドキュメント編集ツールを使って作業している」ことを表すに過ぎません。 どのような「ドキュメント」を書いているのですか?「A-ビジネスモデリング」ですか?「B-ニーズ」ですか?「C-分析」ですか?私が書かずに絵を描いてもいけないのですか?書かずに描かずに、音声で組織のプロセスを明確に表現してはいけないのですか?Wordでコーディング(すなわちD-設計)してはいけないのですか?C#でニーズ(すなわちB-ニーズ)を書いてはいけないのですか? より意味のある言い方は、「ビジネスモデリングをしています」「ニーズ作業をしています」…でしょう。もし「ドキュメント」という言葉があなたにとってかけがえのない快感をもたらすのであれば、「ビジネスモデリングドキュメントを書いています」と言っても構いません。
1.2.4.2 場当たり的な対応
開発者はよく「変化に対応する」と言い、中には「変化を受け入れる」と叫ぶ人もいますが、多くの人はどのような変化に対応すべきなのか、またどのように正しく変化に対応すべきなのかを明確に理解していません。 私たちが「変化」について語る時、その真実は以下のいずれかである可能性があります:
真実(1):そもそも変化がない システムのニーズ(機能、性能、制約)に変化はなく、単に以前、実装担当者の能力の問題により、実装がニーズを満たしていなかったか、あるいはニーズは満たせるものの、システムの内部構造が不合理であると自己認識している場合です。このような修正は「変化への対応」とは言えず、単なる「修正」に過ぎません。 滑稽なことに、この状況を「変化への対応」と呼ぶ人もいます。まるで試験で少し難しい問題が出た際、劣等生が「アジャイル」に計算したが解けず、前のを消してもう一度試したがやはり解けず、そこで「変化が激しい!」と叫ぶようなものです。 この場合、注力すべきワークフローは「C-分析」と「D-設計」です。
真実(2):システムの機能は変わらず、性能と制約が変わった 例えば、応答時間の短縮が必要になったり、実装プラットフォームの変更が必要になったりする場合です。 このような変化に対応するには、「D-設計」ワークフローに注力し、実装のやり方を見直す必要があります。
真実(3):システム機能の合理的な変化 厳密な「A-ビジネスモデリング」と「B-ニーズ」の推論を経て、システムの機能(ユースケース、ステップ、入出力情報、ビジネスルール…)が本当に変化する必要があると判断された場合です。 このような変化に対応するには、「C-分析」ワークフローに注力する必要があります。 ここで言うのは、「A-ビジネスモデリング」と「B-ニーズ」の厳密な推論から導き出された「合理的な変化」であることに注意してください。システムの機能が変化する必要がある根本原因は、システムが置かれている大環境の何かが変化したことにあり、このような変化にはしばしば法則性があります。「C-分析」ワークフローを通じて、システムのコア領域モデルを調整し、コア領域の法則性をより良く反映させることは、このような変化に対応するのに役立ちます。
真実(4):システム機能の不合理な変化 これが普段よく言われる「偽のニーズ」です。(1)と同様に、これは実際には「変化」ではなく「誤り」です。 厳密な「A-ビジネスモデリング」と「B-ニーズ」の推論を経ずに、思いつきで得られたいわゆる「システム機能」は、組織プロセスを改善せず、ステークホルダーの利益も満たしません。 この場合、「C-分析」ワークフローに注力してもあまり意味がありません。なぜなら、このような変化には法則性がないからです。 もし「C-分析」ワークフローに力を入れても「変化への対応」の改善があまり見られない場合、それは注力すべきワークフローが「A-ビジネスモデリング」と「B-ニーズ」であることを意味します。まず、システムの機能を厳密に推論できるようになって初めて、真実が(3)なのか(4)なのかを知ることができます。
医者が患者を診察する例で例えましょう:
真実(1): 医者の診断に問題はなく、処方箋にも問題なかったが、看護師または患者が指示を誤って実行した。 これは「変化」ではなく「誤り」です。これを「変化を受け入れる」と呼ぶなら、それは恥知らずです。
真実(2): 点滴の際に、別のブランドの使い捨て点滴器具に交換した。
真実(3): 患者の病状が本当に変化した。張三は元々B型肝炎だったが、今や肝臓がんに進行した。 このような変化には法則性があります。張三はB型肝炎にもかかわらず、養生を怠り、依然として飲酒や徹夜を続けたため、すぐに肝硬変に進行し、その後肝臓がんに進行しました。 肝臓の働き(C-分析)を十分に理解していれば、張三がB型肝炎と診断された時点で、当時の状況に適切に対応し、後で起こりうる変化を予測して事前に対処することができたでしょう。
真実(4): 医者が病状を誤診した。 張三に吐き気、倦怠感、食欲不振が現れた。村の道士である九叔が彼を診断し、幽霊に取り憑かれていると判断し、除霊の儀式を行う必要があるとした。九叔は除霊理論体系と実践を長年深く研究しており、邪を払う剣術は伝説の王者レベルに達している。 実際には張三はB型肝炎にかかっており、九叔の伝説の王者もこれには何の役にも立たない。 もちろん、除霊ゲームやコスプレをするのであれば、話は別ですが。
おそらくその違いを理解していないか、あるいは自分の無能さを隠すために、開発者はしばしば場当たり的な対応をします。 例えば、真実(4)を真実(3)だと言い、あたかも「ニーズが劇的に変化した」かのような偽りの状況を作り出し、それによって自分が「A-ビジネスモデリング」と「B-ニーズ」の能力に欠けている事実を隠蔽します。 例えば、真実(3)と真実(4)には触れず、真実(2)だけを語ったり、真実(2)への対応策である「D-設計」を通じて真実(3)と真実(4)に対応しようとしたりします。なぜなら、「D-設計」が彼らが唯一精通している内容だからです。 一部の資料は「ドメイン駆動設計」という名目で、内容を見ると、たった1〜2個の「ドメイン」クラスの例を挙げた後、Entity、Service、Repository、DTO、ヘキサゴナルアーキテクチャなどについて議論し始めます。どこに「ドメイン」があるのでしょうか?明らかに「企業アプリケーションアーキテクチャパターン」や「インターネットシステムアーキテクチャパターン」について語っているだけです。 様々なソフトウェア開発技術カンファレンスでも、このような光景を目にすることができます。あるEコマースサイトのアーキテクトが講演し、次に別のビデオサイトのアーキテクトが講演します。あれ、この二人は同僚なのか、講演内容がこんなにも似ているのか?実は、彼らが話している内容はすべて「D-設計」の内容なのです。その理由はおそらく話したがらないからではなく、話すことができないからでしょう。そのアーキテクトはそれしか知らず、自分が開発しているシステムのコア領域についても非常に浅い研究しかしていないのです。
1.2.4.3 偽イノベーションの氾濫
多くの開発者はDの知識しか持っていません。職務が変わり、A、B、Cの作業を行う必要が生じた場合、本来であればA、B、Cのスキルを真剣に学ぶべきです。 残念ながら、多くの人は自分の快適な領域から抜け出したがらず、意図的あるいは無意識に他人を自分の快適な領域に引き込もうとさえします。 例えば、ステークホルダーとニーズについて議論する際に、頻繁に「技術トレンドワード」を連発し、自分の「得意分野」でステークホルダーを圧倒することで、自身のビジネスモデリング(A)とニーズ(B)スキルの不足を隠蔽しようとします。 例えば、コア領域のクラスモデル(C)について議論する際に、すぐに実装方法(D)に言及したり、「性能問題は発生しないのか」(D)と疑問を呈したりすることで、自身の抽象化能力の不足を隠蔽しようとします。 こうして、彼らの好みに合わせた様々な偽イノベーションが登場します。 ある種の偽イノベーションは、A、B、Cの重要性を極力貶め、「あらゆる束縛を打ち破る」ことで若者を惹きつけようとします。例えば、「そんなに考えて何になる?結局コードを書くんだろ?」とLinus Torvaldsの「Talk is cheap. Show me the code.」を口癖のように言います。 その後、「発明家」とその追随者は、すべてを破壊することではうまくいかないことに徐々に気づき、追随者の信念は揺らぎ始めます。そこで、偽イノベーションはA、B、Cを貶めることをやめ、DからA、B、Cを妄想することで、A、B、Cの「方法論」が非常に「簡単で習得しやすい」ものとなり、Dしか知らない開発者が「非常に役に立つ」と感じるようになります。 例えば、様々なステークホルダーの利益を現場で深く調査するのは非常に面倒です。そこで、解決策として「現場顧客」を傍に置き、開発者は安心してPCの前でコーディングし、問題があれば「現場顧客」に押し付けることができます。 例えば、ドメイン知識の様々な概念や用語を真剣に学ぶのは非常に面倒です。そこで、解決策として、開発者は自分の理解に基づいて独自の「共通言語」を創造することができます。 偽イノベーションは、しばしば自分が簡単であることを直接言うことはなく、むしろ自分が非常に奥深いと主張します。宣伝にはしばしば「芸術」「禅」「道」といった言葉が含まれ、意図的あるいは無意識に宗教、芸術、玄学の方向へ誘導します。これは、退屈な数学理論や論理的推論よりもはるかに受け入れられやすいものです。もう一つの大きな利点は、一部のメディア関係者が「芸術」「禅」「道」といった言葉を聞くと興奮し、自ら偽イノベーションの宣伝隊に加わることです。 開発者は最初は非常に難しく奥深いものだと思っていましたが、いざ学んでみると、実は難しくないことに気づきます!まさに、投資が少なく、効果が早く、生産量が高く、敷居が低く、しかも儀式感に溢れています。最も素晴らしいのは、快適な領域から抜け出して苦労して学ぶことなく、「方法論」を手に入れられることです。これはDしか知らない開発者の好みにぴったりです!開発者はすぐに得した気分になり、心に大きな自信が湧き上がります。—さすが俺だ!3歳児を相手にするな、4歳児を相手にしてみろ! 偽イノベーションは「ドメイン駆動設計は銀の弾丸ではない」などと宣言することもありますが、これもさらにイメージを向上させるためです。「私は正直に満点ではないと言ったのだから、私が前に作り上げた90点のイメージは本当のはずだ」と。 各ワークフローにおける様々な偽イノベーションについては、本書の後の章でさらに議論します。
1.2.5 テストワークフローがない?
「テスト」はモデリングの検証プロセスと見なせるため、単に「テストを行う」と言うだけでなく、「テスト」が検証する内容を明確に認識する必要があります。 もし「テスト」が組織プロセス内の各システム間の協調を検証するものであれば、それは「A-ビジネスモデリング」です。 もし「テスト」が対象システムの全体的な振る舞いを検証するものであれば、それは「B-ニーズ」です。 もし「テスト」が対象システム内部の各部品間の協調を検証するものであれば、それは「C-分析」と「D-設計」です。 発見、定義、あるいは検証のいずれであっても、あなたが考えている内容が特定のワークフローの内容であれば、あなたはそのワークフローを行っています。一つのイテレーション周期において、発見、定義、検証はしばしば交錯して行われます。
1.2.6 プロジェクト管理ワークフローがない?
本書が焦点を当てる範囲は方法論に限られ、すなわちA→B→C→Dの正しい推論方法です。その推論が一人が行ったのか、多くの人が行ったのか、あるいは猫が、犬が、宇宙人が行ったのかは直接関係ありません。 先ほどの大楼の例えを再び使います。二棟の大楼がそこに立っており、地震が来た時、一棟は倒れ、もう一棟は倒れませんでした。 直接的な要因は、大楼の構造、使用された材料、所在地の地質環境などであり、これらは深遠な工学力学、流体力学、岩盤力学などの知識に関わります。これこそが、本書が研究し、解説する方法に似ています。たとえ大楼が宇宙人によって建てられたとしても、この基本法則は適用されます。 直接的な原因は理解するのが難しいことが多く、ここで注意すべきは、自分の無能さを隠すために、より理解しやすい他の原因を持ち出して話を混乱させる人がいることです。例えば、事故が起こるとすぐに「誰かがリベートを受け取った!」と叫び、調査の結果リベートを受け取った人がいなくても、作業服の色、作業員がペアで入浴したか、建設チームの会議で立っていたかなど、より理解しやすい側面から原因を探そうとします。 もちろん、ソフトウェア開発プロジェクトを成功させるためには、進捗管理、人材管理など、他にも多くの作業がありますが、これらは本書の議論の範囲外です。ソフトウェアプロジェクト管理に関する内容については、読者が専門書を読んで学習してください。
1.2.7 人工知能がABCD各ワークフローに与える影響
広義に言えば、ロジックをカプセル化したすべての情報システムを「人工知能(AI)」と呼ぶことができます。例えば、電卓は演算のロジックをカプセル化しており、2355465722232×5465768797343という入力を与えれば、ほとんどの人よりも速く結果を出力します。このように、私たちはAIを利用し、AIが特定の部分で人間に優れている状態は、数十年続いています。 ★そろばんはAIではない。知識点は第4章参照。 もちろん、ここで言うAIは狭義であり、生成AI(Generative AI)を指します。GPT-1が2018年に登場して以来、生成AIブームが今日まで続いています。 現在、Copilot、Cursor、Augment CodeなどのAIコーディング環境(またはプラグイン)が徐々に普及しており、AIはDワークフローにおいて非常に大きな助けとなっています。Dワークフローはさらに簡単になり、競争の焦点がABC(ビジネスモデリング、ニーズ、分析)ワークフローへとさらに移行しています。 一方、ABCワークフローにおいて、AIが現在もたらしている助けはそれほど大きくありません。人間はまだより大きな粒度のABCワークフローのやり方を明確に理解しておらず、ようやく進展が見え始めたところに、偽イノベーションに引きずられて後退する傾向があります。 現在、もう一つの悪い状況として、偽イノベーション界隈の「造語」「念仏」「大量の無駄話」がAIを汚染し始めています。ABCワークフローにおいて、私たちは当面、AIを「専門家」として扱うことはできず、非常に非常に賢い学生として扱い、厳密な方法論でそれを解毒し、導いていくしかありません。 本書の以降の章では、ソフトウェア開発ワークフローの各ステップを検討する際に、AI補助の内容を導入します。私たちは方法論の知識を細かく分解し、AIを訓練することで、AIが私たちに真の価値をもたらすようにします。
1.2.8 自習問題
本書には練習問題の解答は提供されていません。QRコードをスキャンするか、http://www.umlchina.com/book/quiz1_2.htmlにアクセスして自己採点してください。全問正解すれば、自然と解答がわかるでしょう。
質問1
[単一選択] 以下の記述は、ソフトウェア開発のどのワークフローに最も当てはまりますか? 各プロジェクトはいくつかの活動で構成され、各活動は多数のタスクで構成されます。1つのタスクはいくつかのリソースを消費し、いくつかの成果物を生成します。成果物にはコード、モデル、ドキュメントなどがあります。 A) ビジネスモデリング B) 要求 C) 分析 D) プロジェクト管理
質問2
[単一選択] 以下の記述は、ソフトウェア開発のどのワークフローに最も当てはまりますか?
A) 要求分析 B) コード設計 C) 詳細設計 D) 設計
質問3
[単一選択] 以下の記述は、ソフトウェア開発のどのワークフローに最も当てはまりますか? システムは会員に購入済みの商品情報を提供します。 A) 機能仕様 B) 要求分析 C) 要求 D) 要求仕様
質問4
[単一選択] 以下の記述は、ソフトウェア開発のどのワークフローに最も当てはまりますか? 祖母を訪ねる途中、李雪琴は祖母へのお年玉のために現金が必要なことに突然気づきました。彼女はまず高徳地図で近くのATMを検索し、中国工商銀行のATMを選びました。車で行ってみると、なんと道端には多くの人が現金を引き出すために並んでいました!李雪琴は仕方なく再び高徳地図を見て、人が少なそうな場所を選んで車を走らせ、ようやくATMで現金を引き出すことができました。それから、彼女はどこでご祝儀袋が売っているか考え始めました… A) ビジネスモデリング B) ユーザーストーリー C) 要求 D) プロセス分析
質問5
[単一選択] 以下のうち、モデリングワークフローABCDに属さないのはどれですか? A) 要求 B) 分析 C) 設計 D) テスト
質問6
[単一選択] 本書では、モデリングワークフローの名称は以前の方法論の名称を踏襲していますが、これらの名称は実際にはあまり適切ではありません。例えば、______ワークフローの名称は「システム責任」に変更する方が適切です。 A) ビジネスモデリング B) 要求 C) ビジネス要求 D) 分析
質問7
[単一選択] ある方法論者が、「壁に貼り付ける」よりも儀式的な「美人モデリング法」を発明しました。 例えば、ある医療・衛生分野のソフトウェア会社は、容姿端麗な女性を多数採用し、それぞれ患者、看護師、医師、料金徴収員、HISシステム、支付宝(Alipay)、微信(WeChat)などを演じさせました。顧客との打ち合わせの際、これらの女性たちに一緒に様々なシナリオを演じさせて顧客に見せました。 顧客からは口々に「このような方法は生き生きとしていて、活発で、斬新で、目に見え、匂いがあり、歯ごたえがあり、後味がよく、一石二鳥だ(追加問題:この一連のフレーズの出典は?)」と好評で、次回の打ち合わせもぜひこの方法でとリクエストされました! 質問です。美人たちが顧客に演じた内容は、どのワークフローに最も該当する可能性が高いですか? A) ビジネスモデリング B) 全体設計 C) 要求 D) 分析
質問8
[単一選択] ソフトウェア開発ワークフロー:A-ビジネスモデリング、B-要求、C-分析、D-設計。現在(2025年5月)、AI(人工知能)が最も役立つのはどれですか? A) A-ビジネスモデリング B) B-要求 C) C-分析 D) D-設計