Home > book

book Archive

何のために開発するかを考える – リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

  • 2012-08-30 (木)
  • book
この記事の所要時間: 532

お盆休みに最近話題の「リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす
」を読みました。Webサービス、システム開発を行う人間にとって示唆に富む内容だったのでご紹介。

ジャスト・ドゥ・イット型起業からの脱却

「とりあえず製品をリリースして様子を見よう」という方針で進むと、このような問題に悩まされがちだ。私はこの方針をナイキの有名なスローガンにちなんで「やってみよう(ジャスト・ドゥ・イット)」型起業と呼ぶ。

新しい製品やWebサービスの多くはこれまで世に無かったものなので、事前に市場調査を綿密にしていても、実際にリリースしてみないと反応が分からないことが多いです。とくに小規模のベンチャーでは市場調査などを行う人材がいない、リソースが割けないということもあり、まず作ってみようというジャスト・ドゥ・イット型で進めることが多くなります。

これはこれで一理あるのですが、闇雲に機能を実装してリリースしても「下手な鉄砲も数打ちゃ当たる」状態になり、上手くいかなかった場合(多くの場合はこうなる)に得られる学びも少なくなります。

私自身もこれまでいくつかWebサービスやアプリを作って来ましたが、多くはまさにジャスト・ドゥ・イット型の開発でした。時には上手くいくこともありましたが、次の手がうまく打てずに萎んでしまったり、工数をかけてじっくりと作ったわりに鳴かず飛ばずでうまくいかないということもありました。

もちろん、そんな簡単にヒットするものが作れないのは当然です。ただ、運を天に任せて、下手な鉄砲を撃ちまくるのでは、宝くじを買うようなものでいつまでたっても陽の目を見ることができません。

そこで、ジャスト・ドゥ・イット型に科学的手法を取り入れて、もう少し成功の確率を高めていこうというのがリーン・スタートアップです。

リーン・スタートアップとは

リーン・スタートアップは、トヨタのリーン生産方式に基いて考案されたもので、顧客にとってのメリットを提供するものに価値をおき、それ以外のものは全て無駄という考え方です。これは至極当たり前のように思えるのですが、サービスを作る側、とくにエンジニアやデザイナのようにもの作りをしている人間の場合、この点を見過ごしてしまいがちになります。

本来は顧客へ何らかの価値を提供するためにものを作るべきなのに、ものを作ることに重点が置かれてしまい、下手をすれば、ものができてからそれが顧客にどんな価値をもたらすのかを考える、という本末転倒な事態になることもあります。

あくまで重要なのは「顧客に価値を提供する」という点なので、それに寄与しないもの(自分たちが作ったものも!)は無駄なものとしていさぎよく捨てる覚悟が必要です。

仮説、構築、計測、学び

リーン・スタートアップでは、まず顧客にどのような価値を届けるか、届けるとどのような反応が返ってくるかという仮説を立てます。そしてその仮説を確かめるために製品を開発します。製品が完成したら、実際にリリースして計測を行ないます。計測で得られた結果、反応を見て、仮説が正しかったかどうかを検証します。そこで得られた学びを元に次の仮説を立てて、また製品を作っていきます。

この一連の流れを小さく早く回して、顧客の反応を確かめながら進んでいくのが特徴です。

つまり「ものを作る」というのはあくまで仮説を証明する手段にすぎません。よって仮説が証明できれば、機能自体は実装しない場合もあります。

極端なことを言えば、最も簡単に仮説を検証できるのは、顧客に直接聞くという手法です。その製品がターゲットとしている顧客にコンタクトを取って、提供しようとしている製品を話せばすぐにフィードバックを得ることができます。もちろん、実際にものが無いと想像できない場合も多いのですが、少なくともそれを欲している人がいるかどうかくらいは分かります。

本書では、仮説を証明するための必要最低限な製品をMVP(Minimum Viable Product)と呼んでいます。このMVPは仮説が検証できれば良いので、それ以外の機能や品質は不要です。

これは自分でもついやってしまうのですが、こういう機能なら今時はソーシャル連携するだろう、Ajaxになっていないといけないなど、機能の本質では無い余計なものまで作りこんでしまうことがあります。もし、その機能自体が誰からも必要とされていなから、そういった余計なものは全て無駄となってしまいます。

