要求から詳細設計までをシームレスに行うアジャイル開発手法
Agile development technique to perform seamlessly to detailed design from the requirement
藤原 啓一＊Keiichi Fujiwara

ソフトウェア設計とは、要求を、各開発フェーズごとに適した粒度で詳細化していく作業である。
本稿では、あるアジャイル設計手法を例に、ソフトウェア要求分析〜ソフトウェア詳細設計までシームレスに繋ぐ仕組みを示す。特に、方式設計を機能と非機能に分けて記述することで、ソフトウェアアーキテクチャの本質である非機能の実現方式を浮き彫りにすることを特徴としている。
Software design is work to make the software requirement detailed by a granularity suitable ineach development phase. This paper shows the mechanism based on an agile design approachthat connects software requirement with software detailed design seamlessly. In particular, it ischaracterized in that highlight the implementation method of a non-functional in the essence ofsoftware architecture by describing divided into functional and non-functional features.

ウェア要求分析の方法論まで拡張したものである。ま1．まえがき

た、 特 定 分 野 で し か 成 功 し て い な いMDA（Model

ソフトウェア製品を作る過程で作られる、仕様書・設Driven Architecture：モデル駆動アーキテクチャ）の計書、テストや障害記録、ソースコードなど、その関連考え方を、一般的なソフトウェア開発に対して可能な限を 相 互 参 照 で き る 仕 組 み を、 ト レ ー サ ビ リ テ ィり取り入れた。それは、各フェーズ内の設計をモデリン（traceability：追跡可能性）と呼ぶ。しかし、有効活用グ作業と考え、フェーズ間の繋ぎをモデル間の連携と考できるトレーサビリティの作り方が分からない、その効えて、上流から下流まで設計をシームレスにつなげると果を実感できない等の理由から、設計現場はそれを積極いうものである。
昨今、多くなっている派生開発では、ソフトウェアア的に作成・維持したがらない。
一方で、ソフトウェア開発現場においては、個々人のーキテクチャ設計（後述の基盤方式設計）やクラス設計生産性の差が５倍以上（時に10倍以上）となることが普を経験することが無い為、その方法を知るエンジニアが通に起きている。経験の浅いソフトウェアエンジニアの育たず、いざ、新規開発となると問題が発生するという困っている部分を紐解いてみると、作ろうとしているプ声を聞く。このような環境的な課題に対しても、本手法

ログラムの上位設計書として何を見れば良いのか、どのは具体的手順を示しているので、設計方法の疑似教育と部分を仕様として捉えれば良いのかが分からず苦労してして有効利用することができると考える。

いることも多い。これは、システムの理解不足や設計手2．ソフトウェア設計手順の概要

法の習得不足が原因で、解決としては、例えば、当該プログラムに関係する機能方式設計書の該当箇所と詳細設ソフトウェア要求をプログラムに展開するソフトウェ

計書の対応（トレーサビリティ）を担当エンジニアに実ア設計手順を図2-1に示す。今回示すソフトウェア開発施させ、有識者がそれをレビューするといったことが必

手法は、汎用系の表現として図2-1に示しているが、下要である。

記のとおり、プロセスの一部を修正することで、汎用系（業務系）、組込系のどちらにも使える開発手法となって本稿では、上記の設計手法に関する課題を解決できるいる。

よう、トレーサビリティの確立が設計作業の中に組み込まれたアジャイル設計手法を示す。本手法は、アジャイ
ル 設 計 手 法 の １ つ で あ る、FDD（Feature DrivenDevelopmen：ユーザ機能駆動開発）をベースにソフト＊関西事業部 第三技術部
1

MSS技報・Vol.24
This document is provided by JAXA.

図2-1

ソフトウェア設計手法の流れ

本手法はモデリングを中心にシステムを開発していく

3.1

業務フローとユースケースの対応関係考えを取り入れているので、MDAの分類も示した。

