人はミスをする。これは当たり前のことだ。 だからミスしないように準備をするし、仮にミスしたとしても、トラブルにならないように防護策を立てておく。人命に関わるような重大なトラブルになるのであれば、対策は何重にもなるだろう。 個人的なミスが、ただ一つの「原因→結果」として重大な事故に直結したなら分かりやすいが、現実としてありえない。ミスを事故に至らしめた連鎖や、それを生み出した背景を無視して、「個人」を糾弾することは公正なのか？ 例えば、米国における医療ミスによる死亡者数は、年間40万人以上と推計されている（※1）。イギリスでは年間3万4千人もの患者がヒューマンエラーによって死亡している(※2）。 回避できたにもかかわらず死亡させた原因として、誤診や投薬ミス、手術中の外傷、手術部位の取り違え、輸血ミス、術後合併症など多岐にわたる。数字だけで見るならば、米国の三大死因は、「心疾患」「がん」そして

例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場

たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。 そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。 すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。 天下りマネージャーが馬鹿なのは、なぜバグを管理するかを理解していないからだ。 なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい（反対に、テスト項目は消化しているのに、バグが出ないと、テストの品質を疑ってみる）。バグの出具

余命、数週間。不自由な体、満足に歩くこともできない。日中も寝ている時間が多くなり、頭もうまくはたらかない ──そんな人生の最終章の人に向かって、こう問いかける。 いま、後悔していることは、何ですか？ 「死ぬときに後悔すること25」の著者は、終末期における緩和医療に携わる医師。現場で見聞した、「余命いくばくもない状態で、後悔すること」をまとめたのが本書なのだ。得られた答えは、多様でいて一様だし、複雑なようで単純だったりする。 もうすぐ自分が死ぬと分かっている人が、何を悔いているのか。これを知ることで、わたしの人生で同じ後悔をせずにすむのだろうか。考え考え読んで、いくつかの「先立つ後悔」を得ることができた。後悔は後からしかできないものだが、これはわたしにとって「先悔」となるものを、ランキング形式でご紹介。本書では25章に分かれているが、わたし流にベスト10に絞ってみた。 第10位　健康を大切に

「だまされた」と思わせずに大衆を騙すテクニックがわんさと紹介されている。 広告・政治宣伝のからくりを見抜くスゴ本。コマーシャルで衝動買いしたり、連呼されるワンフレーズ・ポリティクスに洗脳されることはなくなるだろう。マスメディアの欺瞞を意識している方なら自明のことばかりかもしれないが、それでも、ここまで網羅され研究し尽くされているものはない。 もちろん、チャルディーニの「影響力の武器」と激しくカブってる。その研究成果が幾度も引用されており、暗黙のお返しを求める返報性の罠や、小さなものから大きなコミットメントを求める一貫性の自縄自縛のテクニックなんて、そのまんまだ。 しかし、破壊力が違う。「影響力の武器」を一言であらわすならば、「相手にYesといわせる」ことを目的としているが、本書はそれに加えて「相手を説得し、積極的に賛同させる」ことがテーマなのだ。さらに、一人ふたりではなく、大衆レベルで実現

知でやり込めれば腹立てる。情で迫ると無視される。正論通すと逆ギレだ。兎角オンナは扱いにくい。 ケッコンして何年も経てば、ちっとはオンナを分かった気になれる。 しかし、それはあくまで「分かった気分」だけ。「オンナを理解するなんざ、10万年早いわ！」とか、「生物的に似ているだけで、しょせん違う生き物なのさ…」なんて割り切りたくなる。男脳・女脳とか全部遺伝子のファンタジーにするとラクだもん。 だが断る。 このわたしが最も好きな事のひとつは自分で分からないと思っていることを「知る」ことだから。オンナが大好きだから、理解したい、ちょっとでも近づきたい。何を考えてるのか、知りたい。言葉にするとヘンタイじみているけど、いえいえマジメな知的好奇心ですぞ。 というわけで、オンナの取扱説明書となる7冊をご紹介ー ■ S4G Sex For Girls!―女の子のための性のお話（内田春菊、飛鳥新社、2007）

毎年この時期になると、「東大教師が新入生にオススメするベスト100」という企画で紹介してきたが、飽きた。 ほとんど変わり映えしないリストにも飽きたし、毎年「ベスト1はカラマーゾフ！」とハヤすのも飽きた。カラ兄が最高であることはさんざん宣伝してきたから、皆さんご承知だろう（異論・反論大歓迎、これを超えるものがあるならね）。 だから、今回はスコープを広げてみる。 ■　この企画の趣旨 東京大学に限らず、新入生を迎えるにあたって、センセイたちは思うところがある（はずだ）。ゼミにくる前に、せめてこれぐらいは読んでおいてもらいたいと望んだり、若かりしころハマった本で自分語りをしてみたり。そうした願望を吸い上げているところもいくつか見つけた。以下のとおり。 リスト1 「北海道大学教員による新入生への推薦図書」 リスト2 「京都大学新入生に勧める50冊の本」 リスト3 「広島大学新入生に薦める101冊」

ワインバーグのライティング指南！（ここは驚くところ！あのワインバーグ翁だよ） 文章読本とあるが、コラム・エッセイのようなものではなく、本一冊を書き上げることが目的。自分のテーマを持ってる人は、本書を使うことで一冊書けるだろう。 ただし、いかにもワインバーグ本なので、使えるアイディアや視点は埋まっている。ゴシックで強調されるポイントもあるが、もっと重要な点がサラリと書いてある罠。ワインバーグ自身、自著を「金脈」ならぬ「鉱脈」と紹介する。金剛石はないかもしれないが、掘れば必ず石炭がある。これを「自然石」と名付けている。 有用なアイディア、視点、フレーズ ―― いわゆる「ネタ」―― 自然石を拾ってくること、積み上げることが、いわゆる「本を書く」ことになる。自然石を積み上げるから、「自然石構築法」と訳されている。 本書は、第1章「文章を書くために、一番大切なこと」から、第20章「完成した後は?」の

[チームリーダーは「アジャイルレトロスペクティブズ」から盗め]の続き。わたしの「ふりかえり」をふりかえってみる。 ■01　定期的に、ふりかえる 実は、定期的なふりかえりは、したことがない。たいていは、プロジェクト終了直後や、さらにずっと後になって、「あんな時代もあったね」と語ることはあっても。ただし、「笑って話せる日」は絶対こない。笑わず小声で真剣に「あの二の舞だよ」、あるいは「まだ学習してへんのかッ」と刺す。 そういうチーム運営を定期的にふりかえる必要性に気づいただけでも、本書に感謝しないと。 まずいチーム運営は、トラブルという見えやすい形でフィードバックをもらっていた。メンバーの不満や、作業プロセスのボトルネック、品質チェックの不備は、プログラマの喧嘩や明白なサボタージュ、収拾のつかないバグズライフに化す。 そして、「トラブルの対処」という形で皆の不満を吸い上げたり、手順書を見直したり

プロマネ本は沢山あるが、こいつは具体的。プロジェクトのその場その場で発生する問題とその解決策がよく分かる。「こんなときどうする?」形式なので、自分なりの対策を考えて→次のページで"答え合わせ"をするといった読み方もできる。カユいところに手が届く仕掛け。 例えば… 問題がいつまでたってもなくならない。進捗報告はペンディングの山。どうやって片付ける? テストが甘い。行き当たりばったりで、テスト自体のモレヌケによりつぶすべきバグが後になって湧く。なんとかするには、何をどうすればいい? アバウトな品質要求「使いやすい画面にしろ」といわれたとき、何をどうすれば「使いやすい画面」になっているといえるのか? 進捗管理が甘い。「90パーセントです」が1ヶ月続く。あるいは、進捗会議の場が、「なぜ遅れているのか」の言い訳の場になっている。どうする?　答え 問題を管理する。責任者、期限、優先度を決め、進捗を監視

あいにく銀の弾丸の持ち合わせはないが、うまくいくプロジェクトでよく使われていた言葉は確かにある。耳にしたときは聞き流していてた言葉を、この本は思い出させてくれた。ここでは、そんな「魔法の言葉」を紹介する。 ネタ元は「目標を突破する実践プロジェクトマネジメント」。ふつう、図書館で読んだ本はそれっきりだが、こいつは買って周りにばら撒く。薄くて分かりやすくて、すぐにやってみようという気にさせるところがいい。 ■　もし、問題があるとすれば、それは何ですか? 朝会や進捗会議で「何か問題はありませんか?」という質問はよくするしされる。けれども答えはいつも決まっている→「特にありません」。でもって、不具合が起きると、「あのとき聞いたのにッ」←→「こうなるとは思ってなかった」となる。 身に覚えない? これを、冒頭の質問にしてみると、アラ不思議、いくらでも出てくる。「問題ない?」には無反応だったのが、「これ

燃えるプロジェクトに投下され、火消し&延焼抑止に奔走し、落ち着いたころに引き抜かれ、次へ… そのたびに、心労で胃痛になるか、ストレス食いで太るか。 失敗プロジェクトなら、必ず現場がゾンビ化するとは限らない。腐敗は脳（上層部）から始まり、皮膚の内側（見えないところ）で進行する　←これかなり重要 たとえば、問題なくリリースまで至るが、一銭たりとも支払われなかったとき。次 ver.で費用は見てやるからさ、それまでにこの要件を「追加」として扱わないで作ってよ… というパターン。承諾しないPMは疎まれ、事情を知ったメンバーは総替え（あるいは脱出）する。そして、次の人にお鉢がまわってくる―― いっさいの事情を聞かされずに、警告すらされないまま。さあ、修羅場のはじまりだ … …なんてね、知人の話だよ（棒読み）。 「間違いだらけのシステム開発」では、そんな笑えない知人の話がたくさんある。どいつもこいつも生

もしあなたが週60時間以上働いているとすれば、父親として役に立たない。息子が問題をもつようになったら、それはあなたのせいだろう お題は次の文に続く──「父親はきちんと家に帰ってきて、こどもと一緒に遊んだり、笑ったり、じゃれあったり、ものを教えたりする必要がある」 のっけからショッキングな断定文が続くが、読み進めて納得した。「男の子って、どうしてこうなの?」は、異性である息子を育てるのに途方にくれる母親たちへの福音書かもしれないが、父親が読むと考えを改めさせる指南書なのかも。 けれども会議が、出張が、締め切りが、なんて抗議の声は上げられる。生活を成り立たせるための仕事を放り出したりすれば本末転倒ではないかと。同意、わたしもそうだから。それでもココロのどこかで知っている、ものごとには、取り返しがつくものと、つかないものがある。そして、代替の利くものと、利かないものがある。取り返しがつかないもの

仕事でコード書いてた頃の話。 机上に「本」というメディアは無かった。プログラミングといえばお手本のコピペ＆手直しで仕上げてた。だから、せいぜい入門書やリファレンスといった辞書的なやつだけで、3年もすれば「古い」と引き出しの中へ。 だから、いつまでたっても上手なのは「お作法」だけ。あたりまえだ。仕様を実装したコードに「似た」コードやパターンを探し出す→コピペがプログラマの仕事だと思ってたから。ネットの情報が「全て」であって、「考える」とは、「いかにお手本に合わせるか」だったから。 プログラマというよりも、むしろ「コーダー」。その辺は「プログラマになれなかったわたし」[参照]に書いた。 ここでは、「コンピュータの名著・古典100冊」の既読リストで恥さらし。いかにちゃんとした本を読んでいないかがよっく分かる、なさけない。 本書はプログラミングに限らず、ソフトウェアエンジニアとしての libera