晴読雨読＠エンジニアライフ

実践テスト駆動開発 Steve Freeman、Nat Pryce（著） 和智右桂、高木正弘 (翻訳) 翔泳社 2012年9月 ISBN-10: 4798124583 ISBN-13: 978-4798124582 4,410 円（税込）

■「実践テスト駆動開発」ーー諸君、これがTDDの実践だ！

　TDDは広まりつつある。しかし……。

　アジャイル開発を行う上で、必須といってもいいプラクティスの1つに「テスト駆動開発・TDD」がある。このTDDのバイブルである「テスト駆動開発入門」をKent Beck氏が世に出してから、10年が経った。その間に、欧米では、すでにアジャイルがメインストリームとなった。日本でも、多くの諸先輩方が実践を続けていくなかで、ようやく広まってきたところだ。TDDを学ぶイベント「TDD Boot Camp」も、毎回キャンセル待ちの人が数多く出る人気イベントとなっている。

　日本でも、TDDに対する裾野はだいぶ広がっているのだろう。しかし、いざ実際の仕事でTDDをやろうとすると、いくつもの壁にぶち当たる。イベント駆動型クライアントアプリケーションの場合、データベースが絡む場合、マルチスレッドの場合、サードパーティのコンポーネントを使う場合。あまりに壁が大きいため、挫折してしまった人も少なからずいるだろう。かくいう私も、こうした壁を前にして、心が折れた経験を持っている。

　そうした、悩めるTDDerに向けて書かれた本が、本書「実践テスト駆動開発」である。本書は、世界中のアジャイリストが10年の歳月をかけて積み上げてきた、“TDDを行う上での壁”に立ち向かう術を教えてくれる、テスト駆動開発の奥義書である。

■そもそもTDDとは何か

　Wikipediaによると、

　プログラムに必要な各機能について、最初にテストを書き（これをテストファーストという）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。

とある。

　では、TDDをすることで、どういった恩恵があるのだろうか。本書では

　システムを開発する際には、TDDを採用することで、実装（「正しく動くか？」）と設計（「適切な構造になっているか」）両方の質についてのフィードバックが得られる。テストを先に書いて開発することで、投入した労力による恩恵が二重に得られるのだ。

とある。つまるところ、TDDをすることは、設計と実装を小さなスケールで絶え間なく繰り返すことで、正しいソフトウェアを作っていくことに他ならない。

■立ちはだかる壁を内包したアプリケーションを、TDDで育てていく

　では、実際にTDDはどういった形で進めていくのだろうか。本書のサンプル「オークションスナイパー」というサンプルアプリケーションの開発内容を一部紹介していく。

　まず行うのが、アプリケーションの全体像を考えること。必要となるプロトコルや、状態遷移、扱う機能について洗い出す。いきなりテストコードを書くのではないのだ。何をしなければいけないのか。どういった技術基盤の下に行うのか。そうしたアプリケーションの設計を行う必要があるのだ。

　そうしてアプリケーションの設計をした後に行われるのが、「動くスケルトン」と呼ぶものを作ること。これはシステムで必要となるコンポーネントを網羅した形で一つの機能を、エンドツーエンドテストーーユーザーインターフェイスからサーバとの通信を経て、結果が出るまでーーとして成功するものとして構築したものである。

　「オークションスナイパー」システムでいうと、ユーザーインターフェイスやスナイパーコンポーネント、オークションサービスとの通信を網羅した形で一つの機能をTDDで実装するとしている。

　このとき、オークションサービスは実際のものを使わず、同じように動作させることのできる仮想サービスを用意して行う。

　いわば、アーキテクチャの検証である。考えたアーキテクチャが正しいかどうかを検証するのだ。こうしてアーキテクチャの検証を終えた「動くスケルトン」に一つずつ機能を追加していく。

　「オークションスナイパー」システムは、最初偽のオークションサービスとコネクションを行い、オークションの終了を見届けるだけの機能から作成を始めている。そこから一つづつ機能を追加していく形で、入札を行ったり、新しい商品を追加できるようにしていっているのだ。

　もちろん、テストコードを書き、それが全て成功するのを保つようにして追加していくのだ。このようにして、正しいソフトウェアを育てているのだ。

