RDRA+EAで要件定義モデリング セミナー

　昨日は、スパークシステムズ ジャパンのセミナー「RDRA+EAで要件定義モデリング セミナー」に参加してきました。なにより、RDRAの開発者・神埼善司氏の話を直接お聞きしたかったのです。

　神崎氏の話を聞いていると、RDRAの本「顧客の要求を確実に仕様にできる要件定義マニュアル」を書かれた時と今とでは、考え方に変化が起きていることがわかります。例えば、要望、要求、要件の定義など。最近は既存システムの分析ノウハウなども公開していますし、神崎氏の考え方も日々進化しているのでしょう。

　セミナーは要件定義のプロセスの説明から始まったのですが、「タイムボックス」というマネジメント手法についてかなりの質問が出ました。私は、RDRAはウォータフォールでも非ウォーターフォールでも使えるフレームワークと認識しているので、タイムボックス（反復的な要件定義マネジメント）にこだわることはないのになぁ…　と議論を傍観していました。ただ、神崎氏の「広く浅くの要件定義を繰り返すことで必要十分な要件定義に到達する」という考え方は非常に良いと思っているので、これはRDRA実践時にはプロセスに取り入れるべきだと考えています。
　ちなみに、セミナーの後の会話で「フレームワークの話を先にしてみては？」とお尋ねしたのですが、「ある方からプロセスの話が先のほうがいいと言われた」とのことでした。さまざまな人に物事を伝える難しさを感じますね。

　セミナーの中で「制約を設計する」というような趣旨の話がありました。この発想はおもしろいと思います。通常、制約条件は回避するかなくすかのどちらかの選択ですが、利害関係者との交渉によって「積極的に制約を変化させる」というのは今後意識していきたいことです。

　セミナー終了後、神崎氏とスパークシステムズの河野氏、セミナーの参加者の方と私の4人で懇親会を行いました。RDRAやシステム開発、Enterprise Architectの話、システムには全く関係ない話も含めて、非常に楽しい時間を過ごせました。

　以上、簡単ですがセミナーの感想です。

　神崎さん、河野さん。ありがとうございました。

業務改善プロジェクト システム化構想立案～要件定義編

　もう14年も見ている我が社の業務だから、どこをどう直すべきかは理解している。しかし、組織のアクションとして実現するためには、私の考えを社に示さなくてはならない。そこで、今回はバリューチェーンを使ってみた。


バリューチェーン posted by (C)Satohru

　このバリューチェーン分析によって、各部門の業務の性質やIT成熟度などがとても説明しやすくなり、私の作り上げたアクションプランは社のアクションとして承認された。
　そして2011年4月、具体的に物事を考え始めた。


仕事場 posted by (C)Satohru

1. IT化のスコープはできる限りコンパクトにして、ユーザーと開発者の負担を軽くしよう。
2. 工程をいくつかのフェーズに分け、成果を確認しながら、成功（失敗）体験をユーザーと共に積み重ねながら進めて行こう。
3. 今までと違う手法を試してみたい。今回はドメイン駆動設計を軸にしよう。
4. ドキュメントはイントラネットに公開しよう。

　やるべきこと、やりたいことが湧き上がってくる。しかし、我が社が持つIT系人的リソースは私ひとり（3月までは部下がいたが、諸事情により退社した）。当然というべきか、計画どおり外部リソースを活用することになるのだが、問題はどう使うかだ。
 　SIerに丸投げする気など毛頭ない私は、派遣されてくるエンジニアと私の役割分担を考え、ドメイン駆動とユースケース駆動のツイン駆動だ！（？）、というアイデアにたどり着いた。こうすることで、要件定義手法RDRAの関係性の基づく網羅性の確保がより強固になると考えたのだ。


次期プロジェクトの要件定義手法 posted by (C)Satohru

 　このアイデアのもとSIerと協議し、結果としてふたりのSEと私の3人で今回のプロジェクトを開始することになった。
　
　6月。SIerのSEふたりは業務のフローに着目して分析を行い、業務フローからユースケースを導き出すことを最初のゴールと定めた。一方、私は業務の言葉やものに着目し、ドメインモデルとステートマシンモデルを作成した後、ステートマシンモデルのトリガーからユースケースを導き出した。

　プロジェクトを開始して2週間。私は重要なビジネスエンティティを発見した。これにより、業務のつながりがハッキリと見えるようになった。ドメイン駆動設計を意識したプロジェクトは今回が初めての経験だが、その有用性を十分に体感することができた。

　SEふたりの作業進捗はすばらしかった。モデリングはユースケースからロバストネスモデルの作成まで進み、その過程でラフなデータモデルもできあがっていた。また、私は最初の画面スケッチを手書きでノートに記していた。プロセスには拘らず、今考えるべきこと、今なすことが有効だと思われることをどんどんこなしていった。実に楽しいシステム開発である。

