技術書 Archive

こんにちは、Kuboです。

本書は昨年ホワイトハウスのWebサイトの検索部分に使われて話題になったApache Solrの入門書/解説書です。

今回Twitter上で、技術評論社でソフトウェア・デザインを担当されているの池本さん(@XR230)が書評する人を募集されていて、Solrは実案件で使っていたこともあり手を挙げさせていただきました。
っていうか、遅くなってすみません！

Apache Solrとは

OSSの全文検索サーバです。
いわゆる「エンタープライズサーチ」というようなカテゴリに入るソフトウェアです。
詳細は本書にゆずりますが、Solrは以下のような特徴を持っています。

• OSS
• Apache Luceneを全文検索ライブラリとして採用
• HTTP/XMLを始めとし、言語に依存しない様々なインタフェースをもつ
• 豊富な検索機能(ファセット検索、もしかして、サジェスト、など)。拡張もできる。
• マルチコア、分散検索、レプリケーションなど、大規模システムに対応

Apache Solr入門について

本書は日本語で書かれた初めてのApache Solr本です。
Sorlのまとまった日本語ドキュメントというのは、本書の登場まではSoftware Design 2007年 12月号の『全文検索システム「Solr」徹底活用ガイド』くらいしかありませんでした。
(当時はSolrは1.2、現在は1.4です)

また本書の著者はApache Lucene 入門で知られる関口さんや、上記のソフトウェアデザインの記事を書かれたリクルートの中野さん他著名な方なので安心です。

本書のいいところ

細かいところまで日本語でしっかり説明されている

基本的にはここに尽きると思います。
本書はSolrの利用で必要になる殆どの情報(solrconfig.xml, schema.xml, stats情報, 各種検索、各種クライアント、その他多くの項目)について、しっかりとした説明を用意しています。
よって単に「インストールして使ってみました」という意味の「入門」本ではなく、概要を知るための情報もリファレンスとしての情報も、どちらも載っている「全てのSolr利用者のための」本です。

例えば2章の「スキーマの設定」ではfieldTypeの各属性の説明がありますが、
sortMissingFirstやsortMissingLastの意味などがしっかりと説明してあります。
実はこのあたりの情報は一応公式？ドキュメントであるSolr Wikiにも詳しくは載っていませんし、
載っていても英語の得意な人以外は微妙なニュアンスは分かりにくいものです。

そういう意味ではPostgreSQLやMySQLなどのRDBMSと違い日本語の公式ドキュメントが無い以上、どうしてもはっきりとしない部分が独習では残ってしまいます。
もちろんそういう点を一つ一つ確認していけるのはOSSの利点だと思いますが、それにはかなりの時間がかかります。

エンジニアは新しめの技術を取り入れるとき、往々にして「莫大な時間を費やして一つ一つを精査する」か「精度は諦めて、スピード優先でとりあえず使ってみるか」を選択することになりがちです。
本書があれば、精度とスピードのどちらも手にいれることができます。
私自身、1~2年前に本書があればどれだけ良かったかｗというのが正直な気持ちです。

本書の物足りないところがあるとすれば。。

個人的には以下の内容があればとても嬉しいと思いました。

• サーチ性能、インデクシング性能の指標、事例
• エンタープライズでの利用におけるシステムイメージ
• マルチコア、分散検索、レプリケーションの突っ込んだ話

要するに、ある程度の規模の実案件に投入する際に必要になるところの「イメージ」ですね。
ただこれらは本書『Apache Solr入門』の範囲を超える部分であり、
またそもそも基準が難しい部分であったり、要件によって変わってくる部分であったりしますので、
あくまで高望みですね。

現在上記のことを知りたければ、Solr勉強会の資料などからある程度つかめます。
そしてあとは自分で確認してみましょう。

まとめ

本書はSolrを使う全ての人にオススメできる良書だと思います。
本書がある場合とない場合で、Solrの習得にかかる時間も、その精度も、大きく変わってくるでしょう。
特に実務で使う方は必須ですね。
(本書に限らずですが)その効果を考えると、価格(\3,780)などは非常に安いものだと思います。

Solr使うなら必須。

そう言えば

洋書ですが、以下の書籍が結構前に出ていますね。
内容は見てないので分かりませんが。

リンク

未読ですが、関口さんも書いてるし、これ良いのかも。

こちらも必須といいたいがもしや絶版？

ソフトウェア技術者ならず、見積りをする全ての人にオススメしたい本。

見積もりにはアート(技法)としての見積もりとサイエンスとしての見積もりがあり、本書ではアートとしての見積もりに重きを置く、と書かれており、実際さまざまな見積もり技法について説明している。

その技法は、恐らく多くの見積もりをする人にとって、十分に役に立つものだと思う。
本書の188ページにある例を引用する。

例えば、6ヶ月のスケジュールがあったとしよう。あなたは、最初のマイルストーンを4週間で達成する計画を立てた。しかし、実際には6週間かかってしまった。この場合、あなたなら次のうちどれを選ぶだろうか。