まずは仮説を立てる。そしてそれを確かめるために製品を作る。このアプローチがとても大事です。

開発の現場では当たり前のこと

この一連の流れは視点を変えれば、実は普段からシステム開発の現場ではやっていることと同じです。

例えば、不具合を修正する場合。

不具合の報告を受けて、現象が確認できたら、まずやることは原因を特定することです。原因を特定するには、ここが原因だろうという仮説を立てます。そしてそれを確かめるためにソースを読む、コメントアウトしてみる、テストを書くなどを行ないます。そして実際に動かして仮説が正しいかどうかを確かめます。原因が特定できれば次は修正方法を検討します。そして、修正を行ない、不具合が解消されているかを確かめます。

これはまさに「仮説、構築、計測、学び」のサイクルと同じです。そう考えるとごく自然にこのアプローチが理解できます。

何のために作るかを見つめなおす

やってはいけないことをすばらしい効率で行うことほど無駄なことはない。

有名なドラッガーの言葉が本書でも引用されているのですが、もの作りを行う人間が陥りがちな状況を的確に表しています。誰も求めていない製品を最高の品質で作っても事業としては意味を成さないのです。

自分たちが作っているものは誰のどんな問題を解決するのか、どんな価値が提供できるのか。事業を行う上でも、ものを作る上でもあらためて考えさせられる本でした。

この本ではさらにリーン・スタートアップを行う具体的な手法や実際の事例がふんだんに盛り込まれています。事例には、DropBoxやインテュイット、グルーポンなど馴染みのある企業が登場します。また、アジャイル開発や継続的インテグレーション、Railsなど開発現場で聞かれる単語も登場するなど、自分に近い話として読むことができました。おすすめです。

リーン・スタートアップの原点ともいえるトヨタのリーン生産方式に関する本です。

  • コメント (Close): 0
  • トラックバック (Close): 0

blogに使える、わかりやく伝える3つの技術

  • 2012-02-27 (月)
  • book
この記事の所要時間: 456

「わかりやすく<伝える>技術」からblogに使える3つのテクニックをご紹介。

テレビでお馴染みの池上彰さんの著作「わかりやすく〈伝える〉技術」を読みました。

タイトルどおり、とても読みやすく、分かりやすい内容になっています。読んでいると池上さんがテレビでお話されているかのように、すんなりと頭に入ってきます。

随所に<伝える>技術が盛り込まれているのですが、その中から、blogを書くのに使える技術を3つご紹介しましょう。

1. 伝えたいことをはじめに書く

最初の一文にこのエントリで伝えたいことの概要を簡潔に書きます。

こういったリードがあると、読み手はエントリ自体が何に関するものなのか、どういった方向に話が進むのかというのを理解することができます。この本で言うところの「地図を渡す」ということですね。

全体の流れとしては「概要 or 結論 -> 記事 -> 結論」となります。はじめに提示した結論が良い前フリとなり、記事本文を迷わずに読むことができて、最後は「なるほど」と腑に落ちます。(もちろん内容が伴わないといけないですが)

最初の一文が大事なのは、エントリが読みやすくなるだけではありません。

ソーシャルメディアでは、エントリの序文が掲載されることがあります。はてなブックマークでは、エントリの書き出しのあたりが掲載されます。Twitterでもblogエントリの序盤をtweetするbotがいます。はじめにエントリの内容を簡潔に書いておけば、より多くの人に見てもらえる可能性が広がります。

はてなブックマーク
306F3066306A30D630C330AF30DE30FC30AF - PHPUnit 30C630B930C830B130FC30B9306766F8304D63DB3048305F502430925FA95E303059308B - Shin x blog

ねえ、ねえ、大変!

では分かりやすいリードを書くにはどうすれば良いでしょうか?

ユニークな方法が紹介されています。

相手に自分が体験したことを面白く伝えたい。自分の気持ちをわかってほしい。
そんたとき、まず、「ねえ、ねえ、大変」という言葉から始まる文章を考えましょう。

この言葉の後にエントリで伝えたいことを書けば、それが自然とリードになるという方法です。

例えば、「ちょー聞いてーや、この本めっちゃ面白いで!」というのがまず伝えたいことで、その後に「この本は池上彰さんが書いた本でな、分かりやすいわ−」というように伝えたいことの肉付けをしていきます。

