用語集

サービス紹介に出てくる用語を、役割と活用場面から説明します。

RDRA（ラドラ）

業務とシステムのつながりを可視化し、要件を整理する手法です。 Relationship Driven Requirement Analysisの略です。

利用者、業務の流れ、扱う情報、システムに求める振る舞いを関連付けて整理します。要件の抜けや矛盾を確認したいときや、既存システムの全体像を共有したいときに役立ちます。

例えば予約システムなら、「誰が予約するか」「空き枠をどう決めるか」「キャンセル時に何が変わるか」をつなげて考えます。この例は説明用です。

業務の知識やルールを、ソフトウェアの設計の中心に置く考え方です。 Domain-Driven Designの略です。

業務に詳しい人と開発者が共通の言葉で話し、業務の概念をモデルに表します。複雑な業務を整理し、異なる責務や意味を持つ領域の境界を考える際に使います。

例えば「顧客」という言葉でも、営業と請求では必要な情報やルールが異なります。その違いを捉えて設計します。

業務で起きる出来事を付箋などで並べ、関係者が一緒に業務の流れや課題を探るワークショップ手法です。

「注文が確定した」「代金が支払われた」などの出来事を起点に、誰が何を判断するのか、どこで例外が起きるのかを話し合います。職種や担当領域の異なる人が、共通の理解をつくるために使います。

業務全体の把握からシステム設計まで、目的に応じて進め方を変えます。DDDのモデルや境界を考える際にも活用できます。

情報を更新するモデルと、情報を参照するモデルを分けて設計するパターンです。 Command Query Responsibility Segregationの略です。

更新側では業務ルールを守り、参照側では画面や検索に必要な情報を取り出しやすくします。例えば、注文を確定する処理と、注文一覧を表示する処理を、それぞれの目的に合わせて設計します。

同じデータベースを使う構成もあり、データベースやサーバーの分離が必須ではありません。Event Sourcingとは組み合わせられますが、別のパターンです。導入によって複雑さも増えるため、対象領域の課題に見合うかを判断します。

状態の変更を一連のイベントとして保存し、その記録をもとに状態を組み立てる設計パターンです。

例えば現在の注文情報だけを保存する代わりに、「注文を受け付けた」「商品を追加した」「注文を確定した」という変化を記録します。イベントを順に適用することで、状態を再構築できます。

変更履歴の追跡や、記録からの状態の再構築が必要な場面で役立ちます。一方、イベント形式の変更や再処理、外部システムとの連携には設計が必要です。単にログを残すことや、メッセージを送受信することとは異なります。

Event Stormingは業務を探るワークショップ、CQRSは更新と参照のモデル分離、Event Sourcingは状態の記録方法です。目的が異なるため、それぞれ独立して採用を判断できます。

AIとの協働を前提に、要求・設計・実装・検証などの開発工程を組み立てる方法論です。 AI-Driven Development Life Cycleの略で、AWSが提唱しています。

AIが作業や成果物の作成を進め、人が判断・確認する役割を担います。チームでAIを使う際の進め方や、確認すべき点を揃えるための土台になります。

AIが作り、人が読んで判断する。通れば次へ、通らなければ作り直す。この往復が承認ゲートです。

役割の入れ替わり、工程ごとの承認ゲート、設計が重要になる理由は、AI-DLCとはで図を使って説明しています。

何を作り、どう動けばよいかを仕様として明らかにし、それをもとに実装と検証を進める開発の進め方です。 Spec-Driven Developmentの略です。

AIとの協働では、仕様が指示と確認の共通の基準になります。曖昧な依頼による認識のずれを減らし、生成されたコードが要求を満たすか確かめるために使います。仕様も、実装で得た知見や要求の変更に合わせて更新します。

AI-DLCは工程ごとに人が判断する仕組みですが、判断するには根拠が要ります。仕様駆動開発は、その根拠を仕様という形で持つやり方の1つです。別の系譜から来た考え方であり、AI-DLCの構成要素ではありません。仕様駆動開発だけを先に取り入れることもできます。

次の工程へ進めたり、変更を取り込んだりする前に満たす確認条件です。 このサイトでは、テスト・静的解析・レビューなどによる品質確認を指しています。

例えば「テストが通る」「重大な問題が残っていない」「担当者が設計を確認した」といった条件を、対象とする開発に合わせて決めます。自動検査と人による確認を組み合わせます。

承認ゲートは、人が成果物を確認して先へ進めるかを判断する区切りです。品質ゲートと組み合わせることで、確認内容と判断の責任を明確にできます。ゲートの通過だけで、不具合がないことを保証するものではありません。