システムの設計図は安全に航海するための海図と同じという話

ネットでプログラムのことを調べていると、「仕様書とは海図のようなもので・・・」という文章に出くわしました。
このことについて思ったことがあるので書いてみることにします。

今回書きたいことは以下の2つです。
1つは、仕様変えようとしたら、開発側からそんなに時間や金がかかるはずないだろという提案がくるのはなぜか。
2つは、スモールスタートが叫ばれるのはなぜか。(これは次回書きます)

まず前提として、仕様書とはシステムの設計図のことです。
建物を建てる際にも設計図を元に職人の方々が建物を実際に作るように、
システムもまずは仕様書を作り、そこからシステムをプログラマーと呼ばれる方々が作ります。
システム製作者はこの仕様書と言われる海図を元に、目的地(=完成品)を目指して船をこぎだすわけです。

以前こんな記事をFacebookで紹介しました。
システム技術者が「ちょっと変えるだけでしょ?」という、ユーザーからの注文に辟易する理由。
「ちょっと変えるだけでしょ?」という言葉は一種の呪いの言葉、パワーワード・キルのようなものでして、ユーザー側と開発側の断絶を表す、一つの端的な象徴だと言っていいと思います。
要件的には、確かに「ちょっと変えるだけ」なんです。
・webページの文字のレイアウトを「ちょっと変えたい」
・帳票に表示されている文言を「ちょっと変えたい」
・レポートの一つの項目の数式を「ちょっと変えたい」
(中略)
「Excelだったら5秒じゃん」という言葉も、私実際に、この耳で聞いたことがあります。
ただ、システム開発をする側から見ると、「ちょっと変えるだけでしょ?」という言葉には多種多様な罠が含まれているんです。
細かくはリンク先を見ていただければありがたいのですが、
ちょっとした仕様変更のように見えても、内実そうなっていない状態が多いというところです。
仕様書は設計図でもあるので、家を建ててから設計図ちょっと変えたいんですけど、というのが難しいように、仕様をちょっと変えるのもなかなか厳しいときもあるのである。

海図に例えるとすれば、ちょっと変えるというのは、
危険な海流の記載漏れがありました、といっているようなものではないかなと思います。
仕様変更、つまり見落としに気づいたらどうするか?
まずはそのまま進んで大丈夫か考え、だめなら安全な別のルートを探し、
新しいルートによって必要なもの、仮に遠回りするとしたら燃料がさらに必要かもしれないなど考えなくてはなりません。

ちょっと変えるの一言でこれだけを瞬時にしなくてはいけないので、
これがあまりにも多いと辟易としてしまうのです。
だからこそ、システムエンジニアと呼ばれる人たちは、
しつこいくらい、本当にこの仕様でいいのか、ということをお客様に確認します。
そうでないと、海に出たときに難破してしまうかもしれないからです。

システム作成するときに、
「ここまで細かくしなきゃいけないの」「いい感じに作っておいてよ」
「なんでちょっと変更するだけなのにそんなに時間かかるんだよ」と言われる話はよく聞きますが、
命預かっているものとして、そこに妥協するわけにはいかないということをご理解いただければと思います。

コメント

このブログの人気の投稿

裏の顔診断やってみた

SNS炎上の火種が増えたのではなく煙が見えやすくなっただけでは?

【読書日記】BG、あるいは死せるカイニス