プログラマが知るべき97のこと

著者 : 夏目大

制作 : Kevlin Henney 

• オライリージャパン (2010年12月18日発売)

作品紹介・あらすじ

人々のさまざまな思いを技術で形にするプログラマ。本書は世界中で活躍するプログラマによる97本のエッセイを収録した書籍。プログラミングにおいてもっとも重要な事柄は何か、バージョン管理やテスティング、設計原則とコーディングテクニック、また腕を磨くための勉強法などについて、経験豊かなプログラマが自らの体験を踏まえて解説。プログラマを勇気づけ、新たな気づきをもたらす一冊である。日本語版では、小飼弾、関将俊、舘野祐一、まつもとゆきひろ、宮川達彦、森田創、吉岡弘隆、和田卓人による10本の書き下ろし収録。

感想・レビュー・書評

[ふもさんの感想 · 2011年8月20日]

ひとことふたことでまとめてみました。
http://d.hatena.ne.jp/fumokmm+tail/20110817/1313553630

この本は多くのプロのプログラマが提唱するTips集をまとめたものとなっています。１つ１つは短くシンプルにまとまっており、読みやすいので、読み始めるとついつい没頭してしまいます。

それぞれはテーマも対象もバラバラなのですが、自然とある程度まとまったプログラマ象が見えてくるのが面白いところだと思います。

ここに記されている97＋αのことをすべて実際に実行するのは難しいですが、少しずつでも実行してゆけたらきっと、プロのプログラマに近づいてゆけるのだと思います。

すべてのプログラマ必携の１冊だと思います。プログラマを名乗るあなたはぜひ一読してみてください。

[jun1106さんの感想 · 2012年9月3日]

・みられて恥ずかしいデータは使わないこと
・プロのプログラマは自分の仕事に責任をもつ

[akiyama924さんの感想 · 2012年4月30日]

書名から「き97のこ」の部分をとりだして、「97きのこ本」という愛称がついています。
そのルールに基づくなら姉妹本の『ソフトウェアアーキテクトが知るべき97のこと』も「97きのこ本」になるのですが、こちらは特にそのようには呼ばれてはいないようです。

原著の73人のプログラマによる97本のエッセイに加えて、日本人プログラマ8人（小飼弾、関将俊、舘野祐一、まつもとゆきひろ、宮川達彦、森田創、吉岡弘隆、和田卓人）による書き下ろしの10本のエッセイが追加され合計107本のエッセイ集になっています。

エッセイ1本は2ページのものが中心なので電車の中などでも気軽に読むことができます。

テストを話題にしたものも、タイトルだけでも、8本あります（本書中にある分類では14本になっていました）。

　テスト担当者はプログラマの友人
　偶然の仕様ではなく本物の仕様のためのテストを書く
　テストは夜間と週末に
　テストのないソフトウェア開発はあり得ない
　プログラマとテスターが協力してできること
　コードを見る人のためにテストを書く
　テストは正確に、具体的に
　不具合にテストを書いて立ち向かう

全体的にそれぞれのプログラマ達の経験からのアドバイスが多く好感が持てます。

★★★

本書を読んで初めて知った言葉に「フロー」いうものがあります。
次の文章は、『95　ペアプログラミングと「フロー」』の出だしです。
　何かに完全に没頭している時──夢中で何かをしていて、時間が経つのも忘れてしまっているとき──それはきっと人間にとって幸せな状態です。その状態は「フロー状態」と呼ばれます。

「フロー状態」にすっと入っていけること、また、「フロー状態」を維持できることができたら品質や生産性は格段に上がると思います。

自分自身の事を振り返っても、会社でテストツールのプログラムを書いていたときは、誰もいないときか、みんなが帰った夜中に書いていました。
本、論文、原稿、プレゼン資料を作るときにも、10時間のうち、8時間は題材を考えていたり、資料を集めていたり、テキストエディタに目次と構成をタブで作っていたりして、実際に書くのは2時間というパターンが多いです。その集中して何かをしている時が「フロー状態」なんだろうなと思います。

ソフトウェアの見積りが難しいのも「フロー状態」の自分で工数を見積もってしまうからかなぁと思いました。
ところで、私の場合、「フロー状態」に入るために、

