要求開発アライアンス西日本勉強会#16に参加。

時間があったので、急遽飛び入り参加してきた。

萩本さん直々の「要求開発超入門」を受講。

それまで自分考えていた「要求開発」が、非常に浅い部分しか理解できていないことが分かった。

---

■発想の出発点

• 「管理者」「担当者」「開発者」の３者が相互に協力できていない
• 「開発者」が「管理者」または「担当者」のいいなりになっている
• 上流工程と下流工程が分断。その結果、要求と実装の乖離が発生する

■要求開発の提案

• 「管理者」「担当者」「開発者」の３者を１箇所に集め（＝コタツモデル）、当事者意識を持たせる
• 期間、コスト、実現可能性を考慮し、「真に必要な要求」のみに絞込む
• 上流工程と下流工程を分断せず、上流／下流を行き来する。要求から手段を決め、手段から要求を満たす策を考える

「価値」は、「戦略」と「選択」の上にある。

---

こんなたった数行の文章ですべてを語ることは困難であるが、僕は理解できるので問題無し。

ちなみに、要求開発アライアンスのサイトに「要求開発バージョン0.6」の資料があるが、これを読んでもきっと理解できない。それほど情報が抜け落ちている。

書籍も出版されていて、こちらは「バージョン1.0」との事。

---

聞いていて強く感じたのは、「開発者が（管理者、担当者の）御用聞きになってはいけない」という事である。

■お客さんの視点
ITに関する知識が少ない。だから、開発者からの提案を期待する。

■開発者の視点
業務知識が少ない。だから、お客さんからの注文を期待する。

お客さんが仕様書を書いて、その通りにシステムを開発しても、良いものになる確率は低い。
逆に、開発者が業務知識を持たず、仕様書を書いても、使いにくいものになるだけだ。
だから、ステークスホルダー全員でコタツに入って認識をあわせ、仕様を作成して行く、というストーリーであると理解した。

上流工程において、上記の話を良く耳にするが、面白いのは「上流と下流を分断しない」点。

よくある失敗パターンは、要求が決まった後、システム開発を始めると実現困難な課題にぶつかる場合である。これを回避すべく、要求定義時に「ざっくり」（≠ガッツリ）実現方式を調べるのである。そして、実現困難であれば、要求を見直すのである。

更に、新しい手段を使って、要求やシステムの価値をアップさせることが可能であれば、その案を要求に盛り込むのである。

これを、「管理者」「担当者」「開発者」の３者が当事者意識を持ち、同じ視点で要求を考えるのである。

大事なのは、「開発者」がイニシアチブを取ること。
近い将来、「プログラムレス開発」が可能になる日が来るだろう。その時、開発者の付加価値はお客様が「欲しい！」と思うシステムの要求を定義できるスキルが求められるはずである。

「開発スキル」の向上も大切ではあるが、「お客様が欲しいと思うシステムを提案するスキル」のニーズは、今後ますます増えるだろう。

---

そして、最も興味深かったのが、「要求を変化させないぐらい、しっかり定義する」という考え。

１つは「期間」の問題。
市場で変

１つは「戦略」の問題。
アジャイル開発では、「変化を抱擁セヨ」という言葉があるくらい、変化を前提としたシステム設計／開発がなされている。しかし、「戦略」を練り、「要求」を絞り込むことで、開発途中に変化