「若い頃の自分に教えたいこと」を集めた名言集『他人が幸せに見えたら深夜の松屋で牛丼を食え』
40～60代のおっさん達に、「もし若い頃の自分にアドバイスができるなら、何を伝える？」と聞きまくって集めた名言集。 聞いた場所も、東京なら赤羽・上野、大阪なら新世界、名古屋なら栄の飲み屋街に限定してる。出てきた答えは、下品で下世話で下半身ネタだらけだけれど、心底その通り！と言いたくなる名言ばかり。 誰も教えてくれなかったけれど、長いこと生きてきて、ようやく身に沁みて分かった、何気ない一言が集められている。職場呑みの宴席とか、独りで入った飲み屋のカウンターで、こっそり教わる人生の教訓だ。 わかる人には痛いほどわかるやつで、分からない人は、きっと、幸せな人生だと言えるだろう。 人は、傷ついた分だけ、性格が悪くなる ラブソングとかで、「傷ついた分だけ、人は優しくなれる」というフレーズがある。手垢にまみれまくっているが、これはウソ。 あんなの心地いいだけで、タワゴトです。真実は真逆で、傷ついた分だ
ミスを責めるとミスが増え、自己正当化がミスを再発する『失敗の科学』
人はミスをする。これは当たり前のことだ。 だからミスしないように準備をするし、仮にミスしたとしても、トラブルにならないように防護策を立てておく。人命に関わるような重大なトラブルになるのであれば、対策は何重にもなるだろう。 個人的なミスが、ただ一つの「原因→結果」として重大な事故に直結したなら分かりやすいが、現実としてありえない。ミスを事故に至らしめた連鎖や、それを生み出した背景を無視して、「個人」を糾弾することは公正なのか？ 例えば、米国における医療ミスによる死亡者数は、年間40万人以上と推計されている（※1）。イギリスでは年間3万4千人もの患者がヒューマンエラーによって死亡している(※2）。 回避できたにもかかわらず死亡させた原因として、誤診や投薬ミス、手術中の外傷、手術部位の取り違え、輸血ミス、術後合併症など多岐にわたる。数字だけで見るならば、米国の三大死因は、「心疾患」「がん」そして
なぜ、あの人は、あやまちを認めないのか？
「謝ったら死ぬ病」をご存知だろうか？ どんなに証拠を突き付けても、絶対に非を認めない人だ。 プライドの高さや負けず嫌いといった性格的なものよりもむしろ、過ちを認めることが、自分の命にかかわるものだと頑なに信じている。すなわち、「謝ったら死ぬ」という病（やまい）に取り憑かれている―――そんな人がいる。 もちろん、想像力が衰えて視野が狭く、無知な自分を認めたがらないような頑固者なら、可哀そうに思えども理解はできる。 だが、第一線で活躍する知識人や学者で、ものごとを客観視できるはずなのに、この病気に罹っている人がいる。それどころか、その優れた知性を用いてコジツケを考えだし、論理を捻じ曲げ、のらりくらりと言い逃れる。 なぜ、あの人は、あやまちを認めないのか？ ずばりこのタイトルの本書を読んだら、疑問が氷解した。 それと同時に、「謝ったら死ぬ病」は私も罹患していることが分かった。「あの人」ほどは酷く
1冊の単語帳を610日かけて全読したら語彙力が1万語になった
きっかけは、読書猿さんとの飲み会だった。 「海外の記事やSNSを読むのに英語力が足りない。しゃべれなくても書けなくてもいいけど、スラスラ読めるようになりたい」と愚痴ったところ、「まず2万語」と言われたのが最初だ。 語彙力こそパワー、ボキャブラリーを増やすぞとばかりに選んだのがこれだ。 理由は、英語を学んできた人たちの評価がダントツだったことが一つ。もう一つは、お試しで手にしてみたところ、「ちょっと難しいけれど、頑張れば読めないこともない」というレベルだった点だ。 本書を610日間かけて読み切った結果はこうなる。Preply のボキャブラリーテストによると、ほぼ一万語に到達できた。 7870 words （2021年4月） 9944 words （2023年4月） ぶっちゃけ私一人では無理だった。初志は継続せず、どこかで挫折する理由を探し出していた。 だが、私を一人にしない技法を用いることで
しなくていい失敗を回避する『プロジェクトマネジメントの基本が全部わかる本』
プロジェクトマネジメント（PM）の重要性は、あまり認知されていないように見える。 うまく回っているときは「あたりまえ」扱いでスルーされ、いざ暗礁に乗り上げたときに「どうなってるんだ！？」と糾弾の的となる。 プロジェクトをうまく回していくコツというか勘所は確かにあり、相応のトレーニングが必要だ。にもかかわらず、なぜか蔑ろにされている。ろくに訓練もしないまま、「見て学べ」「やって覚えよ」と実践に放り込み、メンタルをやられず生き延びた者が幹部になる。 これは悪手だ。 よく、「失敗から学ぶほうがより身につく」などと唱える輩がいるが、しなくていい失敗は避けたほうがいいに決まってる。そして、この「しなくていい失敗」のほとんどは、基本を押さえるだけで回避できる。 この、PMの基本を押さえているのが本書だ。 『プロジェクトマネジメントの基本が全部わかる本』には、プロジェクトを回していくために「あたりまえ」
炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
ミスが全くない仕事を目標にすると、ミスが報告されなくなる『測りすぎ』
たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。 そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。 すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。 天下りマネージャーが馬鹿なのは、なぜバグを管理するかを理解していないからだ。 なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい（反対に、テスト項目は消化しているのに、バグが出ないと、テストの品質を疑ってみる）。バグの出具
わたしが知らないスゴ本は、きっとあなたが読んでいる
なぜ自分が自分の形を留めていられるかというと、自分を知る誰かがいるから。 誰も自分を知らない場所へ旅するのもいい。そもそも誰一人いない場所を旅するのもいい。だが、いつかは放浪をやめてこの世界のどこかに落ち着かなければならない。さもないと人という存在と疎遠になり最後には自分自身にとってさえ他人になってしまう。 誰かを撮った写真は、近しい人間の心のなかでしか価値を持たないのと同じように、人の心も別の人間の心の中でしか価値を持たず、その人の思い出は、思い出したときにのみ存在するだけであって、思い出す人がいなくなれば、消え去るほかない。 人生は思い出だ、そして思い出が消えれば無になる。だから人は思い出を物語ろうとする―――コーマック・マッカーシーの『越境』を読んでいる間、そんな声が通底音のようにずっと響いていた。 マッカーシーの代表作ともいえる国境三部作（ボーダー・トリロジー）の第二作がこれだ。第
おっさんから若者に贈る「経験を買う」6冊: わたしが知らないスゴ本は、きっとあなたが読んでいる
結論から言うと、経験は買える。 適切なタイミングで適切な本と出会うことで、しなくてもいい経験や、身につけておくべき知恵を”買う”ことができる。今「おっさん」である私から、20年前の「若者」だった私に、いい仕事をする上で読んで欲しい本を選んだ。 20年前は、炎上プロジェクトに飛び降りて、鎮火しつつ撤退する「しんがり」役を仰せつかっていた。負けることは決まっているが、死なないように生きることばかり考えていた。将来に漠然とした不安を感じていたものの、とにかく目の前の障壁をクリアすることが先決だと思っていた。 今はかなり違う。 身をもって得た経験や教訓はあるが、代償は大きく、もっと効率よく結果につなげることができたはず。この「効率」とは要するに時間だ。莫大な時を費やして手に入れた経験は確かに得難いが、そんなことをしなくても積むことはできた。どうすれば可能か、今なら分かる。 それは本を読むことだ。本
金融再編残酷物語「システム統合の正攻法」
Day2の大本営発表。 Day2とは"Project Day 2"のことで、東京三菱とUFJの勘定系を統合させた、史上最大のプロジェクトだ。本書は、日経コンピュータの記事を元に、Day2のケーススタディとして編纂されている。プロジェクトマネジメントとシステム統合の文字通り「生きた教科書」といえる。ただし鵜呑むのは禁止な、経営層の大本営発表を元に作られているのだから。「涙の数だけ強く慣れるよ」（誤字ではない）とつぶやきながら読むべし。 Day2がいかにデカいかは、次の数字が物語る。 11万人月 2500億円 開発に3年 6000人の技術者 8万人のシステム利用者 比較のために添えておくと、みずほ銀行のシステム統合（2004.12完了）は9万人月、郵政民営・分社化に伴うシステム対応（2007.10完了）は、4万3000人月になる。Day2がいかにケタ違いであるかがよく分かる。これに加え、チーム
コピーが経済を回す『パクリ経済』
結論を一言にすると、「イミテーションはイノベーションを加速する」。 模倣が創造を促すといえばその通りだろう。だが、世間一般の通念は違う。音楽や映像、書籍や製薬などの業界を見る限り、著作権や特許権でコピー禁止の「常識」が形作られている。クリエイターの努力が簡単にコピーしていいのなら、誰もわざわざ新しいものを創ろうとしなくなり、最終的にはその産業が壊滅してしまうという懸念が背景にある。 本書はこの「常識」に異議申し立てをするものだ。ファッション、アメフト、料理、金融、音楽といった分野に目を向け、コピーがイノベーションを促進しているだけでなく、成長の鍵となっている証拠を次々と指摘する。この事例が面白い。単なる反証ではなく、それぞれの歴史的経緯を踏まえながら、どのように折り合いをつけてきたかを解き明かす。 たとえばファッション。メジャーブランドが新作を発表すると、すぐさま模造品が出回るが、そうした
『思考の技法』はスゴ本
哲学するための装備を整え、著者自身の戦歴を踏まえながら自分のモノにする一冊。カタログ的なツール集というよりも、もっと大掛かりで強力な、知の増幅装置に近いイメージ。 「意味」「進化」「意識」「自由意志」といった、手ごわいテーマに対し、手ぶらで対峙しないための装備と考えればいい。オッカムの「かみそり」ではなく「オッカムのほうき」、藁人形論法ではなく「グールドの二段階藁人形」など、一般の思考道具よりも威力のある、77もの装備が手に入る。 たとえば、必要以上に多くの仮説を立てるべきでないとするオッカムの「かみそり」よりも、「ほうき」の方がより凶悪だ。なぜなら、自説に都合が悪いエビデンスや統計情報を掃き出して「なかったことにする」ほうきだから。著者ダニエル・デネットは、暗闇で犬が吠えなかったことが手がかりとなった、シャーロック・ホームズのあの推理を思い出させる。知的に不誠実な人が、不都合な事実を隠し
自炊の味方『小林カツ代のお料理入門』
料理をおいしくするコツが、やさしく伝わる一冊。 我が家で最も信頼されているレシピ本は、小林カツ代シリーズになる。料理一年生ではないけれど、味付けの勘所だとか、おいしくなるひと工夫を、ピンポイントで教えてくれるから。3～4人ぐらいだと、彼女のレシピが一番いい。 ところが本書は、趣が違う。わたし＋誰かのための料理ではなく、わたしだけの美味、ひとりごはんを目指してるところ。いつもの家族向けというより、一人暮らしの自炊の味方となっている。ひとりだと、節約＋満腹に目が行きがちだが、彼女のポリシーだと、「ひとりのご飯こそ贅沢においしく」になる。結果、料理のラインナップは、かなりユニークだ。 たとえば一品目、すき焼き。ひとりすき焼き!? 鍋物って大人数で囲むイメージが崩れさる。しかも、ポイントがシンプルだ。すき焼きで大事なのは、「葱は必ず焼きつける」だそうな。一本以上、斜めに切って、びっしり鍋底に敷きつ
糞システムにしないため、私ができること『はじめよう！ 要件定義』
「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
第8章：プロジェクト品質マネジメント(その2)
ここでは、プロジェクト品質マネジメントをまとめます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ keywords ・シックスシグマ ・トータルクオリティマネジメント(TQM) ・品質計画 ・フローチャート ・特性要因図 ・品質保証 ・品質管理 ・コントロールチャート(管理図) ・上方管理限界と下方管理限界 ・中心線、平均 ・7の法則(ルールオブセブン)とアサイナブルコーズ シックスシグマ 経営指南本で有名なキーワードだけれども、純粋に品質管理の用語。google先生に訊いてみるとそれこそ山のように出てくるけれど、本当に重要なのは次のとおり。 シグマ(記号だとσ)とは標準偏差、すなわちバラツキの度合いのこと。数値が高ければ高いほど、精度が高いことを意味する。例えば、3シグマの精度は99.73％で、1000個の製品のうち、不良品は27個程度混入すると予想される。数値を記憶。
デザインの科学『インタフェースデザインの心理学』
「ファミコン『ドラゴンクエストIV』のパッケージイラストの主役が、一番小さく描かれているのに、最初に目に入ってくるのはなぜか」 これについて、中村佑介氏の解説が目鱗だ→【イラストの見栄えが良くなる】中村佑介先生の公開講座が凄い！。本来は目立たせたいもの（主役）を大きく描くのが原則だが、彩度とコントラストを増やすことで、見やすい画面作りをしているという。 だが、もう一つ、このデザインには「主役」を主役たらしめるテクニックがある。それは以下の通り。 1. 人は、人の顔に一番興味を持つ 2. 人は、画面の中で、顔を最初に見る 3. 人は、画面の顔の視線の先に注意を向ける この原則を知ったのが、本書だ。人はどのように認知し、判断し、行動し、そしてエラーを引き起こすのかについて、ウェブやアプリのデザイナー向けに、「100の指針」という形でまとめたもの。 「嘘のレベルは伝達手段で変わる」や、「読むと理
トヨタ・バッシングの正体『アメリカ型ポピュリズムの恐怖』
アメリカのトヨタ叩きについての「もやもや」が晴れた。これは、アメリカンリスクの教科書として読まれるべきスゴ本。 そのジャイアニズムやダブスタにはちゃんと（構造的な）理由があることが分かる。なぜヒステリックな反応をしたのか、原因判明にもかかわらず、どうしてケジメをつけられないか理解できる。同時に、トヨタの大人の対応と、是々非々バランス感覚の絶妙さに唸らされる。さらに、アウディ、トヨタの次がどこであれ、どんな対応を取ればよいか教訓が得られる。 2009～2010年の「トヨタ急加速疑惑」によるトヨタバッシングは異様だった。メディアの扇情報道がオレモオレモ苦情のループを呼んでヒートアップする一方、トヨタを蹴落とす陰謀論がまことしやかに語られていた。どこまでが「事実」で、どこからが「意見」なのか日本のメディアを探しても、「グローバル経営感覚の欠如」や「トヨタの油断や驕り」など、自虐的な報道ばかり。後
第12章：プロジェクト調達マネジメント(その2)
ここでは、プロジェクト調達マネジメントをまとめます。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ keywords ・契約形態の選択 ・定額契約 ・実費償還契約 ・T&M契約 ・定額契約のメリット・デメリット ・実費償還契約のメリット・デメリット ・T&M契約のメリット・デメリット 契約形態の選択(p.150) ズバリ試験に出るところ。それぞれのタイプの特徴と、どういうときにそのタイプを採用するのかを押さえておく。「○○という条件でどのような契約が有利か?」といった問題が出る。 契約形態は以下の通り。 定額契約、一括請負契約 実費償還契約 T&M(タイム・アンド・マテリアル)契約 何を主眼に置くかで、どのタイプの契約にするべきかが決まる。 スコープがどれぐらい固まっているか? あるいは流動的か? プロジェクトがスタートしてから内容が変更される可能性がどれぐらいあるか(頻度
子どものために、できること「40歳の教科書」
親業の確認のつもりで読む、だいたい合ってた。 親を見て子は育つ。だから、子の努力を望むなら、まず親が努力する。「幸せ」とは何か伝えたかったら、親がイライラするのをやめる。「英語」はツールにすぎないが、「お金」の教育は重要。学校は人間関係を学ぶところだから、失敗の練習場と思え。社会に出ると、失敗は有償だぜ。 受験マンガ「ドラゴン桜」を本にした「16歳の教科書」、その番外編が「40歳の教科書」になる。以下の4テーマに対し、強いメッセージ性をもつ人からのインタビュー集といったところか。一問一答に「まとめ」ると、こんなん。 英語早期教育 「もっと早く英語の勉強をしておくんだった…」 「小学校から英語なんて、破滅するぞ！」 中高一貫校 「早いうちにいい学校に入れば、あなたがラクできるのよ 「その受験で幸せになるのは、子どもじゃなくてあんただろ！」 お金と仕事 「お金の話をするのは恥ずかしい」 「お金
要求の品質
BABOKの最重要ポイントは、要求の品質にある。 そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジを食い込ませてくる。要するに、仕様書には無いが無償（ただ）で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「本当に使う人」「本当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、食い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと]（とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける）。 しかしながら、反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
