アジャイル×DDD×アーキテクチャ

北條育男

yhojo@pp.iij4u.or.jp

2/36

自己紹介

ソフトウェアエンジニア・プログラマ

フレームワーク・エンジニア

アジャイル開発（反復型システム開発）

Webベース基幹業務システム

トランザクション制御、通信ミドルウェア

Growth xPartners 非常勤取締役 技術統括本部長

3/36

Agenda

これからのシステム開発に求められること

アジャイル開発

DDD(Domain Driven Development) アーキテクチャ

ツールの利用

これからのシステム開発に求められること

5/36

これまで信じられてきたシステム開発

決められた期日まで

決められたコスト

決められた要件

トップダウン？

ボトムアップ？

規模？

ソフトウェア・システムを必要とする側にも提供する側にも非常に過大な能力が要求される。

防御的な力が働きすぎ、身動きがとれなくなる。

6/36

機敏であること 柔軟性 社会状況に対応する 現場の状況に沿わせる

安定性 成果を安定させる ソフトウェアの動作を安定させる

持続性 開発 ⇔ 運用 人的依存性

その他の特性 効率、容易性、モジュラリティ・・・

7/36

機敏であるための基本戦略 作業工程（プロセス）の緊密化 問題発生への早期対処 適切な調整

作業サイクルの最小化 作業の平準化 工程の組み替え自由度

円滑なコミュニケーション 作業効率化 見える化 関係者間で問題の構図や目標を共有する

こうした特徴の組み合わせによって柔軟性と安定性が両立する。

8/36

ソフトウェアシステムのライフサイクル

着想から実現へ、そして適切な改善サイクルへ

これらの流れを支えるのが「どんなシステム（業務）なのか？」というイメージ

イメージを具体化するための仕組みが「モデル」

関係者の間で適切に「モデル」を共有する事が重要

アジャイル開発

10/36

アジャイル開発の多様性

アジャイル開発には非常に多様な流儀がある。 XP Scrum Adaptive Development Methodology

(SalesForce.COM)

組織の文化や歴史に合わせて多様であるべき

どんな風に始めるのか？

どんな風に続けてゆくのか？

どんな風に発展させてゆくのか？

11/36

初期のアジャイル開発

職人的なエンジニアの開発スタイル

技術的な難易度が高い

プロとしての高度な態度を身につける

ユーザの役割は大きいが、関わりは小さい

オンサイト・カスタマ（ユーザ代表を開発現場に）

開発体制の確立と利用現場への導入が難しい

12/36

Scrum開発

開発プロジェクトの役割モデル

チーム、スクラムマスター、プロダクトオーナ

工程や作業内容

バックログ、スプリント、スクラム会議

アジャイル開発プロジェクトの様々な物事について名前をつけ、その関係性を定義している。

一定の型にはめることで、多くの知見を利用できるようにしている。

13/36

アジャイル開発の特徴

作業工程（プロセス）の緊密化

作業単位やPDCAサイクルを小さくする

タイムボックス管理（平準化）

作業状況、作業結果の共有

動作するプログラム

プログラムの状態の見える化

作業管理票(Issue Tracking Systemなど) メタファ、モデルの共有（オンサイト・カスタマ）

14/36

アジャイル開発とモデル

正式のドキュメントよりも、コミュニケーションと動作するソフトウェアを重視する。

初期のアジャイル開発ではメタファを非常に重視した。 XPを学ぶときに最も理解が難しいのがメタファ

ソフトウェアをどんな物にするのかを共有（合意）するための「例え」

ユーザにも開発エンジニアにも理解できる「何か」にシステムを例えることで意思疎通の基礎とする。

ユーザストーリー

動作するソフトウェア

コミュニケーション、議論のためのモデル

手順よりモデル

15/36

モデルとは？ 概念、考え方 クランク、シュミレーション、3Dモデル、複式簿記、生産管理

どのように表現するか？伝えるか？ ER図、UML、モックアップ、ガイドブック、ホワイトボード、メモ・・・

モデリングの目的 何を作ろうとしているのか？

どんな問題があるのか？

コミュニケーションの基礎としてのモデリング

動作するプログラム

16/36

クランクを説明してみる

「機械の要素の一つ。回転する軸とそれとは芯のずれた軸を結ぶ柄からなる機構」 Wikipedia

状況（コンテクスト）によって見る部分や考え方が異なる

設計、鋳造、加工、仕上、組付け、修理、車を買うとき。

誰に伝えるのか？

17/36

モデリングで大切なこと

仕様を愚直に形式化することではなく、「どんな物をつくるのか？」について良いコミュニケーションの基礎を作ること。

Domain Driven Development（ドメイン駆動開発）

19/36

変化を抱擁せよ

関係者の学びによる変化

稼働したシステムの外部環境による変化

サブシステムの統廃合による変化

変化に対する反応性を安定させる

実装や仕様をシンプルに保つ（ノイズの除去）

