「カンバン ソフトウェア開発の変革」の感想～カンバンはメトリクス駆動のアジャイル開発

「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」を読んだ。
とても良い本。
率直な感想は「カンバンはメトリクス駆動のアジャイル開発ではないか」。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」の内容はそのまま、Redmineによるチケット駆動開発に全面適用できるし、チケット駆動開発を使えば、カンバンの奥深さをより実感できると思う。
以下、ラフなメモ書き。

【参考】
Yes We Kanban!『カンバン ソフトウェア開発の変革』を読んだ | 世界はどこまでもシンプルである

Technologic Arts Incorporated | 書籍「カンバン ソフトウェア開発の変革」発売

リックテレコム 書籍情報

【1】Redmineによるチケット駆動開発を経験している者から見れば、カンバンは所詮タスクボードに過ぎないでしょ、と思ってしまう。
単なるチケット集計機能に過ぎないカンバンにそんなに奥深さがあるのか？と。

また、ScrumやXPなどのアジャイル開発の観点では、スプリントやイテレーションというタイムボックスでスコープをコントロールするやり方に対し、カンバンでは、仕掛りチケットの枚数をWIP制限で制御する手法に過ぎないのでは、と思う。

さらに、TOCのドラム・バッファ・ロープや5つの改善サイクル、ボトルネックの改善の観点で見れば、カンバンはそれらの技法を取り入れただけではないのか、と思ってしまう。

でも、「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」を読むと、カンバンがそれらの技法と全く異なる概念であることを明確に述べている。

ScrumやXPなどのタイムボックス型アジャイル開発は、イテレーションというタイムボックスでスコープを制御し、プラクティスと言う名の運用ルールで開発メンバーを制御しようとする。
定期的にリリースするから、受託開発案件や製品開発で多いだろう。

一方、カンバンは、タイムボックスはないので緩い。
仕掛中のチケットの枚数をWIP制限で上限を設けて、作業の停滞をなくすことに注力する。
ソフトウェア保守や、最低限の機能を持つ製品(MVP)ないし市場投入可能最小限リリース(MBR)の開発案件に向く。
また、アジャイル開発のようなガチガチのプラクティスはないので、現場の運用ルールをいきなり変えずに、見える化から始めましょう、という掛け声のもとで、導入しやすい利点もある。

【2】カンバンの成功のレシピ

カンバンを成功させるレシピは以下が紹介されている。

【2-1】1)品質に集中
2)仕掛り(WIP)を減らす
3)頻繁なデリバリ

ここまでは、アジャイル開発でも同じ。
カンバンの思想の根底には、リトルの法則が作業を支配している、という発想があるように思う。

リトルの法則は「L＝λW：顧客数＝到着率 * 処理時間」。
SW開発ならば、「WIP＝Velocity * サイクルタイム」または「WIP＝Velocity * リードタイム」を表す。

つまり、下記の因果関係が発生していることになる。
リードタイムが長くなる
＝仕掛り作業が増える
＝メンバーが忙しくなる
＝メンバーの暗黙知が共有できなくなる
＝ソフトウェアの品質が劣化する

だから、カンバンの第1段階は、ソフトウェアの品質を確保し、仕掛り(WIP)を減らすことで、リードタイムを短くし、頻繁にリリースできるようにする。

【2-2】4)要望とスループットのバランスを取る
5)優先順位付け

カンバンの第2段階では、頻繁なデリバリが安定稼働している前提で、デリバリの対象にビジネス価値をがあるかどうかを気にする。
つまり、ビジネス価値の最適化によって、デリバリの質を上げるわけだ。

そのために、要望とスループットのバランスを取って、開発チームが処理できる分量の要望に絞り込む必要があるし、そのために要望に優先順位を付ける必要がある。

【2-3】6)予測可能性を高めるために、ばらつきの要因の解消

カンバンの第3段階は、カンバンの内外から影響してくる要素のばらつきを制御すること。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」では、初期のリーンの論文では、生産のばらつきの考慮が不足していると厳しく指摘している。
このレベルは、カンバンの第2段階までクリアして初めて考えた方が良い、とのこと。

【3】カンバンのメトリクス

「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」で最も印象に残ったことは、以下のメトリクスだ。

【3-1】WIP(仕掛り)

チケット駆動なら、作業中のチケット枚数を表す。
カンバンでは、カンバンに流れる作業に上限を課すために、WIP制限を課す。
WIP制限の枚数が少ないほど、全体のプロセスを見渡すと、暇になる人が増えてくる。
暇にならないプロセスがあれば、そこがボトルネックであると分かる。

つまり、カンバンでは、WIP制限を厳しくしてボトルネックを洗い出し、チームや組織に良い緊張をもたらす。
例えば、マネージャの立場では、暇な人が多いと、部署の稼働率が下がり、スループットが下がって売上が下がるわけだから、すごく不安になってくる。
だから、ボトルネックをフル稼働させるか、ボトルネックを解消させることで、スループットを上げるように仕向ける。

カンバンの手法では、WIP制限を実現する場合、キューに入る作業の最大枚数をWIP制限にする場合が多い。
そうすれば、ビジネスオーナーやプロダクトオーナーが要望をキューに入れる時に、要望の枚数に制約を課せるので、自然にWIP制限を実現できるから。

【3-2】リードタイム

チケット駆動なら、チケットの平均完了日数。
リードタイムが長いほど、リリース間隔が長くなる。
アジャイル開発なら、リードタイムはイテレーションよりも短くなるように、チケットの粒度を細かくするだろう。
カンバンでは、ScrumやXPよりもリードタイムは短くなる。

【3-3】納期パフォーマンス(納期遵守率)

カンバンで最も重視されるメトリクス。
「作業項目(または要件)を計画通りにデリバリーしたか」という割合。

チケット駆動なら、チケット完了率。
つまり、あるイテレーション内で、イテレーション計画時に予定したチケットと割り込みで発生したチケットの合計枚数に対し、完了したチケットの枚数を割った割合。

納期パフォーマンスがは「目標通りにデリバリーできたか」という指標そのものなので、予測可能性のメトリクスとして使える。
つまり、納期パフォーマンス(納期遵守率)が高ければ、ビジネスオーナーは安心して要望を追加できるし、信頼関係を増すこともできる。
逆に、納期パフォーマンスが低ければ、見積もりの精度が悪く、ビジネスオーナーの信頼も下がるだろう。

【3-4】スループット(またはVelocity)

スループットは、ある決まった時間(例：1ヶ月)内にデリバリーされた項目数を表す。
アジャイル開発なら、Vecloity。
チケット駆動なら、イテレーション毎の平均完了チケット数。

