お客さまに関心を持つことが成長につながる
売上や利益をあげ、永続的に栄えることを目的とするのはたしかに企業としての本質ですが、だからといって
お客さまを無視して、
荒稼ぎするだけ
が目的の会社になると、結果としてお客さまをうしなっていくばかりですし、お客さまがいなくなってしまえば企業に未来はありません。
そうならないためにも、ビジネスにおいて何かを考える際には主語を「お客さま」から始めるようにしましょう。
私たちソフトウェア開発を主としたSIerと呼ばれる業界においては、要件定義や設計といった仕事のやり方を身につける以上に、お客さまとの接し方を学んでおくことが大事になってきます。
私も若かりし頃…そうですね…20代の頃はそうだったのですが、エンジニアはお客さまよりも自分が開発するモノ、つまりプログラムやドキュメントとそれを実現する技術に関心を持ちがちです。
いちエンジニアとして技術に関心を持ち続けること自体は何一つ悪いことではありませんが、そこにプラスしてお客さまに関心を持つことも加えればより優れた成果を残すことができるようになります。
たとえば次のようなソースコードを見たとします。
String name = "";
void getLastName (String name) {
this.name = name; // 引数nameの値を、変数nameに代入する
}プログラムの細かいノウハウは必要ありません。
ポイントは、
値を設定しているのに名前が「get」で始まっている
という点です。
getは「取得」と言う意味で、「設定」するのであればsetとするべきです。
このプログラム自体は、別に動作上問題はありません。
しかし、あとから見た人は混乱するでしょう。
名前にはそれぞれの意味があります。
もちろん後で読む人も、名前から意味を読み取ろうとしてしまうでしょう。
その際に、あえて誤解を生むような名称にしていれば、当然ながらバグを誘発することになり、その数が多ければ多いほど手戻りは多発し、スケジュールを維持することが難しくなってしまい、トラブルへと発展してしまうことになりかねません。
あるいは次のようなソースコードを書いてしまったとします。
try {
object.method();
} catch (Exception e) {
return 1;
}
return 1;例外を握りつぶし、何もなかったかのように処理を続行しています。
例外が発生する可能性は低いかもしれませんが、大きなトラブルの原因となるでしょう。
他にも、７層にもネストした基礎制御文や、数千行～数万行もあるメソッドなどいろいろと問題のあるソースコードを実際に見かけたことがあります（上記例もそのうちの１つです）。
ある程度の経験を積んだエンジニアであれば、これらのコードにたとえようのない「気持ちの悪さ」を感じるはずです。とてもこのまま放ってはおけないイライラとした感覚に襲われるでしょう。
こういった気持ちになるのは、みなさんがプログラミングに関心があるからです。
そして「このままじゃプロジェクトが失敗する」あるいは「プロとして、俺の美学が許さない」と、労力の許す限り問題を修正することになります。
お客さまに対しても同じことです。
「コミュニケーションの問題が発生したなら、すぐにでも関係を修復したい」
「お客さまのやりたいこと（要件）をきっちり理解したい」
「偏った情報に惑わされず、最適な技術を適用してあげたい」
お客さまに関心を持ち、このような問題意識を持つことがＢ２Ｂを中心としたＳＩ事業を生業とする企業におけるプロになるための第一歩なのです。
たとえプロジェクトが成功に終わったとしても、お客さまとの関わりがなければ開発者の成長に深みが加わることはありません。ただ漫然と開発してただけ…ということも珍しくないのです。
私の経験でも、お客さまとの関わりがなかったプロジェクトの印象は薄く、成長の実感がありません。これはちょうど、プログラミングをせずにプロジェクトを抜けてしまう開発者の気持ちに似ています。
実際問題として、お客さまに関心を持つのが難しいと感じる開発者が多いのは事実です。「サービス中心」とか「お客さま第一」などといった言葉を空々しく感じることもあるでしょう。
まずはこの問題を解決する必要があります。
お客さまに感心を持てない理由はいろいろと考えられますが、究極的には「コミュニケーション量の少なさ」だと考えられます。要はお客さまと接する機会が少ないために関心が持てないのです。
当たり前ですよね。
会ってもいない人に関心を持つことはできません。
メールだけのやりとりでも用件は済ませることができますが、やはり会わないとコミュニケーションとしては物足りません。仕様だけ把握できれば開発することは可能かもしれませんが、お客さまの事情や背景を知らなければ提案や解決することは難しいでしょう。
たとえば、私が実施してきた過去の勉強会や教育もかれこれ100回以上続けてきましたが、同じことができる人が社内にいないため「大変だ」と言ったら
「ビデオとかで配信すれば？」
と言ってくれる方もいます。しかし、残念ながらそれでは相手の表情や理解度がダイレクトに伝わらず、一方通行的な自己満足のコミュニケーションにしかなりません。「ここまでで何か質問ありませんか？」と聞いてもなかなか質問ができない人もいるかもしれませんが、そういった場合も表情を読み取ればフォローもできるのにそれもできない…。教える側よりも教わる側の方はその時間、理解もままならず無駄な時間を費やすだけになってしまいます。
それは「教育」とは呼びません。
まずはコミュニケーションの絶対量を増やせないか考えてみましょう。
窓口型チーム
図はよくある受託開発チーム体制のイメージです。
「太陽」はお客さまであり、丸い「惑星」がリーダー、リーダーの影にいる「衛星」が開発メンバーです。リーダーが窓口となり、太陽であるお客さまと接することで情報を整理します。
コミュニケーションはシンプルであり、リーダーシップが強力かつ有効にはたらいている限りは問題なくプロジェクトを進めることができるでしょう。この場合はリーダーの情報処理能力とコミュニケーション能力に依存することになります。
裏を返せば、情報処理能力とコミュニケーション能力が相当高い優秀なリーダーでない限り、この方法を選択すれば間違いなくプロジェクトはトラブルへと発展するということです。
窓口を一本化するのは、たしかに情報整理をするうえでとても有効ではあるのですが、ボトルネックになる危険性もはらんでいます。
仮にとても優秀なリーダーだったとしても上司が度重なる負荷をリーダーにかけるようなことをすれば、やはりプロジェクトは頓挫しやすくなることもあります。これは案外要員計画時には全く考慮されていないことが多いのですが、無能な上司やさらにその上の経営層が無能で、とにかくプロジェクト活動以外の負荷をかけ続けるようなリスクは常に考えておいたほうがいいでしょう。
この体制をとる場合、プロジェクトのメンバーであるエンジニアはお客さまに「煩わされる」ことなく、開発に没頭することが可能です。
しかし私も経験があるのですが、この体制では窓口となるリーダーにすべての情報が集中することになります。もちろん、議事録や打ち合わせでメンバーに対する情報共有は行いますが、それでも細かいニュアンスは抜け落ちてしまう可能性がでてきます。だからこそリーダーの情報処理能力とコミュニケーション能力が重要となってくるんですね。
ソーシャルなチーム
先述のようなリスクを減らし、問題を防ぐには、お客さまとのメンバーの直接的なコミュニケーションを重視しなくてはいけません。直接的コミュニケーションを重視したチームを「ソーシャルなチーム」と呼びます。
ある程度「コミュニケーション」の重要性を重視した組織であれば、そういったポイントの育成にも力を入れていることでしょう。
そうするとまだ任せづらい若年層を除き、一人前のエンジニアはそれぞれごとにある程度任せることが可能になります。ソーシャルなチームでは、お客さまとエンジニアとのコミュニケーションを意図的に増やしていくことで、リスクを大幅に減らすようになります。
ただし、コミュニケーションを増やしたいからといって、いきなりチーム全員でお客さまのところに押しかけてもうまくいきません。お客さまの負荷が高まり、リーダーの代わりにお客さまがボトルネックとなってしまうからです。
n人のコミュニケーションパス(経路)の数は n(n－1)÷2 となります。
たとえば２人チームのコミュニケーションパスは１本で済みますが、４人チームの場合は６本も必要になります。
ですので、意味なくコミュニケーションパスを増やしてはいけません。
お客さまとの直接コミュニケーションにもやり方があります。
打ち合わせを題材に説明していきましょう。
よくあるのがリーダーやマネージャー自身が「楽をしたい」がために自分でやるべきコミュニケーションもメンバーに押し付けて、コミュニケーションパスを乱雑に増やしてしまうケースです。
実際、そういう上司やマネージャーというのは多かったりします。
メンバーのWBS上に存在しない業務が増えるだけでなく、情報整理の負担も増えますし、業務上の負担を増えることになりますので、そういったリーダーや上司というのは部下やメンバーからもお客さまからも嫌われ、孤立していくことになるでしょう。
少なくともお客さまとの打ち合わせでは、最低限
「責任者」
「書記」
「Q&Aメンバー」
という3つの役割を決めてください。コミュニケーションの中心は「責任者」が責任をもって行います。質疑は「責任者」だけでなく「Q&Aメンバー」がお客さまの負担にならないよう一つひとつ順番におこないましょう。「書記」は記録管理が責任業務ですので原則コミュニケーションには加わりません。それぞれがそれぞれの責務をきちんと果たすようにすれば、混乱を避けることも容易になります。
情報処理能力とコミュニケーション能力が低いリーダーやマネージャーは往々にして大人数にしたがりますし、コミュニケーションパスをカオスにしようとしがちです。コミュニケーションが必要だからといってやたらと大人数で打ち合わせに参加すればよいわけではありません。参加させる（する）からには、それぞれの役割を意識しないと時間の無駄、経費の無駄、人生の無駄です。
責任者
責任者は通常はリーダーが担当する役割で、開発チームとしての回答責任を負います。
つまりお客さまから決定を求められたとき、開発チームの総意として回答を行う責任を持ちます。誰かに代弁させるものではありません。
何の準備もせず一人であわあわして、部下やメンバーに答えてもらわないとコミュニケーションもロクに成立させられないリーダーというのはいわば
事故が起きた時に記者会見などで何一つまともに答えられない無能な経営者
と変わりません。
「記者会見といえば、弁護士、側近に聞きながら代表が話す。というイメージ。この社長すごい。1人で説明し、質疑応答している。ちゃんと把握して話してる。日本の企業でこれだけできる社長は、どれほどいるのだろうか」
「技術者の端くれとしてKDDIの会見を見ていたが、KDDIに対する好感度がかなり上がった。幹部があらゆる質問を打ち返せているし(なにより驚いたのは社長がiOSとAndroidの仕様差分に言及した点)、慌てふためいたり助けを求めたりするシーンがまるでない」
先日発生したKDDIの大規模通信障害に対して、高橋社長の会見を受けてネットで称賛された内容の一部ですが、ここで引き合いに出された"一般的な日本企業の社長"像と重複するところがありますよね。
また、打ち合わせの進行役でもあります。
決められた時間で想定どおりの結論が得られるよう、会議の流れをコントロールする必要があります。コツを一言で説明するのは難しいのですが、強いて言えば
「ある程度脱線を許容しつつ、本線は死守」
でしょうか。
よくある話なのですが、「今日はスケジュールの遅延を報告しなくちゃいけない。難しい打ち合わせになるぞ」というときに限って別の話題で盛り上がり時間切れになりそうになることがあります。
そんなときは内心「今日は面倒なことを言わなくて済んでよかった」と思ってしまいがちなのですが、このような問題の先送りは危険です。辛くても本線の話は進めなくてはいけません。そのためにも、責任者はお客さまとの関係作りを普段から意識してください。辛い話でも、正直に切り出せる関係が理想です。
書記
書記の役割は議事録をまとめることです。
それ以上でも、それ以下でもありません。
そのことだけに集中させてください。
議事録といっても単なる発言集ではなく、プロジェクトの目的と結論、課題と次のアクションを整理した
「ネクストアクションにおけるインプットとして使えるドキュメント」
でなくてはいけません。
書記はとても重要な仕事です。
打ち合わせを府倣し、適宜議論を整理するための発言も必要となります。言葉の意味を正しく理解する力を鍛えるという意味でも、書記はチームのサブリーダーやリーダー候補が担当するとよいでしょう。
会議という直接のコミュニケーションの場で、お客さまの考えを自分なりに整理し文書化することによって、お客さまとプロジェクトのことをより理解できます。
特に重要なのは「目的」「結論」「課題・次のアクション」です。
目的と結論を読むだけで会議の全体像を理解できるよう簡潔にまとめます。
ただし慣れないうちは目的と結論を把握するのが難しく感じるかもしれません。
なぜならはっきりとした結論が出ない打ち合わせもあるからです。
その場合でも課題と次のアクションは明記しなくてはいけません。課題の抽出とアクション決めは責任者の仕事ですが、書記も議事録をまとめる過程で協力してください。
ちなみに、議事録をうまく書くために意識する行動は２つあります。
まずは「責任者とのコミュニケーションを密にすること」です。
先にも説明したとおり、会議の目的は議事録の重要な要素であり、目的を一番理解しているのは責任者だからです。
そして「打ち合わせが終わったらできるだけ早く議事録を書き始めること」です。
たとえ夜遅くに終わったとしても議事録を書くことを翌日に回してはいけません。とにかく打ち合わせが終わったらすぐに書き始めましょう。
Q&Aメンバー
Q&Aメンバーはいわゆる「そのほかの参加者」であり「衛星」です。
しかし、ソーシャルなチームでは質問と専門的な分野での回答という積極的な役割を担います。役割を持つことにより、プロジェクトに参加している感覚を高めることができます。
打ち合わせ中、必ず１つはお客さまに質問をするよう心がけてください。
要件のヒアリングや仕様のレビューなど確認ポイントがあらかじめわかっている場合や、重要だと思われる打ち合わせの前には、質問をあらかじめ考えておきましょう。
まずはお客さまに名前を覚えてもらい、
「あの人はこの手の話題には強いぞ」
と記憶に残してもらえれば成功です。
Q&Aメンバーは、お客さまからの質問に回答する機会もあります。
進行役である責任者から回答を振られることもあるでしょう。
緊張感を持って打ち合わせに参加してください。
最後にもう一つ、打ち合わせ中は書記だけに任せず、気になったフレーズやキーワードなどはしっかりメモをとってください。責任者や書記の補助的な役割という意味合いもありますが、なにより打ち合わせに参加してメモをとらないのは感じが悪いものです。
気持ちのよいコミュニケーションを実現するために
開発者の「心がけ」によってコミュニケーション量を増やすこともできます。
コミュニケーション量を増やすには、コミュニケーションの「気持ちよさ」を実感できなくてはいけません。量を増やすだけ増やしてよりカオスになってしまうのは、もうコミュニケーションとは呼びません。
気持ちのよいコミュニケーションを実現するにはお互いの心配りが必要ですが、まずは自身から始めてみましょう。
相手の知りたいことを優先する
たとえば、お客さま相手に技術的な用語を乱発してはいけません。
意味がないばかりでなく、悪い印象を持たれます。
お客さまからは
「この人は私がよくわからない技術を知っているので、信頼できる」
ではなく、
「私にわかるように説明できないのでは、技術もたかが知れている」
と思われるのです。
自分が訴えたいことではなく、相手の知りたいことを優先してコミュニケーションしなくてはいけません。
また、エンドユーザだけの話とは限りません。
実際のところほとんどのエンジニアにとっては、お客さま企業の情報システム部門や他ベンダーのエンジニアとの接点のほうが多くなることもあります。
このような場合でも基本は同じです。
相手の知りたいことを真っ先に考えてください。
親しき仲にも礼儀あり
長年のお付き合いで懇意になったり、あるいは年下のお客さまであったりしても礼節は欠かさないようにしてください。
たしかに少しくらいは「崩し」も必要です。
たとえば、私はトラブルプロジェクトに参画して、初めてお客さまとお話しする場合などは
「あのー、すいません。
初対面で申し訳ありませんが、ここからはぶっちゃけて話しませんか？」
ということがよくあります。最短距離・最短時間・最速で進めないとどんどんトラブル被害が広がっていくだけだからです。どんなに私たちが悪かったとしても、トラブルが解決できていない状況で責任の擦り付け合いなんてしていても解決は何も進まないからです（まぁ私自身が悪いわけではありませんしね）。
とはいえ、無礼な態度が出てしまっては開発チーム全体の品格が疑われてしまいます。
あくまで目の前の課題を解決するうえで必要なベクトルであることが大前提です。
開発チームがそうであるように、お客さまもチームで行動しています。
悪い噂はすぐに広まりますから、礼節をわきまえない態度はお客さまだけでなく、あなたの仲間、あるいはあなたの所属している企業に余計な迷惑をかけるかもしれません。
｢問題対私たち」の構図を作り上げる
最終的に目指したい関係は「問題 vs 私たち」の構図です。
ここでの「私たち」はお客さまと開発者のことであり、問題とはプロジェクトで発生するさまざまな課題でありトラブルです。
トラブルが発生すると、しばしばお客さまと開発者は敵対関係に陥ります。
お互いに言い分はあります。
お客さまの立場からすればスケジュールを守れない開発者は悪者ですし、開発者からすれば間際で要件を変更したお客さまこそ悪者なのです。
しかし、お客さまは敵ではありません。神様でもありません。
お客さまは課題を解決するためのパートナー以上でも、以下でもありません。
解決すべき問題に対して一丸となって臨む姿勢とムード作りをしなくてはならないのです。先の２つの心がけもそのためのものです。
これらの心がけは開発のすべての場面において意識してください。
たとえ今は直接お客さまと接するチャンスがなくても、いつか必ず役に立つときがきます。
最後に
うぬぼれが強いと自分にしか関心を持てなくなります。
自分が全体の中でどれくらいの位置にいるのか、周りからどのような技術者だと見られたいのか、そんなことばかり考えていると遅かれ早かれ行き詰まります。
反対に、自分の技術や知識に自信が持てない場合も、急いで身につけなくてはと焦るあまり自分のことに精一杯になってしまいます。
開発者にとって技術や知識は重要ですが、それがすべてではありません。
行き詰まったり、自分の力不足に悩んだときは技術の観点からではなく、お客さまの立場からプロジェクトを眺めてみましょう。プロジェクトのあらゆる場面で顧客満足を勝ち取ることができることに、そしてそれが自分にやりがいを与えてくれることに気がつくでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。