業務フロー中の１業務（業務フロー内の□に相当）にCIM（Computation Independent Mode）は、ドメイン対して１ユースケースを対応付ける。そして、１ユースに着目して開発するモデルで、コンピュータの処理方式ケースごとにユースケース記述を作成する。ビジネスルは取り扱わない。PIM（Platform Independent Model）

ールは、業務フローの判断や、組織で決められている規は、実装技術は特定せずにドメインの中で使用される処則等から抽出し、ユースケース記述と紐付ける。

理 方 式 に 着 目 す る モ デ ル で あ る。PSM（PlatformSpecific Model）は、実装技術を特定した上で詳細化するモデルである。
本設計手法の各開発フェーズにおいて採用している設計アプローチは、以下のとおりである。

3．ソフトウェア要求分析
要求仕様は、①業務フロー、②ユースケース（とユース ケ ー ス 記 述）、 ③USDM（Universal Specification

また、業務フローのスイムレーンごとに定義してあるDescribing Manner）、④ビジネスルールの４つで構成「役割」が、ユースケースのアクターになると考える。

される。

組込系の場合、ユースケースは、主要なイベント対応で作成する。

2

MSS技報・Vol.24
This document is provided by JAXA.

図3-1

3.2

USDMの形式

ソフトウェア機能仕様

3.3

ユースケースとUSDMの対応関係

機 能 仕 様 書 は、USDM（Universal Specification

ユースケースは、アクター（ユーザ）が、システムのDescribing Manner）を使って記述する。USDMの形式

中をブラックボックスとして、システムの外側から見えは図3-1に示す。USDMの特徴は、①要求と仕様を分離るシステム振る舞いを表現したものである。USDMは、する様式となっていること、②要求と複数の仕様の対応システム内部の振る舞い（例：データ変換仕様等）を表が分かり易いこと、である。

現したものである。
ユースケースとUSDMの関係を図3-2に示す。

図3-2

ユースケースとUSDMの関係

3

MSS技報・Vol.24
This document is provided by JAXA.

ユースケースとUSDMを対応づけるルールは以下の4.1とおりとする。

基盤方式設計要件は、機能要件と非機能要件から構成される。非機・ユースケース名（ユースケース全体）をUSDMの上能要件は、制約と品質を含む。そして、非機能要件の客位要求に対応づける。

観的な尺度として品質特性（品質属性とも言う）を導入

・各ステップはUSDMの下位要求あるいはグループにする。品質特性は、いくつかの種類に分類できるが、こ展開する。

こでは、６種類（可用性、変更容易性、性能、使いやす・各ステップの実現方法を仕様に展開する。

さ、テスト容易性、セキュリティ）を使う。

アクターの振る舞いステップの仕様としては、システ

基盤方式では、静的構造（モジュールビュー）、動的ムがそのイベントに反応して動作する条件、イベントの構造（コンポーネント・コネクタービュー）、配置的構インタフェース仕様、イベントを受けた直後に行うシス造を表現する。静的構造とは、時間に関わらず変化しなテムの振る舞い等を考える。アクターとシステムの振るい構造であり、レイヤ関係、クラス、関数等の定義、実舞いを別れた要求と考えて、仕様を考えるのが難しい場

行時のタスクやリソースの構造である。動的構造とは、合は、それらをひとまとめの要求として仕様を考えるの静的構造に現れる要素（クラスやタスク）の相互作用、が良い。

つまり望ましいシステムの振る舞いの表現である。そして、基盤方式設計項目が１対１に非機能要件に対応する

4．ソフトウェア方式設計手順

ことはなく、複数項目の組合せで、非機能要件を満足す

ソフトウェア方式設計は、大きく「基盤方式設計」とることになる。逆に、ソフトウェア構造（静的／動的）「機能方式設計」の２つに分けて行う。設計書も２つには、性能、信頼性、保守性など、ソフトウェアのさまざ分けるのが良い。

