はじめよう! 要件定義 ~ビギナーからベテランまで

著者 :
  • 技術評論社
3.93
  • (15)
  • (24)
  • (15)
  • (2)
  • (0)
本棚登録 : 253
レビュー : 22
  • Amazon.co.jp ・本 (184ページ)
  • / ISBN・EAN: 9784774172286

作品紹介・あらすじ

「こんなソフトウェアを作ってほしい」という思い。そして「お役に立つソフトウェアを作りたい」という思い。その思いをつなぐのが本書のテーマである「要件定義」です。要件定義って何だろう?どうやったら要件定義がうまくできるんだろうか?本書はそれらについて説明しています。読み終わったとき、きっと「なるほど、こうすればいいんだ」という納得を手に入れられることでしょう。

感想・レビュー・書評

並び替え
表示形式
表示件数
  • システム開発には10年ほど関わっていますが、この本を読むことで要件定義ですべきことを改めて整理することができました。いつも感覚的に行っていたことが体系的にまとめられていてとても分かりやすく、新たな方法や気づきを与えてくれる本だと思います。
    必要な時にいつでも読み返せるように手元に置いておきたい本です。

  • 要件定義について分かりやすく説明されている。
    要件定義時点で決めなければならない項目が多いことと、実際の仕事上ではそこまで決めていないを再認識させられた

    UIが最重要、とのことであったが
    組み込みシステムや複数機器の組み合わせシステムなど
    人か介在しない(介在が限りなく少ない)システムの場合、
    どのように読み替えてよいのかが分からなかった。

  • ‪システム開発の要件定義の入門書。プロジェクト失敗の原因は要件定義が最も多いと聞いたことがあるがそもそも何が出来ていれば十分なのか?要求一覧からの絞り込みで迷走気味だったので要件定義の前に全体像を描いて実装技術を選定するという話がとても勉強になった。サクッと読める分量も助かる。‬

  • プログラミングについてある程度の知識がないと理解するのが少し難しい。全くの初心者よりも、プログラミングの技術はあるけれどもうまく周りと連携が取れないという人向けの本だと思う。

  • 仕事の絡みで図書館で借りて読んでみた。

  • 良著だと思います。
    ブリッジSE業務内容そのもので、わかりやすい言葉で書かれています。ぜひ、発注者側に読んで欲しい...

    特に、次の点でよかったです。
     ・言葉の定義が丁寧
     ・マインド(成果⇒評価⇒効果があって然るべき)
     ・要件定義工程を全体⇒詳細で網羅
       ⇒最低限、これだけあれば大炎上は防げるレベル

    本書内で「中流工程」と書かれていますが、そのとおりで、企画と実装のブリッジを理解されたい方の入門書としておススメです。

  • ベテランが読むのに適しているかは分からないけど、ビギナーにもとても読みやすいと思った。

    ◼ビギナーにも読みやすいポイント
    「易しい言葉に言い換える」
    「イラストを多用する」

    ◼その他の読みやすいポイント
    「キーワードは繰り返し提示する」
    「1ページに情報を詰めすぎない」

  • 業務システム開発でもスマホアプリ開発でも、
    ユーザ・顧客が納得のいくソフトウェアを実現するためには「要件定義」というフェーズが欠かせません。
    要件定義とは、「作ってほしい人と作る人の間の合意事項」であり、
    「UI」「機能」「データ」をどのようにするか決めていくことを言いますが、
    実際にはこのフェーズをおざなりに開発を進め、プロジェクトが迷走するケースが後を絶ちません。
    本書では、ソフトウェアの企画・開発に携わるすべての方にとって役に立つ「要件定義」の知識を、豊富な図解とともにわかりやすく解説します。

    本書では、UI・機能・データという3要素を軸に、
    どのように要件定義の工程を進めれば良いかが簡潔に解説されています。
    一般的には画面設計(UI)だけ作って終わりというプロジェクトが多く、
    本書でも「画面遷移図を描こう」が肝だとあとがきで述べられています。
    また、ER図やCRUDマトリクスについてや、
    要件定義の準備として企画内容を確認したり、
    システム全体像を描いたりなどといった話も少ないページの中にバランス良く盛り込まれています。

    ・要件とは注文であり、依頼事項(リクエスト)である
    ・自社で何を作れるか、技術が分かっていないと注文は受けられない
    ・”依頼者の目的を達成すること”がソフトウェア開発の目的
     依頼者の目的を達成できるのなら、要求とは違う代替案の提示もありえる
    ・依頼者は画面(UI)越しでしか確認できない。画面は大事
    ・企画書(目的、ゴール)を資料として明確にし、共有すべき
     依頼側と開発側でこの認識がブレると、手戻りが発生しやすく、完成したものが別物になりやすい
     当然、互いにとって理解できる企画書であるべき。開発者しか分からない資料は意味がない


    ■要望と要求と要件を分けて考える
    要望: システムによって叶えたい思い・未来像
    要求: 要望を叶えるために必要な能力や成果物
    要件: 要求を満たすために必要な条件

    要件定義が出来ているというのは、
    この「要望⇔要求⇔要件」が分割統治されていることが大切です。
    つまり、
    要件に落としこむまでに然るべき理由がそこに存在しているか、
    その要件でなければならない理由は語られているか、
    そういうことをチェックするには分割統治するしかないからです。

    やりたいことと、やらねばならない理由と、
    要求を満たすためにやらなあかんことが分けて考えられていないと、
    要求自体の間違いに気が付かないことになります。

    ■全てのステークホルダーを明確に
    要件定義はそのシステムに関わる「全ての」ステークホルダーの要求を
    可能な限り実現する必要がありますが、
    その全体像をこうまとめると簡単だよって絵がありました。これはわかりやすい。

    システムを中心とし、ステークホルダーでレベル1を作り、
    その要望をレベル2として書いているマインドマップのようなもの。

    そのシステムを使うことで別のステークホルダーの負担が増えたり、
    何かが犠牲になったりするということが、要件定義の過程で結構あります。
    大抵それが地雷になりますので、早めに地雷を摘むためにも全てのステークホルダーの要求をキチンと整理しましょう。

    ■システム化対象業務の設計ポイント
    全体図だけでは設計に移れませんので、
    ドリルダウンして実際の作業とシステムの関係を明確にしていく必要があります。
    羽生さんは「行動シナリオ」の作成を薦めています。
    下記の情報が整理された実際のお仕事の流れをまとめたもの。

    •その仕事を行う人(役割)
    •その仕事の判断・完了基準
    •その仕事の受け渡し先

    特に自分の仕事が終わった!と判断できる基準が最も大切。
    知りたいのは行動を決めるための判断基準。
    その基準を満たせない場合は例外処理やバリデーション対象になる。
    要件定義の時点でそこまで見ていく必要があります。また、下記の2つも考慮ポイントです。

    •差し戻される場合はどういう時か
    •やり直したい・中止したい場合はどうしているのか

    この2つも重要なので考慮して下さい。
    前者は例外処理やバリデーション、
    後者はCRUDが発生した場合に仕様として足りていないものがないかを確認できます。

    この設計したシナリオを元にユースケースが生まれて要件が見え、
    要件を満たすための仕様を考えるフェーズに移っていく。

    ■システム仕様検討はUIファーストで
    UIを作りながら作業に必要なデータを洗い出して構成をまとめ、
    仕事に必要な情報を定義してまとめていきます。

    最終的に、必要なのはレイアウトとアクションと生み出されるデータ。こ
    れが定義されていないとシステムの機能が正しいかどうか、ユーザーが判断できない。

    レイアウト: UI部品。タブ、コンボボックス、テキストボックス、ボタン、表など。
    アクション: クリック、スワイプ、キーダウンetcのUIのイベント。
    データ: その画面で最終的に作られる or 表示されるデータ。

    どの作業中に何をして欲しいかを明確にして、
    ユーザーが何を判断してどんな仕事を完了したいかを詰めていくのが良いと思います。
    これがこう出来ていればあなたのお仕事は完了できますよね〜っていうアプローチ。

    UI設計は入力系の画面から。
    まずは何を入れるかを先に決めないと。
    マスタメンテじゃなくて、行動シナリオの中で受け渡して流れていく情報を作って保存するための画面のUI設計からはじめて下さい。
    (いきなり帳票設計はしない。インプットが決まらないのに検索項目の話はしない)

    UIを決める→データを決める→そのデータを作り出すためのプロセスを決める、という流れ

    (目次)
    第1部 要件定義って何だろう?
    •Chapter-01 要件定義=要件を定義すること
    •Chapter-02 要件定義の基本的な流れ
    •Chapter-03 定義すべき要件の内訳
    •Chapter-04 3つの要素の定め方第2部 要件定義の詳細
    •Chapter-05 要件定義,その前に[準備編]
    •Chapter-06 企画を確認する
    •Chapter-07 全体像を描こう
    •Chapter-08 大まかに区分けしよう
    •Chapter-09 実装技術を決めよう
    •Chapter-10 実現したいことを整理整頓しよう[助走編]
    •Chapter-11 利用者の行動シナリオを書こう
    •Chapter-12 概念データモデルを作る[離陸編]
    •Chapter-13 UIを考えよう
    •Chapter-14 機能について考えよう
    •Chapter-15 データについて考えよう
    •Chapter-16 要件定義の仕上げ
    •Chapter-17 要件定義,その後に

  • 2015年4月刊。要件定義の基礎から実践例までがコンパクトにまとめられている稀有な本かも。◆【引用メモ】「操作性の統一」というお題目は耳に心地良いものです。しかし、不合理で非直感的で使い勝手の悪い操作性に統一されても困るのです。(p.120)◆要件定義における作成担当者の内部レビューとは何か。言い換えると、内部レビューの成果は何かというと想定問答集です。そして重要なのは、そのような想定問答が予測されるなら、その質問自体が発生しなくても済むように、資料自体に自明となるように手を加えることです。(p.163)

  • とても分かりやすい本だった。イラストがあったのも大きいと思うが、情報が整理されている感じがした。明日からでも実践出来る内容が満載で、今要件定義で困っている人にも役立つ。
    要件定義の準備が結構重くて、要件定義の中身はUI、機能、データという。これまで要件定義だと思っていたものが、要件定義の準備で、要件定義は半分基本設計みたいな感じがした。
    要件定義にまつわる他の本も読んでみるつもりなので、比較してみたい。

全22件中 1 - 10件を表示

プロフィール

1968年6月1日生まれ、大阪育ち。89年、桃山学院大学社会学部社会学科を中退後、2つのソフトウェア会社を経てアーサーアンダーセン・ビジネスコンサルティングに所属。その後、トレイダーズ証券株式会社とマネースクウェアジャパン株式会社の新規創業に参画。現在は、自身が設立した複数の会社の代表取締役などを務めながらストーリーデザイナー/IT経営コンサルタントとして活動中。2006年から11年まで、国立大学法人琉球大学の非常勤講師。著書に『はじめよう! 要件定義』『いきいきする仕事とやる気のつくり方』など多数。

はじめよう! 要件定義 ~ビギナーからベテランまでのその他の作品

羽生章洋の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
ジェイムズ・P・...
エリック・リース
ジャレド・ダイア...
伊賀 泰代
有効な右矢印 無効な右矢印

はじめよう! 要件定義 ~ビギナーからベテランまでを本棚に登録しているひと

ツイートする