これまでエンジニアやプログラマーと関わりがなかった文系管理職が、彼らを理解するのは一筋縄ではいきません。エンジニアやプログラマーは何を考えているのか、どういう話し方を好むのか。そして、彼らからの信頼を得る振る舞い、彼らからの信頼を損なう振る舞いとは——。スムーズなコミュニケーションを実現し、彼らのモチベーションを高める方法を紹介します。
文系管理職がプログラミングを学ばなければいけない理由
私は昔、ITエンジニアの人材派遣会社で営業マンをしていました。派遣先候補を打診されたエンジニアの方々が必ずと言っていいほど知りたがるのは、「その会社のマネジメント層はエンジニアリングを理解しているか」「コードへの理解がある会社か」という点でした。ITエンジニアの人たちには、エンジニアやエンジニアリングに対する知識がない人たちと一緒に働くとコミュニケーションコストが高くなり、自分のパフォーマンスが落ちるという認識があるのです。
このエピソードは、文系管理職がプログラミングについて学ぶ重要性をよく示していると思います。管理職であるあなたが、エンジニアという職種の特性を最低限理解し、コンピュータやシステム開発について基礎的な知識を身につければ、優秀なエンジニアを呼び寄せ、彼らのパフォーマンスを上げて、チームで高い成果を出せるようになるのです。
そこで、この連載では、エンジニアとのコミュニケーションを円滑に行うために必要な知識や作法を皆様にお届けします。この第1話では、そもそもエンジニアの人たちとコミュニケーションをするうえで押さえておくべき、エンジニアによくみられるこだわりポイントを紹介していきます。
エンジニアは「定義」を重視する
管理職が人間と対話する人だとすると、エンジニアはコンピュータと対話する人だと言えます。
人間と人間の対話は、双方向的です。話し手がすべてを言葉にしなくても、聞き手は、その場のシチュエーションや相手の感情といった明言されていない情報を推測したうえで、話し手の意図を理解しようとします。
それに対して、人間とコンピュータとの対話は、一方通行のコミュニケーションです。コンピュータは、指示されていないことは一切理解してくれません。文字通り、言われたようにしか動きません。そこで、日ごろコンピュータを相手にしているエンジニアが重視するのは、「定義」です。コンピュータに指示を出すときは、言葉の定義や全体のロジック、最初から最後まで伝え漏れがないかに細心の注意を払います。
この姿勢は、対人コミュニケーションにおいても反映される傾向があります。管理職のあなたがエンジニアに、「これやっておいて（なんとなくわかるでしょ）」と指示しても、「それはどういうことですか？」と聞き返されるでしょう。これはエンジニアが冷淡な性格だからではなく、厳格な定義を求めているから。普段人間を相手にする管理職や一般のビジネス職とは、コミュニケーションのアプローチが異なるのです。
エンジニアとコミュニケーションをするときは、暗黙の前提条件や自明に思われる文脈をできる限り正確に言語化し、一つひとつの言葉をしっかり定義付けることを意識しましょう。
わからないときは「わからない」と言おう
エンジニアと会話するなかで、技術的な内容が難しくて理解できないという場面は当然あると思います。ここでエンジニアリングの専門知識を持たない管理職が一番やってはいけないのは、知ったかぶりをすることです。
「知らない」と言うことは自分の無知を認めることですから、人をマネジメントする立場の管理職にとっては特に怖い行為だと思います。
しかし、知らないのに見栄を張って知っているふりをすると、あなたに対するエンジニアの信頼は失墜します。なぜなら、エンジニアが最も重視する「定義」の真偽が揺らいでしまうからです。「Aの現状について教えてください」と聞かれたあなたが、Aが何かよくわからないまま答えてしまうと、Aの現状は誤って定義されかねません。「Aが何かについてあなたは理解している」という間違った情報をエンジニアに与え、両者の議論の前提にズレが生じることにもつながります。
エンジニアリングについて詳しくない管理職が今日からすぐ始めることができるのは、わからないときに「わからない」と言うこと。「すみません、もうちょっとわかりやすく説明してくれますか？」と聞けばいいのです。
わからないことを素直に認めるあなたをバカにするエンジニアはいません。逆に、正しい定義を与えてくれる存在として、信頼を寄せるようになるはずです。
ただ、「私はわからないから、そちらでよろしく」という丸投げはよくありません。「理解したいので、きちんと説明してほしい」という姿勢が重要です。自分で勉強することも必要です。「何でも聞いてね」と伝えた新人が本当に四六時中何でも聞いてきたら、「ちょっとは自分で考えろ」と思いますよね。
知らない単語は事前に自分で調べ、理解できなかった話は次回のミーティングまでにキャッチアップし、それでもやはりわからないときは、素直に「教えてください」と言いましょう。
フィードバックは、「定量的なファクト」と「課題解決へのインパクト」を大切に
「定義」を大切にするエンジニアは、「ファクト」や「数字」も重視します。エンジニアにフィードバックするとき、「よくやった！」という抽象的な褒め方は得策ではありません。「誰が、どのプロジェクトで、どれぐらいの成果を上げたことに対して評価しているか」の定義付けが不十分だからです。
といっても、「1日でコードを3000行も書いてすごい」と褒められてモチベーションが上がるエンジニアはあまりいないと思います。エンジニアのもう一つの特性は、自分が学んだり身につけたりした技術を使って課題を解決したい人たちだということです。
エンジニアの人たちは、自分のスキルの優劣自体というよりも、自分のスキルがプロジェクトやチーム、会社が抱える課題に対してどのようなインパクトを与えることができたのかを気にしています。
よって、フィードバックをする際は、「プロジェクト達成まで1カ月のバッファ期間を設けていたが、あなたがタスクをスムーズに進めてくれたおかげで、当初の目標期日までにシステムを公開することができた」「皆さんのチームが開発した新サービスのおかげで、新規ユーザー登録数が対前月比120％増を達成し、会社全体に良いインパクトをもたらした」というように、定量的なファクトを根拠にしつつ、目標やミッションへの貢献具合を褒めると、エンジニアのモチベーションをグッと上げることができるでしょう。
