要求開発宣言
![]() |
||||
|
私たちは、企業でのITシステム開発を通じて、「要求」に関して以下のことを学んだ。
|
||||
| ■ | ||||
| ■ | 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。 |
|||
| ■ | 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。 |
|||
| ■ | ||||
| ■ | ||||
| ■ | 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。 |
|||
私たちはこれらの気づきから、「要求開発」という新しい知的活動分野を創造し、それをみずから実践していく。その過程で獲得したナレッジをOpenthology(オープンソロジー)として体系化し、かつ、クリエイティブコモンズの下に公開・共有することで、同様の課題を持っている人々と、コミュニティ活動を通じて分かち合うことを決意する。 |
||||
2004年12月23日 すずかけ台にて |
||||
| JUNZO |
TOMOO YODA |
||||
| MASAO YASUI |
ISAO NODA |
||||
| KENJI HIRANABE |
ZENJI KANZAKI |
||||
| KOUJI YAMAGISHI |
EIICHI HANYUUDA |
||||
| TUTOMU HOSOKAWA |
HIDEAKI TAKEI |
||||
| HIROHIDE YAZAKI |
|||||
![]() |
|||||
要求開発宣言の解説
- 情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
- 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
- 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
- ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
- 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
- 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
−「要求開発宣言」
これが、要求開発宣言の中心文である。情報システム開発を行なう場合に、その入力となる「要求」を私たちはどのように扱っているのだろうか。要求定義、要求収集、要求整理、などの言葉が使われるが、これらの用語はあたかも、要求というものがそこに存在しているような錯覚を与える。要求は「定義されたり、集められたり、整理されるのを待っている」ものではなく、私たちが意識的な活動を通じて「創り出す」ものである。この要求を創り出す活動を「要求開発」と呼ぼう。システム開発が「要求」を入力して「情報システム」を出力するものであるならば、要求開発とは「ビジネス価値」を入力して「要求」を出力する創造的活動である。このように要求を開発するものであると捉えることによって、要求が本来持っている難しさを想起させると同時に、私たちが経験してきた「システム開発」におけるアナロジーが援用できる、というメリットもある。そう、要求は私たちが「開発する」ものなのだ。ビジネス価値に基づいた正しい要求を開発しない限り、下流であるシステム開発は正しくないものを正しく作る無為な行為となってしまう。
−「情報システムと業務活動との相互作用」
情報システムは、ビジネス価値向上の一手段であり、それそのものが単体で価値を持つわけではない。情報システムのデザインは、業務プロセスという上位のデザインの一部であり、そこでは、人間の業務活動と情報システムが相互作用をすることによってはじめてビジネス価値の向上をもたらす。情報システムのみに関心を向けることは、まったくの局所最適であり、手段を目的化する間違いだと認識しよう。そして、デザインされた業務プロセスが果たすべきビジネス価値に、私たちの目を向けようではないか。
−「追跡可能性による説明可能性」
なぜ、この情報システムに投資するのか。この問いに答えるためには、システムに対する要求がいったいどこから出てきたのか、を常に明確にしておく必要がある。このシステムはどのようなビジネス価値に結びつくのか。また、それを実現する手段は何なのか。この目的・手段の構造は目的(WHY)方向の末端をビジネス価値とし、手段(HOW)方向の末端を情報システム(もしくはそれに対する要求)とするツーリー構造をなす。この目的・手段連鎖が追跡可能(traceable)でなければ、間違った問題に答えようとしているのかもしれない、あるいは、目的を果たすために別の手段の方がよりコストが低く効果が高いかもしれない、という不安から逃れることはできない。さらに、ステークホルダーに対する説明責任も果たせない。私たちはなぜこの情報システムを作るのか。この問いに答えよう。
−「ステークホルダーの合意形成」
要求開発は個人に閉じた活動ではない。その情報システムが実現する業務プロセスの価値に関わるステークホルダーの「合意」こそが、要求の開発プロセスとして重要なのだ。ここでのステークホルダーに、情報システムユーザー企業の経営者、エンドユーザ、情報システム部門、ビジネス部門、さらに、情報システムベンダーも含まれている。異種ステークホルダーの合意形成が、困難であることは言うまでもない。しかし、だからこそ、そのプロセスを定義し、継続的に進めることが重要なのではないか。
−「継続的改善プロセス」
要求開発が複数のステークホルダー間の合意形成であることから、そのプロセスは一方向の命令統制ではなく、参加協調が必要であろう。さらに、その合意は複数フェーズにまたがる多段階コミットとなる。このプロセスは、継続的改善やPDCA(Plan-Do-Check-Action)ループと相似形をなすものであり、徐々にゆるやかに合意をブートストラップしていくものである。これは、要求開発がブレークダウン型の情報流では作り出せないこと、そして、よりコミュニケーション重視の創発的な活動が重要であることを示している。
−「モデルと可視化」
私たちは、情報システムの開発を長く経験してきた。そして、要求開発にシステム開発のアナロジーを当てはめることができると考えている。おりしも、オブジェクト指向開発方法論およびUMLが情報システム開発の標準となり、そのモデリング手法の体系ができあがりつつある。これを援用することで、ビジネスそのものをもモデル化、可視化できると考えている。そして、要求開発においても、「見える」ということを第一義に重要としている。見えなければ合意形成はできない。見えなければ目的と手段は追跡できない。見えなければ説明できない。見えなければ継続的改善はできないのである。私たちは、要求開発の出発点を、このモデル化と可視化に置く。
宣言メンバー
| 名前 | 趣意表明 | 写真 |
| 安井 昌男 | 旧来より、要求開発が対象とする分野は、多くの人にその価値や困難さを認められるに至っていなかったように思います。それは作業内容や成果物が属人的て曖昧であった為ではないでしょうか。この曖昧さや属人性を排除した明快なレファレンスをOpenthologyによって提供することで、誰もがビジネスのメカニズムを明示する術を手にすることになります。これにより要求開発の重要性や困難さに多くの人々が気がつき、そして、「Openthologyで、明日をかえよう」と考えるようになる・・・と、いいなぁ。 ■主な著書 「仕事のとれるSE-設計力、技術力、推進力でSEは決まる」 |
![]() |
| 野田 伊佐夫 | 実現したいビジネスから、人と情報システムのあるべき姿をデザインする。キャンバスに向かい絵の具と筆を揃え、技法を学ぶことで描きたい絵に一歩近づく。要求開発方法論はビジネスモデリングを実践する人々にとって「役立つ道具」、「価値あるガイド」となって欲しい。 ■主な著書 「仕事のとれるSE-設計力、技術力、推進力でSEは決まる」 |
![]() |
| 平鍋 健児 (永和システムマネジメント) |
情報システムの開発者はいつも、よい品質のシステムを開発したい、役に立つシステムを作って顧客に喜ばれたい(共に喜び合いたい)と切に願っている。 そして、その前提条件として、「よい品質」や「役にたつ」とは何かを合意しなければならない。すなわち、「ビジネス価値に結びつく要求を開発する手法が存在しなければならない」、と、私は強く思う。 ■主な著書 「リーンソフトウェア開発」 |
![]() |
| 山岸 耕二 (豆蔵) |
ビジネスは、人間系のこてこてした世界で、混沌の中で臨機応変に対応など、定型化は極めて困難である。しかし、一見無秩序な中に普遍的な構造やメカニズムを見出し、その一部をCPUでサイボーグ化する活動によって、業務はハイパー業務へと変身を遂げる。人間系とIT系のトータルコーディネーションによって、ビジネスパフォーマンスを最大に高める手法をいち早く構築し、世界に発信していきたい。 | ![]() |
| 鈴村幸太郎 (日本総合研究所) |
「苦労して開発したシステムが使われない」といった悲惨な結果を招かないために、要求開発の必要性をひしひしと感じている。システムを使う人の「想い」が伝わり、出来上がった情報システムがビジネス価値を向上させるような秘訣を要求開発の中で考えていきたいと思っている。 | |
| 依田 智夫 (シナジー研究所) |
私が実現したいことは、俊敏なビジネスをささえるために、情報システムの開発リードタイムを圧倒的に短縮することです。そのためのキーは、二つ。一つは、もちろんソフトウェア開発の生産性ですが、もう一つは、要求仕様の品質です。優れた要求仕様なくしては、どんなに高い生産性も意味がありません。幸いにして生産性の方はモデリング技術の発展によって明るい展望が見えてきました。あとは要求仕様です。ReDAのすばらしいメンバーとともにこの分野に実績を作っていければ最高にハッピーです。 ■主な共訳書 「UMLによるJavaオブジェクト設計」 「実践UML」 |
![]() |
| 羽生田 栄一 (豆蔵) |
いま日本も世界も大きな曲がり角に来ているように思います。そんな時代に生きていることを幸運だと思うようにしています。ソフトウェアを用いて産業界を活性化することに少しでも貢献したい、そして日本を元気にしたい、ゆくゆくは世界をリードしていきたい。そのためには、「本当にやるべきこと」をみんなで作り出していくことが必要だと痛切に感じます。要求開発はその最初のしかし大きな第1歩です。 ■主な著書 「ソフトウェアの匠」 「ビジネスプロセスモデリング」 ■主な訳書 「UMLモデリングのエッセンス第2版」 「UMLによるビジネスモデリング」 |
|
| 細川 努 (日本総合研究所) |
「情報システムへの無駄な投資を抑えながら、企業の競争力・優位性を真に向上させる方法論としてOpenthologyを日本企業共通の財産として成長させたい」そんな想いでこの活動に参加しております。 | |
| 武井 英明 | 要求開発工程における、無理・無駄を極力排除し、誰にでも実践できる要求開発方法論を体系化したい。従来、要求開発担当者(コンサルタントなど)の能力によってばらつきの大きかった要求仕様策定の品質を高めていくことで、ビジネスへの貢献機会を拡大していきたい。 ■主な著書 「仕事のとれるSE-設計力、技術力、推進力でSEは決まる」 |
|
| 神崎 善司 (豆蔵) |
ソフトウェア開発の世界に身を投じて早二十数年。摩訶不思議な秘術としてのソフトウェア開発から論理的で実践的なソフトウェア開発に進化するなか、最大の難関「要求」に果敢に立ち向かう人々の一員としていられることに喜びを感じられる。そんな技術者でありたい。 | ![]() |
| Yukihiro.F | これまでの情報システムは、システム開発部分にスポットが当たり、情報システム開発の前提となる要求は正しいものとして扱われてきたと思います。 しかし、企業のビジネス環境が激変し、ビジネスの状況により求められるビジネス効果が変遷して行く中で、正しい要求を把握する事が困難となり、情報システムにより当初想定したビジネス効果を得る事が段々難しくなって来ています。 Openthologyによって、ユーザ企業・ベンダーが共通の認識に立ち、ビジネス効果を生み出す正しい要求を把握・システムを実現した上で、ビジネス効果を共に享受出来る様な環境を生み出す事が出来ればと願っています。 |
|
| 矢崎 博英 (豆蔵) |
雨にも負けず、風にも負けず 言われたとおりに要求を記述するだけの御用聞き要求記述者ではなく、顧客のユニーク差を無視して流行のソリューションをどこにでも同じように適用する人になるのでもなく、顧客のビジネスをよく見聞きし分かり、そして真の課題を発見する姿勢でいることを忘れず、顧客のビジネスの利益に確実に貢献する情報システムの要求を顧客と共に開発する、そういう要求開発者に私はなりたい。 |
|
| 萩本 順三 (豆蔵) |
企業ビジネスもコンピュータシステムも人が理解しないかぎりコントロールできません。ビジネスとコンピュータシステムの姿を、理解しやすい構造としてモデル化しコントロール可能にしたい。私はこの会に参加している方たちの高い志に支えられ、企業価値を高める真のシステム作りのための手法について、みんなで創造し育み業界に貢献できることに、誇りと喜びを感じています。 ■主な著書 「初歩のUMLモデリング」 |
![]() |









