SEに最も必要となるのはITに関する深い知識と経験です。
SEはIT技術者という専門職なので、それは当然です。
また、SEの仕事はお客様の業務を効率化し、感謝される仕事ばかりではなく、不具合などの失敗を責められたり、都合の悪い内容について返答を求められることも多々あります。
話は変わり、日本の政界や官僚の答弁では、最近「ご飯論法」と呼ばれる不誠実な話法が流行っています。
百戦錬磨の政治家や高学歴で秀才の代表職である官僚が駆使するこの不毛なテクニックですが、我々SEも会話のなかでこのテクニックを取り入れることで、都合の悪い論点をすり替え、回答をはぐらかし、面倒な質疑を打ち切ってしまうことも可能です。
そんなSEにとってとても大切な話法、論法を紹介していきます。
都合の悪い問いにはご飯論法を活用しよう
皆さまは「ご飯論法」をご存知でしょうか？
「朝ご飯は食べたか」という質問を受けた際、「ご飯」を故意に狭い意味にとらえ、（パンは食べたにも関わらず）「ご飯（白米）は食べていない」と答えるように、質問側の意図をあえて曲解し、論点をずらし回答をはぐらかす手法である。
Wikipedia ご飯論法より抜粋
残念ながら我が日本の某総理大臣も得意としているテクニックであり、最近の政治家や官僚が挙って取り入れている、誠実とは真逆の話法です。我々SEのおいてもシチュエーションをよっては有効な話法なので、はぐらかしの場合においては積極的に使ったいきましょう。
SEにおいて問いに対して回答をはぐらかしたい状況は度々発生します。
- 納品したシステムで不具合が発生し、顧客のもとに営業と謝罪赴いた際に具体的な対策を求められたとき。
- 顧客の合理的ではないシステム要件をそのまま受けてしまい、その機能を実装する必要性をプロジェクトメンバーから問われているとき。
- 適当に余裕をみて算出した見積もりの工数に対して、顧客から具体的な根拠の説明を求められたとき。
などなど。
こんなときは相手の問いに対してそのまま答えてしまうと、自身が責められてしまったり、責任を持たされたり、色々面倒です。出来ることなら問いについてははぐらかし、そのまま有耶無耶にできたら良いですね。
ではここで、「ご飯論法」について定義をしてみましょう。
ご飯論法の定義
ご飯論法では嘘はつきません。
質問者の問いの趣旨に沿っているかは別にして、返答内容は真実である必要があります。
ここがポイントで、もし嘘をついていた場合は、返答をした場所や状況によっては「虚位の答弁」をしたとみなされ、処罰を受ける対象になりますが、嘘をつかなければ質問の意図を取り違えたと言い逃れをすることができます。
第三者がそのやり取りを見ている場合、返答内容が質問の内容に沿っているかをちゃんと意識していないと、一見普通に受け答えをしているように見えます。
当然質問した本人は質問の意図と全く異なる返答が来るので、聞いたことに対して答えていないことは明白なのですが、第三者からそのやり取りがどのように映っているのかも重要です。
質問者の問いに対して、故意のミスリード、スコープの拡大及び縮小、一般論への置き換えなど、あらゆる方法ではぐらかします。
後述しますが、そのはぐらかす際の話法にはパターンがあり、問いの内容やおかれている状況ごとに最適な話法を選択して返答をします。
論法パターンとその使用例
ご飯論法の命名の由来でもある話法パターンです。
「ご飯」という言葉について、広義な言葉の「食事」という意味を持たせた文脈にも関わらず、故意に狭義な言葉の「お米」と解釈して返答を行う話法です。この論法の有利なところは、虚位の返答をして、その虚位がばれて指摘を受けた場合にも言い逃れができるところです。
ご飯論法の定義でも「嘘を言わない」と記載しましたが、例えば「朝ご飯を食べたか？」という問いに対して、「食べていません。(朝に食事はしたが、食べたのはパンであり、米ではない)」と答えた場合、朝ご飯を食べたかどうかの問いに対しては嘘をついたことになります。
もしこの嘘でその場が丸く収まり、それ以降の追求が無ければそれで良し。
その後、その嘘がばれた場合でも、あの時の返答はあくまで「米を食べていない」という意味だったと説明することで、嘘はついていないと言い張ることが可能です。
まさに二段構えの強力な話法です。
使用例
顧客：納品されたシステムでは不具合が非常に多い。”システムテスト“はちゃんと実施しているのか？
SE ：はい、実施しています(“単体テスト“や”結合テスト“はサボってほぼやっていないが”システムテスト“は納品物のドキュメントに指定されているため実施した)。
これは問いの主となる内容について、定義が不明確としてはぐらかす手法です。
ご飯論法的に言えば「ご飯」を「食事」として認めるとしても、じゃあその食事はどこからどこまでを「食事」として扱うのか、食後に出されたコーヒーは「食事」のなかに含まれるのかの難癖をつけて、そもそも「食事」の定義が曖昧で答えることができないという理由で回答することを拒否します。
正確性を重んじるSEにはぴったりの話法ですね。
使用例
顧客：納品されたシステムの”レスポンスが遅い”が改善できないか。
SE ：そもそも”遅い”の定義が曖昧。システムの適切なレスポンスの定義が曖昧なので、その質問には答えられない。
これは、問いの内容を勝手に大きな規模に置き換えて、返答が困難として質疑を打ち切るテクニックです。
ご飯論法的な例では、朝ご飯を食べたかという問いに対して、「日々の食事の一件一件を開示していては、食生活全てを開示すことと同意であり、食生活全ての開示するように求める質問には答えられない。」といった受け答えになります。質問者は朝ご飯を食べたかという局所的な問いをしているにも関わらず、内容の規模を極端に大きなものや広いものにすり替えて、そんな無茶な質問には答えられないとして回答を拒否します。
一見こんな話法で回答を拒否しても、質問者は質問内容のスコープ規模を正したうえで再度同じ質問を繰り返してくることは明白であり、意味が無いように思えますが、この話法では同じ質問が来るたびに同じ返答を繰り返すことで議論を先に進めさせないという意味合いもあります。
同じやり取りが繰り返されれば、何れ相手は質問内容を変えざるを得ないでしょう。
使用例
顧客：納品されたシステムのログイン画面の仕様が要件と異なっている。修正してほしい。
SE ：個々の仕様の相違について個別に対応していくと、そもそもシステム全体をリプレースしているのと変わらない状態になり、そんな要求は受け入れられない。
これは、問いの内容について、勝手に一般論に置き換えて返答をして、個々の事案については答えないという話法です。
ご飯論法的な例では、朝ご飯を食べたかという問いに対して、自分自身の話ではなく、「一般論としては朝ご飯を必ず食べる人と食べない人がいる」とか、「一般論としては健康のためには朝ご飯をしっかり食べて一日をスタートさせることが重要だ」とかの話にすり替えて返答をします。また、一般論としての返答をする前に、相手の「質問の趣旨が分かりかねる」といった枕詞と入れておくとより効果的です。
使用例
顧客：結局、今回のシステムトラブルの原因は御社が作成したシステムの不具合に起因しているのかはっきりしてほしい。
SE ：質問の趣旨が分かりかねますが、一般論としてはシステムトラブルはシステムの不具合以外にも、ユーザー側の操作ミスやイレギュラーな業務の発生など、様々な要因で起こり得ます。
その他の話法・論法例
上記の「ご飯論法」については、相手との議論をはなからするつもりがない、またははぐらかしたいとい状況で使用する話法ですが、もしかしたら、国会では通用しても顧客との会議の場では通用しないかも知れません。
その為、普通に相手にコミュニケーションを取りつつ、巧みにミスリードを誘ったり、問題点を矮小化したりする正統派の話法も簡単に紹介しておきます。
※当初こちらの内容で記事を書こうと思いましたが、ご飯論法の方が面白いのでそっちを主にしました・・・。
参考までにご覧ください。
クラウドに責任を押し付けよう
ここで言う「クラウド」とは、IT用語のIaasなどのクラウドサービスではなく、「手の届かない相手」というイメージです。
具体的には「Microsoft」「Oracle」「Amazon」などのミドルウェア提供企業や、提供している製品などです。
自身が手掛けたシステムで不具合やトラブルが出ました。
こちらの実装の不具合に起因していても、サーバーOSの挙動やミドルウェアの挙動に関連したシステムの問題であれば、こちらのスタンスは以下です。
「正しく実装したはずだが、本来想定していた処理にならない。よって、Oracleデータベースの何らかの不具合の可能性がある。」
実際にOSの不具合やミドルの不具合はよくありますし、それを回避するために技術者が苦労しているケースも多いですが、原因不明な不具合の原因が実はOSやミドルの不具合でしたというケースも結構あります。
更にOSだったらMicrosoftだったりredhatだったり、ミドルならOracleなど、通常の顧客が直接不具合に対して問い合わせる機会の少ない企業や組織が相手です。
そこで問題が有るなら仕方がないという雰囲気になります。
だったら問題の原因はOSやミドルに転嫁し、なんなら更に「挙動のおかしい環境に対応するために余計な工数が発生する。我々も被害者だ。」と被害者面してしまうのも良いでしょう。
ただ、ポイントはOSやミドルの不具合だと断言しないことです。
断言してしまうと、まともな相手であれば、パッチの適用などの根本的な対策を求めてきます。
「可能性がある」と仄めかす程度にしてその場をしのぎ、そのまま有耶無耶にするのに有効な話法です。
不具合の影響範囲は広くても一部にしておこう
システムに不具合が見付かり、その影響範囲を調べたところ、ユーザーの大半が影響を受ける広域な事象でした。
ただ、一部のユーザー環境では正常に動作します。
また、対象の不具合は簡単に修正して再リリースできそうです。
そんなときは、正常に動作している事実だけに着目し、以下のように顧客に報告しましょう。
- 影響は限定的
- 一部の操作で発生
- 特定の条件下でエラー
もしありのままを顧客に報告したらどうなるでしょうか。
ユーザーの大半が影響を受ける不具合に納品して稼働するまで気付かなかったとしたら、テストをまともにやっていないのがバレてしまいます。
それでは信用問題です。
そんな報告はできる訳がありません。
今回のポイントは一部のユーザー環境であれば正常に動作するところです。
また、全てのシステム利用者が不具合の報告をしてきているとは限りません。
もしサクッと修正してリリースし直せるならそうして、不具合の詳細な影響範囲や、具体的な原因の報告を有耶無耶にして、次のプロジェクトに話題を移し、トラブルは無かったことにしていきましょう。
顧客としても、不具合の影響は一部、限られた条件下でのみ発生すると説明を受け、既に修正の手配は済みいつでも再リリース可能だと報告されれば、業者の迅速な対応に満足し、事を大事にせずに穏便に済ませてしまいたいと思うことでしょう。
本当の影響範囲や不具合の詳細はシステムを作った本人達しかわからないのですから。
不具合やバグ、障害という言葉は柔らかい言葉に置き換えよう
システムに不具合などのトラブルが発生し、顧客に対して説明や報告がする場合、言葉の選択が非常に重要です。
何も考えず「不具合」や「バグ」、「障害」という言葉を使ってしまうと、その言葉が持つネガティブな意味で認識が共有されてしまいます。
これは会議などの対面の場での発言でも、メールや報告書などの文面においても同様です。
どんな酷い不具合であっても、貴方がその不具合を「不具合」と呼ばなければ不具合では無いのです。
具体的には以下のような感じでどうでしょうか。
不具合 → 想定外の挙動
× 弊社が納品させて頂いたシステムで発生した”不具合“の件についての・・・
〇 弊社が納品させて頂いたシステムで発生した”想定外の挙動“の件についての・・・
どうでしょうか？
状況や内容にもよりますが、システム会社からしたら、「不具合」は”想定していなかった挙動”と読み替えても間違いではないはずです。
上記の様に”想定外の挙動”と置き換えたことで、何となく印象が柔らかくなり、且つ、不具合を出したシステム会社が悪いのに、何故かシステム会社が被害者かのようにも感じます。
システム障害 → 心配やご迷惑をお掛けした事象
× システムの高負荷に起因した”システム障害“についてですが・・・
〇 システムの高負荷に起因して、”心配やご迷惑をお掛けした事象“についてですが・・・
「システム障害」と呼んでしまうと、何だか致命的できつい印象を与えますが、それを”心配やご迷惑をお掛けした事象”という抽象的な言葉に置き換えることで、顧客の苦労を気遣い、誠実さすら感じ取れる印象に様変わりしました。
ハッキング・不正アクセス → セキュリティインシデント
× 弊社が管理する御社サーバの”不正アクセス“発生についてですが・・・
〇 弊社が管理する御社サーバの”セキュリティインシデント“発生についてですが・・・
一昔前に不正アクセス禁止法が制定され、「不正アクセス」という言葉はだいぶ世に浸透しており、経営層でもサイバーセキュリティを気にするような昨今ですが、自社がハッキングだとか不正アクセスの被害を受けた場合、事は顧客のシステム担当者や現場担当者を飛び越えて経営陣まで伝わっていきます。
そうなると、その管理をしていたシステム会社は何らかの責任を取る事態まで発展してしまいます。
「不正アクセス」や「ハッキング」などの言葉を”セキュリティインシデント”という、知識のない人であれば何だかよくわからない言葉に置き換えてしまうことで、あがってきた報告に対して経営陣は「またいつものよくわからないパソコンの話か」と聞き流してもらえることが期待できます。
また、”セキュリティインシデント”という言葉の響きは、不必要に連呼したくなるような格好良さも感じます。
最後に
今回の記事は参考になりましたでしょうか。
この記事を読んで頂いた方が、記事の内容を真に受けてそのまま実践することはさすがにないかと思います。
※ご飯論法に至っては、実践すると取引禁止になりそうですし。
ただ、トラブルや問題が起きた際に、ありのままを包み隠さず報告、説明することも当然重要ですが、問題点をオブラートに包んだり、大事に発展しないように適度にごまかしたりすることも時には必要だと考えます。
SEだって人間だもの。
ではでは、今回も読んで頂きましてありがとうございました。
それでは皆様ごきげんよう。