• 失った2週間は、スケジュールの後の方で埋め合わせられると考える。
• スケジュールの合計の2週間を追加する。
• 誤差の大きさ(この場合は50%)をスケジュール全体に掛け合わせる。

もっともありがちなのは、1番目の選択肢だろう。通常は次のような論法になる。「要求にかける時間が予定より少し長かった。だが、もう要求は固まった。残りの時間を切り詰めよう。コーディングとテストの間で不足分を埋め合わせられるはずだ」。しかし、1991年に300以上のプロジェクトについて調査した結果によると、プロジェクトが一度失った時間を埋め合わせることは、まず不可能であることが分かっている。それどころか、遅れはさらに広がる傾向にある。したがって、この選択肢がベストチョイスなることは、ほとんどないと思ってよい。
(中略)
よほどの例外を除いて、実際の結果が見積もり通りにならない場合の正しい選択肢は、3番目ということになる。

これを読んで思わずにやりとしたり、あるいは過去の見積もりを思い出す人も多いだろう。
そういう人にもオススメしたい。

実際本書には小難しい(サイエンスよりの)議論も存在するが、最初にアート(技法)に重きを置くと書かれている通り、すぐに役に立つ技法が沢山のっている、いわば見積もり技法のカタログ集と言える。
第9章の1例を挙げると、1点見積もりは実際には「最良ケース」に近くなってしまうことから、次のような公式を提案している。

期待ケース = [最良ケース + (4 * 最有力ケース) + 最悪ケース] / 6

例えば自分で以下のように機能追加の見積もりをしてみる。

• 最良ケース=5人日
• 最悪ケース=20人日
• 最有力ケース=10人日

この場合、より確度の高い1点見積もりを出すために期待ケースの見積もりを出すとすれば、
期待ケース = [5 + (4 * 10) + 20] / 6 = 65/6 = 約11人日
となる。
なお実際にありがちなのは、最良ケース=5人日をそのまま採用してしまうケースだと思う。

※この辺りの「公式」をより正確に理解しようとすると、統計学的知識が必要になるようである。(分散とか標準偏差とか)
※下記はよい本らしい。

・見積もりとターゲットとコミットメントは違うものだ。
　・見積もりは分析的なプロセスであり、確率論的な考え方をする。
　・ターゲットは、実現したいビジネス上の目標。
　・コミットメントは、定義された機能を特定の品質レベルを確保しながら期日までに納品するという約束。
　・よって、コミットメントが見積もりよりも挑戦的だったり、保守的だったりすることが当然ある。
・見積もりと計画の関係
　・見積もりのゴールは正確性であり、特定の結果を追求することではない。
　・計画のコールは特定の結果の追求。
・見積もりがシングルポイントで示される(例: 14週間)場合、それは現実的なものではない。
　実際は見積もりの皮を被ったターゲットである。
・あらゆる見積もりは、確率が含まれている。確率を明示した見積もりは良い見積もり。
　16週以内で完成する確率は0%
　18週以内で完成する確率は10%
　20週以内で完成する確率は50%
　22週以内で完成する確率は75%
　24週以内で完成する確率は90%
・自分のコミットメントが幅のある見積もりの中のどこに位置するのかを把握し、それに応じた計画を立てる。
・見積もりは予言ではない。
・よい見積もりとは、プロジェクトの責任者がターゲットを達成するためのコントロールを行ううえで、適正な意志決定ができる明確な視点を提供する見積もり。
・常人が直感的なセンスで考える「90%確か」は、実際には「30%確か」にほぼ近い。
・見積もりの幅を狭くするプレッシャーを感じたら、それが本当に存在するのか確認すべし。
・多くのビジネスでは、見積もりの予測可能性を重視する。(短かったり、安かったり、というのは結果)
・ソフトウェア業界には過少見積もりの問題がある。まず見積もりを多くすることから始める必要がある。
・優れたプロジェクトマネージャーは、見積もり誤差が実際の20%以内にあれば、プロジェクト完了に向けてナビゲートできる。がそれを超えれば難しい。
・即興の見積もりは止めよう。
・見積もりに必要なのは過去のプロジェクトの見積もりと実績。
・開発者の見積もりは既に十分に楽観的に短くなっているため、削ってはいけない。
・アクティビティの見落としも考慮する。
・ソフトウェア開発では、多くの問題について何千もの意志決定をする必要があるプロセスである。そのためそれぞれの意志決定の不確実性がプロジェクトの不確実性を引き起こす。よって、プロジェクトの見積もりは、プロセスの進行に応じて「不確実性のコーン(円錐)」を形成することになる。
・コーンはひとりでには狭くならない。狭くするためにはプロジェクトコントロールが必要。
・ソフトウェア開発は規模の不経済が適用される。プロジェクトが大きくなればなるほど、効率は悪くなる。(失敗プロジェクトになる可能性も高い)
・1点見積もりは、最悪ケースの見積もりと最良ケースの見積もりのうちの最良ケースの見積もりに近い。

・その他多数…