SE100人に聞いたシステムエンジニアの仕事 - 仕事内容とその魅力

SE(システムエンジニア)100人に聞いたアンケート結果を中心に、SEの仕事内容の実態やSE"あるある"話を紹介します。

カテゴリ:4.こんなときどうする > 4.1 お客様の仕様変更

システム構築にしてもシステム開発にしても、物品販売やノンカスタマイズのパッケージ製品以外の場合は、仕様変更というリスクが存在する。 SE(システムエンジニア)の仕事をしていて、この仕様変更というのはもっとも困る。
6d1e1c71.jpg 

でも、お客様とは仕様書を合意しているわけだから、仕様を変更する場合はお金をもらえばいいのでは?
そう簡単にいけば、誰も苦労しない。現実的には、かなり泣かされる。それが、納期遅れや品質悪化につながり、SE(システムエンジニア)を徹夜へと追い込むのである。
f85f0c97.jpg 

え?堂々と仕様変更はお金が発生するとは言えないの?
難しいだろう。たとえば、仕様というのは文章で書いているのであるが、解釈は人によって分かれる。お客様は当然、自分の都合のいいよう解釈される。また、想定していない事象が発生した場合には、「事前説明がなかったから業者が責任を持ってやるべき」といわれる。
64449fb0.jpg 

なるほど。困りましたね。
では、大変だけど、事前に仕様書できちんと書いておくのですね……
「これは含みません」とか。
それがそう単純でもない。「前の担当者は書いてないこともやってくれた」とか、我々は客なんだぞ!という態度で、「上司を連れて謝りに来い」などと言ったりする。もう、めちゃくちゃである。

誤解の無いようにいうと、お客様がみなそうではない。とても良心的なお客様がとても多く、ほとんどがいいお客様だ。たまに、こういうお客様がいるというだけである。

ただ、そういうお客様にはコテンパンにやられるため、深層心理に深く刻まれる。だから、この問題を回避する術を知っておく必要がある。

今回はSE(システムエンジニア)の皆様にアンケートを採って回答してもらったのであるが、とても貴重な意見をもらえた。とても参考になった。皆様のお仕事のお役に立てば幸いである。

このエントリーをはてなブックマークに追加

イラスト:言った言わないでもめるSE(システムエンジニア)- Copyright (C) viva-se.net システムエンジニアの仕事
画像: 言った言わないでもめるSE(システムエンジニア)

SE(システムエンジニア)の仕事において、仕様変更というのは大きな悩みである。そのとき、イラストにあるようなトラブルにならないための対処策の一つ目が、「記録を残す」ことである。
SE(システムエンジニア)の皆様へのアンケート結果では、「記録を残す」がとても多かった。その意見の一部を紹介する。

「メール、文書などで証拠を残す(35歳男性)」
「会議の録音(49歳男性)」
「議事録は関係各位にメールをする(43歳男性)」
「議事録の相互チェックと承認(39歳女性)」
「知らないと言わせないよう、ドキュメントは共有し、承認印を必ずもらう(48歳男性)」
「履歴を文書に残すこと。議事録などの履歴は会議等が終了直後に配布し、修正点が無ければこれを正とする旨の但し書きを必ず入れ、責任の所在を50:50にする(44歳男性)」
e0f8587a.jpg

たしかに、サインまでしてもらうと、お客様も反論しにくいですね。
でも、サインなんてしてくれないでしょう。
そうなんだ。だから、工夫がいる。たとえばであるが、議事録を2部作成し、お互いにサインする欄を設け、こちらが先にサインをし、先方にもサインをしてもらう。相手だけにサインをしてもらうと、嫌がられるが、こうすれば、相手の警戒も少なくなる。
0919746e.jpg


会議が終わったらすぐに議事録を作ってサインをしてもらうの?
それが理想だが、現実には無理だろう。議事録をすぐにメールで送付し、確認をしてもらう。次の会議には議事録を読み合わせ、問題ないかを確認した上で、その場でサインをもらうことになる。
とはいえ、やり方はいろいろあるだろうから、これは一例と考えてほしい。

こういう地道なことも、SE(システムエンジニア)の大事な仕事なのである。面倒ではあるが、あとあと楽になるので、やっておいたほうがいいだろう。

このエントリーをはてなブックマークに追加

