「DDDは右翼だ！」

この挑発的な声明 (unconf セッションを売り込み、人を集めるのに理想的) の背後で、Simon Chaveneauは、ドメイン駆動設計 (DDD) が私たちの組織 (Product-Tech) に与える影響について自問したいと考えていました。これは、Agicap での最初の非会議中に発生しました。この会議は、製品と技術の人々が集まり、議論、学習、共有、笑いを交わすことができるようにするために開催されましたが、何よりも私たちの日常生活との関係で高みを得ることができました。

アンカンファレンス中、プログラムは聴衆によって確立されます。これは、午前中の最初の「マーケット プレイス」セッションで行われます。この日の最初の本会議では、全員が付箋やマーカーを手に取り、全員の前でセッションを売り込むことができます。次に、人々はそれらをその日のプログラムに配置します (このアンカンファレンスの詳細については、この Twitter スレッドがあります)

しかし、本題とサイモンが提案した興味深いセッションに戻りましょう。

私有財産の支配？

サイモンの最初の売り込みを要約すると、IS のセクション全体がチームに属し、それぞれが 1 つまたは複数の境界コンテキスト (BC) を担当している場合、私たちは私有財産のソフトウェア バージョンに直面していないでしょうか (BC の周りに有刺鉄線があるなど)。 .)? したがって、彼の挑発的な「DDD は右翼のものです!

副次的な質問: 「機能チームに基づく組織の方が効率的ではないでしょうか? (全員がユースケースに向かう途中ですべての BC に取り組むことができます)」

ええと… このセッションは、私が最初に望んでいたよりもはるかに実り多いものであったことを認めなければなりません。なぜなら、私たちの製品/技術組織モードについて非常に興味深い議論が続いたからです。

しかし、私たちが非常に多く参加したこのセッションでたどった道のりを詳述するのではなく (別の投稿のコンテキストで説明するのは確かに興味深いことです)、私が保持していることと、この主題について考えていることを直接説明します.

いくつかの観察

• 効果的なソフトウェアとは、ビジネス上の課題に対応したソフトウェアです。整合とは、ドメイン分野から適切な用語を借用し、ビジネスの主要な概念を正しく表現し、技術的な問題によってもたらされる偶発的な複雑さを可能な限り軽減するソフトウェアを意味します。これは、3 分で説明されているように、ドメイン駆動設計 (DDD) の主な課題の 1 つです。
• コンウェイの法則は、取らないことを選択できる選択肢ではありません。私たちはそれと戦うことを試みることができます ;-) しかし、それはまだ地球上で有効です.
  コンウェイの法則は、 「(広義に定義された) システムを設計する組織は、その構造が組織の通信構造のコピーである設計を作成する」
  と述べている 1967 年の法律です。別の言い方をすれば、ソフトウェアのアーキテクチャは、必然的にそれを設計する人々のコミュニケーション モードの結果です。たとえば、3 つのチームによって開発されたコンパイラは、3 つのパスで動作するか、3 つの個別のモジュールを持つ可能性が高くなります。
• 逆コンウェイ法 (ICM) を使用すると、コンウェイの法則を制御できると考えることができます。当初、この逆の操作は、「チームが効果的にコラボレーションする能力を制限するサイロを打破する」ために賢明に推奨されました。しかし、何年にもわたって、「ターゲット アーキテクチャに到達するために組織を変更する」というばかげた推奨事項に変わりました。ばかげているのは、「文化は朝食で戦略を食べる」ということを覚えているからです。詳細については、その興味深いスレッドをご覧ください。
• ドメイン駆動設計は組織を強制しません。それは、組織が機能不全に陥った場合（チームが戦争中またはお互いを無視している場合）を含め、生存を可能にする鍵を与えます。DDD は、力の問題やチーム間の社会問題を理解するのに役立ちます。その結果、それはむしろ私たちの決定論に対する解放のツールです (したがって、私が言う左翼のツールです;-)
• 一方、DDD は、ドメインに関して可能な限り調整された効率的なソフトウェアを設計できるツールを提供します。その中には、Bounded Context (BC) の概念があり、モデルを用途に合わせて設計し、それらを取り囲み、他のコンテキストから生じる混乱/偽の友人/誤解から保護することを提案しています。
• 整合性と効率性を高めるために、DDD は、ソリューションのビジョンとモデリングに定期的に挑戦することも強くお勧めします。それはまた、ひらめきの瞬間に続いてモデルに革命を起こし、時々変更することを意味します (デザインのブレークスルーと呼ばれます)。そのため、ここでコンテキスト マップ セッションを定期的に開催し、製品担当者と一緒にフィールドのビジョンを常に改善しています。
• 開発チームのバランスは脆弱です。開発チームが本当に効果的になるには、約6か月の同居と対人関係が必要です. このチームに 1 人の人物を追加または削除すると、そのチームは同じチームではなくなります (動的なリチームを参照してください)。効率性という点では、主題に応じて爆発/再分配されるだけのチームよりも、一緒にいて主題を変更するチームが好きです。もちろん、誰かが自分のチームや主題にうんざりしている場合は、チームを変更できるようにするためにあらゆることを行う必要があります (私たちの全体的な効率にとって、個人的に健康であることはさらに重要です)。
• ここAgicapの現在の組織とチームは、問題の複雑さを考慮し、それぞれのビジネス専門知識を最小限に活用するために、1つ以上の境界コンテキストに所属しています. 場合によっては、一部のチームの範囲が広すぎる場合があり、境界付けられたコンテキストをより適切にカットして割り当てる必要があります。一方で、BC のこの区分は、ビジネス コンセプトに関連付けられたままにする必要があります (DDD を思い出してください)。
• 誰もが Bounded Context の境界を尊重している限り、DDD を行う組織に機能チームを持つことを禁止するものは何もありません。
• 当面の間、私たちはスウォーミング(いくつかのチームの人々で構成されるタスク フォースのようなものですが、最終的なアーティファクト (ツール、API、ライブラリ) の説明責任と所有権が最初から定義されている) の実践を大いに好みます。 「よし、一緒に何かをやったけど、今は誰がそれを維持するの?!?」というシンドロームを避けるため)。スワーミングは、テーマに応じて適切な人々に協力してもらう効果があるだけでなく、一時的にチーム間の対人関係を促進することで、組織に多くのソーシャル キャピタルをもたらします(将来、全員がチームに戻ったときに非常に役立ちます)。
• 私たちの現在の製品組織は、開発チームごとに 1 人の製品マネージャー (PM) に設定されていますが、おそらく、PM がチームよりもビジネスの主題に関連していると興味深いでしょうか?

最後に、開発部門ほど組織部門に特効薬はありません。継続的なフィードバック、質問、および実験は、ユーザーに関連するソフトウェアを効果的に作成するための継続的な改善の道のりにおける私たちの仲間です。

注: この投稿は、先週 (2022 年 10 月 14 日) に書かれたフランス語の記事の翻訳です。

Agicap の詳細については、次をご覧ください。

• あなたのドメインを見せてください (キャッシュ フローの監視と予測のコンテキスト マップ セッション)
• https://agicap.com/
• https://career.agicap.com/