仕様変更の常識(1)-無料の仕様変更は存在しない

2018年8月21日火曜日

システム開発

t f B! P L
 情技師(ITエンジニア)とって常識でも、非情技(非ITエンジニア)は知らないもの代表格として「仕様変更の常識」がある。

 システム発注の経験や知識が無いユーザーはシステム開発外注の際、間違った要求を出し、ITベンダーとトラブルに発展し損害賠償支払わされた挙げ句システム化に失敗するという不幸に会う。

 納期の定まったウォーターフォール開発の場合、理論的には仕様変更は不可能になる。現実にはSIerはある程度余剰期間と余剰費用を計上しているのである程度の仕様変更は受け入れる。
 しかし、これは余剰期間と余剰費用を一切計上することなく、必要最小限の費用だけでシステム開発を受託したら「仕様変更は一切できない」ということだ。
 もし受託開発業者が発注元の要求のままに仕様変更を笑顔で引き受けてくれるのなら、予め多くの余剰期間と余剰費用を請求されているということだ。旨い話は無いのだ。

 アジャイル開発だと仕様変更が出来るので良さそうに見えるが、アジャイルの日本語は「反復開発」であり、その名の通り「何度も作り直す」開発手法である。
 ユーザーが要件定義を確定できない時、実際に動くソフトウェアを作りユーザーに試して貰い、そのフィードバックを受けて改造を繰り返す。
 ある機能についてユーザーが「あーでもない、こーでもない」と悩み続け、何度も何度も作り替えればその分コストと時間が積み上がる。それを負担するのはユーザーである。 純粋にコスト効率の良さで考えるとアジャイル開発は安いものではない。訂正が利くのが良いのだが訂正のコストはしっかり請求される。当たり前だ。

 非情技の人々はシステム外注における「仕様変更の常識」を理解しておいた方が良い。正しい発注の仕方を発注元が把握しておけば成功確率は上がる。
 多くの発注元は外注先が「良い業者」か「悪い業者」かばかりに眼を向けるが「自分が正しい発注をしているかどうか」には目もくれない。

 社内システムの開発をほぼ全て失敗している会社で開発を手伝ったことがあるが、開発工程がダメでウォーターフォールなのかアジャイルなのかも判然としないデタラメなマネジメントをしていて「これじゃ失敗するのは当然じゃないか」と思った。この会社は早々に撤退した。

 外注先が「良い業者」か「悪い業者」かを考える前に自分達の「発注の仕方は正しいか」を確認した方が良い。
 「正しい発注」なら「良い業者」に発注すればは成功する。
 「間違った発注」なら「良い業者」に発注しても失敗する。
 「悪い業者」については一々言及しない。

無料の仕様変更は存在しない


 SIer業者の多くがある程度の仕様変更を受け入れるので発注元企業が「軽度の仕様変更は無料だ」と思っている。「全ての仕様変更は無料だ」と思っている悪質な企業もある。
 しかし現実には「軽度の仕様変更」であっても「無料」はあり得ない。それは予め「軽度の仕様変更」分の費用を既に払っているから受け入れられているだけだ。
 SIer企業は発注元企業をよく観察している。そして仕様変更リスクの高そうな顧客には初めからリスク費用を上積みして費用を請求する。
 仕様変更リスクの高そうな顧客は以下のような発注元だ。
1)要件定義を明確に出来ない。又は書けない。
2)業務について十分に説明できない。(社内の協力を取れない。業務担当者が非協力的)
3)部門間で言い分が違う。仲が悪い。意見が統一できない。
4)基本的言行が矛盾している。或いは曖昧である。
5)経営者など「決裁権」を持った人が発注を知らない。興味が無い。
6)バカ(論理や数に弱い)

4)と6)は「地雷」なので断られるが、他のはコストと期間を大きく余分に請求される。

 もし仕様変更しなければ顧客が損をする関係だ。この関係を私はあまり健全だと思わない。
 むしろ、「全ての仕様変更は有料です」という前提で「仕様変更した分だけ追加費用を請求します」という取引関係の方が健全だと思う。これなら仕様変更しなければ安く開発を発注できるからだ。

 通常、システム開発は見積額の三割程度を無条件に割り増しする。期間も同様だ。
 これは「必ず使う」から割り増しにしている。
 システムやソフトウェア開発は「作ってみたら予想と違っていた」という事態が必ずある。三割というのはその事態への備えであり、ほぼ必ず使うことになる。
 従ってこの三割はリスク費用ではなく正当な費用である。

 リスク費用は相手によって二割から十割まで様々である。

 売り手と買い手の力関係では通常は買い手の方が強い。この力関係を悪用しITベンダーに無料で仕様変更を呑ませる悪質な発注元は多い。
 しかしこの場合も「無料で仕様変更」は出来ていない。
 先に説明した「リスク費用」が含まれている点もあるが、それだけでは無い。
 予想を超えてリスク費用が嵩めば当然対策をするものだ。
 ソフトウェア開発は通常、開発して終わりではなく、運用費用が掛かる。また、どんな顧客も最初のリリースバージョンで満足することは無い。必ず追加案件がある。
 リスクで赤字になった案件は運用や次の追加案件でリスク費用を積み増しして費用を回収するのだ。
 初めての取引で無理矢理無料の仕様変更を呑ませて他の会社に移ってしまうような輩もいるが、そういうのは移った先でリスク案件になっているものだ。
 だいたい開発元に運用や追加案件を依頼しない時点で怪しいものだ。こういうのは最初からリスク費用を多めに積んでおくものだ。

 リスク費用を安く済ませたいのなら、次のようにするべきだ。
1)初めから「仕様変更には追加費用を払う、リスケも応じる」と宣言する。(当然嘘では駄目)
2)明確な要件定義を書く。出来なければITコンサルを雇う。
3)業務担当者をシステム開発に参加させる。経営側も連絡が取れるようにする。
4)部門間(社内)の意見を統一しておく。
5)経営者など「決裁権」を持った人の責任で発注する。
6)ある程度「良い業者」なら継続取引をする。(長く付き合うとコストは安くなる)

 「ウォーターフォールでは仕様変更は出来ない」と言っても現実のシステム開発には仕様変更は必要だ。発注元企業も「システム開発に仕様変更は必要だ」という事実と「仕様変更には必ずコストと時間が必要だ」という真理を受け入れるべきだ。
 その上で「仕様変更は必ず必要なので依頼する。その時は必ず追加コストを払いリスケに応じる」と最初に確約すべきだ。
 それから、システム導入計画を立てる時、初めから「仕様変更による遅れ」分の期間を余白期間として確保しておくべきだ。ギリギリの計画など失敗するに決まっているだろ。
 少なくともギリギリの計画の「三割増し」可能なら「五割増し」の計画を立てるべきだ。ギリギリの計画立てている時点で「計画性に著しく欠けている」のだ。


 次回は仕様変更の性質と、「正しい仕様変更はどうするべきか」解説したい。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