カンバンとアジャイル開発では、スループット(Velocity)の扱いに微妙な違いがある。
アジャイル開発では、Velocityは急激に増やすべきものではなく、安定すべき数値として扱う。
つまり、次のイテレーションの見積りに使うために、実績値をベースに予測可能な生産能力として扱う。

一方、カンバンでは、チームや組織がどんなパフォーマンスを発揮しているか、常時改善を行われているか、という指標として使われる。
つまり、ある時間軸でのデリバリー量の予測や、具体的なデリバリーの約束に使うわけではない。

【3-5】デリバリ効率

デリバリ効率＝(トータルコスト-(取引コスト＋調整コスト))/トータルコスト
または
デリバリ効率＝1 - (取引コスト＋調整コスト)/(利益＋取引コスト＋調整コスト)

但し、取引コスト：間接費。例えば、ソフトウェア製品をCDに焼くリリース準備、他サーバーと係るデプロイなど。
調整コスト：直接費。例えば、会議・マーケティング・ヘルプデスクなど。

デリバリ効率は、ビジネス価値として生み出す製品開発の開発効率を表すと思われる。
デリバリ効率を上げるには、デリバリー間の間隔を長くするか、調整コストや取引コストを減らすか、の手法がある。
20世紀は「規模の経済」を優先するために前者を選択する時が多かったが、長期間の減価償却が発生するデメリットがある。
最近のリーン思考を標榜する企業では、バッチサイズ(例：リードタイム)を効率的にするために、調整コストと取引コストを削減することでムダをなくす。

【4】カンバンの変数

カンバンをコントロールする変数は以下がある。

1)仕掛り(WIP)
2)優先順位付け
3)デリバリー
4)優先度分類
5)リードタイム

上記の変数は、カンバンのパフォーマンスを調整するためのレバーの役割を果たす。
レバーをどのように動かし、効果的だと思わせる選択肢をどのように取捨選択するかは、腕の見せ所。

【5】キューとバッファの違い

僕の理解が甘かった部分は、キューとバッファの違い。

【5-1】キューは、処理待ち行列。FIFO。
キューの要素は上から順に優先順位付けされている。

キューのサイズにWIP制限を課すようにすれば、優先順位付けしやすくなる。
例えば、優先順位付けキューのサイズが8枚で、既に5枚埋まっているとしたら、ビジネスオーナーには、直近にデリバリ可能な要望は残り3枚です、今までのバックログにある要望から3枚だけ選んで優先順位付けしてください、と言えばいい。

「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」では、マイクロソフトのチームの事例として、バックログと開発者のタスクリストの間に、WIP制限付きキューを設けて、作業量を調整する手法が取られていた。
その結果、リードタイムが劇的に短くなる効果が出た。

【5-2】バッファは、処理待ち項目を貯める場所。
利用シーンとして、ボトルネックの前に置く手法がよく使われる。
ボトルネック保護、保護アクションと呼ばれるらしい。

バッファをボトルネックの前に置く効果は二つある。
一つは、システム内の仕掛り数が増大するので、リーンの立場では、ムダが増え、リードタイムも長くなるが、容量制約の資源による作業が安定して流れるので、スループットも増える。
つまり、ボトルネックの稼働率を増やしてスループットを増やす。

もう一つは、ボトルネックへの作業項目の到着率のばらつきを吸収することで、ボトルネックの稼働率を上げること。

以上のように、キューとバッファを意識して使い分けることで、カンバンで流れる作業チケットを制御しやすくする。
「リーン開発の現場 カンバンによる大規模プロジェクトの運営」では、カンバンにキューとバッファを配置するノウハウが詳しく書かれていた。

【6】ばらつきの要因の解消の対処

カンバンが従来のアジャイル開発よりも良いとしても、運用が難しい原因の一つは、作業の到着率のばらつきを抑えることが難しい事だと思う。
「カンバン ソフトウェア開発の変革 Improving Service Delivery in Technology Business」では、ばらつきを与える要素の分類として、シューハートの分類「偶然原因」「突き止められる原因」を使っている。

管理図とは

【6-1】偶然原因は、ばらつきがランダム。
ばらつきの内部要因に相当。
例えば、ソフトウェアのバグ。
つまり、予測できない。
しかし、実は、チームやマネジメント層の制御下にある。
実際、ソフトウェアの品質を良くすれば、バグは減る。

解決策はいくつかある。
一つは、作業項目のサイズを整える。
例えば、チケットの粒度を整えたり、RedmineならIssueTemplateプラグインでチケット内容をテンプレート化する。

2つ目は、作業タイプごとに分類する。
例えば、チケットの種類をトピック・ストーリー・タスクに分ける。
あるいは、チケットをタスク・バグ・課題などのように分ける。

この時、チケットの種類ごとに、WIP制限を課すと尚良い。
つまり、開発メンバーの制約、開発環境の制約などのボトルネックを考慮して、WIP制限を課すと、リードタイムの短縮やスループットの増大に寄与する。

3つ目は、作業項目を優先度で分類する。
例えば、チケットの優先度。

優先度ごとにWIP制限を割り当てるとよい。
例えば、今日中に完了すべき特急チケットは、WIP制限1枚とする、など。

【6-2】突き止められる原因は、外部要因によるばらつき。
例えば、顧客による要望変更、マーケット環境の急激な変化によるプロジェクト中止、など。
突き止められる原因は、チームが制御できないが、予測可能ではある。
だから、事前にリスク対策を取ることはできる。

例えば、曖昧な要件に対しては、チケットを却下したり、対応しにくいために放置チケットを見える化することで対処する。
カンバンから、毎月のレポートで、曖昧な要件であるがゆえに却下されたチケットを載せておくと、ビジネスオーナーも気づいて、自分たちで容量の消費をしないように注意し始める。
つまり、不適切な要件記述から生じた「突き止められる原因によるばらつき」という根本原因を除去できたわけだ。

つまり、この事例では、カンバンが開発プロセスを透明化することによって、メンバーだけでなくビジネスオーナーにも影響を与えたことになる。
カンバンが与える透明性とレポートによる効果は、平均リードタイムとばらつきの範囲に対する影響を小さくさせて、根本原因を取り除いたわけだ。

【7】このように読んで理解してみると、カンバンは作業状況を見える化することで、透明化を推進し、組織変革をもたらしている事が分かる。
また、本の事例を読むと、作業チケットの流れをバリューストリームマップで表現してボトルネックの解消とスループットを向上させる部分は、すごくTOCに似ている。

でも、僕が一番興味深いのは、カンバンがメトリクスをかなり重視している点だ。
5つのメトリクス(WIP、リードタイム、納期遵守率、スループット、デリバリー効率)によって、チームや組織の改善が進んでいるかどうか、パフォーマンスをチェックする。
この辺りは、WF型開発で管理者が稼働率や生産性、原価計算をしている部分に似ている。