これは友人や家族へ話す時は自然とやっていることですね。誰かに伝えるつもりで書いていけば、自然とリードをまとめることができます。

2. 文章を短く切る

これは目から鱗というか、恥ずかしくなったというか、安心した技術です。

短い簡潔な文章を重ねるより、長く小難しそうな文章を書いたほうがなんだかかっこ良く思えて、ついつい一文を長めにしがちでした。これをこの本ではバッサリと一刀両断しています。

たとえば、三つの荷物(要素)を、相手(聴き手)のもとに届けるとします。三ついっぺんに運ぼうとすると、ヨタヨタしてしまい、なかなかたどりつけません。一回に一つだけにすれば、簡単に届けられます。それを三回繰り返せばよい。原稿も同じ事だろうと考えました。

考えてみると当たり前のことですね。伝えるために表現として文章を書いているのだから、伝わりやすい方法で書いた方が良いに決まっています。

引用した文章は、まさに短い文で構成した好例です。読んでみるとポンポンとリズム良く文章がやってきます。実にわかりやすい。

短く文章を切る効果は他にもあります。

一つの長い文にすると、文章の中身の要素同士が論理的につながっていなくても、まるでつながっているように思えてしまうのです。たとえば、「〜で、〜ということから、〜といえる」などと文をつなげていくと、論理的な文章に見えてしまうことがあります。

長い文章を書くと書いてる本人も気づかず「それっぽい」文章になってしまうため、論理的につながっていない文章を書いてしまうことがあります。読み手としては「それっぽく」は見えますが、意図がうまく伝わらないため、「結局何が言いたいんだろ?」という感想を持つかもしれません。

短い文にすると、このごまかしが効かないので、意図を明確に伝えることができます。

3. 三の魔術

日常的によく言われていることですが、なぜかこの3という数字はおさまりが良いです。

「大事な事は一つだけです」でもいいのですが、もういくつかあったほうがありがたい気がします。「二つあります」でも「え、二つでいいの?」という物足りない気分になります。それが「四つある」だと、今度は多い印象を受けてしまいます。

伝えたいことが5つあっても、優先順位を考えてとにかく3つに絞ります。これは3という数字が良いというだけでなく、制限をかけることで伝えるポイントをより明確にすることができます。

書き手としても、5や10伝えることを考えるのではなく、たった3つに絞ればすれば良いので、書きやすくなるというメリットもありますね。

<伝える>人には必読の書

本書にはこのエントリで紹介した3つの技術に限らず多くの技術が紹介されています。

「図解する」「プレゼンテーション資料から話す内容を調整する」「パワーポイントにパワーポイントを使う」「具体例を示す」「接続詞の使い方」などなど参考になる技術がたくさん紹介されていますが、三の魔術に従い、あえて3つに絞りました:D

日々の暮らしでは、blogに限らず、ありとあらゆる場面で「伝える」という行為が行われています。

本当はこう言いたいのに、もっと上手く伝えたい、わかりやすく話したいという方にはオススメの一冊です。新書なので持ち運びにも便利なので、ぜひ手にとって読んでみて下さい。

人前で話すことへの恐れを解決する5つの方法

この記事の所要時間: 657

人前で話すことに抵抗がある人にオススメな本があったのでご紹介。

パブリックスピーカーの告白 —効果的な講演、プレゼンテーション、講義への心構えと話し方

著者のスコット・バークンは、マイクロソフトで1994年から2003年にかけて働き、主にIE1.0から5.0のプログラム・マネジメントを担当していたという経歴の持ち主です。プログラマとしてはなんとなく親近感が湧きますね。

この本では現在講演家として活動している著者のノウハウが記されているのですが、著名な講演家の高度なテクニックというよりは、率直に一人の人間として講演、発表に向かう姿勢が書かれています。これまで数多くの発表をこなしている著者でも発表前には恐怖を抱き、それに対処するために様々な努力を重ねている点についてはとても参考になります。

この本を読んで感じた人前で話すことへの対応方法を5つにまとめてみました。

1. ささいな失敗は起こるもの。気にしない。

発表に失敗はつきものです。しかし細かな失敗はたいてい聞いている側は気にしていません。

