give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

祝!増刷 & Ruby版のRailsチュートリアルを目指していた「プロを目指す人のためのRuby入門」の裏話

お知らせ:第3刷の増刷が決定しました!

僕が執筆したRubyの入門書、「プロを目指す人のためのRuby入門」(通称チェリー本)の増刷が決定しました!
2回目の増刷なので、今回は第3刷となります。

・・・といっても本の執筆者と出版関係の人ぐらいしか、「増刷」なんていうキーワードには興味がないかもしれません。
(僕も本を出す前は興味がありませんでした💧)

増刷というのは簡単にいえば「本の在庫がなくなってきたので、まとまった単位で本を印刷し直して在庫を補充すること」です。
つまり、増刷がかかるということはそれだけ本が売れていることを意味します。
つまり、著者としては増刷の連絡がもらえるのは、とても嬉しいわけです!!😆

これもひとえに「プロを目指す人のためのRuby入門」を購入していただき、周りの方々にオススメしてくださったみなさんのおかげです。どうもありがとうございました!
そして、引き続き「プロを目指す人のためのRuby入門」をよろしくお願いします!

f:id:JunichiIto:20180817051330j:plain
MARUZEN&ジュンク堂書店 梅田店にて。直筆ポップを置いてもらってます!

制作裏話:切っても切れない?「Railsチュートリアル」と「プロを目指す人のためのRuby入門」の関係

ところで、Twitter等で「プロを目指す人のためのRuby入門」の反響を見ていると、Railsチュートリアルをやった後、またはRailsチュートリアルをやる前に「プロを目指す人のためのRuby入門」を読まれている方が多いようです。

そして、「Railsチュートリアル」と「プロを目指す人のためのRuby入門」の組み合わせは、RubyやRailsの勉強を進める上で、かなり学習効果の高い組み合わせになっているように思います。

Railsチュートリアルと一緒に「プロを目指す人のためのRuby入門」を読んでもらえるのは、個人的にとても嬉しいです。
それはなぜでしょうか?その理由を以下に書いていきます。

初期の原稿ではRailsチュートリアルのスタイルを踏襲していた

実は「プロを目指す人のためのRuby入門」は、もともと「Ruby版のRailsチュートリアル」を目指して執筆を開始しました。
一番最初に書いた原稿では、Railsチュートリアルを参考にして「例題のコードをチュートリアル形式で読者に書いてもらいながら、一緒に構文や文法を説明する」というスタイルを取っていました。

f:id:JunichiIto:20180817054949p:plain
一番最初に書いた原稿の一部。このときはコードを書きながら構文や文法を説明していました。

ただ、このスタイルだとなかなか例題の説明が進まなかったり、文法の説明と例題の説明が混在してわかりづらかったりする問題があったので、結局ボツになりました。
コードを書きながらRailsの説明を同時進行させても、読みやすさやわかりやすさが損なわれないRailsチュートリアルは偉大ですね!

僕自身もRailsチュートリアルのお世話になっていた

そもそも、なぜ僕が「Ruby版のRailsチュートリアル」を書こうとしたのかというと、その昔、僕自身がRailsチュートリアルのお世話になったからです。

僕もRailsを勉強し始めた頃はRailsチュートリアルを使っていました。
当時はまだ英語版しかなかったのですが、それでもチュートリアル形式でフレームワークの使い方を学ぶという体験が初めてで、すごく斬新でした。
Railsチュートリアルを使って勉強すると、勉強しながらWebアプリケーションができあがっていくので、「これはすごい!そして面白い!」と非常に感銘を受けました。

ただし、RailsチュートリアルはあくまでRailsがメインで、Rubyというプログラミング言語の説明は控えめです。
そこで、「Railsの習得はRailsチュートリアルにまかせて、僕はRubyを習得するためのRubyチュートリアルを書こう!」と思い、「プロを目指す人のためのRuby入門」の執筆に取りかかったのでした。

Railsチュートリアルと自分の書いた本がリンクするのは嬉しい

このように僕個人としては「Railsチュートリアルがあったからこそ、プロを目指す人のためのRuby入門が生まれた」と言っても過言ではないぐらい、(一方的に)縁やゆかりを感じています。

なので、Railsチュートリアルと一緒に「プロを目指す人のためのRuby入門」を読んでくれている読者さんを見かけると、とても嬉しくなります。

また、日本語版のRailsチュートリアルには「読み物ガイド」の項に「プロを目指す人のためのRuby入門」を載せてもらっています。
(ついでにいうと、僕が翻訳した「Everyday Rails - RSpecによるRailsテスト入門」も載っています!)

