『言語化するための小説思考』を技術者が読んだ ~私の世界の「小説」~
昨年末に読んだこちらの本が面白かったので、自分なりに2025年の総括として紹介。
紹介:どんな本か
著者は、小川哲さん。
直木賞受賞の『地図と拳』(2022)、日本推理作家協会賞/本屋大賞受賞の『君のクイズ』(2022)を代表作とする、小説家です(『君のクイズ』、そして最新作『火星の女王』は立て続けに映像化も)
小川さんが記す「文章を生み出すために、何を考えているか」がタイトルにもある「小説思考」であり、それをまとめたのが本書です。
なぜこの本か
技術者が提供するのは小説でも、ましてや芸術の類でもない、形あるサービスやプロダクトです。そのため一見馴染みが薄そうですが「作り手も受け手も完成形を知らない、答えのないものを作り上げる」という意味で、共通する・学べる部分も多いのではと考えました。
「小説家」が書いたそんな本書を「技術者」の視点ではこのように読めた、という感想を共有します。
※一応簡単に本記事の筆者経歴。ひとまずここでは(IT)技術者とさせて下さい。
・様々な組織の課題解決を技術でリードする業務に、10年以上従事
・公的機関にてデータ活用領域の専門人材として登用歴あり
・情報処理技術者試験にて基本、応用、高度(DB)の合格歴あり
同じようにIT業界に身を置いている方や、そうでなくても本書を未読の方に
「小説家の思考をこういう風に受け止める人がいるんだな」(あくまでひとつの解釈)
「IT業界のことは詳しくないけど、小説を介してであればなんとなく理解できそう」
といったような予感を見出して貰えたら面白いなー、と本記事を書いています。
どのようなことが書かれているか
本書は小説を題材にした12の章から構成されていますが、全体について「まえがき」ではこのように述べられています。
・あらゆる文章表現に共通しているのは、その文章に価値があるかどうかを決めるのが「他者」という点である。
・もともと「他者」と関わりたくないから小説を書いたのに、小説を書くためには「他者」のことを考えなければならない。
・本書は最初から最後まで「小説」について書かれている。とはいえ、小説に興味がない人にも読んでもらいたい。小説家が小説について考えてきたことを人生にどう活かすか、あなた自身で見つけてくれれば言うことはない。
(P3-8 まえがき より)
いわゆる「創作術」としてではなく、ものを書く上での思考プロセスが書かれたものです。それ故に、違った業界に身を置いていても共有するものが見つけられるのではなかろうか。以上を前提とし、中でも強く共鳴できた2つに絞って紹介します。
1.小説国の法律について
2.小説の「勝利条件」
3.知らない世界の話について堂々と語る方法 ◀
4.「文体」とは何か?
5.君はどこから来たのか、君は何者か、君はどこへ行くのか
6.小説はコミュニケーションである
7.「伏線」は存在しない
8.なぜ僕の友人は小説が書けないのか
9.アイデアの見つけ方 ◀
10.小説ゾンビになってわかったこと
11.小説の見つけ方
12.本気で小説を探しているか?
3章. 知らない世界の話について堂々と語る方法
→ 「抽象化」と「個別化」を往復し、「私のための物語だ」と思ってもらう
専業作家として小説の世界にいるまま、なぜ知らない世界について書けるのか、という問いから。
例として、ベンチャー企業を書く際に思い浮かべる「何かを生み出す存在(企業)」と「お金を出す存在(投資家、消費者)」の構造が、文学界における「小説家」と「出版社、読者」の構造と同じだという話から、抽象化と個別化が小説を書く際にも有用だ、というようなことが書かれています。
技術を持って課題解決にあたる場合も、「知らない会社・部署」の「知らない業務」について向き合うことが求められる機会は少なくありません。
もちろん案件の最初はその領域の担当者からヒアリングの機会を頂けますが、必要な情報を全て個人から引き出すことは現実的ではなく、過去に従事した案件から同業他社や、業界は違えど同じ業務を扱った事例を思い返し、目の前のクライアントの困り事・制約・求めるものを提案しつつ、その案件でのあるべき姿に近づいていきます。
さらに私の場合、ヒアリングと並行して、クライアント業務の中で発生したデータを見せて頂く事が多いです。そもそもデータを、個別事象の情報を任意のフレームワークにより圧縮した結果と捉えると、そこに見える「売上・人数・回数」などの指標と、「誰が・いつ・どこから(どこへ)」などの切り口の情報を眺め、そこから自分の知るパターンに当てはめつつ、真っさらな状態から段々と業務を理解していきます。これらはまさに技術者における「抽象化」と「個別化」でしょうか。
(ビジネス領域に限った話でなく、例えば専門的な用語をわかりやすく伝えるために、コンピュータサイエンスの概念をヒトの体の機構になぞらえて伝えたり、データ分析の進め方を日常の料理の工程に置き換えたり、というような場面も多いと思います)
とはいえ、過去のパターンを多く持つほどベストな提案ができるかというとそう簡単な話ではなく、結局はその案件、その環境の制約における個別の期待に寄り添った成果が求められます。だからこそそれを確度高く再現できる手法を見つけ差別化すべく、各社こぞって研鑽していますが、この状況はきっと小説家も同じではないかと思います。
抽象化と個別化を駆使しながら「これぞ私のために作られたものだ」と感じて貰うことを目指す。そんな話でした。
9章. アイデアの見つけ方
→ 発想力よりも「視力」により、新しい視点を生み出すのでなく「見つける」
「正しい小説の書き方」は存在しない、それは「読者」が一人ひとり違った欲望を持っているから、という主張から、以下のように続きます。
とはいえ、書き手が持っているのは、ただ一つ「自分の物差し」だけだ。小説の書き手にとって唯一の手がかりは「自分が面白いと感じるかどうか」であるのに、小説を評価する基準は常に「読者(他者)が面白いと感じるかどうか」であり、この「原理的に埋められない差」が埋まらなければ、小説は面白くならない。
(P102 アイデアの見つけ方)
「面白い」を任意の形容詞に置き換えれば、この主張はそのまま私の、それどころかほとんどの仕事に通じるのではないでしょうか。
さらに続きとして(商業的に)成功する人は「他者の物差しを内面化している人」もしくは「なるべく他者の物差しに合うように、自分の物差しを調整した人」の2パターンが挙げられています。
技術者の視点での成果物は、サービスやプロダクトを筆頭とし、その前段にある設計書、さらにその案件にまつわる提案書など様々あります。それらいずれでも「価値がある」と認められるためには、受け手の期待に沿う、さらに言うと期待を超える「新しい視点」が必要となります。
(価値があると認められる、というと抽象的ですが、ビジネス的には案件化・予算化される、さらにその案件・事業が継続する、といった状況を想定してもらうと分かりやすいでしょうか)
その「新しい視点」となるアイデアを見つけるのに必要なものは、発想力やオリジナリティ、ではなく「視力」であると、研究者時代の経験を元に小川さんは述べています。
技術面から提示可能なベストプラクティスはあれど、その理想に対し望む/望まないに関わらず「今ここにある状況」をスタート地点としなければならない、というのはビジネスモデルの垣根を越え、共通することではないでしょうか。
劣勢にみえる状況を嘆くのではなく、小説家が「書いてしまったこと」から新しい視点を見つけるように(さらに言うと「書かれていないこと」にも)目を凝らして、その場をつなぎとめる論理を導き出す「視力」を持つビジネスパーソンが居たならば、是非チームに迎え入れたいものです。
…と書いたように、今まで自分はほぼ常に複数の人と一緒に働いてきました。だからこそ、個々人は「自分の物差し」しかないとしても、それぞれの物差しを持って「死角」をなるべく減らすことで、チームとして成功に近づいて来られたと考えています。「手詰まりだ…」としか思えない場面において、意見をぶつけ合った先に、全ての懸念を払しょくし、これ以外ない!とあつらえたようなアプローチを見つける瞬間こそ、チームで働くことの醍醐味である、と考えています。
自分の物差しを調整するために必要な「分析」の質をあげるには「作品を発表」しフィードバックを得ることが近道だという本書の内容からも、馬鹿にされるかもしれない、嫌がられるかもしれない、といった不安を抱えつつも「意見を表明」することの重要さに改めて納得しました。
チームで働く視点からみると、常に一人で文章と向き合っている小説家の方とは立場が異なりますが、だからこそ偉大な職業だとも思わされる、そんな話でした。
感想:技術者にとっての「小説」とはなにか
→ 「要件定義書」のことかもしれない。ひとまずそう置いておきます。
改めてタイトル『言語化するための小説思考』に戻ります。ここまで本書から教訓めいたものを抽出してみましたが、改めて自分の仕事における「小説」そして「言語化」とはなんだろうと考えてみました。
まず私の成果物は「小説」ではありませんが「言語化」に相当するものはあるでしょうか。
小説家が成果物を出す過程である「執筆」が「言語化」に当たるでしょうか?
であれば、技術者の過程としての「実装」=「言語化」でしょうか?
私はそういう結論にはなりませんでした。
というのも「言語化」というのは単に文章化するというだけではなく、依頼者の気づいていない課題、誰にも議題にあげられていない問い、など「言葉になっていないものを、コミュニケーションから(そしてコミュニケーションに向けて)見出す」行為と捉えています。であれば、小説家は執筆に向き合う前に言語化は済んでいるのではないか。同様に、技術者は実装に向き合う前に言語化は済んでいるのではないか。
そう考えると、実装段階の前に生まれる成果物としての「要件定義書」が私にとっての小説ではないかと考えました。もちろん、一口に技術者と言っても担う領域やフェーズが異なるため、実装された「サービスやプロダクト」や「提案書、設計書、報告書」、または明確に公開という形がとられない「ルール、モデル、アーキテクト」が適切に思える方もいるはずです。
あくまで、私の受け止め方や立つ視点として、今はこれがしっくりきています、という点は付記しておきます。
小説と要件定義書の似ている点を(あえて)見出すと、それを読んだ人が、読む前には想定しなかった「物語」を受け取ることができるということでしょうか。それが受け手の期待するエンディングへ連れて行くものであればいいですが、そうでない場合、意見として作者にフィードバックされて、さらに理想のアウトプットに磨き上がる。このサイクルの最中にいる時であれば、異なる立場にある小説家と技術者も、少しは通じ合えるのではないか、本書を読んで思いました。
本記事では触れられませんでしたが、
「4章.「文体」とは何か?」では、文章の順序における情報設計
「6章.小説はコミュニケーションである」では、見えない読者を想定した情報のやりとり…
など他にも、ビジネスに通ずるのでは?という視点で読める内容が多々ありました。
あなたの仕事における「小説」「言語化」はなんでしょうか。
振り返り(2025年と2026年)
2025年、ビジネスにおける生成AIの活用は当たり前となり、日常生活においても生活に組み込まれ、身近な存在になった、そんな年だったと思います。
では、本記事の執筆における生成AI活用の度合いはどの程度と思われるでしょうか。
答えとしては"ゼロ"なのですが、なぜかというと、生成AIを始めとした技術を活用し、公私ともに業務を効率化させた先の「余暇」で本記事を書いたからです。もちろんAIを使えば、本の紹介として正確な内容、かつわかりやすい文章になったと思います。しかしその過程に潜む苦悩や不便さこそ面白さの本質であり、そこはAIに奪われたくない、という気持ちでいました。
(本書「あとがき」や2章12章などでも、AIの存在に言及されています)
今年も技術の進歩が想像以上に加速していくはずですが、生成AIをはじめとしたテクノロジーを活用する場面においてはあなたも技術者の一員です。今は描き切れない物語を期待しつつ、2026年も楽しく進んでいきましょう。
ここまで読んで下さり、ありがとうございました。
Discussion