プロジェクトにおける技術的課題の進め方

こちらの記事を読みながら技術の実現性検証ってモノ作りの頭かその外でやっておかないと技術的リスクがコントロールできないんだよなと思い浮かべたり。実際、ウォーターフォールでも技術課題は（リスクコントロールするつもりなら）やるし、事業企画でも正にフィージビリティスタディするしなぁ、と。

なぜ技術的検証をするの

技術的検証をする理由を挙げると…

などなどいくつか出てくると思います。

技術的検証をするのは、それをやっておかないとあとあとできませんでした、となる可能性がプロジェクトとして認識しているからです。言い換えれば、今やばそうだとわかっているのに出来るかどうかを今確かめないということは将来のプロジェクトがトラブルかもよ、ということです。

ある技術的を適用することを想定していたとします。もし、何かの理由でその技術が適用できなくなったとしたらどうするかを考えてみましょう。

プロジェクトの中止をする方が一番コストインパクトが少ないですが中止をすることで業務課題の解決を先送りするのでビジネスインパクトはホールドしたまま、となります。

技術のアップーデートを待つのは待っている間コストか掛かりますし、いつまで待てばいいのか問題も出てくるので今ひとつです。

別の解決方法を検討するのが一番世の中で取られている選択肢ではないかと思うのですが。ただ、これも想定していた適用技術と比較してコストが掛かったり、業務課題の解決に制限を設けたりする副次作用が出てくる可能性があります。検討しないとわかりませんが。

本番環境が用意できるのであれば想定する環境を全て用意して検証すればいいです。リソースが確保できるなら検証したい項目を全部検証しましょう。

でも、現実的にはどちらもできないことの方が多いです。NWを使用した負荷テストはNWの仕様により対象にできる機器が限定されるでしょうし、当てられるバジェットも限られるでしょうから、検証項目は厳選されるでしょう。

物理的な制限とリソース的な制限下で、論理構成上の要素を確保しつつ項目を優先順位づけします。

技術的検証をする際に外部からの制約となる制約条件やそれに引っ張られて実施できる技術検証のスコープとゴール設定をステークホルダと合意してください。

特に、技術的検証では時間も限られるのでどこまでの検証項目を必須とするか、線引きを始める前にしておくことあとあと揉めなくて良いです。

もう一つ、技術検証自体でトラブった場合、どこまで突き詰めるかも方針としては決めておいた方が良いです。そうしないと本体のプロジェクトが引っ張られますから。