JAIPA Cloud Conference 2016 開催のご案内

バズワードウォッチ、楽しんでますかー?
実体が曖昧なのに、なぜか盛り上がってる分野で、良く使われるキーワードがいわゆるバズワードです。
バズワードを追いかけると、ビジネス的な大当たりを引くこともあり、ITに関わる経営者は大体バズワードに踊らされています。
踊るのも楽しいですしね。

とはいえ、もちろん踊るだけでなく、確実にバズワードをビジネスに役立てている企業もちゃんとあります。
たとえば「クラウド」というキーワードで儲けてる企業もいくつかありまして、そのうちのいくつかの企業が、情報交換する場の一つとして活用しているのが、「日本インターネットプロバイダー協会クラウド部会」(略称:JAIPA Cloud部会)です。
そのクラウド部会では、2013年から毎年1回「JAIPA Cloud Conference」というイベントを開催しています。
2016年のイベントも明日開催されます。

 

JAIPA Cloud Conference 2016 (略称: クラコン 2016)

 

プログラムの中身を見るとびっくりするのですが「クラウド」で踊っていたはずの企業が、みんな揃って別のバズワードである「IoT」で踊っています。
おそらく IoT ビジネスになりそうなんでしょうねえ。
とはいえ IoT でのビジネスははクラウド以上に知恵と勇気が試される世界のような気がします。
知人がこう言ってました。

「IoT。無邪気な大人の本気総合格闘技」

明日のイベントも無邪気な格闘が見られると思いますので、時間がある方は出掛けてみてはいかがでしょうか?
私も朝から会場入りする予定です。

以上、メディアスポンサーとしてのツチノコブログがお送りしました。

とある肉の日のご案内

これは MySQL Casual Advent Calendar 2015 の19日目です

みなさん、肉の日といえば毎月29日を思い浮かべますでしょうか。
焼き肉が安くなったり、いろいろなキャンペーンを行っている、あの日です。
ツチノコの生息地、大手町のお店でも肉の日にランチ焼き肉が安くなったりしているようです。
MySQL界隈で毎月29日といえば、そうです MySQL用全文検索エンジンMroonga 及び Groonga のアップデート日です。さらに、毎年だいたい02/09にメジャーアップデートを行っています。
現在はVer5系、Groongaは5.1.0、Mroongaは5.10が最新バージョンです。
12/29にはそれぞれまたアップデートが来るのではないでしょうか。
また、MySQL5.7において全文検索機能が入ったということで、いろいろと皆さん試しているのではないか、と思います。

そして来年2016/02/09のに、下記イベントが開催されることとなりましたので、そのご案内を致します!

MySQLとPostgreSQLと日本語全文検索

概要

「MySQLとPostgreSQLと日本語全文検索」は次の2つのことについて紹介するイベントです。

MySQLで日本語全文検索する方法とその利用事例
PostgreSQLで日本語全文検索する方法とその利用事例

私しののめも「DMM.comラボでの日本語全文検索の利用事例紹介」として簡単にお話をさせて頂く予定となっております。

また席に余裕があるようですので、ぜひ皆様恵比寿ガーデンプレイスへお越しくださいませ!
また、MySQLでの全文検索利用事例、PostgreSQL向けのPGroongaの利用事例、pg_bigm利用事例も発表者募集中ですので、ぜひよろしくお願いいたします!

イベント概要
https://groonga.doorkeeper.jp/events/35295
MySQLとPostgreSQLと日本語全文検索
日時:2016-02-09(火)20:00 – 22:00
会場:DMM.comラボ 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー21F

技術書、それも売れるやつを書きたい人へ、編集者からのアドバイス

技術者のみなさん、いつの日か自分の得意分野について最高の技術書を書いてみたくありませんか? それも、どうせだったら出版社から発行して、モデルチェンジのたびにMacBook Proを買い替えられるくらい印税を稼ぎたいですよね。出版社というものは「売れる」技術書の企画を常に探しています。したがって、ほとんどの技術者の眼前には、ネタとやる気さえあれば技術書を上梓するチャンスが転がっているといっても過言ではありません。

