■JavaScriptを堅牢に扱いやすくするための本

　JavaScript関連の本を読むときに気を付けなければならないこと。「この本は、どの立ち位置なのか？」「何が言いたいのか？」を知ること。

　これらをきちんと理解して読まないと、とんでもない回り道をするはめになる。サーバサイドからクライアントサイドまで、JavaScriptがカバーする範囲は幅広いからだ。

　さて、本書の立ち位置はというと、カルーセルやアコーディオンのような、見た目を変化させるjQueryプラグインの紹介は一切ない。ユーザーインターフェイスを求めている人向けの本ではない。

　サブタイトルには「MVCアーキテクチャに基づくWebアプリケーションの状態管理」とある。ぼんやりとでも、この意味が分からなければ、読み解くことは難しい。ここでもあえてMVCの説明はしない。MVCの話が出るということは、「フレームワークの解説か」と思いきや、それも違った。もう少し細かいパーツの世界、フレームワークを構成する部品についての話である。

　つまり、JavaScriptを堅牢に扱いやすくするための本だと思えばいい。本書は、「フレームワーク」という大きな世界観を構成する小さな部品について書かれている。これは、JavaScriptで世界を築くための道しるべとなる。

■目次

• 1章　 MVCとクラス
• 2章　イベントと監視
• 3章　モデルとデータ
• 4章　コントローラと内部状態
• 5章　ビューとテンプレート
• 6章　依存性の管理
• 7章　ファイルの操作
• 8章　リアルタイム Web
• 9章　テストとデバッグ
• 10章　アプリケーションのデプロイ
• 11章　 Spineライブラリ
• 12章　 Backboneライブラリ
• 13章　 JavaScriptMVCライブラリ

　前半はパーツ寄り、後半はライブラリの紹介だ。このコラムでは前半部分、その中でもアーキテクチャよりのトピックを拾いながら考察を深めよう。

■Class is difficult to use

　アーキテクチャ寄りの話では、関数型言語的側面からJavaScriptを攻略するのが最近の流行である。しかし、本書では、JavaScriptをオブジェクト指向言語として扱う。不易流行。

　まずは、クラスの考察から本書は始まる。

　JavaScriptはプロトタイプに基づく言語であり、それゆえにネイティブなクラスの実装というものは存在しません。しかしクラスの性質をエミュレートするのは容易です。

　JavaScriptでクラスを扱うのは難しい。オブジェクト指向言語では当たり前にある、クラスにアクセス制限を与えることでさえ、容易ではない。アクセス制限は、匿名関数の空間を閉じ込めることで、プライベート変数やプライベートメソッドを実現する。カプセル化を実現するためだけでも、知っておくべきことは多い。

　本書のサンプルから、もう少しかんたんな例を見よう。

var Person = function(name){
    this.name = name;
}

var alice = new Person('alice');
var bob = Person('bob'); // undefined!!

　JavaScriptは、細心の注意をもって記述する。こんなシンプルなコードが new演算子1つで変わる。new をつけない Person('bob') を実行するとどうなるだろう？ 変数 bobが undefinedになるだけではすまされない。恐るべきことに、このコードはnameというグローバル変数を生み出してしまう。

　なぜか？

　new演算子は、コンテキストであるthisをインスタンス固有のオブジェクトに設定する。しかし、new演算子がなければ、単なる関数呼び出しでしかない。 関数呼び出し時のthis は windowオブジェクトを指す。つまり this.name は window.nameとなり変数nameはグローバル変数となる。それが邪悪な行為であることは言うまでもない。

■Event is easy to use

　JavaScriptのイベントと聞いて、何を思い浮かべるだろうか？ まっ先に思い浮かぶのは、マウスのクリックや、入力エリアの値が変更されたときに連動した動きなどだろう。そういったユーザー操作のイベントは別の本に任せておこう。

　JavaScriptでは、プログラマが任意のタイミングで好きなイベントを発生できる。そして、そのイベントを自在に受け取れる。この仕組みがJavaScriptを輝かせる。イベント駆動のプログラムがかんたんに組めるメリットは、先ほどのクラスを作るためのデメリットを相殺する。

　イベントベースのプログラミングは、アプリケーションのアーキテクチャを疎結合化できるという点で非常に強力です。

　パブリッシュ／サブスクライブと呼ばれるメッセージ交換パターンは、プログラム間の依存性を低め、オブジェクトの独立性を高める。イベントというトリガーを自分自身のなかに持つことができるからだ。イベントベースのオブジェクトは他者から直接、呼び出されることなく状態が変化する。そのメリットが理解できなければ本書を読むのはまだ早い。

　かつてのMVCパターンはページが軸であった。1つのリクエストは、1つのページを表示することが当たり前の世界であった。StrutsなどのMVCアーキテクチャはページ単位を基本とする。せいぜいフレームやパネルという単位で疎結合であれば十分であった。

　Ajaxは世界を変えた。Ajax全開のアプリケーションでは、時としてDOM要素の1つ1つが、MVCの最小粒度になる。コンポーネントですら依存関係を持つことは許されない。Wicketやclickのようなコンポーネントベースのフレームワークの出現がそれを物語る。もはやMVCはページ単位ではない。主役の座はコンポーネントである。

　あるボタンを押すことや、ちょっとしたマウス操作をきっかけに、何かが変わる。そんな要件を満たすためにパブリッシュ／サブスクライブパターンがかんたんにできる言語は強力な武器となる。複雑な動作をするコードは「なんか、よう分からんけど、動いたからいいか」ではダメだ。

　本来、疎結合なプログラム、堅牢なプログラムは言語に依存しない。この本にはMVCアーキテクチャを実現するために考えるべき要素がたくさん詰まっている。特定の言語を抜きにして触れるのも面白い。

■How to build software

　JavaScript本を読むと、小さなテクニックの断片が目立つ。油断すると、ブラウザごとの差異やちょっとしたTipsをたくさん知ることがJavaScriptを勉強することだと勘違いする。そして、それをどれだけ知っているかが優秀なJavaScripterであるかのような錯覚をする。

　プログラム言語を学ぶとは、そんなことではない。「べからず集」を覚えることがプログラムではない。