　・ 甘いコーヒーを飲み、チョコレートを食べる
　・ 机の上を片付ける
　・ メールを読み、返信し尽くす

という儀式が必要です。こういった儀式を集めたら面白かもしれませんね。

[nuttiさんの感想 · 2012年4月22日]

プログラマに対して、ソフトウェア開発やプログラミングを行う上で気をつけた方が良いことを、97+10(日本人によるもの)=107項目に分けて紹介している。
プログラムを書き始めたばかりのプログラマだけでなく、ソフト開発で重要なことを再認識するという意味で、熟練者やプロジェクトマネージャーなどIT業界で働く人も読む価値があるだろう。

各項目では、今まで数多くソフトウェアの開発に携わってきた人が、それぞれ最も重要であることを伝えようとしている。
そのため、項目間では相反するところもいくつか見られた。
しかし、いずれも間違いではないので、ここに書いてことは、参考するにとどめて、最終的には自分なりに重要な項目を作ると良いかもしれない。

通常の目次に加え、ジャンル別に目次が作られていて、とても親切であるように感じられるが、最初からジャンル別で構成しておけば、さらに良かったのではないかと思う。

[momontyoさんの感想 · 2011年9月3日]

職場で一度読み、自宅でもう一度読んだ。
およそ100人の職業プログラマによる意見なので
それぞれが準名言、準格言のようなものである。

全て通すと身になるとは思うが、
いかんせん、一つのテーマが2ページにまとめられており、
内容にも順序性がないので、
純粋に力をつけたいなら専門書のほうが良いと思う。

職について暫くたって仕事にも慣れ
　「最近進歩が無いな」
と思ったような、師に恵まれない駆け出しプログラマのスキルアップのきっかけとしておすすめ。

[fukayanegiさんの感想 · 2011年5月19日]

自動テスト、リファクタリング、向上心など、技術的な知見というよりは、プログラマとしての心構え、基本的な取組み姿勢を多数の著名プログラマがコラム形式で語っている。

それぞれの書き手が自由に発言しているので、冗長だったり矛盾していたりするところもあるが、概ねあるべき姿の核となる部分を語ってくれていると思う。現実のプロジェクトではつい面倒くさがれ野放しにされがちなところについて「やっぱりしっかりやらねければいけない」と思わせてくれる。

読んでいるうちに早く会社にいって現状に対する対応に取り組みたくなるような一冊だった。

[kaorun55さんの感想 · 2011年1月25日]

プログラマが知るべき97のこと(97きのこ)読みました #97prog_ja
http://d.hatena.ne.jp/kaorun55/20110123/1295794109

[yoruさんの感想 · 2024年1月5日]

優れたエンジニアたちのエッセイを97（+α）本、集めた書籍。ネット公開されている内容だが、書籍ではRubyのまつもとさんや、TDDの和田さん、Rebuild.fmの宮川さんなど、著名な日本エンジニア寄稿分がある。
まつもとさんの、「名前重要：適切な名前が付けられる機能は正しく理解・設計されているということであり、そうでないものは果たすべき役割を理解されていないことが多い」などは確かに、と共感した。
それぞれが大事とするテーマが多岐に渡って紹介されるため、これからの学びのきっかけになり、特に初学者向けに良いと感じた。

[Yuichi Takeuchiさんの感想 · 2022年6月7日]

心がけるべきことを読み物として楽しめる本でした
いろんな見方があるので、絶対的に正しい！というものではありません
たまにぱらっと適当なページを開いて眺めるのもよいでしょう

[別府さんの感想 · 2022年5月19日]