まな品質特性を決定づける要因となっている。
この様子を図4-1 基盤方式設計書の記述内容に示す。

図4-1

基盤方式設計書の記述内容

4MSS技報・Vol.24
This document is provided by JAXA.

図4-2

設計カタログの例

基盤方式設計は、主として非機能要件（品質属性）を4.2

基盤方式設計を効率化する設計カタログ

実現する具体的な仕組み（How）を表現するソフトウ

事前に、品質特性項目毎に、図4-2に示す「設計カタェア構造（タスク構造、ファイルの分割構造、重要な処ログ」を準備しておくと、そこから仕組みのヒントを得理手順）を設計するものであり、次の２つの作業を行ることが容易になるとともに、設計の知恵を流用するこう。とができるようになる。

⑴

非機能要件を満足する為に必要な設計上の方針、制約事項や設計上まもるべき原則、メカニズムの設計

4.3

パターンを示す。
⑵

次に、それらを踏まえた上で、非機能を満足するソ出力が得られるかという、『入力から出力への変換』とフトウェア構造はどうあるべきかをして定義される。機能方式設計は、この機能要求を満足み具体的な仕組として表現する。

する概念的な（論理的な）構造や振る舞いを明確にする

ここで重要なのは、次の３点である。
⑴

作業である。ただし、入力に対してとにかく出力すれば基盤方式は、ざっくりとした雰囲気（方針）を伝え良い、とういうことではなく内部状態に応じたリアクテるものではなく、開発、保守において具体的な判断

ィブな振る舞いに関する記述は必要となる。の拠り所となるべき内容でなければならない点であ機能方式設計の目的は次のとおりである。

る。例えば、例外処理に考慮すべきコーディング規・ユースケースを実現するために必要なオブジェクトや約まで含めた汎用的な準正常処理を記述しておき、⑵

機能方式設計機能に対する要求は、典型的には入力からどのようなクラスを識別する。

詳細設計者すべてに考慮させる等。

・必要なオブジェクトやクラス間の関係を識別する。

非機能要求と基盤方式設計の記述内容のマッピング・属性や操作を識別して、それらをクラスに割り当て表は、必ず作成して設計書に入れる。これが、非機る。

能要求をどのような設計で実現したかのトレーサビ・分析シーケンス図を使用して操作の振る舞いを特定すリティ・マトリクスとなる。マトリクスの中に書かる。

れている黒丸（●）は、適用重要性によって、高／中／低と区別するのが望ましい。
⑶

4.4

機能方式設計と基盤方式設計の関係

具体的なメカニズムを考える際の検討資料（トレー機能方式設計で表現される概念的な構造（本書では、ドオフ表等）は別資料として起こし、該当箇所から後述のロバストネス分析図）は、より複雑性を排除する参照できるようにする（これが真のノウハウであた め に、 基 盤 方 式 設 計 で 示 すCRP（The Commonる）。

Reuse Principle： 共 通 再 利 用 原 則）、CCP（The5MSS技報・Vol.24
This document is provided by JAXA.

Common Closure Principle：共通閉鎖原則）、凝集度と5.1

ソフトウェアのレイヤ構造

結合度等の設計方針に従って、サブシステムやパッケー現在、ソフトウェアを開発する場合、要件変更への設ジにまとめ直す必要がある。その結果は、機能ブロック

計・実装の変更の容易性、拡張性、等々の理由により、図等で表現する。そして、個々の機能は、基盤方式設計

システム全体を論理的な階層（レイヤ構造）に分け考えで採用した「プラットフォームが提供するメカニズム」るのが一般的である。機能と論理構造の違いに注意のこと。

（例えば、アーキテクチャパターン、割り込み機能、OS

各論理的階層の名称／分け方（階層数）は、人によりの提供するタスク、プログラミング言語の提供するクラ様々な名称／分け方（階層数）で呼ばれているが、ここスや関数など）と対応付けて、詳細設計（後述）におい