　それぞれが導き出したユースケースを突き合わせ、認識の違いや網羅性を確認していった。これがまた楽しく有用な作業となった。ドメイン駆動とユースケース駆動のツイン駆動。その有効性がこの作業で確認できた。ただし、プロジェクト特性を十分に考慮してこの手法は採用する必要がある。小規模でデータ集約型業務のシステム開発には、極めて有効なのではないだろうか。

　ひとまずユースケースが出そろったので、今後の計画作りのためにも、作ろうとしているシステムの規模を見積もることにし、ストーリーポイントによる規模見積もりを実施した。
　0、1、2、3、5、8、13の7枚のカードを3人が持ち、ユースケースに対する相対的な重みをカードを出すことによって示し合うのだ。意見が分かれたときには議論し、最終的にはチームの合意としてストーリーポイントを決める。
　これもまたエキサイティングな作業となった。この際の議論を通じ、ユースケースの突き合わせを行ったとき以上に、認識ギャップを埋めることに成功し、ユーザーにとって価値あることとは何かについて深く議論することができ、時には実装方法についても議論がおよんだ。

　規模の見積もりをすると、それに時間や単価という要素を加えて金額を見積もりたくなるのが人情である。サクッとSEが見積もったところ、32人月・4,000万円弱というような数字が出た。
　おいおい、ちょっと待ってくれ。仮に私ひとりでこのシステムを作るとして、32ヶ月もかかるわけがない。この意見にSEふたりも賛同してくれた。伝統的システム開発手法（請負契約によるウォーターフォール型開発など）は、知識の伝播を行う課程で相当の工数を消費する。そこでチームで議論し、このチームにPG2名を加えてアジャイルな開発をしようということになり、その後の私の再計画では5ヶ月・700万円くらいでリリースできるというシミュレーションがはじき出された。んーん、700万円かぁ。まだ高い…
　ということで、PGを外し、新たに採用する私の部下を加えた4人で開発していくプランを考えることとなった。

　そしてビジネス部門への最終提案。関係者を大会議室に集めて説明、質疑応答、議論と続いた。いい会だったと思う。ユーザーたちも主体的に業務のあり方を考えてくれている。

　このプロジェクトの最も大きな問題点は、直接的なユーザーである現場担当者と、間接的なユーザーとなるマネジメント層の関心事があまりにも違うということであり、私たち開発サイドの提案は、段階的にみんなの要求を実現していきましょうということである。

　業務においてどんな分析をするにしても、データがなければどうしようもない。マネジメント層が持つさまざまな関心事も、結局は現場担当者が作業することであり、それにはパワーシフトを起こさなければならない。
　今回提案したシステムは、いわば基礎工事である。基礎なくしてはどんな建物も建築することはできないのだから…　

　8月。プロジェクトは第2フェーズに入った。この続きはまた今度…

プロジェクトの進捗

　新プロジェクトの要件定義が始まって約１ヶ月が経ちました。今回のプロジェクトの開発手法は、開発チームを2班に分け、チームAは業務フローからユースケースを抽出し、チームBの私はドメイン分析からユースケースを抽出するというもので、双方の分析結果を突き合わせることでより豊かな分析を行おうという試みです。
　今のところ、この手法はうまくいっています。双方の気づきやアイデアを交換し合うことで、システム要件はユーザー満足度の高い方向に進んでいると考えています。来週にはこうして導き出されたシステム要件をユーザーレビューし、私たち開発チームの成果を確認したいと思います。

　私はドメイン分析を担当していますが、これまでのプロセスはざっとこんな感じです。
　①ドメインモデルの作成。
　②状態変化を伴うエンティティのステートマシンモデルの作成。
　③トリガーからユースケースの抽出。
　④状態変化を伴わないエンティティのCRUDからのユースケース抽出。
　⑤スケッチしたUIからのユースケース抽出。
　⑥UIスケッチにより、ユーザーにとって付加価値となる機能の発見と、この機能のドメインモデルへの組み込み。

　一方、チームAはAsIsとToBeの業務フローを作成し、ここからユースケースを抽出します。その後ロバストネスモデルを作成し、そのエンティティからデータモデルを作成しています。

明日から新プロジェクト！

　明日から新しいプロジェクトが始まります。今回は、ある業務のシステム要件定義を進
めつつ、全社的な情報アーキテクチャーを整理しようとするものです。私と外部のエンジ
ニア2名によって、まずは7月中に最初の成果を出すことを目標としています。
　この業務を行うにあたって、私はユースケース駆動とドメイン駆動の両面からアプロー
チするという手法を考えました。
　私は主に問題領域の「もの」に着目し、ドメインモデリングを中心に分析を進めます。
外部のエンジニア2名は、主に問題領域の「こと」に着目して業務モデリングやユースケ
ースの抽出を中心に分析を進めます。そして、「もの」から発見されたビジネスエンティ
ティやトリガーなどと、「こと」から発見された情報やユースケースなどの整合性をチェ
ックすることで、新しい業務を正しく設計し、システム要件定義の網羅性を担保しようと
するものです。
　もちろん、要件定義の基本となる方法論はRDRAに準じて行います。さて、どうなるでし
ょうね？　明日からが楽しみです。

仕事場