【メモランダム】
・日本語訳も公開されている。
　□非公式サイト
[https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/]
　□ウィキソース
[https://ja.wikisource.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%8C%E7%9F%A5%E3%82%8B%E3%81%B9%E3%81%8D97%E3%81%AE%E3%81%93%E3%81%A8]

【書誌情報】
原書：97 Things Every Programmer Should Know
編者：Kevlin Henney
監修：和田卓人　
訳者：夏目 大
発行：2010年12月
頁数：276ページ
ISBN：978-4-87311-479-8
定価：2,090円
https://www.oreilly.co.jp/books/9784873114798/


【目次】
監修者まえがき
はじめに

01 分別のある行動
セブ・ローズ（Seb Rose）
02 関数型プログラミングを学ぶことの重要性
エドワード・ガーソン（Edward Garson）
03 ユーザが何をするかを観察する（あなたはユーザではない）
ジャイルズ・カルバン（Giles Colborne）
04 コーディング規約を自動化する
フィリップ・ヴァン・ラーネン（Filip van Laenen）
05 美はシンプルさに宿る
ヨルン・オルムハイム（Jorn Olmheim）
06 リファクタリングの際に注意すべきこと
ラジット・アタパトゥー（Rajith Attapattu）
07 共有は慎重に
ウディ・ダーハン（Udi Dahan）
08 ボーイスカウト・ルール
ロバート・C・マーティン（Robert C. Martin　アンクル・ボブ）
09 他人よりまず自分を疑う
アラン・ケリー（Allan Kelly）
10 ツールの選択は慎重に
ジョヴァンニ・アスプローニ（Giovanni Asproni）
11 ドメインの言葉を使ったコード
ダン・ノース（Dan North）
12 コードは設計である
ライアン・ブラッシュ（Ryan Brush）
13 コードレイアウトの重要性
スティーブ・フリーマン（Steve Freeman）
14 コードレビュー
マティアス・カールソン（Mattias Karlsson）
15 コードの論理的検証
イェッチェル・キムチ（Yechiel Kimchi）
16 コメントについてのコメント
カル・エヴァンス（Cal Evans）
17 コードに書けないことのみをコメントにする
ケブリン・ヘニー（Kevlin Henney）
18 学び続ける姿勢
クリント・シャンク（Clint Shank）
19 誰にとっての「利便性」か
グレゴー・ホーぺ（Gregor Hohpe）
20 すばやくデプロイ、こまめにデプロイ
スティーブ・P・バーチャック（Steve Berczuk）
21 技術的例外とビジネス例外を明確に区別する
ダン・バーグ・ヨーンソン（Dan Bergh Johnsson）
22 1万時間の訓練
ジョン・ジャガー（Jon Jagger）
23 ドメイン特化言語
マイケル・フンガー（Michael Hunger）
24 変更を恐れない
マイク・ルイス（Mike Lewis）
25 見られて恥ずかしいデータは使わないこと
ロッド・ベグビー（Rod Begbie）
26 言語だけでなく文化も学ぶ
アンダース・ノラス（Anders Noras）
27 死ぬはずのプログラムを無理に生かしておいてはいけない
ヴェリティ・ストブ（Verity Stob）
28 「魔法」に頼りすぎてはいけない
アラン・グリフィス（Alan Griffiths）
29 DRY原則
スティーブ・スミス（Steve Smith）
30 そのコードに触れてはならない！
カル・エヴァンス（Cal Evans）
31 状態だけでなく「ふるまい」もカプセル化する
アイナー・ランドル（Einar Landre）
32 浮動小数点数は実数ではない
チャック・アリソン（Chuck Allison）
33 オープンソースプロジェクトで夢を実現する
リチャード・モンソンヘーフェル（Richard Monson-Haefel）
34 API設計の黄金律
マイケル・フェザーズ（Michael Feathers）
35 超人の神話
ライアン・ブラッシュ（Ryan Brush）
36 ハードワークは報われない
オルヴ・モーダル（Olve Maudal）
37 バグレポートの使い方
マット・ドーア（Matt Doar）
38 余分なコードは決して書かない
ピート・グッドリフ（Pete Goodliffe）
39 最初が肝心
マーカス・ベイカー（Marcus Baker）
40 プロセス間通信とアプリケーションの応答時間の関係
ランディ・スタッフォード（Randy Stafford）
41 無駄な警告を排除する
ヨハンネス・ブロドワル（Johannes Brodwall）
42 コマンドラインツールを使う
キャロル・ロビンソン（Carroll Robinson）
43 プログラミング言語は複数習得すべき
ラッセル・ワインダー（Russel Winder）
44 IDEを知る
ハインツ・カブーズ（Heinz Kabutz）
45 限界を知る
グレッグ・コルヴィン（Greg Colvin）
46 すべきことは常に明確に
ダン・バーグ・ヨーンソン（Dan Bergh Johnsson）
47 大量のデータはデータベースで
ディオミディス・スピネリス（Diomidis Spinellis）
48 いろいろな言葉を学ぶ
クラウス・マルカルド（Klaus Marquardt）
49 見積りとは何か
ジョヴァンニ・アスプローニ（Giovanni Asproni）
50 Hello, Worldから始めよう
トーマス・ゲスト（Thomas Guest）
51 プロジェクト自身にしゃべらせる
ダニエル・リンドナー（Daniel Lindner）
52 「その場しのぎ」が長生きしてしまう
クラウス・マルカルド（Klaus Marquardt）
53 正しい使い方を簡単に、誤った使い方を困難に
スコット・マイヤーズ（Scott Meyers）
54 見えないものを見えるように
ジョン・ジャガー（Jon Jagger）
55 並行処理に有効なメッセージパッシング
ラッセル・ワインダー（Russel Winder）
56 未来へのメッセージ
リンダ・ライジング（Linda Rising）
57 ポリモーフィズムの利用機会を見逃さない
カーク・ペパーディーン（Kirk Pepperdine）
58 テスト担当者はプログラマの友人
バーク・ハフネーゲル（Burk Hufnagel）
59 バイナリは常に1つ
スティーブ・フリーマン（Steve Freeman）
60 真実を語るはコードのみ
ピーター・ゾンメルラード（Peter Sommerlad）
61 ビルドをおろそかにしない
スティーブ・P・バーチャック（Steve Berczuk）
62 プリミティブ型よりドメイン固有の型を
アイナー・ランドル（Einar Landre）
63 ユーザの操作ミスを防止する
ジャイルズ・カルバン（Giles Colborne）
64 プロのプログラマとは？
ロバート・C・マーティン（Robert C. Martin　アンクル・ボブ）
65 バージョン管理システムを有効に使う
ディオミディス・スピネリス（Diomidis Spinellis）
66 いったんコンピュータから離れてみる
バーク・ハフネーゲル（Burk Hufnagel）
67 コードを読む
カリアンヌ・バルク（Karianne Berg）
68 「人間」を知る
ケース・ブレイスウェイト（Keith Braithwaite）
69 車輪の再発明の効用
ジェイソン・P・セージ（Jason P. Sage）
70 シングルトンパターンの誘惑に負けない
サム・サーリスト（Sam Saariste）
71 パフォーマンスへの道は地雷コードで敷き詰められている
カーク・ペパーディーン（Kirk Pepperdine）
72 シンプルさは捨てることによって得られる
ポール・W・ホーマー（Paul W. Homer）
73 単一責任原則
ロバート・C・マーティン（Robert C. Martin　アンクル・ボブ）
74 「イエス」から始める
アレックス・ミラー（Alex Miller）
75 面倒でも自動化できることは自動化する
ケイ・ホルストマン（Cay Horstmann）
76 コード分析ツールを利用する
サラ・マウント（Sarah Mount）
77 偶然の仕様ではなく本物の仕様のためのテストを書く
ケブリン・ヘニー（Kevlin Henney）
78 テストは夜間と週末に
ラジット・アタパトゥー（Rajith Attapattu）
79 テストのないソフトウェア開発はあり得ない
ニール・フォード（Neal Ford）
80 1人より2人
エイドリアン・ワイブル（Adrian Wible）
81 エラーがエラーを相殺してしまう
アラン・ケリー（Allan Kelly）
82 他者への思いやりを意識したコーディング
アスラム・カーン（Aslam Khan）
83 UNIXツールを友にする
ディオミディス・スピネリス（Diomidis Spinellis）
84 正しいアルゴリズムとデータ構造を選ぶ
ヤン・クリチアン・"JC"・ヴァン・ウィンケル（Jan Christiaan “JC” van Winkel）
85 冗長なログは眠りを妨げる
ヨハンネス・ブロドワル（Johannes Brodwall）
86 WETなシステムはボトルネックが見つかりにくい
カーク・ペパーディーン（Kirk Pepperdine）
87 プログラマとテスターが協力してできること
ジャネット・グレゴリー（Janet Gregory）
88 コードは生涯サポートするつもりで書く
ユーリー・ズバリョフ（Yuriy Zubarev）
89 関数の「サイズ」を小さくする
ケース・ブレイスウェイト（Keith Braithwaite）
90 コードを見る人のためにテストを書く
ジェラルド・メサローシュ（Gerard Meszaros）
91 良いプログラマになるには
ピート・グッドリフ（Pete Goodliffe）
92 顧客の言葉はそのまま受け取らない
ネイト・ジャクソン（Nate Jackson）
93 エラーを無視するな
ピート・グッドリフ（Pete Goodliffe）
94 リンカは魔法のプログラムではない
ウォルター・ブライト（Walter Bright）
95 ペアプログラミングと「フロー」
グドニー・ハウクネス（Gudny Hauknes）、カリ・ロスランド（Kari Rossland）、
アン・カトリン・ガナット（Ann Katrin Gagnat）
96 テストは正確に、具体的に
ケブリン・ヘニー（Kevlin Henney）
97 ステートに注目する
ニクラス・ニルソン（Niclas Nilsson）

日本人プログラマによる知っておくべき10のこと

01 命を吹き込む魔法
森田 創
02 ロールプレイングゲーム
関 将俊
03 ルーチンワークをフローのきっかけに
宮川 達彦
04 プログラマが持つべき3つのスキル
吉岡 弘隆
05 快適な環境を追求する
舘野 祐一
06 見知らぬ人ともうまくやるには
小飼 弾
07 不具合にテストを書いて立ち向かう
和田 卓人
08 育ちのよいコード
森田 創
09 Noといえることの大事さ
宮川 達彦
10 名前重要
まつもと ゆきひろ

寄稿者紹介

[bob-taniさんの感想 · 2022年4月2日]

今も通用するシンプルな教え。
根本的に変わらない考えは素直に試すと良い。至言。

[mkskさんの感想 · 2022年2月12日]

先日とあるイベントで登壇したt_wadaさんが紹介していたので読んでみた。
第一線で戦うプログラマーは意識を高いところに置いてるんだなと感じた。
コードに対して、チームに対して、そして顧客に対して責任を持って仕事をしていた。
テストと自動化について言及している人が多かったので、その重要性を再確認した。
何度も読み返してわたしも高い視点でコードに向かえるようにしよう。

[ikuwowさんの感想 · 2021年7月31日]

テストの大切さが印象に強く残る。ピンときたものもそうでなかったものもある。しばらくして読み直すとまた新しいものが見えてくるかも。

[ののさんの感想 · 2021年7月23日]

ざっと斜め読み。開発者の心理を理解出来たとは思わないが参考にはなったと思う。

[air1さんの感想 · 2020年7月13日]

「優秀なプログラマとは？」
ひとりひとり答えは違うが、それで良い。
自分にとって正解だと思えるものに近づけるならそれで良い。

[january108さんの感想 · 2020年6月7日]

「「イエス」から始める」とか、「・・・本物の仕様のためのテストを書く」とか、姿勢に対するエッセイもあり、ハッとした

[全ての本さんの感想 · 2020年3月22日]

ためになったな〜というよりは、楽しかった〜という感想。まわりにこういう話ができる人がいないからか。取り入れようと思う内容は多くはないが。自分としては、もっと突っ込んだ内容のもの、最新の内容のものが読みたい。

[senookenさんの感想 · 2020年2月15日]

# 書評☆3: プログラマが知るべき97のこと | 薄く広い知見が収録されたプログラマーの教養本

## 概要
- 書名: プログラマが知るべき97のこと
- 副題:
- 著者: 和田 卓人 and Kevlin Henney and 夏目 大
- 出版日: 2010-12-10
- 読了日: 2020-02-14 Fri
- 評価: ☆3
- URL: https://book.senooken.jp/post/2020/02/20/

## 評価
ときどき紹介されていて気になったので読んでみた。

内容としては，73人のプログラマーによる97本のエッセイと，日本人プログラマー8人による10本の合計81人による107本のエッセイが掲載されている。

エッセイといっても，題名通りプログラマーのためのものであり，「達人プログラマー」のように，他の本で書かれているような開発上のコツなども書かれていた。

エッセイ集になっているのもあり，ややとりとめもなく，1-2ページ程度で話が終わってしまい，薄くて浅い教養本な感じがしてしまった。

教養として読むのは悪くないのだが，本書で引用されているような本をあたったほうが勉強になるように感じてしまった。

## 結論
プログラマーの教養本だった。他の本で書かれているような内容が断片的に書かれており，教養本の通り，薄くて広い知見が得られる本だった。

ただ，個人的にはどこかできいたことのあるような話が浅く書かれており，少々物足りなかった。

けっこうテストが大事とか書かれているのだが，いうのは簡単だが今までやったこともなく，周りで誰もやっていないものを習得するのはなかなかたいへんだ。

[梟さんの感想 · 2019年7月10日]

まさにタイトル通りの内容なのだけど、
良くも悪くも様々な視点での様々な粒度で語られている。

[地下アイドルさんの感想 · 2019年5月5日]

原書と比べると、日本人プログラマの部分が加筆されている

[名古屋大学理学図書室さんの感想 · 2019年4月16日]

有名プログラマーによる97本のエッセイから基本を学ぶ。。原著も併せて受入。理図書 007.64||H52 12038749

[dekadannaさんの感想 · 2018年11月12日]

世界を代表するプログラマのショートエッセイ集。示唆に富む一言そうでもない一言とバラエティに富む。引っかかるか、引っかからないかは、今の自分の実力や興味を示しているのであろう。

・仕事には長い時間をかけず、集中して短い時間で終わらせるように心がける。より効率的な問題解決方法を探す努力を常にする。プロジェクトに貢献するということはそういうことです。
・良いインターフェースとは正しく使用するほうがミスするより簡単。謝った使い方をすることが困難。
・問題が起きたときだけエラーログをとる。
・ソフトウェア設計のアプローチとしてまず、名前から入るのがお勧め。

[ichiro.marinersさんの感想 · 2018年10月23日]

いろいろな人がそれぞれの思いを書いているため、いまひとつまとまりがない気がするが、それでも非常に重要なソフト開発思想がこの本にはある。おっさんが読んでもあまり役には立たないと思うが、若いプログラマーにはぜひ読んでもらいたい。

[yoshio2018さんの感想 · 2018年10月11日]

プログラマーの提言。コーディング、テスト、プロジェクト管理、人間関係、等々。みんなプログラマーに誇りを持っていることがよくわかる。

[休日は読書さんの感想 · 2018年10月9日]

正直、どうだろう…

[hayato_1980さんの感想 · 2018年10月7日]

今の自分に入ってきたのをピックアップすると、この４本。魔法に頼りすぎてはいけない/オープンソースプロジェクトで夢を実現する/すべきことは常に明確に/未来へのメッセージ

[ひらっちさんの感想 · 2018年9月17日]

何度でも読み返したい。

世界中に熱意あるプログラマがいるということ。
超一流のプログラマも、私の周りと同じく十人十色の人柄だということ。細かい・破天荒・溌剌・女性・ナード・上滑り。

誇りある一言一言が、私を勇気付けてくれた。
このままじゃダメだし、このままでいいんだと。

[dora-gtさんの感想 · 2018年6月23日]

「ちょっと基礎の振り返りをしてみるか」程度の気持ちで読み始めたが、思ったよりも勉強になる事があり、読んでよかったなと感じた。

[laysakuraさんの感想 · 2018年3月10日]

良い話が多くて刺激になった記憶

[iked_TDSGさんの感想 · 2018年1月31日]

ソフトフェア開発において、色々な名著があると思いますが、そういった個々の深い本に行く前に読んでおく下準備としても良い本かなと勝手に思いました。
この本を読んでからコーディングの意識は全然変わってきたのでめっちゃいい本だと思います！
この流れで「達人プログラマ」や「リーダブルコード」とかを読み進めたいと思います。

著者プロフィール

1966年、大阪府生まれ。同志社大学文学部卒業。翻訳家。訳書にゴドフリー゠スミス『タコの心身問題』（みすず書房）、グリック『タイムトラベル』（柏書房）、コステロ『エルヴィス・コステロ自伝』（亜紀書房）など多数。

「2023年 『シカゴ・ソウルはどう世界を変えたのか』 で使われていた紹介文から引用しています。」