【「スゴ本」中の人が薦める】技術書は教えてくれなかった。悩めるエンジニアに新たな考え方をもたらす6冊

自分の責任ではないバグなのに、自分のせいにされてしまい、なおかつ納得させられてしまった経験はあるだろうか。私はある。すごくモニョった。

目まぐるしく変わる開発技術やビジネス環境に対し、基準となる考え方が欲しいと思ったことはあるだろうか。私はある。すごく不安だった。

ここでは、そんなエンジニアのお悩みに応える本を紹介する。

いわゆる技術的な問題であれば、スキル上げとリソース投入で解決できるかもしれない。だが、そうした方法では難しい問題は、今までとは異なる観点からの見方や、経験の先取りといった手法を必要とする。ここでは、エンジニアが直面するお悩みに対し、エンジニアの技術書コーナーにない書籍を紹介する。

 

• keyboard_arrow_down コントロールできること／できないことを見極める技術
• keyboard_arrow_down 説明を「押し付ける」技術
• keyboard_arrow_down 問題を外在化させる技術
• keyboard_arrow_down 話しやすいチームにする技術
• keyboard_arrow_down エンジニアの倫理を鍛える
• keyboard_arrow_down おわりに

前任者から引き継いだプログラムに、大きな不具合を見つけたことがある。

書いた人はすでにいないため、なぜそれを放置したのか、聞くことはできない。通常であれば顕在化しないが、あるパターンに陥ると、大問題となる。

ところが、次に予定されている仕様変更を入れると、顕在化するリスクがある。修正にはそれなりのリソースを必要とする。

これ、いま直しておくべきなのか。仕様変更の内容によっては問題にならないかもしれないが、変更内容が煮詰まっていないので未知数だ……。

結局、不安になるあまり、一人で直そうとした。だが、中途半端な修正のため、問題となった。さらに、自分の担当した箇所で発生したため、責任を問われることになった。良かれと思ってやったことが裏目に出て、涙目になったことを覚えている。

あの時の私に薦めたいのが、エピクテトスだ。

『語録 要録』エピクテトス、中公クラシックス

エピクテトスは、古代ローマの哲人だ。奴隷出身で苦難の人生を歩んできた人だが、その言葉は強い説得力を持ち、何千年も生き続け、この一冊に集約されている。

『語録 要録』では、さまざまな問答がなされているが、エピクテトスの原則はシンプルである。

「自分の権内と権外を適切に見極めよ」

見慣れぬ言葉があるが、要するにこうだ。

• 　　権内＝自分がコントロールできるもの
• 　　権外＝自分がコントロールできないもの

重要なのは、権内か、権外か、両者が適切に区別できていること。これこそが人にとって幸福な状態だという。

エピクテトスは、心に沸き上がるあらゆることに対し、この基準をあてがってみろと言う。そして、権外であれば捨て去れと断言する。なぜなら、人を不安にするものは、事柄ではなく、事柄に関する考え方なのだから。

『語録 要録』は古典であり、そのまま読むのが大変なら、『その悩み、エピクテトスなら、こう言うね。』をお薦めする。エピクテトスの考え方を、現代の進路や仕事、人間関係の悩みに当てはめて、対談形式で解説する。

『その悩み、エピクテトスなら、こう言うね。: 古代ローマの大賢人の教え』山本 貴光、吉川 浩満、筑摩書房

あの時の私が、もしエピクテトスを知っていたら、こう考えることができたはずだ——「仕様変更が最終的にどういう内容になるかは、権外だ。だから考えなくてもいい。だが、不具合を知っていることは、権内だ。だから、顕在化の可能性をアナウンスして、リスクを引き受けるか、皆で考えよう」——そうして、皆を巻き込んでいただろう。

問題を見極める時、権内となる要素と、権外にすべき要素を、分けて考える。そして、権内にリソースを集中する。そうすることで、何でも抱え込んで悩み続けることが無くなる。

同じことを、イチロー選手も言っている。首位打者争いをしているとき、ライバル打者について話題が及ぶと、「相手の打率は、僕にはコントロールできません、意識することはありません」と打ち切ったという。

コントロールできることと、コントロールできないことに分ける。そして、コントロールできることのみに集中する。これだけで、お悩みの自己負担は、かなり軽くなるだろう。

説明を「押し付けられた」経験はないだろうか。