また、カンバンのメトリクスは、Redmineによるチケット駆動開発でも実現可能だ。
Redmineなら下記のように置き換えられる。

1)WIP＝イテレーション内の作業中のチケット枚数
2)リードタイム＝チケットの平均完了日数
3)納期遵守率＝イテレーション毎の、完了チケット枚数/(計画時のチケット枚数＋割り込み発生のチケット枚数)
4)スループット≒Velocity＝イテレーション毎の平均の完了チケット枚数

上記4つのメトリクスをイテレーションごとに算出すれば、チームの生産能力や改善能力を測定することもできるだろう。
このアイデアも実際に試してみたい。

プロジェクトマネージャへのお勧めの本

プロジェクトマネージャへのお勧めの本の記事があったのでメモ。
内容はすごく同意する。

PM（プロジェクトマネージャー）になったら絶対に読むべきおすすめの本6選（転載） | Books&Apps

僕も読んだことがある本が多いのですごく同感する。
下記の本は読んだ。

【1】「ソフトウェア見積り」は、「アジャイルな見積りと計画づくり」と合わせて読んだ。
見積りの各種技法が網羅的に分かりやすく書かれているのがいい。

僕は、統計に基づくスケジュールの基本公式は

スケジュール（月）=3.0×人月^1/3

ではなく、

スケジュール（月）=2.5×人月^1/3

を採用している。

例えば、見積り工数が20人月以上なら、上記の公式で工期を一旦はじき出し、要員計画を立てるやり方をよく採用する。
見積り工数が40人月くらいなら、工期は約6～7ヶ月くらいになるので、経験的にも妥当かな。
あくまでも参考値だが、システム提案という限られた時間でシステム計画を立てる時に役立つ。

【2】「曖昧性とのたたかい―体験的プロジェクトマネジメント論」は、典型的な受託開発案件で、WF型開発を行うノウハウが書かれている。
日本人向けのイメージ。

【3】個人的には「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」が好き。
過去に感想をたくさん書いた。

アート・オブ・プロジェクトマネジメント: プログラマの思索

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する: プログラマの思索

Velocity駆動のイテレーション計画の作り方とは: プログラマの思索

【4】他に、「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」も好き。
プロジェクト管理のアンチパターン集なのだが、読んでいて、思わず笑ってしまう。

「アドレナリンジャンキー」「死んだ魚」「レミングサイクル」「残業に見る予兆」「永遠の議論」「ポーカーの夕べ」「明日には日が昇る」「ほったらかしの成果物」「変更の季節」の言葉を聞くだけで、そうだよ、なるほど！と思ってしまう。

プロジェクト管理のアンチパターン集～アドレナリンジャンキー: プログラマの思索

ぽんぽんぺいんなう＼(^O^)／ | 「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」トム・デマルコ他

書評『アドレナリンジャンキー』 ｜ ライフハッカー［日本版］

マネージャのためのRedmineプラグイン「Lychee Enterprise」のCMがYouTubeに公開されている

マネージャのためのRedmineプラグイン「Lychee Enterprise」のCMがYouTubeに公開されていたのでメモ。

Redmineプラグイン「Lychee Enterprise」も一つのパッケージ製品として、こんなCMで流れるととてもインパクトがある。
「あなたのプロジェクト管理をシンプルに」というメッセージは、これだけビジネスが速く変化している現代において、進捗管理に苦労しているマネージャにすごく響くと思う。

ところで、最近は、自分たちで作ったソフトウェア製品やソフトウェアの考え方を簡単に広められるようになったと思う。

例えば、倉貫さんが提唱する「納品のない受託開発」のアイデアは、Blogですごく分かりやすく公開されているし、各地のITコミュニティで講演されている。IT業界にいる人ならたいてい知っているはず。

また、平鍋さんも、モデリングツールastahを使って、UMLやSysMLなどのモデリング技法をYouTubeで公開されている。動画で見る方が確かに分かりやすい。

そんな事例を見ると、SNS全盛の現代では、プログラミングという技術力さえあれば、簡単に製品やビジネスモデルを宣伝告知して、世の中に簡単に広められる。
つまり、以前のように、TVコマーシャルに大量の金額を投資する必要もないし、大量の営業マンを抱えて、無鉄砲に一見さんを訪問する必要もない。
むしろ、現場の開発者がいるITコミュニティを通じて、草の根で口コミで広がる方が確実だし、熱烈なファンになってくれたら営業マンの代わりになってくれる。

面白い時代になったなあと思う。

さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーの感想 #RDRAセミナー

さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーに行ってきた。
要件定義の考え方がすごく参考になった。
感想をラフなメモ書き。

【元ネタ】
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー - アジャイルウェア | Doorkeeper

要件構造の見える化 #RDRAセミナー: ソフトウェアさかば

さくさく要件定義セミナー　in 大阪 from Zenji Kanzaki

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

【1】要件定義の問題。
いつまで経っても、システムの全体像が見えない。
大量のドキュメントばかりで、肝心のシステムが説明されない。
分析と言う名の転記作業ばかりで、要件定義が完了しない。

では、どうすればいい？

要件定義、要件分析では、個人作業は非効率。
レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。

その場で皆で合意を積み上げて進める方がいい。
ステークホルダーの合意のベースを作る方が重要。

議論を積み重ねる時に、使われる手法として、リレーションシップ駆動要件分析RDRAがある。

リレーションシップ駆動要件分析RDRAでは、要件定義書の元ネタとしてモデルを作る。
その時、システムよりも、システムを取り巻く環境に注目する。

システムは、エンジニアがこだわりがち。
その中身の説明は、最終的にはプログラムであり、ユーザは理解しにくい。
エンジニアの立場では、システムの設計は自力で何とかなる。

しかし、システムを取り巻く環境の方が要件定義では重要。
先に、システムを取り巻く環境から、要件を先に固める。
いかにプログラムレスで表現して、エンジニアがユーザと会話できるようにするか？

【2】リレーションシップ駆動要件分析RDRAの構造は、「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」の４つ。

【2-1】システムの価値は、例えば、システムリプレースでは語られない時が多い。
AsIsは分かるが、ToBeが分からない。
ユーザから見れば、既に動いているシステムが要件そのもの、と言うが、実際は何のために作ったのか、その理由や背景が忘れ去られている。

【2-2】システム外部環境は、業務フロー、概念モデル(または用語集)、利用シーンから成る。
利用シーンは、業務フローがない場合に使う。
例えば、初めて作るユーティリティツールのように、まだ実際のシステムがない場合に、そのシステムがどのように使われるのか、という利用状況を描き出す。
業務フローがない場合、誰がどう使うのか、というイメージが湧きにくい。

