エンジニアは建築家と医者の両方の側面を持っているという話
概要
先日、Twitter で 「『1時間の作業の工数の見積もりに30分かかる』ことに驚いている顧客にどう説明したらいいか」という Tweet が流れてきた。
自分は元々バックエンド系の仕事を中心にしているのだが、最近は DevOps 的な仕事の進め方をすることも多く、 エンジニアでない人とやり取りをする機会が増えている。 すると、やはり時折こういった場面に出くわすことがある。
最初は自分も驚いたり、こんこんと業務プロセスの話をしたり、と正面からアプローチしたこともあったが、 思うようにいかないことも多かった。 それもそのはず、専門外の人からすれば、システム開発のプロセスやフェーズなど、説明されてもちんぷんかんぷんなのである。(新人時代を思い出してほしい)
一方で、適切なたとえ話をつかって、細かい部分を端折って根気よく説明をすると、 専門でない人であってもしっかり理解してもらえることに気づいた。
エンジニアからすると、非常に面倒な説明であることに変わりないのだが、一方でこちらがやろうとしていることを 適切に知ってもらうと、そのあとの Ops サイドの人たちとの連携もしやすくなる。 ので、最近は少し時間を取って説明はするようにしている。
医者の例えと建築家の例え
何度かこういったやり取りをしているうちにハマる傾向が強いと思ったのは、「医者」の例えと、「建築家」の例えである。
医者：非常に厳しい制約の下、慎重に検査、検討を行い、全体（人の体）がうまく動くようにする
建築家：自由度を持って作ったり壊したりできるものの、特定の制約（例えば耐震強度とか）を守りながら進めていく
※ なお、自分は医療業界にも、建築業界にも全く詳しくはない。
このたとえは別に自分がゼロから考えたわけではなく、医者の例えは品質管理系の仕事をしていた時、 建築家の例えは、プロジェクトマネージャーの仕事をしているとき、それぞれ語られていた例えの受け売りである。
緊急だが、品質面の心配が必要な時、例えば、「簡単でいいから治して」のような要求があったときは、医者の例えで、 大規模だが、無茶なコストカットの要求があった時は、建築家の例えを使う、といった具合だ。
片方のイメージが定着すると陥る危険
一方で、通り一遍等で上記の例えを使っていると、逆効果になる場面もある。
医者の例えを使いすぎると、ちょっとした修正でなおる課題も、顧客が相談してくれなくなる。 建築家の例えを使いすぎると、システムの根幹に関わる修正を、気軽に依頼してくる。（見積もりを提示すると、「簡単でいいから安くして」になるやつである）
なぜうまくいかないのか
これらの例えを使うことで、なぜ正確なニュアンスが伝わらないことがあるのか、考えてみたところ、次のような仮説にたどり着いた。
エンジニアは開発を進めていく中で、システムを「モノ」としてとらえているフェーズと、 「生き物」としてとらえるフェーズ、二つのフェーズが存在し、それが専門外の人間から見れば全くわからない。
ということだ。
エンジニアからすれば、それはプロセスを進めるうえで明確なのだが、しかし、発注している顧客から見ると、 「なんだか言っていることがころころ変わって騙されている」ような気がしてくるのである。
動き出す前のシステムは、「生き物」ではなく「モノ」
モックアップや設計のフェーズであれば、簡単な修正だったら、とりあえず試してみたり、機能を 追加したり落としたり、といったことを割と簡単に行える。
建築家の例えで言えば、「柱を減らして」のような、根幹に関わる修正はさすがにNGであろうが、 間取りを変えたり、壁紙を一部変更、といったことは、ある程度柔軟に受け入れることができる。
動き出したら、システムは「生き物」になる
一方で、テストフェーズを超えたあたりから、システムは、モノから生き物に変化する。 一見簡単に見える修正も気軽には行いづらくなり、エンジニアも慎重に話を進める必要が出てくる。
文字通り、システム全体が死んでしまわないように、「生き物」としてとらえて、各種センサーの数値を測定しながら慎重に検査をしながら進める必要が出てくるのである。
エンジニアは、そんな大事な命をお預かりする身なので、「ちょっとお腹を開くだけだから、 検査なんかしなくて大丈夫です」 とは口が裂けても言えないのである。
エンジニアが、リリース直前になって、「カンタンな」仕様変更でも渋るのは、こういった理由からである。
コントのように進むプロジェクト
一方、顧客の立場で、システム開発を一気通貫で、しかも何度も経験する、という人は 稀である。そのため、多くの場合、顧客はエンジニアの一方の側面しか知らないことがおおい。
とはいえ、長期間にわたって仕事を一緒にしていくのだから、これら側面の違いや変化を自覚、確認せずにプロジェクトが進むなんて、顧客の怠慢だ、と思うかもしれない。
ところが、実際はまるで某芸人のコントのように、表面上で何となく話がかみ合っているかのようにプロジェクトが進み、 要所要所でおかしな現象を引き起こしながら疲弊している現場は多い。
例：
患者「（頭が痛いので）治してほしいんですが」
建築家「今すぐドリルで穴開けます」
患者「簡単に言わないでください！」
例２：
家が欲しい人「やっぱりこの二つは付け替えてください」
医者「（右の肺と左の肺を入れ替える手術は）リスクが高すぎます！」
家が欲しい人「左右を入れ替えるだけで何を言ってるんだ？！」
現実世界では
上に書いたのはあくまでジョークの一環だが、現実世界にするとこんな感じで、 とても笑っていられない。
医者と話しているつもりで、建築家と話している人
エンジニアのことが、「やたらと手術を提案してくるマッドサイエンティスト」に見えてしまう。
- 不信感から、本来の悩みを相談できなくなる。
- セカンドオピニオン（コンペや情報収集、比較検討）を繰り返して、時間を無駄にする
- 実際は少しのコストで解決できる課題を何度も繰り返し検討しているうちに、いつしか手遅れな状態になってしまう。
- はたまた、悪徳なコンサルの耳心地のいい提案に乗って無駄な投資をしてしまったりする。
建築家と話しているつもりで、医者と話している人
簡単な手術は気軽にできると思ってしまう。
- 「検査」に工数がかかることを見落として、コスト高の見積もりに激昂する。
- 無茶な工数削減を繰り返すあまり、検査をおろそかにさせて、結果、危険な作業をさせてしまう。
- これらのやりとりの繰り返しでいつしか重大なトラブルが発生し、責任の押し付け合いや裁判沙汰に発展する。
顧客だけが勘違いしている、とも限らない
自分も、エンジニアしか経験していなかったときは、これらはすべて顧客のみに起こりうる問題だと考えていたことがある。 が、一方で、顧客サイドも何度か経験させていただいた経験からすると、単純なパターンだけでない現場もいくつかあるということがわかってきた。
上記は顧客『だけ』が相手の立場『のみ』を理解していないパターンで、実は割と単純な構造だったりする。冒頭に書いた通り、エンジニアが丁寧に説明を試みれば、解決するパターンも多い。
より複雑なパターンは、それぞれ、互いの立場、そして、自分自身の立場さえ勘違いしている、なんてこともあるのだ。
つまり、エンジニアは、「自分は医者だと思っている建築家」や「自分は建築家だと思っている医者」。顧客は、「頭から血を流しているのに、家のリフォームを優先する患者」や、 「雨漏りを放置して、何度も風邪をひいて医者に行く顧客」、それぞれ入り混じっているのだ。
すると、話はもうちょっと複雑になって、現場目線では全体的な構造が見えにくく、 ちょっとした人狼ゲーム状態になる。
懐疑的なコミュニケーションで、罪のない人（顧客やエンジニア）を追放したり、オオカミ（自社の課題）を放置して全滅してしまうのは、 ゲームの中ならいざ知らず、現実で起こると割とえげつない。
自分と相手の立場を理解してから進める
ひどく当たり前の結論だが、全員が自分の立場と相手の立場を理解していれば、 大きなトラブルになる前に防げる問題も多い。
エンジニアは顧客の業務課題、顧客はエンジニアの業務プロセス、それぞれ互いに理解するのは 言うほど簡単ではなく、時間もかかる。 それでも自身の専門にとらわれず、また、過去の経験にしがみつかずに、努力して、 エンジニア、顧客の双方が課題に向き合って解決する現場、というのが増えればいいなと思っている。