Comments
Description
Transcript
ソフトウェア開発における システム要求仕様書の書き方
ソフトウェア開発における システム要求仕様書の書き方 [email protected] http://www.metabolics.co.jp/mmw/ 2006.10.26 1 I. 要求仕様書とは II. 要求仕様のプロセス III. 要求仕様書の書き方 IV. 実際にConOpsを書いてみる V. 実際にSRSを書いてみる 2 I. 要求仕様書とは 3 なぜ要求仕様書を書くのか • • • 顧客 • 我々は「何が」欲しいのか 開発者 • 我々は「何を」提供すればいいのか 何を • • • • • • • 機能 性能 品質 期限/費用の目安 導入/移行の目安 運用の目安 保守の目安 4 要求仕様書の位置付け • • SLCP (Software Life-Cycle Process) ISO/IEC 12207 共通フレーム98 (SLCP-JCF98) • • CMM/CMMI 5 基本プロセス群 企画 プロセス 調達プロセス群 開発 プロセス 運用 プロセス 取得 プロセス 保守 プロセス 供給 プロセス 共通プロセス群 プロジェクト管理 プロセス 環境構築 プロセス 作業支援 プロセス SLCP 6 業務機能の開発 開発プロセス 運用機能の開発 移行機能の開発 開発工程 外部仕様 概要定義 詳細定義 内部仕様 設計 プログラム 設計 製造 プログラム 作成 製品のテスト 結合 テスト 総合 テスト 設置 導入 開発プロセス 7 目的および目標の設定 現状の調査 処理要求の定義 データ要求の定義 システム化個別計画書 インタフェースの定義 要求品質の確認 業務組織形態の確認 システム概要定義書 ConOps システム概要定義書の 作成 成果物の評価 概要定義 8 業務運用の定義 要求品質の決定 機能仕様の定義 システム処理方式の定義 システム概要定義書 ConOps インタフェースの定義 データ構造の定義 SRS ソフトウェア要求仕様書 テスト仕様書 システム要求仕様書の 作成 テスト仕様書の作成 成果物の評価 詳細定義 9 運用機能の 概要定義 業務機能の 概要定義 業務機能の 詳細定義 業務機能の 設計 システム化個別計画書 運用機能の 運用要求定義書 運用定義書 システム概要定義書 詳細定義 テスト仕様書 移行機能の 概要定義 移行要求定義書 移行機能の 詳細定義 システム移行定義書 品質管理計画の 立案 品質管理計画書 ソフトウェア要求仕様書 システム設計書 プログラム外部仕様書 他の作業との関係 10 レベル5 - 最適化されている レベル4 - 定量的に管理されている レベル3 - 定義されている - 要件開発 レベル2 - 管理されている - 要件定義 レベル1 - 初期 CMMIの段階型表現モデル 11 レベル5 レベル4 レベル3 プロジェクト管理 エンジニアリング 定量的プロジェクト管理 統合プロジェクト管理 リスク管理 統合チーム編成 統合供給者管理 プロジェクト計画策定 レベル2 プロジェクトの監視と制御 供給者合意管理 レベル1 要件開発 技術開発 検証 妥当性確認 成果物統合 要件管理 支援 原因の分析と解決 統合のための組織環境 決定分析と解決 プロセス管理 組織の改革と展開 組織プロセス実績 組織プロセス定義 組織プロセス重視 組織トレーニング 構成管理 測定と分析 プロセスと成果物の品質保証 プロセス領域 12 成熟度 プロセス領域1 プロセス領域... 固有ゴール 固有 プラクティス プロセス領域n 共通ゴール 実施の コミットメント 実施能力 履行指導 履行検証 共通 プラクティス CMMI段階表現のモデル 13 要件管理 SG1 要件を管理する SP1.1 要件の理解を獲得する SP1.2 要件に対するコミットメントを獲得する SP1.3 要件変更を管理する SP1.4 要件に対する双方向の追跡可能性を維持する SP1.5 プロジェクト作業と要件の間の不整合を特定する 14 ユーザのニーズ 顧客の期待 ユーザ機能 システム機能 総合テスト コンポーネント 結合テスト ...... 単体テスト 追跡可能性 15 要件開発 SG1 顧客要件を開発する SP1.1 ニーズを引き出す SP1.2 顧客要件を開発する SG2 成果物要件を開発する SP2.1 成果物要件と成果物構成要素の要件を確立する SP2.2 成果物構成要素の要件を割り当てる SP2.3 インタフェース要件を特定する SG3 要件を分析し妥当性を確認する SP3.1 運用の考え方と運用シナリオを確立する SP3.2 要求された機能性の定義を確立する SP3.3 要件を分析する SP3.4 つり合いをとるために要件を分析する SP3.5 包括的手法で要件の妥当性を確認する 16 要求仕様の二つのレベル • • ConOps SRS 17 Concept of Operations • ConOps 顧客要件, 要求定義書, ストーリ・カード, ... • • • • • 要求をユーザ/顧客の視点から捉えたもの 主な読者はユーザ, 顧客など SRSの元となる IEEE Std. 1362-1998 18 Software Requirement Specification • SRS 成果物要件, 要求仕様書, タスク・カード, ... • • • • • • • 要求を成果物の視点から捉えたもの 主な読者は開発者, 顧客など ConOpsをエンジニアリングの言葉で言い換えたもの 設計書, テスト仕様書の元となる システム・レベルの要求仕様書 (SyRS) がある場合がある IEEE Std. 830-1998 19 ConOpsの内容 • • • • • • 現在どういう状況にあるか それをどういう状況に変えたいか そのために何を実現すればよいか シナリオ どういう影響が予想されるか 注意すべき点 20 SRSの内容 • • • • • • 外部とのインタフェース 機能 性能 データ構造 制約 品質属性 21 外部環境 顧客/ユーザ 制約/影響 見積もり/計画 要求 要求を抽出する フィードバック ConOps 要求を洗練する 制約/アドバイス フィードバック プロジェクト 管理者 要求を組織化する 技術環境 要求仕様を作成する 要求を検証する SRS 開発者 要求仕様策定のタスク 22 外部環境 顧客/ユーザ 要求変更 報告 要求変更 要求変更を管理する 変更 要求の妥当性を 確認する 要求変更 要求を追跡する 報告 開発者 要件管理のタスク 23 II. 要求仕様のプロセス 24 要求を抽出する • • • • • 誰が 何から どういうタイミングで どうやって要求を抽出し どう表すか 外部環境 顧客/ユーザ 制約/影響 見積もり/計画 要求 要求を抽出する フィードバック 要求を洗練する 制約/アドバイス フィードバック ConOps プロジェクト 管理者 要求を組織化する 技術環境 要求仕様を作成する 要求を検証する SRS 開発者 25 誰が • • どんな知識が必要か • • • 問題領域の知識や経験があるに越したことはない しかし我々が専門家になる必要はない 解決領域の知識や経験があった方がよい どんな素質が必要か • • • • • コミュニケーション能力 論理的に考える能力 問題を見つけ出す能力 学習能力 これらの能力は育てることもできる 26 どんなチームで • できればユーザが (フルタイムでなくても) チームに加わってくれると よい • • • 人数はスコープによるが, 複数人の方がよい • メンバに得意分野があるとしても, 早いうちに専門を固定しない方が よい • • 随時チーム外の専門家に協力を求められると理想的である スコープが広い場合, 最初は少人数で始めて人数を増やしていく 数人を超えるようならば, 少し進んだところでスコープとチームを分 割する ピラミッド型か水平型かはチームによってどちらでも 27 何から • • • • • ユーザへのインタビュー, 観察, 共同作業 ユーザ提供の資料 既存システムとそれに関連するドキュメント, ソース・コードなど 現在使われている帳票, 帳簿, その他のノート, 文書類 法律, 条例, 業界標準, 内部規約など ユーザ/顧客から預かった資料の一部は保存, 取扱に十分すぎるほどの注意が必要であることに留意する 28 どういうタイミングで • 「完全な」要求の収集/抽出を求めてはいけない • • • 「完全な要求」が出揃う頃には最初の重要なことを忘れている • • 人間の理解力/記憶力には限界がある ユーザ/顧客はもちろん話したことを覚えている → 不信感 要求はそもそも矛盾しているものだから, それを逐一調整していた らいつまで経っても終わらない 次の工程に回らずに山積みになっている「完全な要求」は不良在 庫と同じ (資産ではなく, コストと捉えるべき) • なぜならばその間にも要求や状況は変化していくから • すべての完全な要求が揃わなければ次の工程に進めない, というのは 神話であり, 多くの場合それはむしろプロジェクトの遅延を招く • 要求の漸増的な変化に対応可能な設計/実装技術は既にある 29 どうすればよいか ✓ ✓ ✓ 時間を区切る 全体の75%を押さえることができたと思った時点でいったん終了する 全体がよく見えないものを学習するためのひとつの方法: T字型探索 2. システムの本質に近い部分, 重要な部分を見いだす 1. まずは全体をおおざっぱに押さえる 概要 大粒度 経理 総務 人事 ... 中粒度 小粒度 3. その部分をいちばん深いところまで掘る 4. そのノウハウを活かして残りの部分を分担して行う 30 どうやって • インタビュー • 録音, 録画をすることもあるが, 後で聴き (見) 返すことは (予算が十 分で専任がいるような場合を除いて) ほとんどない • ホワイトボードを使って重要な部分を図示する (してもらう) と役 に立つこともあるが, 下手をすると後で何を書いたか分からない • • • • もちろん, 盤面はコピー, デジカメなどで残す ノートに記録する代わりに, プロジェクタで画面を投影したPCに書 いていくと, インタビュー相手のフィードバックを得られる場合が ある • この場合にはそのまま生きた資料として使える可能性がある いずれの場合もインタビューをする側は複数の方がよい 現場 • 実際に数日間 ~ 数週間, 一緒に仕事をする 31 どうやって • • • 資料 • 既存システムの画面, ユーザーズ・マニュアル, 開発ドキュメント, ソース・コード, DBスキーマ, 外部システムとのインタフェース • • • • 帳簿, 帳票, コード体系, ノート, メモ 関連法規, 条例, 業界標準, 社内規約 できるだけ電子的なコピーを作って保存する 保存/取扱には注意する ユーザの情報システム部門担当者 • 現状にどっぷり浸かっているので意外とバイアスがかかっている 場合もある ユーザ/顧客のトップ・マネジメント • ポリシ, 制約, 方向性, ... 32 どう表すか • • • • • できるだけ迅速に • 例えばインタビューの当日中, あるいは翌日中 複数の当事者が共同で • • 例えばプロジェクタで画面を共有しながら あるところまで押さえたら後は分担してもよい できるだけ電子的/標準的/単純な表現方法で • 例えばテキストはプレーン, HTMLなどで, 図はチーム標準の作図 ツールを決める, など まとめたものは全文検索可能なように • フォルダ構成に凝りすぎてもしようがない バージョン管理をする • • CVS, subversionなど 著者, 日付, コメントなどメタデータも管理できる 33 どう表すか • • • • • • 自然言語 図表現 (UML) モデル 辞書 一次資料 (かたちにならない - 体験, 気持ち, 雰囲気, etc - 成果物もあることに注 意) 34 自然言語 • wikiが役に立つことがある • 同じ用語, 概念の間の (自動) リンク • いかにうまく「名付け」られるか • 簡潔明快な文章 • 論理的な文章 • 曖昧で不明な部分はそのまま残しておくことも重要 ➡ 辞書 35 図表現 • • • • • • マトリックス → 最初から使いすぎない → 後述 象限図 → 最初から使いすぎない → 後述 ベン図 → 最初から使いすぎない → 後述 バブルチャート ツリー まとめるためではなく, 考えるため, こんぐらかった現実を腑分けする ため, 気付くための道具として 36 (UML) モデル • システム (これから作るもの) をモデリングするためではなく, 現実を モデリングするためにUMLを「借りる」 • • できるだけオープン・セッションで 例えば帳票 37 (UML) モデル • 例えば作業フロー 38 辞書 • • • • 専門用語, 業界用語, 社内用語, 技術用語, 隠語など キーになる概念, 帳票名, 画面名など それらの間のつながり どうやって表すか • • • • • Excelなど (そのうちに大変になる) 前述の自然言語のWiki Link 前述のバブルチャート (MindMapなどでもよい) 前述の (UML) モデルのクラス図など オントロジ・エディタ 39 オントロジ • • • • オントロジとは • • 概念化の明示的な規約 • 複数人の間で共有される合意内容 人工システムを構築する際の部品として用いられる基本概念/語彙 の体系 概念辞書の発展形と思ってもよい • 実際に多くのシステム構築 (例えば原子炉制御システム) で使われ ている オントロジ表現言語 • 代表的なのはSemanticWebでも使われているOWL/RDF オントロジ・エディタ • 代表的なのはProtégé (スタンフォード大薬学部, 20年近い歴史) 40 オントロジの例 41 要求を洗練する • • • • • 誰が - 前と同じ 何から - 前のアウトプット どういうタイミングで どうやって要求を洗練し どう表すか - 前と同じ 外部環境 顧客/ユーザ 制約/影響 見積もり/計画 要求 要求を抽出する フィードバック 要求を洗練する 制約/アドバイス フィードバック ConOps プロジェクト 管理者 要求を組織化する 技術環境 要求仕様を作成する 要求を検証する SRS 開発者 42 どういうタイミングで • ある程度細かく • • 例えば毎週 例えば分野/粒度の区切りごと 概要 経理 総務 人事 ... 大粒度 中粒度 小粒度 • • • 月に一回とか最後に一回では少なすぎる ユーザ/顧客や専門家からのフィードバックが重要 開発者がユーザ/顧客から, ユーザ/顧客が開発者からお互いに学び合う よい機会であると考える 43 どうやって • • • 抽出した要求のプレゼンテーションと議論 (レビュー) • • 目的は「完全で正しい」要求に到達することではない 限られた時間と費用でよりよい要求に合意することである ポイント • • • • (詳細すぎない) アジェンダ (目標) を用意すること 結果をちゃんと反映させること よい進行役 (ファシリテータ) がいること 一度に時間をかけすぎないこと (最大3時間) 動くものがあるとよりよい • 最近はクラス図などから少ないコストでマスタ画面を作ることが できるものもある • • GUIの紙芝居 画面遷移/状態遷移のシミュレータ 44 要求を組織化する • • • • • 誰が - 前と同じ 何から - 前のアウトプット どういうタイミングで どうやって要求を組織化し どう表すか 外部環境 顧客/ユーザ 制約/影響 見積もり/計画 要求 要求を抽出する フィードバック 要求を洗練する 制約/アドバイス フィードバック ConOps プロジェクト 管理者 要求を組織化する 技術環境 要求仕様を作成する 要求を検証する SRS 開発者 45 どういうタイミングで • • • 要求のリリース計画を立てよう 例えば • • • • 最初の一ヶ月目に全体の概要 以後2週間ごとに部門ごとの主要要求 設計開始前にその部門の詳細要求 設計開始後に毎週要求変更管理 つまりConOps, SRSも進化する • 出たとこ勝負での進化ではなく, ある枠組みの中での進化 46 どうやって • • • • • • • • • • • ユーザ 機能 品質 性能 優先度 シナリオ 制約 前提 実現可能性 リスク 要求自体の品質 47 ユーザ • • • このシステムに関わる組織にはどんな役割 (ロール) があるか 誰 (役割) がそのシステムを使うのか • 誰がそのシステムから利益を得たり, 影響を受けたりするのか 誰 (役割) がその機能を使うのか • 誰がその機能から利益を得たり, 影響を受けたりするのか 48 機能 • • • • どんな機能が必要とされているか • ここで問題にしているのはユーザ機能 (フィーチャ), つまりユーザ から見える機能であることに注意 • 往々にしてシステム機能, つまり実現する側から見た機能と混同し やすい ユーザにとって意味のある単位であること • • つまり「ボタンを押す」などは機能にならない その機能からユーザがまとまった利益を受けるものである 優先順位を付ける • MoSCoWルール = Must, Should, Could, Would (必須/必要/希望/オプ ション) 具体的かつ簡潔に • 具体的かつ簡潔に書けないと言うことはまだ詰めが甘い 49 品質 • 理想的には機能ごとに次頁の品質属性のそれぞれについて定量的に定 義する • • しかしそれは現実的ではない ひとつの方法として • 機能あるいは機能グループに対して, 最優先すべき制約 (品質, 納期 など) 1~2点とそれが実現しなかった場合の損害額を定義する • その点数X損害額に応じて開発チームはボーナスあるいはペナル ティを得る (この点は契約が絡むので難しいが) • これによってモチベーションと同時に何に注力すべきかを開発者 と顧客/ユーザで共有できる 50 品質モデル (ISO/IEC-9126) • • 外部品質/内部品質 • • • • • • 機能性 信頼性 使用性 ユーザの品質ニーズ 効率性 利用時の品質 保守性 移植性 外部品質要求 利用時の品質 • • • • 利用/反映 妥当性確認 外部品質 有効性 生産性 内部品質要求 検証 内部品質 安全性 満足性 51 機能性 • ソフトウェアが, 指定された条件の下で利用されるときに, 明示的及び 暗示的必要性に合致する機能を提供するソフトウェア製品の能力 • 副特性 • • • • • 合目的性 正確性 相互運用性 セキュリティ 機能性標準適合性 52 信頼性 • 指定された条件の下で利用するとき, 指定された達成水準を維持する ソフトウェア製品の能力 • 副特性 • • • • 成熟性 障害許容性 回復性 信頼性標準適合性 53 使用性 • 指定された条件の下で利用するとき, 理解, 習得, 利用でき, 利用者に とって魅力的であるソフトウェア製品の能力 • 副特性 • • • • • 理解性 習得性 運用性 魅力性 使用性標準適合性 54 効率性 • 明示的な条件の下で, 使用する資源の量に対比して適切な性能を提供 するソフトウェア製品の能力 • 副特性 • • • 時間効率性 資源効率性 効率性標準適合性 55 保守性 • 修正のしやすさに関するソフトウェア製品の能力. 修正は, 是正もしく は向上, または環境の変化, 要求仕様の変更及び機能仕様の変更にソフ トウェアを適応させることを含めてもよい • 副特性 • • • • • 解析性 変更性 安定性 試験性 保守性標準適合性 56 移植性 • • ある環境から他の環境に移すためのソフトウェア製品の能力 副特性 • • • • • 環境適応性 設置性 共存性 置換性 移植性標準適合性 57 利用時の品質 • • • • 有効性 • 利用者が指定された利用の状況で, 正確かつ完全に, 指定された目 標を達成できるソフトウェア製品の能力 生産性 • 利用者が指定された利用の状況で, 達成すべき有効性に対応して、 適切な量の資源を使うことができるソフトウェア製品の能力 安全性 • 利用者が指定された利用の状況で, 人, 事業, ソフトウェア, 財産また は環境への害に対して, 容認できるリスクの水準を達成するための ソフトウェア製品の能力 満足性 • 指定された利用の状況で, 利用者を満足させるソフトウェア製品の 能力 58 シナリオ • • 単に機能を列挙しただけでは, 見落としや矛盾, 間違いを見つけにくい • • ソフトウェアの「絵コンテ」 • シナリオは機能が時間に沿ってどう使われるかを具体的に描くするも の ここでは「コンテキスト (文脈)」や「時間」が重要になる • • • もちろんすべての場合を列挙することはできない 典型的な例+重要な例外 どこまで考えていたか, を明らかにすることも重要 ただしユーザ・インタフェースを詳細に指定するものではない 59 シナリオの書き方 • • • • 自然言語 • アウトライン・プロセッサなどが使いやすい 絵コンテ風 • 右側に画面イメージなど, 左側に説明 脚本作成ツール • NovaMind/ScreenWriterなど UMLシーケンス図/アクティビティ図 60 制約, 前提, 実現可能性 • • • 制約とは • • 要求に含まれる設計/実装上の制限 法的な制約, 組織方針による制約, 物理的な制約など 前提とは • • 要求が成立する条件 前提が成り立つ場合にのみ要求が意味を持つ 実現可能性とは • 要求が現在の技術水準, 開発者の持つ技術力, 適正な時間とコスト で実現可能かどうか 61 リスク • この要求を実現するに当たって, どのような, どの程度の不安要因があ るか (未来に対する不確実性) • • リスクがなければチャンスもない • 要求に関するリスクの種類 重要なのはリスクを避けることではなく, リスクを認識し, リスクに対 処すること • • • • • 技術上のリスク 開発側に由来するリスク 顧客側に由来するリスク 状況変化のリスク 要求自身に含まれるリスク 62 要求の品質 • • • • • • • • • • 要求は明確か 要求は関係者全員にとって一意に理解可能か 要求は重複していないか 要求は (ほぼ) 完全か 要求は矛盾していないか 要求の間の依存関係は明確か 要求は変更/進化が容易か 要求は検証と妥当性確認が可能か 要求は追跡可能か 前に述べた要求の属性 (ユーザ ~ リスク) をすべて満たしているか 63 どう表すか • • • • • Excel, ワード・プロセッサ, アウトライン・プロセッサなど 要求管理ツール UMLモデリング・ツール カード その他 64 要求管理ツール • Rational Requisite Pro • http://www.sra.co.jp/Rational/requisitepro/requisitepro.html • Telelogic DOORS • http://www.telelogic.co.jp/products/doors/ • OSRMT (Open Source Requirement Management Tool) • http://www.osrmt.com/ 65 UMLによる要求モデリング • • • • • • • アクタ ユースケース 概念クラス シナリオ 状態遷移 ルール UMLは本来ソフトウェア・システムをモデリングするものであるが, ここではあくまで要求をモデリングするのであって, ソフトウェア・ システムをモデリングするのではない! 66 要求を検証する • • • • • 誰が - 前と同じ 何から - 前のアウトプット どういうタイミングで - 前と同じ どうやって要求を検証し どう表すか - 前と同じ 外部環境 顧客/ユーザ 制約/影響 見積もり/計画 要求 要求を抽出する フィードバック 要求を洗練する 制約/アドバイス フィードバック ConOps プロジェクト 管理者 要求を組織化する 技術環境 要求仕様を作成する 要求を検証する SRS 開発者 67 どうやって • • • インスペクション プロトタイピング モデル検証 68 インスペクション • • • ユーザ/顧客を入れる場合と入れない場合がある • インスペクション・ミーティングの時間は2時間 (どうしても必要なら 休憩を挟んで) 2回 • • • インスペクション・ミーティング中に議論は行わない 要求検証と妥当性確認のためのチェック・リスト (1頁) を用意する インスペクション・ミーティングの前に全参加者に対象成果物と チェック・リストを渡しておき, あらかじめチェックしておく 対象成果物を読み上げる人, 進行をする人, 記録をする人をおく フォローアップを行う 69 プロトタイピング • • • • • クラス定義から操作GUIを生成するようなツール • Ruby on Rails, Django, Mock Object, ... UIの紙芝居 • Flash, ... モデル駆動開発 シミュレータ • • • 状態チャート メッセージ・シーケンス・チャート ワークフロー・デバッガ 実は要求と実装の間の距離はどんどん近くなっている 70 要求仕様を作成する • • • • • 誰が - 前と同じ 何から - 前のアウトプット どういうタイミングで どうやって要求仕様を作成し どう表すか 外部環境 顧客/ユーザ 制約/影響 見積もり/計画 要求 要求を抽出する フィードバック 要求を洗練する 制約/アドバイス フィードバック ConOps プロジェクト 管理者 要求を組織化する 技術環境 要求仕様を作成する 要求を検証する SRS 開発者 71 どういうタイミングで • 1回のリリースしかないウォータフォール型プロセスならば • • • • • この時点でほとんどできるという確信がなければならない 全体のスケジュールの40%をここに割いてもよい • 残りは20%が設計, 10%が実装, 30%がテスト 実際にはコードの一部もテストの一部も既になければ完全な要求 仕様書にはならない 要件の変更は「本当は」あり得ない 複数回のリリースが可能ならば • 例えば, 最初のリリースに対応する部分については90%, それ以外に 関しては40%程度の完成度と思えればよい • • 本質を捕まえることが重要 要件の変更をちゃんと追跡し, 管理する 72 III. 要求仕様書の書き方 73 参考図書 • • • • • • • • • "要求開発", 要求開発アライアンス, 2006, 日経BP "要求定義・要求仕様書の作り方", 山本, 2006, SRC "ソフトウェア要求と仕様", ジャクソン, 2004, 新紀元社 "ソフトウェア要求", Wiegers, 2003, 日経BP "要求工学", 大西, 郷, 2002, 共立出版 "要件プロセス完全修得法", ロバートソン, ロバートソン, 2002, 三元社 "要求定義工学プラクティスガイド", Sommerville, Sawyer, 2000, 共立出版 "要求定義工学入門", Loucopoulos, Karakostas, 1997, 共立出版 "要求仕様の探検学", ゴーズ, ワインバーグ, 1993, 共立出版 74 要求仕様は 与えられるものではなく, 発見と 合意形成のプロセスである ユーザにとっての価値を最大に するものでなければならない 75