利用シーンは、ユースケースとは違う。
ユースケースは、アクターとシステムの相互作用を表すから、システム境界に含まれる。
利用シーンは、システムを使って何が嬉しいのか、を表す。
利用シーンは、ユースケースが何故存在するのか、という理由や根拠になる。

【2-3】システム境界は、UIのような画面・帳票、外部I/Fのような外部システム連携などがある。

【2-4】リレーションシップ駆動要件分析RDRAは、モデル同士のリレーションに注目する。
リレーションシップ駆動要件分析RDRAでは、モデル同士の依存関係を表したい、という目的がある。

問題意識としては、混乱している要件定義フェーズを収束させたい。
その鍵は、モデルの依存関係にある。

よくある問題は、いきなり機能一覧を洗い出すものの、要件が発散してしまうこと。
特にリプレース案件で多い。
現状のシステムから、機能一覧はすぐに洗い出せるが、それだけでは要件定義は終わらない。

何故、その機能やデータがいるのか？
AsIsではなく、本来のあるべきシステム像は何なのか？
例えば、昔は汎用機やCobol、10年前はVBでガリガリ作られたデスクトップアプリだったろうが、現代では、クラウドの上のWebシステムや、工場でも作業者がタブレットを持って歩きまわるように実現すべきではないか？
AsIsの要件にひきずられると、高い費用を払ったのに、昔と変わり映えしないシステムになってしまい、ユーザにとって価値がない。

まずは、システムそのものではなく、システム境界を定めよう。
システムのスコープは何か？
システムとユーザのインターフェイスは何か？

システム境界の話で要件定義がまとまらないなら、システム外部環境に話を移そう。
どんな業務フローでシステムが必要なのか？
どんな利用シーンでシステムが使われると嬉しいのか？

それでも駄目なら、システムの価値を探ろう。
なぜ、システムは必要なのか？
誰にとって、システムは必要なのか？

「システムの価値」「システムの外部環境」「システム境界」「システム(内部)」という4つの視点が重要。
でも文章では分かりにくい。
だから、図ないしモデルで描こう。

但し、リレーションシップ駆動要件分析RDRAで描いたモデルは、ユーザ向け資料の元ネタであり、ユーザ向け資料は別途作成する必要がある。

【3】Q.価値を考える人とシステムを考える人は別々になりがちだが、リレーションシップ駆動要件分析RDRAではどのように対応すべきか？

価値を考える人＝ユーザ、ドメインエキスパート。
システムを考える人＝アーキテクト、エンジニア。

あるいは、価値を考える人＝元請けSE。
システムを考える人＝下請けPG。
日本のIT業界では、多段階下請構造によって、要件定義とシステム開発の工程が分断されがち。

A.攻め方が違う。
初めての新規システム案件なら、システムの価値→システムの外部環境→システム境界→システムのようにブレイクダウンしていく。

リプレース案件なら、AsIsのシステムがあるから、システム境界(or システム)→システム外部環境→システムの価値のように、リバースエンジニアリングしてシステムの構造やシステム境界を明確にしてから、システムの価値を探っていく。
リプレース案件では、機能一覧は普通にあるはずなので、そこからシステムの価値へ登っていく。

どちらにせよ、4つの観点のブレイクダウンやボトムアップで双方向に行き来する。

【4】コンテキストモデルでは、アクターとしてステークホルダーを洗い出す。
要求モデルでは、アクターの要求を洗い出す。

お金の権限を持つステークホルダーとその要求を洗い出せているか？

業務フローは作業フローではない。
業務フローは、普通、システムに大きく依存する。
作業フローは不要。
担当者の作業はコロコロ変わるから。
ロールや業務を洗い出したい。

ユースケースは機能分割しない。
ユースケースは機能ではない。
リレーションシップ駆動要件分析RDRAにおける「機能」とは、パッケージ製品のカタログの機能一覧の項目と同じレベル。
例えば、MSWordなら、こんな機能があります、というイメージ。

イベントモデルは2種類ある。
例えば、GoogleMapsのように、1回のやり取りでデータが確定するもの。
それは、機能モデルで表現できる。

一方、外部システムとのバッチ連携のように、データを何度もやり取りする場合がある。
それは、プロトコルモデルで、状態遷移図として表す。
イベントが発生したら、次の状態へ移る、という内容をプロトコルモデルで表す。

【5】リレーションシップ駆動要件分析RDRAでは、モデルをEnterprise Architectで描きます。

設計開発を強力に支援するUMLモデリングツール Enterprise Architect 概要と特徴

Enterprise Architectの良さは、設計情報がリポジトリに格納されるので、モデルの関連付けが自動付与されること。
また、モデルを描けば、設計リポジトリから機能一覧をすぐに出力できる。
機能一覧を元に、ユーザにヒヤリングして、要件を深堀りできる。

さらに、依存関係が不十分なモデルがある場合、クエリを使って設計リポジトリから対象モデルをすぐに検索できる。
要件定義レビューの前に、担当者にモデルを修正するように作業指示も出せる。

他に、Enterprise Architectはリバースエンジニアリングが強い。
JavaやC#だけでなく、RubyやActionScriptなどの軽量言語もサポートしているのが強み。

Enterprise Architectで、現状のシステムのソースを全部読み込み、クラス同士の関連をリバースエンジニアリングした後、モデルを整理していけば、システムの構造が見えてくる。
そこから、システム境界、システムの外部環境、システムの価値を探っていく。

【6】リレーションシップ駆動要件分析RDRAで作成したモデルでは、網羅性と整合性の根拠を説明できる利点がある。

アクター→要求→利用シーン→ユースケース→画面→機能→データ　のように関連付けていくので、なぜその機能やデータが必要なのか、という根拠を説明することはできる。
つまり、ある要求に基づく画面や機能が網羅されているか、という根拠を説明はできるだろう。

また、モデルの整合性は、モデル同士のリレーション、依存関係で語れる。
例えば、機能一覧にあるこの機能は、このユースケースを実現したものであり、それはこの設計書に書かれている、など。

要件定義では、要件の網羅性、要件の整合性を語ることができれば、ステークホルダーを説得することができる。

【7】要件定義プロセスはタイムボックスで作業すると良い。
つまり、イテレーションごとに、要件定義を進めていく。

最初のイテレーションでは、荒い粒度のモデルしか作れないが、速く作れる。
3回ぐらいのイテレーションで、まずはシステムの全体像を把握できる。

その後のイテレーションで、モデル同士のリレーションを正しく書いていく。

