要件定義とか設計とか真面目に考えてみよう
画面設計とか外部設計とか、もうやめようよに対し色々意見をいただいた。感謝。
要点繰り返し
- 自分は「画面の見本を使ってフィーチャを抽出する」というやり方に反対はしてない。
- ただし、その「見本」が妙に具体的かつ詳細になってくると、本来フィーチャではないものまでフィーチャとして取り出してしまい、後続の工数が膨れちゃうよ、ということを警告しているのである。
- 「妙に具体的かつ詳細な見本」ってのは、世の人がいう「画面設計書」でしょ？
- なのでそんなのはやめちゃえ、ということ。
以下、頂いた意見に対しての感想などを。
家やマンションに例えない
「家やマンションは最初に完成像をみてもらい納得してもらう必要がある。システム開発も同じだ。」みたいな意見があった。
- 画面の見本があれば完成像を想像しやすくはなるけど、実際に動く見本があれば想像する必要はなくなる。
- むしろ、操作することで「紙芝居」ではわからなかった要件が浮かび上がることもある。
- 最初に紙芝居で完成像を固定させちゃうと、後から発生する改善要望は捨てられることになる。
→これってプロのやり方かね？
- マンションや家を建ててから「こんなんでどうでしょ」「だめです」「どっひゃ〜」とやりとりするのはお金がかかってしかたないので、模型やCGで確認する価値はある。
- ソフトウェアも、完成してから「こんなんでどうでしょ」「だめです」「どっひゃ〜」とやりとりする光景は過去にあった。でも、そうならないように工夫したのがAgileだ。
- 正確には「今回はこんなんでどうでしょ」「だめです」「(小さな)どっひゃ〜」「じゃあここを変えてください」というやりとりを繰り返しながら完成させていく。
→こちらのほうがプロのやり方でしょ...
人のせいにしない
- 「業務をわかっている人がいない」とか「技術をわかっている人がいない」とかいう言い訳をよく聞く。
- じゃあ「わかっている人が揃っていたら問題ないの？」と問い詰めたい。
- また何か別の理由を持ってきて「○○が足らない」とか言い出すだけなんじゃないの？
- 100%の能力を持った人が揃えば問題はないかもしれない。
- でもそんなプロジェクトはまず滅多にない。
- ほとんどのプロジェクトは平均的な人の集合なのである。
- 平均的な人達は平均的に間違いをおかす。
- そして平均的な人達は平均的な割合でのみ、その間違いを検知して修正できる。
- つまり、平均的なプロジェクトは必ず間違いを含んだまま進んでいく。
- それらの間違いが積もり重なり、最後の最後になって「どっひゃ〜」となるような事態につながらないようにするにはどうすればいいか。
- リスク制御を真面目に考えて実践していくのがAgileなのである。
最初から100点満点を狙わない
- 画面設計にこだわる人は、もしかしてシステムの状態は「未完成・完成」のどちらかでしかない、と思ってないか？
- 例えば「書籍の検索」を考えてみよう。
- 検索語にかかった書誌情報一覧を表示する。
- 検索語にかかった書誌情報一覧を頁分けして表示する。
- 検索語にかかった書誌情報一覧を頁分けして表示し、検索語だけ色を変えて表示する。
- もちろん三番目のストーリが完成状態なんだけど、とりあえずのフィーチャ確認段階では最初ので充分だろう。
- この「とりあえず」の段階でお客さんに使ってもらい、改善要望をもらっておくというのは重要だよね。
- そういう「段階的リリース」を考えると、「最初に画面ありき」の要件定義はつらいのですよ。
過去の成功体験にひたらない
- 「いや、そうはいっても今までのやり方でうまくいってきた」という人もいるでしょう。
- でも、本当はもっとうまいやり方があったのかもしれない。
- それを探求しないで「今までのやり方でいいじゃん」と納得しちゃうのはプロのやることじゃないよ。