しかし、いうまでもありませんが、チャンスがあることと実現することの間には「壁」が何枚も立ちはだかっています。「一冊分くらいの技術ネタは十分にあるし、執筆する時間もとれそうだ。小説とかわりと読むほうだし、文章力にはそこそこ自信がある。実は技術系の同人誌を出した経験もあるんだよね。」という、編集者目線でハイスペックなポテンシャルを秘めた技術者でも、いざ書き始めようとすると、そもそも書き出しが思いつかなくて気力が消滅したり、これ誰が読むんだろうって白けた気持ちになって進捗がアレしたり、うまい例題が思い浮かばなくて行き詰まるのがふつうです。枯渇しかけたモチベーションをレッドブルでひねり出しながらなんとか書き終えても、さっぱり売れなかったり、アマゾンで誰かに酷評されたりすれば、あとに残るのは悲しみだけです。印刷製本しちゃった場合には在庫も残りますね。

この記事を書いている人間は、IT系技術書を企画し制作する編集者として、数々の技術書の一生を見守ってきました(ここに職務経歴書があります)。その経験をもとに、「技術者が技術書で読者に評価されるためのコツ」みたいなものを紹介できればと思います。技術者にして出版人でもある高橋征義氏は、「技術書がなければ技術者は死んでしまう」と言っています。優れた技術書を書けるのは、優れた技術者だけです。この記事では、優れた技術者の方々に、「技術書を執筆したい、それも今すぐにだ」と奮起してもらえることを目指します。

技術書の評価がみるみる向上する5つの工夫

ソフトウェアにしろハードウェアにしろ、技術者が技術について解説する「ドキュメント」としては、いわゆるマニュアルや論文があります。ブログやメルマガなどで技術解説を書いたことがある人も多いでしょう。そのようなドキュメントと技術書とが決定的に違うのは、技術書は「商品」であるという点です。有料の技術ブログやメルマガもあるし、別売りのマニュアルなんかもありますが、流通する商品であることは技術書が他のドキュメントと一線を画する最たる特徴だといえます。(雑誌の記事なら書いたことがあるという技術者の方も少なくないと思いますが、商品としてのボリュームや責任の重さを考えると、雑誌の延長として技術書を考えるのは難しいかもしれません。)

お金を出して買ってもらう商品である以上、技術書を書くときに「商品として意識すべきこと」がいくつかあります。書き手がちょっとだけ意識することで読み手がハッピーになる、そんな工夫はたくさん考えられると思いますが、独断で大きく以下の5つに要約してみました。

  1. わかりやすく伝えるための工夫
  2. うそをつかないための工夫
  3. 読み終えてもらうための工夫
  4. 読み返してもらうときのための工夫
  5. 読み始めてもらうための工夫

この5つは、およそ「人に読ませる技術文書」のすべてについて必要な工夫ともいえますが、とくに技術書の場合には「お金をもらうレベル」で必要になります。まあ、商業出版をしようというケースであれば、これらの工夫は担当の編集者に任せればいいはずなんですが、書き手がこういうことを意識しているかどうかで出来上がりはずいぶん違うものです(それに、経験によると、こういう工夫ができる編集者とできない編集者がいます。備えよう)。

なお大前提として、「何を誰に向けて書くか」はすでに決まっているものとします。つまり、ネタの選び方はこの記事では触れません。対象読者を決めることの重要性についても触れません。すでに伝えたいトピックが見つかっていて、どんな技術レベルの読者向けに解説を書きたいか、おおざっぱに決めている人がこの記事の対象です。対象読者を見据える重要性や題材の選び方について手っ取り早く知りたい人には、次の本が参考になるでしょう。

山内俊介 著 『専門家のための「本を書こう」入門』

http://www.amazon.co.jp/dp/4904536665

1. わかりやすく伝えるための工夫

のっけから失望させてしまいそうですが、技術的なトピックをわかりやすく説明する安直な方法はありません。でも、技術書をわかりにくくするのなら簡単です。そんなアンチパターンとして頻出なのは次の3つ。

  • 用語の解説ばっかり
  • 図や表だけで説明が終了
  • 具体例や動機を示さない

