後始末に興味ありますか
去年かな？、大怪獣のあとしまつ、こんな映画がありましたね、見よう見ようと思いながら、結局は見ませんでしたが、着眼点としては面白そうに思えました、後始末って、する人、しない人、興味ある人、興味ない人に分かれそうですね、システム開発の仕事の傾向として、終了したらそこでバイバイ、これが普通でしょう、正社員ならまだしも、非正規社員の心は次の仕事に向かっています、終わったプロジェクトがその後、どうなっているかなんて正直、あまり興味ありませんね、これ本音です、こちらも生活がかかっているのですから、たまに、派遣会社の方に「前のXXプロジェクト、どうなりましたか」と聞く程度です、さすがに、火を噴いていたプロジェクトだけは気になりましたね
裁判も行われている
最終的に失敗プロジェクトと判断するいくつかの要因があります
・スケジュール的に間に合わない
・スケジュール的には間に合ったがシステムダウンの多発
・ユーザーが望んだシステム内容ではなかった、応答時間が遅い、
操作性 の不備、等
開発側企業とユーザー側の間で裁判になった場合、おそらく、スケジュールの遅れやバグを開発者側が全面的に認めたのであれば、あとは賠償金の金額だけの話になるでしょう、問題は’ユーザーが望んだシステム内容ではなかった’場合です、良くある話なのですが「言った言わない論争」になるのです、言った、そして、どのように伝わったのか、どのように確認したのか、ここがポイントです、開発者側としてはユーザーに対して、あくまでも「あなたの望み通りのシステムを作りましたよ」と言いたのですが、ユーザー側は「そんなことは言っていない」と反論するわけですね、裁判結果によっては何億円の金額が移動するのですから双方とも必死です、ユーザーから「そちらにすべてお任せします」と言われたプロジェクトは、きっと、開発者側の負けになる可能性が大でしょう、ユーザーからの言葉を鵜呑みにするのは、とても怖いことなのです
どうすればよかったのか
要件定義書、会議の議事録、メール、このような文書に残るものを用意することです、裁判では、このような文書がどのような意味を持つのかが焦点になるでしょう、そして、議事録はその都度関係者全員に必ず見てもらうことです、確認した書類には印鑑を押してもらうなんて、今は誰もしない方法ですが、立派な「確認しました、了解しました」の証拠になります、裁判は双方がありったけの自分有利の文書を提出しあって、裁判官がどう判断するのかが決め手になるのでしょう、現代は何事においても透明化が求められる時代になりました、私が最後に経験したプロジェクトでは会議内容はすべて録音されていました
議事録の思い出
私が若かった頃、正社員採用された職場で真っ先に教わったのは、電話対応の仕方、次が議事録の書き方でした、議事録の書き始めは前提だったはず、つまり、この議事録が、何に対しての文章なのかを書いてから本文を書き始めるのです、議事録の作成は簡単ではありません、必死になって会議内容を把握しなければなりません、あらためて、日本語の難しさを実感するのです、議事録にはひな形がありました、この時初めて知りました、ひな形の意味、今思うと、新人社員にとっての議事録作成は、まさに技術者としての最初の訓練の場だったのです
コメント