　ロジックをいかに組むか――オブジェクト指向だけでなく関数型言語やファーストクラスオブジェクトを理解するとがJavaScriptの真の学習であるはずだ。本書が、プログラムとは何かを考えるきっかけの1つになればと思う。

■なぜRubyistに惹かれたのか

　Rubyへの心変わりは誰の影響だっただろうか。

　業務と関係なければ、勉強しなくていいと思っていたはずだった。アジャイル系コミュニティに参加したしばらくあと、地域Rubyコミュニティに迷い込み、いつしか彼らと楽しくお酒を飲むようになっていた。

　アジャイル系コミュニティの人々が仕事について・技術について話している姿は楽しそうだった。

　彼らはRubyistでもあった。彼らの姿に惹かれ、僕もRubyを学び始めた。

　そうして門を叩いた地域Rubyコミュニティの人々も、アジャイル系コミュニティと同様に、技術について話している姿は輝いていた。

　そして、他の言語コミュニティとは、暖かさが違っていた。その暖かさに触れ、僕も彼らの仲間になりたいと思うようになった。

　なぜ僕は彼らに惹かれたのか。本書の中にその答えはあった。

■Ruby入門書というよりは、Rubyist入門書

　本書は、それまでのRuby入門書、いや、言語全般の入門書とは趣が異なっているRuby入門書というよりも、「Rubyist入門書」といった方が正しいだろう。

　本書の構成は次のように成り立っている。

• Chapter1 「たのしい開発」を求めて
• Chapter2　Rubyの基礎知識
• Chapter3　Rubyを使ってみよう
• Chapter4　Ruby on Railsとは
• Chapter5　Railsを触ってみよう
• Chapter6　Rubyの文化
• Chapter7　自動化されたテスト
• Chapter8　アジャイル開発とRuby
• Chapter9　Rubyのコミュニティ
• Chapter10　とある企業のRuby導入事例
• Chapter11　「たのしい開発」の答え

　言語仕様についてではなく、Ruby on Railsや自動テスト、アジャイル開発やコミュニティについてなど、Rubyを取り巻く世界全体について書かれている。そしてRubyの文化は、これらの要素が合わさることでできている。

■Rubyの自由さ

　そもそもRuby自体が、自由度の高い言語である。Rubyは自分のやりたいことを直感的に表現できる言語であると、著者らは述べている。

　さらに、Ruby on Railsが進化の速いフレームワークであり、アプリケーションの自動テストを作っておかなければ、バージョンを上げることもままならないと述べている。そうした背景があり、RubyやRailsによるアプリケーション開発では、自動テストを作ることが当たり前となった。

　つまり、Railsを取り巻く世界では、自動テストの文化も発展していく。RSpecやCucumberなどはその典型であろう。その思想はいまや他の言語にも伝わりつつある。

　また、そうした自動テストツールにアプリケーションが支えられることで、要件が変わったりすることにも柔軟に対応できるようになった。

　結果として、Railsが

　プロセスやツールよりも、人と人の対話を
　包括的なドキュメントよりも、動くソフトウェアを
　契約交渉よりも、顧客との協調を
　計画に従うことよりも、変化への対応を

という、アジャイルマニフェストに従うことが容易になり、Rubyの自由さをより体現している。

■Rubyが楽しい理由

　このようなRubyの自由さ、プログラマを大切にする価値観の構成要素はこうして生まれていく。

　その結果、新しい技術に挑戦するプログラマにとっても、世界を変えようとするベンチャー企業にとっても、お客様に対する価値を最大化したいと願う受託開発プログラマにとっても、Rubyの開発そのものが楽しくなっていったのだろう。

　さらに、そうした開発を楽しむ人々がコミュニティに集って情報交換をしたり一緒に学んだりするのだ。コミュニティが楽しいに決まっている。企業もコミュニティを支援することで、その企業には優秀なエンジニアも集まってくるようになる。すると、その企業も盛り上がっていく。

　この流れはこれからも続いていくのだろう。だから著者たちは本書のカバーでこう宣言しているのだろう。「これからRubyはもっと楽しくなる」と。

■楽しい開発を目指そう

　では、どうすれば楽しい開発への一歩を踏み出せるのだろうか？

　著者らはこう述べている。

　やりたいこと、やりたくないこと、自分がどうしたいのか、どうしたらうれしいのか。それらに素直に目を向け、受け入れることが「楽しい開発」につながります。

　まずは著者らの言うとおり、そうした自分の想いを見つめ受け入れる。その上でRubyを学びたいとなれば、本書を皮切りにRubyについて1つずつ学んでいけばよいのではないだろうか。

　残念ながら、本書だけでRubyを使ったアプリケーションを作れるようにはならない。それは、本書であまりに広範な話題を扱った結果であり、文化を伝えるためには必要なことだったのだと思う。その代わり、本書の巻末で著者らはRubyを学ぶ道筋を示している。その道をたどっていけばよい。

　楽しい開発を目指そう。

■このコード、なんだかにおうよ

　「コードのにおい（code smell）」という言葉がある。なんとなくこのコードは良くないぞ、バグを含んでいるか、あるいは将来にバグを引き起こしそうだぞ、という兆候のことだ。

　未熟、怠慢、無知などの理由によって生まれた駄目コードからは、往々にしてこの「コードのにおい」が漂ってくる。多くの責務を抱え込んだクラス、巨大で分岐の多い関数、繰り返し現れる同じ処理（それぞれちょっとだけ違ったりすると最悪）。しかし、書いた本人はたいてい「自分のコードが臭い」などとは、夢にも思わずに書いている。何が臭くて、その結果どのような良くないことが起きるかを学ぶ機会がなかったからだ。

　一方、良いコードはびっくりするほどシンプルなことが多い。変数やメソッドには分かりやすい名前がつき、処理の流れは見通しよく整理されていて、重複部分はすっきりと分割して再利用されている。

　同じ「コード」だというのに、この違いは何だろう？ プログラマに「コードのにおいを嗅ぎ取る能力」があるかどうかだ。よいプログラマであろうとするならば「自分の書いたコードが臭い」なんてことには耐えられないはずだ。しかし、「何が臭いのか」を知らなければ、臭くないコードを書くこともできないだろう。

■においの見張り番

　本書「リーダブルコード」は、そんな「におうコード」のサンプルをたくさん収録している。