ときどき、技術用語の説明文を並べることで技術書を執筆していく人がいます。用語集ならそれで構いませんが、そうでないなら、その用語が必要になる背景をなんとかして説明してください。背景になる概念がうまく伝われば、それに名前を付けることで、自然な流れで技術用語を説明できます。たとえばC言語の入門書を書いていてポインタについて説明したかったら、「ポインタとは……です。」という用語解説スタイルで理解してもらうのはたぶん絶望的に困難であり、そもそもポインタが必要になるような状況のほうを解説してあげるほうが本質をよく理解してもらえそうですよね。どんな技術書でも状況は同じです。「およそあらゆる概念は用語の説明をするだけでは伝わらない」という態度を原則にして執筆しましょう。

図や表を描いて説明終了というのも、技術書における典型的なアンチパターンです。よく見かけるのは、フローチャートのみで説明に代えているケースです。どんな図表にも、すでにわかってる人にしかわからない見どころがあるものです。「図を見ればわかるでしょ」という態度で執筆されていると、たいていの読者は面食らってしまいます。うまい図や表は読者の理解を促進させますが、その図だけで理解できる話なら、そもそも技術書という形の込み入った解説は必要ないでしょう。図や表で解説をしたつもりになってはいけません。図表は本文の解説を補うために使ってください。

最後のアンチパターンは、具体例や動機付けに欠ける説明です。その技術が「どうやって」問題を解決するのかだけでなく、「どんな場面で」「なぜ」その技術が必要になるのかを伝えましょう。そもそも、ある技術によって解決する問題が見えているのは、その技術を十分に理解している人だけです。これからその技術を勉強しようという人に向けて、その技術が世界のどんな問題を改善するのか、なるべく具体的に明示してあげてください。いかにうまい例をひねり出すかが勝負です。

なお、ここで必要だと言っているのは「具体例」であり、「たとえ話」のような「例」ではありません。よく言われることですが、技術書では比喩の扱いに注意してください。使っちゃダメっていうことはありませんが、それがあくまでも比喩であることを明らかにしましょう。その比喩を解説の根拠にするのはもってのほかです。

わかりやすい説明を書くためには、文章力が必須なのでは?

そんなことありません。

とはいえ、文章力がまったくなければ何も書けないため、それなりに日本語をがっつりと書く覚悟は必要です。でも、技術書に必要なのは「ぐっとくる情緒的な文章」ではないので、たとえば面白い小説とかブログ記事を書くのに必要という意味での文章力は、あるに越したことはない程度だと考えてください。技術書にとって本当に必要な「文章力」は、うっかり間違った説明を書いてしまったり、意味が特定できない文章を書いてしまったり、そういう問題を避けるためのものです。そのような意味での「文章力」については「2. うそをつかないための工夫」で説明します。参考書籍としては、やや学術的ですが、次の本の第2章と第3章を挙げておきます。

森口 稔 著 『テクニカルコミュニケーションへの招待』

http://www.amazon.co.jp/dp/4385366020

ただし技術書の文章は、論文の文章のように無駄を一切そぎ落とす必要があるわけではないので、ところどころで「ぐっとくる文章」を狙ってみるのも悪くないと思います。その辺はいろいろ工夫してみてください。可能なら担当編集者やレビュアーにも相談してみましょう。

「わかりやすく伝えるための工夫」のまとめ

  • わかりにくい解説のアンチパターンを避ける
  • いわゆる「上手な文章」を書く自信がなくても大丈夫

2. うそをつかないための工夫

なにより重要なのは真摯な態度です。わからないことはわからないと書きましょう。全知全能でなければ技術書を書いていけないわけではありません。あるいは、知らないことは書かないようにしましょう。個人的な意見ですが、浅く広い情報を紹介するよりも、フォーカスをぐっと絞ったほうが良い本になる場合が多いです。

意外と陥りがちな罠は、「難しいことを易しく説明してしまう」です。これは絶対やっちゃだめ。難しいものは難しいのです。理解するには時間がかかるものなのです。だから安易な説明で「わかった気にさせる」のではなく、じっくり説明したり、説明の仕方を工夫したりすべきです。まあ、それが難しいんですけどね。