「この変更は、今月中に対応してリリースすべきです。お客さんも喜ぶし、ウチの利益につながるので、絶対に必要です。逆に、なぜできないのでしょうか？ できない理由を聞きたいのではありません。どうすれば間に合わせることができるのか、そのために何をすればよいのか、それを考えるのは、エンジニアの仕事でしょう！」

こんな風に、営業から言われたことはないだろうか。私はある。しょっちゅうだ。

多分この営業、お客さんに「できます」と言っちゃった手前、引き下がれないんだろうと思いつつも、「なんで私が説明するのか？」という疑問がつきまとう。

そもそもスケジュール的に無理があること、変更のインパクトがどの程度なのか分からないこと、当初の予算内に収まるかも分からないことを説明する。あたかも、できないことが私の罪で、その罪を免れるための言い訳をしているような気にさせられる。

逃げられない会議の席上でそんな流れになり、できない理由をしどろもどろに言わされて涙目になったことがある。

あの時の私に薦めたいのが、『議論の技術』だ。

『議論の技術』倉島保美、講談社ブルーバックス

『議論の技術』は、よい議論のためのルールとメソッドを、丁寧に説いている。

似たような本は沢山あるが、類書より飛び抜けて優れた点がある。それは、ルールを逆手に取った詭弁を見抜き、対策までしてくれるところだ。議論の技術とは、ルールブレイカーを追い詰める技術なのかもしれない。

「よい議論」とは、主張のメリット・デメリットを掘り下げ、お互いにとって望ましい結論を導き出せる話し合いのこと。詭弁を弄し、言いたいことをまくし立て、マウンティングで勝ち負けを決めるようでは失格だ。

この本を読むと分かる。かつての私が失敗したのは、「なぜできないのでしょうか？」という質問に、答えようとしたからだ。

人というのは不思議なもので、「なぜですか？」と聞くと、反射的に答えてしまうもの。そしてエンジニアというのは真面目なもので、なぜ難しいのかについて、できるだけ正確に答えようとしてしまう。

それは罠だ。できない理由を裏返すと、それさえクリアすればできるから、それをクリアするための方法を皆で考えよう、という流れになってしまうから。

正しくは、「その質問に、なぜ私が答えなければならないのか？」という視点だ。

いま進行しているプロジェクトは、決められたリソース内で、合意された成果物を生み出すためのものだ。それを、わざわざ変更したい、と言い出しているのは、営業だ。だったら、なぜ変更しなければならないのかについて、答えなければならないのは、言い出しっぺの営業になる。

その変更に対応できる／できないとかの議論の前に、それを今しなければいけない理由を、きちんと説明してもらおう。

本書では、これを「立証責任のルール」として解説している。要するに、言い出しっぺが証明しなければならないというルールだ。議論が上手い人は、立証責任を押し付けるのが上手い人だと言えるだろう。

これは悪用もできる。たとえ自分が言いだしっぺで、立証しなければならない場合でも、「あなたは反対なのですか？ なぜ反対なのですか？」と質問することで、立証責任を相手に負わせることができる。本書では、立証責任の負わせ方、かわし方が沢山の事例とともに紹介されている。

「できない理由」を説明させられて閉口したエンジニアなら、武器となる一冊となるに違いない。

トラブルが起きたときや、厄介な問題にチームで取り組むとき、最も役に立つツールは何か？

私の場合、それはホワイトボードになる。

トラブルが露見した直後は、たいてい混乱している。火を噴いている問題の「事象」は見えていても、原因は分からないし、どの程度の影響がありそうかも見えない。先に火を消すのが有効か、まず延焼を食い止めるのが先か分からない。

それに対し、チームの皆がバラバラの情報を持っている。原因に近い情報を知っている人、どんな影響になりそうか予想できる人、問題の爆発を止められる人、真の原因を抱えている人、バラバラだ。

そんなとき、「誰」が問題か？　という犯人探しを始める人がいる。「このバグが悪いので異常終了した」とか、「悪さをしているコード」など、「悪」という言葉を好んで使い、「問題を作り込んだ人が悪い」という追求の仕方をする。

すると、メンバーは互いに疑心暗鬼に陥り、犯人にされたくないため、口数が少なくなる。問題は誰かが持っている「悪」であり、問題の押し付け合いになる。ギスギスしてくると、問題ではなく、人格攻撃になることもある。

そうした、犯人探しから逃れるために有効なのは、ホワイトボードになる。

問題を抱え込んでいる「誰か」がいるわけではない。だから、問題をホワイトボードに書き出すのだ。いま噴いている火そのものが問題ではなく、ひょっとすると燃料が漏れているのかもしれない。だから、「解決すべきこと」とか「現状」といった見出しにする。

