保険

システム開発の工数見積もりを行う場合、たいてい「保険」を入れることがある。ほとんどのプロジェクトの場合、思ったより工数がかかってしまうので、「保険」の意味で工数を割り増しして見積もりを提示しているのだ。

私も自分が見積もる際には、ある程度は理論的に見積もるが、その後顧客に提示する際には、営業サイドで2割から5割程度割りまして提示されることが多かったようだ。そして、それがたいていにおいて適正かもしくは足りないと言う状況に陥っていた。

システム開発を見積もる上で「保険」を入れることはある程度常識になっていて、それが許されることも多い気がする。しかし、その「保険」は本当の意味で「保険」として使用され、適切に機能しているのだろうか。

成果物の品質レベルはさまざまだ。

• 動くだけ。
• 同時アクセス、排他など一部不具合あるが、運用でカバー。
• ドキュメントは記載漏れが多い。何が書いてあるか不明。間違いまである。
• 再帰テストは不可能。テストをする場合は再度一からデータ作成、手動テストが必要。
• ソースコードは再利用、変更容易性まったく考慮されていない。
• クラス名がばらばら。小文字で始まるクラス名さえある。
• ログもまったく出力されていない。

こんなレベルでも動くソフトウエアは完成し、納品され、本番稼動することができている、そんな例もあるのだろう。もう少しよくなれば、

• クラス図とソースが整合性が取れていない。
• ドキュメントは信頼できるものと信頼できないものがあるが、おおむねドキュメントを見れば、システムを理解できる。
• 単体レベルでの再帰テストはできる。データ投入も含むため、自動再帰テストを流すと1日かかるが、それでも先日テストしたときには成功していた。
• ログはやたらに多く、必要なログがどこにあるかわかりにくい。

こういうレベルもある。

もちろん

• クラス図は適切に最新状態が維持されている。
• ドキュメントは適切に作成されている。
• ソースは再利用、独立性が高く、変更容易性、テストのしやすさもOK。
• テストケース、カバレッジ基準もクリア。再帰テストも自動化。
• 運用性、メンテナンス性も高い。

こんなレベルもあるだろう。システム開発着手時は最高を目指すが、最終的には、最低限のレベルしか満たせなかった、とか、リリースすらできず納期が遅れ赤字になることもある。

開発者はまず、最高を目指して開発に着手するが、これが実は間違いな気がする。まずは、最低限の機能を満たす。(通常のイテレーションとは違うレベル)そして、期間が短く実現できたら、少しレベルを上げる。(リファクタリング、テスト見直し、ドキュメンテーションなど)

つまり、

• 最低限の実装、テスト
• 余裕があれば、レベルアップ
• 余裕があれば、レベルアップ
• 余裕があれば....

こんな感じで進むべきなんじゃないだろうか。最初から最高を目指すため、最初は良いのだが、後で苦労するのだ。

たとえば、昨日の日記で「HTMLのタグは小文字に統一する。」などは、このレベルアップで行えばよいのだ。最低限の実装でよければ、必要が無い。「まだ余裕があるから今のうちに対応しましょう。そのほうが全体でコストが下げられます。」というのは、納期以内に納品できる場合にのみ有効なことで、まだ出来上がっていない段階で余計なリスクをおい込むことは避けるべきなのだ。

まずは、最低レベルの実現、それからレベルアップをイテレーティブに。この考えをプロジェクトの価値としてメンバ全員が認識すれば、かなりの確実で赤字プロジェクトになることはないだろう。

これは性善説にのっとっている、と批判されるかもしれない。つまり、最低限の実装、テストが終了したら、後の時間は顧客に内緒で他の作業をし、最終的に、「ここまでしかできませんでした。」というチームが出るのではないか、ということだ。しかし、システム開発の目的は「顧客満足度のUP」だと考えるプロジェクトが多い現実では、可能な限りレベルアップをするのが常だろう。

まずは最低レベルの実現をする。そして余った時間が「保険」として有効にレベルアップに利用できるのである。