説明文を書くときは文法にも気を付けましょう。といっても、学校で習うような文法に忠実であれという意味ではありません。どんな言語にも、ネイティブだと無意識に見過ごしてしまう暗黙の性質があるものです。たとえば、なにげなく使った助詞の「の」に誤読を招く可能性があるとか、そういうのを執筆時に意識しましょうという話です。意識できるようになるには、やっぱり文法に立ち返るしかありません。日本語の文法については、たとえばこんな本を一冊読んでおくだけで、ずいぶん見方が変わると思います。

益岡 隆志 著 『24週日本語文法ツアー』

http://www.amazon.co.jp/dp/4874240844

知らないと意識できない部類の落とし穴として文法より致命的なのは「誤謬」です。操作手順のような文章だけを書いているぶんには心配いりませんが、技術の必要性を説く文章や、概念をかみ砕いて説明する文章では、うっかり論理展開がおかしくなってしまうことがあります。幸い、おかしな論理展開はある程度パターン化されているので、そのような「誤謬」を避けたり、校正時に気づいて修正したりするためにも、一通りさらっておくのがよいでしょう。

Wikipedia: 誤謬

https://ja.wikipedia.org/wiki/%E8%AA%A4%E8%AC%AC

Wikipedia: 詭弁(こちらも参考に)

https://ja.wikipedia.org/wiki/%E8%A9%AD%E5%BC%81

「うそをつかないための工夫」のまとめ

  • 知らないことは書かなくてもよい
  • 難しいことを易しく説明しない
  • 文法に敏感になろう
  • へんな論理展開にも敏感になろう

3. 読み終えてもらうための工夫

大前提として、あなたの本を読み始めた人がみんな必ず本を読み終えてくれるわけではない、という覚悟をしてください。このブログだって、ここまで到達していない読者が大半でしょう。そのうえ技術書ときたら、ブログに比べると圧倒的に長い。読み始めたけど時間がなくて読めなくなる人、その技術の解説が不要になった人、自分に合わない本だと気づいた人、当然いろいろな読者がいます。なんだかんだ言って、全部を読まなくても内容が理解できる技術書がベストなんです。

それでも書いている側としては、なるべく「全員の読者がハッピーに読み終えられること」を目指さなければなりません。そのために必要な工夫は、ずばり「段落」です。

技術書の目次構成をものすごーく粗くとらえると、「部」や「章」を適切に並べたものだといえます。部や章が適切な順番に並んでない本は、とても読みずらいので、読み切ってもらえる見込みはほとんどなさそうです。

目次構成をさらに下に降りていくと、「章」の中には「節」があります。節の構成がぐだぐだな章が読みにくいのは必然ですね。さらに「節」の中には「項」があり、項の順番がうまくないと節が読みにくくなります。最後の「項」を構成するのは、目次には見出しとして現れませんが、「段落」です。技術書の構成の最小単位は、実は目次には現れない「段落」だということです。

構成の最小単位は段落

いま見た技術書の構成をボトムアップで見ていくと、段落が適切に並んでいないと項が読みにくくなり、さらに節が読みにくくなり、章や部が読みにくくなり、書籍全体として読みにくくなるといえます。読みにくい本より読みやすい本のほうが最後まで読んでもらえるはずなので、段落がうまい具合に並んでいる技術書のほうが最後まで読んでもらえそうですよね。

ただし、これは、そもそも各段落がきちんと「技術書の構成の最小単位」になっていることが前提です。一つの段落にたくさんの内容を詰め込んだり、逆に意味をなさない段落を大量に作ったりすれば、どうがんばって並べても読みにくい技術書にしかなりません。

ある程度まとまった文章を書いたら、段落ごとに「何を伝えている段落なのか」を要約してみましょう。そして、その段落たちの適切な並びを何度も何度も検討してみましょう。足りない段落がないか、重複する機能を持った段落がないか、自己レビューしてみましょう。文章における段落は、プログラムやハードウェアにおける「モジュール」のように考えるとよいかもしれません。モノリシックなモジュールは悪です。不要なモジュールも悪です。モジュール間の連携がとれていないと、製品はまともに機能しません。