　実際のアプリケーションをTDDで開発していくのにここまでやる必要があるのかと、私は圧倒された。しかし、ここまでやるからこそ正しいソフトウェアを育てていけるのだろう。ウォーターフォール型開発で最後にテストを行なうことで、バグが吹き出して苦しい思いをする。それに比べれば、こちらの方が、開発は大変ではあるが、安心して開発ができるように思う。

■すべてのTDDの難問に対する解はここに

　この「オークションスナイパー」のサンプルには現れていない、TDDをする上で陥りやすい罠や立ちはだかる壁はまだ多くある。こうした難問に対しても、本書は解を示している。

　例えばデータベースを扱う際のTDDはどのようにして行えばいいのか。永続データの消去をテストの開始前に行うのだ。整合性制約があるので、テーブルから行を削除する順序を一つにまとめ、行うのがよいとしている。

　トランザクションを必要とする場合はどうすればいいか。トランザクション管理を行うオブジェクトを抽出し、そのなかでユニット・オブ・ワークパターンを用いればよいとしている。

　他にもマルチスレッドでのTDDや非同期処理でのTDDなど、「こういう場合のテストはどう書けばいいんだ……」という、TDDerの悩みに本書は応えてくれるだろう。

■TDDを学び、本書を携え実践しよう

　残念ながら、本書はこれからTDDを学ぼうとする人が読むには敷居が高いだろう。初めてTDDを学ぶならば、やはりKent Beck氏の「テスト駆動開発入門」を読み、実際にコードを打ち込んで、体験する必要があるだろう。もちろん、TDD Boot Campへ参加するのもいいだろう。

　そうやって、TDDを学んで実際に使い始めると「こういう場合どうすればいいんだ……」という場合が必ず訪れる。そのときこそ、本書はあなたの力になってくれるだろう。私もまた、本書を携えてTDDを実践していこうと思う。

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システムに求められる分析機能の要件は極めて高度で、統計や分析にうといエンジニアが処理できる世界を超えつつある。

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

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

実践JS　サーバサイドJavaScript入門 井上　誠一郎（著） 技術評論社 2011年4月 ISBN-10: 4774146293 ISBN-13: 978-4774146294 3570円（税込）

■Webブラウザという揺りかごを捨てたJavaScript

　JavaScriptを使う理由はただ1つ、他に選択肢がないからだ。JavaScriptは、Webブラウザで動く唯一の言語である。FlashやJavaアプレットでもWebブラウザからプログラムを動かせるが、JavaScriptとは根本的に違う。

• プラグインやJVM（Java仮想マシン）など外部的な何かを必要としない
• HTMLを直接操作できる

　この2点において、JavaScriptは圧倒的な優位性がある。他の言語はWebブラウザの世界に入ることすら許されない。

　今、Webブラウザの中で育った言語が、サーバサイドJavaScriptという形でWebブラウザから飛び出そうとしている。

　しかし、ブラウザ以外でJavaScriptを使う理由はどこにあるのか？ Webブラウザというゆりかごを捨てて他の言語と同じ土俵に立つことで、JavaScriptはどこに向かおうとしているのか。

■概念としてのサーバサイドJS

　本書は6章構成である。

• Part1　サーバサイドJavaScript序論
• Part2　共通API
• Part3　サーバサイドJavaScript
• Part4　ドキュメントDB
• Part5　クラウドの拡張言語
• Part6　Webアプリ実装

　前半はJavaScriptの歴史、後半はDBの拡張言語としてのJavaScriptや、Javaの話が中心だ。Java Servletだけでなく、DIやRESTの知識、Javaでの使い方を知らないと、読み進めるのは難しい。

　現段階では、サーバサイドJavaScriptとは、仕様でも実装でもなく「概念」だ。本書は、単純にサーバサイドで動くだけのライブラリからMVCアーキテクチャを実現するフレームワークまで、有名なライブラリやフレームワークを、サンプルとともに紹介している。技術のTipsというよりは、どちらかといえばJavaScriptを取り巻く“今”を俯瞰（ふかん）するための書物である。

　本書を読んでいるうちに、以下の問いが頭をめぐった。

　サーバサイドでJavaScriptを動かすことの意義はどこにあるのか？

■クライアント／サーバサイド、すべてをJavaScriptで書く？