では、情報系ソフトウェアのレイヤ構造例を示す。以て、実際に動作する実現構造とするのである。

降、この名称で説明する。

変更容易な構造を導くことを例に説明する。変更容易性を実現するには、まず、開発されたソフトウェアが対象とする世界を理解し、どのような変更を容易にするのかを明確にする。
次に、ソフトウェアの論理的な構造の作り方の方針として、以下のことを、基盤方式設計で示す。
①ソフトウェア構造化の方針決定
・想定する変化に容易に対応する為の方針
・変更が想定される機能や情報を局所化するメカニズム②設計上の技法の選択・決定された構造を実現する為の技法の決定
・デザインパターンの適用方針
4.5

図5-1

階層アーキテクチャ

表5-1

論理的階層の役割説明

機能方式設計と基盤方式設計の進め方

機能方式設計と基盤方式設計は相互に関係しあって並行に進める。その設計作業の進め方と内容を図4-3に示す。

図4-3

機能方式設計と基盤方式設計の進め方

5．基盤方式設計の内容例
非機能要求の実現方式を表現する基盤方式設計において、検討すべき内容の具体参考例として、レイヤ構造、イベント検知の仕組みの２つを示す。

6MSS技報・Vol.24
This document is provided by JAXA.

5.2

イベント検知の仕組み

機能と非機能の違いを表す例として、イベントが発生したら、何らかの処理を行うソフトウェアについて考える。機能的に見ると、どちらも、イベントの発生をトリガーとしてデータ処理を行うものであり、違いはない。
非機能的には、イベント発生から処理を行うまでの応答性の違う２つの方式が考えられる。
（1）は周期的にイベントを監視し、イベントの発生を検知したら処理を行う構造である。
（2）はイベントの発生で割り込みを起こし、割り込みハンドラやそれが起動するタスクで処理を行う構造である。

ロバストネス分析は、レイヤを意識せずに行い、後述するシーケンス図で、オブジェクトのレイヤ割り付けを6．機能方式設計手順の詳細行う。

機能方式設計では、機能を構成する論理構造（コンポーネント）を明確にすることから始める。その基本は、意

6.1.2

ロバストネス分析図作成の粒度

味的にひとまとまりの処理、ひとまとまりの情報をできロバストネス分析図は、ユースケースに対応させて作るだけ同じコンポーネントにまとめるということであ成する。つまり、ユースケースひとつに対して、ロバスる。これは、ロバストネス分析を利用して行う。

トネス分析図を１つ作成する。

6.1

6.2

6.1.1

ロバストネス分析
ロバストネス分析図とはユースケース／USDM仕様／ロバストネス分析図の関係

ロバストネス分析図は、アプリケーションに要求されロバストネス図はユースケースをオブジェクトの絵とる機能を、バウンダリ（画面、印刷）、コントロールして表現したものである。つまり、ユースケース記述と（機能）、エンティティ（データ、ファイル）に分類し、機能仕様であるUSDMから、アプリケーションの機能それぞれの関係、振る舞いを表現するものである。

コンポーネントの構成（関連）を決めるのがロバストネ
ス図であると考えることができる。ただし、ロバストネ

7

MSS技報・Vol.24This document is provided by JAXA.

ス図では、アプリケーションを「どのように」実行する

6.3

分析シーケンス図作成

かではなく、アプリケーションに「なに」をさせるかに⑴作成の目的焦点をあてている。

分析シーケンス図は、ユースケースを実現するためにユースケース（ユーザ要求）とUSDM（機能要求）必要なオブジェクト間のやり取りを時系列に表現したもとは、3.3章で示した関係で繋がっている。従って、ロのであり、ロバストネス分析図に出てきたクラス及び、バストネス分析のコントロールとUSDMの仕様のトレそれを補完する主要なクラス間の関連、クラスの属性、ーサビリティを取ることで、コントロール仕様、すなわ操作を見つけ出すために作成する。