SE(システムエンジニア)の仕事において、仕様変更は最大の悩みである。そのときのトラブルの回避方法の2つ目である。

まず、お客様に、仕様変更を簡単にできると思わせてはいけない。仕様書および契約に基づいて仕事をしているので、仕様変更となる場合は契約変更も必要という認識を持ってもらう。
そのための一つの方法が、仕様変更のルール化であり、責任者によるしかるべき手続きを文書で行ってもらうことだ。皆さんのご意見は以下。

「口頭仕様変更は不可とし、書面でもらう(49歳男性)」
「変更仕様書の作成(57歳男性)」
「仕様変更は、プロジェクトの責任者と顧客の責任者間で合意した場合のみ実施する(41歳男性)」
「その都度、確認書を受領している(55歳男性)」
df9dc207.jpg

でも、「LANケーブル1本追加してほしい」という簡単な要求の場合、受けた方がいいのでは?
お客様との良好なコミュニケーションを考えると、そういう考えもある。現に、親切心から口頭で対応してしまうSE(システムエンジニア)もいるだろう。
でも、それであっても面倒な手続きを踏んでもらうほうがいい。または、全てをその手続きを踏まなくても、少なくとも1回は手続きを踏んでもらうことが大事だ。そうすることで、お客様に、「仕様変更は簡単にはできない」ということを伝えることができる。

このエントリーをはてなブックマークに追加

SE(システムエンジニア)の仕事において、仕様変更は最大の悩みである。それの対処方法の3番目である。

これは、お客様との見解の違いというか、意識違いをなくすためのものである。お客様が、そういう次元ではなく、ひっくり返してくる場合には通用しない。
SE(システムエンジニア)の皆さんの声は以下である。

「細かい事まで文章にして、口頭でも確認する(36歳男性)」
「確認事項を最後にお互い確認する(43歳男性)」
「細かなレビューポイントを設ける(41歳男性)」
「「そんなつもりで言ったわけではない」という状況を回避するために同じ内容を幾通りもの言い方で表現して相手に分かってもらう(51歳男性)」
「綿密な作業進捗の相互確認(49歳男性)」
「念を押して確認する(37歳男性)」
「決める時点で、考えられる点を説明。漏れていた場合は受諾する(51歳男性)」
「ユーザーの言葉をそのまま信じない(39歳男性)」

このエントリーをはてなブックマークに追加

できないと言えば、「やれ」と言われる。できないのではなく、「やります。その場合、これくらいのお金がかかります」と伝えるのである。
妥協点は、「○○円かかりますが、半分はこちらで負担します」という言い方で、こちらも努力していることを見せるテクニックもある。

SEの皆さんの声は以下。

「見積工数 + n% までは対応するがそれ以上は時間精算(35歳男性)」
「追加の費用を請求する(51歳男性)」
「期間と工数と、それに必要なお金の相談を持ちかける(37歳女性)」
「工数の見積もりをやり直し、リスクの説明と回避策の提示(42歳女性)」
「内容によっては、金額が上がることを説明し、納得してもらわねばならない(50歳男性)」
「納期が遅れるリスクや費用が別途発生するリスクを説明して、どちらを選択するかを選ばせる(34歳女性)」
「期限を切り、以降は議事録の有無にかかわらず仕様変更として有償対応する旨を契約に盛り込む(35歳男性)」

たとえ泣く泣く無料で受ける場合であっても、少なくとも費用提示はしたいものだ。相手も人間だから、「それだけの費用(人件費)を負担させているんだ」と思ってもらうことが、次の仕様変更の抑止効果になることであろう。
または、費用以外のデメリットを伝えるのもいいだろう。品質悪化になるとか、スケジュールが遅延するなのである。以下がその意見の例。

「日本ではできないので、海外(中国)に丸投げになりますが、よろしいですか?(46歳女性)」
「リスケ(30歳男性)」
「代わりに他の機能の一部を実装できないと言う(51歳男性)」

ただ、これらのやり方は、ときにお客様との関係を悪化させる場合がある。注意が必要だ。飲み込める程度のものは、気持ちよく無料で受けておく方が、トータルで考えるといいかもしれない。

このエントリーをはてなブックマークに追加

私は勉強不足で恐縮だが、これをやったことがない。でも、何人かの方がこう述べているので、実践されている人も多いのであろうし、これは有効な方法だと思う。
以下がSEの方の声である。

