リスト：ソフトウェア開発を楽しくするために を表示しています。（全 17 件）

驚くことに日本のソフトウェア業界にはレビューの価値を評価できずに、省略しても構わないとする文化が少なからずともあります。本書はしつこいくらいにレビューの必要性を説き、中でもインスペクションの有効性を強調しています。
私自身、ソフトウェア業界に従事して20年近くになりますが、レビューの必要性を痛感する一方です。会社にレビュー文化をいかに根付かせるか悩んでいる方にはうってつけの書籍ではないでしょうか。私は、自分の会社でこの本を配布し、レビューをソフトウェアシステム構築の重要なタスクのひとつであるということを認識させることに成功しました。（川久保智晴 / 2004-06-26）

レビューという言葉はコード・レビューの意味で使われることが多いようですが、最初の検討フェーズから各ステップでレビューを実施すれば大きな効果が得られると思います。
この本ではピアレビューをＣＭＭＩレベル３での実施アイテムとして提示していますが、企業としてのレベル３取得の動きとは関係なく実施できると思います。内容はなかなか実践的なので、読者自身が工夫することで自分のプロジェクトに応用できそうです。（横丁のおじさん / 2004-05-02）

ピアレビューとは「同僚による査読」であり、品質向上のためのツールのひとつ。この本はタイトル通りこの「ピアレビュー」をテーマにした1冊。その中でも「インスペクション」と呼ばれる公式レビューについての解説が厚い（第4章〜第9章）。公式レビューは、概要説明、準備、インスペクションミーティング、修正、フォローアップという5段階を踏み、モデレータや記録者、読み手という役割が必要となるが、それに見合う欠陥検出効果が見込めるという。実際には、プロジェクト計画において品質目標、規模などを考慮して公式レビューを取り入れるのかどうかを見極めることになるので、必ずしも公式レビューである必要はない。とはいえ、こういう手法を知っておくのはいいことだ。
第4章でも言及されているが、インスペクション（準備をしてミーティングによって欠陥を指摘する）がどれほどの効力があるかについては議論の余地があるようです。この本以外の書籍についてもあわせて読むことを薦めたい。たとえばソフトウェア・テストPRESS　vol.2でインスペクションについての記事が載っている。（softest / 2008-08-12）

内容は、レビュの重要性、効果が少々で、あとは、レビュを組織的に行うには？の説明です。
レビュ、インスペクション、ウォークスルーの違い、インスペクションの各種手法、インスペクションの準備、成果物、評価、陥りやすい失敗とその対策、効果を上げる方法等です。
インスペクションが中心に記述されています。ウォークスルー等については、違いが記載されている程度です。
手法そのものよりも、成果物や人の教育、体制、改善など、組織に導入するという点に重きが置かれている印象でした。
初心者にも、分かりやすく書いてありました。
また、厳密なインスペクションの実施に興味がある方には、参考になることがあると思います。（lemonerika / 2005-09-02）

この本はピアレビューを行う際の観点についての記載はないです。
残念。
みんなが悩んでいるところは、どうすればレビューで不具合を漏れなくガードできるかなんじゃないかな？こういった具体的なネタは会社固有のノウハウでなかなか外には出てこないのでしょうね。
プロセスについてはCMMIやPMBOK本のほうがいいかな！？（樹 / 2008-10-03）

　コンピュータを使おうとする人に対して、より自然で使い勝手の良い
ユーザーインターフェイスはどのように考案すればよいかということの
方法論を解説した本である。
　しかし、そういう目的でこの本に接しようとした人にとって、本書は
かなり使い勝手が悪い。章立ても素直でなければ、重複も多い。解説文
はあまりに冗長でお世辞にも読みやすいとはいえない。
　実践的であるというより、学術的、研究的。本書の性格を見極めないと
時間とお金の使い方に失敗する。
（ny / 2007-11-30）

ペーパープロトタイピングとしての手法はすごく納得のいくもので是非現場で使って欲しいし、使っていこうと思うが、本の書き方が冗長すぎてよむのがダルくなる
もっとエッセンスだけをまとめて書かれていればもっとよかった（timeserver / 2005-07-05）

本のなかで何を述べようとしているかのコンセプトはわかるのだけれど，実際に応用となると難しいし，煩雑すぎるような気がします．こういった手法が合っている人にはよいと思うのだけれど，こういった手法がスタンダードになり得るかと言えば疑問かな．（水稲農林100号 / 2006-03-23）

設計時UIをどう扱うかというのは永遠の課題のような気がする。
この本が指摘している通り、モックでもHTMLベースの画面が出てくると機能ではないところに議論が集中してしまい、結局何も決まらないということが多い。
この本で紹介しているように何も説明せずに機能をみせるのは良い方法かもしれないが、ペーパープロトタイプで果たしてどこまで効果があるかは未知数。
手書きが早いのは事実だが、枚数があったり複雑な動きを紙上で実現することの面倒さを考えると、小規模でも効果確認を実際にやってみたほうがよいだろう。
しかし、やってみる価値はありそうな気がする。（Turtle / 2008-03-02）

