大き目なウォーターフォール開発とは？
一般的な大規模開発プロジェクトで要件、設計、実装、テスト、運用までの各工程を完了してから次の工程に進める開発手法を指します。そのほとんどが年単位などで計画されているイメージです。
第三者検証とは？
基本的に開発者や直接の利害関係者ではない第三者の専門家が、その品質や安全性、仕様適合性などを客観的な視点で評価・検証するプロセスの事を指します。
その役割とは？
大まかには対象としているサービスやプロダクトに対して品質を第三者視点で保証することとなります。基本的な仕様書通りに動作するか？や性能、脆弱性、セキュリティ対策、ユーザビリティなど様々な観点から品質を保証する役割だと思います。
現在起こっていること
様々な現場に入って起きている思っていることは第三者検証として参画する際に、基本的に品質を保証できる状態にない場合が多いです。理由は「検証部分の後回し」、「プロダクトの複雑性の増大」、「担当者の属人化」、「目的や成果の形骸化」が原因ではないかと思います。（基本的に大き目のプロジェクトで最終段階で参加することが多いので課題は多岐にわたっている印象です。）
- 検証部分の後回し
- 第三者検証を導入する時期が遅すぎて、参画時に品質について整理をしても時すでに遅し、の場合です。基本的に後から来た人の意見も聞かないイメージです。
- プロダクトの複雑性の増大
- 長い期間の設計や要件の調整で変更や課題は膨れ上がり、暫定案やその場しのぎの対策が横行して複雑化が進んでしまう事象です。プロダクトの複雑さは品質の低下だけでなく、属人化やモチベーション低下など働く人にも大きな影響を与えます。
- 担当者の属人化
- 「ドキュメントは現在ありません。」、「～さんしか知らないと思う。」など多く耳にしたことがあります。これらは局所的な人員に責任を押し付け、オーナーシップを欠いた無責任なプロジェクトへとなっていきます。
- 目的や成果の形骸化
- 「良いプロジェクトにする」、「使われる人が助かるようにする」など当たり前の目的が、「目の前の課題を片付ける」や「期間を守るために不正をする」に代わっていきます。
今後どうしていくべきか？
本来、第三者検証のプロセスを導入する場合はプロジェクト開始時か最低でも要件を定義する前に導入するべきだと思います。早い段階で参画して、どういった保証をするかどうやってセーフティラインを引くかなど知見を活かすべきだと思います。それでも、後工程から参加することがある場合はどれだけ課題が多く、意味のないプロジェクトかを分析して次に生かしていきましょう！
まとめ
雇用を生むという話と開発をするという話が、僕の中ではこの話に大きくかかわっていると思います。雇用を生むために作業や業務を無理やり作り誰でも働けるモデルに作り替えることとより良いものを世の中に残すために色々と試すことは違うと思う。だからズレてると思う。