今日は震災で壊れたキャビネットのリプレース工事が行われ、ガンガン騒音が…
そんな中ドメイン分析をしておりました。


仕事場 posted by (C)Satohru

次期プロジェクトの要件定義手法

今度のプロジェクトでは、ひとつの問題領域を2チームで要件定義する予定。そして、チーム毎の作業を対照的に行うことで、成果の品質を高めるという目論見。

下図はサンプルです。


次期プロジェクトの要件定義手法 posted by (C)Satohru

要件定義手法のRDRA、ユースケース駆動開発手法のICONIXプロセスを組み合わせて、UMLをツールとして使用します。
モデリングツールはEnterprise Architect。9.0が間に合うといいけど…
ちなみに、上図はEnterprise Architect 9.0のベータ版で「手書き風」にしてみました。

ソフトウェアエンジニアリングとは…

概念の抽象度を洗練させること。
その抽象モデルの属性と振る舞いを正しく記述すること。
それらを体系化し、制御し、実益をもたらすこと。

簡単なソフトウェアを作ってみよう(2)

　前回は完成したソフトウェアをご覧いただきました（例外処理や永続化の実装を除く）ので、今回は設計図書をご覧ください。
　設計≒モデリングには、Enterprise Architect 8.0を使い、工程としては要件定義から、モデルとしてはRDRAに則りコンテキストモデルの作成から進めました（参考：ソフトウェアの開発プロセスについて）。
　今回のプロジェクトは、ソフトウェア開発の世界を知らない人のために、ソフトウェアが生まれるまでを見せようという目的ですので、実際には他のモデル（要求モデル、業務モデル、概念モデル、画面帳票モデル）も作成しましたが、その内、開発の核となるもの≒ICONIXプロセスの成果物を中心に紹介します。
　実際に動作しているソフトウェアを見ながら、下記2図を眺めてみてください。

　本図は、コンテキストモデル、ユースケースモデル、ユースケースシナリオ、ロバストネスモデル、画面モデル、クラスモデルから構成されています。

簡単なソフトウェアを作ってみよう(2) posted by (C)Satohru

　この図はシーケンスモデル。画面とオブジェクトとのやり取りを表しています。


簡単なソフトウェアを作ってみよう(3) posted by (C)Satohru



簡単なソフトウェアを作ってみよう(3)に続く…

簡単なソフトウェアを作ってみよう

会社の人達に少しでもソフトウェアに関する理解を深めてもらおうと、「簡単なソフトウェアを作ってみよう」と題して、分析、設計、開発、テスト、見積などを実物で紹介する活動を先週から始めました。
今日は実物を作ったので、お披露目です。



設計では3画面構成だったのですが、手を抜いて1画面にしました。


簡単なソフトウェアを作ってみよう(1) posted by (C)Satohru


簡単なソフトウェアを作ってみよう（２）に続く…

性質変換によるデスクワークの工場化(1)

　私の勤める会社は主に不動産賃貸業を営んでいますが、ある人にいわせると、「江戸時代からビジネスモデルが変わっていない業態」ということだそうです。この真意はともかくとして、そんな会社で情報システムを任されている私には、この業態が故の「当たり前のムダ」というものがたくさんあります。
 　例えば「鍵」。賃貸住宅のドアのキーです。お客様との契約前には内覧をしていただきますが、その為にはたくさんの鍵を管理し、社員がお客様に同行し、中を開けて説明し、他の部屋が見たいと言えば、では後日、と言って再び同じことを繰り返します。あるいは、契約書であるとか、預金口座自動振替依頼書であるとか、さまざまな「紙」が発生し、これをお客様との間でやり取りする過程で、封入コストや郵送コスト、管理・保管コストが発生します。
　このような例が、私がいうところの「当たり前のムダ」です。言い方を変えると、他の業態と比べると相対的にムダに見えるものということになります。例えば、ネット証券会社を考えてみてください。ほとんどのオペレーションが電子的に済み、さまざまなリソースを多くの顧客でシュアしている業態は、うらやましいほど効率的です。しかし、「当たり前のムダ」がある中でも、より効率的なオペレーションは築いていけるはずです。
　私は何とか「工場化」できないか？　と考えています。「IT化」ではなく「工場化」です。つまり、事務作業やデスクワークといわれる業務を、製造作業のような「性質」に変換できないか？　ということです。
　では、「製造作業」と「デスクワーク」の違いは何でしょうか？　これを考える前に、ビジネス（あるいは、仕事、業務、作業）の構造を考えてみましょう。

　上記の図を一旦ビジネスの構造とし、ビジネスルールと呼ぶことにしましょう。