　コードのにおいを嗅ぎ取る能力があるプログラマにとっては、思わず鼻をつまみたくなるようなサンプルコードを載せ、それがなぜいけないか、そのコードのどこがにおうかを丁寧に解説し、そして「におわないコード」になるようにリファクタリングするまでの流れを、においの種類別に何度も見せてくれる。

　簡単な例を引用してみよう。

if/else 文のブロックは、並び順を自由に変えることができる。例えば、以下のように書くのと、

if (a == b) {
    // 第1のケース 
} else {
    // 第2のケース 
}

以下のように書くのは同じことだ。

if (a != b) {
    // 第2のケース 
} else {
    // 第1のケース 
}

　これまであまり深く考えなかったかもしれないけど、この並び順には優劣がある。

p.86 7.2「if/else ブロックの並び順」より

 

　「えっ、何か違うの？？」

　そう思った人は、ぜひ本書を手に取って「なぜ優劣があるか」を学んでほしい。

　ちなみにこのページには、このコードがどう「におう」のかをユーモラスにあらわしたイラストがついている。このイラストは、普段から「におわない」コードを書いているプログラマにとっては、本文を読む前にニヤッと笑えることだろう。そうでないあなたも、ぜひ本文を読んでこのサンプルコードの「におい」を嗅ぎ取れるようになり、そしてこのイラストで笑えるようになってほしい。

■においがつかない無臭コードだ！

　本書の帯には「周囲の皆が喜んで使ってくれるような、リーダブルなコードを書く方法を楽しく解説！」とある。

　現実のあれこれと同様、「臭い」コードを「みんなが喜んで使ってくれる」とはとても思えない。チームで開発していたり、コードを公開したりしているプログラマの皆さんは、ぜひ本書を読んで、「臭くない」コードを書く技術を身に付けてほしい。

　そしてすでに「臭くない」コードを書けるプログラマのみなさんも、やっぱり本書を読んで「うんうんあるある」とうなづくだけの簡単なお仕事をしてみてほしい。

　もしかしたら、意外と知らなかったり忘れてたりしたことを発見するかもしれないし、そうでなくても、たくさんのユーモラスなイラストを眺めるだけでも楽しい時間が過ごせる。先ほど引用したp.86では「自分のペット紹介」で笑えるし、p.16「超硬い金属のクギを打ちつける棒状のもの」、p.174「あれでいいかもね」などが特に気に入っている。

■においは元から絶て

　世の中から臭いコードを減らすことは、回り回って皆さんの、そして私の仕事を楽しく快適にすることに直結する。本書がきっかけで「臭いコード撲滅運動」が盛り上がり、どんどん「臭いコード」と「臭いコードを書くプログラマ」を駆逐していくのが、今から楽しみである。

（『Wife Hacks ～仕事と家族とコミュニティと～』
コラムニスト　kwappa）

■自作アプリの経験はありますか？

　スマホ業界の勢いはますます加速している。この流れに乗って、スマホ業界への転職を考えているエンジニアもいることだろう。そして、スマホ開発企業は、「業務か自作での、アプリ開発経験」を採用基準とするところが多い。

　Titanium MobileやPhoneGapといった、ネイティブコードを触らずともクロスプラットフォームでアプリ開発できるプロダクトも登場している。私自身、Titanium Mobileを使ってiOSアプリをリリースしたことがある。

　しかし、今のところ仕事としてスマホアプリ開発に携わるなら、大半の現場ではiOSならObjective-C、AndroidならJavaで書くことを求められる、と感じている。

　本書は、スマホ業界に挑もうとする人にとっての先導役といえるだろう。

■書上のハンズオンセミナー

　著者 新居雅行氏は、iOSアプリ開発の講師業もしている。そのためか、実際に本書の内容を試すと、まるで著者のハンズオンセミナーを受けているような感覚でアプリ開発を体験できた。

　iOSでの各種オブジェクトの使い方とそのサンプルコードが載っているような本とは明らかに一線を画しており、実践的な開発を学べる本である。

　本書で扱う内容は次のとおり。

• Chapter1 iOSアプリケーション開発者を目指そう
• Chapter2 iOSアプリケーション開発の流れ
• Chapter3 画像ファイルを表示するビューアを作ろう
• Chapter4 スクロールする画像ビューアを作ろう
• Chapter5 クラウド住所録を作ろう（ネットワークアクセス編）
• Chapter6 クラウド住所録のインタフェースを作ろう（iPhone編）
• Chapter7 クラウド住所録のインタフェースを作ろう（iPad編）
• Chapter8 電子ブックビューアを作ろう
• Chapter9 カメラと画像の顔検出機能を利用する

■実践的なアプリ開発トレーニング

　私にとって、一番の読みどころは、Chapter 5～7の「クラウド住所録を作ろう」だった。

　この章では、Amazon Web ServiceのSimple DBを使って、住所録アプリ開発を行うのだが、その中でネットワークアクセスやSAXによるXMLパースについて取り上げている。ここで取り上げている内容が、Web APIを使ったアプリを作る際に大いに役立つのではないかと思う。

　実際はオープンソースのDOMパーサライブラリやiOS5から標準で使えるようになったJSONパーサを使うことになるかもしれない。それでも、この章の内容を理解していれば、さほど苦しまずに開発していけるのではないか。

　また、本書ではiOS5から利用できるようになった「ストーリーボード」というGUIデザイナを用いた開発も紹介されている。iOSにおけるモダンな開発手法を学びたい人にとっても、参考となる1冊だろう。

■スマホ業界に挑む、最初の一歩

　一方、本書で取り上げていないことも数多くある。例えば、ローカルデータベース（SQLite）の扱い方やユニットテストの扱い方、バージョン管理（Git）の扱い方などだ。これらについて学ぶ場合は、別の書籍やWeb上の情報を参考にする必要がある。

　とはいうものの、これからiOSアプリ開発を学ぼうというエンジニア向けの書籍としては、初めからこれ以上の量を扱うのは苦しいとは思った。上記のような技術は、Objective-Cでの開発にある程度慣れてからでないと理解が難しいかもしれないからだ（私自身、かつてローカルデータベースを扱うあたりでObjective-Cの学習に挫折したことがある）。