Railsチュートリアルにお世話になった人間としては、これも非常に嬉しい出来事でした。

f:id:JunichiIto:20180817062039p:plain

もちろん、「プロを目指す人のためのRuby入門」の参考文献にもRailsチュートリアルを掲載させてもらっています。

f:id:JunichiIto:20180817064818p:plain

まとめ

というわけで、今回のエントリでは「プロを目指す人のためのRuby入門」の増刷のお知らせと、Railsチュートリアルに関連した制作裏話を書いてみました。

そういえば、去年の今頃は自宅に届いた「プロを目指す人のためのRuby入門」のゲラ(試し刷り)をチェックして、原稿を校正している真っ最中でした。

f:id:JunichiIto:20180817065516j:plain
去年の夏はゲラを読みながら校正作業をしていました

当時はまだ本当に出版されるのかどうかすら半信半疑な状態だったので、自分の本がどれくらい読んでもらえるかなんて全く予想が付きませんでした。
ですが、実際に出版してみると、予想をはるかに上回る好評価をいただき、売れ行きも好調で筆者として非常に嬉しい限りです。

欲張りかもしれませんが、もっとたくさんの人に読んでもらいたいので、まだ購入されていない方はぜひ書店で手に取ってみてください!

また、本の感想も随時募集中です。
ご自身のブログやAmazonレビュー等で書評を書いてもらえると大変ありがたいです。

みなさん、「プロを目指す人のためのRuby入門」を今後ともよろしくお願いします!😄

お客様から「日本にサマータイムを導入したいんだけど」と言われたらプログラマとしてどうすべきか?

はじめに

東京オリンピックを2年後に控え、日本のIT業界に突然降って湧いた「日本でもサマータイムを導入するかも?」という問題。
この話、数日経てば「そんなのうそぴょーん」とか「すいません、前言撤回します」みたいなオチで終わるだろうと思ってたのですが、このブログを書いている時点ではそういう気配はなく、むしろ前向きに検討しているような雰囲気で「おいおいおい!」と思っております。

こんな「ピカーン💡いいこと思いついちゃった!」的なノリで突然サマータイムを導入するのが、技術的にどんなに無茶な話なのかは、他の専門家のみなさんが論じてくれているのでここでは書きません。
そのかわりに、もしこんな話が僕が勤めている株式会社ソニックガーデンの「納品のない受託開発」で巻き起こったら僕はどんな対応をするか、という思考実験をしてみようと思います。

f:id:JunichiIto:20180814103545j:plain

前提知識:「納品のない受託開発」の開発スタイルについて

「納品のない受託開発」ではその名の通り、お客様の要望に応じて専用のシステムを開発する「受託開発」でありながら、システムを全部最後まで作ってお客様にお渡しする「納品」がありません。

「納品のない受託開発」の特徴を簡単にまとめると以下のようになります。

  • プログラマとお客様が毎週定例のミーティングを開き(通常はビデオ会議)、その週に開発するシステムの仕様を決める
  • プログラマは次回のミーティングまでに、お客様に成果が見えるプログラムを実装する
  • 翌週のミーティングで開発したプログラムをお客様とレビューする。そして、また次の週に開発するタスク決める
  • レビューが済んだプログラムは随時本番環境にリリースされる
  • ソニックガーデンは毎月定額の開発費をお客様からいただく
  • プログラマは毎週、一定量のタスクを実装する。納期についてはあくまで「ベストエフォート」でしか約束できないので、「xx月xx日までのリリースを死守してほしい」というようなご要望には原則として応じない

上の流れを見てもらえばわかるとおり、「納品のない受託開発」ではプログラマが直接お客様と対話し、話をした本人がプログラムを書きます。
SEとプログラマが分かれていたり、間に別の会社が入ったりすることはありません。

「納品のない受託開発」の詳細についてはソニックガーデンのホームページ、もしくは弊社代表の倉貫が書いた以下の著書をご覧ください。

「納品」をなくせばうまくいく

「納品」をなくせばうまくいく

もしお客様から「日本にサマータイムを導入したいんだけど」と言われたら

さて、ここからが本題です。
現実にはあり得ませんが、もしお客様から「日本にサマータイムを導入したいんだけど」と言われたら、僕はどう返事をすればいいでしょうか?

「それは無理です。絶対にできません」?
「仕様を教えてください。それから見積もりいたします」?
「サマータイムを導入するのがどんなに大変なことか、ちょっと説明させてください」?

いいえ、どれも違います。
最初に返す言葉は、

「なぜサマータイムを導入する必要があるんですか?その理由や背景を教えてください」