「曖昧さが残りそうな仕様については、要件定義の段階で必ずQA形式で顧客に確認をとり、文書で回答してもらう(37歳男性)」
「議事録+QA表 印鑑いり(52歳男性)」

このエントリーをはてなブックマークに追加

まあ、基本でしょう。でも、結構手間だったりする。

「プロトタイプを作って目に見える形で仕様決定する(51歳男性)」
「少しずつ見せながら開発してゆく(46歳男性)」
「アジャイル開発による、ユーザーストリー別での見積もり(54歳男性)」


女性SE(システムエンジニア)の成子 
話が全く変わりますが、WordやExcelは、バージョンが変わるたびに、ボタンの位置ががかりと変わります。ちょっとイラッとします。
目で見える確認は絶対にされているはずなんですが…

このエントリーをはてなブックマークに追加

リスク回避方法は?という質問には、以下のような意見がたくさんあった。

「現時点、回避できていない。こちらが折れてしまう(28歳男性)」
「ごり押しには何をやっても無駄(48歳男性)」
「これは、ユーザにはつきもので、どうしようもないが、どうにもならない場合は、こちらから手をひく(52歳男性)」
「ゴリ押しにも従うことが、長い意味でのリスク回避。拒否したって、後に響くから(50歳男性)」
「ない、というか、継続して仕事をもらうために、ついつい受け入れてしまう(48歳男性)」
「いろいろな手段を打ったがそれでも仕様変更するのであまり有効なものはない(44歳男性)」

これは、お客様との力関係(お金を払う立場と貰う立場)から、やむを得ないと思う。であれば、事前にそうなるつもりでリスク費というか、バッファを積んでおくのである。

私はこれが一番だと思う。お客様の仕様変更要望にはなるべく気持ちよく応じ、お客様への信頼関係を築いておく。そうしておくと、本当にやばいものは笑顔で断れたりもする。
以下がSEさんの声。

「20%程度のリスクをつむ(50歳男性)」
「ある程度を想定したバッファを積むこと(44歳男性)」

このエントリーをはてなブックマークに追加

90ae07d2.jpg 

何ですか?これ
いい言葉が思い浮かばなかったので、こうした。具体的には以下を確認してほしい。

【対お客様】
・お客様との良好な関係を築いておく。特にキーマンを押さえておくとよい。これは、飲み会が以外にバカにできない。結構重要だ。
・お客様に貸しを作っておき、ここぞというときには許してもらう
以下の意見もその一つであろう。
「頻繁にお客様とあう(24歳女性)」
「議事録を残し説得し、中間点くらいの着地点を目指す(32歳男性)」
「担当者と1:1での腹を割ったコミュニケーションをする(35歳男性)」
 →これは、担当者に信頼関係を作った上で、二人きりで話をし、本当に困っていることを伝えたり、折衷案で妥協してもらう交渉になる。

【対社内】
無理難題であっても、社内で費用支払の許可が出たり、メンバー追加、できるSEをアサインすることで解決できることもある。社内での交渉力を持っておくことや、助けてくれるよき仲間と信頼関係を築いておくことが大事だったりする。
これに関連する内容として、次の意見があった。
「社内、社外、客先問わず、ホウレンソウの徹底(40歳男性)」

【対ベンダ】
上記の社内向けのことは、ベンダや協力会社にも言える。こちらが困ったとき、一緒に泣いてくれたり、助けてくれる関係があるといい。

このエントリーをはてなブックマークに追加

最後は、回避方法ではない。少数意見である。回避できる可能性は未知数であるので、状況を見て対応してもらいたい。
SEの皆さんの声は以下である。

「客に資料を出させる(50歳男性)」
「正論を堂々と述べる(53歳男性)」
「有効ではないが、強気にいく(31歳男性)」
「どういう証拠を残しても、やはりお客様が強いので有効となる方法はなかった。争うつもりがあれば別だが(55歳男性)」
「運用でカバーする方針(31歳男性)」
 →仕様変更はせずに、別の代替え案で納得してもらうという意見である。お客様が納得してもらえるかであるから、あまり有効ではないかもしれない。

このエントリーをはてなブックマークに追加

スポンサードリンク

このページのトップヘ