段落をうまく制御することは、技術書に限らず、あらゆる技術文書にとって「鉄則」です。これについては、とりあえず次の本を絶対に読んでおきましょう。

木下 是雄 著 『理科系の作文技術』

http://www.amazon.co.jp/dp/4121006240

段落を並べて、文脈を作る

段落の並べ方に鉄壁のルールはありません。大まかな道筋としては、概要からスタートして細部の説明に入っていくのがいいでしょう。でも、何が「概要」で何が「詳細」かは文脈、つまり自分がいま何をどう説明しているのかによります。段落を整理するときの心がまえは「文脈をうまく作り出せるように並べる」です。「この段落は、自分の本をここまで読んできた読者にとってどんな役割があるか」をよく考えてください。読者にとってつらいのは、文脈における各段落の役割を見失ってしまうことです。すべてが腑に落ちるまで、何度も段落の切り分けや配置を工夫してみてください。

ちょっと脱線しますが、技術書を書くという行為は、小説のような読み物を書くのとは違って、一本の糸をつむぐことではありません。自分がみんなに伝えたい技術について、「線」ではなく「面」で解説することを心がけると、良い技術書になることが多いように思います。縦糸をたらしたら、必ず横糸を張る。文豪クラスの筆力を持っていて、一本の糸を編み物のように編み込んで面を作り出せる著者もたまにいますが、たいていの人には無理です。それができることを目指す必要もありません。あるトピックを解説するときに、それが全体の中でどういう位置づけにあって、なぜここで解説が必要なのかを、しつこく読者に思い出させてあげればいいのです。

「読み終えてもらうための工夫」のまとめ

  • 技術書の最小単位は、段落
  • モノリシックな段落や不要な段落を撲滅する
  • 段落を並べて文脈をうまく作り、読者を迷子にせずに面で解説する

4. 読み返してもらうときのための工夫

技術書は小説などの文芸書と違って、いったん読み終えてからも必要な情報を参照するためにランダムに見返されることが多い本です。意外かもしれませんが、紙の本というメディアは案外とランダムアクセス性に優れています。つまり、読みたい場所へとアクセスしやすいメディアです(しょせんはアナログメディアなので検索とかは不得手ですが、ことランダムアクセス性に関しては、まだ紙の本のほうが優れているかもしれません)。

そんな紙の本のランダムアクセス性を生み出しているのは、パラパラとページをめくって参照したいページを目で捕まえるという単純な動作です。この動作を助ける工夫をしてあげることで、使い勝手がよい技術書になれます。実際、世の技術書編集者もさまざまな方法で「読み返し」を助ける工夫をしています。

プロ編集者が得意なのは、レイアウトを工夫したりイラストを挿入したりすることで、本のあちこちに「目が引っかかる」場所を作ることです。学校のテスト中に、「この用語が思い出せない……教科書のあの辺に書いてあったのは覚えてるんだけど」という苦々しい気持ちになったことはありませんか? 人間、そんなふうに「書籍のページの雰囲気」はよく覚えているものです。紙面のレイアウトに変化をつけたり、ところどころにイラストを挿入したりするのは、組版屋さんがなんとなくでやっているわけでもないのです。レイアウトやイラストは著者が自分で工夫するのは難しい部分ですが、図とか表とか、あるいは数式とかコラムとかで、著者自身がそういう「ページにおける目の引っかかりどころ」を工夫をできる場合があります。

読み返してもらうときの工夫として、目次や索引も忘れてはいけません。技術書では目次や索引を付けるのは「あたりまえ」です。とくに索引は、全文検索の下位互換と思われがちですが、技術書に対して別の見方を提供できる便利なコンテンツです。この話は長くなるので、気になる方は手前味噌ですが以下のスライドに目を通してみてください。

Keiichiro Shikano “Indexing makes your book perfect”

http://www.slideshare.net/k16shikano/imybp-light

「読み返してもらうときのための工夫」のまとめ

  • とくに紙の本は、わりとランダムアクセス向き
  • それならば、ランダムアクセスする場合のことを考えよう
  • 目次とか索引を上手に使おう

5. 読み始めてもらうための工夫

