DDD / Story of a Breakthrough


Breakthroughの話 (p.194)

要約

  • 導入 (p.194)
    • 投資銀行におけるシンジケートローン(協調融資)管理システムの話。
    • 業務の内容:
      • 例えばインテル社が10億ドルで工場を建てたいと思ったとして、その時のローン金額はどこか一つの金融業者("a lending company")が請け負うには、あまりに大きくなってしまう。
      • そこで貸し手はシンジケートを形成し、「機関」("a facility")を支えるための資本をプールするのだ。
      • 投資銀行は通常シンジケートのリーダーとなり、取引やその他のサービスを調整する。
      • 我々のプロジェクトはこの全プロセスを追跡し、サポートするためのものだった。
  • それなりのモデル、でもねぇ。。。 (p.194)
    • 四ヶ月前は本当にどうしようもなかったレガシーを、MODEL-DRIVEN-DESIGNに組み込むことができていた。
    • Loan Investmentが導き出されたオブジェクトで、Loanに対する特定の投資家による貢献を表しており、Facilityにおけるシェアに比例している。(図 8.1)
    • 不安な要素もあった。例えば、Facilityにおけるシェアは特定のローンに参加する際の目安でしかないということが徐々に分かってきた。
    • 通常自分のシェアに応じた投資をするが、他のメンバーと調整することもある。この仕様に対応して、モデルにLoan Adjustmentを追加した。(図 8.2)
    • この手の洗練によって、さまざまな取引のルールが明らかになる過程についていくことができた。しかし、(モデルは)徐々に複雑になっており、機能の実装をすばやく行なうことができなくなっているようだった。
    • 加えて、丸め処理に伴う不整合も問題になっていた(銀行だけに深刻)。「これはデザインに基本的な問題があることの兆候では?」
  • The Breakthrough (p.196)
    • ある時、何が問題であったのか明らかに!
      • FacilityLoanの結び付け方が実際の業務に照らして適切でなかった。
      • LoanのシェアとFacilityのシェアはお互い関係なく変化することができる!
    • 二つのシェアが無関係に変化する業務の説明。
  • A Deeper Model (p.198)
    • 深い洞察が二つ得られた。第一に、モデルにあった"Investment"と"Loan Investment"は、一般的で本質的な概念である「分け前("shares")」の特別な形態に過ぎなかったということ。
    • 数日後、「分け前」モデルのスケッチを作成。
    • Share Pieによって「分け前数学("shares math")」を導入することができた。それによって取引における分け前の計算は大幅に単純化され、この計算もより分かりやすく、簡潔に、簡単に組み合わせられるようになった。
    • しかし何より、新しいモデルが不適切な制約を取り去ったおかげで諸々の問題が解決したのだ。Loan's ShareFacility's Shareと関係がなくなった。
    • Load Investmentが消えた。実際、ビジネスエキスパートは何度となく「よく分からない」と言っており、技術的に必要なものなんだと理解していた。
    • 新しい視点によってどのシナリオも非常に分かりやすくなった。そして、新しいモデル図はビジネスエキスパートにとっても完璧に意味をなした。彼らはいつもモデル図は自分達にとってあまりに「技術的」すぎると言っていたのだが
    • 新しいモデルは本当に優れていた。本当に、本当に優れていた。
    • そしてみんなうんざりした!
  • しらふにさせる決断
    • この時、私たちが大喜びしただろうと思われるだろうがそんなことはない。期限は迫っていたし、スケジュールは遅れていた。
    • リファクタリングの鉄則は「常に全てが動くように保ちながら少しずつ」だが、このリファクタリングには踊り場の存在しない大幅な変更が必要だった。そして、当時はまだテストコードもなかった。
    • この変更は努力を要するものだし、メンバーは皆疲れ果てていた。
    • マネージャーとのやりとり
      • Q:新しいデザインで今の機能を回復するのにどの位かかるんだね?
      • A:3週間です。
      • Q:他に方法は?
      • A:あるかもしれません。しかしはっきりしたものはありません。
      • Q:次のリリースでやるという訳にはいかんのかね。
      • A:変更をしなければプロジェクトがスムーズに進みません。そして一度基盤を作ってしまったら、変更はもっと大変になってしまうでしょう。
      • Q:やるべきだ、ということだね?
      • A:政治的には不安定な状況だということは理解していますから、必要とあればうまくやるでしょう。私たちは大変疲れてはいますが、はい、よりシンプルな解決策であり、業務にはよりフィットしています。長い眼で見ればリスクは低いです。
    • ボスはゴーサインを出し、批判はどうにかしようと言ってくれた。
    • 私たちはがんばって3週間でやり抜いた。大仕事だったが、おどろくほどスムーズに運んだ。
  • 結末 (p.200)
    • 突然の仕様変更はやみ、バージョン1をリリースして、バージョン2への道筋も明らかだった。
    • バージョン2ではShare Pieの概念がシステム全体を通じた統一的なテーマになった。技術者とビジネスエキスパートはシステムについて議論する際にこの概念を使い、営業は将来の顧客に特徴を説明する際にこの概念を使用した。候補者や顧客は即座にこの概念を理解し、特徴について議論するのに使用した。これは本当の意味でUBIQUITOUS LANGUAGEの一部になったのだが、それはローンシンジケートの意義の核心を捉えていたからなのだ。

担当者のつぶやき

  • "Breakthrough"という単語は英語圏ではそれなりに良く使われるようです。
    • 新しいMacBook?があそこまで薄くなったのは一枚のアルミから本体と骨組みを削りだしているからだそうですが、その発想も"Breakthrough"と表現されていました。
  • 内容的には「気がつくの遅くないか?」という気がしますが、「違和感を感じつつチョコチョコと直してしまう」というのはありがちです。
  • 「デザインに本質的な問題がある兆候」に敏感になり、根本的な見直しをする勇気が大切なんだと思いつつ、実際に全面修正に踏み切るのもなかなか大変ですよね。。。

みんなの突っ込み


まとめ (議事録)