話がだとだどしい、噛む、間があく、スライドの誤植、スクリーンからスライドが少し切れている、などなど発表者としては気になる小さな失敗はたくさんありますが、聞く側はそれを認識はしますが、それが発表の印象にはそれほど大きく繋がりません。

本書では、デール・カーネギーの「Public Speaking for Success」からの引用を用いて、同じ発表でも話す側と聞く側でいかに印象が違うかが語られています。

よい講演家が話し終えたとき、通常そのスピーチには4つのバージョンが生まれています。その講演家が話したスピーチ、その講演家が準備したスピーチ、その講演家が話したと新聞に伝えられているスピーチ、そして、講演家が帰宅途中でこう話せばよかったと思うスピーチです。

大事なことは話すべきこと、発表の内容であって、まずはそれに注力すべきです。

2. 「人前で話すのは怖い」ということを自覚する

本の中では「人類の最大の恐怖」というリストが紹介されています。

1. 人前で話す
2. 高いところ
3. 虫、虫、そして虫
4. お金の問題
5. 底なしの水
6. 病気

さすがにこれは大げさですが、こんな例えが出るほど、やはり人前で話すということは怖いものです。人前で平然と話す人でもよく観察すると緊張している様を見ることができます。

まずは、人前で話すのは怖いということを自覚し、それは当然のことだと受け入れることが大切です。

本書ではその恐怖を克服する有効な手段として事前準備の重要性について語られています。

3. 事前準備がとにかく大事

パレードの法則などで「段取り8割」と言われていますが、まさにこれですね。事前準備の出来によって発表の出来が大きく左右されます。

本書では事前準備としては、発表内容を考える、スライドを作成する、練習するなど通常の準備で行うことはもちろんのこと、さらに会場への入り方、発表機材のチェック方法、発表時間までの過ごし方、など数多くのTipsが書かれています。

会場への入り方や発表時間までの過ごし方などは、いわゆる勉強会での発表に際しては、やや過剰気味に見える気もしますが、これらは全て「人前で話すときの失敗をできるだけ避けるため」であり、さらに「その失敗の想像から来る恐怖を軽減する」ためのものだと感じました。

「たかが勉強会の発表のために、こんなことまでやらなくて良いかな」ということでも、自分がそれをやって楽に発表に望めるならやっておいた方が良いです。

プログラマー的な発想でいうところの「怠惰」と似た感覚ですね。(本番で楽するために全力で準備しておく)

出来うる準備は全てやっておいて、そして気持ちを楽に本番に望みましょう。

4.準備にかける時間

ではどれくらいの時間を準備に割けば良いかということですが、それについて参考になる内容があります。

100人があなたの話を1時間聞く場合、それはあなたが言わなければならないことに対して聴衆の100時間という時間が充てられるということを意味します。聴衆のために準備をし、聴衆について考え、聴衆の必要性に最も合うようにあなたの考えを磨くために、5時間、10時間という時間を充てられないとしたら、聴衆の時間に対するあなたの尊敬の念についてなんと言っていることになるでしょう。

これを5分のLT(ライトニングトーク)に当てはめると、聴衆が200名であれば、5分*200=1000分という他人の時間が充てられるということです。これだけの時間が充てられるのですから準備に時間をかけるのは当然のことかもしれません。

ただし、これは1000分かけて準備しなければならないということではなく、最大それくらいの時間を準備に費しても良いということだと思います。(技術系の発表では調査含めて、さらに多くの時間がかかることも多いですけどね:D)

もし準備に時間がかかることを気にしているならば、実際の発表では聴いている方からこれだけ多くの時間を頂くわけですから、安心してじっくり時間をかけて準備をしましょう。

5. 練習のススメ

これは最も大事な事前準備と言っても良いかもしれません。発表の練習です。

ここでいう練習というのは、発表で話す内容の一文一句を間違えずに話すようになるということではありません。

私の目的は単に自分の原稿を理解して十分に安心できる状態になることです。完璧ではなく、自信が目標です。

話す言葉はその時々の表現で問題無いのですが、話すべき内容、発表で主張したい内容のいわゆる発表の芯の部分を徹底的に磨いていく作業が練習だと思います。

この発表内容を精査していく手法として以下のような方法が紹介されています。

私は練習するとき、特に新しい原稿の草稿で練習するとき、たくさんの問題に遭遇します。そしてつっかえたり、混乱したりしたときには、そこで中断し、次の選択肢から一つ選びます。