1. トリガー（業務の引き金）　：　どんな業務でも、必ず開始されるきっかけがあります。それには「アイデアがひらめいた」とか、「仕事の依頼がきた」、「上司に指示された」、「期日がきた」などさまざまでしょう。
2. ロール（業務の実施者と役割）　：　業務は人によって行われます。誰が、どんな役割で業務を行うのか？　これがロールです。IT化された業務では、システムがロールとなることもあるでしょう（ロールがシステムだったとしても、その処理内容は人が管理していますので、最終的にはすべての業務が人によって行われているということになります）。
3. インプット（業務に必要なもの）　：　業務には何らかのインプットがあります。伝票や請求書、要件などです。また、業務の実施者の知識や経験、アイデアのような無形のものもあります。
4. プロセス（業務の手順）　：　何を、どう処理していくかという業務の手順がプロセスです。「請求書の内容を確認し、支払管理システムから支払依頼書を発行し、経理に提出する」というようなものです。
5. コントロール（業務の制御）　：　取り敢えず「制御」という日本語を充てていますが、管理、監督、統制など、Controlのいくつかの和訳に置き換えてもいいでしょう。プロセスには何らかのコントロールがあります。「上司の承認を受ける」とか「支払額は予算の範囲内」とか、「条件分岐」であったりします。
6. アウトプット（業務の成果）　：　プロセスによって生み出された成果となるものがアウトプットです。インプットと同様、アイデアなどの無形のものもあるでしょう。

 　ビジネスルールは、下図のように次のビジネスルールへと引き継がれるケースがあります。また、下図「ビジネスルール A」と「ビジネスルール B」をひとつのビジネスルールに集約することも可能ですから、ビジネスルールはネスト構造になっていると捉えられます。つまり、「粒度」があるということです。

　ビジネスルールを一定の定義に基づき理解した上で、製造作業とデスクワークとの違いを考えてみましょう。

　製造作業は、明確な役割分担のもと、品質レベルが明確な成果物を、定まられた手順に従って行い、かつ、生産量や技術レベルを物理的・定量的に捉えることができ、作業全般を通じて可視化されています。
　これに対しデスクワークの一部は、不明確な役割分担のもと、品質レベルが不明確な成果物を、試行錯誤の連続によって行い、かつ、成果物や業務遂行レベルを定性的に捉えることが多く、作業全般を通じて見えにくくなっています。
　上表のように、{ T,R,I,P,C,O }で比較してみましょう。

1. ロール　：　デスクワークでは責任と権限のバランスがとれていないケースがあります（責任だけは押しつけられるが、それを遂行するだけの権限がないなど）。
2. インプットとプロセス　：　例えば新規事業を企画する、というような業務を行う時、インプットやプロセスは試行錯誤の連続によって行われます。「市場調査をやってみたけれど有用な情報を得られなかったから、競合他社の分析をしてみよう」というようなケースです。そうした試行錯誤の連続は、スピードや効率の低下要因となります。
3. アウトプット　：　最も大きな違いがアウトプットです。製造作業のアウトプットには明確な品質レベルが測定可能な形で定義され、よって検証することができます。しかし、デスクワークのアウトプットの大部分はこの逆です。例えるなら、製造作業はX,Yの座標で弓を射る目標を定義しているのでズレを定量評価できますが、デスクワークは的のどこかに当たればいいというような曖昧な定義なので、定性的な評価しかできません。

　このようなデスクワークの各要素を製造作業の持つ性質に近づけることができれば、デスクワークの「工場化」を推進することが可能です。

　性質変換によるデスクワークの工場化、理屈はこれでいいのかもしれませんが、では実践ではどのようなアプローチをすればいいのでしょうか？　これから具体的に検証していきたいと思います。

ソフトウェアの開発プロセスについて

本コンテンツの趣旨としては、世の中の知恵を集めて自己の基礎を作り、後は状況に応じてカスタマイズしましょう、というようなことです。
先人の知恵として、富士通SDEM、共通フレーム2007、RDRA、ICONIXを取り入れています。

上流工程の研究グループを立ち上げました

　2010年2月24日、私を含む有志5人により、上流工程の研究グループを立ち上げました。
　第1回目は、2時間程度のフリーディスカッションにとどまりましたが、システム開発に対する想いや、今後の方向性は共有できたと思います。具体的な成果（中間的な物や、問題提起も含め）は、Satohru Noteでもレポートしていきたいと思います。
　次回は、UMLモデル駆動開発チャート（SDEM@富士通の開発ライフサイクル、要件定義手法のRDRA、開発手法のICONIXが合体したもの）を仮の開発パターンとして、さまざまな観点から幅広く議論を行い、より具体的な研究テーマの抽出を行いたいと思います。

要求関係モデル

　現在、来期の行動計画を策定中ですが、今年は要求の関係に着目して計画を練っています。
　今までは、私が社にとって必要だと考えた要求を、コスト削減や生産性向上などの一般的な価値として、定性的に、あるいは定量的に表現してきました。しかし、一般化された価値では、ステークホルダー間で共有がスムーズにいかない場面があり、計画の確定、予算の承認までに時間を要することがあったのです。
　そこで、今回はステークホルダーの１人ひとりに、具体的な価値を示すことを目的として、要求の関係を整理することにしました。

　まず、予算編成方針などから経営層の要求であるトップダウン要求を洗い出します。次に、私の要求をピックアップします。そして、下図のように、トップダウン要求を実現するのはボトムアップ要求である、という関係が成り立てば、ボトムアップ要求には妥当性があり、経営層にとっても価値ある要求である、という関係が成り立ちます。また、私はボトムアップ要求の出所を説明しやすくなり、経営層は理解しやすくなると考えられます。

