＜前置き：本件でのIT刷新コンセプト＞
・アーキテクチャから考える。
・ドメイン駆動設計（DDD）
－ドメイン（事業の中心領域）を核に設計する。
・モデル駆動開発
－共通言語によるモデリングで仕様設計する。
・オブジェクト指向
－以上に適するオブジェクト指向で徹底する。
＜経営者が抜本改革を主導＞
ご縁があって、90年代に同じビジネス・ドメインでパッケージ・システムの開
発に携わっていたことを買われて、本プロジェクトに参画する機会を得ました。
お客様は、ヘルスケアで臨床領域の大手プレイヤーさん。M＆Aで規模拡大して
来た結果、システムがバラバラなまま運用まで肥大化し、保守を担うIT子会社を
含めてROIが低下し続けて、経営の足枷になっていました。人口減少という日本
の特殊事情から、海外展開を急いでいる時のことでした。
そんな中、経営者が主導して、外部からCIOを迎え入れ、抜本改革に乗り出し
た訳です。目玉は、コアコンピタンスをキチンとモデル化した上で、ドメイン駆
動・モデル駆動で通貫して、「業務構造改革とIT刷新を同時に行う」というもの
でした。
過去に同じドメインのパッケージ・システムを開発し、多数の医療施設に展開
した経験から、ヘルスケア領域のソフトウェアは、上手くやれば1.2億人ではな
く60億人を相手にできる可能性があり、モデリングにより普遍的価値（長持ちす
る位かな）を導出・洗練化して、実装までを一気にやろうというテーマは、とて
も興味深く思えました。実際、この臨床領域のコアモデルは、２０年前とそんな
に変わっておらず、とっても驚きましたが、同時にこのモデルを洗練化して実装
する価値にも、気付かされました。
印象的だったのは、経営者自らが、早い段階からその価値に気付き・こだわり
続けていることでした。避けて通れない商品のコモディティ化に抗いながら、グ
ローバル化に舵を切らなければ、今日のような明日はないことに備えているかの
ように。。。
＜アーキテクトとして、品質と開発スピードの両立に向き合う＞
事務局型でなく、ドメイン＆モデル駆動の現場にfitするやり方を模索して、
杓子定規の手抜きに陥らず、臨機応変に目的合致でメリハリを付ける事に留意し
ました。
（１）課題バラし（発掘と精査）と計画作り
・「品質を担保する材料評価」
品質保証の観点で、積み上げるべき品質を担保する材料を、それぞれ具体的
に評価して、優先順位を付けて、開発現場で臨機応変のコントロール活動に役立
てられる様にしておく。
・「着任前に実施されていたプロトタイプ開発からの学び取り」
設計視点で、「概念モデルとユースケース(UC)/アクティビティ図(AC)」に対
する試行錯誤から、本開発における手戻り等リスクを低減させる要素なりヒント
を、一般論ではなくできるだけ具体的に得て、現場負担の小さな有効策を考える。
収穫はレビュ設計とその運営に反映しました。
テスト視点で、プロトタイプ開発の成果物を元に、概念モデル＋物理モデル
に対応する、「テスト仕様書（準ずるもの）」と「テストデータ」および「テス
ト後に検出された不具合（テスト検出漏れ）」から、必要十分なテスト準備を行
うためにすべきことを収穫として得ました。
（２）設計レビュ（概念・クラス・ユースケース(UC)・シーケンス）
・概念モデルとUC/ACの確からしさで、品質担保。
チーム毎に、概念モデルへの揺さぶり活動で出て来た課題を捌きました。
・物理モデル（クラス図・シーケンス図）の確からしさで、品質担保。
チーム毎に、物理モデル描き込みで出て来た課題を捌きました。
・原則、モデラによる事前チェック->有識者によるレビュ->統括者による外部
レビュの３段階で担保を積み上げ、参加者はレビュ特性に応じて臨機応変に
アレンジしました。（重要領域は手厚く）
（３）セルフチェックとお客様業務設計者を巻き込んだテスト仕様の準備
・「設計品質チェックリスト」によるセルフチェックの展開と浸透工夫を行い
ました。
・各ドメイン内結合テストに備えて、テスト仕様書のパイロット版を作成し、
記述性やテスト密度のガイドラインとして活用しました。
・このドメイン内結合テスト以降、テスト仕様は業務設計者が担うことに、開
発標準を変更しました。
（４）テスト仕様レビュと不具合分析を元にした現場牽制
・業務設計者と開発チームの恊働型で作成した「内部結合テスト仕様書」のレ
ビュで、チーム外の有識者を参加させました。
・合わせて「テスト品質チェックリスト」によるセルフチェックの展開と浸透
工夫を行いました。
・redmineで管理された不具合チケットを分析することで、問題を抱えている
だろうチームを狙い撃ちして、振り返り機会を提供しました。また、メトリ
クス評価からのフィードバックを適時行い、現場牽制を日常化させました。
*redmine: Webベースのプロジェクト管理ソフトウェア
http://ja.wikipedia.org/wiki/Redmine
（５）ソースコードレビュ
・「ソースコード品質チェックリスト」によるセルフチェック（チーム内有識
者による）の展開と浸透工夫を行いました。
・ピンポイントでレビュ対象チームを指名し、有識者による事前チェックと、
チェック結果の質疑応答を行いました。
この場には、他チームの製造リーダも招集することで、横展開を行いました。
・これは、意図通りに、コード品質に責任を持つ各チームの製造リーダが、ピ
リピリする場となりました。
＜凝りもせず？上流工程で定量的品質管理にチャレンジ＞
せっかく概念モデリングから参画した訳なので、通貫型の品質評価を行うネタ
も揃っており、品質可視化の試行錯誤を行いました。
品質保証プロセスはお客様主体であり、ドメイン間結合テストの実施主体から
お客様がベンダーに代わって前に出てくる構図でした。そこへつなげるベンダー
が積み上げる品質の中身を、どのように工夫して見える化できるかの試行錯誤と
なりました。
参考資料：IPAのSEC BOOKS：「続 定量的品質予測のススメ」
http://www.ipa.go.jp/sec/publish/tn10-004.html
http://www.ipa.go.jp/files/000005143.pdf
（１）観測A：不具合仕込みvs検出予実評価
開発工程別の欠陥予測数と、レビュやテスト工程別の検出予測数とその実績を
ドメイン単位でそれぞれ観測しました。週次で実績を反映させて、都度評価モデ
ルを見直すことを繰り返すと、各種予測の精度が徐々に上がること、実感しまし
た。
振り返っての利益は、現在のプロジェクトへのフィードバックももちろんあり
ますが、次にドメイン＆モデル駆動プロジェクトを行う時に、とても参考になる
指標の重み付けと、傾向の予実観測結果が得られたと思います。
簡単ですが、以下に観測項目を列挙しておきます。
(ア)基本指標
ユースケース(UC)数
画面/帳票数
クラス数
メソッド数
LOC
コード自動生成率
平均欠陥密度、、、
(イ)開発成果物
AC図
UC一覧
概念モデル
UC記述
画面/帳票類定義
クラス図
シーケンス図他
実装
変更・追加の補正パラメータ、、、
(ウ)レビュ工程
AC図
UC洗練化
概念モデル
物理モデル＆シーケンス＆テスト仕様、、、
(エ)テスト工程
内部結合１までの準備（単体）
内部結合テスト１
内部結合テスト２
結合テスト
受入テスト１
受入テスト２
運用テスト
（２）観測B：製造メトリクス分析
（詳細は割愛）
（３）観測C：不具合発生状況分析
（詳細は割愛）
＜アーキテクトとして、やれたこと・やれなかったこと＞
上流工程で重要な役割を担うアーキテクトが、早い段階からクオリティ・コン
トロールに関与したことで、各ドメインの開発現場それぞれの特性に応じた、画
一的・事務局的でない活動が可能になったと思います。
その活動により、当初のサブミッションであった「品質と開発スピードの両立」
にも貢献できたこと、評価して頂きました。
活動上のポイントは、繰り返しになりますが、「品質管理の基本を押さえつつ
臨機応変の目的合致で振る舞うために、常にクオリティ・コントロール上の優先
順位に照らしながら進めること。チームリーダ層からは、少々嫌われ者になりま
すが（笑）、理にかなっている活動は、最後は支持されるものなので。」
また、複数拠点へ展開されるシステムだったので、プロダクト系での品質保証
(QA)の経験が役立ったのかなとも思います。「１つの不具合が複数拠点におよぶ」
というのは、やはり緊張感が違いますからね。
しかしながら、個人的な振り返りからは、以下２点の重要課題が残ってしまいました。
（１）ベンダー縦割り構図の克服
・プロジェクトの全体体制は、３ベンダーがお客様に縦割り統治される形態で、
私が直接関与した領域は全体の約1/3で、ベンダー間を統合するテストフェー
ズでは、様々な品質課題が頻発してしまいました。ドメイン間は疎結合が設計
原則なので、相互影響は極力出ないはずですが、受け渡されるデータ型等イン
タフェースの詳細仕様の変更＆追加など、基本的と言えばそれまでですが、複
数ベンダーが牽制し合うと、こういう何でもないことが、上手くできなくなる
んですね。
・各ベンダーの担当アーキテクト（モデラー）は、当初少なくとも毎週の定例会
議で顔を合わせて、些細な心配事まで会話しながらお互いすり合わせを行うこ
とが習慣になっていました。ところが、各チームの設計現場では、ベンダー間
の牽制構図も働いてしまい、外野からのお節介な尻たたきでは、なかなかポテ
ンヒットを避ける事、できませんでした。
（２）ドメイン駆動設計・モデル駆動開発における品質保証
・部分最適の、自分達が担った領域で品質管理を良くするだけでなく、全体最適
でお客様価値となる品質保証にどう貢献できるかをミッションにできなかった
のが敗因（言い訳）です。
・建前は、小職契約元ベンダーの利益で動くため、３ベンダーから独立した品質
保証に踏み出す事、叶いませんでした。
・インフォーマルに、やれるお節介はたくさんしたつもりだけれども、未達感が
たくさん残ってしまいました。
次への糧ですね。
合掌。
＜後記：言い伝え＠ワインバーグとデマルコ＞
「品質とは誰かにとっての価値である」
http://www.amazon.co.jp/exec/obidos/ASIN/432002706X/
「（されど）測定できないものは制御できない」
*DDD: Domain-Driven Design（ドメイン駆動設計）
http://www.amazon.co.jp/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1414501863&sr=1-2
https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
------------------------------------------------------------------------
■執筆者プロフィール
Yukihiro Maruyama（丸山幸宏）
Product Business & West Regional Director
日本インフォビューテクノロジス（株）
ITコーディネータ
コメントをお書きください