・もう一度やればうまくできるだろうか?
・このスライドかこの前のスライドを変更する必要があるか?
・この文章すべてを一葉の写真と説明に置き換えることができるか?
・前の論点からこの論点へのもっと良い誘導方法はあるか?
・この論点またはスライドまたはアイデアを単に完全に無くしてしまったほうが全体的に良くなるだろうか?

大きな間違いをせずにひと通り最後まで話し終えられるようになるまでこの過程を繰り返します。

発表で伝えたいことが明確であれば、表現で多少つまづいても大きな問題にはなりません。それより結局何が言いたかったんだ?という発表の方が問題です。

誰もいないところで一人で練習するのはなんだか小っ恥ずかしいですし、やり辛いものです。しかし事前に練習を行っておけば論点の矛盾や展開のつまづきに簡単に気づくことができます。

発表が苦手な人ほど練習を避ける傾向にあるようなので、次回の発表ではじっくり練習をやってみてはどうでしょうか。

他にも気になるTips

発表への苦手意識を克服するという視点で取り上げていますが、この本では他にも発表について数多くのTipsがあります。

個人的には以下の内容が面白かったです。

  • 主張の伝え方
  • リモコンやモニタ、マイクなどの機器について
  • 「えー、あー」を止める方法
  • 話を聴いてくれない、質問を執拗にする、など少し困った聴衆に関する対処
  • 発表内容、タイトルを考える方法

人前で話す人にオススメしたい本

著者のような著名な講演家が練習をじっくりやっているという点について非常に心強く感じました。私自身も過去の発表でうまくいったと思う時は、事前に準備をしっかりやったときです。これからも安心してしっかり準備したいと思います。

本書では他にも著者自身の発表に対する考え方がユーモラスな表現を交えて率直に書かれており、とても地に足がついた内容になっています。人前で話すこと本業にするような人だけでなく、私のように勉強会などで話す程度の人間にとっても役立つ内容が盛りだくさんとなっています。

信頼のオライリー・ジャパンですし、ぜひ一度手にとって読んでみて下さい。(お知り合いの方ならお貸ししますので、連絡下さい。)

7/25にCakePHP Cafe LiveTalkを行います。

この記事の所要時間: 118

CakePHP1.2ガイドブック刊行記念イベントとしてトークイベントを行います。

「CakePHP Cafe LiveTalk」

安藤祐介×岸田健一郎×新原雅司

  • 会場:ジュンク堂書店 池袋本店(TEL:03-5956-6111) 4F喫茶にて。
  • 日時:7/25(土)19:00~
  • 入場料:1,000円(ドリンクつき)
  • 受付:1階 案内カウンターにて。電話予約承ります。

安藤さん岸田さん、新原の3人で、CakeFestやら、CakePHP本やら、CakePHPやらについてお話する予定です。

CakeFest開催後のイベントとなるので、現地に行かれる安藤さんのお話はフレッシュでとても楽しみです。もちろん岸田さんも私も負けじとCakePHP話を繰り広げるつもりですよ。

普段の勉強会とはまた違った雰囲気のイベントとなるので、日頃聞けないような話が飛び出すかも:-D

参加される方はジュンク堂池袋本店1F案内カウンターにてお申し込み下さい。また遠方の方などお申し込みに行けない方はTELにて予約できるそうですので、ご確認下さいませ。

[2009/06/16] まだ受け付け開始していないようです(id:cakephperさん情報ありがとうございました!)。受付開始後にご案内しますので、お待ち下さい。

[2009/06/19] 受け付けを開始しました。ふるってご参加下さい:-D

イベント後は有志による懇親会なども企画しているので、夏の夜にみなさんで盛り上がりましょう!

CakePHP1.2ガイドブックが出ます

この記事の所要時間: 10

一部でお待たせしていましたCakePHPガイドブックの1.2版が今月下旬に発刊されます。

表紙が青になっているのがポイントですね:-D

この本では、単に1.2対応としただけでなく、章によっては全面書き直しや新機能の加筆といった作業を行ったので、ガイドブックからは50P増になりました。

1.2では多くの機能が盛り込まれており、この1冊で全てを網羅することは難しいのですが、ガイドブックにあった「導入」「実践」「応用」の流れはそのままに、必要な情報を取捨選択して1冊にまとめました。