　Webアプリケーションには、さまざまな言語や技術要素が混在する。クライアント側に出力するHTML、CSS、JavaScriptをサーバサイドの言語で制御するスタイルが一般的だ。

　ここに、サーバサイドで動くプログラム言語としてJavaScriptが新たに加わった。「言語の混在を解決する」というが、クライアントとサーバサイドの言語が一致することにどんなメリットがあるのか。

　「どうせやるならサーバサイドも含めてすべてJavaScriptで作ろう（p.28）」

　本書はこのように提案している。1つの言語だけですべてが成り立つのなら学習コストは下がるが、現実はそう甘くない。

　例えば、クライアントサイドの言語としてJavaScriptをゴリゴリと書いたとしても、Webブラウザのみというネイティブな環境だけではJavaScriptは力不足だ。たいていの場合、Webブラウザ間の依存を吸収するためにjQueryやprototype.jsなどのライブラリを使用することになるし、ライブラリを使わなければなおのこと、依存関係を隠ぺいするために何らかの手段を講じなければならない。

　私がこのアプローチをとるなら、JavaScriptを自動生成するようなフレームワークやライブラリを採用するだろう。JavaScriptをまったく知らなくてもよいという意味ではないが、適切なものを選択すれば、JavaScriptを書く必要はほとんどない。

　GWT（Google Web Toolkit）を使うなら、GWTが出力するJavaScriptをきちんと理解した上でライブラリを使用する。それでも機能が足りないならば、GWTの枠組みの中でJavaScriptを自動生成するプログラムを書く。なぜなら、クライアント側のコードはブラウザによって挙動が違うからだ。Webブラウザごと処理を切り替えるようなロジックをJavaScriptに書くよりは、ブラウザごとに必要なJavaScriptのみを出力させているほうがよい。

　本書が例示する「バリデーションコードの重複」などは、サーバサイド言語から自動でJavaScriptを出力させた方が良い。この手の処理は再利用可能な作り方をしているので、正しい使い方を理解していれば何も問題ない。

　インフラも含めてWebアプリケーションのアーキテクチャは日々、複雑さを増している。厳しいことを言うようだが、複数の言語が入り乱れた程度で「プログラムが作れない」と音を上げる人間に、今日のWebアプリケーションの開発は不可能だと思う。

　事実、最終章ではJavaで構築したアプリの上でJavaのVMを経由してJavaScriptを実装している。これは相当に難しいアーキテクチャである。この場合、言語の差異、つまり「JavaにできてJavaScriptできないこと」と「JavaScriptにできてJavaにできないこと」を明確に知った上での実装を要求される。「クライアントサイド／サーバサイド」という明確な線引きができるようなものではない。

■サーバサイドJSは、ロジックの入れ替えが自由なのか？

　「サーバ側に他のプログラミング言語を使う場合に比べて、コードを相互に移動可能だからです。クライアント側が重いとなれば、処理をクライアントからサーバに移す、あるいは逆の移動、このようなことが相対的に容易です（p.30）」

　上記の文章は「JavaScriptならクライアントサイド、サーバサイドで相互にコピペで移植が可能」と読める。しかし、この考え方は危険だと私は思う。

　プログラムは、動きさえすれば何をやってもよいというものではない。クライアントとサーバでは役割が違う。コードが書かれる場所にはしかるべき理由があり、「どこに書いてもいい」処理は存在しない。

　入れ替え可能なロジックはコピペで行うのではなく、プログラムの中で実現するべきものだ。プロキシやアダプタを使い疎結合にして、ストラテジなどのパターンでプログラムを部品化する。その先で負荷分散やパフォーマンスチューニングを行う。最適化はそれぞれの領域が持つ技術で解決したい。

　JavaScriptはほんの少しDOM（Document Object Model）への参照に気をつかうだけでも、動作速度がぜんぜん違う。正しい知識を持って作れば、たいていの処理は高速化される。特にサーバサイドでは、負荷分散の技術は山のようにある。そちらの技術を使えばいいのではないだろうか。

　小手先のテクニックでごまかしていると、問題が起こった時、真の原因にたどり着けなくなる。ただし、初学者がクライアントとサーバそれぞれの役割を学習するという意味では、有効なアプローチにはなるだろう。

■JavaScriptの未成熟なライブラリ？

