DebTab

  • ホーム
  • DevTabとは
  • 記事一覧
    • きたえる
    • かえる
    • つくる
    • みちびく
    • たばねる
    • つたえる
かんたんログイン
Githubでログイン
Githubアカウントでかんたんにログインして、DevTabをもっと便利に使おう。

DebTab成長しつづけるデベロッパーのための情報タブロイド

DebTab

ログイン

検索 検索

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

写真市谷 聡啓

つくる

2016.09.20

ポイントポイント

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

共感した

ポイントポイント

1

取り消す

この記事に共感したら、何度でも押してこの記事のポイントをみんなでアップしよう。

自分の感想を残す

この感想は、サイトに公開されることはなく自分にしか見えません。自分の考えのログを残すために感じたことを登録し、のこしておきましょう。あとで振り返ったときに、あのとき自分はこう考えていたのかということを知ることにより、あなたの成長へとつながります。

Githubでログイン

Githubアカウントでかんたんにログインして、DevTabをもっと便利に使おう。

  • ひとつ前の記事

    「リモートワークでの1日」と「やってみて感じた3つのこと」

  • ひとつ後の記事

    シン・ゴジラの仮説を仮説キャンバスで立てる

この記事もどうですか?

「実際の利用者からフィードバックをもらう」ことを体験した話

 ギルドワークスで現場コーチとしていろいろな現場が変わっていくことや改善を支援している中村 洋です。…

きたえる

つくる

2018.12.12

ポイント
0

if文の条件式の書き方

ギルドワークスの増田です。 (前回書いたリファクタリングのエッセンスの続編です) if文のちょっとし…

つくる

2016.10.18

ポイント
2

「場合分け」の書き方あれこれ

ギルドワークスの増田です。 以前に書いたリファクタリングのエッセンスの続編です。 場合ごとのロジック…

つくる

2016.10.19

ポイント
1

シェア
  • Twitter
  • このエントリーをはてなブックマークに追加
  • Google Plus

ログインして
ブックマーク

  • Twitter
  • このエントリーをはてなブックマークに追加
  • Google Plus
  • ログイン
LINE@

新しい記事が出たときや、注目の記事などを
定期的にLINEでお知らせしていきます

LINEで登録

LINEイメージ

DevTab
成長しつづけるデベロッパーのための情報タブロイド

株式会社ギルドワークス
https://guildworks.jp
  • プライバシーポリシー
  • お問い合わせ

Copyright © GuildWorks Inc. All Rights Reserved.

ページのトップへ