NEW! スキル
現場を知り尽くしたPMOが教える
技術を、評価に変えるコツ客先常駐の現場では、技術力だけで成果や価値が正しく伝わるとは限りません。相手に合わせた伝え方、意思決定者を動かす報告、信頼を損なわない振る舞い、情報をつかむ動き方もまた、プロジェクトを前に進めるための技術です。 本連載では、数多くの開発現場を見てきたPMO・甲州潤さんが、客先で評価される人と損をする人の違いを実例から解説。単なるコミュニケーション論やマナー論ではなく、技術力を成果と評価につなげ、その経験を次の現場でも通用するキャリアの資産に変えるための「現場技術」を紹介します。
お客さま先の無理な仕様変更や、現実的ではない納期スケジュールに対して、エンジニアとして「要件定義書にありません」「この期間では実装不可能です」と回答したことはありますか？
言っていることは100%正しいはずなのに、なぜかお客さま先の空気が凍りつき、後日「あの人は少し扱いづらい」「コミュニケーションが取りづらい」と評価を下げられてしまった……。
客先常駐（SES/SI）の現場で、このような経験をしたことはないでしょうか。
「自分は間違ったことは言っていない。リスクを正確に伝えただけだ」
「お客さまが感情論で怒っているだけで、エンジニアとしては論理的に正しいことを伝えただけなので、感情的にならず合理的に判断してほしい」
そう考えて通り一辺倒の主張を続けていると、仕事自体は大きなトラブルなく終わったとしても、次の契約更新のタイミングで「別の方のご提案をお願いします」と要員交代を打診される事態に陥りかねません。
今回は、連載の第2回として、「正しいことをして仕事は進めるが、一緒に仕事をしたいと思われない人」の構造的な原因を分析します。そして、お客さま先との信頼関係を壊さずに、外部の人間だからこそ言える「本質的な提言」を相手に受け入れてもらうための伝え方のノウハウを解説します。
株式会社office Root（オフィスルート）
代表取締役社長
甲州 潤（こうしゅうじゅん）
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（ビジネス教育出版社）
目次
「甲州さん、お客さまが無茶な要件を追加してきたので、仕様通りには作れないと突き返したんです。プログラムのバグを防ぐために正しい指摘をしたつもりなんですが、なぜかお客さま側のPMに嫌われてしまって……」
以前、現場に入っていたSES企業に勤めるエンジニアから、このような相談を受けたことがあります。彼は技術的なジャッジが非常に正確で、プロジェクトのリスクをいち早く見抜く力を持っていました。しかし、お客さま側の担当者との関係がいつもギクシャクしており、技術レベルの高さに見合った評価が得られていない状態でした。
彼の話を聞いていて分かったのは、彼がお客さまに対して「機械」や「プログラム」のように接してしまっている、という点です。本人に自覚はありませんが、相手からそのように見えている状態でした。
システム開発において、誤ったインプットに対してエラーコードを返すのは正しい仕様です。しかし、人間同士のやり取りにおいて、相手の事情を無視して「仕様にないため無理です」とそのまま突き返すのは、対人コミュニケーションのインターフェースとして不具合を起こしていると言わざるを得ません。
お客さまはあなたに「指示通りに動くだけのロボット」になってほしいわけではありません。システム開発のプロとして、よりよい仕事をしてほしいと思っています。さらには、どのようにしたらより良い解決方法があるのかのアドバイスがほしいとさえ思っています。
あなた自身は、「正しいことを言って仕事を進めて、最小限の情報で端的に正確に伝えることこそがプロ！」と思っているのかもしれませんが、会話に温度がなく、冷徹で機械的な人は、そのプロ意識がほとんど伝わっていません。
そうした振る舞いを続けていると、お客さまは「あの人に相談すると正論で詰められるから、話しかけづらいな」と感じるようになります。結果として重要な相談があなたに届かなくなり、現場が変わるたびに評価がリセットされる「指示通りにしか動かないエンジニア」の枠から抜け出せなくなってしまうのです。
誤解してほしくないのは、「お客さまの顔色をうかがって、無理な要求にもYesと答えなさい」と言っているのではありません。むしろその逆です。
お客さまは、社内での関係があるため、上層部や他部署からの無茶な要求に対して「それは不可能です」「リスクが高すぎます」と本音を言えないことが多々あります。そんなとき、外部の人材であるSESエンジニアが客観的な事実に基づいた「正論」を口にする価値は、非常に高くなります。
問題は、その正論を伝える際の見せ方です。
お客さま側のPMも、内心では「このスケジュールは厳しい」「この仕様変更は無理がある」と分かっているケースがほとんどです。しかし、彼らも社内のプレッシャーがあり、板挟みの中で仕事をしています。
そこに追い打ちをかけるようにあなたから「ロジックとして破綻しています」と機械的な正論を突きつけられると、「そんなこと分かってるよ。その上でどうしたら良いかを考えたいんだけど……」となってしまいます。
お客さまを論破するのではなく、彼らが抱えている「悩み」を把握した上で会話を組み立てることが重要です。対立関係を築くのではなく、お客さまと一緒にこの悩みを解決するパートナーとして寄り添えるかどうかが大切です。
このひと工夫ができるかどうかが、お客さまから「もう呼びたくない」と思われる人と、「単価が高くても契約を延長したい」と思われる人の決定的な違いになります。
では、正確に情報を伝えつつ、お客さまとの信頼関係を失わずに、会話を発展させるにはどうすればいいでしょうか。
ビジネスの世界では定番の話し方の型ですが、現場で徹底的に実践することをお勧めします。
それが「PREP（プレップ）法」です。
●P（Point）：結論 （端的に伝えたいことを書く。ただし、＊＊＊について はダメ）
●R（Reason）：理由（背景も合わせて書くとより良い）
●E（Example）：理由を裏付ける具体的な内容
●P（Point）：結論の繰り返し
エンジニアが得意なロジカルなメッセージ構文ですが、これをお客さまの立場に合わせて少しチューニングするだけで、機械的な物言いが「私が持っている情報と考えではこのように思いますが、一緒に考えましょう」というメッセージへと生まれ変わります。
具体的な会話の例で比較してみましょう。
「その追加要望は要件定義の範囲外です。現在のスケジュールでは実装する工数がありませんので不可能です」
（ただ「できません」と突き返しているだけで、お客さま側PMの立場を無視しています）
【結論】「今回のリリースにその機能を無理に含めるのは、スケジュール的に避けた方が安全だと考えています」
【理由】「なぜなら、このタイミングで仕様を変更すると、本番環境でのデータ整合性をテストする期間が不足し、リリース直後に障害が発生するリスクが極めて高いからです」
【具体例（代替案）】「例えば、もし実装の優先度を〇〇機能の後回しに変更していただけるなら、今回の工数内で対応が可能です。あるいは、この機能だけを次フェーズのマイナーアップデートに切り分ける形であれば、調整できる可能性はあります」
【結論】「御社の社内調整としてどちらの方向性が進めやすいか、システム品質を守る観点からチームとして一緒にご相談させてください」
言っている「現在のスケジュールでは無理」という事実は同じですが、OK例ではお客さま先の「社内調整のしやすさ」に配慮した具体例・代替案を提示し、主語を「システム品質」という客観的な目標にしています。
これにより、お客さまはあなたを「融通の利かない頑固な外部の人」ではなく、「一緒にプロジェクトの落とし所を考えてくれる頼もしいパートナー」として認識するようになります。同じ正論でも、このPREPの構文を通すだけで、相手に与える印象は180度変わるのです。
ここまで読んで、「PREP法なんて、ビジネス書の最初の1ページに載っているような基本中の基本じゃないか。今更言われなくても知っているよ」と思われた方も多いかもしれません。
しかし、私がPMOの現場で見てきた中で、この型を「知っている人」は9割を超えますが、トラブルが起きた緊迫した場面や、お客さまから無茶な要求をされた瞬間などで、本当に「実践できている人」は1割にも満たないのが現実です。
人間は、焦ったり、自分の正当性を主張したくなったりしたときほど、防衛本能から結論を後回しにして「言い訳（理由）」や「愚痴（感情）」から話し始めてしまう生き物です。
おそらく前述のNG例のエンジニアもOK例のようなことは頭にあったはずです。そのことを考えていたのに、結論だけを伝えているということは意外と多いです。
私自身が、会話を掘り下げて質問をすると、OK例のような会話に発展することはかなり多くあります。その都度、私から「次からは頭の中で考えていることも含めて文字にして伝えてください」と伝えます。すると、みるみるコミュニケーションがスムーズになっていく場面を何度も見てきました。
技術の世界で言えば、どんなに優れたフレームワークを使っても、ソースコードを正しく記述して実行しなければ、システムとしては一切機能しません。
コミュニケーションも全く同じです。「知っている」だけの知識には何の価値もありません。ビジネス書を読んだり、コミュニケーション研修を受けて、できた気になっているのではなく、実際に使って初めて意味をなします。
「できません」と言いそうになったその瞬間に、頭の中でPREP構文へとシフトさせましょう。そして「できない理由」を並べるのではなく、「どうしたらできるか？」という視点で考え直してみましょう。さらに、相手の立場になって考えてみましょう。
お客さま側PMの「立場」とは感情論ではありません。「直前の仕様変更を飲まないと上層部に説明がつかない」「障害時の責任主体がどこにあるか」という構造的なプレッシャーです。相手の心理ではなく、相手が背負っている「制約条件」のトレードオフを言語化すること。これが技術者が持つべき相手視点です。
この徹底した「実践」の繰り返しこそが、あなたのエンジニアとしての評価を、文字通り桁違いに上げてくれます。
仕様の可否を伝える際は単なる「期限」ではなく、「合意のクリティカルパス」を提示してください。「〇日までに回答がなければテスト工程のイテレーションが1回減り、品質保証の責務を果たせなくなる」と、判断の遅れが及ぼす技術的・事業的インパクトをセットで提示するのです。
同じ「来週金曜までの回答」を求める場合であっても、単に「スケジュール的に不可能です」と突っぱねるのと、「〇日までに判断いただければイテレーションを削らずに済みます」と伝えるのとでは、お客さま側に伝わる解像度が全く異なります。
なぜその期限設定になっているのか、遅れるとシステムやプロジェクトにどんなインパクトが及ぶのか。その背景と依存関係を可視化することこそが、相手の立場に立った伝え方です。
根本としては、「自分はこのように考えていて、あなたにとってはこれが良いと思ってこの結論になりました」という相手へのアライメント（整合）が重要です。そしてそれを具現化する基本的なフレームワークが「PREP法」なのです。
意見をまとめるときは、「できない理由」から考えるのではなく、「どうしたらできるか？」という視点で考えてみましょう。
このように、相手に端的にお願いごとを伝えながら、こちらの事情も伝え、そして相手のことも配慮した伝え方ができる。
この積み重ねがお客さまからの評価につながります。
根本としては、「自分はこのように考えていて、あなたにとってはこれが良いと思ってこの結論になりました。」という考えが重要です。そしてそれを具体的に表現する方法が、「PREP（プレップ）法」です。
意見をまとめるときは、「できない理由」から考えるのではなく、「どうしたらできるか？」という視点で考えてみましょう。
さらに、相手の立場に立って考えてみることを意識してみましょう。
はじめのうちは難しいかもしれませんが、相手にメッセージを送る場面、仕事上の小さな報告や相談から始めてみましょう。
もし、「相手の視点に立てない」「自分の考え以外に思いつかない。絶対これが正しいはずだ」という人は周りの人と意見交換を活発に行なってみましょう。こんな考えもあるんだ！そういう発想になるんだ！というように世界が広がるはずです。
相手の制約条件が分からない場合は、構成員全体のインセンティブ設計（お客さま側のPMは何で評価されるのか、自社の営業は何を求めているか）を図解してみることを勧めます。
単なる自分の主張から一歩引き、プロジェクト全体を「システム構造」として俯瞰する視点を持つことが、正論を武器に変える第一歩です。
『DX時代の最強PMOになる方法』
著：甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる７つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
タグ