　しかし、ボトムアップ要求がトップダウン要求に直接結びつかないことがあります。例えば、次のようなケースです。

1.  トップダウン要求：　経常利益を○○億円以上にする。 
2. ボトムアップ要求：　不用なPC等を廃棄処分する。

 　不用なPC等の廃棄は必要なことであり、そのための予算が必要ですが、このままではトップダウン要求に対する妥当性が説明できません（「当たり前」であるとか「常識」は、要求同士の関係を何も説明していません）。

　そこで、下図のように要求と要求を接続するためのブリッジ要求を見つける必要があります。これを見つけることができれば、それぞれの要求は次のように文章化できます。

1. トップダウン要求は、ブリッジ要求を内包し、ブリッジ要求はボトムアップ要求により実現される。
2. ボトムアップ要求は、ブリッジ要求を実現し、ブリッジ要求はトップダウン要求に含まれる（または、実現する）。

　先の例も、ブリッジ要求を加えることで関係を整理できます。

1. トップダウン要求：経常利益を○億円以上にする。
2. 【ブリッジ要求：コストを削減する。】
3. 【ブリッジ要求：無駄を排除する。】
4. ボトムアップ要求：不用なPC等を廃棄処分する。

 　このような手法により、情報システム部門として来期必要なすべての要求を整理したものが、下図になります。

　ブリッジ要求は、単に要求同士を橋渡しするだけでなく、管理層の要求に結びつくことが考えられます。したがって、要求関係モデルを作成することは、経営層、管理層、実務層のそれぞれに、全体整合のとれた価値を提供する可能性を高めます。もちろん、システム開発の要求分析にもこの手法は適用できます。

＊上図から一部を抜粋し、具体例を示します。

　黄色で示したボトムアップ要求は、ブリッジ要求として性質を合わせ持っているため、このような位置に表現しています。

　「サーバー更新」というのは、保守期間の終了により自然発生するボトムアップ要求です。しかし、トップダウン要求は「利益目標の達成に繋がる投資を積極的に検討すること」ですので、単純にリプレースするのではなく、そこに投資対効果を高めるためのアイデアが要求されます。そこで、「サーバー更新」とトップダウン要求のふたつに答えるために、「仮想化技術の導入による所有コストの削減計画」というブリッジ要求を加えています。

1. トップダウン要求「経常利益を○○億円以上にすること」は、トップダウン要求「利益目標の達成に繋がる投資を積極的に検討すること」を内包する。
2. ボトムアップ要求「サーバー更新」は、トップダウン要求「利益目標の達成に繋がる投資を積極的に検討すること」の検討要素である。
3. ブリッジ要求「仮想化技術の導入による所有コストの削減計画」は、上位要求を満たす要素である。
4. ボトムアップ要求「仮想化実験」は、ブリッジ要求「仮想化技術の導入による所有コストの削減計画」を実現するために必要なプロセスである。
5. ボトムアップ要求「次期ITインフラストラクチャー」は、上位要求を実現する。

手法の比較

＊言葉足らずと思い緑字部分を補足します。

　本投稿は、要件定義時における設計への踏み込み具合について、ふたつの手法を比較することで検討しています。従いまして、下記赤字の目的とは、要件定義を意味しています。

　簡単な業務モデルを基に、要件定義手法「RDRA」と分析設計手法「ICONIXプロセス」によるモデリングを比較してみました。

　RDRAは要件定義手法なので、設計や実装には原則触れません。ICONIXプロセスは分析から設計へのプロセスなので、下図の一部であるロバストネスモデルはその橋渡しとなる予備設計を行います。

　これらは性質が異なりますので、どちらが優るかという話ではなく、目的を達成するためにはどちらの手法がフィットするか（あるいはどうミックスするか）の問題です。

　プロジェクト特性やプロダクト特性、開発の局面により、特性を認識したうえで使いこなすことが重要です。

（ここから先は見積もりをも含めて）

　同じように、業務フローとユースケースシナリオ、ユースケースの粒度、ユースケースポイントかファンクションポイントかストーリーポイントか？　これらの内どれが優れているとか、唯一絶対の手法はどれかではなく、いかに効率的に、正確に、問題や解決の領域を表現し、コミュニケーションできるかの選択であると考えています。

　つまり、より多くの手法等を学び、適用の対象となる物事に合わせていいとこ取りできればよいと思うのです。

IT投資の意思決定に必要なこと

　IT投資の意思決定において、「どのような仕組みを作るか」という機能要件と並んで重要なことは、「いくらで、いつまでにできる」というコストと時間の見積です。場合によっては、見積が機能要件を超える意思決定要素になることもあります。

　無い袖は振れない、という言葉があるように、実際、どんなに素晴らしいIT投資案件でも、お金がなければ投資することはできません。逆に、少ないコストであれば、取り敢えず導入してみるか、という判断があり得ます。
　IT投資の意思決定をする実際の現場では、IT投資にかかる見積を早い段階で正確に知るということは、極めて重要なことなのです。

