RDRA・DDD・アジャイル開発の統合

新しいサービスづくりにおいてバックエンドをどうするのか

サービスの新規の立ち上げだとしても、その構想によって組織の既存のデータやシステムを活用したい(あるいは、あえてしない)というテーマに向き合うことになります。例えば、新たな物品購入サイトを立ち上げようとすれば、在庫はどうする、商品管理はどうする、注文管理はどうなる、と業務寄りの検討も当然必要となります。

新たなサービスづくりの場合、ユーザーに近いフロント側の作り込みに注目が集まりがちですが、バックエンドの設計についての意思決定も、プロダクトの成長を描くにあたって重要な事案です。最初の段階で採用する方針は、「実用的な最小限の範囲の実現」だとしても、サービスが次の段階に進む場合には、どのような拡充を行うのか。

最初は既存システムと連携しない、あるいは手運用を行うとしても、サービスのトランザクションが増える次の段階では、どう運用するのか。ユーザーへの提供価値の仮説検証とともに、システムの展望についても作戦を練る必要があります。

ユーザーフィードバックが盛んで、開発・更新の速さを求められるフロントエンドの開発と、安定した管理業務の実現や既存システム・データとの整合性が重視されるバックエンドの開発とでは、取るべき戦略が異なります。

フロント側は、検証結果がより早く適用されるように、開発の方向性としてはアジャイルに。バックエンドでは、対象領域の全体像の可視化や業務ルールの整理を行わなければならない。問題は、こうした 異なる方針の開発を並行して進めていかなければならない ということだけではありません。

リレーションシップ駆動要件分析・ドメイン駆動設計・アジャイル開発の統合

新たなサービスづくりを立ち上げようとしている企業がベンチャーの場合、フロントエンドの開発をスピーディに進めることには相性が良いものですが、 バックエンド側がこれまでの事業展開で設計が置き去りになっており、手をいれるには限界を迎えてしまっている。

あるいは、歴史のある企業が、アジャイルにサービスづくりを進めていくには、 バックエンドの歴史も深く、しがらみが多く、取り回しが困難となっている。 何がどうなっているかの整理から必要となる。

企業の歴史の短い、長い両端どちらからみても、バックエンドの課題は大きい。 はじめようとしているサービス、事業が新規的であるほど、既存との兼ね合いが難しくなります (だからこそ、既存との関係性を断ち切って新規事業をはじめるという方針も取られるわけですが、この意思決定も言葉ほど容易ではないはずです)。

こうした状況において、ギルドワークスでは、 フロントエンドではユーザー提供価値の仮説検証活動およびアジャイル開発の適用。バックエンドの全体像設計に リレーションシップ駆動要件分析（RDRA） およびドメイン駆動設計の適用を模索しています。

RDRAは バリューソースの神崎さん が提唱する要件定義の方法論です。要件定義といえば、重たくなりがちなイメージがありますが、神崎さんは現場感のある現実的な取り組みを進めてこられています。

仮説検証、アジャイル開発、RDRA、ドメイン駆動設計これらを適切に使いわけ、統合するには、かなりの練度が必要になるはずです。私たちにとっても、統合運用についてはまだ実績を積んでいく段階ではありますが、それぞれの道での自信はあります。今後、継続的に情報発信をしていきます。

まず最初の発信として、アジャイル札幌さんでのイベントを開催します。
リレーションシップ駆動要件分析 ☓ ドメイン駆動設計 ☓ アジャイル開発
札幌近郊の方でご関心のある方はぜひご参加下さい。本州でも同様のイベントを企画していきたいと思います。

Photo credit: jeronimoooooooo via Visualhunt / CC BY-NC-ND