CakePHP初心者の方から中級・上級の方まで参考になる本となりましたので、是非手に取って頂ければ嬉しいです。

前作のCakePHPガイドブックは私自身初めての書籍ということで思い入れの強い本でした。その続編である本書を書く際はこの1年半を振り返る意味でも有意義なものでした。

一緒に執筆した堂園さん、安藤さんには、、、、、、、、

と、言った話をするトークイベントを7/25に池袋ジュンク堂さんにて行います。こちらも楽しいイベントになりそうなので、ご参加下さいませ-。

イベントについてはこちらで。

「CakePHPによる実践Webアプリケーション開発」が出ます

この記事の所要時間: 17

執筆に関わった「CakePHPによる実践Webアプリケーション開発」が今月末に発売されます。

私は「Chapter 4機能を拡張する」を担当しました。

本書全体では一つのシステムを構築していく流れを解説しているのですが、私の章ではそのシステムの拡張を通して、メインでは触れていないフレームワークの機能を解説しています。

「メール送信」「携帯対応」「CSV出力」といった現場ではよくある機能をいかにCakePHPの機能を使って実装するかについて書いてるので、実際の開発に取り入れやすい内容だと思います。活用して頂ければ嬉しいです。

ちなみに個人的には本書の目玉はChapter 3のユニットテスト解説だと思ってます。

フレームワークに即したユニットテスト解説がしっかりと書かれているのはCakePHPに限らずわりと珍しいように思います。しかも書かれているのが、CakePHPカンファレンスや勉強会でテストについて講演されているきしださんなのでこれは間違い無いです。

テストを書いた方が良いのは分かるけど、どう書けば良いか分からないという方には是非手に取って貰いたい本です。

もちろん安藤さんの導入も見逃せないところですよ:-D

というわけで発売までしばし時間がありますが、よろしくお願いします!

PHP×携帯サイト デベロッパーズバイブル

この記事の所要時間: 21

PHP×携帯サイト デベロッパーズバイブルを著者の荒木さんから献本して頂きました。
# 荒木さんおめでとうございます&ありがとうございます。

現場から生まれた本

ざっと読ませて頂いたのですが、さすが携帯サイトの開発に携われてきた荒木さんが書かれた本だけに、様々なノウハウがぎゅっと詰まっています。

3キャリアの公式情報から目的別(文字エンコーディング変換やらメールやら絵文字やらセッション管理等々)に欲しい情報が抽出されているのはもちろんのこと、公式の情報には明示的に記載されいていないノウハウが解説されています。

# 個人的にはメール絵文字(特にVodafone/Softbank)が泣けてきました:-D

こうした情報は実際に携帯サイトの開発に携わらないと分からない点で、まさに現場から出てきた本だと言えます。

対象機種選定の材料に

本書では携帯サイトの仕様について多くの解説があるのですが、構築する携帯サイトの対象機種を現行機種(3G)に限定すると、全てを実装する必要はありません。(もちろん本書内でも触れられれています)

これから携帯サイトを作ろうとしている人が陥りがちなのが、こうした仕様を見ると、全てを実装しようとしてしまう、すべきだ、と思い込んでしまう事です。

全端末対応が理想なのは確かなのですが、下位機種については対応する実装が複雑になりがちなわりにユーザ数が少なかったりするので、こうした機種は対応しないという選択肢が現実的だったりします。

そうしたケースで判断に必要なのが「下位機種対応のコスト」で、コストを計る上でこの本にある詳細な解説が参考になります。(単純にクライアントや上司を説得する材料になりますね)

そういった意味では、実際に開発をしなくても、携帯サイト制作に関わる人(デザイナさんや営業さん等々)なら、携帯サイトの仕様を知る面で価値のある一冊ではないでしょうか。

将来は

個人的には近い将来3キャリアの仕様が統一されて、本書のような解説書が無くとも携帯サイトが作れるようになってくれると嬉しいですね。:-D

現在の流れとしては、以前よりも3キャリア共に同じような仕様になりつつありますので、いずれは実現すると思います。

3キャリアの仕様が統一されて手軽に作れるようになった頃に、本書を見て、携帯サイト開発の歴史を振り返る、なんてのもオツですね:-D

