2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

【要求定義の原則とプロセス】ワインバーグのシステム変革法(ソフトウェア文化を創る) - 15章

Posted at

記事要約

  • ソフトウェアと同じように、要件も「開発」するプロセスがある。
  • ソフトウェア開発プロセスと要件開発プロセスは相互にフィードバックを受ける
  • お客さんと開発エンジニアとの対話が大事。対話がなければエンジニアが要件に沿ったソフトウェアを作れない。

書籍情報

Amazonリンクで出典と代えさせていただきます。

注意

この記事は自らの読書体験を可視化するためのものです。

記事タイトル内にある本の内容を正確に描写することは保証しません。

練習問題の本文は、改行を変更した箇所もありますが、文章は完全に引用しております。
※ 問題解説は筆者の解釈です。本の中には書かれていません。

構成

タイトルの本全体および、章について自分なりのまとめを書いていきます。
その後、章末の「練習問題」を解きます。

本の概要

ソフトウェア開発における品質と生産性向上のための環境をどう作るかについて書かれたもの。

全4巻のシリーズ構成となっており、この本は4巻目。

前3巻までで解説した管理ツールとしての考え方を用いて、
組織に健全なエンジニアリングマネジメント(本では工学管理と称していた)を将来にわたり継続できるようにするための方法を述べている。

15章の概要

この章では、要求定義の原則について述べられている。これは、16章でプロセスを実施するための準備となる。

(p.302) ※太字は記事執筆者にて

ソフトウェア工学は、ある顧客もしくは顧客たちのために、あるものを構築し運用し保守する役目を担っている。要求定義(要件)は顧客との関係や対応のほんの一部分にすぎないが、大切な部分である

これがソフトウェア開発のすべてであると思う。ユーザのためにやることがソフトウェアに携わる者のすべて。

そういうわけで、要件は最初に確定するものじゃなくて、開発を進めるなかで相互にフィードバックを受けて進化するものだ。

(p.302)

ソフトウェアの第0法則:
ソフトウェアがまともに動作する必要が無ければ、他のどんな要件も満たすことができる。

「いやいやそんなの意味ねーだろ!」と思ったが、そういうものなのかも。
それほど「要件」というものは管理が難しいし、だが真剣にやらないとダメなものだ。

練習問題

問題1

「ウォーターフォール・モデル」や、「ラピッド・プロトタイピング・モデル」のようなさまざまなソフトウェアプロセスモデルが、どのように時間とともに乖離を狭めるかを示す図を描け。

問題解説

要件はソフトウェア開発が進むにつれて製品と乖離が狭まる」、と本章にあるので、具体的にどうなん?っていうのを聞いている。

自分の回答

ウォーターフォールモデルで考えた結果が以下。
image.png

問題2

要件原則のいくつかに違反したプロジェクトを想起せよ。その影響はどうだったか?そのプロジェクトはこうした影響をどのように補償しようとしたか?

問題解説

要件は最初から固定されてれば楽だが、そんなことは無い。変動が少なければそれだけ管理が楽だが、そんなプロジェクトに大した価値はない。

だいたい、ソフトウェア開発を舐めたクソな客が、「どんな家に住みたいか分からないけど、いい感じに作っといて。あ、ちなみに何人住むかはわからないから、以上」みたいなノリで言ってくる感じが満々。

自分の回答

仕様を決めるステークホルダーが顧客ではないプロジェクトがこんな感じだった。バカみたいに複雑なデータバリデーション仕様を決めておいて、超複雑なテストをやってしまい、想定の半分の機能しかリリースできなかった。

しかもリリースした機能も結局は「何のために作ったんだっけ?」という話になり、まるごと削除された。5000万円の工費がすべてムダ。

仕様策定からやりなおしになり、追加で1000万円使ってすべて作り直した。

問題3

プロトタイピングプロセスが要件乖離を狭めつづける収束的フィードバックをもたないとき、何が起こるか述べよ。できれば、読者自身の体験から例示せよ。開発を収束的にするために、そのプロセスに何ができるはずだったか?

問題解説

要件乖離を狭めないと、エンジニアが良かれと思ってどんどん機能を複雑にする傾向がある。

自分の回答

データ編集機能の要件定義をやるとき、コンフリクトが怖かったのでパターンをいくつも列挙した。でもそこに業務を知ってる人がいなかった。
コンフリクトが起きる可能性は、同時使用ユーザの数に大きく左右されるのに、ユーザビリティの考慮を業務を知らないエンジニア間で完結させた。

業務を知ってる人のフィードバックを受けていれば、複雑かつ全く使われることのない製品を作ることなどなかったのに。

問題4

誰かが、置き換えようとする古い事柄の経緯を十分尊重も配慮もせずに、何か新しいものを導入しようと無理押ししたような、読者の体験について述べよ。読者はその時どのように感じたか?どのように行動したか?読者自身この種の素人間違いを犯したことがあるか?他の人びとの反応はどうだったか?

問題解説

現行サービスへのリスペクトを持たずに取り替えると、当時の問題意識を失うぞ、という警告。

自分の回答

自分が自社サービスを作るときに、ちょうどオブジェクト指向を導入しようとした。一人で作ってたから他の人々の反応はわからなかったが、それまで作ってたモノリスがすべてぶち壊されて究極的に読みづらいソースコードになってしまった。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?