　「他のプログラミング言語では当たり前にあるようなファイルの読み書きすらJavaScriptの標準APIには存在しない（p.26）」

　JavaScriptはその発展の歴史から、Webブラウザが必要としない機能は組み込んでこなかった。Webブラウザから動かすJavaScriptでさえ力不足を感じるときがあるが、その解として、CommonJSを中心とした標準APIとでもいうべきものが策定されようとしている。

　標準APIといいつつ、今の段階では仕様が固まっていないものが多い。だが、今後標準APIが大きく変更されることはないだろう。これらは、JavaScriptという処理系に何が足りないのかを明確にしてくれる。言語の外枠が見えてくれば、標準APIがリリースされることを待たなくても、今のJavaScriptの書き方が見えてくるのかもしれない。

　基本的な道具がそろっている言語は“成熟している”と言える。だが、JavaScriptはどうだろうか？ おそらく、ここがサーバサイドJavaScriptで最も弱い部分だろう。Javaや.NET Frameworkなど、他言語のライブラリや、オープンソースの充実ぶりを見ているとよく分かる。

　流行の負荷分散やパターン認識、自然言語解析だけでなく、ロガー1つ取っても、JavaScriptだけでは心もとない。JavaScriptは、まだまだサーバサイドで使うだけの道具が足りない。使える道具がひととおり揃うまでに数年はかかるだろうと見ている。

　プログラム言語は仕様だけがすべてではない。それを取り巻くコミュニティや文化といったものがあって初めて成熟する。見方を変えれば、今サーバサイドJavaScriptの世界に飛び込んでおけば、JavaScriptが真の実力を得たときに、自分が活躍できる日が来るかもしれない。

■じゃじゃ馬のようなJavaScriptをいつか使いこなすために

　プログラミング言語は面倒なものである。そもそも、処理系を用意したり、環境を構築したりという、コードを書き始めるまでの準備が面倒だ。画面が派手に動くプログラムを作るのだって難しい。

　こうした手間を飛ばしていきなりプログラムが書けて実行できるJavaScriptは貴重な言語である。必要なのはブラウザとテキストエディタだけ。文法を少し覚えたらスグに実行できる。HTMLの知識があれば、GUIでインタラクティブなツールを簡単に作れる。

　だが、私は「安易」というイメージのままサーバサイドに持っていくことに警鐘を鳴らしたい。JavaScriptは、お手軽に組める言語であるがプログラム言語としては相当に扱いづらい。奥が深いといってもいいだろう。

　『JavaScript The Good Parts』にはこう書かれている。

　「JavaScriptには多くの設計ミスと、変わった特徴が存在している」

　JavaScriptには、DOM（Document Object Model）を直接操作できることや、関数型言語の性質、それらがオブジェクトの中に取り込めることなどの魅力がある。JavaScriptの持つ真の力を出せるアプリケーションを作るには相当な力量を要求されることになるだろう。あらためて思う。サーバサイドJavaScriptよりもJavaScriptの方が難解だ。

　私自身、関数型言語の思想が、まだ本能レベルで理解できていない。ちょうど、手続型言語で育った世代がオブジェクト指向言語に感じる壁のようなものを感じている。それでもエンジニアの矜持として、技術から逃げたくはない。いつの日か、このじゃじゃ馬のような言語を乗りこなしてみたい。

エンジニアのためのExcel再入門講座 吉川昌澄（著） 翔泳社 2010年1月 ISBN-10: 4798119474 ISBN-13: 978-4798119472 2310円（税込）

■Exceにまつわるエンジニアの叫び

　「Excelの方眼紙はやめてくれー！」

　「遂にMac版のExcelで方眼紙テンプレートが標準搭載されたらしいぞ！ ガクブル」

　今日もTwitterのタイムライン上で、技術者の心の叫びがこだまする……。

　かつて、上司によく小言を言われました。

　「ソフトウェアの特性を生かした使い方をしろ。一般ユーザー向けソフトだからこそ、技術者としてきちんと勉強しろ」

　「Excelは、表計算ソフトであって、表作成ソフトではない」

　前述のように、Excel方眼紙に苦しめられているTwitterユーザーのつぶやき（もはや叫び）を時々見掛けます。私自身、現場で「なんでこんなことに!?」と思わず頭を抱えたくなるような使い方を目にします。優秀なExcelが泣いています。

