とあるプロジェクトで失敗しました。少し自分には経験がないような、ただ自分が提案して非常に意義はあると信じていたプロジェクトであったため、少し落ち込んでいる。

プロジェクトでは大規模なソフトウエアを開発するものだった。これなら価値があるかも、というニーズの仮説を立て、そこから要件・要求定義やアーキテクチャ選定はそれなりに手順を踏んだし、必要な技術の知識を身に着けた。

しかし失敗した。いわゆるプロジェクト倒れというもので、プロジェクトの求める結果にリソースをかけすぎて、意味のある結果が残せなかった。

原因は以下の通りに考えている。

①　技術的な難易度・最終的な価値を事前に十分把握できていなかったのに、大きなシステム全体からリリースしようとした。

複数のサブシステムにわたる重要技術の難易度（必要リソース）がわからない状態で、かつ最終的な価値がわからないまま（仮説のまま）、全体のシステム構築を始めた。結果としてValidationまでに異常に時間がかかる、何をやっているかの全体像が見えない、意味がなさそう、という結果になってしまった。

②　メンバーを取り巻く環境、モチベーションの維持

メンバーも、技術的難度がつかめない&最終outputの実感がないので、モチベーションが維持できなくなっていった。各メンバーは何をしたらいいかがなかなかつかめなかった。

学んだこと：

技術的難度が評価できないほど不確定性がある場合、全体のシステムとして設計をしていくべきではない。その技術だけにフォーカスして、意味のあるものを抽出して小さく実証すべき。or その技術を排除して、同等に近い価値をまず出してvalidationをすべきであった。

validationも技術も不確定性がある場合、結局何をやっているのかわからなくなる。まずはしっかりValidationをしてから、意味のある技術を作るべきだったのだろう。もしくは小さなローンチを繰り返して、意味のある形にすべきだったのだろう。

どうしても、大きなシステムで経験のある領域をやってきたため、そのV字感覚に流されていた。Validationがわかっているもの（つまり最終的な価値がわかっているもの)はよいが、そうでないものはそれではいけない。

そういうときはVではなく、渦巻型に進んでいく必要があるのだろう。