　本書は、これからスマホアプリ開発を学びたい、もしくはそれを仕事にしたいと考えるエンジニアにとってよい助けになることだろう。

■現在進行形で、ソーシャルゲームを支えている技術

　本書は、1日35億PVの巨大システムを支える技術とノウハウについて、これでもかというほど贅沢に書いた書籍である（もっとも、1日35億PVをさばくノウハウが必要なエンジニアはそれほど多くはないだろうが……）。

　わたし自身、今年にWeb企業へ転職し、現在はソーシャルゲームの開発に携わっているので、大変面白く読めた。

　フィーチャーフォン向けのWebアプリケーションの開発ノウハウなど、スマートフォン全盛のこの時代にはそぐわない内容のように思える章もいくつかある。しかし、ソーシャルゲームでは依然としてフィーチャーフォンのユーザーが多く、こういったノウハウは今、まさに現在進行形でソーシャルゲームを支えている技術である。そういった意味で本書は、現実に即した内容であるといえるだろう。

　実際、本書に書かれているノウハウのいくつかは、わたしがソーシャルゲームの開発において直面した問題であった。

■目次

　本書は、4つのパートで構成されている。

• Part1　ソーシャルゲーム開発技術
• Part2　ソーシャルゲーム運用技術
• Part3　ソーシャルゲーム開発効率技術
• Part4　ソーシャルゲーム分析技術

　ご覧のとおり、かなり幅広い内容を扱っている。一方、構成が分かりづらい個所もあった。例えば、RESTfulなAPIの設計についての説明は、なぜか「MySQLとの付き合い方」の章に入っている。

■肝はデータマイニング

　ソーシャルゲームの運用にとって、サーバ運用や開発ノウハウも重要なのだが、実際にビジネスとしてのソーシャルゲームの命運を握っているのは、データマイニング技術である。

　ソーシャルゲームは日々、ユーザーの動向などの膨大なデータを分析し、UIやパラメータなどについて、1日単位で細かいチューニングを行う。

　そういった観点から、Part4「ソーシャルゲーム分析技術」は興味深く読んだ。

　Part4は、データマイニングついて、いくつかの技術が紹介している。ただ、データマイニングは、技術もそうだが、「データをどうとらえるか」という判断が最も重要なので、DeNAがどういう観点でデータを分析しているのか、という話題があれば、もっと良かったと思う。

■まとめ：ソシャゲ、Web業界に興味のあるエンジニア向け

　ソーシャルゲームやディー・エヌ・エーが提供するプラットフォームに関わる人でない限り、技術書として本書を使いこなせるエンジニアはそれほど多くはないだろう。

　ただ、話題の業界に所属する人が、その知見をふんだんに詰め込んだ本なので、ソーシャルゲームに興味のある人や、Web業界を指向するエンジニアにとっては面白く読める本であると思う。

　昨今なにかと話題になることの多いソーシャルゲーム界隈。中の人も、そうでない人も、本書を読めばその一端を垣間見ることができると思う。

■中身が素晴らしいので、外見をdisる

　最初に言っておこう。本書は、PHPでWebアプリケーションを開発する人間にとって、とても大きな価値を持つ本である。

　今はただの「PHPer（ぺちぱー）」であっても、この本を読んで「Programmer」にステップアップする可能性は十分にある。だからこそ思う、もっと適切なタイトルがあったのではと。

■大事なのは「効率」ではなく「モダン」

　本書は、PHPによるWeb開発を仕事にしていて、なおかつ

• MVCに沿ったクリーンなコード
• フレームワークを活用した開発スタイル
• オブジェクト指向の基本と応用
• Gitによるバージョン管理

といったトピックを完ぺきに実践できていない「PHPer」のための本である。サブタイトルである「モダン開発」にも入門できるし、「プロの現場」で起きていることも体験できるし、「最新PHPプログラミング」の動向も知ることができる。

　だからこそ、だからこそ！ 「効率的な」ではなく、サブタイトルの「モダン開発」の方を、強くアピールしてほしかった。

　いわゆる「PHPer」に必要なのは「効率」ではなく「モダンな開発スタイルの知識と実践」なのだから。

■ところで、ぺちぱーとは

　さっきから書いている「PHPer」という言葉は、PHPをメインに書いているプログラマのことである。類義語として、Rubyなら「Rubyist（ルビイスト）」、Pythonなら「Pythonista（パイソニスタ）」がある。

　しかし、「PHPer」にはやや侮蔑的なニュアンスが混じっているようにも思える。PHPばかりを好み、他のプログラミング言語やアーキテクチャ、モダンな開発スタイルに興味を持たないPHPプログラマを「PHPer」と呼んでいる場面が多い。

　私が最初に体験したWeb開発の現場でも、「クラスってよく分からないから使いたくないんだよね」というPHPerが、業界第3位（当時）のサービスの大部分を開発していた。ご想像のとおり、そびえ立つレガシーコードの山であった……。

　本書が書かれた真の目的は、この文脈での「PHPer」たちが、職業人としての「Programmer」にステップアップする手助けをするためであろう。

■PHPerよ立て、立てよPHPer

　本書は大きく「前半」と「後半」に分割できる。両者にはまったく違った価値があるので、別々に紹介していく。

●後半は「実践編」

　いきなり、後半から紹介する。後半はSymfonyというPHP製Webアプリケーションフレームワークを使い、実際に稼働するWebアプリケーションを開発する、という紙上ハンズオンになっている。フレームワーク上で開発をした経験がない人、それぞれの会社で使われている「オレオレフレームワーク」でしか開発していない人には有益なカリキュラムだ。プロの現場での開発、現場におけるフレームワークの使われ方を体験できる。

　特に「オレオレフレームワーク」上で生活している人は、ぜひ読むだけでなく手を動かしてみていただきたい。OSSとして世界中のユーザーに使われているフレームワークがどんな思想で作られ、どんな機能やポリシーを提供しているのか。「オレオレフレームワーク」しか知らない人には、貴重かつ重要な体験となるはずだ。

●前半は「理論編」

　対する前半は、理論に関する内容が中心。PHPerには不足しがちな「モダン開発」に必要な知識を紹介している。そしてこの「理論編」にこそ、著者からPHPerに向けられた強いメッセージが込められている。

