システムの構築、導入において幾つか読めない時間と言うものがあります。
その一つが検証時間。
新しいツールなどを、今の環境に導入するに当たりそれが可能（動作する）かどうか。
または、システムの構築に当たって言われた事が技術的にそもそも可能なのかどうか。
要件の定義がきっちり終わっていれば実装するに当たり、その工数と言うのは
おおよそ出す事ができます。
これは、機能や画面数などそれを見積もるための指標があるからですが、検証というのは
それが可能かどうかを調べる時間であって、OKがでるまで（またははっきりとNGとわかるまで）
延々続くことになります。
何かのシステムを導入するに当たってもある程度、動作環境というのは明確になってたり
するものですが、そのシステム上の要件が全て同一であると言う事はまずありえません。
その環境での設定一つ違うだけで、ライブラリなどのバージョンがちょっと異なるだけでも
動作しない場合があります。
私の経験上（そして多くの経験者がいるものだと思いますが）、同じような環境
（厳密に言えば同じではないのだけれども）で、同じようなことをやるにしても「何故だか」
うまくいかないのです。これは本当に不思議なくらいに・・・。
これは、先ほど言ったように細かな（本当に細かな）環境の違いがその問題に大きく
のしかかっていたりするからです。
そして、それに気づき修正しようとする。そこでまた時間がとられたりするものです。
こういった事で、大きく時間がとられる場合もあれば、スコンと入って終わる場合もあります。
この差が非常に大きいわけですが、スコンと入ることを前提に時間を取っておいても
何かある場合に対応できない事になります。（大体何かあるものです）
ですので、ある程度のキャパシティを取って対応時間を確保します。
これが、時間軸のずれ で書いたシステムを知らない人から見れば「何でこんなに？」というような
疑問が出るところでもあります。
当然、延々と検証時間を取るわけにも行かないので、ある程度で区切り今の環境で
無理な場合は、代替案を考えなければなりません。
対応する技術者のスキルによってもこの時間は当然変わってきたりします。
大げさに言えば、元々どんな人がやろうとも無理なことをやっている場合もあります。
また、スキルがない技術者がやっていて、たまたまその解決方法に気づかずに終わる
という場合もあります。
ここまで書いてきて具体的な解決方法を提示していないのは、私自身がその解決法を
しらないからです。（これはあるのかもしれないし、ないのかもしれないし）
つまり、解決する方法がないので先ほど述べたようにある程度の期間をはじめに決めて
おいた上で検証を行うということに重点をおいています。
3日とか、1週間とか。その期間はそのPJにどれだけそこに割く時間的な、リソース的な
余裕があるか、またその検証事項の重要性がどれくらいのものなのかによってくると
思います。
その機能が、今回のシステムの肝になるのであれば何が何でも実現しなければならない
でしょうし、代替案がありその方法でも「まぁいいよ」ということであれば、とりあえず検証を
何日か繰り返し、できれば最善策を、できなければ代替案をということになるかと思います。
読めない時間・・・。
そうはいっても、PJの緊迫したスケジュールの中でそういったことを私たちシステムを
知る側も楽しんでやっているわけではありません。できれば避けたいところです。
時間的に余裕のある中でとか、PJを関係なくそれに割く時間があるときは楽しいんですけどね。
