Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」

1,583 views

Published on

2015年7月31に開催した第74回名古屋アジャイル勉強会のワークショップ資料です。

Published in: Software
  • Be the first to comment

第74回名古屋アジャイル勉強会「後悔しない要件定義のまとめ方」

  1. 1. 後悔しない要件定義のまとめ方 2015-07-31 名古屋アジャイル勉強会 山本 博之
  2. 2. 2 自己紹介 ● 山本 博之(やまもと ひろゆき) ● ベンダー勤務のITエンジニアです。 ● 最近はメインフレームのデータベース移行支援の仕 事をしています。主な開発ツールはエクセルです… ● 以前はミドルウェア製品の保守を担当していて、トラ ブルや要望対応をしていました。顧客と直接会話す る機会はほとんどなく、サポート部門やSEとのやり とりが多かったです。なにがしたいかを聞くときに は、なぜそれがしたいのかを聞くことが大事、という 経験をよくしました。
  3. 3. 3 この資料について ● この資料はインターネットで公開し、URLは開催報 告等で広報します。 ● ですので、この資料の内容をメモする必要はありま せん。 ● セッションやワークショップに集中していただければ さいわいです。 ● テーブルにプリントアウトを用意してありますので、 必要に応じて参照してください。
  4. 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. 5 要件定義を難しくしているもの ● 今日のソフトウェア開発・システム開発では、以下のよう な点で難しさが増加しています。 – 業務面:単純なIT化でなく、業務改革や革新的な新規業務 などが増え、困難さや不透明さが増えた – システム面:他システム連携が当たり前となり、必要な調査 範囲が膨らみ、制約が課せられる – プロマネ面:グループ共通基盤、海外向けシステムなど、ス テークホルダー範囲が拡大した ● このような背景が、顧客の要件を聞き出してまとめるア クティビティである要件定義を難しくさせていて、結果と してプロジェクトの遅延やコスト増大といった失敗を招 いています。
  6. 6. 6 今回の勉強会のねらい ● 今回の名古屋アジャイル勉強会では、要件定義をう まく行なう方法について、学んでみたいと思います。 – といっても、要件定義の範囲ややり方は、プロジェクトに よって千差万別なので、こうやればOKという話は残念な がらできません。 – 要件定義に関する汎用的なヒントやツールを紹介しま す。 – また、参加者のみなさんの体験・経験も共有して、みなさ んの今後の参考になればと思います。
  7. 7. 7 アジェンダ ● 要件定義とは ● 要件定義は難しい ● ワーク:自己紹介 ● 要件定義を成功させるためのポイントとツール ● ワーク:要件定義を体験してみよう ● まとめ
  8. 8. 8 要件定義とは ● システムやソフトウェアの開発において、実装すべき機能や満たす べき性能などのを明確にしていく作業のこと。いわゆる上流工程 の一部で、実際の開発・実装作業を始める前に行う作業の一つで ある。 ● 要件定義では、利用者がそのシステムなどで何がしたいのかを元 に、それを実現するために実装しなければならない機能や、達成 しなければならない性能などを開発者が検討して明確にしてい く。 ● まとめられた成果は「要件定義書」として文書化されることが多 い。一般的にこの段階では「何が」必要なのかを定義するに留め、 それを「どのように」設計・実装すべきかは後の工程で検討され る。 – (IT用語辞典 e-Words http://e-words.jp/w/%E8%A6%81%E4%BB %B6%E5%AE%9A%E7%BE%A9.html)
  9. 9. 9 要件定義と要求定義 ● 要件定義に先立って、利用者が業務を進める際に、 そのシステムなどを使って何がしたいのか、何がで きなければ困るのかといった内容を聞き取ってまと める作業を「要求定義」というが、要件定義と要求 定義を同義とする立場もあり、その場合は、このよう な利用者からの要求をまとめる作業も要件定義に 含まれる。 – (IT用語辞典 e-Words)
  10. 10. 10 要件定義は難しい ● 顧客は自分が求めているものを具体的に把握しているとは限りま せん。 – 立場によって「どうあるべきか」は異なります。 – 昨今、業務改革や新規事業の構築など、システムの目的が複雑になって きています。 ● 顧客はシステムのプロではありません。 – さらに顧客側の窓口/代表は業務のプロではないかもしれません。 – と同時に開発者は業務のプロではないことが多いです。 ● 要求以外の要件を定義することも難しい。 – 性能、セキュリティ、災害対策などトラブル時のリカバリー等々、検討し明 確にしなければならないことが増えています。 – 利用者数やデータ量の将来的な変化を予測・限定することが難しくなっ ています。 ● 先のことを正確に予測することは難しいです。
  11. 11. 11 ベームの図(あるいは不確実性コーン) http://csse.usc.edu/csse/TECHRPTS/1984/usccse84-500/usccse84-500.pdf
  12. 12. 12 プロジェクトの最初の段階ですべてを 決めることはできない ● 一括請負での受託開発が本質的に抱えるリスク ● 計画重視型プロジェクトのモデル – いっぺんにまとめて全部作る – 要件定義をもれなく行なうことでリスクを回避しようとす る ● しかししばしば失敗します。典型的には、要件定義が終わらな い。 – さらなるリスク対策としてバッファを積む ● バッファは必要とは思いますが、これは本当の解決なのでしょ うか…
  13. 13. 13 ワーク:自己紹介 ● ここで、自己紹介の時間を取りたいと思います。 ● A3用紙にサインペンで以下の事項を書き出してく ださい。 – お名前(本名でなくてかまいません) – お仕事(お話できる範囲でかまいません) – これまでのお仕事で、顧客と接するなかで感じたこと、体 験したことをなにかひとつ紹介してください(お話できる 範囲でかまいません) ● 書けたら、順番を決めて発表してください。
  14. 14. 14 要件定義を成功させるためのポイント ● IPA(情報処理推進機構。日本におけるIT国家戦略を技 術面、人材面から支えるために設立された、経済産業省 所管の独立行政法人)が提供している「共通フレーム 2013」というドキュメントがあります。 ● 「共通フレーム」とは、ソフトウェア・システムのライフサイク ルを通じて必要な作業項目、役割等を包括的に規定した 共通の枠組みです。関係者が同じ言葉で話すことができ るように記述されています。 ● このドキュメントは要件定義を含む「超上流」を特に重視 しています。このドキュメントの主な考え方から、要件定義 を成功させるために重要と思われるいくつかを紹介しま す。
  15. 15. 要件定義を成功させるためのポイント ● 超上流における準委任契約の採用 ● 多段階見積り方式 ● 利害関係者の役割と責任分担、要件の合意および 変更方法の明確化 ● 非機能要件の重要性の認識
  16. 16. 16 要件定義は準委任契約で ● 要件定義を受託契約で行ったプロジェクトの失敗率が 高いことが指摘されています。 – ユーザー企業ソフトウェアメトリックス調査報告書2012年度版 – 経済産業省「情報システムの信頼性向上のための取引慣行・ 契約に関する研究会」報告書(平成19年) ● 要件定義と開発以降の工程を切り離して別契約とし、準 委任契約とすることが有効であるといわれています。 ● 成果物の完成責任を受託側が負わない契約なので、発 注側としては若干嫌な感じかもしれません。 ● 顧客側に本気になってもらうためには有効な手段だと考 えられています。
  17. 17. 17 多段階見積り方式 ● 先に述べたように、初期段階で遠い先のことを正確 に予測することはできず、その予測に基づいた計画に は多大なリスクが含まれます。 ● これを回避するために、フェーズ毎に見積りをやり直 し、それに基づいて計画の見直しを行うことを、プロ ジェクト計画に盛り込むとよいです。 ● アジャイル開発では、リリース計画やスプリント計画 において常時直近の開発の見積りを行いますし、非 アジャイル型開発においても、適宜再見積りと計画の 見直しを行うことが有効であるといわれています。
  18. 18. 18 利害関係者の役割と責任分担、要件 の合意および変更方法の明確化 ● 利害関係者の役割と責任分担の明確にします。 – 事業要件、業務要件、システム要件を定義できるのは、 それぞれ経営層、業務部門、情報システム部門であり、 それぞれが責任をもってみずからの役割を果たすこと で、要件を適切に定義できます。 ● 要件の合意及び変更ルールを事前に確立しておき ます。 – 要件は時間とともに変わるものなので、その変更ルール を関係者が事前に策定し合意しておくことで、柔軟な対 応が可能になります。
  19. 19. 19 非機能要件の重要性の認識 ● 非機能要件(性能やセキュリティなどの間接的な要 件)の重要性を認識します。 ● 非機能要件にはなにがあって、どこまで検討し明確 にしておかなければいけないか、関係者が共通理 解を持っておくべきです。 ● 後述する「非機能要求グレード」を利用するなど、汎 用のテンプレートを用いることが有効です。
  20. 20. 20 非機能要求グレード ● IPAが提供しているドキュメントです。 ● 非機能項目を分類し、各項目の特徴を説明し、実現レベルを6 段階で定義しています。 – 大項目として、「可用性」、「性能・拡張性」、「運用・保守性」、「移行 性」、「セキュリティ」、「システム環境・エコロジー」が挙げられていま す。 ● 実現レベルの異なる3種類のモデルを定義し解説しています。 ● 要件定義工程での利用イメージ 1.事業要件定義・業務要件定義段階において、モデルシステムを選定 する 2.システム要件定義段階において、重要項目のレベルを決定する 3.RFPの作成、見積りや提案書の作成段階において、重要項目以外の レベルを決定する
  21. 21. 21 ここまでの理解度チェック ● 「表明じゃんけん」でみなさんの理解度を確認させ てください ● ここまでの理解度に応じて、グーチョキパーを出して ください – パー:十分に理解した。問題なし。 – チョキ:いまいちだが、進んでよし。 – グー:全然分からない。 ● 質問・コメントがあればお願いします。
  22. 22. 22 ワークショップ:要件定義を体験しよう イラスト:いらすとや http://www.irasutoya.com/
  23. 23. 23 お題:おもてなしを要件定義しよう ● 米国大統領がアジア歴訪の一環として来日するこ とが決まりました。3日間の来日中に、首相との会食 (夕食会)を設けたいと思います。 ● 顧客(山本)はお寿司なんかいいんじゃないかと 思っています。 ● この「おもてなし」を要件定義してください。
  24. 24. ワークのアウトプットと進め方 ● 要件定義のアウトプットは「要件定義書」とします – A3用紙に、要件のリストを書き出してください。 – 要件とは、顧客が実現したいこと(要求)と、要求には直接現れない けれど検討や準備が必要な事項(非機能要求)です。 ● ワークの進め方 – 要件定義書の作り方を話しあって決めてください – 必要に応じて役割(書記とかタイムキーパーとか)を決めてください – 要件として明確にすべき項目を洗い出してください – 要件を明確にするために、顧客(山本)がインタビューに答えます – 時間になったら、作成した要件定義書を説明してください – その後、ワークの感想をシェアします。
  25. 25. 要件定義体験の感想の共有 ● 要件定義(のシミュレーション)を行ってみていかが でしたか? – 顧客と協調しておもてなしを実現できそうですか? – 要件はもれなく明確化することができましたか? – 要件の変化に対応できそうですか?
  26. 26. 26 まとめ ● 要件定義とは、顧客の要求と、それを実現する機能 や性能などを明確にし、関係者で合意することです。 ● しかし、プロジェクト初期の短い時間で要件をすべて 洗い出し確定することは簡単ではありません。 ● 要件を明確にするための仕組みや体制、努力は重 要ですが、変更にも備えるべきです。 ● IPAの共通フレームから、要件定義のポイントをみて みました。 ● 非機能要件を確実にまとめるツールとして、IPAの非 機能要求グレードがあります。
  27. 27. 27 参考:アジャイル開発での要件の扱い ● アジャイル開発においても、プロジェクトの最初に要件の洗い出しを行いま す。しかし、この段階ですべてを洗い出し確定できるとは考えません。この段 階では考えられる要件を概要レベルで洗い出し、リストを作るにとどめます。 ● 最重要で直近に着手すべき要件だけに絞って、詳細に検討し、実装します。 – 顧客にとって最も価値がある要求 – 全体のアーキテクチャや非機能要求に深く係る部分 – 最も困難な課題 ● 実装した要件を顧客にレビュー(あるいは使用)してもらい、そのフィードバッ クを元に、要件リストの見直しを行います。 ● これを繰り返します。 ● プロジェクトが終わるのは、最初に決めたことがすべてできた時ではなく、顧 客がもう十分だと感じた時です。 – しかし、今日のシステム開発に終わりがあるでしょうか? – 継続的なシステムの成長・変化を、システムのライフサイクルを通じて実現するのが アジャイルの考え方です
  28. 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
  29. 29. 29 なにか質問・ご意見があれば ● 時間のある限り、お話ししたいと思います。

×