【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

プログラミングの書籍を書くことについての対話 - [[結城浩]]です。

結城浩です。 プログラミングの入門書を書くって大変だなあ、 といつも思います。 そのくせ入門書ばかり書いている。 以前は入門書を書くのは 「専門用語が使えないから大変」と 思っていたけれど、最近は「何を書いて何を書かないかの取捨選択が大変」なのかなあ、とも思うようになっています。

本を書いているとどんどん厚くなります。 もっともっと詳しく、細部まできちんと説明しようとすると、 ものすごく長くなる。それはそれで書くのは楽しいが、 読むほうは楽しくないよなあ。

短くても必要な情報が手に入って、しかも 「うん、自分にもできそうだぞ。わかったよ」 という気分にさせるような本なら最高なんだけれど。、

あなたはどう思いますか。

さかい@dti: 私の場合は、書籍の厚さは気にしません。 内容的に、概略(ふ〜ん、ぐらい)→詳細(なるほどぉ、ぐらい)→応用(! もしくは 目から鱗)ぐらいのレベル(特に()内が重要)で書いてあるのがよいと思っています。 それと、「これについては後で説明します」みたいな記述がが少ないもの。これが多いと、「まだまだこんなに説明が続くのか...。いったいいつになったら終わるのだろう...。」という気になってしまいます。

コメントありがとうございます。 書籍の厚さは実は大きな問題で、価格の上昇につながるからなんです。 「後で説明します」も使い方が難しいです。 すぐ説明してほしい人もいるし、後回しにしてほしい人もいるので。 でも、まあ、その技術によって著者はお金をもらっているとも言えるし…がんばりまっす。p(^_^)q

さかい@dti: 本の厚さと価格の関係というのは考えていませんでした。さかい@dti的には、コンピュータに関係する本は高いものだという頭があるので、買うときに価格をあまり気にしないもので...。 ただ、800〜1000ページ程度でおさまるものを何冊にも分けて、1冊あたりのページ数を減らす(価格も下がる)、というのはあまり好きではないです。 モチロン、結城さんが書かれている「C言語〜」のように意図的に分けるのはこの限りではありませんが。

コンピュータに関する本は高い、と思ってくださるのは 好意的なお客さまですね。感謝感謝(^_^)。 著者への印税は部数×単価に比例します。 単価を上げて稼ごうと思っても売れなければ部数が伸びないし、 たくさん売れても単価が低い場合には印税の総額は少なくなる。 悩みどころです。が、結城の場合には、 あまり儲けようとは思っていなくて、 「よい本」を書きたい、と思っています。 たくさん売れるよりは長く売れる本になってほしい。 ベストセラーよりはロングセラーになってほしい、 と思っています。

さかい@dti:そういう意味では、結城さんの狙いどおりですね(^_^)。 さかい@dtiがよく行く書店では、いつも結城さんの本が平積みされています。 話はそれますが、以前、会社でC言語を勉強したいという後輩に結城さんの本を薦めて、同時に「この本で理解できなかったらC言語は諦めた方がいいよ」と言ったことがあります。 その時に薦めた理由は、わかりやすい、というのもあったのですが、結城さんの本は「恐くない」というのが大きくありました。 さかい@dti自身は、ひと通りC言語の勉強をしてから読んだ(結城さんのサイン&ひとこと入りの本です(^_^)v)のですが、傍にいて語りかけてくれるような感じがして、とても柔らかい印象を受けました。

励ましの言葉をありがとうございます。とてもうれしいです。 でも…できれば「この本で理解できなかったらC言語は諦めた方がいいよ」は避けていただけるとうれしいです。 初学者って結構そういう言葉に弱いものですし、 新しいものを学ぶ前というのはけっこう「びびる」ものですから。 それに相性もあるんですよ、本で学ぶときには。 かんでふくめるような解説で学んだほうがいい人と、 要点だけとっとと教えてもらったほうがうれしい人と。 ですから、結城の本で理解できない人(あるいは結城の本が 肌にあわない人)でも、諦めた方がいい、とまでは言えなかったりするんです。 (ちょっと杓子定規な答えですみません。 せっかく宣伝していただいたのに) いつもありがとうございます。

プログラミングの入門書って、次のステップへ進むための足がかりだから、その本の中で完結してしまってはいけませんものね。 本のなかで完結してしまっているほうが読むのは楽なんですけれども。 (SoraSora)

そらまめさんのこの意見はとても深いものを含んでいるように思います。 入門書に限らず、「本」はある意味では完結しなくてはなりません。 完結、というのは変ですが、何らかのまとまりがなければならない という意味。例えば連載記事をただつなげれば本になるという ものではない、と私は考えています。 (そらまめさんがそう主張しているわけではないことはわかっています) 入門書は基礎的な事実(覚えるべきこと)を伝えることと、 基本的な考え方を伝えることと、 こんなこともできるのか、という将来のビジョンを示すこと のすべてを含んでいればよいなあ、と思います。 (ああ、書いていて自分の非力さが…げほ、げほっと) そらまめさんの考えは基本的に正しいです。 難しいのは(そして興味深いのは)、 読者を導きつつ、読者に自分の足で歩いてもらうか、 というところです。 この機会にもう少し書いてしまいますが、 プログラミングの本なんて寿命は短いものです。 でもそこに、自分の人生の時間を注ぐとするなら、 やはり…「作品」と呼べるようなものにまでしたい。 何か大きな真理のすそに触れるような、 読んだ人の心に何かを残すような(たとえそのプログラミング言語がすたれた後でも)本を書きたいと切に願っています。 そのプログラミング言語が流行らなくなった後でも、 なぜか結城の本は捨て難い、手元に置いておきたい、 と感じるような本が書きたい。