　見積の精度を向上させるためには、「今わかっていること」に「将来わかること」を加えなくてはなりません。例えば、システム開発のライフサイクルをウォーターフォールモデルとした場合、システムの構想段階で、次工程のシステム企画で明らかになることを知ることができれば、見積精度は確実に向上します。また、要件定義段階で、設計の要素を知ることもしかりです。極論すれば、システムをリリースしてから見積を行えば、すべてが今わかっていることになるわけですから、完璧な見積ができることになります。
　ということは、設計まで行ってから見積を行い、それを持って意思決定すればいい、という選択肢が考えられますが、意思決定するということは、投資を見合わせることもあるわけですから、見積までにかかったコストをどうするか、という問題が出てきます。

　この問題へのひとつの解として、共通フレーム2007などでは、システム開発の工程によって契約を分割することで、ユーザーと開発側のリスクをヘッジすることが推奨されています。なるほど、理にかなった手法です。しかし、ユーザー（組織）は、その理屈を知ったうえでも早く未来を約束することを開発側に求めてきます。現実問題として、いや、一般論ではなく、少なくとも私の所属している組織では、予算時にかなりの精度の見積を示す必要があります。なにしろトップが、「予算とは会社に対するコミットメントである」と宣言しているのですから、『アジャイルな見積もりと計画づくり』を共有するには相当な時間を必要とするでしょう。

　私は実務を行わなければなりません。また、個人としてどんなに異なる意見を持っていたとしても、組織として意思決定されたことには従わなければなりません。当たり前ですよね、民法上の使用人ですから。
　私は、予算という名の見積を会社にコミットメントすることを要求されているのです。そこで、IT投資かかる見積の精度を向上することは、私の重要な使命となります。

　では、どうするのか？

　これが現在の私の問題の中心です。そして特に、要件定義から生じる見積を高い精度にするためには、要件定義に「将来わかること」の何を加えればいいのか？（しかも効率的に…）　そんなところを試行錯誤しているのが現在連載中の『Open Knowledge System』です。
　RDRAベースの要件定義工程に、ICONIXプロセスを組み合わせることにより、予備設計という要素を加えることで、ユーザーが求める将来価値と現在価値のギャップを解消したい。上流工程に関わる開発者として、何としても成果を出したいという思いを実現するための「戦術を研究する」テーマです。

　予想される結論として、要件定義のアウトプットを改善しただけではこの問題は解決しないでしょう。『アジャイルな見積もりと計画づくり』や共通フレーム2007に紹介される思想を組織に広めることも必要です。そうしたさまざまなアプローチが、いつの日か、相互理解による価値の共有という理想へ辿り着かせるのだと思います。そして、その理想のひとつが、私が「流麗なシステム開発の上流工程」と称しているものです。これについては、来年から本格的に活動を開始する予定です。

Open Knowledge System(9)

　今回は、knowledgeをCRUDするユースケースシナリオをロバストネス分析します。

　Rは前回分析済みですので、残りのCUDに該当するユースケースとユースケースシナリオを下図のように配置しました。これは今回の作業をしやすいようにした状態ですので、ロバストネス分析が終わればロバストネスモデル以外は破棄します。なお、私は全体の関係を一望にしたいので、下図のようにひとつのモデルとして描いていきます。モデルを分割するかどうかはお好みでよいのでしょうが、要素の関係をトレースできることが失われないように注意が必要だと思います。
　＊言い方を変えると、私は「うっかり」が多いので、それを予防するためにも全体を見ながら作業します。今回の作業用モデルも、その一環です。
　
　下図中、灰色のダイアグラムは前回分析が終了したもの、薄いピンクが今回抽出したもの、赤字で示した「ユーザーを認証する」コントロールは、前回までは「トップページを表示する」コントロールでしたが、今回の分析により、管理者だけがknowledgeを削除できるという要件を再認識したので、修正しました。

　knowledgeを更新・削除するユースケースシナリオには、knowledgeを世代管理するための記述があります。このことは、世代管理のためのコントロールの出現を予感させますが、今回は「knowledgeを更新する」と「knowledgeを削除する」のふたつのコントロールに内包されているという解釈のもと、別のコントロールに分けることはしませんでした。knowledgeの世代管理に関するユースケースシナリオは他にもありますので、その分析時に世代管理の的確なモデル化ができると予想しています。

追記

　ひとつコントロールを見落としていたので追加しました。

　knowledge追加画面には、更新者などをデフォルト値としてセットしておいた方が良さそうです。そこで、「knowledge追加画面を表示する」コントロールを追加しました。

続く…

Open Knowledge System(8)

　今回は、「新着のknowledgeを新着リストに表示する」ユースケースとprecedesの関係にある「knowledgeを参照できる」ユースケースをロバストネス分析します。
　まず、「新着のknowledgeを新着リストに表示する」ユースケースのユースケースシナリオは、修正前は不要ですのでモデルから削除します。次に、「knowledgeを参照できる」ユースケースのユースケースシナリオをノートに表示させます。この辺の作業は、Enterprise Architectを使うととても効率的に行えます。