つまり、前半のイテレーションでは、システムの全体像をつかむために速く成果物を作り、後半のイテレーションで成果物の品質を向上させていく。
すなわち、前半は漸進型開発、後半は反復型開発に切り替える。

【7-1】お客様は大量の成果物を好む。
詳細は見ないけれど。
お客様は根拠を聞きたがる。

お客様の打合せに合わせて、イテレーションを組み立てる。
お客様の打合せに合わせて、資料を作り、ブラッシュアップしていく。

まず、システム地図や機能一覧を作る。
そして、詳細を詰めていく。

マイルストーン(イテレーションの区切り)の単位で、成果物の範囲を決める。
そうすれば、要件定義が成果物の転記作業の繰返しにはならない。

【7-2】Q.リレーションシップ駆動要件分析RDRAでは、システムの実現可能性はどこで行うのか？

A.リレーションシップ駆動要件分析RDRAでは、要件定義とアーキテクチャの話を分けている。

・要件定義フェーズでアーキテクチャ設計は並行して行うが、要件定義とアーキテクチャ設計は別チームで行う

・要件定義チームから非機能要求を渡し、アーキテクチャチームでアーキテクチャ候補を返す

・二つのチームは手段で話をせずに非機能要求で話をする。

・後付けでもいいので「非機能要求があってアーキテクチャがある」という形は崩さないことが重要。そうすればアーキテクチャ決定の根拠が明確になる

要件定義チームとアーキテクトチームに分けた理由は何か？
アーキテクトが要件定義チームに入ると、ブレーキをかけがち。
例えば、その要件は、現在採用しているフレームワークやアーキテクチャでは実現できませんよ、とか。
あるいは、リプレース案件では、AsIsのアーキテクチャに引きずられて、ToBeのアーキテクチャを考えにくくなる。

【8】今日は、システム地図を書きます。
システム地図とは、アクター、ユースケース、画面、機能、データ、外部システムなどの項目を関連付けて、システムの全体像を表したもの。
システム地図は数時間で書ける。

RDRAのモデルは種類が多いので、丸一日かかる。
だから、今日はシステム地図を書きます。

【8-1】僕達のチームで作ったシステム地図はコチラ。
@spring_kumaさんのおかげで、かなり品質の高い成果物が作れたと思う。
@spring_kumaさんに感謝。

さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナーのお題「貸会議室.com」 from akipii Oga

【9】システム地図を書いた感想：
僕の感想と、発表後に聴衆の方からあがった質問も書いておく。

【9-1】利用シーンとユースケースの使い分けが難しい。
混乱した。

利用シーンは、システムを使って嬉しいこと。
利用シーンは、ユースケースの根拠になる。
なぜ、そのユースケースは必要なのか、その理由は、こんな利用シーンが必要だったから、と。

【8-2】ユースケースは出しやすい。
ユースケースはアクターとシステムのインターフェイスになるから。

ユースケースは普通は画面で実現される。
つまり、ユーザがシステムとやり取りするI/Fが画面だから。
そして、画面のボタンが「機能(Function)」になる。

【8-3】要求が結びつくアイコンは？
それはアクターまたは利用シーン。

機能に要求を結びつけても説明しにくい。
モデルが複雑になる。

【8-4】メール送信や決済代行システムのモデルが表現しにくい。
バッチ処理で描こうとして、上手く書けない。
僕らのチームは、画面から予約ボタンを押したら、予約確認メールが飛ぶような仕組みで表現して逃げた。

神崎さんの回答は、バッチかどうかはアーキテクチャの話。
要件定義では、アーキテクチャの話は不要であり、システムと機能やデータがどのように関連付けられているか、が分かれば十分。

【8-5】システム地図を描く利点は、自分たちが弱い部分が判明するのが良い。
例えば、決済代行システムの部分が描きにくい、など。

システム地図が描きにくい部分のモデルを特定できれば、ユーザのヒヤリングをその部分に集中することで、ヒヤリングの精度を上げることができる。
不明点に重点を置いてヒヤリングすればいい。

【8-6】システムの地図の粒度は？

粒度はケースバイケース。
イテレーションごとに詳細化していく。
最初から細かく書く必要はない。

最初のイテレーションでは粗い粒度で、システム地図を描き、システムの全体像を把握し、自分たちの弱点を見出す。
その後のイテレーションで、ユーザにヒヤリングしながら、モデルを詳細化していけばいい。

【8-7】他チームのシステム地図で面白かった点は、利用シーンから考えたので、良い議論ができた、ということ。
例えば、貸会議室.comのお題は、利用者と貸主のマッチングサイトを作ること。

その利用シーンとして、貸主が空いている貸会議室を登録するだけでなく、貸会議室.comでは儲からないから、貸し会議室.comから貸会議室を予約取り消しする機能が必要だね、という議論があったらしい。
僕達のチームでは、そんな発想は出なかった。

つまり、利用シーンを元に、メンバー同士で議論していたら、そんな機能が必要である可能性まで深く議論できたことになる。

【8-8】貸会議室.comのお題というリッチピクチャがあったから、システム地図が描きやすい。
実際の要件定義では、貸会議室.comのお題のようなリッチピクチャは存在しない。
真っ白な所から、システム地図を描き出す必要がある。
要件定義は、そういうもの。

【9】リレーションシップ駆動要件分析RDRAの全体感想：

「モデルベース要件定義テクニック―要件定義書がスラスラ作れる」を読んでいたから、4つの観点やモデルは理解していたが、実際の話を聞いてかなり理解できた。
神崎さんの話を聞くと、要件定義でよくある失敗を踏まえたノウハウがたくさん散りばめられている。

【9-1】要件定義フェーズでは、少人数の担当者が限られた期間で要件を収集し、ステークホルダーの合意を得て、要件を確定しなければならないプレッシャーがある。
また、作成した要件定義書は、その後の設計・開発フェーズの元ネタになるので、開発チームにとって非常に重要だ。

例えば、要件定義書で既に要件が漏れていたら、開発チームは対処できない。
受入テストになって初めて、要件漏れが発覚して、デスマーチになりがち。

あるいは、システムの価値は要件定義フェーズでしか得られない。
要件定義フェーズでシステムの価値を明確に定義できなければ、開発チームは、システムの価値を気にせず、ひたすら作ることだけに集中してしまいがち。
受入テストになって初めて、ユーザからこんなシステムが欲しいのではなかった、と言われる。
でも、開発チームにとって、そんなことを言われても、自分たちの責任ではないよ、と言いたくなる。

【9-2】リレーションシップ駆動要件分析RDRAのポイントは、二つあると思う。