ち、コントロールが「なに（what）」を行わなければな

この分析シーケンス図は、実装を忠実に表すものとしらないかが明確になる。そして、この仕様に基づいて、て、ロバストネス分析図で登場した、すべての論理的なソフトウェア詳細設計では「どのように（How）」実行

静的クラスに加えて、ソフトウェアの実現に必要な新たするかの実現方法を考える。この関係を図6-1に示す。

なクラスも登場させて、それらの振る舞いを表現するも文章のみで記述されている機能方式設計書では、要求のである。

仕様に記述している内容の多くを再記述している場合も⑵多く見られるが、この設計手法では、USDMに要求と仕

具体的な作成方法
ロバストネス分析図とそれから分析シーケンス図の関様を集約し、参照関係（トレーサビリティ）を用いるこ係を図6-2図に示す。とで、二重に記述することを防ぐことができる。

アプリケーション機能の動的な振る舞いを分析する為

また、ロバストネス分析図を作成している最中に、ユに、ロバストネス図の構成要素である、バウ ンダリースケース/USDM仕様の曖昧さ、矛盾点に気がつくこ（B）、コントロール（C）、エンティティ（E）をオブジとが多々あるので、それらを、確実にフィードバックしェクトにしたシーケンス図（分析シーケンス図）を作成てユースケース/USDMを修正することが重要である。

する。

図6-1

ユースケース記述／USDM／ロバストネス分析図の関係

8

MSS技報・Vol.24
This document is provided by JAXA.

まず、エンティティが、どのレイヤ内に位置するのか

6.4

レイヤ内の構成要素の設計を考える。そして、エンティティを、ドメイン層のクラレイヤごとに割り付けられたオブジェクトの静的モデル

スか、データアクセス層のクラスかに分類する。シーケ作成を行う。ここでは、アプリケーション層とドメインンス図は、左から右に流れるので、バンダリ、コントロ層に関して、設計の進め方を示す。

ール、ドメイン層のエンティティ、データアクセス層のエンティティの順番に並べる。

6.4.1

アプリケーション層の設計

コントロールとエンティティを結ぶ線は、それぞれのアプリケーション層は、アプリケーション層以上の上クラスのメソッドに相当するので、これをシーケンス図

位層にとって『価値のある小さな機能のかたまり』であのメッセージで表現する。コントロールは、アプリケーるサービス（以降、フィーチャーと称する）がその構成ション層のクラスの主メソッド（サービス）になると考要素となる。フィーチャーが、独立性の高いアプリケーえる。

ション機能をプログラムとして実現する単位となる。つ⑶まり、フィーチャーは、サービスクラスの責務（≒そのシーケンス図の作成単位ロバストネス分析図ごとに、シーケンス図を作成すクラスの主メソッド）を表している。フィーチャーは、る。ただし、エラー処理を記述したい場合、対応するシロバストネス分析図のコントロール（オブジェクト）のーケンス図は複数枚になっても良い。

中から抽出する。

ユースケースとロバストネス分析図は、１対１に対応⑴

フィーチャー概念の定義しているので、結局のところ、ユースケースの独立性

フィーチャーは、が、分析シーケンス図を過不足なく記述できるかどうか〔目的語（オブジェクト）〔〕結果〕〔動詞（アクション）〕に影響を与えることになる。

ただし、〔結果〕は省略可能。

図6-2

ロバストネス分析図と分析シーケンス図の関係

9

MSS技報・Vol.24
This document is provided by JAXA.

という形式で表現する。

ロバストネス分析図は、ユースケースをオブジェクトフィーチャーの例）の関連として表現したものであり、そこに登場するコン・販売員の成果を査定する。

トロールオブジェクトの殆どがフィーチャー（＝サービ・スケジュールされた自動車整備を実施する。

ス）に相当するので、フィーチャーの集まりがユースケ・カード所有者のクレジットカード取引を認証する。

ースの機能的実現方式を表現したものと考えられる。