自分の本が書店に並んだ

この記事の所要時間: 67

先月末に共著者として執筆したCakePHPガイドブックが書店に並びました。

書籍を執筆するということはとても貴重な体験でした。以前から書籍や雑誌の記事を執筆したいという想いはありましたし、いずれ実現したいと思っていました。しかしそれはあまりにぼんやりとしたもので、目標というよりは憧れでした。それがひょんな事から執筆に参加することができ、本が出版されました。

いろいろな事があった出版への道のりでしたが、執筆に関わる前(実際に執筆するなど想像もしていなかった頃)に疑問に思っていた事が実際どうであったかについて書いてみます。

執筆のいきさつは?

そもそもなぜ執筆する事ができたか。これまで私は書籍どころか雑誌等に寄稿したことなども全く無く、まともに原稿を書いた経験はありませんでした。

何人かの人には「企画持ち込んだの?」とか聞かれたのですが、実は出版社側からオファーがありました。いや、ホントですよ。オファーはありましたよ。ありました、ありました、堂園さんに:-D。

知名度も何も無い自分にお声がかかるはずはありません。。。出版社から堂園さんへCakePHP本のオファーがあり、堂園さんから共著で執筆しませんか、とお声をかけて頂いたという流れです。

お話を聞いた時は是非やりたいと返答はしたものの、この段階では全くリアリティーが無く、自分(達)の本が出るかどうかは半信半疑といったところでした。

書く内容はどうやって決める?

出版社の担当の方と執筆者3人との打ち合わせ時に大枠を決めました。ここでは、3部構成にする、執筆者ごとに担当する決める、部の大まかな構成を話し合いました。目次構成などは以後オンライン上でWikiやMLを通じて決定しました。

書く前は目次だけどうやって決めるんだ?とか思っていたのですが、やってみると意外と決まるものですね。あとこの段階の目次は仮なので書き進めている中で変えていくのもアリです。

ちなみに私が担当したのは3部の応用編(Ajax除く)でした。私自身書きたい内容だったというのはもちろんなのですが、ここでは各章にそれほど繋がりが必要でなく、blogや雑誌の記事を書く感じで短いページ数の内容を数多く書くという作業だったので、書きやすいのではという配慮もありました。(実際これは助かりました。;-))

何を使って書くの?

3人ともWordで原稿を書き、MLで送るというパターンを取りました。書き方自体は執筆者が望めばいかようになるようです。今回は3人とも特にこだわりが無かったので、皆が共有しやすいようにこのような形になりました。

あと上でも触れましたが、情報共有はMLとWiki、原稿共有にはFTPサーバを使いました。

書くのって大変じゃない?

大変でした。;-)

調べて書く、書いて気になった箇所を調べる、というのはblogと同じなので(まあこれも大変ですが)、気にならないのですが、表現というか上手く文章にするのが大変でした。自分の文章力の無さを痛感しました。。。

また、少ないながらも投稿後すぐにアクセスやSBMで反応して貰えるblogとは異なり、章を書き終えてもすぐには反応が得られないので、気力を補うという部分が少ししんどかったです。ただこの点については共著だったおかげで、お二人に救われました。

書くための時間は早朝や夜中などのオフタイムが中心でしたが、仕事に余裕がある時は日中、事務所で書いてました。休日は午前中だけ書いて、午後から家族と過ごすような感じでした。

書く場所は事務所や家もあるのですが、カフェが一番はかどりました。あとこの頃は東京出張が多かったので新幹線の中も貴重な原稿書きの時間でした。自分の場合、全くプライベートな空間より少し公共の場の方が集中できて良かったです。(もちろんNCイヤホンは必須ですが;-))

報酬は?

本を書く話を友人にすると「印税生活やな!」とちゃかされるのですが、全くもってそんな事はありません。(いや本がアホほど売れれば別ですが、技術本なんで;-))

これまで本を書いたという人からは「儲からない」と聞いていました。(中にはオファーがあっても仕事の方が儲かるので断っているという人もいました。。。)

実際に提示された内容は書けませんが(・・・)、具体的な数字を見た時は率直に「それほど悪くはないんだなあ」と思いました。まあただ一つ言えることは、時給計算はしてはいけません。悲しくなります。