一つ目は、モデル同士の依存関係に着目することで、要件の網羅性や整合性の根拠を説明しやすくなること。
ユーザからの質問や要件定義ビューで、要件の網羅性や整合性の根拠を語ることが出来れば、スムーズに要件分析できる。

2つ目は、要件定義もアジャイル開発のようなタイムボックス型の作業にすることで、要件定義の成果物をブラッシュアップしやすくなること。
最初から完璧な要件定義書を作るのではなく、イテレーションに応じて、粒度を変えて、詳細化するタイミングを設定すればいい。
例えば、2ヶ月間で要件定義を終わらせるならば、1週間毎にユーザヒヤリングの場を設けてマイルストーン化し、最初はシステム地図で全体像を把握し、機能一覧を作り、詳細化していけばいい。

このテクニックを実際の現場でも使ってみようと思う。

「Open Source Strategies for the Enterprise」～開発環境はベンダロックインからオープンソースへ進化する

Jenkins ユーザ・カンファレンス 2015に参加できなかったけれど、昨今の開発環境の流れについてメモ。

【元ネタ】
Open Source Strategies for the Enterprise?-?O'Reilly Media

≫ Jenkins ユーザ・カンファレンス 2015 東京 ? セッション/LT 日本Jenkinsユーザ会

Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015 - yukungのブログ

三浦カズヒト(エモいこと言う人(自動))さんはTwitterを使っています: "早い！！早いよyukungさん！ｗ Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015 - yukungのブログ http://t.co/pBPzNB2GQA"

【1】Linuxが出る前の2000年以前は、開発環境はベンダロックインされているのが普通だった。
マイクロソフトのVisualBasic、VisualStudioが典型例だっただろう。
他にも、IBMやらCoboleベンダー、C言語ベンダーが提供した開発ツール上で、プログラミングし、デバッグし、リリースするのが普通だった。

ベンダロックインされた開発環境では、開発環境の不明点があったり、バグがあれば、ベンダーが必ずサポートしてくれる安心感はある。
しかし、IT業界のように、案件ごとに現場を行き来するエンジニアにとって、開発ツールがバラバラであるのはすごく苦痛だ。
ベンダロックインされた開発ツールのノウハウは、他の現場では使えず、また一から開発ツールを覚えなければならないから。

また、ベンダロックインされた開発ツールは、大手ベンダーでない限り、VerUpの頻度が遅い。
PCというハードやDBなどのミドルウェアのVerUpの速度に、開発ツールがついていくのは結構大変だ。
せっかく安定している開発環境をVerUpして動かなくなるのはよくあったし、異なるバージョンの開発環境が混在するのも面倒だ。

さらに、ベンダロックインされた開発環境は、その時代の最先端の開発ノウハウが提供されていたかもしれない。
しかし、これだけ技術進歩の速い時代では、むしろ弱点の方が大きくなっている。
例えば、SAPでも、SAP特有の開発環境を用意しているが、今となってはCobolチックで、アジャイル開発に慣れた開発者から見れば触りたくもない代物だろう。

以前のIT企業は、「技術の標準化」という活動で、開発ツールを自社内で統一し、そのノウハウを共有させようとしてきた。
しかし、周囲の技術の進化のスピードに乗り遅れやすく、すぐに陳腐化しやすい弱点があった。

【2】現代は、GitHubによるプルリクエスト主導のアジャイル開発が主体となっているから、いかに開発環境を追随させていくか、という流れで技術進化している。
たしか、誰かが「エンタープライズ開発でも、オープンソースでやっているような開発スタイルを取り入れるべきだ」と言っていたが、まさにその通りだと思う。

今はベンダー主導の開発ツールよりも、オープンソースで育まれた開発ツールの方がどんどん進化しており、よりアジャイルな開発スタイルを実現させている。

その筆頭がGitHubであり、他にも、Jenkinsがあり、クラウドなインフラを提供するツール群があったりする。
もちろん、その流れに、Redmineなどのチケット駆動開発も含まれているだろう。

【3】今後の技術者は、ベンダーが提供した製品やツールに慣れるよりも、オープンソースの開発スタイルに慣れた方が数多くのメリットがあるだろう。

まず、オープンソースの開発スタイルの方が最新技術のトレンドに触れやすい。
次に、オープンソースの開発スタイルに慣れておけば、他の会社や他の現場に行っても、同じような技術を使える。一から覚え直す必要がなくなるし、開発ツールに慣れる学習時間というロスが減る。

さらに、オープンソースの開発ツールのコミュニティにも参加したりコミットできれば、世界中の開発者が今まで体験してきた開発ノウハウを共有できるし、逆に、新しい開発ノウハウを提供して、他の開発者に好影響を与えることもできるだろう。

「Open Source Strategies for the Enterprise」という本がオライリーで英語本が出ているらしく、その本では、上記のような流れの内容が書かれているらしい。
翻訳が出たら読んでみたいと思う。
(Amazonで見ると、Kindleで無料なので、読める人は読んでもいいかもしれない)

ITの地殻変動はどこに起きているのか～ソフトウェアの複雑さをどのようにして手なづけるか？

ソフトウェアの本質的な問題とは何だろうか？
僕は、「ソフトウェアの複雑さをどのようにして手なづけるか？」という問題だと思う。
以下、ラフなメモ書き。

【1】問題提起

ソフトウェアをインタプリタのように、書いては動かし、というやり方で作っていく時は楽しい。
しかし、じきに、行数が大きくなり、ソースファイルを分割して、クラス設計していくうちに、どんどんソフトウェアは肥大化し、複雑になっていく。
大人数で開発し始めると、当初の設計思想や開発の規律からズレ始める。

ソフトウェアの複雑さをどのように手なづけて、制御していくべきか？
その問題を幾つかの観点から考えてみる。

【2】単純な解決法～間接層を設ける

一つの塊で実装するのではなく、分割する。
その時に、間に「間接層」を入れる。
例えば、DAO、サービス層かな。
ダイクストラの下記の言葉を思い出す。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

ポインタを制する者はプログラミングを制する: プログラマの思索

florigenの日記

複雑さを間接層に押しこむことでスッキリするが、じきに複雑さは手に負えなくなる。

【3】DOAの発想

DOAでは、全システムのデータベース層を一元化する方針。
この最たる例がERP。
データを一元化すれば、データ保守がやりやすくなるし、データの精度も高くなり、データを再利用しやすくなる。
つまり、複雑さをデータ層に押しこむ。

この発想を推し進めたのが渡辺幸三さんの三機能モデル。
「業務層(ユーザの業務フロー)とデータ層(DB)に複雑さを集約し、機能層(システム)は複雑にしない」という方針。
データを重視するからこそ、データ入力やデータ保守を行う業務を複雑にしてでも、データの精度を上げる方向へ持っていく。
下手にシステムの機能をリッチにして、どんなデータでも入力できるようにすると、データの精度が落ちてしまう。

