実現仕様はなからずお墨付きをもらわないといけない理由

当たり前のことですかねー。トラブルとかで専門でもないはずなのに、先々を見通して会話される頭のよい人がいるんですが。

その人の話すことを一つひとつ、「(なんでそんなこと言っているのかな？？？)」って思いながら、実は裏を見ようとしているんですが、よくよくその言葉を考えたら、「(あれ、それ自分やってたじゃん？)」って思い出したりして。

例えば、ミドルウェアやアプリケーションパッケージを適用してカストしたシステムを作るとき、実現したい要求を使用に落とすときに、そのパッケージで実現できるか検討しようとするはずです。

そのとき、目の前にあるパッケージを使ってみて、「あれこれ設定したり作り込んだりすればいいんだ。」と思ってそのまま仕様にして、実装しちゃうとその実装は製品のさぽーとを受けられるかどうかという実は先に深刻なリスクを生むときがあるのです。

それって、ほんと危ない。実現仕様を組み上げるとき、その実装方法がちょっとでもパッケージの簡単な実装でなかったら、いくつかの機能を組み合わせるとか、そうした時には必ずパッケージのサポートされる実現仕様になっているかを確認しておかないと。

パッケージはプロジェクトに適用するものであって、その機能や使用方法は、パッケージメーカーの推奨する利用方法でなければ、それに沿わない実現仕様の箇所においての責任を丸ごと負う形になるのです。それは負えるもののもしかしたらあるかもしれませんが、実現仕様まで顧客は中に入ってこないでしょうから、そこは、SIerが負うところになってきます。

でも、推奨する仕様なら、その責任はSIerとメーカーの、責になるわけです。

共犯は多い方がいい。

面と向かって謝る必要な場面になったら自分がすればいいんですが、でも、「メーカーだって良いって言っていたから仕方がないじゃん？」って言いたいし。その上で、「いついつまでに直りそうなんでお待ちいただけませんか。」って言いたいし。

まぁ、それをしたいが為に、ってわけじゃないですが、パッケージを使う以上、「勝手な思い込みで実現仕様を作ってはいけないんだよ。」っていうことだし、「使い方がサポートを受けられる範囲に収まっているかを想像がついたとしても保険のために聞くのはタダなので聞いて記録しておけ。」っていうのが大事だったと思いだした2013年の夏。