１月はサボりましたので、２ヶ月ぶりの開催です。20名もの多数にお集まりいただきました。ありがとうございます。今回のテーマは「要求開発と三要素分析法で要件定義」でした。日本発の手法ですのでもっと広まって欲しいです。実はこの勉強宴会と共通の「目的」があることを初めて知りました。本文で書きます。
２次会は１２名＋2次会から参加１名。３次会は７名＋３次会から参加１名(笑)でいつもどおり延々とシステムについて議論しました。お開きは２：３０ごろでした。
＜今回の勉強会資料＞
Kansai-IT-Benkyo-Enkai_20130222_sano.pdf
Kansai-IT-Benkyo-Enkai_20130222_yamamoto.pdf
※発表で使われた小ネタ入りのバージョンとは多少違います(笑)
＜動画＞
業界標準プロセスと、なんちゃってＤＯＡ（１４分）
http://youtu.be/TLMVbd7tkO0
要求開発と三要素分析法で要件定義（９４分）
http://youtu.be/1jJWKPW0tNU
＜業界標準プロセスと、なんちゃってＤＯＡ＞
セールスフォース・ドットコム 佐野初夫要求開発の発表を山本さんにお願いしたとき、そもそも「要求定義って何かをご存じない方が多いかも知れない」と思いました。良い機会ですので、30分だけお時間を頂いて、ウォーターフォールの標準的なプロセスを整理してお伝えします。
本日の結論は「適当でもいいからデータモデルを書こう」というものです(笑)
共通フレーム2007は多くのＳＩｅｒやユーザが集まって制定しIPAが発行した日本の標準です。2007年ということは6年も変わっていません。つまりあまり使われていないということですが、今でもお客様が発行するRFP（提案依頼書）にはこの共通フレームの用語が使われていたりしますので、知っておくべきです。
共通フレームをご存知の方はどのくらいいらっしゃいますか？・・・約半数ですね。顔ぶれをみると年齢層が高いというか経営層やマネージメントの方のようです。まず上から見ていくと企画プロセス、要件定義プロセス、開発プロセスとあり最後が運用プロセスです。上流工程はどの部分になるのでしょう？企画＋要件定義のプロセスでしょうか？
良く見ると、「要件」という言葉が３種類使われています。要件定義プロセスはわかりますが、残り２つ、システム要件定義とソフトウェア要件定義はわかりにくいです。前者はシステムに必要な機能などを定義するのでしょう。後者は共通フレームの説明を読むと「利用者の視点から、ソフトウエアに必要な機能や能力、インタフェースを決定する」となっています。どうやらここは、私たちの用語でいう機能要件・非機能要件を決めるフェーズのようです。非機能要件というのは業務以外の要件、例えば何秒以内のレスポンスだとか障害復旧目標時間などです。
一般的な開発プロセスとマッピングするとこうなります。つまり上流工程は、要件定義プロセスの途中から開発プロセスの中のソフトウェア方式設計までです。要求定義と要件定義の間にはRFP（提案依頼書）があります。RFPを境にして業務主体の整理から、システム主体に変わります。「業務軸からシステム軸への変換」こそが上流工程のキモです。
そしてそのためには「なんちゃってＤＯＡ」が役に立ちます。例としてノンプログラミングツールであるＷａｇｂｙのページで販売管理を説明する図を見てください。
http://wagby.com/apps/sales/lesson.html
売上伝票複数枚で見積伝票が出来上がり、１つの見積伝票には複数の販売商品が入り１つの得意先があるということがわかります。
昔、トラブル案件に呼ばれて調べると100%データモデルがありませんでした。データモデルもなくてプログラムを作ればまともなシステムが出来るわけありません。どうやってテーブルを確定しているかを聞くと、プログラマーから必要といわれてから追加していました。
なんちゃってＤＯＡには２つの効果があります。まず納品物として指定することで設計能力のないＳＥを排除できます。もう一つは見積に前提として記述することで、開発範囲が青天井にならずにすみます。そういう効果もありますので、適当でもいいからデータモデルを書いてみてください。
＜要求開発と三要素分析法で要件定義＞
株式会社ウイズ 山本 幸伸さん「要求はあうものではなく、開発するものである」という考えから、要求開発アライアンスという組織で発展してきました。大阪でもほぼ毎月、匠の萩本さんがこられて勉強会をされています。そこに何度も参加し、実践してきましたのでその内容を発表します。
要求開発は実はこの勉強宴会と同じ目的もあるそうです。ＳＥや技術者が開発だけでなく企業戦略などの超上流にタッチ出来るように教育するという目的です。怪しげなコンサルなどが暗躍したトラブル案件を減らすためには作る技術のある方が出来るだけ早い段階で入ることが重要だという問題意識です。
先ほどの佐野さんの説明のとおり、要求開発は、要求開発フェーズですのでＲＦＰの前です。ただ、そういうフェーズにＳＥが参加させてもらえることは難しいので、今回はＲＦＰの後である要件定義フェーズで使ってみた報告になります。
まず「要求開発」の説明で私の心に刺さったものをお話します。
１．要求開発の理論
（１）既存システムの６割はほとんど使われていません理由は、「正しくないものを正しく作っている」からです。
（２）要求開発四象限
ビジネス戦略という「価値(what)」を実現するためにビジネスオペレーションという「実現方法(how)」があります。ビジネスオペレーションをwhatと見ると、それを実現するためにシステム要求(how)があります。システム要求を実現するためにシステム設計があるという連鎖になります。
目的と手段の連鎖の例を示します。（資料を見てください）
（３）コタツモデル
要求定義には、「オーナー」と「開発担当者」と「業務担当者」が必要です。それぞれが自分の立場で発言している限りばらばらな成果物になります。３者がコタツに入って相手の立場を考えながら作ることが重要です。
（４）要求のロジカルな落とし込みと構造的階層化
要望：ユーザからのリクエスト。実現可能かなど不明
要求：関係者が合意したあるべき姿
要件：予算・スケジュール・可能性まで検討してシステムを定義したもの
２．実践例
（１）プロジェクトゴール記述書フォーマットとしてタイトルに難しい言葉をつかっていないので大変わかりやすいです。
【何をする事で、何が、いつまでに、どうなる、評価尺度、目標値】
ユーザさんとも一緒に決めることが出来ました。特に評価尺度と目標をこのタイミングで決めるため、定量的な会話が出来ます。
（２）要求分析ツリー
階層を３段階に固定しているので使いやすい。
【業務要求、ユーザ要求、システム要求】
（３）ビジネスステークホルダリスト
言葉は難しいですが、今回のシステムの登場人物一覧です。意思決定するとか関与するとかは関係なく何をする人かと人数を書きます。
（４）業務フロー
ここからの３つは三要素分析法のフォーマットを流用することで大変効果的に整理することが出来ました。業務フローは「どんなきっかけでそのフローが発生するか」が描けることが有用でした。
（５）ＥＲ図
一般的な表現ではなく、渡辺幸三さんの表現が大変役に立ちました。というのはユーザさんはEXCELを使いこなしている方が多いので、項目を横に書くと理解しやすいようなのです。もちろん実際の値が何件でも書けることも重要でした。
（６）アクションツリー図
どんなときにどういう分岐の判断をして何をするかという業務フローを整理した形です。
３．まとめ
・効果：GOALを共有して進めるため、要求の爆発を防ぐことが出来ました
・エンドユーザにはUMLより三要素分析法の図法が圧倒的にノレルようでした
＜所感＞
渡辺式のER図は私も大変好きで利用させていただいています。でもEXCELと近いからお客様にわかりやすいという視点はありませんでしたので参考になりました。
要求開発が若いＳＥさんが超上流にタッチする支援という目的があるとは知りませんでした。それなら我々と目的は同じですから合同勉強会を企画しようかと思いました。
以上