しかし、データの一元化を推し進めたERPの導入は、今となっては負の遺産に近い。
ERPのパラメータを覚えるのが業務SEの仕事みたいになり、業務設計のノウハウが消えてしまった。

また、ERPは業務の標準化を押し付けるために、独自の業務を行うユーザ企業にはフィットしない場合がある。
結局、ERPを単なる帳票出力システムとしてしか使えない事例も多い。
逆に、ERPをカスタマイズしすぎて、VerUpなどの保守コストが増えるデメリットもある。

【4】OOAの発想

OOAでは、部品オブジェクトを作り、再利用する方針。
いわゆるコンポーネント設計。
複雑さをコンポーネントに押し付けて、外部から必要なAPIを使う。
カプセル化、情報隠蔽の発想。

例えば、.NETのDLLやJavaのJar、Warのようなコンポーネント。
Javaでは、EJBがその理想に近かったのではないか。

しかし、部品の再利用は難しい。
ビジネスオブジェクトのような粒度の高い部品はなかなか作れない。
ソフトウェアプロダクトラインが「コア資産」という概念で、再利用できるコンポーネントを生み出そうとしたが、共通の原則を見出しにくい。

また、一つのシステムを作るために、コンポーネントをつなげるノリの部分の開発が難しいのだ。
ノリの部分がコンポーネントよりも大きなソースになってしまいがち。

他にSOAのように、複数のシステムをEAIのようなツールでシステム連携し、サービスと見なして統合する手法もあった。
しかし、システム連携の開発が正直難しいのだ。
「ドメイン駆動設計」でも、「顧客・供給者の開発チーム」パターンや「順応者」パターン、「腐敗防止層」パターンなど、色んな手法を使わざるをえない。

結局、フレームワークのような開発基盤しか、再利用できるシロモノは作れなかったように思える。

例えば、アジャイル開発の戦略では、優れたフレームワークを開発基盤として用いて、アーキテクチャをできるだけ固定化しておき、フレームワーク上の薄いロジック層をアジャイルに開発していく。
つまり、要件や仕様というスコープ変更に重点を置き、アーキテクチャのリスクをフレームワークで無くしておいた方が、アジャイルに開発はしやすい。

他に、継続的デリバリーはどうか？
継続的デリバリーは、あくまでも開発プロセスのリードタイム短縮に焦点を置いているのであり、ソフトウェアの複雑さを解消しようとする方法ではないと考える。

【5】最近の傾向

ソフトウェア開発がコモディティ化している現在、ソフトウェアの複雑さをどのように手なづけようとする方向に向かっているのか？
僕はその方向性を知り尽くしていないが、ファウラーの話を読むと、「犠牲的アーキテクチャ」「マイクロサービス」の概念が見て取れる。

Martin Fowler氏の語る“犠牲的アーキテクチャ"

マイクロサービスとSOA

マイクロサービス設計概論

犠牲的アーキテクチャ～リプレースを正当化するアーキテクチャ: プログラマの思索

マイクロサービス～疎結合なアーキテクチャが時代に合っている: プログラマの思索

【5－1】犠牲的アーキテクチャ

システムのアーキテクチャを定期的にリプレースを実施するやり方。
フレームワークや開発基盤を定期的に入れ替える。
複雑さを押し込めるのではなく、複雑さを解消できなくなったら、定期的にリプレースしてしまう。

すごくリスキーなやり方に思えるが、このやり方を採用したい時もある。
ハードの進化、ソフトウェアの技術動向の変化などによって、アーキテクチャそのものの寿命がすごく短くなっているからだ。

例えば、以前はStrutsで作っていたが、StrutsがVerUpしなくなって、順次Railsに入れ替えた。
しかし、アクセス数が多くなり性能要件に問題があるから、Scalaに順次置き換えた、とか。

犠牲的アーキテクチャを採用する場合、どのタイミングで再構築すべきかという意思決定と、再構築の方法が問題になるだろう。
リプレースできるようなアーキテクチャは、どんな構造であるべきか？

【5－2】マイクロサービス

一連の小さなサービスで1つのアプリケーションを開発する手法。
「ドメイン駆動設計」の「境界づけられたコンテキスト（Bounded Context）」パターンや「公表された言語（Published Language）」を使う。
例えば、REST APIとかJSONとか。
マッシュアップが一番の例だろうか。

サービスごとにモデルのコンテキストがあり、サービス同士のI/Fがコンテキストの境界になる。
サービス同士のI/FがREST APIのような「公表された言語」で、やり取りされる。

今は、Google、Amazon、Yahooなど色んなWebサービスが公開されていて、それらを連携するだけで色んなアプリが作れる。
GoogleMapが一番良い例。

Webシステムの機能は、色んなマイクロサービスの集合体に置き換える方式であってもいい。

ビジネス的には、いわゆる外部接続用のI/Fを公開して、たくさんの開発者に使ってもらう方がメリットがある。

マイクロサービスの利点は、他のサービスと独立しているから、デプロイ＆リリースを頻繁にできたり、スケールアウトしやすかったり、障害の影響を最小限に抑えられる点があるだろう。

"Microservices"を読んだ | SOTA

(引用抜粋)
・Microservicesはライブラリを使うが，主要なコンポーネント化はサービスへ分割することで行う
・Microservicesでは，チームはプロダクトを持っていると意識する
・Microservicesはビジネス能力に基づきサービスの分割を行う
・Microservicesアプリケーションは，出来るだけ粗結合であることを目的にする
・Microservicesは適切な場所で適切なツールを使うことを好む
・データの分散管理は更新管理に影響を与える
・Microservicesアプリケーションは，継続的デリバリーや継続的インテグレーションの経験をもつチームによって構築されている
・サービスをコンポーネントとして扱うため，アプリケーションはサービスの障害に耐性のあるように設計される必要がある
・サービスの分割により開発者は変化のスピードを落とすことなく変更をコントロールできる
(引用完了)

マイクロサービスは、Webシステムにおけるコンポーネントとイメージできるのではないか？
だとしたら、マイクロサービスに複雑さを押し付けた反面、マイクロサービスで取得したデータを組み立てるノリの部分の開発が膨れ上がる場合もあるだろう。

つまり、複雑さをマイクロサービスへ押し付ける場合もあれば、マイクロサービスの呼び出し側に押し付ける場合もある。

【6】「ソフトウェアが宿命的に抱える「複雑さ」をどのように手なづけるか？」という問題は、たぶん絶対唯一の回答はないだろう。
ただし、その時代に合った手法と概念が生まれて、特定の状況では問題の一部が解決できる。