　筆者の カール・Ｅ・ウィーガーズ (Karl E. Wiegers) 博士 はEastman Kodak社で写真技術に関する研究やソフトウェア開発に18年間かかわり，現在は， Process Impact 社 を主宰して，ソフトウェア開発に関するコンサルテーション，講演，執筆などを行っている．
　本書は，1996年に出版され，ソフトウェア開発者向けの専門雑誌 Software Development Magazine 誌 の Productivity Award を受賞した話題作である．1996年の出版と聞くと内容が古いという印象があるかもしらないが，決してそんなことはない．流行の技術には殆ど左右されない本質的な内容である．
　私自身の経験では，この手の本では，「80%以上賛成」できるものは非常に少ないが，この本書は，その少ない例の一つだと言える．
　目新しい技術や，魔法のような手法ではなく，確実に効果があると知られているものについて，判り易い文章と豊富な参考資料とともに，うまくまとめている．
　原題は「Creating a Software Engineering Culture」であり，ソフトウェア工学のお作法を，単に技術としてではなく，文化ととらえている点が，本書と他のソフトウェア工学の本との大きな違いである．さらに，品質と，継続的な学習を重視している点が，とても良い．
　プロとしてソフトウェア開発に関わるすべての人，これからソフトウェアの道を歩もうとする人に，強くお勧めする．ソフトウェア開発技術者必読の一冊．（Dr. Jason / 2005-10-01）

物騒なタイトルを書いてしまったが、各章の最後に「文化を生かすもの」と「文化を殺すもの」の項目が記述してある。特に殺すものを読むと、自分の今までの経験の中でいくつかは当てはまるものを発見し苦笑いする人も多いのではないだろうか？そうした目でもう一度本文を読み直すと理解が深まると思う。
また、やはり各章末の「参考文献」と「補足資料」も役に立つ（日本語訳のない文献が多いのが残念だが、この書についている数行のコメントでもかなり雰囲気はつかめる）（キミノリ / 2006-03-23）

