クライアントから信頼を得るためにやるべきこと
はじめに
ITエンジニアとして業務を行う際に、クライアントというものが存在することが多くあります。
受託開発を行っている場合は発注元がクライアントとなりますし、SIer・SESでの業務においてもは常駐先の社員等がクライアントとなります。自社開発の場合はクライアントが存在しないように思われがちですが、自社内のユーザ部門や経営層などがそれに近い形になることがあります。
今回、「ITエンジニアの業務で関わるクライアント」と良好な関係を築くために必要なことについて、一つの考察をしていきたいと思います。
1.状況が見えるようにする
クライアントとの良好な関係を築く上で、クライアントに状況が見えるようにすることは重要です。
例えば、宅急便で荷物をおくるとき、最近の宅急便のシステムでは今の荷物の配送状況がわかるようになっています。本来の宅急便のサービスであれば、荷物が無事に届けばサービスとして問題ないのですが、状況がわかることが利用者の不安の払拭に繋がります。
システムの開発を依頼された際も同様です。依頼しているシステムが今どれくらい出来上がっているのか、順調なのか遅れているのか、問題が発生しているのか、場合によってはクライアント側でなにか調整が必要なのか、といったことが気になってしまいます。そのような状況の共有がなく、突然「間に合わない」とか「問題が発生しました」という状況になると、信頼は一気に崩れてしまいます。
状況の共有を行う方法として以下のような手段があります。
1.1 ツールを使って状況を共有する
もっとも効率よく状況を共有する方法は、ツールを使って共有することです。
ExcelやGoogleスプレッドシートなどで共有資料を作る方法や、Trelloのようなボード機能など、様々な方法があります。
とはいえ、内部の細かいタスクをすべて共有するのは、双方負担が大きいことと、無意味に不安を与えてしまうことがあります。
状況によって異なりますが、共有するべき項目として配下のようなものがあります。
1.2 定期的に報告の場を設ける
資料を使って共有するのみだと、クライアントにはただしく意図が伝わら無いことや、誤解によりハレーションが発生することがあります。特にクリティカルな問題点はどのように報告数かが重要です。
最も良い方法は、週に１回など定期的なミーティングを開催し、状況について簡単に報告することです。クリティカルな問題点があった場合、その対応状況を正しく伝えられれば問題にならないこともあります。また、直接会話をして状況を共有することで、認識相違なども発生しくくなります。
2.交渉材料を提供する
クライアントに交渉材料を提供するというのも、非常に重要な内容となります。
例えば、クライアントが求めている機能が、技術的な問題により実現できないことが判明したとします。受注前（つまり、できると言ってしまう前）であれば実現できないこと自体は問題ありません。エンジニアの多くは、このような場合に「無理ですね」で終わってしまうことがあります。
しかし、クライアント側の立場に立てば、更に上の上司や、クライアント側のユーザや関係者、株主といった関係者に説明をしなければならず、苦境に立ってしまうことがあります。
「無理ですね」で済ませるのではなく、クライアント側がその先の交渉がしやすくなるような材料を提供することが重要です。
2.1 代替案を提案する
最も効果的な材料は、代替案を提供することです。クライアントが望む要件げが実現できない場合でも、その目的が達成できる別の案が実現できれば問題ない事が多いです。
少しだけ要件を変更するだけで実現できることもあれば、他のツールやシステムを導入することで実現できることもあります。
クライアントの要件に完全にフィットしなくても、妥協できる点・できない点を整理して代替案を用意し、ビジネスとしての目的を達成することが重要です。
2.2 実現困難な理由を説明する
代替案が提示できればそれで良いのですが、どうしても実現できないことがあります。その場合は、実現できない理由をクライアントに正しく説明することが重要です。
そうすることで、問題点を正しく把握することができ、その後のビジネス的な判断に活かすことができます。クライアント側の立場からも、関係者に説明しやすくなります。
また、実現できない理由がわかれば、別の観点から解決できることもあります。
- 人員や費用の増加で解決する
- 有識者を導入して解決する
- 新技術を導入して解決する
そういった判断を正しく行うためにも、「できない理由」は正しく伝えることが重要です。
3.受け身にならない
これはエンジニアに限った話ではないですが、仕事をする上で「受け身にならない」ということも、クライアントから信頼を得る上で重要な内容となります。
システムの開発の仕事で、依頼されるレベル感は様々です。
- システムの企画や要件から提案してほしい
- 要件（やりたいこと）は決まっているので、それを実現するシステムを作って欲しい
- システムの設計はできているので、実装してほしい
- 実装は完了しているので、品質を高める施策をしてほしい
- 運用しているシステムを保守して欲しい
- 技術的なアドバイスがほしい
- 開発工程のマネジメントをして欲しい
受注するレベル感や立ち位置によりますが、状況によってはより良い案を提案していくことが重要です。
3.1 要件や設計に抜け穴がある場合
要件が提示されていたり、設計がすでに完了している状況で、要件や設計に抜け穴があることがあります。
特に要件のレベルではどうしても細かい検討が漏れており、いざ実装してみたら、どうにも使いにくかったり、おかしなデータが登録されたしまうパターンがあったり、といったことがあります。
そのような場合に、「問題はありそうだけど要件（設計）通りだから関係ない」、「提案したら仕事が増えるからこのままにしておこう」といった思考になることが多いですが、この状況では良いシステムが作れません。
もちろん、契約外の問題解決まで無償でやる必要はないですが、問題点として共有しておくことが非常に重要です。
もしかしたらすでにその部分は検討済みで制約事項として許容しているかもしれないですが、多くの場合は「考慮不足」であることもあります。そういった考慮不足は早い段階で拾えたほうが良いので、クライアント側からすると非常にありがたい提案になってきます。
3.2 回答が来なければリマインドする
クライアントとやり取りをする中で、クライアント側のタスクが発生することも多々あります。例えば、複数の対応案があるときの判断であったり、仕様の確定であったりといったものです。
そういったクライアント側のタスクについて、状況によっては対応が遅れることがあります。そのような場合に、クライアント側に確認を行うことが重要です。
状況によっては、作業のやり直しやリリースの延期にも繋がりかねません。「クライアントが対応しないことが原因だから関係ないや」と考えることもあるかもしれませんが、クライアント側も様々なタスクを抱えており、対応が漏れることはあります。
そのような場合は、「クライアントから回答を得ることも仕事のうち」と考え、リマインドを行ったり、判断に必要な情報が不足していたら提供するなどのフォローを行うことが重要です。
4.決定権がないものは簡単に回答しない
クライアントとの調整を行う上で、自分に決定権が無いものを質問されることがあります。
例えば、金額について決定権を持っていないにも関わらず、先に金額を（正式なものとして）伝えてしまい、その後自社で「この金額では受けられない」と上司から言われ、訂正する必要が発生した場合です。
金額については非常に重要なことで、クライアント側がすでに稟議を通していたりしたら、問題に発生することがあります。参考程度に伝えるなら良いのですが、その場合も「あくまでも参考値です」と伝え、数字が独り歩きしないようにすることが必要です。
それ以外にも、自分がコントロールできない他チームや他社の業務に影響が出るような内容も気をつけたほうが良いでしょう。
とはいえ、細かい仕様の一つ一つに「社内で確認しないと回答できません」と言っていると話が進まないので、自分がコントロールできる範囲を明確に定めておき、コントロールできる部分はその場で回答、できない部分は持ち帰るという形が良いです。
5.最後に
クライアントと良好な関係を築く上で必要な内容についてまとめてみました。決して、無理な要求を無償で対応するということではなく、正しくコミュニケーションを取っていくことが重要であると言えます。
そして、ここに書いた内容は一例であり、他にも重要な要素はたくさんあると思います。もし木になる点があればコメントを頂けると幸いです！！
まとめ
- 開発中の状況は、ツールや報告会などを設けて状況が見えるようにすると良いです。
- 実現が難しい要件が発生した場合、「無理ですね」ですませず、代替案を提示したり、難しい理由を正しく説明することが重要です。
- 要件や設計に抜け穴があったり、クライアントのタスクの漏れがあった場合、受け身にならず、解決のために行動することが重要です。
- 自分がコントロールできない内容は、安易に回答しないことが重要です。
Discussion