・銀行預金口座の残高を取得する。

⑶

ドメイン層のサービスクラス

フィーチャーは、ドメインオブジェクトやドメイン層単一ドメインオブジェクトの振る舞いではなく、複数のサービスを使って、アプリケーション固有の振る舞いのドメインオブジェクトが協同して、1つの意味ある振（アプリケーション毎に異なる処理）を実装したものでる舞いを表す場合、それを、 ドメイン・サービスある。時として、フィーチャーがデータアクセス層を直して定義する。

接利用する場合もある（例：データベース検索）。
⑵とドメインオブジェクトに含むことができる振る舞いは共通フィーチャーの明確化

積極的に含め、どのドメインオブジェクトにも所属させ１ユースケースごとに作成したロバストネス分析図間られないものをドメイン・サービスとする。そして、オを跨ぐ共通なフィーチャーが存在する。これをこの段階ブジェクト間の動作を含めて、ドメイン駆動開発のアグで共通化しておくことが、詳細設計で同じものを作らせリゲート（Aggregate）に集約するという考え方でドメない重要な作業となる。

インサービスクラス設計を行う（図6-4）
。

6.4.2

ドメイン層の設計

アプリケーションが実現しようとする問題領域（例：通信、カーナビ、○○制御等）の構造とできるだけ親和性をもつようにした設計モデルを、ドメインモデルと呼ぶ。ドメイン層の静的モデルは、最大限流用性を図る為にドメインモデルで作る。
⑴

ドメインオブジェクト作成手順
ロバストネス図のエンティティの関係を整理し、その関係をドメイン層のクラス（ドメインオブジェクト）図として表現する。ドメインオブジェクトは、ドメインで共通的に利用されるものという観点で抽出する。また、エンティティがすべてドメイン層のクラスになるわけで

図6-4

アプリケーション層とドメイン層のサービスの違いは無く、データアクセス層のクラスになるものもある。
⑵

アプリケーション層とドメイン層の関係

アプリケーション層とドメイン層のサービスの違いはアプリケーション層にあるフィーチャーは、ドメイン対象とする相手である。アプリケーション層のサービス層にある複数のドメインオブジェクト（の処理）を使っ（＝フィーチャー）は、ユーザにとって意味のある（利て、その役割を果たすことになる。この関係は、図6-3

用価値がある）ものであり、ドメイン層のサービスは、のとおりである。

アプリケーション層にとって意味のあるものである。
7．タスク設計（基盤方式設計）
リアルタイム性（非機能要件の性能属性）を満たす為には、アーキテクチャの動的な構造に視点を向ける。具体的には、CPU（マルチCPU、マルチコア）上で動作する塊であるタスク（プロセス、スレッド）構成とタスク間通信を検討する作業である。
タスク設計は、実時間を満たす視点からタスクという器を抽出し、機能の視点で抽出したオブジェクトをどの器に入れるかという分類を考えていく作業であり、次の図6-3手順で実行する。

アプリケーション層とドメイン層の関係

10

MSS技報・Vol.24
This document is provided by JAXA.

①イベント分析②タスク抽出とオブジェクトのタスクマッピング③タスク優先度の決定④タスク間インタフェースの決定
機能方式設計で表現される「論理的な振る舞い」に、「OSが提供するメカニズムを対応付けて性能要求を満足する」ことを表現した結果が、基盤方式設計のタスク設計となる。従って、安易に、機能＝タスクにしてはならない。
この作業はPIM領域であるが、④タスク間インタフェースの決定においては、メッセージキューやTCP/IPで行う等の方式を決め、その物理的メッセージ形式まで決定する。詳細は割愛する（参考（12）（13））
。
8．機能方式設計から詳細設計への展開
詳細設計は、方式設計を入力として、個々のクラスのプログラム実装方法を検討する作業である。
詳細設計では、主に下記の成果物を作成する。
①実装クラス図：プログラムとして実現するためのクラス図②実装シーケンス図：プログラムとして実現するための

