なぜウォーターフォール型の受託開発では終盤に問題が起きがちなのか
結論から言うと
「システムの発注者が受注者に対して設計段階で適切なフィードバックをできていない」
から。
はじめに
これは個人的な経験に基づく意見であり、観測範囲はすごく狭く、広範囲の調査を行ったものではありません。あくまで個人的にはこうだったから、こうなんじゃないかなという仮説とポジショントークてんこもりの話です。
前提とか背景とか
私の経験では受託開発の受託側で仕様の検討から実装・テストまで担当することが比較的多く、また、システム開発にあまり詳しくない発注者が、実際にシステムの開発を行う受注者に発注する開発スタイルが多かったです。
また、開発体制などの都合からまっとうなアジャイル開発やスクラム、テスト駆動開発をやったことがありません。
また、この記事での機能仕様書とは、システムの振る舞い=どういう入力があって、どのように処理されて、どのように出力されるかを定義したものであり、Joel on softwareで述べられているところの機能仕様書を想定しています。
場所によっては外部設計などとよばれているかもしれません。
影響を受けているもの
リーンソフトウェア開発の作りすぎの無駄を極力避けるという考え方に、Joel on Softwareの機能仕様書の考え方を混ぜた感じと言ったらいいんでしょうか。
ろくに仕様の検討や設計もせずに先に実装を進めてしまうと、間違って作ってしまった実装やテストの修正コストが無駄になり、何より貴重な時間というリソースを浪費してしまうので、分かる範囲で仕様の検討や設計を行ってから実装しよう。 仕様書の修正コストは実装の修正コストよりも低いからなるべくそこで問題を見つけよう。 仕様書にはシステムがどのように振る舞うか、入力に対してシステムがどのような反応をするか、具体的に、詳細に、網羅的に記述しよう。
そんな考えです。
これまでの経験をふりかえる
私がやってきた仕事の範囲でいうと、発注者側からまともな機能仕様書をもらったことも、発注者の代わりに機能仕様書を作成してその仕様に対して文言・フォーマット・体裁以外で設計に関わる重要なフィードバックをもらった事も、残念ながらほとんどなかった。
これは別に「私の機能仕様書作成能力が高いからフィードバックが無かった」とかそんな理由ではない。 他人が書いた機能仕様書であれば、多かれ少なかれ考えが違う部分はあるはずで、ここはこうしてほしいとか、そういうフィードバックは少なからずあったはずだ。
私の機能仕様書作成能力が低くて、発注者が読んでも分からなかったからフィードバックが無かった？ 別に分からないなら分からないでそのことをフィードバックすればいい話だ。
だが、そういったシステム開発を行う上で重要なフィードバックはほとんどもらったことがなかった。 20年ほど前にウォーターフォール型の開発をした時もそうだったし、最近ウォーターフォール型の開発をしたお客さんもそうだった。
ウォーターフォールと修正コスト
一般的なウォーターフォール
一般的なウォーターフォール型の開発はこんな感じ。
バグの修正コスト
で、設計時の問題が後工程になるほど修正コストは指数関数的に跳ね上がる。
http://www.jaspic.org/event/2009/SPIJapan/keynote/SJ9keynote.pdf
図は2009年のもので、オンラインでアップデートが当たり前になった現在の状況はどうなっているか不明だけど、それでも稼働中のシステムの修正には注意と慎重さが必要なので、そのまま利用できると思っている。
この修正コストをウォーターフォールの図に反映するとこうなる。
本来のウォーターフォール
本来のウォーターフォールでは、開発の各工程で見つけた問題を前の段階にフィードバックする前提があったとか無かったとか。
うん、適切にフィードバックがあれば、バグの修正コストの問題が解決できそうですね。 適切にフィードバックがあれば。
でも、なんで今になってもいつもシステム開発の終盤になってから重大な問題が見つかっているのか？ バグの原因をたどっていくと、仕様の検討不足や考慮漏れが多いのはなぜなのか？ 仕様書のレビューで平仄やフォーマットの指摘が多めになり、設計に関わる部分でのまともなフィードバックが少ないのはなぜなのか？
ウォーターフォールの工程が会社をまたがって分断されている
まず、ウォーターフォールの工程が会社をまたがっており、分断されていることが原因の1つに挙げられる。 契約や納品が絡んでくると、前工程の成果物が間違っていたから修正するというのは難しくなる。 問題がみつかっても、「すでに納品しちゃってるし」「修正するとやり直しが手間だし」「原因究明の報告書を書かないとならんし」みたいな感じで適切なフィードバックがしにくくなる。
本来のウォーターフォール開発では各工程を会社をまたいで行う前提はなかったんじゃないか？
システムの発注者が機能仕様書を読めないのではないか？
会社間をまたぐのが多少手間でも、納品前であればフィードバックはできるはず。 しかしそれすらできていないのはなぜか？ もしかして、発注者が書いてもらった機能仕様書を読めていないのではないか？
本来のウォーターフォール開発が提案された時期、大昔のシステム開発は組織内で行うものであり、システム開発に詳しい発注者が仕様を決めるものであり、その前提だったのではないか？
一方で、現代の日本においてはシステムに詳しくない発注者がシステムの開発を依頼するパターンが多いのではないか？
だとすると、システムの発注者がシステムの受注者に機能仕様書を作成してもらったところで、機能仕様書の内容を読み込めず、そのためレビューでは設計に関わる指摘よりもドキュメントの平仄やフォーマットの指摘が多くなり、問題が後工程まで残存し、実際に受け入れ段階になって動かしてみて初めて問題に気づくのではないか？
ではどうするか？
システムの発注者が機能仕様書を読めない、仕様のレビューでフィードバックもできないのだとしたら、根本的に開発プロセスを変える必要がある。
いくらちゃんとした機能仕様書を書いても受け入れテストのときに「思ってたんと違う」をやられて無駄だから、先に動くものを作って確認してもらおうぜっていうアジャイル的開発スタイルにするしかないし、そのスタイルが流行るのもわかる。
しかし、発注側にシステム開発の経験が少ない場合、こういったアジャイル的開発スタイルを利用しても開発コストは減らないし、システム全体の完成時期も早くならない。逆に前工程での無駄を削減できない分開発コストは増えるし、システム全体の完成時期も伸びる。 とりあえず動いているシステムだけは手に入ることだけが救いだ。
結局、先に動くものを作って確認してもらおうぜっていうスタイルであっても発注者側の力量を上げないと解決しない問題なのではないか？
理想的には
- 実際に作って動かして確認する部分と、機能仕様書を先に作成して開発の無駄を削減する部分を分けること
- システム発注者が機能仕様書をレビューできること
- システム発注者が機能仕様書をレビューできないのであれば、その分増える開発コストを負担すること。
システム発注者に言いたいこと
いくらシステム開発を依頼して作ってもらっているとはいえ、どういうシステムを作って欲しいかは依頼者が決めなければなりません。仕様を提案してもらったり、他人に書いてもらってもいいですが、その仕様をレビューしてフィードバックを行う責任は発注者側にあります。
この世の中にまだ存在していないものを作ろうとしているのですから、「全部おまかせしますからいい感じで」では本当にほしいシステム、役に立つシステムは手に入らないでしょう。
具体的には
- あなたがほしいと思っているシステムは、まだこの世には存在しておらず、実現可能な仕様として文書化され、網羅されていなければ作ることができません。まずそのような仕様書があれば出してください。
- そのような仕様書がなく他人に書いてもらうのなら、仕様書を書いてもらうために必要な打ち合わせの分のお金もちゃんと払ってください。
- 他人の時間と頭脳は無償のリソースではありません。
- また書いてもらった仕様書のレビューを行い、自分がほしいと思っているシステムと一致しているかの判断と、設計への具体的なフィードバックが必要です。
- 以上の全てができないのであれば、実際に動くものを作ってもらって、それからフィードバックをかけるしかありません。そのせいでよけいにかかる実装やテストなどの時間的、金銭的コストはあなたが負担してください。
最後に
こういう事を書いてますが、 「仕様を誰かに決めてもらって、決まったモノをそのまま作りたい」 という考えではなく、
- 自分で良い仕様や適切な仕様を考えたり、提案したりしたいけど、それを無償でやらせられると商売あがったりなので、他人の時間と頭脳に金をちゃんと払え。
- 設計でなるべく品質を向上させて、バグが後工程に流れることで発生する無駄なコストを削減したい。
- いちいち作ったあとで間違いだったと気づくのは無駄なので、問題になりそうなところは先に文書という形で明確化し同意をとっておく。
やってみなければ分からない部分はもちろんあるけど、実際に作る前に机上で検討することで削減できるコストもある。 ならば、それぞれを区別して無駄を少なく開発できればいいな。 そういう感じ。
