ちょっとだけ進捗
原稿書きを再開したのもつかの間、先々週、先週と何もせずに過ごしてしまった。文化の日の三連休の時はプライベートな用事があり、先週は会社の持ち帰り仕事があったことが一応の理由だが、要はやる気の問題である。半年間塩漬けしてしまった後遺症のせいか、なかなか気分が乗らない。
なんとかこの状況を打破しようと思い、先週の火曜日には日経BP社に行って編集者のTさんに会ってきた。考えてみれば、書籍の企画が通ってから、かれこれ2年になるのだから我ながらあきれたものである。結局、当日は本の企画の打ち合わせはほとんどせず、原稿を書く気になれない理由をダラダラと喋ってきた。自分で企画を持ち込んでから2年間も経ちながら、言い訳ばかりしているのも情けない話である。話し合いの結果、いつまでも塩漬けしていても仕方がないので、来月中旬までに1つの章を書き終えられなかったらこの企画はボツにしましょうという結論にしてきた。
そんなこんなで相変わらずの状態だが、今週は少しだけ原稿が進んだ。この週末は会社の持ち帰り仕事もなく、プライベートの用事も流れ、しかも今日は天気が悪かったので、原稿を書くのには最適な1日だった。いや、他にやることがなかったと言ってもいいだろう。しかし以前ならこんな日でも何もしなかったことを思えば、少しは尻に火がついたのかもしれない。
先日のエントリに書いたように、前回の本を書いた経験から、第1章は後回しにして第2章から書き始めることにした。第2章は練習問題を通じて、UMLの規則と集合論で物事を整理する能書きを解説する章である。連載の原稿をもとにしてはいるとはいえ、書き直しのボリュームは結構あるのでなかなか大変である。雑誌の記事の場合は、紙面の都合もあり、前提知識がある読者を対象にしているが、書籍の場合はもう少し基本的なところからきちんと掘り下げて説明する必要がある。そんなことを考えながら、解説の内容を考え直し、それに合わせて問題も作り直したら連載の原稿にほとんど手を入れる羽目に陥った。なんだか今回の原稿書きは職人的な感じがする仕事なので、飽きっぽい自分には向かないかもしれない。（ま、別に職人的な仕事じゃなくても向いてないのは間違いないけどね）。朝と夕方の2回ドトールコーヒーショップにこもって原稿を書いたところ、なんとか15ページぐらいまで書けたのは奇跡である。しかし最終的なボリュームとして想定している200-250ページぐらいに達するためには、まだこの15倍ぐらいの量を書かなければならない。まったくもって気が遠くなる仕事である(笑)。
第1章で思案中
先週に引き続いて、この週末もドトールに行ってきた。で、早速コーヒー回数券を使おうと思ったが、なんと家に置いてきてしまっていた。ま、自分に限って10回やそこらで原稿が書き終わるはずはないので、別にどうってことはない。
今日は書籍全体の構想を考えた。今回書くのはレッスン本なので、自宅にあった類似の本をひと抱えドトールに持ち込んで眺めてみた。眺めたのは以下の4冊である。
1) 論理トレーニング101題
2) マッキンゼー流 図解の技術 ワークブック
3) 将棋ワークブック―将棋を覚える人のためのやさしい詰みと必至
4) すらすらと手が動くようになるSQL書き方ドリル
どの本も練習問題に入る前の説明が少ないのが共通の特徴である。前書きはそこそこにしてすぐに問題を提示し、答えを説明しながらノウハウを解説している。3)だけは盤面の構成や駒の動かし方など将棋のルールを説明しているが、それでも必要最低限にとどめている。また1)や2)では最初の説明で悪い例を提示し、読者にモチベーションを与えていた。そういえば『リファクタリング』も最初に悪いコードを出して、それを改善する例を提示する方法をとっていた。うまくやれると効果的だが、最初に大きなUMLモデルを提示するのはかえって抵抗感を大きくしてしまうかもしれない。
自分が書くテーマは要件定義段階で行うUMLモデリングである。この分野の本はそこそこあるものの、実際に開発の現場でモデリングをやっている場面を見ることはそれほど多くない。したがってモデリングのノウハウを身につける効果を読者にきちんと伝えるために、ある程度は最初に能書きを書いておく必要があるだろう。しかし抽象的あるいは浮き世離れしたモデリング話を冒頭から書いて読者を煙に巻くのは、現実派を標榜する自分としては避けたい。冒頭の解説をどうするかが今回の悩みどころのひとつである。
本は一度しか書いたことがないが、第1章は特に難しいと思う。前回の本の時も第1章はだいぶ苦労した。最初に3〜4ヶ月ぐらいかけてドラフト版を書いたものの、本全体の半分強まで書き進んだ頃に書き直したため、結局当初の原稿はほとんど捨ててしまったことを思い出す。
一日いろいろ考えた末、前回の経験を生かして第1章は後回ししようと思う。ということで今週も進捗はゼロである(笑)。
ボチボチ再開するかも？
連載最終回掲載号が発刊されてから早いもので半年が過ぎてしまった。当初の予定では半年ぐらいかけて連載内容をふくらませて書籍化するはずだったが、1文字も書かずに半年間を過ごしてしまった。原稿を書かなかった理由は色々ある。
まずは暇が少なかったことである。春先の3月から5月ぐらいは会社の仕事が忙しく、物理的にも精神的にも余裕がなかった。6月頃には熱を出したり、鼻の裏側に腫れ物ができる奇病にかかったりもした。7月頃からは浅田次郎さんの小説にハマり始めた。『椿山課長の七日間』や『鉄道員（ぽっぽや）』は以前読んでいたが、今回は『蒼穹の昴』や『プリズンホテル』、『壬生義士伝』、『シェラザード』などの長編小説を立て続けに読んだため、通勤時間や休日の多くの時間を読書に費やす結果になった。
もう一つの理由は、自分自身の関心がモデリングから離れたことである。この春ぐらいからは現場仕事が減ったために、モデリングに対する関心が薄れてきた。関心が少ないテーマの文章を書くのはつらい。加えて、原稿書きという仕事自体に以前ほど新鮮味を感じなくなった気もする。今回のテーマについては10回の連載を書き上げてそれなりに満足したし、たったの1冊とはいえ書籍も2年前に出版させてもらった。副業ライターなので、休日に仕事をするためには強いモチベーションが必要だが、以前のような気合いが出ない。
そんなこんなで半年間を無為に過ごしてしまったが、いい加減に再開しようかと思い始めている。先週はとうとう意を決して近所のドトールコーヒーショップに行ってきた。結果は連載記事を読み返しただけで終わったものの、帰りがけに10回分のコーヒー回数券を買ってきたのが成果である。おかげで今朝もドトールコーヒーショップで数時間を過ごし、ほんの少しだけとはいえ、半年ぶりに原稿を書いた。
出版社さんともしばらく連絡を取っていない。思い返せば書籍の企画を通してもらったのはかれこれ2年前のことである。前作に続く2冊目の書籍として自分から持ち込んだ企画で、快くOKをもらったものの、執筆は一向に進まなかった。そこでまずは日経ソフトウエア誌に連載を書かせてもらい、その後で書籍化するという方法をとったが、結果はこの始末である。
ま、過去のことを振り返っても仕方がないし、今さら焦っても仕方ないので、気楽にやりましょ。ライフワークって感じで。
なぜオブジェクト台湾版
『オブジェクト指向でなぜつくるのか』の台湾版が手元に届いた。タイトルは『How Objects Work - 物件導向系統是怎麼運作的』となっている。翻訳者の方、ご苦労様でした。またありがとうございました。
韓国語版(id:ahirasawa:20050808)はハングルなので読むのは厳しかったが、今度は漢字ばかりなので抜群に読みやすい。漢字で横書きなのはちょっと意外だったが、自分の名前もそのままクレジットされているのが嬉しい。
気になる第1章のウォーミングアップクイズを見てみた。この件に関しては、翻訳者の方とのやりとりを以前ブログに書いたが(id:ahirasawa:20050418)、最初の選択肢に出てくる「訒麗君」という名前をググってみたら、果たしてテレサ・テンだった！（→Wikipediaへ）
これで中国人民10億人にリーチできたことになる(笑)。こうなれば世界征服の野望を果たすために、英語とスペイン語とアラビア語にも翻訳するしかない。でも誰もやってくれなさそうだから、ここは一丁、自費出版でもしますか(笑)。
連載最終回掲載号
先週末は病気で寝込んだため1週間遅れの告知になってしまったが、日経ソフトウエアの2006年5月号*1が発売された。
（→日経ソフトウエアのページへ、→Amazonへ）
特集のタイトルは「Google、Amazon、Yahoo!徹底活用 Web APIプログラミング！」である。APIというとOSやミドルウェアが提供する機能を指すものと思っていたが、最近ではこんな仕組みが提供されていることには感心した。自分は会社生活をリタイアしたら、シルバー世代限定のオープンソースコミュニティを作って、ボケ防止にプログラミングをやろうなどと密かに企んでいるが、こういう面白い仕組みを見ると今からリタイアしようか(笑)という気になる。
でもこのWeb APIに関してはちょっと疑問も感じた。GoogleやAmazonのAPIを利用してソフトウエアを作る開発者の側は面白いだろうが、結果としてAmazonやYahoo!モドキのサイトが乱立してしまうのだとしたら少々困りものである。とはいえプログラマの意欲をそそるとても面白い仕組みだし、きっとこの仕組みからいろいろな技術やアイデアが登場して、さらに発展していくのだろう。
さて、自分の連載記事のタイトルは「UMLでロジカル・シンキング！」である。この企画、すなわちシステム開発のためのデータモデリングの話を続けた後で、最後に整理術としてのUMLモデリングを紹介する構想は、連載当初から練っていたもので、タイトルも早くから決めていた。途中いろいろ迷ったが、なんとかほぼ当初の構想通りに書けたので自分としては満足している。
悩んだのはロジカル・シンキングの扱いである。元々は、UMLモデリングを「複雑な物事の整理術」としても利用できることを説明したかっただけで、ビジネス・コンサルティングで使うロジカル・シンキングを解説する意図はなかった。「ロジカル・シンキング」という言葉は、たんに「論理的に整理する技術」という意味として使っただけである。
しかし記事を書いていて別の懸念が出てきた。それは2つの練習問題をそこそこうまく作れたため、“UMLモデリングなら森羅万象を整理できる”とミスリードしてしまう懸念である。DOAの人達はデータ構造設計の枠からはみ出さないが（数学系に走る人はいるようだが）、UMLモデリングだとデータ構造設計に限定する歯止めがきかないためか、森羅万象を表現する方向に走る人を今まで何度か見てきた。
そこでUMLモデリングでうまく整理できない例として「主婦の悩み」を持ち出し、MECEとロジック・ツリーで整理する例を簡単に紹介してみた。結果的に、記事としては詰め込んだ感じになってしまった気もするが、まあまあのバランスだったのではないかと思っている。何しろロジカル・シンキングの解説をきちんとやり始めると連載の主旨から逸脱してしまうし、このテーマに関しては会社の同僚が「ITアーキテクト」誌（IDG Japan）に別の連載を書いているから。
しかし、改めてこの記事を読んでみて、雑誌全体の中で「浮いている」感を強くした。今までも同じ感覚はあったが、特にこの最終回は「浮いている」感が際だっている。何しろ練習問題は「ビジネスにおける課題の答え」に「犯罪の成立要件」だし、記事の内容もソフトウエア開発とほとんど関係ない。ま、でも10回頑張って書いたんだから、1回ぐらい遊んでも許してくださいな。
古典落語を喋ってきた
昨日は会社関係のおつきあいで、テクノブレーンさんのセミナーでUMLモデリングの講習会をやらせていただいた。昨年の夏はモデリングライブだったが(id:ahirasawa:20050709)、今回の企画はワークショップ形式の勉強会である。とはいえ内容は会社で時々やっている勉強会のままで、特別な資料を準備せずに済んだため、楽だった。
参加者の多くは20代から30代ぐらいのまじめそうな技術者の方々だった。無料セミナーとはいえ、土曜日にわざわざ勉強会に出かける姿勢には頭が下がる。少なくとも自分は若い頃に、休日の社外勉強会に参加した記憶はない。もっとも毎週のように休日出勤していた気もするが(笑)。
題材はインターネットの自動車ディーラーである。モデリングの基本として、種類とブツの区別があるが、新車と中古車の情報の持ち方を考えることで、それに気づいてもらおうという意図である。しかし実際にやってみると、「車の種類」のとらえ方がなかなか難しい。何しろスカイラインやカローラなどの車種（愛称）、サンルーフやエアバッグなどの個々の装備、排気量や装備の違いによるグレード、色などいろいろな要素があるためである。「車両型式」の意味をズバリと説明できる人がいると話が早いが、そういう人に出会うケースは意外に少ない。
しかし、このネタを使ったワークショップもずいぶん場数を踏んだ気がする。少なくとも20回、おそらく30回以上実施しただろう。自分にとっては、古典落語のような位置づけになりつつある。もちろん相手は毎回違うのでそれなりに発見もあるが、ちょっとマンネリ感が出てきた気もする。連載も終わったので、そろそろ別の題材を考えてもいいかとも思った。しかし、せっかく連載が終わったんだから、そんなに頑張って仕事ばかりする必要もない。ということで、もうしばらくは古典落語を喋り続けることにしよう。
