なぜ仕様変更が開発者にとって大変なのか考えてみた

先日、コデアルさんのインタビューで「受託開発から自社サービス開発に転換できた」話を取り上げていただいた旨を書きましたが、受託開発って本当にうまくいかないんですよね。

先日も、旭川医大とNTT東さんの裁判の件は、IT業界では話題になってましたね。

失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/092501136/?rt=nocnt

 

旭川医大だけにかかわらず、受託開発にまつわる大体の問題が、「仕様変更」によるものなのですが、これに対する解決ってないんですよね。

発注側:「ちょっとのことなんでしょ?なんでやってくれないの」

この繰り返しなんですよね。

あと、発注側が完璧を求めすぎる。

プログラムの世界には完璧はないんですよ。

この点が、なかなか理解して頂けないんですが。

 

どうも、プログラマーの仕事を職人の手仕事と同じようにみられているように思いますが

「プログラマーが手を抜かずにちゃんとやれば、完璧にできるはず。だから、バグは手抜きとか力不足が理由。」

という理屈が発注側さんに往々にしてありますね。

そうではないんですよ。

 

プログラムという製品が複雑すぎるのです。

「いや、簡単でしょ。もし〇〇したら〇〇するって書いていけばいいんでしょ」

っていう人がいます。

いやいやいや。

 

まー、問題をシンプルにするために、仮に

「もし〇〇したら〇〇する」

だけがプログラミングだけだとしよう。

例えば

「もしメールが届いたら自動返信する」

とかだったら、簡単かもしれない。

しかし、それだけのプログラムは何の役にも立たない。

 

現実世界で起こるような複雑な処理をしてるわけです。

例えば、朝起きてから会社に行ってお昼ご飯までの

「もし〇〇したら〇〇」

という分岐をすべて書いてみてください。下記のような感じです。

「朝7時半に目覚ましがなって起床

(目覚ましが鳴った時)             (鳴らなかった時)

↓                             ↓

7:35  パンがあるかないか調べる         寝ている
(パンがある)    (パンがない)              ↓

↓               ↓             ↓

7:45 パンを食べる   ご飯があるか調べる      寝ている

この後延々といろいろと続く…

とっても複雑になってしまいますよね。

で、それを確認して、

「もう間違いない?これで大丈夫?」

と何度もテストしてみます。

 

仕様変更というのは、そのあとで

「んー、7時半に起きるとやっぱり眠いから、7時45分に起きることにしよう」

と変更が重なっていくという感じです。

すると、上記の分岐のタイムラインをほぼ書き直さないといけない。やることも時間がかかることをやめないといけない。

ぐちゃぐちゃになっちゃうわけですよね。

 

もちろん、これはわかりやすくシンプルに伝えたかったサンプルなので、実際はこんなんではありません。

if文だけでこれなんで、実際はもっと複雑なんです。

 

「でも、それって自社サービスでも受託でも一緒でしょ」

って声があるかもしれませんが、これは90度ぐらい違います。

受託だと、否応なしに天の声として降ってくる。

自社サービスだと、そこはコントロール可能な範囲で、理由も飲み込める。

なので、自社サービスのほうがずっと楽なのです。

 

2 thoughts on なぜ仕様変更が開発者にとって大変なのか考えてみた

  1. 分かりやすい説明、ありがとう(^0^)
    トーシロでもなんとなく分かりました!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です