です。
「やりましょう」でも「無理です」でもなく、「そもそもなぜサマータイムの導入が必要なのか」を確認します。

報道などで伝え聞くところでは、「マラソンの開始時刻を2時間早めたいから」という理由があるようですが、もしお客様がそのように回答してきたら、「では、そのまま素直に開始時刻を2時間早めればいいんじゃないでしょうか」と提案します。
そこから「いいえ、それは無理なんです。なぜなら・・・」と、お客様から納得のいく理由が返ってくれば議論をさらに進めることができます。
ですが、そうでなければ「サマータイムの導入」というタスクは永遠に実行に移されません。

受託開発と言えど、ソニックガーデンのプログラマはお客様の要望を全部そのまま受け入れるわけではないのです。

「IT投資に対するソフトウェアの価値を最⼤化すること」というビジョンと、「判断に理解と納得を持ち思考停止しないこと」という価値観

ソニックガーデンのビジョンの一つに「IT投資に対するソフトウェアの価値を最⼤化すること」があります。

IT投資に対するソフトウェアの価値を最⼤化すること
SonicGardenはソフトウェアの可能性を信じています。物理的な制約を受けることのないソフトウェアは、ユーザや企業が必要とする要求に対し、最も効率よく価値を提供することができるはずです。しかし、今のソフトウェア開発には無駄が多く、投資に対する価値が提供しきれていないように思います。私たちは、業界にはびこる無駄を見直し、IT投資に対するソフトウェアの価値を最大化することを目指します。

https://www.sonicgarden.jp/company

さらに「判断に理解と納得を持ち思考停止しないこと」という価値観もあります。

「判断に理解と納得を持ち思考停止しないこと」
SonicGardenでは、言われた通りに仕事をするということを嫌います。お客様からの要望による機能を実装するにも、自社サービスの機能を設計するにも「本当に必要なのか?」という観点から考えて納得をした上で取り組むようにします。

https://www.sonicgarden.jp/company

これらを組み合わせると、プログラマは「サマータイムを導入することは本当に必要なのか?サマータイムを導入する以外に、お客様の問題を解決できる、もっとスマートで低コストな解決策はないか」ということを考えます。
その解決策を検討するために、「本当に困っていることは何か」「本質的な問題はどこにあるのか」ということを、ミーティングの中でお客様と議論しながら深掘りします。

議論の末に出てくる結論

議論ではお客様とプログラマの双方が心の底から納得がいく結論を出す必要があります。
先ほど述べたとおり、「お客様が本当に困っていること」を探り出すのも重要ですし、我々プログラマもお客様に対して「もしサマータイムを導入しようとしたら、どれくらい大変なのか、実際にどれくらいの工数がかかるのか」を説明し、お客様にその大変さやサマータイム導入によるメリット・デメリットを理解してもらわなくてはなりません。

このようにお客様とプログラマが、お客様のビジネスを成功させるために本音で意見をぶつけ合い、最終的な結論を導き出します。
「サマータイムを導入するか否か」というテーマであれば、大きく分けて「導入しない」もしくは「導入する」という2種類の結論が出てくると思います。

「サマータイムを導入しない」という結論の場合

お客様が「本当に困っていること」を理解し、それを解決するもっと良い方法が「サマータイムの導入」以外にもあるなら、我々プログラマはその方法を提案し、お客様に納得してもらいます。
場合によっては「全くコードを書かない(つまり、何もしない)のがベスト」という結論に至ることもあります。

普通の受託開発では「コードを書かない=儲からない」ということになりますが、「納品のない受託開発」は毎月定額で料金をいただくことになっているので関係ありません。
むしろ、「サマータイムを導入しない代わりに、お客様にとって、もっと価値の高い別のタスクに取り組む」という、お客様とプログラマの双方にとって有意義な選択肢を採ることができます。

「サマータイムを導入する」という結論の場合

一方、議論の結果「なるほど、そんな事情があるのなら、サマータイムを導入することもやむを得ない。いや、むしろサマータイムを導入することには十分な理由と価値がある!」という結論に至る可能性もゼロではありません。

しかし、その場合でもソニックガーデンでは「毎週、一定量の成果を出す」というルールを変えることはありません(つまり、プログラマは体を壊すようなハードワークをしません)。

なので、あまりにも無茶な内容だと、「見積もりした結果、お客様が希望する納期に間に合わない」という問題が発生します。
その場合は「無駄な要件を可能な限りそぎ落とし、本質的な問題を解決できる要件だけを残して、納期に間に合うように努力する」という選択肢を採ります。

