FoW!勉強会〜要求とか要件について一度みんなで語り合おうに出てきた。

前職時代にお世話になったStarlight & Stormの長谷川さんの企画で、

「FoW!勉強会〜要求とか要件について一度みんなで語り合おう」に出てきました。
これがとても面白かったです。さすが長谷川さんプロデュースです。本当に
こういう「役に立つ」ことを提供するセンスは本当に素晴らしいです。また
行きたいなぁ。内容は下記の通り

１．ライトニングトークス

• 要件定義開発方法論RDRAの神崎さん
• Starlight & Storm ,Springユーザ会の長谷川さん
• 私
• アークランプの鈴木雄介さん

２．Ｑ＆Ａ（パネルとお客様で）

というとっても豪華なメンバーの中に加えてもらってとても嬉しかったですし、
参加された方も、Ｍｒ．保守の方、Form Indiaの方や、それ以外の方々もとてもコアな
人々が参加されていて、単純に講演するというのではなくて、ＬＴと長谷川さんが事前
に、アンケートしてあつめたＱ＆Ａがこれがまた良かった。そういう話もちょっと書い
てみようと思います。　このFow!勉強会ですが、面白そうなので、私も登録しておきま
した。

→Fow!メーリングリストの申し込みページです。

神崎さんはもちろんRDRA（ラドラと読むらしい）のお話です。私は神崎さんの本を持って
いましたので、特に新しい話はありませんでしたが、RDRAはとてもいい要件定義方法論
だと思います。UMLを中心に、要求工学・ビジネスモデリングそしておそらく神崎さんが
現場でいろいろ苦労されて工夫されたものがおりこまれた、現場でできそうな内容です。
わたしもコンサルをする時には結構参考にしています。とても地に足がついた内容で
お気に入りです。

是非神崎さんの書籍をチェックしてくださいね

顧客の要求を確実に仕様にできる要件定義マニュアル

や リレーションシップ駆動要件分析のページ

次に長谷川さん

長谷川さんは方法論とかそういう観点ではなく、要件定義はサービス業という観点で
お話してくれました。いつも通りの長谷川さんらしい、「正直」トークはもちろん
健在で、鋭い視点と、ものの見方がとても興味深く「そうだよな〜」と思いました。
この話し方がまた、上手い！

最後に鈴木ゆうすけさん

　要求開発アライアンスとかでたまに話をしていましたが、いつもなんか自分が大切
にしていて、そうありたいということがあるのですが、そういうセンスを既に持っている
私よりきっと若いけど、私の憧れの人的なところもあります。

　今回も人間中心設計、ユーザ中心設計、エスノグラフィ等の話を交えて、誰から
要求を聞くか？という観点で、要求は「ユーザを観て観察する」という視点を紹介
してくれました。これはソフトウェア開発観点というよりも、ユーザビリティエンジ
ニアリングやデザイン系での知見を「見える化」してくれたものだと思います。
　これには、ちょっとやられた。さすがですね。雄介さんの主張は本人自らブログにＵＰ
してくれています。皆様も楽しんでくだされ。個人的にも、実はこの辺に興味があって
勉強したくなってきました。実際にやってみたい。

http://www.arclamp.jp/blog/archives/fow_requirement.html

私のお話は、要求開発の本質の話と、現場の制約がある中でどうやっていくのか？というお話を
してきました。要求開発は、ＩＴ化プロジェクト企画等の領域（ＲＦＰ前ぐらい）で使われる
部分での「要求の開発方法論」です。

要求開発~価値ある要求を導き出すプロセスとモデリング

私は結構ビジネスモデリング道場というところで記事かいたりしてました。

本質の話というのは、例えば、要求開発でも、他の方法でもなんでもいいのですが、
基本的に「要求工学」や「ビジネスモデリング」と言うものは、見た目は結構ちがっていても、
「本質的」には似たような事をしているので、自分の好きなのや、自分の状況で使いやすい
やつをつかってくださいという話です。

とってもざっくりうと、業務のモデル化と言う観点では、

• プロセス（ex. 業務フロー)
• 概念 (ex. 概念クラス図）
• サービス（ex. ビジネスユースケース図)
• ゴール (ex. ゴール記述書)

という感じで、いろんなツールが存在しています。ここにあげた以外のものも沢山あります。

そして、要求の抽出と言う観点では、

• トップダウン分析（上位の目的から、要求を抽出）
• ボトムアップ分析（現場の課題から、要求を抽出）

　　＃そして、それらを目的ー手段の観点で構造化する
　　　　　　（ex. 要求分析ツリー、BSC戦略マップ）

• 分析しなくてもある要求　

　　　　　　（ex.こんなシステムをつくるなら、こんな機能いれてや！）

• プロセスモデルからの要求

（業務フローの中でシステムの使用箇所を特定すると、そこに何らかの機能がある）

• モデルを参考にしたゆさぶり

（概念クラス図や、目的ー手段の構造化してものやCRUD的なものから、
　本当にこの要求でいいか、漏れは無いか？の検証をする）

そして、そいつを優先順位付けするという感じです。大体方法論はちがっても似たような事を
やっていますね。という話。

あとは、制約がいろいろ多くて、お客様にあまり聞けない状況で
どのようにこれらのスキルを役立てるか？という話をしました。

例えば、上から下まで、こってこてに、要求開発プロセスを適用
できなくても、例えば、業務やシステムの鳥瞰図的なものを作って
共有するとか、わかっているレベルで要求を構造化すると言ったこと
をすると、それだけでも、プロジェクトに参加しているメンバーの
業務知識の習得スピードがアップしたり、要求の問題点に気づきやすく
なったりもします。

なによりも、それを指差して、話ができるようになりますね。

　とっても当たり前ですが、私の言いたかったことというのは、
「こうだからできない」という思考を「こうやったらできる」
「ここだったらつかって役立てられる」とかにちょっと変えて
あげるだけで現場で得したり、楽しくしたりできました。

という事をお伝えしたかったのでした。

　その後の、Ｑ＆Ａも、「非機能要件ってどうしてるの？」とか
「保守開発、派生開発ってどうするの？」「見積もりはどうするの」
と本ではあまり書いてないけど、現場は違うよね！という３大要素。

パネラの皆さんもお客様もとても活発な話をしていて本当に面白かった
です。今度は羽生田さんにも来てほしいなぁ。

　特に今の世の中は「全くの新規システム」は特にビジネス系だと
少ないと思うので、清水さんという方も本を出しているとおり、
「保守開発」「派生開発」とか、要求のリバース（既存システムしか、
システムの要求を知らないというパターン）がこれから注目される
かもしれませんね。私も現場派なので、このへんも深堀していきたい
と思っています。

　そういった開発の場合、本に書いてあるようなスムーズな要求開発
なんてありえなくて、お客様からヒアリングがほとんどできない、とか
そいういう「制約事項」があるのが実は「当たり前」になっていると思う
ので、現場ではそういうノウハウが必要と感じています。みんなきっと
いろいろ工夫していると思うのですが、そういうのを見える化したいですね。

長くなりましたが、、お付き合いありがとうございました。