プログラミングの学習って「学ぶ理由」が必要だと思います。 プログラミングを初めて学ぶひとは、 プログラミング自体ががおもしろいってはじめから思う人は 少なくって、かえって 「それができるから何なの?」 「もうそういうソフトはあるじゃない」という反応が多いようです。 (SoraSora)

そらまめさんの意見はまたまた鋭いところを突いています。 おっしゃる通りで、特に最近のように「コンピュータは使うけれど、 プログラミングはしたことがない」という人に どのようにプログラミングの面白さを伝えられるか、 というのは大きな課題です。 とはいえ、実利的な例ばかりに走ってはつまらない。 理想的な話、理論的な話ばかりでもつまらない。 ここにも、(教える、という行為につきものの) 二律背反があるように感じます。

プログラミングはライティングに似ている。 プログラムを書く面白さを伝えるのは、 文章を書くことの面白さを伝えるのと似ています。 最初は読者をうまく「釣って」面白がらせないといけない。 でもその面白がらせるやり方は、 媚びたり、おふざけをするわけではなくて、 身近な例、既知の例を上手く使うことになる。 読者を既知から未知へ導き、 そしてさらには著者にとってすら未知の歩みを手助けする、 そんな本を書きたいものです。

PerlQuiz はまさに 「読者を既知から未知へ導き、 そしてさらには著者にとってすら未知の歩みを手助けする、 そんな」作品ですよね。 動きが感じられると楽しいです。 それが作者と読者のやり取りであったり、 プログラムの実行であったり。 (SoraSora)

メールマガジン『Perlクイズ』は私も楽しみながらやっている企画です。 話変わりますが、本を書くって楽しいけれど、とってもつらい。 叫び出したくなったり、全部はじめからやりなおしたくなったり、 もうやめたくなったり、することもなくはないです。 本を読むのと、本を書くのの間には深い深い溝があります。 本を読むと「駄目じゃんこんな本」って思うことってありますよね(ないですか?)。 でも、自分で書こうとすると、 本を書くことの難しさをひしひしと感じます。 やっぱりそこには、自我を捨てることの難しさと、 相手(読者)のことを思いやることの難しさがあるように感じます。 やっぱり「愛」なんですよ、「愛」。きっとね。 技術的な知識は二次的なものじゃないのかなあ。 そういう意味では、本を書くのも「愛の訓練」なのだと思っています。 私が今日書く一行は、愛を表現したものになっているだろうか。

私的には、注意力と集中力を磨く本を書いて欲しいですね。 プログラムはWritingだとおっしゃりましたが、Writingは、正確でなければ ならない。私は多くのプログラム本の校正の甘さに、「この人達はプログラマではないな。」 と感じることが多くあります。特にWebプログラマにこういう人が多くなった。 楽しいレベルでお仕事できるのは、一部の人だけです。 結城さんは、誤字、脱字、スペルミス非常に気を使う。 正しい文章を書ける人が、正しいプログラムを書けると私は思っています。 これは私にとってとても厳しいことです。あいまいプログラミングと神経質プログラミング。 この両者は性格が強く出ます。しかしながら生き残っている人は全て 神経質プログラミング です。あー胃が痛い。 (McIII)

最近は入門者はアマチュアよりもSE1年目の社会人の方が多いような印象があるので、 入門書はプログラミングへの興味をかきたてるようなスタイルより 学校or塾での教え方に近いスタイルのほうが受けがいいんじゃないかと思います。 (Tokumei)

私の場合は、「これについては後で説明します」という記述に好印象を抱きます。筆者は、ここまでの知識で取り敢えずのことは出来るので、ひとまずここで区切って、知識が定着したら続きを書こう、というつもりでいるのだなと認識して読んでいます。どこで区切るかは筆者の腕次第なのでしょうが、段階的詳細化をしようという態度が感じられて、読んでいて判りやすく思います。(Mitsu)

しばいぬ: 私は、プログラミング言語の入門書として最初に読む一冊は、薄い本にしています。 全ての機能が説明されていなくても良くて、その言語の感じだけが解れば良いです。 また、プログラムを動かしながら学びたいので、一冊を通じて一つのプログラム(家計簿でも何でも良いです)を作るスタイルが好きです。 章を追うごとに機能拡張されていって、その都度、新しい機能の説明があると良いです。 薄い本を読んで感じがつかめてから、辞書的に書かれた厚い本を読みたいです。