DDD Alliance!に参加して感じたソフトウェア設計と組織のあり方

手持ちの紙楽譜をフルデジタル化してiPad Proで管理だぜ！っと9月末くらいに意気込んでいたものの、iPad Pro発売までの期間に熱が冷めてしまったのに加え、お値段も結構高いのでコスパを考えてしまい、結局iPad Proを購入しない可能性が96%となった代表の国本です。

さて、個人的に昨年くらいからソフトウェアの設計技法としてドメイン駆動設計(DDD)に強い興味と関心を持っており、昨日11/10に開催されたDDD Alliance! ドメイン駆動設計をやってみた6つの現場からの報告に参加させていただきました。

リアル(リモートじゃない)勉強会に参加するのは約半年ぶり？であり、今回のDDD Allianceを通して、感じた事をざっくりと書いてみようと思います。

チームビルディングの重要性

単純に複数人で一緒にソフトウェアを開発するだけでは、チームとして機能しているとは言えず、ビジネス価値を最大化するためメンバー全員が一丸となって、同じゴールを認識し、進んでいけるような組織作り。つまりチームビルディングがソフトウェア開発の現場には不可欠だと強く実感しています。

もちろん、チームビルディングの重要性はDDDに限った話ではありませんが、開発に携わる全メンバーがドメインモデルを真剣に考え、設計、実装を進める上で、チームコミュニケーションを円滑化し、ドメインに関する知見や暗黙知を共有できる土台作りを行う。

そしてメンバー個々人の能力のみならず、お互いが高め合うことによる相乗効果を生み出すことが、DDDを現場で実践する上での一つのキーになるのではと感じています。

また、登壇者の方がお話されていた設計議論におけるファシリテーションの大切さという点については気付かされた事が多く、私自身がファシリテーターとして議論を進めていく際に「メンバーが考える場を作れているか？」「各メンバーの思い・意見を引き出せているか？」「認識ずれを解消できているのか？」というあたりは、自分自身改善の余地がまだまだあると痛感しています。

学習と実践による継続的な改善

書籍「実践ドメイン駆動設計」では、題材としてSaaS型でプロジェクト管理サービスを開発するチームを具体例として示してくれてはいますが、登壇者の方々のお話をお聞きして、実プロジェクトにおいてDDDを導入する際は、理論学習と並行して、実践で手を動かしながら継続的に理解を深めていくような改善方式が有効なのだろうと感じています。

実際の開発現場では、プロジェクトの成り立ち・背景、利害関係者間の意識や、開発に携わるメンバーのスキルセットのバラつきなど、障壁となるポイントが多々あるだけに「これが正しいDDD」というような形式的な部分にとらわれすぎずに、とりあえず小さいパイロットプロジェクトで実践しながら腹に落とし込んでいく。というアプローチが大いに有りなのだと気付かされました。

ソフトウェアを開発を行う組織としてのあり方

今回の勉強会を通して、ビジネスのコアとなるドメインに対し継続的な改善(ドメインリファクタリング)を実現するために、コード変更が容易な、しなやかな設計を実現するというDDDは、ソフトウェア開発を通じたビジネス価値を継続的に磨き上げるために必要な、恒常的な改善活動を実践する組織作りを体現していると強く感じています。

私自身もDDDに関する学習を継続的に進めながら、小さい自社のパイロットプロジェクトを対象に、DDDの導入を行い、より良い組織作りに励もうと思います╭( ･ㅂ･)و ̑̑

kuni