　これで準備完了です。

　ユースケースシナリオを読みながら、「knowledge参照画面」バウンダリ、「knowledgeを表示する」コントロールを抽出し、「knowledge」エンティティは前回抽出したものに関係線をつなぎます。

　＊灰色のクラスは前回抽出したもの。薄いピンクは今回抽出したもの。

　さて、問題はprecedesと表現した関係をどう分析するかです。まずは、青色で表示しているユースケースシナリオから「新着リストで選択されたknowledgeの識別子を渡す」コントロールを抽出し、上記図のように分析しました。んんぅ？　何かしっくりきませんね…

　ふたつのユースケースは本当にprecedesの関係なのでしょうか？

　precedesとinvokesの意味を今一度確認すると、ユースケースモデルにそもそもの間違いがあることに気づきました。そこで、下図のように修正しました。

　ユースケースがひとつ足りなかったのです。これにより、

1. 
   
    「新着のknowledgeを新着リストに表示する」ユースケースの後に、「新着リストのknowledgeを参照する」ユースケースがあり、
2. 
   
   「新着リストのknowledgeを参照する」ユースケースは、「knowledgeを参照できる」ユースケースを呼び出す。

　というすっきりとした関係になります。

　Open Knowledge Systemシリーズは入門講座ではありません。ですから今回の間違いは、実際に私が犯した間違いです。しかし、このように正しい手順でプロセスを重ねていけば、間違いを発見し修正できるのです。

　先人たちの知恵、素晴らしいですね。

続く…

　

Open Knowledge System(7)

　ユースケースシナリオを書き終えたところで、ユースケースシナリオのレビューと予備設計を同時に行えるロバストネス分析に入りたいと思います。
　今の考えとしては、ロバストネス分析によってシステム全体の関連性を確認してから、RDRAの画面帳票モデル、機能モデル、データモデルにバウンダリ、コントロール、エンティティを落とし込んではどうか？　と思っています。かなり冗長なイメージですが、実験プロジェクトですので、トライしてみます。また、RDRAの機能モデルとICONIXのコントロール、この違いも（教科書を読んだだけではなく）体験として捉えることができるかもしれません。ということで、作業に入りましょう。

　最初に選んだユースケースは、

　新着のknowledgeを新着リストに表示する

　そしてユースケースシナリオは、

1. システムは、トップページを表示する時に、現在の日付から7日前までに作成（更新）されたknowledgeを、作成（更新）された順番の新しいものから順番に表示する。
2. ユーザーは、トップページにアクセスした時に、新着リストを参照する。
3. ユーザーは、新着リストの項目を選び、該当するknowledgeを参照する。

　ICONIXプロセスの教えによれば、ユースケースシナリオがしっかりしていれば、バウンダリ、コントロール、エンティティの抽出は簡単に行えるはずです。試してみましょう。

　ユースケースシナリオを読みながら、順番にクラスを抽出していきます。

1. トップページ（バウンダリ）
2. トップページを表示する（コントロール）
3. おっと、ここでユースケースシナリオの不備が見つかりました。新しいものから順番に表示するものは何？　それは新着リストであることが読み取れません。ですから、 新しいものから順番に新着リストに表示する、とユースケースシナリオを修正します。これで新着リストを表示する（コントロール）を見つけることができました。
4. トップページを表示する（コントロール）は、具体的に何をするのかよく分かりませんが、新着リストを表示する（コントロール）は、ユースケースシナリオによって明らかになっています。これにより、knowledge（エンティティ）が発見され、新着リストを表示する（コントロール）と結びつきます。

　素晴らしですね。実にシステマティックです。

　ユースケースシナリオの最後に「…該当するknowledgeを参照する」が残っていますが、このシナリオには独立した「knowledgeを参照する」ユースケースが用意されていて、これとprecedesの関係であることがユースケースモデルによって明らかにされています。ですから、最後の参照部分はここでは扱いません。

　下の図は、この作業の一場面をキャプチャーしたものです。

　ご覧のように、ユースケースシナリオとそのオーナーであるユースケース、関係するユースケースを眺めながら、先のようにシナリオを読み進めれば、簡単にロバストネス分析は終了します。また、この作業を通じてユースケースシナリオのレビューを行うことができます。

　また必要により、図のように新旧のユースケースシナリオを並べておくと、ユーザー（要求者）とのコミュニケーションなどに役立つかもしれません。

続く…

Open Knowledge System(6)

　ユースケースシナリオができたので、ここでOpen Knowledge Systemの「規模」を見積もってみたいと思います。手法には、「アジャイルな見積りと計画づくり」に紹介されているストーリーポイントを使ってみます。

　私のやり方は、Enterprise Architectからユースケース名とユースケースシナリオを出力し、一つひとつのユースケースを下写真のようにカード化し、全体を眺めながらストーリーポイントを与えていきます。ストーリーポイントは相対評価ですので、これとこれはどっちが大きい？　というような比較の時、物理的なカードは非常に処理しやすいインターフェースです。個人的にも、このようなアナログ作業は好みです。