図9-1

フィーチャーリストとトレーサビリティ管理表

オブジェクトの振る舞い③状態遷移図：プログラムとして実現する上で重要な状態遷移力を発揮する。ここでは、その活用がより有効性を発揮④アルゴリズム設計書：②のシーケンス図では表現できすることを示すために、トレーサビリティ管理表は、何ない処理手順。

らかの形でデータベース化され、検索やフィルタリング

この時、重要なのは次の２つである。

機能を実現できていると仮定する。

⑴⑵

設計対象クラスの仕様範囲は、対象となるソフトウ

仕様・設計変更時に、関係設計書をどのように取り出

ェア要求仕様（USDM）とトレーサビリティを確すのか、その手順を説明する。ただし、既に確立された立することで明らかになる（図9-1参照）

仕様項目内の変更か、仕様追加かによって、関係設計書詳細設計が基盤方式設計で規定している内容と矛盾の取り出し方は異なる。

ないことを必ずレビューで確認する。

⑴

9．トレーサビリティ確立方法
9.1

既に確立された仕様項目内の仕様変更①USDMを使って変更仕様を特定する。
②＜トレーサビリティ管理表利用＞特定した変更仕様項

機能方式設計段階のトレーサビリティ確立方法

目に関係するフィーチャーを取り出す。

USDMとロバストネス分析図および分析シーケンス⑵

図を入力情報として、図9-1に示すトレーサビリティ管

新規の仕様追加①USDMを使って追加仕様に関係するであろう既存仕理表を作成する。このトレーサビリティ管理表は、要求様を特定する。

仕様（USDM）とフィーチャー及び、フィーチャーを②（これ以降は、既に確立された仕様項目内の変更に同構成するクラスとの対応関係を示すものである。このトじ）

レーサビリティ管理表をフィーチャーリストと呼ぶ。

既に確立された仕様項目内の仕様変更よりも、新規の仕様追加の方が多い為、システムを変更しようとする人

9.2

トレーサビリティ管理表の利用方法

は、『システムの理解』が重要なファクターとなり、こトレーサビリティ管理表は、双方向トレーサビリティ

こに多くの時間を要する。

を確立するために用いる。このトレーサビリティ管理表

それでも、既存仕様・設計書間にトレーサビリティがは、設計フェーズでのレビューや仕様・設計変更時に威確保されていれば、変更箇所を特定する作業は楽になる。

11

MSS技報・Vol.24
This document is provided by JAXA.

表12-110．どの部分がアジャイル開発なのか？

多重度管理表アジャイル開発とは、「顧客価値を持続的に提供するために、繰り返しながら、コミュニケーション重視で、チームを改善しつつソフトウェア開発に取り組むやり方」である（設計せずにコーディングを始める開発というのは誤解）。開発プロセスとして見た場合、一番重要な部分から、動くソフトウェアを細かく作って完成させていく「短期の繰り返し型」であることが一つの特徴で13．むすびある。
本手法の中では、独立性の高い、ユーザから見た小さ本設計手法は、いくつかの実プロジェクトに適用してな機能であるフィーチャーが繰り返しの単位となる。

効果が見えてきているものである。

フィーチャーは、設計とプログラム開発を２週間程度

設計手法を統一する意義は、エンジニアの目を設計品（もしくは更に短い期間）で開発が可能な単位であり、質と生産性向上（流用）に集中させられること、ドメイ独立性が高いので複数人で並行開発、かつ、反復（イテン知識を有すれば、エンジニアの流動性を高められるこレーション）開発ができる。とにある。特に、レビューにおいて、忙しい有識者がチェックするポイントを統一できる効果は大きい。これ

11．短納期開発が可能

は、構造化プログラミングが果たした成果と同じこと

本手法では、レイヤ毎に並行開発が行える。十分なリが、設計プロセスレベルで発揮できていることになる。