システムのイメージにシステムの構造を合致させる

一貫してユーザの言葉でシステムを構築する

20/36

システムのイメージに構造を合致させる

ユーザからのフィードバックに応えるため

できて当たり前のことに対応できるようにする

「びっくりしない」の法則

文書駆動（ウォータフォール）

要件→仕様→設計→実装→テスト

動作するプログラム

計画→変更→検証→分析

動作するプログラムはモデルとしての機敏性が高い

21/36

モデリングの基礎としてのユビキタス言語

言語＝語彙＋構文

モデルは語彙と構造によって作られている

語彙のギャップをなくす

ユーザ部門間での語彙のばらつき

開発エンジニア間での語彙のばらつき

論点を明確にして議論を活発化する

ユーザの知見と情報工学の知見の両者を統合する

22/36

モデルを改善する

モデルをシンプルに保つ

モデルの構成要素の統廃合を行う

新たな仕組みを試行する

モデルが自身に課す制約を調整し、必要な自由度を得る

23/36

リファクタリング

稼働するプログラムを稼働する状態を保ったままオーバーホールする技法

モデルや稼働中のシステムにも応用可能

稼働する状態を保つために多数の手順に分解して実施される。

個々の手順はPDCAサイクルに基づいたプロセスで実施

語彙と構造を統合する作業

24/36

一致させる為のコスト要因

不十分なコミュニケーションで混入したノイズ モデルが関係者に対して十分にシンプルでない

システムに対するイメージに混入したノイズ 学習が不十分であるために発生する

プログラムの実装上の都合により混入したノイズ 実装技術が不十分であるために発生する

多くのコスト要因はTPSで改善できる ずれた物を合わせるのは大変

なぜを５回 5S 需要を生み出す

25/36

部分最適化と全体最適化

各システムの最適化

より大きな括りでの最適化

粒度の違いはあっても、語彙と構造の統合を段階的に進めるという意味で同じ

アーキテクチャ

27/36

建築のアーキテクトの役割

多様な人々による多様な生活が行われる場の構造をデザインする

間取りや材質、空間のあり方や工法についての深い理解とこれらを統合する力が要求される。

28/36

ソフトウェア・アーキテクトの役割

システムの置かれた文脈（コンテクスト）に沿って構造を（仮に）決める

システム開発の初期段階でプロジェクトに語彙と構造を与える

ユーザ部門の状況やビジネス環境を理解して、それらをプログラムに反映できるような仕組みを作る

多様なスペシャリストを利用する

プロジェクトの内部はもちろんのこと、外部にも働きかける。

29/36

アーキテクチャとモデル

モデルは外部の構造と呼応して決まってゆく。

コンウェイの法則

ソフトウェアのどの部分であれ、それを作った組織の構造を反映する

アーキテクトはソフトウェア開発に関わる様々な「モデル」を仮決めする事で、構図を与えて自立的な改善のプロセスを立ち上げる。

30/36

開発プロセスのアーキテクチャ 非常に多様なツールを組み合わせて使う Issue Tracking System(チケット管理）、ソースコード・レポジトリ、

CI（継続的統合）、Enterprise Wiki(文書管理）、コード自動生成

可視化する仕組み、調整して決定する仕組み

複雑なシステム構成 ミドルウェアやツールの導入は多量の制約を課す

制約は物事を標準化する

プロセスを立ち上げる どんな風に始めるのか？

どんな風に続けてゆくのか？

どんな風に発展させてゆくのか？

31/36

アーキテクトはどこにいるのか？

アーキテクトに要求される技能は、開発チームのすべてのメンバーが持つべき技能

アーキテクトは、チームを正しい方向に向かわせる事に注力する

スクラム・マスター

ツールの利用

33/36

ソフトウェアは見えない

ソースコードの状態を一元的に観察することはできない

開発中、稼働中のソフトウェアの問題点は視点によって様々な形で現れる

お仕着せの判定基準は通用しない

規律によって、定型化し異常を早期に検出する事が重要

規律が破られつつあることを機械的に日々確認する

要件が規律を超えつつあるのか？単純な間違いか？

34/36

JIG Framework 治具を使ったソフトウェア開発 プロジェクト規約に沿った実装を支援する

モデルを実装の基礎に位置づける

用語辞書をベースに語彙と構造に該当するプログラムコードをモデルデータから自動生成 コミュニケーションミスの低減

実装作業効率の向上

モデルによる実装のチェック

検査主義に陥りがちな設計・実装工程で品質の作り込みを実施

35/36

DDDとJIG Framework レイヤード・アーキテクチャ

ベース部分にモデルデータから生成された語彙・構造のコードを利用

Presentation

Service

Business Logic

ORM

DB

Presentation

Service

Business Logic ORM

DB

Domain Model

一般的なレイヤー構造 JIG Frameworkでのレイヤー構造

36/36

最後に

考えることは重要だが、行動しなければ何も変化しない

違和感を言葉にすること、話し合って行動に移すこと