　各章の見出しを見てみよう。

• Part1　MVC開発の基礎知識
  • 1章　MVC開発の概要
  • 2章　オブジェクト指向
• Part2　フレームワークを利用する利点
  • 3章　レガシーコードの欠点
  • 4章　リファクタリング・デザインパターン実践
  • 5章　フレームワークを活用する

　これだけの内容を、わずか100ページ弱に詰め込むなんて「無茶しやがって……」としか言えないのだが、典型的なPHPerでは、これらの概念に触れることすらないまま、仕事としてWebアプリケーションを作り続け、レガシーコードの山を高くし続けている事例が多く見られる。

　そんな状況を打破し、1人でも多くのPHPerを一人前に育てよう、という意気込み。これこそが著者からPHPerへのメッセージなのだ。

■「パーフェクト」の血筋

　本書の著者は小川雄大（@fivestr)氏。先日書評した『パーフェクトPHP』の著者の1人である。なるほど、「パーフェクトPHP」を読んで感じた「決意」のようなものが、本書からも感じ取れた。

　先日開催された「Symfony勉強会 #6」では、小川氏のセッションがあったようだ。スライドが公開されていたので、こちらも一読をお勧めしたい。本書が書かれた理由が語られている。ご自身の苦労や失敗、そして学びの経緯は、まさに「PHPer」が「Programmer」になる過程そのものだった。

■「PHPer」がdisられないために

　冒頭でちょっと触れた、「PHPer」という言葉のちょっとネガティブなニュアンスは、本書から学ぶことで打ち消していけるかもしれない。パーフェクトなPHPを書き、モダンな開発手法を身に付けた、disられないPHPerが増えることを願っている。

　そして、主に他のプログラミング言語を使っているプログラマ諸君にも、特に前半「理論編」は一読をお勧めしたい。ちゃんとできてるか？ 大丈夫か？

（『Wife Hacks ～仕事と家族とコミュニティと～』
コラムニスト　kwappa）

Head Firstデータ解析 ―頭とからだで覚えるデータ解析の基本

Michael Milton（著）、大橋真也（監訳）、木下哲也（翻訳）
オライリージャパン
2010年7月

ISBN-10: 4873114640
ISBN-13: 978-4873114644
3360円（税込）

■データ分析のスキルを持つ人が足りない

　「Microsoft Excelのヘルプファイルを、実際より見栄え良くプリントアウトしただけじゃないデータ解析本があったら素敵じゃない？ 夢物語にすぎないかもしれないけど……」

　なんとも皮肉の効いた吹き出しから始まる、他のデータ分析本とはひと味違う1冊。

　ビジネスの世界において、データに基づく判断は、ますます重要になってきている。しかし、専門的・体系的な理解を有するデータ分析者は、ニーズに比べてぐっと少ない。

　私自身、かつて大学の授業で、統計の基礎を学んだものの、実践的な利用イメージがなかったために、あまり興味が持てなかった。しかし、今コンサルタントとして働く上で、データ分析の基礎は学んでおきたい――そんな動機で本書を手に取った。

■本書の構成

　著者のマイケル・ミルトンは、非営利団体の資金提供者から集めたデータを解析し、その結果に基づいて行動し、非営利団体の資金調達を強化するのを手伝うことにキャリアのほとんどを費やしてきた。なんとも説得力を感じるプロフィールである。

　本書は、主にクライアントとデータ分析者（以下、アナリスト）がやりとりするという形式で進む。

• 1章　データ解析入門：分析する
• 2章　実験：持論を検証する
• 3章　最適化：最大にする
• 4章　データの可視化：図を使うと賢くなる
• 5章　仮説検定：否定する
• 6章　ベイズ統計：基準を活用する
• 7章　主観確率：数値で表した信念
• 8章　経験則：人間らしい解析
• 9章　ヒストグラム：数値の形状
• 10章　回帰：予測
• 11章　誤差：誤差を適切に示す
• 12章　リレーショナルデータベース：関連付けられますか？
• 13章　データクリーニング：秩序を与える

　ご覧のとおり、分析の基本的な考え方、確率、最適化、予測、データ加工、ビジュアライズと、実務で必要な要素はひととおりカバーしている。

■無味乾燥なデータ本とは一線を画す

　本書が他のデータ分析の指南書と異なる点についても、触れておこう。通常、データ分析の本は、たいてい下記の特徴を持っているように思う。

• ある特定のツールを前提にしている
• お題データがあるものの、ツールの機能を使用して加工・分析を進めていく
• 機械的で無味乾燥

　これらの本は、脳を刺激してくれない。文字だらけのパワーポイントを眺めているのと同じだ。記憶への定着が難しかったり、気付きを得る機会がぐっと減ってしまう。

　一方、Head Firstシリーズはすべて、下記のような方針で作られている。

• ビジュアル重視
• 会話のような親密な感じの文体
• 考えを深めながら学べるようにする
• 読者の関心を引きつけ、飽きさせない
• 感情に訴える

　これだけでも、無味乾燥なデータ本とは一線を画する本であることが、お分かりいただけると思う。

■作業だけでは足りない、必要なのは“思考”

　なぜ、普通のデータ分析本は飽きるのか？ 飽きる原因はひとえに、「“作業”ばかりで“思考”するタイミングがない」ことではないだろうか。

　本書では、ストーリーの至るところに「自分で考えてみよう」という演習を用意していて、読み進めるうちに、なかば強制的に「思考」することが求められる。ゲームをしているような感覚を覚えて、非常に面白い。

■クライアントとの付き合い方も学べる？

　また、ストーリーがクライアントの存在を前提としているため、常にクライアントの反応（期待、クレーム）に対するアプローチを意識して学習を進められる。

　「答えを求めている相手＝クライアント」と、「解として提示すべきものが何なのか」を考えることで、無駄な作業を減らせる―ーこうした考え方は、実際にお客さん相手に仕事をしてみないと分からないことなので、簡単ではあるものの、疑似体験できる価値は大きい。この点も、従来のデータ分析本にはなかったアプローチだ。

