エンジニアは日々現場で学ぶ
開発現場で学べること
第8回　現場で必要な表現力とは？

クロノス 山野寛
2004/7/14

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

■SEという職業の特異性

　IT業界にはプロジェクトマネージャ（PM）やコンサルタント、システムエンジニア（SE）やプログラマといったような職業が存在する。その中でもSEという職業は、「ある意味」において特殊なスキルを必要とする。それは何かというと、「状況に応じて表現を使い分ける」というスキルである。

　例えば、SEがシステム設計書を記述する際には、いかに「網羅的で正確な表現」をするかが問われる。逆に、クライアントへの提案などにおいては、ある程度核心を伏せた「あいまいな表現」を望まれることも多い。普段われわれSEは、この「網羅的で正確な表現」と「あいまいな表現」を意識することなく使い分けているのだが、その場の状況によって適切な表現を用いるように心掛けなければ、聞き手（読み手）に大きな誤解を与える可能性があることに注意しなければならない。では、この「網羅的で正確な表現」と「あいまいな表現」がいったいどういったものなのかを簡単に説明しよう。

■網羅的で正確な表現〜SEが扱うシステム設計書

　読者の皆さんは過去に、「表現が適切でない」と感じたシステム設計書や仕様書を目にしたことはないだろうか。例えば、次のような表現で記述された文章がそうである。

支払金額が支払予定金額と一致した場合、支払済みフラグを立てて更新する。

　この「支払済みフラグを立てて」という言葉は、「フラグを立てる＝フラグを1にする」という暗黙のルールの上に成り立つ表現である。また同じような例として次のような文章がある。

支払完了通知書には、相手先コードがBreakするごとに小計を出力する。

　こちらも同様に、Break処理のやり方を知っているという前提で記述されている文章だ。当然、経験のあるエンジニアであればこういった表現でも理解できるだろう。しかし、システム開発経験の少ないエンジニアの中には、この文章を読んでもすぐには理解できない人がいるかもしれない。

　このような「表現が適切でない」と感じる設計書や仕様書は、書き手側（SE）の思い込みや、書き手側と読み手側との認識の差に原因があるようだ。一般的に設計書や仕様書は「網羅性の文章」といわれ、「漏れなく読み手側に情報を伝える」という目的を持っている。従ってこれらを作成するSEは、自分勝手な思い込みをすることなく、可能な限りあいまいな表現を避け、正確な表現を用いて記述しなければならないだろう。

■あいまいな表現〜クライアントとの会話

　逆にわれわれは、普段の会話においてはある程度あいまいな表現を用いて会話をすることの方が多い。例えば、とある打ち合わせの場で、クライアントが担当SEに対して次のような質問をしたとしよう。

クライアント　「支払いが完了したかどうかが分からないので、支払いが完了したら担当者へメールを送るという機能を追加してほしいのですが、できますか」

　この質問を受けたSEは、まずその質問の内容と目的を理解し、実現が可能かどうかを頭の中で整理する。その結果、実現可能であると判断した場合、おそらく次のように答えるだろう。

SE　「はい、できると思います」

　この「思います」という表現は日常の会話で頻繁に使われる。それは、もしもできなかった場合の「保険」という意味合いを含んでいるのだろう。逆に、

SE　「はい、できます」

と迷わず答えることができる状況はそう多くない。なぜならば、十分な確認をすることなく、仕様変更が容易で、かつ懸念事項もなく、コストも期間もまったく問題がないと即断することは、到底できないからである。さらには、もしこの場で「できる」といい切ったにもかかわらず、後になって結果が覆ってしまえば、クライアントの信頼を大きく失うことにもなるからだ。そのような理由からも、クライアントとの打ち合わせの場では、あいまいな表現を用いることが望まれる場面が多い。

　しかし、あいまいな表現を用いることは、時として聞き手に誤解を与えることも少なくない。以下では、その誤解を生む表現について筆者のエピソードをもとに紹介しよう。

■PMへの報告に対しての指摘

　われわれのプロジェクトも長かった製造フェイズが終了し、ようやくシステムテスト・フェイズへ突入した。システムテスト・フェイズでは、システムテストでの具体的な計画立案はもちろん、今後実施するユーザーテストや並行本番（既存システムを動かしながら、新システムも同時に動かすこと）に関する課題の検討、タスクの洗い出しなども同時に行う必要がある。当然、それに伴ってPMや先輩SEへテストの結果や懸念事項などを報告する機会が増えてきている。そんな中、システムテスト中にプログラムにバグが発見され、そのプログラムの修正完了をPMに報告した際、筆者は次のようなやりとりをPMとした。

