第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」
•
5 j'aime•2,305 vues
2015年7月31に開催した第74回名古屋アジャイル勉強会のワークショップ資料です。
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à 第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」
Similaire à 第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」 (20)
Plus de hiroyuki Yamamoto
Plus de hiroyuki Yamamoto (20)
第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」
- 2. 2 自己紹介 ● 山本 博之（やまもと ひろゆき） ● ベンダー勤務のITエンジニアです。 ● 最近はメインフレームのデータベース移行支援の仕 事をしています。主な開発ツールはエクセルです… ● 以前はミドルウェア製品の保守を担当していて、トラ ブルや要望対応をしていました。顧客と直接会話す る機会はほとんどなく、サポート部門やSEとのやり とりが多かったです。なにがしたいかを聞くときに は、なぜそれがしたいのかを聞くことが大事、という 経験をよくしました。
- 4. 4 要件定義の重要さと難しさ ● ソフトウェア開発やシステム開発は、簡単に言ってしまえば、顧 客の要求をソフトウェアによって実現することです。しかし、顧 客の要件をうまくまとめることができず、開発がうまくいかない ことがとても多いです。 ● 日本情報システム・ユーザ協会(JUAS)の「ユーザー企業ソフ トウェアメトリックス調査【調査報告書】2012年版」 （http://www.juas.or.jp/servey/library/pdf/12swm.pdf）によ れば、工期遅延理由のトップ3は、 – 1. 要件仕様の決定遅れ(20.86%) – 2. 要件分析作業不十分(16.18%) – 3. 開発規模の増大(13.90%) ● となっています。
- 5. 5 要件定義を難しくしているもの ● 今日のソフトウェア開発・システム開発では、以下のよう な点で難しさが増加しています。 – 業務面：単純なIT化でなく、業務改革や革新的な新規業務 などが増え、困難さや不透明さが増えた – システム面：他システム連携が当たり前となり、必要な調査 範囲が膨らみ、制約が課せられる – プロマネ面：グループ共通基盤、海外向けシステムなど、ス テークホルダー範囲が拡大した ● このような背景が、顧客の要件を聞き出してまとめるア クティビティである要件定義を難しくさせていて、結果と してプロジェクトの遅延やコスト増大といった失敗を招 いています。
- 6. 6 今回の勉強会のねらい ● 今回の名古屋アジャイル勉強会では、要件定義をう まく行なう方法について、学んでみたいと思います。 – といっても、要件定義の範囲ややり方は、プロジェクトに よって千差万別なので、こうやればOKという話は残念な がらできません。 – 要件定義に関する汎用的なヒントやツールを紹介しま す。 – また、参加者のみなさんの体験・経験も共有して、みなさ んの今後の参考になればと思います。
- 8. 8 要件定義とは ● システムやソフトウェアの開発において、実装すべき機能や満たす べき性能などのを明確にしていく作業のこと。いわゆる上流工程 の一部で、実際の開発・実装作業を始める前に行う作業の一つで ある。 ● 要件定義では、利用者がそのシステムなどで何がしたいのかを元 に、それを実現するために実装しなければならない機能や、達成 しなければならない性能などを開発者が検討して明確にしてい く。 ● まとめられた成果は「要件定義書」として文書化されることが多 い。一般的にこの段階では「何が」必要なのかを定義するに留め、 それを「どのように」設計・実装すべきかは後の工程で検討され る。 – （IT用語辞典 e-Words http://e-words.jp/w/%E8%A6%81%E4%BB %B6%E5%AE%9A%E7%BE%A9.html）
- 10. 10 要件定義は難しい ● 顧客は自分が求めているものを具体的に把握しているとは限りま せん。 – 立場によって「どうあるべきか」は異なります。 – 昨今、業務改革や新規事業の構築など、システムの目的が複雑になって きています。 ● 顧客はシステムのプロではありません。 – さらに顧客側の窓口/代表は業務のプロではないかもしれません。 – と同時に開発者は業務のプロではないことが多いです。 ● 要求以外の要件を定義することも難しい。 – 性能、セキュリティ、災害対策などトラブル時のリカバリー等々、検討し明 確にしなければならないことが増えています。 – 利用者数やデータ量の将来的な変化を予測・限定することが難しくなっ ています。 ● 先のことを正確に予測することは難しいです。
- 12. 12 プロジェクトの最初の段階ですべてを 決めることはできない ● 一括請負での受託開発が本質的に抱えるリスク ● 計画重視型プロジェクトのモデル – いっぺんにまとめて全部作る – 要件定義をもれなく行なうことでリスクを回避しようとす る ● しかししばしば失敗します。典型的には、要件定義が終わらな い。 – さらなるリスク対策としてバッファを積む ● バッファは必要とは思いますが、これは本当の解決なのでしょ うか…
- 13. 13 ワーク：自己紹介 ● ここで、自己紹介の時間を取りたいと思います。 ● A3用紙にサインペンで以下の事項を書き出してく ださい。 – お名前（本名でなくてかまいません） – お仕事（お話できる範囲でかまいません） – これまでのお仕事で、顧客と接するなかで感じたこと、体 験したことをなにかひとつ紹介してください（お話できる 範囲でかまいません） ● 書けたら、順番を決めて発表してください。
- 20. 20 非機能要求グレード ● IPAが提供しているドキュメントです。 ● 非機能項目を分類し、各項目の特徴を説明し、実現レベルを6 段階で定義しています。 – 大項目として、「可用性」、「性能・拡張性」、「運用・保守性」、「移行 性」、「セキュリティ」、「システム環境・エコロジー」が挙げられていま す。 ● 実現レベルの異なる3種類のモデルを定義し解説しています。 ● 要件定義工程での利用イメージ 1.事業要件定義・業務要件定義段階において、モデルシステムを選定 する 2.システム要件定義段階において、重要項目のレベルを決定する 3.RFPの作成、見積りや提案書の作成段階において、重要項目以外の レベルを決定する
- 21. 21 ここまでの理解度チェック ● 「表明じゃんけん」でみなさんの理解度を確認させ てください ● ここまでの理解度に応じて、グーチョキパーを出して ください – パー：十分に理解した。問題なし。 – チョキ：いまいちだが、進んでよし。 – グー：全然分からない。 ● 質問・コメントがあればお願いします。
- 24. ワークのアウトプットと進め方 ● 要件定義のアウトプットは「要件定義書」とします – A3用紙に、要件のリストを書き出してください。 – 要件とは、顧客が実現したいこと（要求）と、要求には直接現れない けれど検討や準備が必要な事項（非機能要求）です。 ● ワークの進め方 – 要件定義書の作り方を話しあって決めてください – 必要に応じて役割（書記とかタイムキーパーとか）を決めてください – 要件として明確にすべき項目を洗い出してください – 要件を明確にするために、顧客（山本）がインタビューに答えます – 時間になったら、作成した要件定義書を説明してください – その後、ワークの感想をシェアします。
- 25. 要件定義体験の感想の共有 ● 要件定義（のシミュレーション）を行ってみていかが でしたか？ – 顧客と協調しておもてなしを実現できそうですか？ – 要件はもれなく明確化することができましたか？ – 要件の変化に対応できそうですか？
- 27. 27 参考：アジャイル開発での要件の扱い ● アジャイル開発においても、プロジェクトの最初に要件の洗い出しを行いま す。しかし、この段階ですべてを洗い出し確定できるとは考えません。この段 階では考えられる要件を概要レベルで洗い出し、リストを作るにとどめます。 ● 最重要で直近に着手すべき要件だけに絞って、詳細に検討し、実装します。 – 顧客にとって最も価値がある要求 – 全体のアーキテクチャや非機能要求に深く係る部分 – 最も困難な課題 ● 実装した要件を顧客にレビュー（あるいは使用）してもらい、そのフィードバッ クを元に、要件リストの見直しを行います。 ● これを繰り返します。 ● プロジェクトが終わるのは、最初に決めたことがすべてできた時ではなく、顧 客がもう十分だと感じた時です。 – しかし、今日のシステム開発に終わりがあるでしょうか？ – 継続的なシステムの成長・変化を、システムのライフサイクルを通じて実現するのが アジャイルの考え方です
- 28. 28 本日紹介したIPAの成果物 ● 共通フレーム2013 – https://www.ipa.go.jp/sec/softwareengineering/repo rts/20130304.html – 共通フレーム2013の概説 ● https://www.ipa.go.jp/files/000027415.pdf ● 非機能要求グレード – http://www.ipa.go.jp/sec/softwareengineering/report s/20100416.html