TMD45'β'LOG!!!

Life is Beta-ful.

『はじめよう! 要件定義』を読んだ

知人のフリーランス エンジニアの方が推していて、著者を招いて小規模の勉強会をやったという話を聞いて興味を持った。

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

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

(ひさびさに1冊読了した…わたくしの活字離れがひどい。)

どんな本

  • 要件定義とは
  • 要件定義で得られるべき成果物とは
  • あとがきより
    • 本書の肝をひと言で言うなら「画面遷移図を描こう」になります
    • 画面と画面の間にイベントを機能を図示する

とにかく頭からおわりまで通しで読むのがいい本。 「エンジニアにしか読めない」「ディレクターじゃないとわからない」という本ではない。

全体の感想

  • エンジニアが「これだけ揃っていればすぐにとりかかれるぞ!」と思えるレベルまで要件を固めて見える化する方法
    • とは言え、エンジニアに話持ってくるまえにここまでやってこいや!という話ではない
    • 企画者もエンジニアも含めてプロジェクト全体でゴールを見えるようにする
  • 「企画が要件に落とし込めるレベルでない」状況から始まり、「データベース設計まで行う」ところまで流れで書かれている
    • 頭からおわりまで流して読むのをおすすめする
    • セキュリティ(権限管理まわり)が最後に書かれているのはちょっと気になった。もっと早くてもいいのでは?
  • 忘れられがちなことが良くピックアップされている
  • 企画・営業、ディレクター、(マネージャー的な意味での)SE、エンジニアが共通の言葉で話すというのがどういうことか、この本の語り口からわかると思った
    • このくらいの丁寧さでとか、繰り返し出てくる言葉を省略しないとか
  • 実態を良く捉えていて理想論にならないように工夫されていると思った

特に「!」と思った記述

Capter-2

要望・要求・要件の違い

  • 「要望」を出す
  • 「要望」を「要求」にする
  • 「要求」を検討する
  • 代替案を考えて提案する
  • 提案への検討から再要求を繰り返し
  • 合意して「要件」にする

Capter-3, 4

  • プログラマがソフトウェアを作るには「UI」「機能」「データ」が必要
  • 「何はともあれ UI」

Capter-6

  • ゴールを確認する
  • 「それを使って5分以内に手際よくプロジェクトの紹介を前提知識のない人にできる」資料
  • プロジェクト計画書からマネジメント向けのものを除外したサマリー
    • 逐一「この程度でいい」の例が上がっているのでわかりやすい

Capter-7〜16

すべて終えて出来上がる成果物

  • 企画書
  • 全体像(オーバービュー)
  • 利用する実装技術
  • 実現したいこと一覧(要求一覧)
  • 行動シナリオ一覧
  • 行動シナリオ
  • ワークセット一覧
  • 概念データモデル
  • ラフイメージまたはモックアップ
  • 画面遷移図
  • 項目の説明
  • 機能の入出力定義
  • 機能の処理定義
  • 統合ERD

Capter-7

  • 利用者としてのシステム管理者を忘れずに含める
  • 連携するシステムも忘れずに書く

Capter-12

  • p.92 Column
    • ありきたりの、通りいっぺんのその辺のよくある事例を転がしたような前例主義的な行動シナリオしか浮かばない状態であれば、いっそ何もやらないほうが傷は浅くて済むんじゃないか。

Capter-13

  • p.120 Column 共通化について

Capter-16

  • 精度を高める
    • ここまで作成してきたものを見直すと、不足してたものが見えてくる
    • 面倒くさがらずに、不足していたワークセットを追加して、同じ手順で要件を決める
    • 不足だけじゃなくて全体を見渡したら変えたほうが良い部分も見えてくるかも
    • とにかく「急がば回れ」面倒くさがらない

所感

なんか読みながら考えたこと

  • 「不要な機能をそぎ落として重要なものから素早く作る」というのはわかる
    • けどそれを検討できる「要望」や「要求」はきちんと一覧化されているか?
    • 不要なもの、のまえに何が欲しいって話だったっけ?
  • アジャイルにドキュメントは不要」という間違った論に傾いていってないか?
    • そう思ってるひとはいないと思うけど、実際ちゃんと必要なものはドキュメント化されているか
    • 必要なものってなに?
  • この本にあるとおりの成果物(ドキュメント)をきっちり作りましょう、という話ではない
    • 要件定義はドキュメントを作るのが目的ではない
    • 要件を定義して見える化する、その成果物がドキュメントになっているだけ
  • 「要望」からダイレクトにプログラミングに移れるのは本当にいいことなのか?
    • ほんとに何も考えずに作り始めることはないけど
    • 「要望」から「要求」を読み取る
      • そこをエンジニアがやっている気がする(これは自意識過剰かも)
      • その過程で「要望」を出した人に検討に参加してもらっていない気がする
      • あるいは「要求」から検討したことを「合意」してもらっていないのでは
      • 「信じてるから、やっちゃって」っていうのは本当にいいの?
      • 検討とか合意とかするために必要な「見えるもの」がある?

▲ ページトップへ移動