とはいえ、「日本にサマータイムを導入する」というレベルになると、何を削ったら納期に間に合うようなボリュームに落とし込めるのかイメージが沸きませんが・・・。
ですが、実際の「納品のない受託開発」では「要件のスコープ」を調整することで、お客様の希望する納期に間に合わせることがよくあります。

まとめ:で、結局「サマータイムを導入して本当に解決したい問題」は何?

というわけで、このエントリでは「納品のない受託開発」でお客様から「日本にサマータイムを導入したいんだけど」と言われたらプログラマとしてどうするか?という思考実験をしてみました。
実際に「日本にサマータイムを導入したい」なんていう話をし始めるお客様はいませんが、そこまでいかなくても「それ、本当にやろうとしたら大変な工数になりますよ」というようなご要望をいただくことはよくあります。
そういう場合は上に述べたような議論を通して、我々プログラマはお客様にとって最も費用対効果の高い形にタスクを落とし込むようにしています。

ところで最初の話に戻りますが、僕らは普段こんなふうに仕事をしているので、「マラソンの開始時刻を2時間早めたい。だから日本にサマータイムを導入したい」という話がいまいちピンと来ないんですよね。
僕はどう考えても「マラソンの開始時刻を早めたい」なんていうのは表面的な理由で、「本当は何かもっと本質的な理由や目的が背後に隠れているはず」と思ってしまいます。
ですが、報道ではそのあたりの情報がハッキリ明示されないので、サマータイム導入に関する昨今の議論を見てても非常にモヤモヤしてしまいます(「そもそも」の話がしたいのに、それができなくてモヤモヤする)。

少なくとも僕個人としては「うーん、今見えている理由だけだと、ちょっとサマータイムを導入するのは無理(=プログラマとして受け入れられない)ですね」というのが、現時点での答えになると思います。

あわせて読みたい

このサマータイム導入問題は、以前読んだ「失敗の本質」にどこか通じる話があるんじゃないか、という気もしています。
結局、戦争が終わってから70年経った今でも「声の大きい人の意見が通る」とか「非合理的な精神主義で、現場が無茶を強いられる」といった行動パターンから抜け出せないのだとしたら、非常に残念です。

購入して1ヶ月も経たないうちにGoogle Homeを手放した

はじめに

妻に誕生日のプレゼントとしてGoogle Homeを買ってもらったんですが、1ヶ月も経たないうちに僕を含めて家族全員が飽きてしまい、全然使わなくなったので、手放すことにしました。

この記事ではGoogle Homeに期待していたことと、そのギャップについてあれこれ書いてみます。

f:id:JunichiIto:20180806083905j:plain

Google Homeに期待していたこと

僕が「へー、Google Homeって面白そう」と興味を持ったのは、この記事を読んだのがきっかけです。

この記事にはまるでSF映画のような、おばあさんとGoogle Homeの交流が描かれています。
この記事を読んで、僕は「Google Homeってこんなにハートフルな会話ができるの!?」と思ってしまいました。

また、僕も妻も音楽好きで普段からよく音楽を聴くので、Google HomeがSpotifyや手持ちのBluetoothスピーカーと連携できる「賢いミュージックプレイヤー」として活躍してくれることも期待していました。

実際に使ってみてどうだったか

雑にまとめると「結局Siriと同じやん」という感じです。
Siriを頻繁に使う人なら、Google Homeも便利なんじゃないかと思います。
僕はSiri、すなわち音声アシスタントをあまり使わないので、結局Google Homeもすぐに使わなくなりました。

いうほど賢くない(Siriと同じレベル)

まず、前述の記事のようなハートフルな会話ができるのかというと、全然そんなことはありませんでした。
何か尋ねたり話しかけたりしても、半分以上の確率で「すみません、よくわかりません」「お役に立てそうにありません」という返事が返ってきます。
会話のキャッチボールどころか、スタートラインにも立てません。

「ねえGoogle、何か面白い話をして」みたいなことを話しかけると、小咄(こばなし)的なギャグを言ってきたりしますが、こんな機能は1日で飽きます。

子どもたちも買ったその日は「ねえ、Google!」と何度も話しかけて反応を楽しんでいましたが、翌日にはすっかり飽きていました。

また、質問に返答したとしても、かなりの確率でとんちんかんな返事を返すところもSiriと同じです。
「おいおい、そんなことは聞いてないって!」と家族全員でツッコむのも面白いと言えば面白いのですが、実用性はゼロなので、結局「もうええわ、スマホで調べよ!」となります。

ディスプレイ=視覚情報がない辛さ