ソースを準備すれば、どれだけ開発する規模が大きくと基本的な手法は変えず、多重度のような改善概念を付も、各レイヤは１〜２ヶ月で詳細設計〜単体テストを完加していくことで、さらに、ソフトウェア設計における了させることができる。

生産性・品質向上が図れると考える。

また、ドメイン層がかなりの割合で流用可能なまでに成謝辞

熟していれば、プレゼンテーション層と、アプリケーション層のフィーチャーの追加・修正でプログラムを完成

本手法を多くの実プロジェクトに適用した際に発生しさせられる。

た課題に対して、現場で使えるよう工夫・改善を継続してくれている関西事業部第三技術部の各位に感謝する。

12．ソフトウェア設計品質検証方法

参考文献

設計プロセスよりも一段詳細な設計手法を決めて、そのトレーサビリティをどのように確保するのかの説明を（１）ソフトウェアアーキテクチャ

岸知二、野田夏子、行った。これで分かることは、設計そのものがスパゲッ

深澤良彰、共立出版（2005/6）

ティになっている、つまり、仕様項目や設計項目間の結（２）実践ソフトウェアアーキテクチャ

Len Bass/合度が高い場合、いくらトレーサビリティを確立したとPaul Clements/ Rick Kazman 前田卓雄他訳、日しても、下位設計から上位を見れば多くの設計条件があ刊工業新聞社（2005）

り、上位設計の絡まり具合を下流に持ち越したままにな（３）システムアーキテクチャ構築の原理 ITアーキテクってしまうということである。

トが持つべき3つの思考（IT Architects

そこで、設計品質の良し悪しを計る指標として、「成Archiveソフトウェア開発の実践）ニック・ロザンスキ、果物項目間の多重度」を用いることを考える。成果物項

イオイン・ウッズ、榊原

目間の多重度とは、表12-1のように、ある成果物の項目彰、牧野祐子、翔泳社（2008/12/3）

が、別の成果物の項目といくつの関係を持っているかを（４）リアルタイムUMLワークショップ示す指標値のことである。

グラス

良い設計が行われた際、成果物項目間の多重度が取る

ブルース・ダ鈴木尚志訳、翔泳社（2009/12）（５）オブジェクト指向設計 滝澤克泰、ソフトバンクパ

べき大凡の範囲が予め分かっていれば、その範囲内にあブリッシング（2005/1）

れば良い設計、範囲外であれば悪い（どこかおかしい）（６）【改訂第２版】要求を仕様化する設計、と判断できるようになる。

術

技術表現する技

清水吉男、技術評論社（2010/6）（７）「派生開発」を成功させるプロセス改善の技術と極12MSS技報・Vol.24This document is provided by JAXA.

意清水吉男、技術評論社（2007/11）

執筆者紹介（８）Java/Webでできる大規模オープンシステム開発
入門林浩一他、丸善出版（2012/10）（９）ユースケース駆動開発実践ガイド

藤原啓一

ダグ・ローゼ1985年入社。関西事業所に配属。入社〜1992年、防衛のンバーグ、マットステファン、佐藤竜一他訳,翔泳

ソフトウェア開発に従事以降 カーナビ、気象レーダ、社（2007/10）

ニューラルネット、医用画像、衛星通信、業務系システ（10）エンタープライズアプリケーションアーキテクチャ・パターン

マーチン・ファウラー

ム等のソフトウェア開発に従事。

長瀬嘉秀

2014年（現在）通信に関するソフトウェア開発部長。

監訳,翔泳社（2005/4）（11）エリック・エヴァンスのドメイン駆動設計エリック・エヴァンス

今関剛監訳、翔泳社（2011/4）（12）リアルタイム組込OS

Qing Li/Caroline Yao翔泳社（2005/11）（13）組み込みソフトウェアの設計＆検証

藤倉俊幸、

CQ出版（2006/9）

13

MSS技報・Vol.24This document is provided by JAXA.