人間はいろいろな問題についてどう考えていけば良いのか

一文で表すと…?

作者の森博嗣は小説家になるまで大学教員として勤めており、その中で培われた抽象的な発想は、具体的で主観的な情報が溢れる今日では、(人によるが)役立つのではないかと主張した本。

Think Abstract

この本は僕の大好きな本の一つで折に触れては読み返していたりします。このWebサイトのタイトルもこの書籍の内容から名付けました。
森博嗣の書籍に初めて触れる方は、好みが分かれることが多いので、まえがきをさっと読まれてからその先を読むかを検討されると良いと思います。

さて、この書籍を読んで僕がまず感じたのは哲学的な匂いでした。つまり、具体的な行動指針を勧める自己啓発書など(批判ではなく、種類として)とは異なり、基本的に明確な答えなどを出しません。そのため、本のまえがきでも「多くの人が眠くなってしまうかも」と述べられています。
しかし、抽象的な発想は科学の世界では当たり前に行われ、その発想をもって現実世界の物事を捉えると主観や感情によらない判断が下せるようになる(かもしれない)ということです。

具体が悪く、抽象が良いというわけではない

学問の世界では抽象化できた方が良いという考えがあるものの(例えば、アインシュタインの E=mc^2 のように世の現象を一つの数式に抽象化すること)、現実世界は具体的な行動で物事が行われる以上、そこに優劣があるわけではありません。
絵画にも写実画と抽象画があって、どちらとも優劣がつけられないように、それぞれの良さがあってそれを見た人の気持ちや環境などで、どちらが見て良いと感じたのかが決まります。

想像するということは、抽象的に考えること

自由に想像することは抽象的に考えることに近しいと本書では述べられています。
例えば物語を作るとき、ストーリーやキャラクターを想像しますが、それは自分が読んだり、体験した話や人物との会話をもとに作られています。その際、細かいディテールを削っている(抽象的に考える)ため、具体的なものとは異なります。

よくベストセラーの書籍が実写映画になったとき、「この俳優は合ってない」など意見がありますが、これはその意見を言った人が考えた抽象的なキャラクターと具体的な俳優とのディテールの違いから来ているものと推測されます。同じくアニメのキャラクターもディテールを削っている(デフォルメ;実際にはあるはずの肌の質感や骨格を省略している)ため、具体的な俳優や女優が演じると、「なんか違う」ということになります。

相手のことを想像する、客観的に物事を見る

抽象的な考え方をすると生きる際に役立つことがあると著者は述べていますが、特に人間関係についてはそうだと言えると感じました。
例えば、自分の立場にしか立たず意見を述べるよりも、相手の立場を想像して「なぜ相手はこういう風に考えたのだろう?」と考えることで、人間関係をポジティブに捉えることができます。

また、森博嗣の知人で自殺した何人かの人は「あまりに主観的(自分の身について具体的)に考えすぎている節がある」と著者は推測しています。確かに自分のことばかり考えているうちに段々と視野が狭くなっていき、他人から「世界にはもっと苦しんでいる人がいる」と言われても、「他人は他人だろ!」と叫びたくなる気持ちは、自殺願望のある人に共通して見られる思考と言えるかもしれません。

抽象的に考えられるようになる手法はない

名古屋大学で教員を十数年勤めた著者ですが、抽象的に考えられるようにする効果的な教育方法はないとしています。しかし、効果的かは分からなくとも自由に発想することを習慣づけることは重要なのではないかとしています。
例えば、
1. 普通のことを疑う (なぜ葉っぱは秋になると赤くなるのか etc.)
2. 普通のことを変えてみる (もしも人類が水の中で生きる動物だったら、どんな社会が出来ていただろうか etc.)
3. なんでも喩えてみる (静かなること林のごとし etc.)
4. 創造的なものに触れる、創造的なことを行う (抽象的なものを具体的に、具体的なものを抽象的に)
ということを行うことで、抽象的な思考がしやすくなるのではないか、少なくとも重要な数式や文学などはこうした思考から生まれていたりすると著者は分析しています。

なにものにもこだわらない

教員であり、物書きであり、さらに多趣味で庭に電車を走らせる著者のポリシーは、意外なことに「なにものにもこだわらないこと」だと言います。このポリシーは簡単(あるいは怠惰)に見えそうですが、その実、難しいものであったりします。
人間は生きていく上で必ず何かしらの慣習や制度に従うことになります。こうした常識に従うことは生きていく上で快適なのですが、その常識がいつの間にか自分の視野を狭めてしまい、それがストレスになっていることがあります。
そんなときに自由な発想をすることは、ときに周囲から奇妙な目で見られることがありますが、自分の人生のより豊かなものにできるきっかけにもなります。

虚しいことは悪いことではない

抽象的に考えていくと、「生きていること自体も宇宙規模で見たら意味のない、虚しいことじゃないのか」と結論づいてしまうかもしれません。しかし、虚しいことが悪いことというのは、そう思い込んでいるからであって、虚しさに楽しみを見出すこともできないことではないのです(例えば、短歌など)。

