お役立ちコンテンツ | フリーランスエンジニアの案件・求人なら【テクフリ】
今回は、システムエンジニアやプロジェクトマネージャーなど、クライアントと直接会話する立場のエンジニアであれば、一度は耳にしたことがある、“クライアントからの迷惑な一言”とその対処法について、まとめてみました。
現在、直接的にはクライアントと関わることはない立場の方も、今後、キャリアップ・スキルアップに伴って、クライアントと直接かかわることも出てくるので、知識として知っておいていただきたい内容になっています。
『いい感じで』という言葉は、本当に取り扱い注意です。
なぜか？
それは単純に、「なにを持って“いい感じ”とするか、クライアントとエンジニアの間で認識があっているか、保証がない」という点です。もっと言ってしまえば、エンジニアの感覚で、『いい感じで』作ったシステムがクライアントにとっての『いい感じ』のシステムなのか、誰にもわからない、ということです。
そして、『いい感じで』の基準が明確に共有されていなかった結果、本当にクライアントが求めていたものと異なる機能を開発してしまったために、再開発(手戻り)になったり、納品拒否されるなど、“失敗プロジェクト”になってしまうことも少なくありません。
クライアント担当者から『いい感じで』という言葉が飛び出したら、なにをもって『いい感じ』とするか、しっかりとヒアリングして“要件定義”をしましょう。また、要件定義ができた後は、ちょっとしたことでも、メールや議事録などで良いので、後から「クライアント・エンジニア双方が、どのような内容で合意したか？」を確認できる形で記録を残しておきましょう。
なぜ、そこまでするかというと、『いい感じで』という言葉を発するクライアント担当者は“システム開発がわかっていない人”であることが多いからです。
実際、私が相対した、『いい感じで』をやたらと使うクライアント担当者さんは、機能要件・非機能要件という言葉も知りませんでした。知識がないために、うまく要求事項をまとめられず、『いい感じで』を連呼していたというわけです。
そして、『いい感じで』を多用するシステム開発が分かっていないクライアント担当者は、この後紹介する、『なるはやで』、『思ったより工数かかるんだね』『頼んだじゃん！』もよく使う傾向にあるため、慎重に扱った方が良いことが多いのです。
日本では『なるはやで』という言葉が好きな人が多い気がします。「そちらの予定次第で良いですよ」というニュアンスが含まれていて、一見、親切な言葉に見えます。しかし、ビジネスの世界では使ってはいけない言葉です。
なぜならば、『なるはやで』では、いつまでにやってほしいのかが分からないからです。仕事である以上、納期や、ターゲットとなる時期があるはずなのに、それが隠されてしまいます。
私自身、『なるはやで』という言葉で、痛い目に合いかけたことがあります。
「急いでいる訳ではないんですけど、なるはやでネットワーク作業をお願いします」とクライアントから月次会議で伝えられて、“今期中のどこか手隙のタイミングで対応すれば良いか”と考えていたのですが、翌月「健史郎さんのネットワーク作業待ちなんですけど、まだですか？」と催促されたのです。
よくよく聞いていくと、私の対応は、クライアント会社内部で行われた監査に関連したものであり、クライアント社内で「何月何日までに対応完了予定」と会社の上層部にも情宣されている、ということでした。そして、その期限が、催促を受けた月の月末最終営業日だったのです。
このときは催促がきっかけになって納期の確認ができて、問題が起きませんでしたが、危うく「ネットワーク担当の健史郎というエンジニアがスケジュールを守っていない」という話になるところでした。
そのような事態にならないためにも『なるはやで』と言われた場合は、クライアントの担当者と相談して、「いつまでに行うべきか？」を明確にしましょう。
なお、「いつまでに行うべきか？」を相談すると、システム開発が分かっていないクライアント担当者は、その作業の手間や準備期間、さらには後続作業との関連性が見えておらず、非現実的なスケジュールを提示してくることも少なくありません。
こうしたクライアント担当者を逆にコントロールして、現実的なスケジュールをくみ上げていく手腕も上流工程を行うエンジニアには重要です。
『なるはやで』と同じで、作業の手間や準備期間、さらには後続作業との関連性が見えてないこともあり、思った以上にお金やスケジュールがかかる、という不満を漏らすクライアントも多いです。
結局、クライアント担当者はシステム開発を発注する側、つまり買う側です。より安く、より早く納品してもらった方が嬉しいですし、その観点でしか見積書や請求書を見ない、あいは、その観点でしか評価する能力がないクライアント担当者も多いのです。
さらに言えば、日本ではIT投資はコストという風潮が強く、安ければ安いほど良い、と考える経営者が多いです。そして、IT企業側も人件費(つまりエンジニアの報酬)を圧縮するなどしながら、価格競争をしている状況です。
“適正価格”というか“相場”があってないような状況にあるのが、ITビジネスの現実です。
私の場合、『思ったより工数かかるんだね』と言われたときは、工数の見積もり根拠を説明するようにしています。「このリンクをクリックしたら、この画面が立ち上がるようにしたい、というお話ですが、これを実現するためには、この画面を作るだけではなく、DBにも手を加えます。なぜならば……」といった風に。
そもそもシステム開発が分かっておらず『思ったより工数かかるんだね』と言ったクライアントは、たいていの場合、これで納得してくれます。
たまに、どこぞかで知識を仕入れてきて「もっと安くできるはずだ」とおっしゃるクライアント担当者もいます。そういう方に対しては、管理工数や実績などを絡めながら「安かろう、悪かろうですよ」という趣旨のお話をすることもあります。
完成したものを見せたら、頼んでいた機能がないとか、思っていたのと違うものが出てきた、と文句を言うクライアント、やっぱりいます。
こういう事態になるのは、『いい感じで』としか言われなかったせいで、ボタンを掛け違ったまま開発を進めていた、というのもありますが、「クライアントが開発スコープを分かっていない」というのもあります。
開発スコープ、つまり、どんなものをいつまでに開発するかは、要件定義で検討され、実装することが確定した機能についてのみ、要件定義書などで明文化されるのが通常です。逆に言えば、検討されたものの、要件定義書などのドキュメントに記載のないものは開発する必要はありません。もっと正確に言えば、開発してはなりません。
ところが、検討した記憶が残っているクライアント担当者の上席にあたる方などから「あれも欲しかったのに」と言われるパターンが一番多いです。
その場合の対応法は、要件定義書などのドキュメントを再確認するようにしています。そして、「スコープ外となったため開発していないんですよ」と説明し、納得してもらうようにしています。
結局のところ、クライアント担当者はエンジニアではないため、システム開発やシステム作業について、正しい知識を身に着けている、という期待は持ってはいけません。
分かっていない人、あるいは分かっている風だけど変な知識を持っている扱いが難しいクライアント担当者をうまくコントロールする技術も、ある意味、エンジニアが出世するのに必須となるスキルです。
3つの質問に答えるだけで、フリーランスエンジニアとしての単価相場を算出します。 スキルやご経験にマッチする案件もあわせてご紹介いたしますので、気軽にご活用ください！ ※単価相場の算出に個人情報の回答は必要ございません。