インスペクションとは上流工程からの成果物(機能仕様書、テスト仕様書など）に対して一定の判定基準を元に内容を精査するプロセスのことです。
ソフトウェア開発プロセスの品質改善とプロセス自体の改善を目指したものであり、そのために本書ではデータの収集と分析を非常に重んじています。
どちらかといえば形式的なところを重んじていますが、それによる問題も同時に取り上げています。
正直な感想としては、内容に重量級のボリュームがあり、すぐに実践できるかというと、「それは無理」と感じます。
何度か実経験を踏んだ上で、さらに何をどうしたらよいか考える再に、非常に示唆に富んだ提言がかかれていると思いました。
実際の成功例・失敗例などもリアルに書かれているので、インスペクションは成功すれば成果はすごいが、そんなに容易でもないということを分からせてくれます。
分量的な面から言っても、あまりイントロダクションとしてはふさわしくないです。
インスペクション初心者には Karl E. Wiegers の「ピアレビュー」と併読することを勧めます。
「ピアレビュー」は大変良い書物ですし、内容の割には薄い本なので初心者にはもってこいなのです。
その上で本書を読むことにより、インスペクションを実施していくための理論的基礎の強化ができると思います。（taka-m / 2005-11-08）

検査といわれればするのに、インスペクションといわれた途端にやる気がなくなる現場がある。なぜかはわからない。自己査定は許容水準だった。自分では、この点よりよくするつもりはありません。これ以上やると無駄が増え、改善を阻害しそうだと感じるからです。大規模組織で、大規模開発の場合と、小規模組織で、小規模開発の場合での違いがあるかどうかが課題だと考えています。
以下は自己査定の回答例です。
(1)　通常する
（２）通常する
（３）ときどき
（４）通常する
（５）ときどき
（６）ときどき
（７）通常する
（８）ときどき
（９）通常する
（１０）まったくしていない
（１１）通常する
（１２）通常する
（１３）通常する
（１４）通常する
（１５）ときどきする（kaizen / 2008-07-09）

ソフトウエア開発の現場では、今でもいろんな混乱がある。
■工期短縮のためには工数増が必要であるのも拘わらず、プロジェクト開始後に要件決定の遅れや納期の短縮要求をズルズルと受け入れてしまう。
■トップがその年に決めた目標(たとえば生産性向上５％)を達成するために、他の重要なメトリックスを悪化させてしまう。
この本の中では、ソフトウェア開発の分野では中核となるメトリックスは５つある（規模、工数、工期、品質、生産性）といい、６３００の実績データの分析、メトリックスの導入、注意事項について解説している。
全体を通して痛感するのは、何を測るか、それをどのようにフィードバックするか、こういうことを継続して考えていかないと５つのメトリックスを同時に改善していくことはできないということ。本書の中で引用されている、絶対温度で有名なケルビンの「計測できればコントロールできる」という言葉が強く印象に残ります。日本でも、ソフトウェア開発分野のプロセスエンジニアという職種が定着することが必要とも感じました。（yu-ji / 2006-09-13）

2000年までの6300件のデータをもとに、多くのグラフを用いて説明されており、非常に説得力があります。
概念的には、機能総量＝プロセス生産性×工数×開発時間で表すことができます。この関係からわかるように、工数と開発時間はトレードオフ関係にあり、開発時間を延ばせば工数が減ることになります。
従来の見積もりでは単に人月であり、開発時間を考慮していないため、正確に見積もれないことがわかります。（100人月：100人なら１ヶ月？１人なら100ヶ月？）
どんなに頑張っても（コスト・人を投入しても）これ以上早くは開発できないという最短開発期間が存在するというのも、目から鱗でした。無理ムリのスケジュールでの開発は、破綻することになります。
計測されたデータの分析結果が主になっているので、いざ実際に計測しようとすると、他の書籍などを調べる必要があるかとは思います。
5章と11章だけでも読む価値があるかと思います。（tkcjun / 2005-12-03）

ソフトウェアのプロマネ本の1つです。
ソフトウェアの開発を管理する上で、気を配らなければならないことが書いてあります。作者の長いソフトウェア業界での経験が凝縮されていて、その点は参考になります。
しかし、少し内容がふるいのが気になります。1980年代の前半の話などがよく引用されて出てきます。さすがに20年前の話をされても困ります。
で、トータルすると星３つ。（ユングベリ / 2008-12-21）

プログラムマネージャーとして働くことが多いため、どうやって円滑にプロジェクト、特にチームを率いていけるだろうかと考えていたころ出会った本です。
仕様書の書き方（なるべく面白く書く）、WindowsとUNIXの考え方の違い（これはすごく同意します）、ペーパープロトタイピング（この本でそういうUIデザインの技術があることをはじめて知った）、エクセルの共有機能を使ったスケジュール管理、テスタ（QA）を雇わないと大変、マーケティングの人間にプログラムマネージャーにしない、開発者の面接の仕方、などなど
この本に書いることは全部ためしている。
ぼくが以前はプログラマーであったので、ジョエルの開発者からの視点はすべてに納得がいきます。
でも、結局はビジネスの人はシステムをドラえもんが作っていると思っているんだろうなぁと良く感じる。
今のところ四次元ポケットを作れといわれていないのが救いか？（紅天太郎 / 2007-01-30）

メソドロジやプロセス、プロジェクトマネジメントなどを扱った書籍って、最近多いですね。そういう書籍って、読後に「結局現場で使えるのかなぁ」といったモワモワした感じが残りがちです。そういう本に飽きが来ている人に、この本をお勧めします。この本はソフトウェア開発にまつわる様々なことが書かれた著者のブログを集めたものですが、いろいろな「気付き」を与えてくれるだけでなく、内容がとても「地に足着いて」います。前述したモワモワ感が残りません。著者が現場で得た生きた経験に基づいているからだと思います。
また、訳書ですが、十分自然な日本語であり、とても読みやすいのも GOOD です。（rerun / 2006-02-20）

プロジェクト管理に関する45のエッセイを人気Webブログサイト「Joel on Software」から収録した本。多くの章は読み物として読んだが、中には実務で使いたいと思う方法や考え方を見つけられたのは収穫。一時有名になった「Joel Test」（プロジェクトを成功に導き、コードの質を高めるための指標）に始まり、仕様書の書き方、スケジュール管理、テスターの重要性、ペーパープロトタイピング、開発者の面接方法、チーム管理などなど、ユーモアたっぷりに、現実的ですぐ実践できる指針を示しているのがよい。ブログサイトでのQA集を最終章として収録。（鈴木純一 / 2007-09-29）

書かれている事にすごく共感が出来、そういう本は読んでいて楽しい。
たとえば、低レベルな事が高レベルなモノコトに対する理解や意志決定を支配するって事や、いいから仕様書書けとか、オープンソースに対するIBMのスタンスについてだとか、読んでいてすごく共感できる。
まぁ日経ソフトウェアだとか、ソフトウェアピープルだとか、＠ITとかばっか読んで、いったい僕は(私は)どんなふうにこれからソフトウェアを作っていけばいいのよって思っている、方法論中毒患者(かわいそうに)の方は読むと多少すっきりするかも。
（ishisaka / 2005-12-23）

Webサイトに公開したエッセイをまとめたものです。
内容は、仕様書はどうあるべきか、プログラミングに関するtips、人の採用やプログラミングチームのマネジメント、自分自身の仕事の方法、取組み方、IT業界の歴史や各社の戦略、競争に関する考察、以前にいたマイクロソフトの開発の様子などです。技術技術した話題は少なく、マネジメントやIT業界に関する話題が多かった気がします。
独立した話が４５個程度あり、順序もなく、興味のある内容だけ読めるようになっています。
アメリカと日本の違いなどもあり、「明日からそのまま使える」という本ではなかったですが、その考え方は、ソフトウェアプロダクトの生産現場やプログラミングチームを率いるときに、役に立つことが多い印象でした。
勉強のため、というより、読み物として、と思うと、楽しく読める本であると思います。（lemonerika / 2006-09-24）

　そもそも「情報デザイン」とは何だろうか？　本書ではそのような素朴な疑問に対して「論理的な裏付け」「実践例」「技術的なアプローチ」と大きく分類した上で、斯界の専門家がそれぞれの分野について解説する物だ。「情報デザイン」をいかにカテゴライズするかという哲学的な論考から、博物館での具体的なナビゲーション設計の実例実例、インタラクティブなコンピュータ技術の最新動向までと各論は幅が広い。このように、ある意味で散漫な内容は、最終章で編者が敢えて言うように「情報はデザインできない。デザインできるのは伝達のモードであり、情報の表現方法である」と言うことにも通じる。
　執筆した専門家が大勢いるように、自分にとって「情報デザイン」とはどのような意味を持つ言葉なのかを探って選び取ってさらに読み進めば良いのだと思う。
　個人的には実践例が一番面白く読めた。日常風景の中にある情報の可視化や、インタラクションについていかに考えるべきことが多いのか、ということがよく分かったが、情報デザインの設計意図に合わせて人間が行動するのかどうかという点は考察が少ないように思われた。（まる・ち / 2004-06-20）

他のレビュアーにもあるように、
雑多な寄せ集めという印象はぬぐえない。
リズ・サンダース、深澤直人、杉浦康平、・・・
「情報」+「デザイン」にまつわる仕事に携わる
著名な執筆人に目を奪われるが、内容はさほど濃くなく
さわり（サマリー）を見ている感。
例えるなら雑誌の特集記事的である。
逆にいうとそのレベルでの情報インデックスとしては
そこそこ充実しているともいえる。
取り上げてるジャンルとしては、
インターフェイス、インタラクション、デザイン構築、
コミニュケーションデザイン、・・・といった
本のタイトルに沿う「いかにも」なもの。
この本に出てくるキーワードでの
再検索、各論学習をするとよいだろう。（kurukuru / 2003-03-29）

取り扱われているのが必ずしも副題の「分かりやすさの設計」ばかりではなかったのがちょっと残念でした。ただ、多分野の事例を横断しているため、興味のそそられる内容も多く、それなりに楽しめる内容だったと思います。
ある感覚を別の感覚に置き換えたり、わかりにくい数値をより直感的に表すことなど、デザインの枠をちょっと超えた範囲での具体的な事例には個人的に興味をそそられました。筆者によっては論文の梗概のような印象を受けたものもありましたが、参考としてはどれも有意義なものではないでしょうか。（tayki / 2002-10-22）

「この書籍がそのものが情報デザインであり、インターフェイスという
見地に立って気を配った」と書かれていました。確かに、背の高さ、
紙の質感、レイアウトどれをとっても個性的な本です。
確かに情報量の多いページレイアウトではありますが、その分読みやす
さを若干犠牲にしている面もあるように感じました。
巻末にある「情報デザインを知るためのキーワード」解説、
「参考文献」はそれだけでも価値のある内容です。（チューリング / 2002-04-01）

　“分かりやすさの設計”とサブのタイトルにはあるが、情報デザインを語る語り手が一冊の本に何人もいるせいか、この書籍が言わんとする設計の方向性、及び趣旨が読み手に伝わり難いように感じられた。
　立場の違いが視点の違いを生んでしまっているように思える。それだけに、情報のデザインに対しての様々な持論にしても、各々の持論が束ねられていない印象があり、情報デザインという１つの情報をデザインすることがこの書籍には欠如しているような印象を受けた。（ / ）

ある道具をうまく使えなかったら、それはあなたのせいではなくて道具のデザインが悪いせいである。
この本の主張はこの1文に集約できる、と私は敢えて断定します。日常の道具である電灯のスイッチやドアのデザインを具体例に、使いやすくデザインするための原則が丁寧に説明されています。
実例はこのような日常の道具なのですが、ひとが使うためのものであれば誰にでも適用できる原則です。そして、世の中にはひとの使うためのものはたくさんあります。あなたの仕事や専門に照らして考えてみてください。「使いにくいのはデザインのせいである」と思える何かがあるのではないでしょうか。
私自身も、専門としている仕事にかかわる、しかしながら普通の意味の「道具」ではないところに関して、非常にこの本が参考になりました。読む前は思いもよらなかった収穫です。（こじま / 2003-10-28）

　全ての”ものづくり”する人にとって得ることが多い著書だと考えます。
　本書中、悪いデザインの例としてオフィスの電話を、良い例として自動車を取り上げています。
　きっとあなたのオフィスの電話にも、ピックアップや保留等の機能がついています。ぶ厚いマニュアルを読まないと機能の存在さえわからないだけです。
　これに対して自動車は、電話より機能が多い（エアコンやオーディオまである）のに、初めて乗る自動車でも、運転できると思います。
　この２つの差は、ユーザの勉強不足等が理由ではなく、商品のデザインに関係しているというのが本著者の主張であり、非常に参考になります。
　私も技術者のはしくれですが、今まで「マニュアルをきちんと書く」というのが最良であると教えられ自分でもそう考えていましたが、
　★マニュアルが無しで操作可能なように設計（デザイン）する★
が最良の道であることを知りました。（cxj01155 / 2003-08-26）

事例は確かに古いようですが、そのようなことは全く関係なく現在でも普通にあてはまるわかりやすいものでした。最近は建築でも工業デザインでも、わりと「シンプル」なものが多いように見えますが、「シンプル」=「何もない（少ない）」ようなことに錯覚しがちです。この本を読んで、アフォーダンスすら省いた「シンプル」が、外見だけでまかり通ってしまっている現状があることを再認識しました。
ユーザーと対象物との関係が明確にデザインされていることも、ものにとっては必要な機能なのだと思いました。この本を一通り読めば、単に「何もない（少ない）」のか、必要な機能を盛り込んだ上で本来的に「シンプル」なのか、デザインするときにも何かを選ぶときにも通用する基準が明確に持てます。（tayki / 2002-12-26）

この分野では、有名な書籍です。写真など見るとに少し古さを
感じる方もおられるようですが、内容的には普遍的、重要な
要素を多く含む優れたものです。その意味では、少し古典的
ではあるものの、アフォーダンス、ヒューマンインターフェイス、
情報デザインに関する必読書、名著であると考えます。（チューリング / 2002-04-02）

ずいぶん昔に友人に進められて、この本を読みましたが、いまだに思い出します。ソフトウエア技術者としてそれほどデザインを重視していませんでしたが、目から鱗が落ちました。 機能重視で、いろんな機能があればそのほうがいいじゃん、と考えている方にお勧めします。
ちょっとうろ覚えですが、モデルがユーザに分かることが重要であるというメッセージは印象に残っています。たとえばCDプレーヤで、CDにも再生や早送りのボタンに三角形が使われています。別段本当に巻いてるわけではないのに、です。これはテープレコーダというモデルを利用してCDプレーヤの操作方法をデザインしているというわけですね。そんな話があったと記憶しています。（ / ）

この本は、道具というものが、人が日常をうまく生活（賢くと呼んでいる）するのかをこれまで分かってきた認知科学や認知心理学からの視点を取り入れて解説している。
特に、人の認知活動に焦点を当てて、その認知活動から人の活動をうまくサポートできる道具とは、どのような特徴を持っているのか、様々な具体例を提示しながら説明しているところがおもしろい。また、人の認知活動を中心にしてよりその活動を支援するための道具を考えるときのヒントにもなると思う。道具のデザインをしているデザイナー、設計者から、人の認知活動を研究しているような認知科学者、教育実践者まで幅広い人におすすめします。（ / 2000-11-30）

「人を賢くする"道具”」とタイトルされているが、
”モノ””サービス”etc.幅広い対象に応用可能な内容である。
----
進むべき先を見つけにくい／見失いやすい　現代社会において、
人生という「一刹那」を満足させるための「快楽」にむけての"道具””モノ””サービス”という見方を私たちは安直にしてしまいがちだが、
（またそういう見方を考えるほうが、非常にラクなのだが）
この本は、
真に人類が進歩するに必要な（＝後世に継承していくべき）"道具””モノ””サービス”とは何か、という視点に関する、
大いなるヒントが得られるであろう一冊と感じた。
普段、世の中に折々に感じられる"閉塞感”が、
実は「人間とテクノロジーのあり方」（特にテクノロジーに対する人間の見方）
に起因する部分少なくないことにも、はっと気付かされる一冊。（岩田　祐一 / 2005-11-11）

この本は教科書です。
お手軽にユーザビリティの知識を得たい方は、他の本を買う事をおすすめします。
教科書として比較的読みやすく、実例も豊富にまとまっていますが、それでも本書の言い方をすれば「教科書としての実用性」を守るために少々読みにくい（ユーザビリティに欠ける）ものになっていることは否めません。それでも、本格的にユーザビリティについて学びたい方は読んでおく事をお奨めします。
この本の80%程度を理解できた時、あなたのユーザビリティ観は、「なんとなく使いやすい」などという曖昧なものではなく、しっかりと体系づけられた見方へと変わっている事でしょう。（Nothing=Nothink / 2004-02-23）

　泣く子も黙るノーマン・ニールセングループのニールセンですから、読んでおいて損はないだろうと思い読んでみました。多少古い本ですが、内容は決して色あせていません。技術と違い、「使いやすい」とか「わかりやすい」といった人の心の仕組みはなかなか変わるものではありません。
　この本では具体的にどういったテストがあるのかや、テストの時の注意点など良いシステムを開発する上で欠かせないポイントが書かれています。
おそらくデザイナの方はもちろん、プロジェクトの計画を立てる立場の方が読まれても良いと思います。きっと今までなかった次元から、どうすれば独りよがりなシステムにならないかという視点を与えてくれることでしょう。
　また、一つ一つの論理の積み重ねには、きちんと論文などから背景や裏づけを取ってありますので、筆者の誠意が感じられると思います。
　最後に技術系の本には定常的な問題である翻訳についてですが、わかりやすい日本語で翻訳されており、良くまとまっていると思います。（angelic / 2003-06-16）

全体的には認識しておくべき様々なポイントが
事例とともに示されているとはいえ、
ユーザビリティの定義として
・学習しやすさ
・効率性
・記憶しやすさ
・エラー発生率
・主観的満足度
とありますが、どうも私には
「学習しやすさ」と「効率性」と「記憶しやすさ」の違いが明確でありませんでした。
例えば「望んだ反応が得られる」という項目はどこに入るのでしょう。
定義は状況を網羅できているのでしょうか...
定義自体に疑問が残るので、
続きを読んで部分部分では納得したとしても
しっくりこないままでした。
そもそもこの本書自体が
あまりユーザビリティを意識した構成になっていないとも思います。
訳本だからでしょうか...（ / ）

ユーザビリティの概念や、起源、歴史から学べます。内容としては少し古い本ですが、ヒューリスティック評価法などの基礎を学べました。（mina / 2004-08-11）

「ユーザビリティ」
新世紀を迎えてからというもの、世間がやっとユーザビリティの重要性を認識し始めた。５年以上も前から研究している専門家たちは、胸をなでおろしていることだろう。
最近は、猫も杓子も、馬鹿な上司でも、使う単語。
しかし、果たして、
「日本語で誰にでもわかるように説明すると？」
という質問をされたときに、咄嗟に、正確に解答できる人間は、そのうちの何％だろう。
解答例（１０点満点採点）
ユーザインターフェースのことだよ。
→０点
とりあえずかっこよければいいんだよ！
→１点
ユーザにとってやさしいことだよ。
→５点　
ユーザビリティという単語を一言で説明することは、どうやら相当難しいみたい。。。それなら、お得意の小話をひとつ。
Ａさん「たとえば、あなたが使いやすい・使っていて楽しい・もっと使いたいと思うものって何？」
Ｂさん「自分の愛用茶碗！」
Ａさん「君の愛用茶碗って、僕も好きかな？」
Ｂさん「さあ？　私は好きだけど、あなたが好きかは知らないよ。」
Ａさん「けど、君が好きなんだから僕も好きかもしれないよね？」
Ｂさん「まあ、なんたって私の愛用茶碗だからね！」
実は、、、自分の好きなものを、他人と共有する、その手助けをしてくれるものなんですよ。なんと素敵なんでしょう！
素敵なだけじゃないですよ、便利で、人間にとってやさしいんですよ。（ちょっと意味不明、失礼）
あれっ、猫も杓子も・・・を増長してるのは私？（ぐう / 2002-10-04）

アフォーダンスについて生態心理学をやっている人に何回か概略を聞いたことはあったが、イマイチよくわからなかった。言わんとすること「情報は頭で処理するのではなく、すでに環境の中にある」ということになるんだろう。上手く泳げるということは、それだけ水の中にある私を泳がすアフォーダンスを上手に引き出しているという感じだ。このような喩えは今ではいくらでも浮かんでくるが、本書を読むまでは「かっちり」と理解したり、実感したりは出来ていなかった。実感してみると妙に世界が奥行きをもってひろがって感じます。
本書はアフォーダンス理論の創始者ギブソンの研究の歴史から、視覚の話におけるアフォーダンスの理論をとてもわかりやすく紐解いている。とても読みやすい小冊子で、よくここまで短い分量にエッセンスが整理されているものだと感嘆した。逆にいえば、この本は、最小の分量で、アフォーダンスの理論の本質を、ざっと理解させてくれると言えるだろう。現在進行形のギブソンの後継者達（ギブソニアン）の活動も概観しつつ、アフォーダンスという新しい「世界のとらえ方」を理解させてくれる。専門家の入門書としてだけでなく、一般への優れた啓蒙書にもなっている。なんら専門的背景知識がなくても、十分に引き込まれ、考えさせられ、ぱっと目が拓いた。
子供の頃から、パチンコ屋などの電光掲示で、個々は点滅をしているだけなのに、全体が帯状に移動しているように見えるのが不思議で不思議でよく凝視していた。その現象がファイ現象という名前で、まさにそれがギブソンが研究を始めたときに認知の科学で侃々諤々の議論の中心だったゲシュタルトの表象だと、この本で知った。また、人工知能研究におけるフレーム問題や、それを回避したＭＩＴのクリーチャー研究など、非常に学際的な話が、とてもわかりやすく、またブレークスルーしそうなワクワク感を感じた。
知的閉塞感を感じているような方は、是非読まれてみれば、何か発見があるように思います。
私はとても勇気づけられました。（keyquo / 2004-11-25）

知っている人には説明不要、日本における
アフォーダンス研究の第一人者佐々木正人氏による
アフォーダンス本の原点とも言えるバイブル。
ギブソンの開拓した認知心理学の新分野「アフォーダンス」
について、研究経緯を順に追う形で解説する。
ただ正直、入門書としてはあまりお奨めじゃない。
佐々木氏はその後数々のアフォーダンス本を出しており
その論点や切り口は非常に多彩。そういった本や
他の著書、あるいはD.A.ノーマンの狭義的アフォーダンスに
比べるとこの本はいささか堅苦しく読み辛い。
氏の文章も決して読み易くはないのでなおさらだ。
ただ、内容的には噛めば噛むほどに味が出るスルメのように
後から読み返してアフォーダンスの深遠さに何度も感心する。
他のアフォーダンス本と併読しながら、
そういったバイブル的な読み方をぜひして欲しい。（kurukuru / 2005-03-12）

アフォーダンスについて知りたいと思い、手始めにこの本を読んだ。
コンパクトな本なので、気負わずに手にとることができたとともに、
読み始めてみると、「アフォーダンス」の生みの親、ギブソンの既存
理論を崩していく、という研究人生にココロ打たれた。
また、読み進むにつれて、自分の視界に入ってくるもの、すべてが
情報なのか、自分のカラダはそういうふうに動くことになっているのか、
と新鮮な感動を覚えた。
アフォーダンス理論にたどりつくまでの背景もわかりやすく書いてあり
ますし、入門書としてオススメです。（らりほー / 2002-06-21）

「知覚する」ということの解明に一生涯をささげたギブソンの難解なアフォーダンス理論を平易なことばでわかり易く説明することを心がけながら書かれていることに好感が持てる。あえてアフォーダンスそのものに正面から切り込むことを巧妙に避けながら、その周辺領域をなぞることによってアフォーダンスの世界へ誘ってくれている。日本のアフォーダンス研究の第一人者である佐々木先生の巧妙な語り口に引き込まれてしまいます。入門書というには、あまりにも巧妙で完成度が高すぎます。脱帽！（水稲農林100号 / 2005-06-04）

アフォーダンスといえば本書というくらい、名著で
あると思います。参考文献に必ずといってよいほど
紹介される本です。アフォーダンスとは何か、その
歴から、原理までこの小さな本の中に入っています。
アフォーダンス最初の1冊として、人工知能、情報論、
デザイン、心理学などに興味のある方にお勧めします。（チューリング / 2002-04-07）

　プロブレムフレームとは、ソフトウェアの開発における問題を、分析するものといって良いだろう。問題を「解決」するという本は多数出ているが、このように問題そのものを検討するものは少ない。実際にソフトウェアの開発で問題に直面している人にはすぐに役立つだろう。今すぐ問題を抱えてない人でも、読んでおくと後で役に立ちそうである。
　さらに、本書で紹介している考え方は、ソフトウェア開発以外にも十分適用できるものである。紹介されている問題や著者の語り口が大変読みやすくわかりやすいため、エンジニア以外の人も興味を持って読めるだろう。ぜひ多くの人に読んでもらいたい本だ。（yoshik-y / 2006-06-01）

「最高のプレイヤーがいるチームが最高のチームだ」
「スキル不足をプロセスで穴埋めする事はできない」
「バスに乗っている一部の不適格者のために官僚的なプロセスを適用すると、適格者がバスから降りてしまう」
「問題に慌てて対応してしまうと、後で技術的な負債が増大していく」
プロジェクトマネジメントオフィスからではない、現場からのリアリズムあふれる直言。
近道なんてない。ただ当たり前の事を当たり前に地道にやっていこうという本。アジャイルとはかかれているが、アジャイルには限らないプロジェクト管理の基本。
あなたが抱えている問題に、あなたに代わって答えを出してくれるHow to本ではないが、あなたが自分で考える手助けをしてくれる筈。（0xdeadbeef / 2005-10-23）

自らが参画するプロジェクト、その成功は？
対場によって目指すゴールにギャップを感じ、プロジェクトマネジメントの難しさに直面された方も多いことと思います。
この本で語られる「アジャイルプロジェクトマネジメント(Agile Project Management)」とは、競争力のある製品により「変化を作り出す」こと
チームで「変化に対応する」ことこの両者が一体となり、「変化を味方につける」新しいマネジメントの考え方である
　と示されています。
実際に読まれて「なんだ。自分の判断は正しかった。」と感じる方も多いのではないでしょうか？
実は（生意気かもしれませんが）私も「やはり、間違っていなかった！」と感じた一人です。
もちろん、新たに学ぶことも多く、よい意味で考えさせられました。
ここで解説されるアプローチは、日本の現場にとても親和性のあるアプローチです。
チーム作りのポイント「や「毎日のミーティングでリズムを作る」効き目のある「意思決定の枠組み作り」など、
今すぐにでも実践できそうな考え方や行動のポイントがわかりやすく書かれています。
また、事例も多く盛り込まれています。
加えて、付録の「アジャイルプロジェクトマネジメント(APM)の体系」に本書籍内の関連ページが記載されて使いやすさを増しています。
プロジェクトのゴールに発注者、ユーザーの笑顔が見える。
チームのメンバーがプロジェクトを通して成長できる。
そんなゴールを目指す方々（ソフトウェアの開発者や、様々な業種のプロジェクトマネジャー）にお薦めの一冊です。
（ / 2005-08-23）

詳しく書かれているのでしょうが、内容からすると少し文章が長く辛かったです。
プロジェクトマネジャーの立場としてアジャイルを解説しているので、
顧客とのやり取りに重点をおいています。
特に参考になったのが、意志決定で「Win-Win」を重視するために、
激しい議論の中にも、お互いに信頼し合い、尊敬し合ったうえでの、
礼儀ある議論という言葉でした。
熱くなると、自分さえWinになればと考えてしまいますが、冷静になれる言葉でした。
（なか / 2008-09-17）

初版は１９８７年だから、もう２０年にもわたって読み継がれているソフトウェア開発者の「古典」である。著者のトム・デマルコは、８０年代後半から９０年代にかけて活躍したシステムコンサルタント。構造化技法のひとつである「デマルコ法」の考案者としても著名である。
ドッグイヤーとかマウスイヤーと呼ばれるほど進歩の早いこの業界にあって、本書がこれだけ長い間読者を魅了し続けるのは、まさに書名のとおり、ハードウェアでもなく、ソフトウェアでもなく、それを作る「人」に焦点をあてた論考だからであろう。
最近でこそ、コーチング理論やメンタルヘルスなど、ヒューマンリソースのケアが重要視されているが、当時、開発者のやる気や、生産性の高い作業環境、チームビルディングの重要性を正面から論じた本はこれ以外にはなかったと思う。
現場のソフトウェア開発者の視点に立って、管理者や会社側の不条理を追及するというスタンスなので、当時プログラマだった筆者は「わが意を得たり」と密かに喝采を送ったものだった。チームで回し読みしては「パーキンソンの法則」「スパゲッティディナー効果」「チーム殺し７つの秘訣」「黒服チームの伝説」などなど、議論白熱して終電を逃したことも懐かしい。
当時の仲間はいまや皆管理職になり、本書からは攻撃を受ける立場になった。今、第二版を読み返してみると必ずしも肯ける話ばかりではないが、それは単に立場が変わったというだけではなくて、きっと初心を忘れてしまっているからなのだろう。
というわけで、筆者にとって本書は、この業界に身を投じた当時の初心に立ち返るための大切な本であるが、もちろん若い方にも勧めたい。頭のかたい上司、理不尽な上司の下で働いている方なら、きっと溜飲が下がること請け合いである。（丁三 / 2006-06-17）

いかなる仕事も，それを実行する「人」にかかっている。このあたりまえのことをあたりまえと放置せず，「人」の仕事の質を上げる，または下げる要素について広く深く分析している。特に阻害要因についての記述は，組織で仕事をしている人ならば誰しもが頷け，自分の組織にこうなって欲しいと希望を持ち，
あるいは自分の組織のダメ具合に暗澹たる気持ちになるような内容である。経営者やリーダーたち全員に読んで，本書の示唆通り実行して欲しい本。多数の読者の声によって，そのために復刊されたのだから。（kasm / 2001-11-26）

1987年に出版された第1版にプラスして「ピープルウェアの小さな続編」を設けたこと、それと電子メール環境の繁栄により一部の記述を変更した形となって第2版が出ました。実は第1版は読んでいないのですが、記述されている「プロジェクトにおける人」について如何に振舞うか、扱うかの内容は今も15年前も変らないです。特にプロジェクトにおける管理者の役割についてはプロジェクトマネージメントの精神論的な内容に思えて、「ここまで人を大事にすべきか！」と思われるほどです。作業環境について一人あたりのスペースについても記述されていましたが、目に見えない効果をどこまで管理者層が納得して動けるか・・・というのは大きな課題です。
これまでの日本において欧米に追いつけ、追い越せで実施してきて戦後（そのときは皆中流階級）、そして日本が世界に到達したときに得た次なる目標、次なる仕事の仕方が見えなくなり、それとともにITによる世界的なデフレ化。そのために「人」も他と同じように頑張れば食べていけた時代から、何時の間にか360度評価、実績主義へと変貌したかと思ったら、次は「整理解雇」に意味が取って代わったリストラが台頭してきている現在を思うと、「ピープルウェア」は誰のために？と悲しくなったりします。
お互いの利益を超えた（というか利益を考えずにお互いの幸せを供する）仕組みが近いうち訪れるのではないのかと考えています。資本主義は競争社会であり、かつかけがえのない地球を蝕んできたことを徐々に多くの人が気づき、良い方向に向かおうと努力しているように思われます。そのときには「ピープルウェア」の真髄が随所に発揮される世の中になっているのではないでしょうか。
「人」について一番幸せな方法を皆で考えましょうと訴えてくれた大切な一冊になりました。（やんちゃ青 / 2002-07-02）

旧版とあわせて、折に触れて手に取ります。

・・・プロジェクト成功の鍵は、「技術」「プロセス」「人」の３つ。
ＩＴ技術者にとって「技術」は生命線ですが、
プロジェクトの円滑な推進には「プロセス」と、
そもそもの「人」・・感情を持つ人間の営み、組織論の理解が
十分条件になると再認識し、
チームのあり方や
自身の行言動を振り返ることしばしばです。（papillon / 2007-08-21）

謳い文句としてはソフトウェアプログラマーの管理手法とそのあり方についてのお話。
だが、管理という概念について非常に考えさせられる有益な本だと思う。
実験結果もあり、童話のようなものもあり、説得力も高い。
ただ、内容的には「デッドライン」と多くの部分がかぶっている。
気になったのが、後半部から訳が直訳になっていて、
日本語としてというか文章として成立してないと感じる部分が
非常に多く、翻訳ソフトを通した結果でも見ているかのような
文章になっていた。
「デッドライン」のほうは完璧に日本語に感じられたので残念。（んにゃ / 2004-11-27）

的確なカテゴライズ
インターフェイスは通常、全面が直接ユーザーに提示されるので、「使い易い」「使いにくい」「良い」「悪い」という全体的な結論はすぐ出るのだが、そこから先へ、理論的に分析を進めるのが難しい。
同時に色々な要素が絡まっているから、分析の論旨を整理するのが以外に難しい。
この本は、インターフェイスを構成する要素を、的確に分類して、イディオムという形でパターン化してまとめている。
的確な評価指針
インターフェイスをそのようなイディオムごとに分析すると、それぞれが十分にシンプルなので、明確に分析・評価し、結論を出せる。
それらの個々の議論を積み重ねてインターフェイスをデザインすれば、確実に「使い易い」「使える」インターフェイスを作ることが出来る。
この本は、そのようなインターフェイスの設計・評価に関わる指針を提供してくれる。
読んで損はない良書です。
（gankon / 2007-02-17）

ひとつひとつが真新しいものということではないが、この書籍の功績はこれらを体系化したことにある。
ただ、これを手にとって眺めるだけでは駄目。何度も繰り返して読み込み、自分のものにするべきだ。
その辺のWeb雑誌を読むのであれば、この書籍を見返したほうが有意義だ。（酔兎 / 2007-04-24）

あなたはamazonのページに対してどんな印象を持ちますか？どんなところが使いやすいと感じますか？
本書では上記の問いに対して、この部分はこの手法が用いられている、一方この部分にはこの手法が用いられているという答えを示してくれます。
提示されたもの（ユーザが操作可能な「インターフェース」だけでなく画像やテキストも含むため、あえて「提示されたもの」とします）に対してユーザが心理的にどう思うかまで掘り下げてパターンを説明しているため、デザイナだけでなく、ものを誰かに示す必要のある全ての人に読んでいただきたいと思いました。（さわだ / 2007-02-28）

本書は特にWEBデザイナーやサイト設計に関わる人向けに書かれたものではありません。
しかし、登場する多くのインタラクショナル･デザインのパターンが示唆する考え方には多くを得るところがあるかと思います。
序盤で「関係ないかな、自分には・・」と挫けそうになりますが、そういう人はきっと無理してでも読み進めると私のように最終章で繋がってくるはずです。
最後の参考資料のページに掲載されている多くの書籍は、この分野を研究している人なら一度は目にした事のあるものばかり。
つまりは、そこから抜粋された考え方の多くは本書を読むだけで理解できます。
東大のKALSが開発しているアプリケーションへもこの考え方、取り入れて欲しいです。（modame / 2008-03-20）

いわゆる「デザインパターン」を、ユーザインタフェースの分野で整理した本です。他のレビューにあるとおり、内容はとても良いと思います。
ただしクロスリファレンスは、最初、少し戸惑いました。他のパターンとの関係を説明する際に「第×章の○○○」という記述が出てくるのですが、ページ数どころかパターン番号（≒節番号）も書かれておらず、そのたびにページを探してイライラしました。
いくつか試してみた結果、巻頭の目次に戻って探すのが最も手軽で早いようです。私のようなクロスリファレンス重視の方は、目次にしおりを挟んでおくと良いのではないでしょうか（私は片っ端からページ数を書き込んでいきましたが…）。
（nagae / 2008-02-17）

難解なギブソンの生態心理学を初心者にもわかるように平易な言葉で記述しようとする著者の苦心が伝わってくるような労作である。ただ、やはりギブソン心理学は難解だなあと再確認してしまう契機を与えてくれもする。佐々木先生のアフォーダンス解説書と併読してみるとオーバーラップするところがかなりあるが、語り口が異なっているので、読者にとって理解しやすい方で理解を深めるといった読み方が良いのではないかと思う。ギブソン心理学の理解を深めるには、何冊かの本を併読をするのが一番の近道だと思います。（水稲農林100号 / 2005-06-21）