技術書は、その技術を必要とする人が読むものです。ということは、ある技術書を読み始めてもらえるかどうかは、その本で解説している技術そのものの需要によってほぼ決まりそうですね。誰もが注目している新技術で、とにかく解説本が求められているという状況なら、「○○についての日本で最初の解説書」というだけで読み始めてもらえるでしょう。

でも、そういう本を書けるチャンスは必然的に限られます。うまくチャンスを見つけて書き始めたとしても、そもそも「最初の解説書」になれるとは限りません。怒涛の執筆力で「最初の解説書」の座を獲得できたとしても、次々に競合書が出てきてシェアを奪われるのは時間の問題でしょう。みんな考えることは同じなのです。

というわけで多くの技術書は、「みんながまだ必要性に気づいていない新技術」とか、「ある技術をよりよく理解するための基礎知識」とか、「特定の部分にフォーカスを絞ったすごく深い解説」とか、逆に「広い知見を得るための概説書」とかになるでしょう。こういう本は、何も考えずに執筆するだけでは読んでもらえません。というか、まず買ってもらえません。「この本の内容はこんなに価値があるから、みんなこの本を買って読むべきです!」というメッセージを作っている側が打ち出す必要があります。

読み始めてもらうために使えるツールとしては、「書名」や「カバーデザイン」のほか、「はじめに」とか「有名人による推薦文」、「帯」(カバーの上から巻いてある宣伝文とか載っているやつ)などがあります。出版社から発行する技術書の場合、「はじめに」はともかく、ほかの要素は著者の一存で決められない場合がほとんどですが、とくに「書名」については、企画の段階であれば著者として大いに提案できます。その際には、自分がかっこいいと思う案を提案するのではなく、「この本を必要としている人に手に取らせて読ませるための動機を与えるのに適切なタイトルは?」という具合に考えましょう。

さらに重要なのは、いわゆる「パブリシティー」です。出版社に任せるだけでは、潜在的に読んでほしい技術者には届きません。FacebookやTwitterでの徹底的な告知、非公式サポートページの準備、書評を書いてくれそうな人への献本、教科書にしてくれそうな教育機関への売り込みなど、すべて自分でやってしまうくらいの気持ちで十分です。このようなパブリシティーについて出版社の影響力は案外と限られています。自分でやるほうが、間違いなく良い結果になります。

「読み始めてもらうための工夫」のまとめ

  • ほとんどの本は、読んでもらうまでは存在しないも同然である
  • 読んでもらうための努力が必要
  • とくにネットでのパブリシティーは出版社に頼るな

「良い本だったけど赤字に終わったね」を技術書界から駆逐したい

というわけで長々と「売れる技術書の書き方」みたいな話を書いてみました。念のため免責を述べておきますが、ここに書いてあることを実践したからといってあなたの技術書が売れるという保証はありません。でも内容は間違いなく向上します。読んでもらう機会もきっと増えるでしょう。

技術書編集者が原稿に対峙するときに気を付けていることは、ここで上げた5つの工夫のほかにも、まだまだたくさんあります。句読点との付き合い方や文のリズム、箇条書きの使いこなし、対象読者とのインピーダンスミスマッチの整合、参考文献の形式などなど、それぞれの編集者の頭の中には言語化しにくい独自のノウハウや要出典のセオリーが山ほど抱え込まれているはずです。この記事をきっかけに、そういう工夫が見える化されて共有されたり、著者が自分で勝手に取り込んでいって原稿の質がもりもり改善されるといいなと思いました。

最後に、この記事はツチノコブログという技術書とはあまり関係なさそな媒体に掲載してもらえることになりました。ツチノコブログの中のみなさんの寛大な心に本当に感謝します。ありがとうございます。

DMM.com Labo デザイナーブログ始まりました

おはようございます。ライトノベル好きの新人ツチノコです。

DMM関連でお知らせがあります。

DMM.com Labo デザイナーブログが始まりました。
フロントエンド・Webデザイン・UXなどの技術やデザイン部からのお知らせなどが掲載される予定です。先行しているDMM.com Labo 開発者ブログ、ツチノコブログ(ここ)ともどもご愛読のほどお願いいたします。m(_ _)m