まあ何より「本が出る」という事の方が大きいですのでこれは納得です。

実際に本が書店に並んで

はじめはもっと感慨深いかと思っていたのですが、色々とドタバタあったのもあって、ホッとした気持ちの方が大きかったです。あと何だか気恥ずかしいような気もあります。

もともと本屋は好きなのですが、あちこちの書店に行くのがさらに楽しみになりました。先日ある書店でまさに目の前で本を手に取ってくれている人がいたので、思わず声をかけそうになりました。;-)

周りの反応は様々ですが、やはり技術系の方の方が受けが良かったです(お祝いケーキも頂きました!)。妻は書いている時は半信半疑な感じだったのですが、実際に書店で見た時は喜んで貰えました。

あといくつかのblogではレビューを書いて頂きました。blogやサービスに言及されるのとはまた何か違う感じがしますね。嬉しいです。

謝辞

色々とありましたが、こうして無事に本を書くことができたのは多くの方との関係があったからと思います。

まずid:shimookaさん。私がこの本に関わるストーリーはshimookaさんとの出会いが原点です。以前から本を書く事に対する憧れはあったものの、環境や状況のせいにして一歩を踏み出すことをしていませんでした。しかしshimookaさんの著作で同じような環境の人が実際に事を成し遂げているのを知りました。自分が単に言い訳しているだけなんだと悟りました。もちろんこの時点では執筆の話しなど全く無かったのですが、ここから流れが変わったような気がしています。

マイコミ出版の方々にはお世話になりました。ずぶの素人の私が執筆することができたのは皆さんのアドバイスのおかげでした。あと編集を担当していただいたT氏にはプロの仕事を見せて頂きました。(その成果は書籍に現れています!)

そして共著者である堂園さん、安藤さん。お二人との出会いなくしては今回の書籍はあり得ませんでした。きっかけそのものを頂いたのももちろんですし、内容や目次、原稿についても多くのアドバイスを頂きました。お二人の原稿はもちろんのこと、ML内でのやり取りや仕事の進め方など多くの事を勉強させて頂きました。書籍に限らずCake関係や開発などでまたご一緒できればと思います。(そろそろCakePHP勉強会やりましょうか!)

他にも多くの方にアドバイスや励ましを頂きました。皆さん本当にありがとうございました。

最後に実態の見えないよく分からない事に興じているダンナを明るく支えてくれている妻、いつも愛くるしい笑顔で父を励ましてくれた2人の娘にありがとうと言いたいと思います。ありがとう。

# というような謝辞をいつか書いてみたかった:-D

# 謝辞ってみんな同じような事かくよな、と思ってたけど、なんだか自分もこういう気持ちになった。:-p

CakePHPガイドブック登場

この記事の所要時間: 032

先日ご案内したCakePHP本がいよいよ登場します。タイトルは「CakePHPガイドブック」です。

ベタな名前ですが、あえて奇をてらわず、定番となる本になって欲しい!という執筆陣の思いが詰まっています。またカバーもシンプルなデザインになっているのでオフィスに置いて頂いても違和感無いかと思います。

10月末頃には書店に並ぶそうです。見かけたら一度手に取って頂ければ嬉しいです。

# 私自身も初めての書籍なのでとても楽しみです。;-)

出版元のマイコミさんのサイト [MYCOM BOOKS – CakePHPガイドブック]

CakePHP解説本を書きました

この記事の所要時間: 046

先日のPHPカンファレンス2007で安藤さんが発表されたとおりCakePHPの解説本が出版されます。

この本の執筆にcakephp.jp管理人である堂園さん、そしてPHP勉強会やカンファレンスでお馴染みの安藤さん、と共に参加させて頂きました。

原稿はほぼ書き終えた状況で、現在は10月出版を目指して諸々の作業を行っています。

これまでもCakePHPを扱った書籍はあったのですが、単独での解説本としては(世界?)初となります。基本的な使い方から実践的な内容までカバーしているので、CakePHPユーザはもちろんの事、フレームワークは初めてという方にもおすすめの一冊となっています。

現段階ではamazon等で予約はできませんが、正式な発売日など決まりましたら、またお知らせ致します。

お楽しみに!

via: CakePHP のおいしい食べ方: 間もなくCake本登場!!

ホーム > book

検索
フィード
メタ情報

Return to page top