ITの世界で何かを作るとき、大きく分けて二つの方法がある。
・要件定義をしっかりやって設計を作る。設計に基づいて実装する。実装がちゃんと動くかテストを行う。すべてのテストを通過したらリリースする。いわゆるウォーターフォール型の考え方。
・要件定義はある程度大まかに行い、設計・実装を素早く行う。テストを行い不満点や要望を吸い上げ、新しい要件や修正点を洗い出し、再度設計・実装を行う。最終的に満足が得られる状態を確認したら、リリースする。スパイラル型とも呼ばれる。
特にインフラの分野で働いているとわかるが後者の方法は特に有効だ。なぜなら、顧客が自分の要望を実装していない段階で１００％言語化できている場合が少ないからだ。実装時に、こうしてほしいああしてほしいが頻出する。え、それって、当初そんなこと言ってなかったよね。そんなことを言っていたら仕事にならないのだ。
また、試験環境もなく、机上で設計しなければいけない場合も多い。本番環境と全く同じ開発環境を用意しているシステムは少数派だ。お金もかかるし、開発環境があってももっとスモールだし冗長化構成も省略している場合も多い。結局はお金に返ってくるので、現実解としてそのようになる。この状況で後戻りできないウォーターフォール型では散々要件定義や設計時に議論したとしても、実際実装してみたらいろいろと想定外がわかり、初めからやり直すことになる。手戻りは工数のロスと捉えられるために効率も悪い。散々ドキュメントも整備した挙句の作り直しになる。
したがって、上流は目的の確認など曖昧にしておいて、ある程度の手戻りは覚悟しておく。だからドキュメントもある程度曖昧にしておくし、詳細に仕上げるのは全部出来上がってからにする。最終的にドキュメントはきちんと整備しなければいけないのだが、いつそうするか。何回かのテストや要件変更や追加からの実装を通じて、最終的に目的がかなうものが出来上がっていく。こういう作り方は、システム開発の現場でも最近は取り入れられているが、インフラの場合は、「よくあること」だ。
しかし。たまにユーザー側にウォーターフォール絶対主義者が存在する。このときは厄介なことになる。手戻りを悪とするからだ。テストにおける想定外の発見を悪とする。なぜ事前にわからなかったのか。コミュニケーション不足ではないか。そんな指摘を行ってくる。しかし、これは完全に手法の食い違いだ。
この状況で、いやいや、スパイラル型でやるんであれば手戻り上等でしょという思うのだが、どうしてもウォーターフォール絶対主義者の言う通りにしなければならない状況というのはあるので、この時は静かに、次回以降はそうしますね、と言うことしかできない。手戻りが許されないのであれば、もはや机上で実装前にユーザー側から要件や要望をひねり出し、全て文書化しなければいけない。徹底的に問い詰めて、そしてそれ以上の要件追加や変更を認めないように証拠を積み上げなければいけない。
世の中には、技術等々には興味がなくプロセスの正当性ばかりに注目する人がいて、しかもマネージャーにアサインされているケースもある。そうすると、いや、技術的に・・と話をしても通じない。そして、学んだウォータフォールの世界観が全てなのだ。そうなると、効率の良いスパイラル型における「曖昧の許容」はない。この場合には効率を落とすことになるので、その分のコストを載せることになる。仕方がない。
この議論、私はどちらが正しいかを決めることができない。ある時はウォーターフォール型の方が正しいかもしれないし、スパイラル型の方が正しいかもしれない。しかし決めるのはユーザー側だと思う。例えそれが理不尽だとしても。ユーザー側の組織の中でも、スタッフとマネージャーで認識がずれている場合もあるので厄介だと思うのだが、このあたりをベンダーが間違えると地雷になる。意味不明にユーザー側の現場と一緒に怒られることになる。
ウォーターフォール型とスパイラル型、もちろん他にも開発手法はあるが、この二つの方法を巡って、曖昧をどう処理するかでかなり衝突がある。プロジェクトが燃えるときのよくある理由の一つなので、おぼえておいて損はない。