確かに天気予報やニュースを尋ねたりすると情報を返してくるのですが、耳でしか情報をキャッチできない、というのは結構しんどいです。
Google Homeが話し始めたら最初から最後まで注意深く耳を傾ける必要があります。
回答が長くなると前半の内容を忘れかけることもありますし、途中で聞き取りづらいところがあったりすると、「もう一回言って」となることもあります。
ディスプレイがあれば目で見て回答が確認できるので、何度でも情報を行き来できますが、スマートスピーカーではそれができません。

ブラウジングしながら今の気分に合う音楽を選択できない辛さ

また、ミュージックプレイヤーとしても同じようなことが言えます。
Google Homeを使って初めて意識したのですが、音楽を聴くときって結構「ブラウジング」が重要になるんですよね。
つまり、音楽を聴くときのフローって、

何か音楽でも聴こうかな
 ↓
iTunesやSpotifyを開く
 ↓
アーティスト一覧やアルバム一覧を眺める(←これがブラウジング)
 ↓
よし、Steely Danを聴こう

となることが多いわけです。

f:id:JunichiIto:20180806081017p:plain
僕がSpotifyに登録しているお気に入りアーティストの一覧

ブラウジングなしで音楽を聴こうとすると、どのアーティストのどの曲を聴きたいか、頭の中でブラウジングしなければなりません。
これは想像以上に辛い、というか、画面を見ながらやる方が100倍ラクです。

「ねえGoogle、何か音楽かけて」とか「ねえGoogle、Steely Danかけて」みたいなざっくりしたリクエストをすることもできますが、微妙に今の気分にマッチしない曲を掛けてきたりするので、「うーん、なんか違う」となってしまいます。

あと、Spotify連携やBluetoothスピーカー連携がときどきうまくいかなかったりする点もストレスが溜まりました(BGMとしてかける音楽はすぐにスタートさせたいので)。

2番目以降の検索結果を確認できない辛さ

音楽以外の用途についても同じことが言えます。
「ねえGoogle、xxxについて教えて」みたいに質問しても、Google Homeは検索のトップに上がってくる情報しか話してくれません。
スマホやPCで検索すればチェックできたであろう、2番目以降の検索結果が確認できなくて少しもどかしい気持ちになるところも、やはりディスプレイが存在しないことのデメリットだと思います。

家電連携するには家電の買い換えや買い足しが必要

Google Homeをはじめ、各種スマートスピーカーでは「音声で部屋の電気を付けたり、テレビの操作をしたりできる」と宣伝されることがありますが、これには当然、それに対応した家電やアイテムを取りそろえる必要があります。
買い換えや買い足しにかかる手間や出費は馬鹿にならないですし、もし仮に音声で操作できるようになったとしても結局「最初から手でスイッチやリモコンを操作すればええやん」というオチが待っている可能性が高いです。

「音声で家電を操作できる」というのは、別にゼロからイチが生まれるような画期的な価値ではありません。
スイッチやリモコンによる操作に特別大きな不満を持っていないのであれば、「選択肢がちょっと増えた」ぐらいの価値しかないと思います。

というわけで、僕は実際に音声で電気やテレビを操作したわけではありませんが、これもまた人生を劇的に変えるほどのインパクトはないだろうなあ、と予想しています。

まとめ:なんだかんだで現時点ではスマホが一番便利

というわけで、今回はGoogle Homeが期待したほどの働きをしてくれなくてすぐに手放した、という話を書きました。

自分の意図を確実にコンピュータに伝えるには、文字入力や指を使った物理的な操作が一番安定していますし、コンピュータとのやりとり(インタラクション)についてもまだまだディスプレイ、すなわち視覚情報が必要なんだなあ、というのがGoogle Homeを使ってみて僕が学んだことです。

結局、この両方を兼ね備えているのは、現時点ではスマホかパソコンということになります。
そして、日常生活において、ふと思ったときに、いつでもどこでもさっと使えるという点ではスマホが一番便利だと思います。

もっと画期的なデバイスが登場するまで、僕はしばらくスマホとパソコンでいいや、と思いました。
ごめんね、Google Homeちゃん。

最後に娘が「ねえGoogle、さようなら」と声を掛けたら、「残念です。またどこかでお会いしましょう」と返事を返してきました。
そして僕はGoogle Homeの電源ボタンを長押しして、本体の初期化をしましたとさ。

おしまい。

余談

最近は液晶画面付きのスマートスピーカーも出てきましたね。
ディスプレイがなくて困る問題は多少解消されるとは思いますが、Google Homeを使った感想から言うと、これもなんだかんだで「スマホでええやん」という結論になりそうな気がします。。。