久々の更新です。理由を付けては更新を怠っていました。

さて、この時期になると制作業界はいろいろな案件で盛り上がってくるかと思います。
特にシステム開発などは4月に公開するようなものだと、今時分になって

「それは仕様書に書いてあります。」
「それは仕様通りの動きです。」
「そういう仕様だとは思っていなかった。」

こういった熱いやり取りが繰り広げられる光景がどこの会社でもあるのではないでしょうか。

言った言わないの世界になるので、仕様書にしてきちんと確認と承認を取りながら進めても、お客さんにとってみたらイメージと違っていた。
確かに仕様には記載してあるけど、説明を受けていた内容とは違う、などいくら作る側の仕様を主張しても揉めてしまうことが多々あります。

当社ももちろん例外ではありませんが、いくら分厚い仕様書を作ってみせても仕様の認識の食い違いや変更は後になって出てくるものです。

制作する側にとっては仕様を覆されるほど困ったことはありません。
お客さんにとってみたらお金を出す以上自分たちの納得いくものをとことん追求して作らせるという気持ちも分からなくはありません。

でも確認した仕様はきちんと主張したい。改造は改造にしてほしい。

こういった依頼する側される側の主張がぶつかりあうわけですが、今回は制作側の仕様を主張するなら普段から気をつけておきたいことを書き出してみます。

仕様です！と正論を言い放つことは簡単ですが、それを納得していただくためには日頃からきちんとしていないと駄目だと思うのです。

日頃からミスを少なく

当たり前のことではあるのですが、日頃の作業ミスは極力減らしたいところです。
日頃からきちんと滞りなく、ミスがなく成果物を提示していれば、いざ仕様云々の話になった時もきちんと後ろめたさなく主張できるわけです。

制作側のミスや漏れが多々あると、仕様云々の話とは関係なくても、人間論争になった時は関係ない部分で鬱憤が溜まっていたことを引っ張りだすものです。
自分たちの正当性を主張したければ自分たちもきちんと制作していないといけないと思います。

日頃からレスポンスよく

メールの返信や確認などの日頃のレスポンスは早い方が良いのは当たり前ですが、仕様についても普段すぐに確認していた方が良いでしょう。
レスポンス悪く、ずいぶん経ってから「これは仕様なので変更はできません」とか言われてもお客さんも納得しがたい場合もあります。

単純にレスポンス悪いのは印象も良くですし、印象が悪いより良いほうが同じ話をしても人間納得してくれます。

日頃からレスポンスよくコミュニケーション取っていれば、揉めなくて済む話もあるわけです。

お客さんとの共通言語はないと思ったほうが良い

専門用語はさておいて、仕様の話を進める際に同じ言葉でも、人によって解釈のニュアンスが微妙に違っていたりするので、よくよく言葉の定義はしたほうが良いと思います。

たとえば、「文字化け」という表現にしても、実際はSQLエラーが表示されていたのを「文字化け」 と表現される方もいらっしゃいます。
制作している側にとってみれば「文字化け」ではなく「エラー表示」と言ってくれないとわからない！となるわけです。

例えは極端ですが、同じ言葉でも人によって解釈が違うので、仕様書があるとはいえ、お互いの言葉の意味のすり合わせは大切です。
仕様の解釈違いというのは結構、言葉の解釈違いで起こることがあるので気をつけたいですね。

メールプラス電話

メールだけで事を済ませてしまいがちになりますが、必要な時は電話できちんと説明する、話すということは非常に重要です。
話すことが面倒に思える時があったり、話しにくい場合にメールだけで済ましてしまうことは誰にでもあると思います。

でもメールだけで済ませたことによって誤解が生まれることもあると思います。
純粋にお客さんが確認出来ていなかった、何かしらの通信エラーで不達だった、などというトラブルもあるわけですし、仕様の話でいえば「それは仕様なので、改造になります。」と一文だけだと、なんだか突き放されているように感じる場合もあります。

いくらこちらの主張が正しくても、メール一本で断定的に済まされると、人によっては「なぜこんな重要な話をメール一本で済ませるんだ！」と思う方もいらっしゃるわけです。

きちんと口頭なり顔を合わせて説明すればお客さんも納得していただける場合はあります。
メールで履歴を残すことは必要ですが、テキストからは表情や感情は伝わりません。
重要なことは口頭なり顔を合わせてお話することは重要だと思います。

矛盾した仕様のまま作業しない

これは実際に作業する人にあたりますが、納期が差し迫っていたりすると、仕様にちょっと矛盾を感じてもそのまま開発してしまうことってあると思います。

制作をしている側の立場になると、それはそれでしょうがない部分もあります。
でも「あれ？」と思ったり、気づいていたのに、仕様書がこうなっていたので、と作業を進めるのもどうかとは思います。

仕様を作るのも人間です。
バグが起こるのと同じように、ミスもあれば抜けもあります。

もしチームでやっていて仕様を作る人間と開発している人間が別々であれば、お互い確認しながら進めたほうが幸せになれると思います。

 

＊＊＊＊＊

メールや文面できちんと確認して承認をもらうのは必要なことですが、それでもお客さんと食い違うことは多々あります。

時には仕様変更だと分かっているうえで強引に主張される場合もあると思います。

冒頭でも書きましたが、制作する側にとって仕様を覆されることほど困ることはありません。
「それは仕様です！」と通すために普段から気をつけないといけないことってあるんだと思います。