今後も問題意識として持っていく。

OSSのERP「iDempiere」の資料のリンクPart2

OSSのERP「iDempiere」の資料のリンクをメモ。

【元ネタ1】
OSSのERP「iDempiere」はどこまで使えるか-アプリケーション開発基盤としての魅力

ERPと言えば、SAPがデファクトスタンダード。
海外に工場や小会社のある大企業なら、SAPを入れていて当然。

しかし、SAPを入れるほどの体力も必要性もない中小企業や海外子会社では、独自のERPとして、iDempiereを導入し運用する方法もある。
iDempiereはオープンソースなので、カスタマイズ箇所をきちんと見極めれば、基盤そのものはVerUpに追随し、自分たち独自の要望を機能追加すればよい。
あるいは、親会社はSAP、小会社はiDempiereで使い分けて、データ連携する方法も採用できる。

【元ネタ2】
やってみよう iDempiere: iDempiere 想定業務フロー

やってみよう iDempiere: iDempiere 新想定業務フロー（欲張らずにシンプルに）

iDempiereの資料: プログラマの思索

iDempiereのインストール方法と画面キャプチャ: プログラマの思索

iDempiereを実際に製品評価している記事を見つけた。
iDempiereの想定業務フローとして「受注後発注　（受注先行型）」「事前発注・在庫販売　（発注先行型）」「パーツ事前発注・受注後組み立て」の業務フローを作り、iDempiereにマスタ登録して運用を試みようとされている。

ERPが面倒なのは、使う前にたくさんのマスタを事前に登録するコストがある点と、実際の現場の業務フローを作成するコストがある点だ。
前者はいわゆるデータ移行。
後者はフィットギャップ分析。

上記のような事例があると取り掛かりやすいだろうと思う。
実際に試してみたい。

RDRAセミナーが1/24(土)に開催されます

RDRAセミナーが1/24(土)に開催されるのでメモ。

【元ネタ1】
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー - アジャイルウェア | Doorkeeper

(引用開始)
さくさく要件定義（リレーションシップ駆動要件分析RDRA）セミナー

＜日時＞

2015/1/24（土）13:30?17:00（13:00開場）

＜会場＞

NSE 梅田店B
大阪市北区曽根崎2-5-10 梅田パシフィックビル6階

＜協賛＞

株式会社アジャイルウェア

＜セッション概要＞

モデルベースの要件定義を体験します。
システムの全体像を短時間でつかみ、要件を組み立てるためのモデリングをご紹介します。

要件を組立るための考え方を知ると要件定義がさくさく進みます。

１時間のレクチャーに続きグループ作業で要件定義のモデリングを行います。
EAを持っている方はEAで、持っていない方はRDRA用のツールを使って作成します。

内容は「モデルベース要件定義テクニック―要件定義書がスラスラ作れる」のエッセンスになります。

要件定義に興味のあるかたはお気軽にご参加ください。

※参加者にはRDRAツール(ベータ版)を差し上げます。

＜講演者＞

神崎 善司 (かんざき ぜんじ)
株式会社バリューソース
(引用終了)

【元ネタ2】
既存システムを分析するコツは「システムの地図」を作ること （1/3）：CodeZine

UMLを使った既存システムの分析 （1/3）：CodeZine

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

【1】RDRA(リレーションシップ駆動要件分析の略)で注目する点は、UMLの各種ダイアグラムを使って、システム提案や要件定義の資料の元ネタを作れること。

システム提案や要件定義フェーズでは、現行の業務システムを洗い出し、新システムの要件や方式を決定する作業が多い。
この作業の技術的課題は、ゴールやスコープが定まらないと、いつまでやってもキリがないことだ。
だから、短時間で、広く浅く新システムの特徴を見極めて、後工程の作業へスムーズにバトンを渡すのが重要になる。

このフェーズの役割の人は、アーキテクトないしITコンサルタントと言われる人が多いだろう。
彼らは、自分の経験を踏まえて、自分なりの手法を身に付けているが、その手法は第三者に共有されていない。
だから、新人のアーキテクトはいつも苦労する。
この辺りの手法をもっと共有できないものか、といつも思っている。

【2】RDRAという手法が最上の解決策とは思わないが、一つの手法を提示していると考える。
個人的に気に入っているのは、UMLの各種ダイアグラムを使って、「システム価値」「システム外部環境」「システム境界」「システム内部」の4つの観点でシステムを分析する手法を提示している点だ。

システムには利害関係者が求める要求があり、それが「システム価値」になる。
システムの運用の立場では、業務フローや利用シーンがあり、それが「システム外部環境」になる。
もちろん、外部システム連携などの外部システムも含まれる。

また、ユーザとシステムの接点はユースケースだったり、画面・帳票などのユーザインターフェイス、外部システムの接続I/Fだったりする。
それらは、「システム境界」に相当する。

さらに、システム内部の機能へ詳細化すると、機能モデル・データモデル・ドメインモデルになり、それが「システム内部」になる。

つまり、「システム価値」「システム外部環境」「システム境界」「システム内部」の4つの観点で作られた成果物は相互にリンクしており、トレーサビリティを意識して作られている。
換言すれば、自分が今どのスコープの成果物を作っているのか、を常に意識させてくれるので、無駄な成果物を作る作業が省かれやすい。

RDRAを使った手法が使いやすい場面は、既存システムのリバース・エンジニアリングだろう。
広く浅くシステム要件を理解したい時に使えると思う。
「既存システムの調査分析はシステムの地図を作ることだ」という指摘は同意する。

【3】但し、いくつか注意点はある。
一つは、システム要件を広く浅く理解する時には役立つが、開発方式やアーキテクチャなどには触れていない点だ。
この点は、RDRAという手法の前提条件として、「方式は記述しない」と既に明示されている。

その理由は、既存システムの要件をリバースした後、新システムを作り直す場合、既存の開発方式をベースに作り直すケースは少ないし、既存の方式に囚われていては、新システムをリプレースする意味もないからだ。

しかし、新システムの方式設計を描きたい時もあるし、新旧のシステムのアーキテクチャを比較検討したい時もある。
その場合は、他の手法を使うしか無いだろう。

もう一つは、RDRAの成果物の粒度を決めにくい点だ。
RDRAの成果物は顧客に提出する資料とは別であり、資料の元ネタになるものと位置づけられている。
だから、広く浅く作るために、粒度はおおまかになりやすい。
ある程度の詳細化は必要だろうが、要件を詳細化し始めると、後工程の作業に入ってしまうので、要件定義のゴールやスコープからずれてしまう。

その意味では、粒度をどのレベルで落としこむか、というのは難しい所だと思う。

この辺りも実際のセミナーで聞いてみたいと思う。