　今まで私が読んできた本では、Excelの機能を懇切丁寧に説明しているだけのもの、お題のデータを使って段階的に演習していくものがほとんどだった。ベンダの研修も似たような内容で、「思考する機会は帰ってからどうぞ」という感じだったので、本書のスタイルは思考したい人にとってはぴったりだろう。

■データ分析はツールが大事

　大量のデータ分析は、もはや人間の計算力・速度では対応できない。そのため、ツールを活用する必要がある。

　代表的なものとして、Excelのような表計算ツールが挙げられる。ある程度コストを掛けられるなら、もっと高機能なツールの使用も可能だ。本書で取り上げられているツールは2つ。1つはExcel、もう1つはRという統計分析ツール（フリーソフト！）である。

　本書の演習は、ExcelとRをうまく使い分けており、実践的な考え方に基づいて執筆されていることがよく分かる。

■まとめ：入門書としては申し分なし

　とにもかくにも本書は「実践的」という印象で、データ分析の入門書としては申し分ない。

　昨今、データに基づく経営、ビックデータからインサイトを得るなど、データ分析に関連する話題が飛び交っている。しかし、基本的なデータ分析のスキルなくして、インサイトなど得られるのだろうか。

　ボタンを押したら答えが出てくるような話ではない。ITシステムに求められる分析機能の要件は極めて高度で、統計や分析にうといエンジニアが処理できる世界を超えつつある。

　欧米に比べると、統計の専門者が圧倒的に少ないという日本の現状はあるものの、専門家にならなくとも、データ分析の重要性を考えていくべき、と感じる今日この頃だ。

　皆さんも、本書とともに、深遠なるデータ分析の道の第一歩を踏み出してみてはいかがだろうか？

徳永拓之（著）
技術評論社
2012年2月

ISBN-10: 4774149934
ISBN-13: 978-4774149936
2699円（税込）

■まるで空気のようなシステム

　この書評を読んでいるあなたが感想をTwitterに書きこもうとする時、日中の仕事でメールを書く時、友人とSkypeでチャットする時、Excel方眼紙に業務システムの設計書を作っている時。

　これらすべての場面で、共通して使用するソフトウェアがある。日本語入力システムだ。
　
　日本人としてコンピュータ上で日本語を扱う場合、このソフトウェアを利用せずに日本語を入力することはあり得ない。しかし、日本語入力システムはその重要性に反して、利用者のほとんどが意識しない。まるで、空気のようなシステムである。

　だが、空気とあなどるなかれ。日本語入力システムには、実は計算機科学の技術の粋が結集されている。

■複雑な日本語処理のすべてをここに書き残した

　本書は、日本特有のソフトウェアの中でも、最も重要性と難易度が高いシステムである日本語入力システムが、どのように設計されて動作しているのかを、実に読みやすく書いた良書だ。

　黎明期から現在に至る日本語入力システムの成り立ち、日本語入力システムの概観、それを実現するために必要なデータ構造の基本的な考え方や言語処理、機械学習のアルゴリズムなど、日本語入力システムのすべてが、本書には書かれている。

■メモリは限りなく少なく、しかし機能は膨大

　日本語入力システムに求められる機能は多い。

　日本語入力システムは、文字入力を必要とするあらゆるソフトウェアと連動して動作する。「入力」と「変換」という2つの機能を持ち、変換候補の一覧をどこに描画するか、という視覚的要素も必要だ。

　変換誤りに対する訂正の手段をどのように提供するか。仮にクラッシュした場合、他のアプリケーションを巻き込まないようにどう設計すべきか――。こうした高機能と変換に必要となる膨大なデータ量を要求されるにもかかわらず、空気のような存在であるがゆえに、メモリ量はできるだけ小さくなければならない。

　見た目のシンプルさや空気感と対照的に、日本語入力システムに求められる要件は複雑で、ソフトウェアとして高難度なものばかりだ。さらに、日本語は文法が複雑で、かつ扱う文字量の多さも半端なく多いため、さらに複雑さに拍車をかけることになる。

■難易度の高い話題を分かりやすく

　データ構造やアルゴリズムに関する章では、数学的な知識や情報処理についての素養が求められる場面もあるが、巻末に付録で説明されているので心配することはない。随所に登場する専門用語も、すべて初出時に定義されている。内容の高度さに比べると本書は驚くほど読みやすく、きちんと時間をかけて読めば誰でもこの本の内容を理解できるだろう。

　第3章以降のデータ構造、アルゴリズムの解説は難しいが、第2章の「日本語入力システムの概観」まではとても分かりやすく、日本語入力システムのエッセンスのすべてが書かれている。興味のある人は、第2章までを読むだけでも価値はあると思う。

　これほど身近に存在するにもかかわらず、その詳細を知る人はほとんどいないであろう日本語入力システム。その深淵の一端を、本書より感じとってもらいたい。

　これまではキーボードからの入力のみであった日本語入力システムは、スマートフォンなどで使用されるタッチパネルや音声入力など、一層の進化が期待されている。今、日本語入力について勉強してみるのもいいだろう。

■どんどん増える、スマホ対応のお仕事

　「2011年はスマホ元年」と言われたように、スマートフォン市場が急成長を続けています。Webサイトや携帯サイトをスマホ対応させている人は多いでしょう。私もその1人です。

　iPhone、Android、Windows Mobileといった多様な端末それぞれに最適化したページを作成することは簡単ではありません。端末の種類を吸収し、どの端末で見ても同じデザインで見せるフレームワークを用いれば、簡単にスマホ対応ができます。jQuery Mobileは、それを実現させるフレームワークです。

■秀逸なオフライン・ドキュメント

　本書は、jQuery Mobileでできることを網羅的にまとめています。公式Webサイトにあるドキュメント内容はほぼすべて掲載しており、かつソースコードだけでなく、スクリーンショットも豊富なので、オフラインのドキュメントとしておすすめできます。

　私は、今年からフリーランスのプログラマとして仕事をしています。スマホ対応サイトを構築するお仕事をもらったので、早速オフライン・ドキュメントとして本書を手に入れました。

●目次

• 1章 jQuery Mobileをはじめよう
• 2章 アプリケーションの構造とナビゲーション
• 3章 ページの要素
• 4章 テーマの切り替え
• 5章 jQuery MobileのAPI
• 6章 jQuery Mobileアプリケーションの実際
• 付録A 知っておくと役に立つTIPSとjQueryの基礎知識
• 付録B リファレンス

