もう少し具体的に自分たちのプロジェクトの欠点を考えてみると、要件の詰め方が悪いと思った。タスク処理系のシステムなので、全般的なユーザ業務に関わってくる。だからだろう、具体的な業務イメージが少ないまま改善開発が次々と決まっていた。こうなると強いのはユーザで彼らの意見頼りになってしまう。彼らの要求をそのまま聞いて、できないであろうことにだけ首を振ると、ガタガタの要件定義書ができあがる。代表的な業務にすら照らし合わせていないので、想定していない動作だとユーザから注意を受けて、みんなが胃をきりきりと痛めたりする。それに基本設計書への落とし込みにも四苦八苦する。改善要望なのだが想定するシステム動作もイメージしやすいにも関わらず……
相手の言うことや現状の業務をシステム化するのはとても簡単なことなのかもしれない。しかし、そこで業務を巻き取って自分たちのシステムを通した新しい業務を提供することができるのがSIerのもたらすことのできる本当の価値なのではないだろうか。案件とタスクベースで進みがちな私たちの業務には「どうにかしてやり過ごせば何とかなる瞬間」ができてしまう。そんな心の隙間に落ち着いてしまってはいないだろうか?
上記の考え方を持つことができるのかどうかで「見積り」という言葉のイメージも変わる。私のもつ見積りのイメージは、ユーザの要望を叶えるために私たちがかけるコストというものだったが、本来は相手の業務変換がもたらす効果を基に、今回のシステム開発にはこれぐらいの費用をかけることができるはずだと提案するものなのだ。待つだけのシステム開発屋はもう時代に則していない存在なのかもしれない。
私たちが参加するのはステークホルダーにとって唯一無二のプロジェクトであるはずだ。そんなプロジェクトであっても我々の作業はどこかルーチンワークになりがちで、ふとした瞬間に足元をすくわれたりする。ユーザの業務運用の全貌が把握できないと仕事の達成感だってすぐに飛散霧消してしまう。だからこそ相手の業務にぐっと踏み込む気持ちでシステム開発に臨み、最終的なオーバーカット目指して、次の工程につながる上流工程を実現したい。