そして、その「現状」に対し、原因と思われるもの、影響や対策をどんどんヒアリングしていく。ポイントは、ホワイトボードに注目してもらうところ。「誰か」が悪いのではなく、ホワイトボードに書いた「何か」がうまく動いていないことを強調する。書き出された「何か」に対し、質疑応答を繰り返していく。

問題は「人」ではないのだ。仮に問題があるとしたら、それはホワイトボードにある。火種に詳しいからといって犯人扱いされることもなくなる。これが浸透していくと、チームの皆は安心する。率先して答えてくれるようになる。

このやり方は、『問題解決大全』で学んだ。

『問題解決大全』読書猿、フォレスト出版

「あらゆる問題は誰かが検討済み」という考え方に立ち、様々な学術分野で培われた技法が、37のツールに結集されている。「巨人の肩の上に立つ」というニュートンの言葉を借りるなら、「巨人たちの肩の上に立つ」のが、『問題解決大全』と言ってもいい。

そのツールNo.30に、「個人攻撃の罠」が紹介されている。

個人攻撃の罠とは、うまくいかないことがあると、その原因を自分や他人の性格や能力、やる気や適性のせいにしてしまうことだという。ここにハマり込むと、問題の根本原因は人にあるとしてしまい、犯人を見つけて罰すれば問題解決となってしまう。

そうさせないために、問題を外在化させる。問題を擬人化し、その「問題さん」にインタビューをすることで、人ではなく、問題そのものと向き合えるようにするのだ。

私はここからヒントを得て、問題をホワイトボードに書き出し、それへの質疑応答という形で取り組むようになった。

コロナ禍の現在、リモートワークが中心のため、「皆がホワイトボードの前に集まる」なんてことは少なくなった。なので、今は「メモ帳」がホワイトボード代わりとなっている。オンラインミーティングでは、メモ帳アプリを立ち上げて、画面共有する。そして、どんどん書き足していくことで、問題を外在化させる。

もし、問題について私の理解が誤っていれば、それはすぐにメモ帳の文章で可視化される。メンバーは容赦なく「それは違う」と言ってくれる。誤りなのは私ではなく、「メモ帳」なのだ。言うほうも聞くほうも気楽になる。

この「気楽さ」が大切だ。

気づいたことを気楽に言える空気を作り出し、メンバーが安心して意見できるようにする。なあなあの慣れ合いではなく、互いに尊重しながら、率直に話し合える雰囲気だ。

これはなかなか難しい。新しい職場に移ったり、メンバーが入れ替わったりすると、こんな不安が出てくるからだ。

• 　　・こんな基本的な質問をして、無能だと思われないだろうか
• 　　・このミスを認めてしまうと、詰められたり、罵倒されたりしないだろうか
• 　　・余計なことを言って、会議を脱線させたと思われないだろうか
• 　　・せっかく前向きのいい流れになっているのに、ネガティブな意見を言って反感を持たれないだろうか

そんな不安を抱えたままだと、何でも気楽に言えなくなる。課題を見つけて報告すると、「じゃあキミがそれやって」と押し付けられたり、問題が露見すると犯人探しをするようなチームでは、皆が委縮し、本来の力を発揮できないだろう。

こういう状況を抜け出し、チームメンバーが安心して話せる雰囲気のことを、「心理的安全性」と呼ぶ。Googleの研究発表をきっかけに広まった用語だが、ある程度キャリアを積んできている読者では、「話しやすい職場」「話しにくい職場」という言い方がピンとくるかもしれない。

話しやすいチームにするには、『心理的安全性のつくりかた』が心強い味方になる。

『心理的安全性のつくりかた』石井遼介著、 日本能率協会マネジメントセンター

「これが正解」というものが見えなくなっている。そのため、トライ＆エラーをくり返し、チーム全員の考えを集め、軌道修正しながら正解に近づける必要が出てきている。

そんな状況で求められる「話しやすい職場」すなわち心理的安全性の高いチームを作り上げるためのノウハウを結集したのがこれだ。

これ一冊で網羅されているが、特に雰囲気づくりにヒントになるのは、リーダーの口癖の実例だ。

たとえば、「それはちょーどよかった」。いつ使うべきかというと、大きなトラブルが発覚した時の第一声だ。問題が起きているのに、「それはちょうど良い」とは何事だ！？ と思うかもしれない。