　以下は、すべてのページの基礎となるソースです。

　head部分でjQueryとjQuery Mobileのjsとcssファイルを指定し、body部分でヘッダとフッタ、ならびにページのメイン部分を記述していきます。後は、jQuery MobileならびにHTML5の仕様に合わせて記述していくだけで、簡単にスマホ対応サイトのページを作成できます。

　もちろん、jQueryならではのアニメーションやナビゲーション、ページ間の制御などの設定も可能です。これらの点は、公式Webサイトのドキュメントだけでは分からなかったので個人的には大変ありがたく、実際に仕事で参照しました。

　最も役立ったのは、5章の「初期化イベント」です。仕事で、「ページ遷移の直前に処理を行い、処理を反映した状態で次のページを表示できないか」という依頼がありました。公式Webドキュメントだけでは理解しづらかったのですが、本書のその部分を読み、実装可能であると分かりました。

　例えば、bind()という関数と pagebeforeshow というイベントを用いて、下記のように記述します。

<script>
$("page1").bind("pagebeforeshow", function(event, ui) {
    （何らかの処理を記述）
});
</script>

　こうすれば、「ページ遷移の直前に、遷移先のページで記述された処理を実行し、その処理が反映された状態のページを表示する」ことが可能です。

■本書をおすすめする人

　jQuery Mobileを利用する上で、jQueryの知識は多少必要ですが、簡単なjQueryの使い方を知っていれば十分jQuery Mobileを使えます。

　本書は、プログラマだけでなくデザイナーにとっても非常に読みやすい内容です。フォーム部品など、どういった表現がjQuery Mobileで可能かを本書で確認しつつ、デザイナーとプログラマの間で打ち合わせを行い、サイトを設計・構築していく――本書は、その一助になると思います。

（『It’s Party Time!』 コラムニスト　あずk）

■世界はきのこに満ちている

　「○○が知るべき97のこと」シリーズの第3弾が出た。本書は、プロジェクト・マネージャ（以下PM）向けのエッセイを97本（日本版は＋11本）を収録している。

　第2弾『プログラマが知るべき97のこと』は、プログラマ向けのエッセイが収録されている名著だった（以前に書評を執筆したので、ぜひご覧いただきたい）。

　『プログラマが知るべき97のこと』は通称「きのこ本」として親しまれている。ちなみに第1弾は『ソフトウェアアーキテクトが知るべき97のこと』。これはもう「きのこ本シリーズ」とでも呼ぶべきだろう。

■きのこ本が築く、きのこの山

　「きのこ本シリーズ」は、それぞれの分野で活躍する人物の手によるエッセイを97本（+α）収録するものだ。いろいろなキャリアを積んできたベテランが、プロジェクトで経験してきたことを短く印象的なエッセイにまとめている。

　「いろいろなキャリア」に根ざして書かれたコラムはどれも味わい深く、時には執筆者同士がそれぞれ違う主張をぶつけ合うことだってある。それが「きのこ本シリーズ」の魅力の1つでもある。

　ところが、本書は過去2冊と比べて明らかに「主張の衝突」が少ない。これはどういうことなのだろう。

■PMの問題領域、それは「人」

　本書を最初から読んでいくと、「プロジェクトを進める際によくある落とし穴」「気を付けるべきポイント」「よりよい行い」といったことを書いたコラムが並んでいる。アジャイルな開発手法を少しでも学んだ／経験したことがある人にとっては「あるある」の連続だろう。

• 顧客／ユーザーを巻き込む
• シンプルを心がける
• 問題を小さく分割する
• 優秀なチームを編成する
• チームで責任を果たす
• 変化を受け入れる
• コミュニケーションをとる

　読みながら分かったのは、「PMの問題領域は人間である」ということだ。

　考えてみれば当たり前なのだが、ソフトウェア開発においてもっとも難しいのは、設計でもプログラミングでもデバッグでもなく「合意すること」なのである。

　ユーザーは「自分たちが何を必要としているか」を分かっていない。顧客は予算を出し渋り、期間を圧縮したがる。開発者は移り気で扱いづらい。そしてみんな人間なので、エゴや怠惰さ、自己顕示欲や怠惰さを備えている。

　ソフトウェア開発プロジェクトでは、こういった「人間の厄介さ」が集約するハブとして「PM」というポジションがあるのだ。

　それであれば、本書に「主張の衝突」が少ないことにも納得がいく。人間関係の問題とは、「すでに解決策が分かっており、そしてそれを実践するのが困難」なものだからだ。

　ミーティングがつい長くなってしまう問題、複数のステークホルダーが違うことを言い出す問題、チームに問題児が紛れ込んでしまう問題、納期が遅れてしまう問題。いずれも、ソフトウェア開発が産業として興る前から存在し、そしてきっと、今後も存在する問題なのだろう。

■プロジェクト・マネージャとしてこの先生きのこるには

　ソフトウェア開発にかかわらず、プロジェクトをマネジメントするには「人」が最も大きな問題になるのだろう。そういう視点で本書を読みなおすと、PMという立場に置かれた時の心構えを準備できるだろう。

　目次を見てみよう。いずれも、ソフトウェア開発に関するエッセイとは思えないような見出しだ。

• 05「複雑よりもシンプルな方がいい」
• 14「大きさが重要」
• 27「見積もって見積もって見積もる」
• 37「自らに誠実であれ」
• 39「変化のための道筋を描く」
• 69「コミュニケーションが重要」
• 82「みんなが聞きたいことはなんですか？」

　だが、PMが扱う問題領域は、まさにこうした解決法を必要としている。現場で問題に立ち向かうには、かつて問題に立ち向かった諸先輩の声をよく聞き、よく咀嚼（そしゃく）し、そして

• 16「さあ、プラクティスを投げ捨てよう」

　自分の現場でこの先生きのこるには、自分の現場に合ったマネジメントを、自分の手で編み出す必要があるのだ。

（『Wife Hacks ～仕事と家族とコミュニティと～』
コラムニスト　kwappa）

■たかがマニュアル、されどマニュアル