　もっと、使いこなして業務に生かしてあげてください。これはヘルプデスクとしての切な願い（もはや叫び）です。

■エンジニアだからこそ、Excel

　さて、本書は「Excelの機能を知り尽くしている（はずの）優秀なエンジニアであるにもかかわらず、Excelを使って作成したドキュメントはなぜこうも見にくく、再活用が困難であるのか」という誰にとっても覚えのある疑問から出発します。本書のテーマはずばり「読みやすいドキュメントをいかにしてExcelで作成するか」。

　Excelはあくまで手段であり、目的ではありません。目的（＝ドキュメントを作りたい）を果たすため、手段・道具（＝Excel）を使いこなす。その際に役立つ知識、すなわち

• 表のレイアウト
• データモデル
• 可読性の向上
• メンテナンス性をいかにして考慮するか

などのノウハウを解説しています。非常にシステマティックです。

　また、表ドキュメンテーションのノウハウという観点だけでなく、データ分析やグラフによる「見える化」、業務の流れに沿った帳票の作り方にも言及しており、現場のメンバーから管理職まで、幅広い人材が読むべき内容が網羅されていると感じます。

　巻末には、ドキュメント作成に有効なExcelの操作メモ、さらに章の間には筆者のコラムもあるという親切設計。あまり使う機会がない小技やTips、筆者の体験談などが書かれており、「Excel萌え」の私としては、非常に楽しく興味深く読めました。ここに記載されているExcelの操作知識は、エンジニアであれば押さえておきたいところです。

■まとめ：Excel萌えヘルプデスクの必読書

　「入門」とタイトルについていますが、あくまで「エンジニアのための」本です。

　Excelの操作知識が十分にあるエンジニアが、より良い「素敵ドキュメント」を作成するための知識や考え方、Excelの小技が網羅されています。決して「Excelの使い方」ではないので、Excelの知識が浅い人は、まずしっかり基本をマスターしてから一読することをお勧めします。

　細かいノウハウを紹介することはあえて避けましたが、エンジニアならば読んでいて楽しくなってくるはず。日々、現場で「どうしてこういうことをするのですか？」と、作り手に詰め寄りたくなるExcel帳票を見ている私としては、「必読書」として自社で推薦したいです。

　そして、ますますExcelの奥深さにハマりそう……。勉強、勉強！

●おまけ：編集部おすすめのExcelコラム

・次世代ソフトを提案する。　―Microsoft編―