しかし、トラブルはすでに起きたことだ。「発生した」という事実は変えられない。だから、トラブルに対して自分の中で湧き上がってくる思考や感情と「戦う」のではなく、いったん「受け容れる」ことが肝要だという。

そして、焦る気持ちに動かされて犯人探しをするのではなく、起きたことに対し、現実的に向かい合う。そのためのきっかけとなる言葉が、「それはちょーどよかった」になるのだ。

私の場合だと、「ありがたい、いま知れてよかった」になる。いつも私は、失敗すること、最悪のことをよく考えるのだが、心配事のほとんどは起こらない。起こったとしても最悪には至らない。

だから、最悪になる前に、いま知ることができて良かった、と感謝から始める。部下がミスを報告しても「いま分かったので助かる」だし、自分がやらかした失敗は「大事になる前で良かった」と発言する。この口癖は、話しやすいチームづくりの一助となっているはずだ。

おそらく、今は悩んでいないかもしれない。だが、近い将来、直面することになるかもしれない問題について、予習しておきたい。

それは、モラルの問題だ。

たとえば、偶然にも、構造的な設計ミスを見つけたとする。プロジェクトは既に進行しており、リリース目前の段階だ。今からそのミスを指摘して、作り直すような時間も予算もない。設計ミスが問題を引き起こし、大惨事につながる可能性は、比較的低い。上司に報告しても、取り合ってくれない（知らなかった／聞かなかったフリをする）。

そのとき、どうすれば良いのか？

もし、自分の良心を優先し、設計ミスを告発し、公けに訴えたならば、リリースを差し止めることはできるだろう。たとえ可能性は低いとはいえ、そんな問題を抱えたまま、運用していくのは社会が許さないからだ。

だが同時に、それは自分の立場を危うくすることにもなる。いちエンジニアが、経営レベルに影響を及ぼすブレーキをかけたからだ。当然、（聞かなかったフリをした）上司も呼び出され、説明を求められることになる。人間関係は最悪になるだろう。場合によっては、職を失うかもしれない。

声を上げるべきか、口を噤むべきか。この問題について、様々な事例とともに掘り下げているのが、『そのとき、エンジニアは何をするべきなのか』だ。

『そのとき、エンジニアは何をするべきなのか』Alastair S Gunn/P Aarne Vesilind、森北出版

エンジニアのモラルを問われるような判断を、どう扱うか。人によっては、某巨大銀行の勘定系システムのことを思い起こすかもしれない。だが、本書で挙げられている事例は、スペースシャトル・チャレンジャー号の爆発事故や、シティコープ本社ビルの設計ミスになる。

断っておくが、ここに「正解」が書いてあるわけではない。

「設計ミスによる大惨事を、たった一人のエンジニアが気づく」のは、ドラマティックな設定だが、現実としては起こりにくい。また、人命に関わるようなものから、収賄や汚職のようなものまで、様々なパターンがあり、接し方も変わってくる。

だから、それぞれの事例に対し、当事者が何を考え、どう行動したかが記されている。特に、小説仕立てのパートでは、主人公の内面の感情まで掘り下げて描かれており、読者は「自分ならどうする？」と嫌でも自問させられる。

私が本書で学んだのは、良心の共有だ。

一人で抱え込むのではなく、上司だけに報告するのでもなく、チームで考える。幸いなことに、大事になるような設計ミスを、たった一人で見つける……なんて経験をしたことはない。だが、モラルを問われるような判断が必要な場合は、自分の良心だけに従うのではなく、「この考え方で合っているか？」とチームに問いかけている。要するに、良心をチームで共有した上で、判断するのだ。

合計6冊、紹介した。

自分の問題として扱うか、どうやって割り切るか。「できない理由」の説明を押し付けられたら、どうやって対応するか。大きなトラブルが起きたとき、どんなツールを使えばよいか。話しやすいチームにするための口癖は何が良いか。モラルを問われるような判断に迫られるとき、何に頼ればよいか。

どれも、エンジニアが直面する悩みにもかかわらず、エンジニア関連のコーナーには無い書籍ばかりだ。

それぞれの問題について、今まさに悩んでいるなら、ぜひ手に取って参考にしてほしい。また、将来、そうした不安がありそうならば、今のうちに予習しておくのも良いかもしれない（私はいつも、問題が起きてから本を探してきた。泥縄だね）。

繰り返す。あらゆる問題は、すでに誰かが検討している。自分にとっては初めてかもしれないが、検討した「誰か」が残した技術を、まずは参考にしよう。