情報システム作りだけでないかもしれませんが、プロジェクトを進めるに当たり、進め方の選択肢は多い方がいい。プロジェクトに想定外やトラブルは付き物だし、選択肢が沢山あれば、その種類だけ挽回策を立てるのもたくさんの方法で立てられる。
例えば製品のEOS (end of support/service)期限ギリギリにシステム再構築の完成時期を持ってくるなんてのは最悪で、なにか問題が起きれば、「サポートが切れることになるか、特別料金での対応チームを個別に残しましょうか」などと、SIer に足元を見られて吹っ掛けられることが多い。
とはいえ、プロジェクトを予定より前倒しでやるんだから、周りのメンバーからは、「そんなに急がなくても良いじゃん。まだ期限は先なんだから」ともなる。
どうせS_IN間近は帰れなくなるんだから、それまではそこまで一生懸命にやらなくてもいいじゃん。みんなで仲良くシステム作れれば良いけど、なかなかタイミングが合わないことも多い。
システム作りは仲間作り、社会作りでもある。再構築したシステムに、既存のシステムからデータの移行をして、その移行したデータに基づいて事業把握するんだから、その事業自体に社会性がある事業であれば、そんなシステムの再構築は、社会の再構築だし、再構築したシステムが、事業の想定通りでなかったり、利用者の想定通りでなかったりすると、社会的に大々的に取り上げられる大事件になってしまう。
７Payの事例（7pay - セブン‐イレブンで使えるかんたんスマホ決済）は非常に印象的に残る。期待感も高かっただけに、ちょっとした、でも基本的なところで欠陥があると、事業継続もできないし、社長や管掌役員は交代になる。
SIerがちゃんと助言してくれないかなという声も多いのかもしれないけど、結局は発注力かなぁ。ユーザ企業としての。
結局はどう予防するか・・・余裕を持って、予めリスクも含めて情報を収集して、プロジェクトの早期にどういう改善策が打てるのかをどうかを決める。その選択肢はシステムを前倒しで作るかどうかだけではなくて、ステークホルダーを如何に脅したり透かしたり、できるだけの策は弄してみる。
色々と振り回されたプロジェクトも多かったけど、自分から振り回したほうが納得感もある。車の運転も、人の運転に同乗すると酔うけど、自分の運転なら酔わない。そんなものかな。