　同じくヘルプデスクのコラムニストがつづる、次世代ソフト妄想。「ExcelとWordの究極合体「Exord」(エグゾード）」は必見。

・Excelの必殺技（101回死んだエンジニア）

　Excelは使う人によって、驚くほどの差が出る。見た人が「格好良い！」と鼻血をふくほど華麗にExcelを使いこなせるエンジニアになりたいものだ。

入門 自然言語処理 Steven Bird、Ewan Klein、Edward Loper （著） 萩原正人、中山敬広、水野貴明 （翻訳） オライリージャパン 2010年11月 ISBN-10: 4873114705 ISBN-13: 978-4873114705 3990円（税込）

■自然言語処理とは

　「自然言語処理」（NLP：Natural Language Processing）という言葉をご存じだろうか。自然言語処理は、コンピュータの用途の1つとして、古くから研究されてきたジャンルである。

　言葉を分割して考えてみよう。「言語」は自明であるとして、「自然言語」とは何か。

　「自然言語」とは、人間が日常のコミュニケーションを取るために使う「言葉」である。単に「言語」といえば、一般的には英語や日本語など自然言語のことを指すことがほとんどだろう。まあ、エンジニアが「言語」という場合はRubyだったりCだったりするのだが。

　「自然言語」に対して、人間が作った言語を「人工言語」という。ゼビ語やクリンゴン語など架空の言語、HTMLやXMLなどのマークアップ言語、そしてRubyやCなどのプログラミング言語などが代表的な「人工言語」である。

　「自然言語」という場合は、「人工言語」との対比を明確にする狙いがあるようだ。

　続く「処理」は、コンピュータプログラムで解析・利用すること。「自然言語」に対しての「処理」は、字句解析や構文解析などの「解析」と、文章の意味を理解したり作文したりする「理解」に大別される。

　つまり、この本は「自然言語」をコンピュータで「処理」するために必要な基礎知識を身に付けるための「入門」書なのである。

■入門準備号

　……と、こんなようなことを、この本のレビューをすること決めてから本が届くまでの間に調べてみた。なんとなく分かっているつもりでも、きちんと調べると知らなかったことが出てきたりして面白い。さらに、これをネタにして社内のLT（Lightning Talks）大会で発表したりと、読み始める前から盛りだくさんな1冊である。

　このように個人的予習をしてから読み始めたのだが、届いてからもなお、まだやるべきことがあった。題材として選ばれているプログラミング言語「Python」と、Pythonの自然言語処理ライブラリである「NLTK」（Natural Language Toolkit）の準備である。

　教材のサンプルを実行する環境を用意し、手を動かしながら読むことで、この本の真価に触れられる。手前味噌で恐縮だが、環境構築手順のメモをブログにまとめたので、参考にしていただければ幸いだ。

■1冊で、自然言語処理とPythonと英語が学べる

　「まえがき」にあるように、本書は学生の新学期のカリキュラムとして、

• 「自然言語処理について」
• 「コンピュータプログラミングについて」
• 「Pythonについて」

を教えてくれる。プログラミングの基本となる考え方にもざっと触れているし、Pythonの特徴的な部分にも言及しているので、熟達していない分野があれば一緒に学べる（というか、学ばざるを得ない）というのも、手強く、かつ面白いところである。

　読み進めると、自然言語処理についての理解が深まるのはもちろんだが、題材が主に英語についての解析なので、強制的に英語の勉強もすることになる。手元に使いやすい英和辞典を用意しておくとよいだろう。わたしはこれがきっかけで、iPhoneアプリを購入した。

　また、日本語を処理するための知識として、訳者陣によって第12章「Pythonによる日本語自然言語処理」が丸ごと加筆されている（第12章は無償公開されている）。第11章までの内容は、日本語の読者にとっては「十分すぎる予習」なのかもしれない。第12章では、日本語特有の事情、形態素解析と係り受け解析、意味解析への入り口など、これまでなかった「日本語に対しての自然言語処理」の案内が記されている。

■まとめ：自然言語処理への入門

　さあ、これで「自然言語処理」に「入門」する準備はできた。

　本書は、大学のカリキュラムとして十分な量の学びが用意されている。焦らずじっくり、手を動かしながら読みこんで、自然言語処理の世界に入門しよう。

リーンソフトウェア開発と組織改革 Mary and Tom Poppendieck（著） 依田光江（翻訳） 依田智夫（監訳） アスキー・メディアワークス 2010年10月 ISBN-10: 4048687417 ISBN-13: 978-4048687416 2940円（税込）

■偉大なリーダーはあらゆるレベルに存在する

　ソフトウェア開発における「リーダー」というと、皆さんはどんな人物を思い浮かべるでしょうか。顧客を喜ばせるようなビジョンが作れる人？ 卓越した専門性を持つ技術リーダー？ 制約（コストや納期）の中でプロジェクトを完遂させる実装の主導者？ たゆまぬ組織改善を行う指導者？ 最前線に立って周囲の人々に大きな影響を与える現場のリーダー？

　どれもが正解ではないでしょうか。というのも、ひとことで「リーダー」といっても、さまざまなフェイズに、さまざまなタイプのリーダーが必要とされるからです。

　「リーン開発」の提唱者、メアリー・ポッペンディーク氏とトム・ポッペンディーク氏は、『リーンソフトウェア開発と組織改革』で、次のように語っています。

　「偉大な企業は組織のあらゆるレベルに偉大なリーダーがいるのだ。さもなければ彼らは偉大な企業になっていなかった」（p.311）

■24のフレームと、6つのリーダー像

　本書は『リーンソフトウエア開発――アジャイル開発を実践する22の方法』『リーン開発の本質――ソフトウエア開発に活かす7つの原則』に続く「リーン開発シリーズ」の第3弾です。リーンの視点から、組織改革と、それを実現するリーダー像について論じているのが特徴です。

　全体の構成として、24のフレームが提示されています。それらは6つの章に分けられており、1章につき4つのフレームを解説されています。各章の最後には、対応するリーダー像が示されており、「どのフレームではどんなリーダーシップが求められるか」が確認できます。

• 第1章「システム思考」
• フレーム1：顧客中心
• フレーム2：システムの能力
• フレーム3：開始から終了までのフロー
• フレーム4：ポリシーが生み出すムダ
• 第2章「技術的卓越性」
• フレーム5：本質的複雑性
• フレーム6：構成的な実装による品質
• フレーム7：進化型開発
• フレーム8：深い専門性
• 第3章「確実なデリバリ」
• フレーム9：裏づけのある実績
• フレーム10：ワークフローの平準化
• フレーム11：プル型スケジューリング
• フレーム12：適応制御
• 第4章「たゆまぬ改善」
• フレーム13：完璧を視覚化する
• フレーム14：ベースラインを決める
• フレーム15：問題を顕在化させる
• フレーム16：改善の仕方を学ぶ
• 第5章「人こそすべて」
• フレーム17：知識労働者
• フレーム18：「助け合い」という規範
• フレーム19：相互尊重
• フレーム20：熟練の誇り
• 第6章「連携型リーダー」
• フレーム21：理論から実践へ
• フレーム22：ガバナンス
• フレーム23：団結
• フレーム24：持続可能性

　これらのフレームから導かれるリーダー像とはどんなものでしょうか。第1章では「製品のアイデアにシステム思考を取り入れる『製品チャンピオン、テイク1』」、第2章では「優れたテクノロジの開発に全力で取り組む『高能力・高業績（コンピテンシー）リーダー』」、第3章では「制約、リスク、スケジュールを管理し、実装を主導する『製品チャンピオン、テイク2』」、第4章では「たゆまぬ組織改善に努める『メンターとしてのマネージャー』」、第5章では「現場において人々に影響を与える『前線のリーダー』」の人物像が描かれます。それらを踏まえ、第6章では『あらゆるレベルのリーダー』の人物像がまとめられています。

■結果に着目するのは誤りである

　ところで、本書は技術書なのでしょうか。それともビジネス書？ 恐らくは両方です。例えば第2章「技術的卓越性」では、テスト駆動開発や継続的統合といった手法をソフトウェア工学の歴史の延長上に位置付ける形で解説しています。また、第3章「確実なデリバリ」では、「制約に合わせて活動を設計する」というシステム設計の考え方を、エンパイアステートビルの建築プロジェクトを例にとって解説しています。その一方で、第4章「たゆまぬ改善」や第5章「人こそすべて」において、マネジメントや組織改善といった課題への取り組みについて論じています。

　読み手によって、どの章を面白いと思うかは分かれるのではないでしょうか。そしてそれこそが、その人が「どのタイプのリーダー向きか」を表す鏡として機能します。

　ただし、共通する視点も存在します。その1つが、原書の副題ともなっている“Results Are Not the Point”です。「ベロシティの高い企業」（業界を常にリードしている企業）について、本書では次のように書かれています。

　「ベロシティの高い企業は複雑性にどう対応するかを予測しようとせず、複雑性を学ぶことに集中する」（p.217）

　「ベロシティの高い組織は、予定とのずれを、学習する好機として歓迎し、仕事の複雑性についてもっとよく知ろうとするのだ。ベロシティの高い組織は仕事を終わらせることではなく、仕事を終わらせる方法を学ぶことに重点を置く」（p.217）

　別の章では、知的労働について、次のように書かれています。

　「知的労働では、人と、人が働くシステムなくして成功はありえない。結果が肝心なのではない。人とシステムを育成し、両者の力が合わさって成功を達成できるようになることが肝心なのだ」（p.260）

　組織を改善し、人を育てながら、制約の中で素晴らしい成果を作り上げるのは、並大抵のことではありません。それを可能とするシステムを作り上げるのが、リーダーの仕事なのではないでしょうか。

　本書の最後には、「偉大な企業のあらゆるレベルに見られるリーダーの人物像」がまとめられています。これらを参考にして、偉大なリーダーとして自分のチームや会社を改善させることに、ぜひ挑戦してほしいと思います。

• リーダーは目的を示す
• リーダーはトーンとテンポを決める
• リーダーは人を成長させる
• リーダーは他者が成功するための場所を作る