技術検証のスコープ管理

　システム開発でマネジメントしにくいフェーズは、要件定義やモデリングだけでなく、技術検証も該当するのではないか。（多分、既に誰か主張しているしているだろう）
　特にWebシステム開発は、色んなミドルウェアを組み合わせるため、思わぬ爆弾が至る所にある。まるでMineSweeperをやっているようだ。

　例えば、帳票をPDFで出力する機能を技術検証する事になったとしよう。
　最初は、HTMLのボタン押下後、PDFをダウンロードする仕組みを作るのが普通。その仕掛けのために、お金があるならSVF（1ライセンス50万円以上！）を使えば簡単に実装できるが、安く作りたいなら、ApacheFOP等のオープンソースを使ってみるしかない。それらフリーのライブラリの使い勝手や負荷の検証は情報が余り無いから、意外に時間を取られる。
　更に、帳票印刷はDB接続だけでなくPDF作成にも時間がかかるものだから、ユーザ画面でPDF作成を指示後、後でいつでもPDFをダウンロードできる仕組みにしておくのが普通。すると、PDF作成を指示したイベントをRDBへキューとして貯めておき、バッチでPDFを作成する仕掛けが必要になる。バッチ処理はテスト作業量が多くなるので、時間が取られる。
　だから、帳票PDF作成時に、機能のスコープを決めるだけでなく、PDF作成の技術検証のスコープもあらかじめ決めておかないと、いつまで経っても終わらない。

　お客さんからすれば、技術検証はSEの腕の見せ所でしょう、と思われるので、正直辛いものがある(m_m)
　プロジェクトマネジメントで一番大事なのは、スコープ管理だと個人的に思っている。理由は、スコープが時々刻々と変化するのにその事実になかなか気付けないから。