プライドの高いプログラマーに穏便に助言するための“心を操る”方法：プログラマーにうまくアドバイスする心理的テクニック【後編】

直接的な要望や文句を提示せず、穏便に問題を解決するためには、プログラマーにどのような形で自分の考えを伝えればよいのか。具体例とともにテクニックを紹介する。

[Joseph Ottinger，TechTarget]

　私の友人から「不備のあるソースコード群の結合に悩んでいる」という話を聞いた。私も過去に同じような体験として、テスト未実施のソースコードを結合しなければいけなかったことがある。このとき私は「テストコード（テスト用プログラムのソースコード）はどこにあるのか」と、そのソースコードを記述した同僚プログラマーに尋ねることで、遠回しにテストの必要性を伝えることに成功した。

　実は私の勘違いで「テストコードは存在する」という答えが返ってくる場合もある。このときは私の思った通り、テストコードは存在しなかった。だがテストコードが実際に存在するかどうかよりも重要なのは、テストの必要性を同僚プログラマーに考えてもらうことだ。テストコードが存在しないことに同僚プログラマーが気付けば、引き継ぎのために必要な要素としてテストコードを作成してくれる可能性がある。

　テストを想定せずに書いたソースコードをテストするのは難しいが、その問題はソースコードを受け取るまでは考えなくてよい。これをきっかけに、私が持論を提示することなく、同僚プログラマーは自分のプログラミングに対する認識を見直すことができた。

　同僚プログラマーにテストを要求する権限が、自分にないこともある。その場合はソースコード引き継ぎの担当者に協力を求め、テストが完了していないソースコードを他のソースコードに組み込むと信頼性が欠けることを担当者に伝えよう。そうすることで、テストの要求に必要な権限を得た上で、あらためて構造とテストについて同僚プログラマーと話し合うことができるようになる。

プライドを傷つけずにアドバイスできる“心理的テクニック”

併せて読みたいお薦め記事

プログラミングのテクニック

• Javaの「変数」「メソッド」「定数」名の“ひんしゅくを買わない”付け方
• Javaで「ケバブケース」はなぜ駄目？　「参照型変数」「パッケージ」の命名規則
• その変数は「パスカルケース」「キャメルケース」「スネークケース」「ケバブケース」のどれなのか？　命名規則の違い

　同僚プログラマーとの話し合いでは、逆の言い方をするとよい。解読困難な「スパゲティコード」（複雑で内容が整理されていないソースコード）を書いて悦に入っているプログラマーには、「あまり理解力のない私にも分かりやすいように、プロジェクトの基準に従って書いてほしい」と頼もう。例えば次のようなイメージだ。

　「この243行目の関数は素晴らしいけれど、私には理解するのが難しい。これを分解して複数の小さな関数に分けるとどうなるか、教えてもらえないだろうか。この『j』はインデックス？　何か具体的な名前に変更できるだろうか。これはウィンドウハンドル（『Windows』でウィンドウを操作するボタン類に割り振られた番号）？　よく分からないから教えてくれ」

　これは職場での初歩的な心理テクニックだ。“人を操る”方法とも言える。私たちは日々のやりとりにおいて、可能な限り優しく、そして相手にとって親切な方法で人を操っている。例えば笑顔であいさつすることで、相手に幸福感をもたらす。良いニュースを先に伝える、あるいは伝えないことで、相手の心を目的に適した状態にする。自分の目的のために人の考え方や受け止め方を利用するのは、結果の差し引きがプラスになるなら、異常な行為や悪い行為ではない。

　より良いプログラミングのために人を動かす心理テクニックを利用するのをためらう必要はない。正直なところ、怒鳴りつけたい相手にそうできないとつらいときもある。だがたいていの場合、怒鳴っても逆効果に終わる。建設的な結果を生み出したければ、気が済むまで相手をやり込めるよりも、目的を果たすことができる状況をどうすれば作り出せるのかを考える方が賢明だ。

TechTarget発　先取りITトレンド

米国TechTargetの豊富な記事の中から、最新技術解説や注目分野の製品比較、海外企業のIT製品導入事例などを厳選してお届けします。