自分の庭は自分が満足できればよい

この本の最後に具体的な例として、著者が自分の手で設計もなしに作り上げる庭の話を挙げています。
努力して築き上げた庭でも冬になると枯れ、その度に正直ため息も出したくなる気持ちになったと言います。しかし、そんな地道な努力は全体として「自分が望む」方向へ変化するだろうし、それが蓄積して自分が満足できる世界に近づいていくのではないか、そしてそれに微笑むことができる抽象的な考えを持てれば良いのではないかと結論づけています。

合わせて読んでほしい

こちらも僕にとって重要な考え方を示してくれた書籍です。話の内容はこの本と通底しており、「自由に生きるということは、思い通りに生きる」ということだが、それが実に難しいと森博嗣は述べています。

デスマーチはなぜなくならないのか – IT化時代の社会問題として考える

一文で表すと…?

現在の文脈において、なぜデスマーチが起きてしまうのかを3名のソフトウェアエンジニアへのインタビューを基に社会学のアプローチを用いて考察した書籍。

ソフトウェア開発はデスマーチが起こりやすい性質がある

IT業界ではよくある話としてのデスマーチですが、その原因についてあまり考えてこなかったということもあり、読んでみました。
本の中では主に著者がソフトウェアエンジニアに対して行ったインタビュー内容とその考察が記されているのですが、インタビュー内容はうなずきながら読むことができ、また著者が社会学の博士課程を通じて専門としていることもあり、そのインタビュー結果を解釈するプロセスが勉強になりました。

僕が特に面白いと感じたのは、ソフトウェア開発はデスマーチが起こりやすい性質があるという著者の視点です。
本の中でも述べられているように、エンジニアはそもそも「ソフトウェア開発」はどういったプロセスなのかを考えることはあまりありません。確かに僕もただ作りたいと思っているものをコードとして書き出すということをしているわけですが、この作業は抽象的な要求を具体的なものとして落とし込むプロセスだと著者は考え、その性質がデスマーチを起きやすくしていると考察しました。

確かに業務を考えてみると、仕様書や口頭でソフトウェアに関する要求を理解し、実際はそれを微妙にコードで調整しながら、お互いの認識に合う落とし所にプログラムを作成していきます。
つまり、ソフトウェアが完成するまで具体的な仕様は決定せず、時間やコストの見積もりはかなり困難であることになります。例えば、あるライブラリの機能を使ってソフトウェアを作る際に、そのライブラリの仕様が変わる、ドキュメントと実際のコードに差異があったということを経験した方は少なくないでしょう。
その結果、開発に見積もり以上の工数がかかるのは現場のエンジニアの能力以前に、ソフトウェア開発の性質となります。

そのために、製造業的な見積もりを行い、限られた納期を伸ばすという想定がなされないまま仕事が依頼され、エンジニアは死の行進へと向かいます。

遊び感覚のソフトウェア開発もいつまでも遊びではいられない

インタビューを通じて、さらにわかったのはデスマーチに陥る理由はエンジニア側にも存在するとしています。特に若い頃から遊び感覚でプログラミングを行ってきたエンジニアは、仕事は遊びの延長であり、長時間ソフトウェアを書くことを苦にしないという方が多くいます。
しかし、そうしたエンジニアも次第に年齢を重ねるに従って、自身の健康や家族との時間を過ごしたり、両親の看病を行うなど様々な外的要因によって徐々に開発や勉強にかけられる時間が減るという問題が出てきます。

そのようなプレッシャーの中で先の見通しにくいソフトウェア開発は肉体的にも精神的にもエンジニアを追い詰め、最終的に燃え尽きてしまうということが起こってしまうのです。

この本は単純にデスマーチは人・時間が足りないから起こるという結論で済まされがちなところを、上記のようなソフトウェア開発の性質やそこに携わる人や組織の観点からより深く分析をしており、またその分析手法も社会学の方法を取り入れて出来るだけ客観的に試みているところが面白く感じました。

関連書籍

ソフトウェア開発では人数を増やしても仕事は早く終わらない、むしろ長期化する恐れがあるということを世に主張した言わずと知れた著作です。
20世紀中頃まで一般的に行われていた産業では仕事を細分化して、大勢の人に割り当てれば仕事も早くこなすことができていました。しかし、近年、ソフトウェアに代表されるように作るものが複雑化するに従って、人数が増えてもプロダクトの説明や教育に時間がかかり、また仕事を細分化するのが難しいなかで、プロダクトマネージャーはどうしたらよいのかを知ることができます。

個人的には、ソフトウェア開発は手術みたいなもので、プロジェクトマネージャとしての正しい方針はまずプロジェクトの性質を見極め、設計1/3、実装1/6、テスト1/4、統合・実地テスト1/4という割合で時間を配分し、手術と同様、執刀医、副執刀医を決めて、その二人を補助するように他のプログラマを配置すると良いという発想が斬新でした。