　19あるユースケースカードを、下写真のように1、2、3、5、8、10の各ポイントに割り振っていきます。

　この作業の結果は以下のとおりです。

　ユースケース（ストーリーポイント）

1. knowledgeが更新された時、更新前のknowledgeを世代管理する (5)
2. knowledgeを全文検索できる (3)
3. knowledgeを削除できる (2)
4. knowledgeを参照できる (2)
5. knowledgeを更新できる (3)
6. knowledgeを追加できる (3)
7. ブックマークを削除する (2)
8. ブックマークを追加する (3)
9. ブックマークリストを表示する (8)
10. ラベルでknowledgeを絞り込める (2)
11. ラベルを削除できる (2)
12. ラベルリストから複数のラベルを選択し、knowledgeに付けることができる (3)
13. ラベルリストを表示する (1)
14. 世代管理されたknowledgeを公開中のknowledgeと交換できる (10)
15. 人気のknowledgeを人気リストに表示する (5)
16. 任意のラベルをラベルリストに追加できる (2)
17. 新着のknowledgeを新着リストに表示する (2)
18. 誤って更新されたknowledgeを知ることができる (1)
19. 誤って更新してしまったknowledgeには誤修正フラグを付けられる (3)

　 ストーリーポイント合計：62

　現時点で、Open Knowledge Systemの規模は、62ストーリーポイントであることが分かりました。次は、規模から期間を導出することになりますが、それはまたの機会に行うことにします。

続く…

ユースケースを考える

　システム開発の上流工程の中で、要件開発からユーザーインターフェース設計への流れは、現実からシステムへの変換過程における「現実とシステムの変換点」と捉えることができます。また、要件開発に用いるユースケースは、「ユーザーとシステムとの接点」となります。ということは、ユースケース駆動開発という手法があるように、ユースケースはシステム開発における極めて重要な要素、システム開発の中心ともいうべき要素といえます。
　このような前提の基、私はユースケースを深める試行錯誤を行い、次のような整理をしました。

• まず、ユースケースの定義をRDRAの「人とシステムとの接点」とする。
• 次に、ICONIXプロセスを組み合わせ、ユースケースシナリオ、ロバストネス分析を行うことによって、ユースケースの粒度と質をそろえると同時に網羅性を検証する。＊これは、開発者の能力不足を補う意味もあります。

　ところが、あるプロジェクトで実践してみると、他のユースケースよりも粒度の大きなものがひとつだけ残りました。それは次のようなユースケースです。

　顧客の対応をする。

　これは、ユーザーが顧客の対応を行いながら、氏名などの基本となる顧客属性を入力したり、コミュニケーションの内容を記録したりする、複数の機能を必要とする作業です。粒度を他のユースケースとそろえることは簡単ですが、私はユーザーに示すユースケースとしては、この粒度の方が良いと考えました。

　それから数週間ほどの時間が経っていますが、この粒度の違いを正当化する論理を見いだせないでいました。しかし今朝、KenichiroMurata氏のブログ「UMLの参考書籍」を読んで、解決の糸口を見つけることができました。

　ユースケースは何を表すものか？　ユーザーがシステムから受けるサービスか？　それとも、ユーザーが使用する機能か？　そう考えた時、私は「ユースケースとはユーザーにとって魅力的なストーリーであるべきだ」と考えました。
　ユースケースは、ユーザー（要求者）と「何を作るか？」を決めるための重要なコミュニケーションツールであり、それはユーザーにとって魅力的であることが最も重要なはずです。なぜならば、これが実現すれば便利になる、楽になる、安くなる…　こうした魅力（価値）を感じなければ、ユーザーがシステム開発に参加する際のモチベーションが低下し、結果的に十分な問題領域の分析ができなくなってしまうリスクが高まるからです。

　さて、ここで疑問が生じます。であるならば、ユースケースを階層化すれば？

　なるほど、階層化すればボトムのユースケースの粒度は均一になります。しかし、私がユースケースを作る目的は、ユーザーにとって魅力的なシステムを実現するためであり、学術的であったり、規範に準拠することではありません。また、そもそも、ユースケースの粒度をそろえなければならない理由は何なのでしょうか？
　ユースケースポイントによりシステムの規模を見積もろうとするならば、粒度は一定である必要があります。しかし、ユースケースをストーリーとし、ストーリーポイントで相対的に規模を見積もるのであれば、粒度がそろう必要はないはずです。

　では、現時点での私の仮説を整理します。

• ユースケースとは、ユーザーにとって魅力的なシステムとの接点である。
• この段階での規模見積もりにストーリーポイントを採用するのであれば、ユースケースの粒度は無視できる。
• ユースケースシナリオとロバストネス分析は、要件開発段階ではユースケースを深めるための手段であり、プロジェクトやプロダクトの特性によりその使用を判断する。

　この仮説に従い、しばらく検証を続けたいと思います。