システム開発の見積もりは超適当という話

いつも首がヨレヨレのTシャツを着ている、ユゲタです。 ここ数年、服を購入しておらず、毎日同じものを着回している状態です。 自宅で仕事をするようになると、こんな風になっちゃうんですね。 ところで、非常に楽しみにしていたゲームソフトの発売日が待ち遠しい中、開発が延期して、発売日が半年も遅くなってしまって悲しい思いをしたことがある人も多いと思いますが、 「ナニ開発遅らせてんねん！」とか、「チンタラ開発してんなや！！！」などと野次ってはいけません。 開発遅延は必ず起きる事象であると認識しましょう。 無理して開発の締切に合わせるような進行をすると、「セブン○イ」のような不具合の温床みたいな事になりますからね。

開発の見積もりが甘いんではないか？という疑い

ゲームだけに限らず、IT企業では、必ずIT開発が行われていて、その中の開発部門の人たちが日々寿命を削りながら、仕様と研究開発とより美しくコーディングするセンスを磨きながら頑張っています。 そもそも開発の最初に必ず期限の見積もりが発生して、それをもとに、開発終了を定め、製品であれば発売日、ツールであれば、使用開始日などが算出されます。 ゲームに関して言うと、ある程度開発が進んだ（大体5合目）ぐらいの段階で、発売日を世の中に公表するため、デッド日がより明確になってしまいます。 そもそも、開発の最初で工程の見積もりを行うやり方が悪いのではないかという疑いについて考えてみると・・・ 実際に開発を始める前の見積もりという段階では、よほど問題がなく、懸念点が無い状態でない限り、正確な見積もりというのは、皆無であると言ってもいいでしょう。 既製品のプラモデルを作っているわけではなく、どの開発もある程度の新規要素やこれまでにない何かしらの要素を持っているため、開発をするのであるから、実際に開発をしてみないと分からないという部分が存在するのは致し方ないでしょう。 もちろん、それも踏まえて「バッファ」という魔法を見積もり担当者は埋め込むのですが、かの有名な「パーキンソンの法則」の為、開発員は決められた開発末日キッチリ終わるように、工程スケジュールをセットし、気持ちもそこに終わるように調整します。 あまり大声では言えませんが、日某ＴＶ局の夏休み終わりぐらいにやる24時間テレビのマラソンで、放送終了時間ギリギリにゴールするように調整する間隔に似ています。 本当であれば、夕方ぐらいに到着して、ゆっくりと休みたいというランナーの本音を無視した、スケジューリングに、世の中の人は感動していると考えるとアホ臭いですが、開発員も非常にこれに似た心境に陥ります。 なのでバッファはあって無いようなものであるという事実をまず理解しましょう。 そすうると、新規開発の為の研究・調査部分に思いの外時間が掛かってしまうと、基本的に開発は押してしまうというトコロテン状態になります。 スケジュールは押し出されてしまうのです。

早く終える開発を見たことが無い

僕の経験では、長期開発をする場合に、例えば1年の開発を行う場合に、2ヶ月手前で開発が完了したというケースはまず見たことがありません。 必ず1ヶ月前になると、ラストスパートと言いながら、会社に泊まり込みの合宿生活がはじまり、1週間前になると、お坊さんの修行のごとく、寝ない生活が始まります。 開発員のストレス量が多いのももしかするとこういう生活を余儀なくされるからなのだと気が付きますよね。 何故開発は早く終えることができないのでしょう？ パーキンソンの法則の他に、組織問題も含まれています。 大規模開発は、1人で行っているケースは少なく、複数人で分担して行うため、1人が早くスケジュールを終えても、他の人と結合しないとチェックができないため、必ず全員が同じ進行を行わなければいけません。 ここで分かるのは、結合して初めて発見される不具合があると、当たり前のようにスケジュール外の作業が発生します。 こうして、チーム開発というのは、設定されたスケジュールよりも確実に遅れるという性質があります。

見積もりに正確性は有り得ない

開発は確実に遅れるという事実がわかれば、見積もりに正確性を求めても無駄という事がおわかりでしょうか？ アジャイル開発やら、ウォーターフォール開発などのように、いかにもスケジュールを守るためのチーム構成、開発工程を組み上げても、スケジュールは遅れて当たり前というのが現実なんですね。 そんななか、見積もりに正確性が無いのかというと、実は超適当であると考えてもいいかもしれません。 もちろん、ゴミ見積もりを作っても仕方がないので、ようするに開発発注者が納得する金額と納期があれば、見積もりの内容などは後ほどなんとでも変わってくるし、気前のいいクライアントであれば、開発中に発生した問題点は別開発として見積もりを追加したり作り直したりもできる事もあります。 いったい、見積もりの正確性ってなんなんでしょうね。 お金を出す人は、できるだけ安く開発を行い製品やツールを作りたいのだろうが、開発側は、これで売上を立てているため、納期よりもクオリティに力を入れたいはず、実際は、クオリティが二の次になるケースのなんと多いことやら。 そもそも、見積もりを開発員が書いているケースも少ないのかもしれませんけどね。

システムの見積精度を上げたい人へ

下記サイトでは、品質管理に関するテストや工程などを解説してくれています。 https://sqripts.com/