PM　「この前のバグ修正はもう終わった？」
私　「はい、終わっています」
PM　「その修正で、ほかのプログラムにバグが混入しているということはないか？」
私　「ええ、していないと思います」
PM　「思います？ バグが混入していないと思い込んでいるだけじゃないのか？ きちんと確認したのか？」

　筆者は、プログラム修正前にそのプログラムの設計書を十分確認しており、バグを修正することによってほかのプログラムに影響を与えることはないだろうと予測したため、PMへの報告でこのような表現をしたのだ。

　しかしPMは、筆者が何の確認もせずに自分の思い込みで発言をしているように受け取ったのだろう。同じような例として、テスト計画のすり合わせを行う打ち合わせの場で、とあるSEとPMとの間で次のようなやりとりが行われた。

PM　「ユーザーテスト計画の件はどうなっている？」
SE　「その件はクライアント側で計画してくれていると思います」
PM　「それは『クライアントが計画してくれているだろう』と勝手に思い込んでいるだけじゃないのか？ きちんと連絡はしたのか？」

　こちらも、そのSEは事前にクライアントと連絡を取っており、いまはクライアントが計画してくれている段階であると予測できたために、このような発言をしたのだった。しかし、PMは、そのSEがクライアントに何の連絡もせずに「期待して待っているだけ」のように受け取ったのだろう。

　上記の例のように、あいまいな表現によって、聞き手側が誤解してしまうケースは日常の会話でも多く存在する。今回のPMのように、誤解してしまう可能性を指摘してくれれば特に問題はないのだが、場合によってはその聞き手側の間違った解釈が、後に大きなトラブルを引き起こす可能性もあるのではないだろうか。では、われわれSEにとって必要な表現力とはどのようなものなのだろうか。

■的確に聞き手に伝える表現力を身に付ける

　日本には「お互いの気持ちを察しあう」という文化が存在する。つまり、話し手がすべてを語らなくても、その言葉の裏側に存在する意味を、聞き手がくみ取ってあげるというのが日本人のコミュニケーションにおける慣例となっているのだ。しかし、言葉足らずのあいまいな表現は、上記の例のように相手に誤解を与えてしまうことも多い。やはりわれわれは、誤解を招かないためにも、聞き手側が正確に受け取ることができるような表現をしなければならない。

　先ほどのやりとりを例に挙げると、

PM　「その修正で、ほかのプログラムにバグが混入しているということはないか？」

というPMの問いに対して、もしも事前にバグ混入の可能性を確認しているのであれば、

私　「このプログラムの設計書を確認したのですが、ほかのプログラムとの関連性がなかったことが確認できたので、ほかのプログラムにバグが混入していることはないと思います。回帰テストは必要でしょうか？」

といったような表現をする必要があるだろう。仮に、確認はしていないものの、修正内容が単純であり、バグ混入の可能性が少ないと判断したのであれば、

私　「プログラムの設計書は確認していませんが、修正内容が単純だったので、ほかのプログラムにバグが混入していることはないと思います。一度設計書を確認しておいた方がよいでしょうか？」

といった表現が適しているのではないだろうか。筆者はこのような表現を心掛けるために、次のような3つのポイントを常に考えるようにしている。

ポイント1　質問された内容に対する事実は何か
ポイント2　事実によってどのような答えが導き出せるか
ポイント3　その答えに対してフォローが必要か

　これを上記の例と照らし合わせると次のようになる。

【質問された内容に対する事実】
設計書を確認し、ほかのプログラムとの関連性はないことを確認

【導き出した答え】
バグ混入の可能性は低い

【フォローが必要か】
回帰テストが必要かどうか

　これらを踏まえて表現することで、聞き手側の誤解を招くことをかなり防げるだろうと筆者は考える。即座にこの判断をするにはそれなりの鍛錬が必要ではあるが、クライアントへ提案することも多いSEにとっては、誤解を与えない表現をするスキルを身に付けることは非常に重要であろう。

■SEに必要な表現力とは

　冒頭に話したとおり、SEには「網羅的で正確な表現」と「あいまいな表現」を使い分けるスキルが必要とされる。しかし、どちらの場合にもやはりコミュニケーションの鉄則が存在する。

　この鉄則とは、前回（「第7回 開発現場のコミュニケーションを高める3つの方法」）でも話したとおり、「相手が考えていることや望んでいることを察知し、それに応じた発言や行動を取ること」である。保険をかけたあいまいな表現を用いる場合でも、聞き手がその発言をどのように受け取るかを事前に察知し、誤解を招かないような表現を心掛けることが重要であろう。

　たった1回の誤解を生む表現によって、開発に大きなトラブルを招く可能性もある。そのことを念頭に置いて、われわれSEは常に状況を読み、相手に誤解を与えない表現を心掛けなければならないのだ。

筆者プロフィール

山野寛（やまのひろし）●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント／サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。