　長い開発が終わってようやく一息つけると思ったのもつかの間、「マニュアル作っておいて」という一言により、慌てて画面をキャプチャし始める。マニュアル担当になったものの、開発側の仕様決定遅れに引きずられてリリース前に徹夜して書き上げる……。こんな経験は皆さん、一度ならず、二度三度はあるだろう。

　なんだかんだとなくてはならないもの、それが「マニュアル」である。マニュアルに携わるエンジニアを救ってくれる（かもしれない）のが本書、『業務システムのためのユーザーマニュアル作成ガイド』だ。

■オーソドックスな章立て

　章立てを見ていこう。

• 第1章　マニュアル作成の「間違った常識」
• 第2章　マニュアルの企画はこう進める
• 第3章　マニュアルの文章はこう書く
• 第4章　マニュアルや仕様書をわかりやすくするビジュアル表現
• 第5章　マニュアルの内容・表現の校正はこう進める
• 第6章　マニュアルの保守管理はこうする
• 第7章　部品化と構造化で効率アップ

　第1章で「間違った常識」と読者の注意を喚起し、2章以降でマニュアルの作り方を順に説明していくという、オーソドックスなスタイルだ。「マニュアルの書き方を知りたい」読者にとっては一見、冗長にも見える。

■思わず読み込んだ「マニュアル作成の間違った常識」

　まずは、1章から紹介しよう。

• 1‐1 常識の誤り マニュアル作成は目次構成の検討から始める
• 1‐2 常識の誤り マニュアルは読者別に分冊にする

　「常識の誤り」とは、なかなか過激な見出しである。普段、当たり前にやっていることなのだが、本書によれば「誤り」らしい。こういうやや過激な見出しは往々にして中身が伴わないものが多いが、本書は読んで納得できた。例えば、1‐1の「マニュアル作成は目次構成の検討から始める」では、「典型的な目次先行検討法の例」として「XX設定・XX登録」など機能の羅列の悪い例が示されている。確かにやりがちである。この「誤り」に対する、本書の回答。

• 何を伝えたいのか明確にする
• 伝える内容を整理整頓する
• 見せ方、探させ方の設計が目次作成である

　なるほど納得。特に3番目は「目次作成とは何か？」という著者の定義が明確に主張されていて、分かりやすかった。

　続いて1‐2の読者別分冊、ここではよくある（でも良くはない）家電のマニュアルが例として挙げられている。

• 1冊目：「初めてお使いの方に」
• 2冊目：「取扱説明書応用編」
• 3冊目：「困ったときに」

　それぞれの問題点と改善例が示されている。読みながら一緒に考えてみるとよいだろう。

　本書は、他にもいろいろな「常識の誤り」を紹介している。

• 1‐3 常識の誤り 書き始める前に文章の組み立てを行う
• 1‐4 常識の誤り マニュアルでは操作と結果を分けて書く
• 1‐5 常識の誤り わかりやすいマニュアルを書ける人は、文章の上手な人
• 1‐6 常識の誤り 正しい日本語文法の知識は必須である
• 1‐7 常識の誤り マニュアルには索引は必須である

　ほとんどが「常識じゃなかったの!?」という内容だったので、思わず熟読してしまった。

　誤りの改善例として、「文章の組み立てのためには、マインドマップを使って書きたいことを視覚化する」というものがあったのだが、自分も同じ解決法を用いていたので、ほっとした。他にも「Wordの文章校正機能などを使って文法ミスを回避する」など、日ごろから行っておきたい例が紹介されている。

　1章はこの後の各章の導入部となっているので、飛ばさず読んでおきたい。

■マニュアルも企画が肝、実はシステム開発と同じなのかもしれない

　2章では「マニュアルの目次を仕上げるまで」――つまりマニュアルの企画段階について書いている。この章は内容が濃かった。

　業務フローを作成するところが出発点だ。しかも、導入前と導入後のフロー両方である。まるで業務分析をしているかのようだ。そこから「機能」「操作」へと落とし込んでいく。

　マニュアルらしいところは2-6の「期待に応えられないところを探し出す」だろう。「できると思っていることができないという情報もまた、必要な情報」というところは、利用側の立場になってみればよく分かる。実際にできると思って探し回るのは、経験上よくあることだ。

　2章は17節まであり、ボリュームが大きい。そのくらい、企画段階はマニュアルにおける“肝”なのだろう。

■マニュアル作成のプロによる作成に校正、保守の解説

　3章の「文章はこう書く」は、読者を絞り込むペルソナモデルからスタートし、漢字・ひらがなの使い分け、修飾語、接続詞、助詞、指示語、といった「書き方」についてのポイントを紹介している。文科系出身の人間は、息がつけるところだ。「に」と「へ」の区別などを再確認するのにちょうどよい。

　4章はビジュアル表現。ビジュアルと聞くとすぐにイラストを想像してしまうが、それだけではない。ビジュアルは特に、図解によるグルーピングなど、論理的な思考を試される。この4章でようやく、Wordの「段落書式の設定」といった、具体的なツールの使い方が出てくる。本書が、手法に重きを置いていないということがよく分かる。4章までを読めばひととおりのマニュアルが書けると思う。

　5章は校正について。PDF校正の利点についての説明は、マニュアル作成をやったことがある者としてよく分かる。

　6章では保守管理、7章では部品化・構造化について。通常のシステムマニュアルでここまで踏み込むのは容易ではない。ただしマニュアル管理の業務に携わったことがあれば、イメージがつきやすい内容だろう。

■まとめ。マニュアル作成側の地位向上はなるか？

　内容をまとめよう。1章の常識は、次章以降の導入部となっているため、読んでおく必要がある。2章以降は、作成の手順に沿った構成で分かりやすい。だからといって「さあ、作ってみよう」というチュートリアル形式の手段や方法ではなく、考え方が述べられているので応用が利く。

　マニュアル作成全般のフェイズだけでなく、メンテナンスのフェイズでも手元においておきたい本である。

　ただし、いくらマニュアルを工夫しても、出来の悪いシステムが良くなるわけではない。分かりにくいインターフェイスは分かりにくいままだ。

　だから、マニュアル作りが軽視されるのかもしれない。本来はシステム開発において開発側と両輪であるべきだし、マニュアル側から開発へ改善を求めるくらいが理想的なのだろう。