５月２９日に、「要求開発アライアンス５月定例会」に行ってきた！
つぶやきＮＧだったみたいだから、内容を書いて良いのか、
よくわかんないけど、ま、いいか、大丈夫だろう
ということで、その内容をメモメモ
■概念モデルよ、キミこそ主役だ！・
骨太のユースケースと概念モデルが世の中を照らす
メッセージ
・概念モデルをもっと活用しよう
・そうすれば、今よりも楽に質の良い仕事ができるようになる
・そのためには
１．概念モデルの出番を確保し
２．概念モデルの出番を早め、
３．概念モデルの品質を高めるポイントを理解すること
が大切
私の２種類の現場
システム開発
マネジメント向け概念モデルセッション
・メモ書き（概念モデル、クラス図）→設計書
・言葉の定義→ビジネス戦略を正確に語れる
１．概念モデルの出番を確保する
・出番はどこに
システム開発工程の上流
要求開発工程
概念モデルのための特別なプロジェクトで
・アクティビティの前後関係に注意
ユースケースの時間をとる
概念モデル検証の時間をとる
・システム開発工程では、通常データ構造分析・設計の手間が取られているが
ありがちな問題は
実装を意識したモデル（クラス図）にならざるを得ない
常に「手抜き実装モデル」、つまりある種の不良品になる恐れがある
概念モデルのための技法が使えなくなる
今日紹介するビジネスユースケース駆動など
ソフトウェア開発工程
概念モデル ｜
要求→ 分析 →設計→実装 →テスト
アクティビティとして時間とマンパワーを確保することが必要
開発スタイルによってはそれが難しいことも
反復型ソフトウェア開発
UP、RUP
概念モデルにフィードバック
インセプション
要求開発工程
→要求開発の本
概念モデリング・プロジェクトという考え方
概念モデリング→要求→ 分析 →設計→実装 →テスト
２．概念モデルの出番を早める
・概念モデルの出番の作り方
・システム開発プロジェクトの上流
・要求開発プロジェクト
・概念モデリングプロジェクト
・プロジェクトの設定がどうであれ、概念モデルはいきなり搭乗できない
・概念モデルはゆーすけーすという文脈があって生まれる
概念モデルの特徴とユースケース
・UMLのクラス図を利用したモデル
オブジェクト図や製薬記述も併用
・特定のビジネス（企業）、業界における概念・用語の構造的な関係を図に示したもの
・普通のユースケースと良質の概念モデルを比較してもユースケースのほうがわかりやすい
・そのため、ユーザーは本来概念モデルに至るひとつのステップであるはずのユースケース
や画面スケッチなどを上流の成果物として好む傾向がある
わかりやすさのひかく
・じむあろう(Dr Jim Arlow)
成果物作成にかける時間配分のイメージ
システムユースケースVSビジネスユースケース
・ビジネスユースケース＝ビジネスシステム・ユースケース
・システムユースケース＝情報システム・ユースケース
BS概念モデルVSIS概念モデル
BS概念モデル 事業領域を表す概念モデル
IS概念モデル BS概念モデルに対してIT施策が反映されたもの
BSの切り出しはビジネスプロセスマトリックスでスリムにやる
・ビジネスの流れを横軸に
・商品・サービスの分類を縦軸に
・商品・サービスごとのビジネスプロセスの相違をきわだたせる
ビジネスプロセスマトリクス
基本ビジネス
ビジネスプロセスを縦軸に展開し、CRUD風のテーブルへ
桁：概念モデルのパッケージ構造
行：BSユースケースパッケージ
概念モデル
商品 まーけ 営業 見積もり 契約
商品
まーけ
営業
見積もり
事例
事例１：クララオンライン様 クラウドビジネス
事例２：不動産仲介ベンチャー ワンストップ様
お客さんは語りたい関心事がある→おかしさがある
オブジェクト図を書かないと結局だめ
構造概念は役に立つ
３．概念モデルの品質を高めるポイントを理解する
１．中級
・親切なクラス図
・見やすいクラス図
・データ型がきちんとしているクラス図
２．上流
・嘘をついていないクラス図
・すっきりしたクラス図
・継承がさわやかなクラス図
３．組織で対応
・漂流しないクラス図
・進化するクラス図
・手を抜いていないクラス図
・検証できるクラス図
親切なクラス図
・クラス図だけで理解するのは相当大変
・だからオブジェクト図も作ろう
人は例を通じてのみ理解する（ピーターコード）
・静的構造２点セット
クラス図、オブジェクト図
見やすいクラス図
・パッケージを利用し、ビューを制御する
同時に全部見せない
・ユースケースを説明するクラス図
→スコープが狭いために理解しやすい
ユースケーススライスというそうです（羽生田さんがいった）
・データ型がきちんとしているクラス図
数が限定されているなら、列挙型に
嘘をついていないクラス図
・関連のループがあったら注意
静的構造３点セット
クラス図
オブジェクト図
不変制約：オブジェクト制約言語
すっきりしたクラス図
継承がさわやかなクラス図
継承よりコンポジション
役割
日本料理もでる中華料理屋をやりたい
漂流しないクラス図
概念と実装のはざまで漂流しない
概念モデルは人間の言葉をモデル化する
実装に配慮した（気兼ねした）概念モデルは質の悪い実装モデルとみなされる
進化するクラス図
ラウンドとリップエンジニアリング
リバースエンジニアリング
人力モデル駆動
モデル間の整合性を維持する責務が組織内に存在していることが重要
整合性維持が自動化されたシステムで行われるかは重要ではなくむしろ人力のほうが優れている
手を抜いていないクラス図
汎用的なデータ構造は概念モデルではない
（汎用的なデータ構造は有効な場合があるが、概念モデルの代わりにはならない）
検証できるクラス図
ユースケースがあるから概念モデルが生まれる
ユースケースによってのみ概念モデルが検証できる
アンダーラインの活用
ユースケースに概念モデルがあったら、アンダーライン
骨太ユースケースと概念モデル
モデラーの心構え
・チームの平均レベルを常に意識せよ
受けているか
理想の図を描く必要はない
妥協してチームの成長を待つことも必要
必要としているまさにその時に教えよ
・モデルは段階的に成熟させてもよい
周囲のレベルに合わせる
利用可能な情報の量に合わせる
・知識をひけらかすモデルを書いてはいけない
・モデルは現場に力を与え、相違と信頼を醸成するものでなくてはならない
・標準UMLにこだわることない
■見通しのよいシステム開発に向けて 全容を俯瞰せよ
あじぇんだ
・弊社紹介
・今回の取り組みの経緯
・取り組み時に感じた課題認識
株式会社クララオンライン
・もともとはレンタルサーバー
・近年はアジア：クロスボーダー
メインランドチャイナ
台湾
ASEAN
韓国
日本
従来のサーバーホスティング
１：１
クララオンライン
自社だけでない
今回の取り組みの経緯
・マルチクラウド、多拠点、マルチカレンシー
→既存システム、既存業務の見直し
新システムの開発も急務
昨日やデータの重複、システム連携や業務整備の遅れは回避しなければならない
そのために（あえて）
１つ１つの機能やデータを詳細に検討するのではなく
業務やシステムを俯瞰することで大きな問題点を把握し
見通しに良いシステム開発を実現する
実際のアウトプット
俯瞰による問題認識の意義
・どこに注力すべきかの判断材料になる
→コスト（人、金、時間）をどこにかけるべきか
→問題や、その影響が少ない部分は多少品質を落としても・・
取り込み時に感じた課題認識
１．短時間／短期間で既存システムや業務の整理と新規構想の具体化が必要
２．そのためには培われたノウハウが必要
概念モデル化する技術力が不足している
今後
１．精通者／理解者を増やす
・概念モデルを作成でき、より適切な表現やとらえ方ができるように議論できる人材を育てる
・会社全体を業務やシステムの視点で把握している人材／できる人材を育てる
２．実践（アウトプット）を続ける
・実践なくして、技術は磨けない
ノウハウは得られない
■ワークショップに予定していたこと（実際は時間切れ）
１．ビジネスプロセスを探る
２．骨太ユースケースから概念モデル、そして検証
推薦図書
・UMLモデリングのエッセンス
・Java Modeling in color with UML ピーターコード
つぶやきＮＧだったみたいだから、内容を書いて良いのか、
よくわかんないけど、ま、いいか、大丈夫だろう
ということで、その内容をメモメモ
■概念モデルよ、キミこそ主役だ！・
骨太のユースケースと概念モデルが世の中を照らす
メッセージ
・概念モデルをもっと活用しよう
・そうすれば、今よりも楽に質の良い仕事ができるようになる
・そのためには
１．概念モデルの出番を確保し
２．概念モデルの出番を早め、
３．概念モデルの品質を高めるポイントを理解すること
が大切
私の２種類の現場
システム開発
マネジメント向け概念モデルセッション
・メモ書き（概念モデル、クラス図）→設計書
・言葉の定義→ビジネス戦略を正確に語れる
１．概念モデルの出番を確保する
・出番はどこに
システム開発工程の上流
要求開発工程
概念モデルのための特別なプロジェクトで
・アクティビティの前後関係に注意
ユースケースの時間をとる
概念モデル検証の時間をとる
・システム開発工程では、通常データ構造分析・設計の手間が取られているが
ありがちな問題は
実装を意識したモデル（クラス図）にならざるを得ない
常に「手抜き実装モデル」、つまりある種の不良品になる恐れがある
概念モデルのための技法が使えなくなる
今日紹介するビジネスユースケース駆動など
ソフトウェア開発工程
概念モデル ｜
要求→ 分析 →設計→実装 →テスト
アクティビティとして時間とマンパワーを確保することが必要
開発スタイルによってはそれが難しいことも
反復型ソフトウェア開発
UP、RUP
概念モデルにフィードバック
インセプション
要求開発工程
→要求開発の本
概念モデリング・プロジェクトという考え方
概念モデリング→要求→ 分析 →設計→実装 →テスト
２．概念モデルの出番を早める
・概念モデルの出番の作り方
・システム開発プロジェクトの上流
・要求開発プロジェクト
・概念モデリングプロジェクト
・プロジェクトの設定がどうであれ、概念モデルはいきなり搭乗できない
・概念モデルはゆーすけーすという文脈があって生まれる
概念モデルの特徴とユースケース
・UMLのクラス図を利用したモデル
オブジェクト図や製薬記述も併用
・特定のビジネス（企業）、業界における概念・用語の構造的な関係を図に示したもの
・普通のユースケースと良質の概念モデルを比較してもユースケースのほうがわかりやすい
・そのため、ユーザーは本来概念モデルに至るひとつのステップであるはずのユースケース
や画面スケッチなどを上流の成果物として好む傾向がある
わかりやすさのひかく
・じむあろう(Dr Jim Arlow)
成果物作成にかける時間配分のイメージ
システムユースケースVSビジネスユースケース
・ビジネスユースケース＝ビジネスシステム・ユースケース
・システムユースケース＝情報システム・ユースケース
BS概念モデルVSIS概念モデル
BS概念モデル 事業領域を表す概念モデル
IS概念モデル BS概念モデルに対してIT施策が反映されたもの
BSの切り出しはビジネスプロセスマトリックスでスリムにやる
・ビジネスの流れを横軸に
・商品・サービスの分類を縦軸に
・商品・サービスごとのビジネスプロセスの相違をきわだたせる
ビジネスプロセスマトリクス
基本ビジネス
ビジネスプロセスを縦軸に展開し、CRUD風のテーブルへ
桁：概念モデルのパッケージ構造
行：BSユースケースパッケージ
概念モデル
商品 まーけ 営業 見積もり 契約
商品
まーけ
営業
見積もり
事例
事例１：クララオンライン様 クラウドビジネス
事例２：不動産仲介ベンチャー ワンストップ様
お客さんは語りたい関心事がある→おかしさがある
オブジェクト図を書かないと結局だめ
構造概念は役に立つ
３．概念モデルの品質を高めるポイントを理解する
１．中級
・親切なクラス図
・見やすいクラス図
・データ型がきちんとしているクラス図
２．上流
・嘘をついていないクラス図
・すっきりしたクラス図
・継承がさわやかなクラス図
３．組織で対応
・漂流しないクラス図
・進化するクラス図
・手を抜いていないクラス図
・検証できるクラス図
親切なクラス図
・クラス図だけで理解するのは相当大変
・だからオブジェクト図も作ろう
人は例を通じてのみ理解する（ピーターコード）
・静的構造２点セット
クラス図、オブジェクト図
見やすいクラス図
・パッケージを利用し、ビューを制御する
同時に全部見せない
・ユースケースを説明するクラス図
→スコープが狭いために理解しやすい
ユースケーススライスというそうです（羽生田さんがいった）
・データ型がきちんとしているクラス図
数が限定されているなら、列挙型に
嘘をついていないクラス図
・関連のループがあったら注意
静的構造３点セット
クラス図
オブジェクト図
不変制約：オブジェクト制約言語
すっきりしたクラス図
継承がさわやかなクラス図
継承よりコンポジション
役割
日本料理もでる中華料理屋をやりたい
漂流しないクラス図
概念と実装のはざまで漂流しない
概念モデルは人間の言葉をモデル化する
実装に配慮した（気兼ねした）概念モデルは質の悪い実装モデルとみなされる
進化するクラス図
ラウンドとリップエンジニアリング
リバースエンジニアリング
人力モデル駆動
モデル間の整合性を維持する責務が組織内に存在していることが重要
整合性維持が自動化されたシステムで行われるかは重要ではなくむしろ人力のほうが優れている
手を抜いていないクラス図
汎用的なデータ構造は概念モデルではない
（汎用的なデータ構造は有効な場合があるが、概念モデルの代わりにはならない）
検証できるクラス図
ユースケースがあるから概念モデルが生まれる
ユースケースによってのみ概念モデルが検証できる
アンダーラインの活用
ユースケースに概念モデルがあったら、アンダーライン
骨太ユースケースと概念モデル
モデラーの心構え
・チームの平均レベルを常に意識せよ
受けているか
理想の図を描く必要はない
妥協してチームの成長を待つことも必要
必要としているまさにその時に教えよ
・モデルは段階的に成熟させてもよい
周囲のレベルに合わせる
利用可能な情報の量に合わせる
・知識をひけらかすモデルを書いてはいけない
・モデルは現場に力を与え、相違と信頼を醸成するものでなくてはならない
・標準UMLにこだわることない
■見通しのよいシステム開発に向けて 全容を俯瞰せよ
あじぇんだ
・弊社紹介
・今回の取り組みの経緯
・取り組み時に感じた課題認識
株式会社クララオンライン
・もともとはレンタルサーバー
・近年はアジア：クロスボーダー
メインランドチャイナ
台湾
ASEAN
韓国
日本
従来のサーバーホスティング
１：１
クララオンライン
自社だけでない
今回の取り組みの経緯
・マルチクラウド、多拠点、マルチカレンシー
→既存システム、既存業務の見直し
新システムの開発も急務
昨日やデータの重複、システム連携や業務整備の遅れは回避しなければならない
そのために（あえて）
１つ１つの機能やデータを詳細に検討するのではなく
業務やシステムを俯瞰することで大きな問題点を把握し
見通しに良いシステム開発を実現する
実際のアウトプット
俯瞰による問題認識の意義
・どこに注力すべきかの判断材料になる
→コスト（人、金、時間）をどこにかけるべきか
→問題や、その影響が少ない部分は多少品質を落としても・・
取り込み時に感じた課題認識
１．短時間／短期間で既存システムや業務の整理と新規構想の具体化が必要
２．そのためには培われたノウハウが必要
概念モデル化する技術力が不足している
今後
１．精通者／理解者を増やす
・概念モデルを作成でき、より適切な表現やとらえ方ができるように議論できる人材を育てる
・会社全体を業務やシステムの視点で把握している人材／できる人材を育てる
２．実践（アウトプット）を続ける
・実践なくして、技術は磨けない
ノウハウは得られない
■ワークショップに予定していたこと（実際は時間切れ）
１．ビジネスプロセスを探る
２．骨太ユースケースから概念モデル、そして検証
推薦図書
・UMLモデリングのエッセンス
・Java Modeling in color with UML ピーターコード
アクセス
トータル
ランキング
