2024年4月9日
古今東西のスゴ本(すごい本)を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。
わたしが知らないスゴ本は、きっとあなたが読んでいる
ITエンジニアにとっての「武器」といえば技術力だ。プログラミング言語をはじめとし、フレームワークやデータベースの知識、クラウド構築の経験やネットワークやセキュリティの知識など、多岐にわたる。この記事を読まれる方なら言わずもがなだろう。
釈迦に説法はここまでにしておき、ここでは、そうしたITテクノロジーの範囲に収まらず、なおかつITエンジニアにとって有用な「武器」となる指南書を紹介する。
現在あなたが身に着けているIT技術の他に、サブウェポンとなる能力だったり、あるいは、技術力そのものに永続的にバフをかける方法だったり、さらには先人が拓いたショートカットの知恵もある。いずれも、あなたの手持ちの技術と掛け合わせることで相乗効果が得られるものばかりだと請け負う。
少しでも気になるものがあったら、ぜひ手に取ってチェックしてほしい。あなたの手持ちの武器を増やし、強化する5冊だ。
1冊目は、『独学大全』だ。
「武器」というよりもむしろ、オールマイティの最終兵器で、「独りで学ぶ」ことなら、ここに出てくるやり方を実践するだけで上手くいく。
「そんな甘い話があるわけがない」と警戒する方もいるだろう。ムリもない、そういう方は、私も含め、いままでさんざん騙されてきただろうから。「1日15分だけで上達」とか「一冊でマスター」、あるいは「たった3ヶ月でペラペラに」という帯や惹句に引き寄せられて、さんざん無駄金を払ってきただろうから。
しかし、これは違う。
なぜ違うと言い切れるのかというと、私自身がこれを試して効果を確かめており、なおかつ、現在進行形で確信中だからだ。そして、どんな効果を確信しているのかというと、「学び続ける」になる。エビデンスはこれ。
Merriam-Webster’s Vocabulary Builder を毎日読みます。読んだ分を記録して公開します(2周目)。 #独学大全 #ラーニングログ #コミットメントレターhttps://t.co/Uas8DyN7ZN
— スゴ本の中の人 (@Dain_sugohon) March 10, 2024
独学大全で紹介されている「ラーニングログ」と「コミットメントレター」の実践例だ。「ラーニングログ」とは、自分の学ぶことを一覧化し、記録を取り続けることだ。
英語力を底上げするためには単語力、すなわちボキャブラリーを増やす必要がある。そのためにボキャビル本で有名な ”Merriam-Webster’s Vocabulary Builder” を毎日読む。ただしこの本、私にとってレベルが高く、読み干せたら力になる反面、挫折しやすいリスクがある。
だからこうする。
これだけ。
これだけで、1周することができた(現在は2周目の半分くらい)。学ぶことを習慣化し、全体のどこまで進捗しているのか可視化し、周期的にやってくる挫折の誘惑を把握する。これが「ラーニングログ」である。
そして3の、「毎日読みます」と twitter で明言することで、自分が続けていることを知らせる。別に報告義務なんてないし、そもそも誰も見ちゃいない。でも、だからこそ良いんだ。ただひたすら、約束を公言して、結果をアップし続ける。これが「コミットメントレター」である。
この2つの技法で2年かけ、7800語から1万語までボキャブラリーを増やすことができた(語彙力はpreplyでテストした)。
ここで重要なのは、続けられたこと。この技法が無ければ、間違いなく途中で挫けていた。毎日読むといってもペースにムラがあるし、できない日もあった。嫌になって投げ出しそうなときもあったのだが、結局はやり通すことができた。
継続はチカラというが、どうやって継続していくか、まさにそれが書いてあるのが『独学大全』なんだ。
挫けそうなとき、先が見えないとき、壁にブチ当たったとき、何をすればよいのか分からなくなったとき、ヤル気が出ないとき、「なんでこんなことをしているのだろう?」と疑問に思ったとき―――どうすれば良いかが全部書いてある(巻末の折り込み索引を見るべし)。
一点、注意を喚起したい。
本書は独学の百科事典を目指して書かれたものだ。かなりのボリュームがあり、いわゆる「鈍器本」と呼ばれている。手に入れたときの高揚感から、これを読むことを独学にしてしまう人がいる。
もちろん、通読することで技法の由来となった人物や史実に精通することができるし、独学へのモチベーションも上がるだろう。人類が積み上げてきた問題解決への叡智を学ぶ人文書として読むのも最高だ。
だが、全読を目的にしてはいけない。読むことを目的にしてしまうと、自分がやりたい独学が後回しになってしまう。あくまでもこれは事典なのだから、引いて使うべし。
ITエンジニアならお馴染みのこれ。
顧客、営業、プロジェクトリーダー、プログラマと、それぞれの立場によって、「作るもの」が変わってしまうことを、面白可笑しく描いている。ベテランなら「あるあるw」と笑うだろうし、新人なら「まさか!?」と驚くかもしれないが、本当だ。
この絵で注目すべきなのは、最初のコマと最後のコマだ。最初のコマは「顧客が説明した要件」であり、最後のコマに「顧客が本当に必要だったもの」が描かれている。つまり、「顧客が本当に必要だったもの」は、「顧客が説明した要件」ではない点が重要なんだ。
「顧客が本当に必要だったもの」は、もちろんプロジェクトリーダーの理解とも違う。設計とも、コードとも、ましてや、出来上がったものとは似ても似つかない。だが、実際にプロジェクトを動かし、試行と錯誤と怒号と違約金を経て、ようやく明らかになっている。
顧客が欲しがっているものと、顧客が本当に必要なものは違うのだ。
19世紀にヘンリー・フォードが尋ねたら「もっと早い馬車が欲しい」と言うだろうし、マクドナルドがアンケートをすれば「野菜サラダをメニューに入れて」と言うだろう。スティーブ・ジョブズはいみじくも言った「顧客が何を求めているかについて探すのは、顧客の仕事ではない。あなたの仕事だ」。
では、「本当に必要なもの」をどうやって知るのか? 当の顧客ですら知らないのに、どうやって知り得るのか?
この疑問に具体的に応えたのが、『リーン顧客開発』になる。
リーン(LEAN)とは形容詞で「無駄がなく、引き締まった」という意味になる。顧客開発とは製品開発に対応する概念で、顧客とは誰であり、顧客の問題やニーズを追求して仮説検証をするアプローチになる。
著者曰く、顧客開発に1時間費やすことができれば、設計やコーディングの10時間以上、削減でき、機会損失や無駄なコストを削減できると断言する。
本書で挙げられているやり方は、私の経験に照らし合わせても、使えると断言できる。例えばこのリスト、本書ではこの空欄を埋めるようにヒアリングせよと説く。
最も重要なのは1だ。もちろん2~5も大切だが、1を外すなという。
なぜなら、顧客の「課題」に焦点を当てているからだ。顧客の「欲しいもの」ではなく、「課題」が重要なのだ。顧客は課題による痛みに苦しんでおり、自分で様々な解決を試みようとしている。その人が試してきた改善手法やツール、その課題によってどんなマイナスが生じているか、そこを聞き取れという。
一方、スルーしていい顧客の声は、「〇〇が欲しい」という声だという。この機能が必要だとか、あれがないとダメだという「欲しいものリスト」は耳を傾ける必要は無く、聞くフリをしていればいい。その代わり、「なぜそれが欲しいのか」という質問を投げるのが重要だ。欲しい理由を深掘りしていくと、課題に突き当たることがあるからだ。
フォードの質問に置き換えるなら、「なぜ早い馬車が欲しいのか?」という問いかけになる。ひょっとすると顧客は「もっと早く職場に着くために」と答えるかもしれない。すると、準備するものは馬車でも自動車でもなく、早く職場に着かないことで起きている課題は何か?という焦点に移るだろう。
「なぜそれが欲しいのか?」は、プロジェクトを開始する前に質問することができる。そして、それにより「顧客が説明した要件」ではなく、「顧客が本当に必要だったもの」に近いものを引き出すことができる。これにより、無駄な手戻りや、「こんなはずじゃなかった」はかなり回避できる。
3冊目は、『ユーモアは最強の武器である』だ。
ユーモアはメンバーの恐怖心を取り除いて創造性を高め、チームとしての一体感を醸成し、起きたことを思い出深いものに変える。
「頭の良さは、どんなときに笑うかで分かる」という言葉の通り、ユーモアは知性の証であり、あてこすりや皮肉の一刺しのような攻撃にも用いられ、何を笑う/笑わないかによって、自分の意思を強く示すことができる。
神経科学で言うならば、「脳内カクテル」になるという。私たちをハッピーな気分にさせ(ドーパミン)、人への信頼を高め(オキシトシン)、ストレスを緩和し(コルチゾールの減少)、高揚感をアゲアゲにする(エンドルフィン)。
ただでさえ面倒で厄介ごとだらけの人生を、なるべく楽しく面白く過ごすための技術―――それがユーモアだという。あれだ、ルパン三世の次元大介がピンチになると、「さて面白くなってきやがったぜ」と呟く、あのノリである。
それは分かっているのだが、それが一番難しい。「ユーモアのセンスは才能だから、『技術』とは違うのでは?」とツッコミたくなる。
ユーモアセンスの欠片さえ持ち合わせていない自覚だけはある。トラブルでピンチになったとき、少しでもリラックスさせようと冗句じみたことを口走るのだが、常にスベっている自覚もある(苦笑いでも笑わないよりマシ、と考えるようにしている)。
しかし、著者は力強く「ユーモアは技術だから教えることができる」と言い切る。本書を通じてトレーニングすることで、ユーモアはのセンスを筋トレのように向上させることができるという。
ユーモアとは筋肉のようなものだ。生まれつき筋肉質の人もいれば、そうでない人もいるが、トレーニングにより身に着けることができる。使わないと衰えるし、意識するほど磨かれてゆく。
では、どうすればその技術が身に付くのか?
エッセンスをかいつまむと、「事実」を見極め、そこから「驚き」と「ミスディレクション」を導き出せという。
ユーモアは何もない所から出てくるものではなく、必ず核心となる事実がある。その事実から不可解なことや不条理に気づき、それが予想外のやり方で解消されるとき、ユーモアが生まれてくる。
シンプルなジョークで説明する。
あなたは夕食会に参加している。最初の料理が出されてから30分も経ったころ、参加者がひとり会場に入ってきて、すごく申し訳なさそうに言う。
「遅れてすみません、来たくなかったもので」
すかさず「なら来んなや」とツッコミ入れたくなるが、思わずフフっとなるかもしれない。
このセリフがおかしいのは、率直な本音をぶちまけている点にある。普通なら、道が混んでたとか適当に言い訳するところだ。だが、「遅れてすみません」の次に出てくる言い訳として予想外のセリフが来たので、驚きとミスディレクションが生まれている。
ユーモアの核心には、共通した事実がある。だから、ユーモアを探すとき、「何か面白いものがないか?」ではなく「どんな事実が潜んでいるか?」と自問せよという。
前に笑った内輪ネタをこする「コールバック」や、メールの追伸や会議終了の去り際を狙った「ピーク・エンド」など、今日から使えそうなものもある。スベったときの対処法であるら「ユーモアのグレーゾーンを切り抜ける」や、「メール・対面・オンラインを使い分けろ」というハウツーは押さえておきたい。
「なぜ、お客が望む通りに見積もりができないのか。顧客ファーストだろう?」とドヤ顔で言い放つマネージャーがいた。自社開発のソフトウェアを組み込む提案をしたときの話だ。
確かに顧客ファーストは重要だが、お客の要望をそのまま実現しようとすると、ソフト改修に設計思想レベルで影響があり、コストも時間も莫大なものになる。見積もるだけでも大変だし、べらぼうな額になるのは必至なので、こう返答した。
「お客のいう通りに見積もるのが仕事じゃないです。お客が目指すビジネスにどう貢献できるかを提案するのが仕事です。見積もりはその一部に過ぎません」
愚かな思いつきばかり口走るマネージャーだが、バカではない。リジェクトされるのが分かっている非現実的なコストを見積もる作業はナンセンスであることを懇々と言って聞かせると、ようやく納得してもらえた。彼の言い分では、経営会議での参考になるからというが、選ばれない方に注ぐ努力は無駄なり。
『リーン顧客開発』で説明したように、「顧客が本当に欲しかったもの」は、顧客は分からない。だから、以下の行為に注力することは、「どうしてこうなった」という惨事への第一歩になる。
・お客の要望を100%満たすことに全ての努力を捧げる
・「問題かもしれない」ことを片端からトライ&エラーで解決する
あながち間違いには見えないのだが、生産性が悪すぎる。無限の体力と時間があれば、数をこなしているうちに当たるかもしれない。だが、リソースが限られている現場で的を射るには技術が必要だ。そして、この的を射る技術を言語化したものが、『イシューからはじめよ』である。
イシュー(issue)とは、一般的に「課題」「問題点」などを意味する。ビジネスの上で明確に特定され、解決していくことが目指されるものになる。本書では「本当に白黒はっきり区別する必要のある問題」と述べられている。
「問題かもしれない」と言われることが100あるとすれば、本当に白黒はっきりさせるべき問題は、せいぜい2つか3つくらいになるという。
普通の人なら、がんばって100を分析 ⇒ 優先順位付け ⇒ 対処していこうとするだろう(それだけでヘトヘトになるはずだ)。これを絞り込み、適切な問題にする方法論が、本書の目的になる。ノリ的にはこれだ。
「世界を救うために1時間与えられたなら、55分を問題を定義するのに使い、5分で解決策を見つけるだろう」
要するに「課題の質を上げよ」ということなのだが、アインシュタインのセリフらしい(真偽不明)。間違った問題に全力投球する愚を犯すより、「これは何に答えを出すためのものか」「そもそも求めるレベルで答えを出せる課題か」といった自問を繰り返すことで、イシュー度(=課題の質)を高めてゆく。
『イシューからはじめよ』は、この55分をどう使うかに全振りしている。読むだけでなく、自分の今の目の前の仕事で実践していくことで、課題の質を磨き上げることができる。
では、具体的にどうしていけばよいか?
本書では様々な手法が紹介されているが、ここでは地球温暖化問題について、「So What?」を繰り返していくことにより、イシューである度合いがが高まっていく例を挙げる。
この手法は、漠然としたイシュー候補に対して、「So What?(だから何?)」という仮説的な質問を繰り返すことで、検証すべきイシューが磨かれていくやり方だ。トヨタ自動車のカイゼン活動における「なぜなぜ5回」のアプローチに似ているが、「なぜなぜ5回」は原因究明のためである一方、「So What?」は課題見極めのためにある。
最初の見立て①の仮説に対し、「So What?」を投げかけることで、②の仮説になり、さらにその②に質問することでより具体化され③になり……と、イシュー度(白黒はっきりさせる具合)が高まっているのが分かる。
①の「地球温暖化は間違い」といった焦点の定まらない主張だと反論しようがないが、⑤にまで磨き込まれていれば、白黒はっきりさせるために何をどう検証すればよいか、見えてくる。
「So what?」のほかに、「空・雨・傘」といった技法が登場するため、気づく方もいるだろうが、これはマッキンゼー&カンパニーのコンサルになる。ただし、本書が他のマッキン本と異なるのは、完全に血肉化されているところだろう。
本書は、「コンサルティングファームの報告書のリード文に最終的に何を書くか」を丁寧に解説したものだ。だがこれは、そのまま、「どの課題に取り組めば、成果が出たといえるか(そしてそれをどう伝えるか)」という現場の問題に応用できる。
与えられた問題に疑問を抱かず、唯々諾々と取り組んでいるうちに終業時刻となる。怖いのは、頑張って残業しても終わらないところ。ドラッカー『現代の経営』にこうある。
重要なことは、正しい答えを見つけることではない。正しい問いを探すことである。間違った問いに対する正しい答えほど、危険とはいえないまでも役に立たないものはない
間違った99の課題を正しくクリアしようとする行為は、端的に言って「悪」だ。だから、正しい1つの課題を見出すことに注力しよう。
どうせなら成果が出る仕事に取り組もう。価値のある仕事とは、質が高い課題に宿るのだから。
「セックスロボットは悪なのか」という議論がある。あるいは、「アンドロイドが運転する車が事故を起こしたら、誰に責任を問うべきか?」という議論がある。ChatGPTを始め、長足の進歩を遂げる技術が、SFの思考実験ではなく、現実として解決しなければならない問題として、「AIと倫理」を提起している。
こうした議論は、論点が噛み合わないか、漠然とした話になりがちだ。意識とは何かが曖昧なまま「AIには心がある/ない」といった水掛け論になったり、トロリー問題を引き合いにしつつ「功利主義なら倫理をプログラミングできる」といった「can(できる)」と「should(すべき)」をすり替える話になる。
ともすると堂々巡りに陥りがちな議論を整理し、概念や価値観を明確にしながら、新たな視点を提供するのは哲学の出番だ。そして、技術にまつわる領域において、技術とは何か、技術の発展は社会にどんな影響を与え、幸福をもたらすのかといった問題を考えるのが、技術哲学になる。
『技術哲学講義』は、技術哲学について書かれた教科書だ。技術と社会で生じる様々な課題が整理され、議論の最先端が紹介されている。日本語で読める網羅性の高い一冊で、文系・理系、アカデミック・実社会という枠を超えてお薦めできる。
例えば、「AIと倫理」について。堂々巡りになっている理由として、プロパティアプローチがあるという。プロパティ(属性)から道徳的な権利が導かれるという考え方だ。つまり、単なるモノに過ぎないのか、あるいは人間とのパートナーなのかといった立場は、対象の属性が決めているという論法である。
ロボットについて考えてみよう。
ここでは「意識を持つ」かどうかが判断の基準となっているが、「感じることができる」「人間らしい反応をする」など、様々なプロパティ(属性)が挙げられる。これが絶対というものを決めるのは難しいだろうし、そもそも正しい組み合わせがあるのかも分からない。
著者のクーケルバークは、問題は2つあると指摘する。
ひとつ目の問題は、そうした属性が何かというのではなく、この1~3の決め方そのものにある。1の「あらゆる意識を持つ存在は、道徳的な権利を持つ」という前提は、なぜそう言えるのか?「意識」の箇所を、感情、心、経験などのいくつか、あるいは全てに置き換えたとしても、その前提が正しいと確信できるのか(いやない)。
もう一つの問題は、そうした「意識」「感情」「心」といったものが特定できていない点にある。ロボットが経験し、感じていることが、私たちの「感情」や「経験」と同じだと断定できない。それにもかかわらず、両者を同じだとする前提から始めていることが問題なのだ。
議論の対象となる存在の属性を分解し、どの属性を満たせば合格とするかといったプロパティアプローチでは、遅かれ早かれ行き詰まることなる
では、どうすればよいか?
著者はデリダやレヴィナスの現象学からのアプローチを紹介する。他者の属性を分解するのではなく、他者と自己の関係性に着目し、他者が自分にとってどのような存在であるか、自分の経験や意識の中で他者がどのように現れるかに焦点を当てる。
例えば、ロボットやAIについて議論をするとき、私たちは、対象を何と呼んでいるかに着目してみる。ある人は、それ(it)と呼ぶだろうし、あるいは彼女(her)と呼ぶ人もいるかもしれない(AIのフランス語 intelligence artificielle は女性名詞)。名詞だけでなく、ロボットを「使う」やロボットと「会う」、ロボットに「話しかける」といった表現にも関係性が現れてくる。
ロボットをモノ(it)として使役する人と、ヒト(her)のように扱う人の意見が異なってくるのは、当然の帰結だろう。前者からは、セックスロボットは「モノ」なのだから壊そうと何しようと勝手だという話になる。後者からは、「ヒト」のようなパートナーだから人倫にもとる扱いは、その人の人間関係にまで悪影響を及ぼすという主張になる。
そして、その人がロボットをどのように語るかは、それ以前のロボットにまつわる経験に依存する。未来の世界のネコ型ロボットに馴染んだ人と、未来から送られてきた殺人マシーンを見てきた人では、全く印象が異なるだろう。
そこには時代や地域性があるかもしれない。ロボットにまつわる物語は、時代や地域によって変わるからだ。「アメリカ製人工知能が暴走すると世界征服を目論むが、日本製人工知能が暴走すると冴えない男と恋に落ちる」という冗句の通り、ロボットとの関係性に地域差があるのかもしれぬ。
著者は、道徳的態度は文化に依存すると説く。
道徳のコミュニティに「誰(who)」が含まれ「何(what)」が排除されるのかの違いを決定する際、それぞれの単語は、「含む」「排除する」という行為の一部となっていて、道徳的に中立ではないのだ。
つまり、対象についての関係性を語るときに、私たちが使っている言葉の中に、既に価値判断や思考が反映されている。従って「AIと倫理」という問題は、関係性の分析によって見えるコミュニティごとに、取り組み方が変わってくるだろう。
ここでは、AIと倫理を巡る議論の一部を紹介したが、本書では、他にも様々な問題が扱われている。ごく一部を紹介する。
採用試験のプログラムに偏りがあり、黒人男性は犯罪リスクが高めに判定されていた。裁判沙汰になりプログラムは改修されたが、そもそもAIがモラル判断をしてもよいのか?
私たちはSNSに個人情報や興味や時間を「搾取」されているのか?あるいはSNSは新しい大衆社会の成立に寄与しているのか?
文字を使うことで記憶力が弱まり知識が表層的になるとプラトンは主張したが、Googleなどの強力な検索エンジンによって、ますます人は覚えなくなるのではないか?
超音波検査によって胎児の異常が把握できるようになる一方、ダウン症などの重い病気の場合に人工中絶するかの判断が求められるようになった。これは「よい」ことなのか?
よく、「哲学は正解の無い不毛な問いに取り組んでいる」と非難する人がいるが、的外れだ。
「正解」を単純に計算したり測定できる問題は、それぞれの学問領域に引き取られており、簡単には出せないものが、哲学に引きつけられている。そして、正解に近づけるための問答が積み重ねられている。
積み重ねを無視して問題に取り組もうとすると、前提の取り違えや議論のすり替え、詭弁によって堂々巡りに陥るだろう。
技術と社会を巡る問題を、より深く・効率的に考えるために。
今回は5冊紹介した。
巨人の肩の上で培われてきた独学の技法を学ぶことで、自分の武器の「増やし方」を身に着ける『独学大全』、「顧客が本当に必要だったもの」をプロジェクト開始前に引き出す『リーン顧客開発』、メンバーの恐怖心を取り除きチームの創造性を高める『ユーモアは最強の武器である』、100の課題の山から本当に解決しなければならないものに絞り込み・磨き上げる『イシューからはじめよ』、そして複雑に絡み合った概念や価値観を明確にし、技術にまつわる新たな視点を提供する『技術哲学講義』を紹介した。
どれもあなたの技術と掛け合わせることで、あなたの価値をさらに高めることができる。優れた本は、あなたを優れたエンジニアにしてくれる。そう断言できる5冊。
関連記事
人気記事