曖昧な要求でSEを振り回すとキレられます

１＋１を０＋１と計算するSEに115万ぼったくられた話 - しろぐらまー

逆ギレしたSEを、ラーメン屋に例えて笑い話に昇華してみる - しろぐらまー

2部作で面白げな話があったので、ちょっとだけ分析させていただこうかな。 

SEとの仕事でもめている話です。この手のトラブルはオッサンのお手の物なので、ちょっとだけ整理してみましょう。

よくもめるパターンの「仕様の認識の差異」

• ラーメンを頼んだのにプリンが出てきた
• 理由を聞いたら「お前が悪い」と逆ギレされた
• 謝って「質問してください」と言ったら「質問などしない」と言われた
• 「でもラーメンを頼みました」と言ったら（ラーメンを頼んだこと自体は、紹介者も認識している）、「そんなの無視してプリンを作った」と言われた
• さらに「客だからって上から目線で話すな！」と言われた
• うんざりして「もういいです」と言ったら、紹介者への影響を気にしたらしく、「紹介者の仕事を切ったりするなよ」と言われた

上記のお話から察するに、おそらく「曖昧な要求定義」が問題と推測されます。

おそらく、SEの方の気持ちになって読み取ってみると

1. システムを作って欲しいとの依頼を受けた
2. （自分の認識した）要求通りに作ったのに、「仕様が違う」とはねられた。
3. 出来上がった後なのに、無茶な仕様変更で作りなおしを指示された

ってな感じかな。

よくある話です。特にシステム開発に不慣れなユーザと、初めて一緒に仕事をするSEとの間では。

この話のポイントは、一番最初の「要求定義」の段階で、しろさんとSEとの間にボタンの掛け違いがあると推測されます。

SEは、しろさんから受けた指示を認識した通り作成し納品しました。

おそらく請負契約だと思いますが、要求仕様通りに作成したのであれば、その後の修正は、瑕疵担保責任の対象となりません。追加請求となります。

ただし、しろさんは自分の考えている要求と異なるため、障害として判断されたと思われます。となると、瑕疵担保責任の対象として修正を要求する事になります。

ところが、SE側としてはただの仕様変更と認識してます。本来であれば、次のお金を払ってもらわなければならない仕事なのに、障害として難癖つけられ、タダ働きさせられそうだと感じたのでしょう。「質問してください」なんて言われても困ります。言われたとおり作ったのですから。

だから、「客だからって上から目線で話すな！」なんて発言になったのかなと思います。

SEの方の立場からすると、理不尽な要求と映っているのでまあ仕方が無いですね。

なので、「絶対に謝らない美学」「分からないことは質問せず無視する美学」ってのは今回の場合、ちょっと違うかなって思いますね。

SEとしてみれば、無理難題をつきつけられた難癖なので謝るなんておかしいって映っているでしょうし、そもそも指示通り作っているのだから質問をする必要ないしって感じていることでしょう。

※仕様を障害と言って振り回されたりするのは、SE側にとってもダメージの大きい話なんですね。しかも、わりかし遭遇率の高い話だったりするので警戒されるんですよ。

システム開発も基本は対話

さて、問題点についてちょっと指摘しましたが、ではどうすればよかったのか、ついでに考えてみます。

今回のプロジェクトは、請負契約で仕事を依頼し、最終納品時に問題が発見された、というパターンと推測されます。

この契約パターンであるならば、要求仕様に対する答えとして、「外部設計書」を納品してもらうのが良いかなと思います。

つまり、しろさんが行った要求に対して、SEがどのような認識して何を作るのか理解した結果を「仕様書」として認識合わせをしたあとで、開発してもらうのが良いかと思います。

最終納品の段階で仕様の認識相違があった場合、手戻り等双方の負担は大きなものとなります。なので、早い段階で認識合わせするのが吉です。

プロジェクトに参加する人はそれぞれバックグランドが違ったりしますので、知識レベル、趣味嗜好、関心の方向性等何もかも違うことなんてザラです。

そういったメンバーの意識を束ねて、一つの方向に向けるようにすることがプロジェクトを成功させるための秘訣です。

まあ、結局のところ、システム開発っていうのは対話が命なんですよ。

まとめ

今回のような「要求仕様の認識相違」なんてのは、初心ユーザとSEとの間だけでなく、それなりに経験を積んでいるはずのユーザや、きちんと経験を積んでいるはずのプロマネなんかの間でも起きうるような、システム開発よくある話です。

システムの要求伝達ってただの伝言ゲームではないです。要求をシステム仕様に変換することがもっとも重要なわけですが、結構スキルが必要だったりもします。

色々分析して書きましたが、決してしろさんを責めるつもりはないです。ベテランだって、きちんとできないこともある話です。気を悪くしないでください。

まあ、こういうのが難しいからこそ、オッサンの仕事の需要があるわけですが。

システム開発で仕事を依頼する以上は、常に認識相違がないかだけでも気をつけるようにしてください。

今後の失敗をぐっと減らすことができると思いますよ。

以上

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術