この本がスゴい！2021
「後で読む」は、あとで読まない。 「後で読む」は、あとで読まない。 「試験が終わったら」「今度の連休に」「年末年始は」と言い訳して、結局読まなかった。「定年になったら読書三昧」も嘘になるだろう。そもそも、コロナ禍で増えた一人の時間、読書に充てたか？（反語） だから「いま」読む。 たとえ一頁でも一行でも、目の前の一冊に向き合う。いま元気でも、一週間後には、読めなくなるかもしれないから。 今年は、死を意識した一年でもあった。「やりたいこと」を先延ばしにしてるうちに、感染して望みが断たれる可能性が爆上がりした。 時の経つのは早い。人生が長いほど、一年は短くなる。体感時間は加速する一方、人生の可処分時間は、短くなる。 だから「いま」読む。 積読を自嘲したりマウント取るのもヤメだ。いま読まない理由を並べ立てて開き直る不毛も捨てよう。そして、ずっと取っておいた、とっておきの本を、いま読む。 そんなつも
大好きなマンガが完結したので全力でお勧めする『大蜘蛛ちゃんフラッシュバック』（ネタバレ無し）
このマンガは、同級生のお尻を見てたら、ひっぱたかれるところから始まる。 ……このシーンは、主人公の実（みのる）の目線ではない。お尻を見てたのは亡き父で、その記憶が、折に触れて、実の脳内に蘇るのだ。 お尻の持ち主は、若かりし頃のお母さん（旧姓：大蜘蛛ちゃん）。つまり、母に一途な父の目線でもって、「女子高生のお母さん」の記憶が、息子にフラッシュバックされる。 そして厄介なのは、実は、お母さんに恋をしてしまっていること。女子高生のお母さん（細身で強気）と、今のお母さん（むっちり無防備）に煩悶する、マザコンラブコメ。 「お母さんに恋してる」なんて、ちょっとヤバくね？ その自覚はある。だから実は自問する。 だけど、お母さんとの日常に、父の過去の記憶が入ってくると、女子高生のお母さんの可愛いさに撃たれる。そして、（ここ重要）父がどれほど母を好きだったか、ということを、父の目線で思い知る。だから実は煩悶
日本史に残る巨大 IT プロジェクトから学べること『みずほ銀行システム統合 苦闘の19年史』
大規模 IT プロジェクトの成功事例と、大規模システム障害の失敗事例を合わせた一冊。読み手に応じ、さまざまな学びが得られる。 困難な状況で、プロジェクトを成功に導く教訓を学ぶこともできるし、史上最悪のシステム障害がどのように発生し、波及していったかを生々しく読めるし、二度と起こさないための再発防止策を具体的にピックアップすることもできる。 「東京スカイツリー7本」の ITプロジェクト なぜアズイズ（As-is）が問題なのか プロジェクト推進体制を強化する具体的な方法 2002年と2011年の大規模システム障害の顛末 IT システムの赤の女王説 日経コンピュータの「演出」 1. 東京スカイツリー7本分 IT業界のサグラダファミリアと呼ばれてきた、みずほの勘定系システム「MINORI」が、2019.7月、ついに完成した。 4,000億円という巨費を投じて 富士通、日立製作所、日本IBM、NTT
この本がスゴい！2016
人生は短く、積読山は高い。 せめては「死ぬまでに読みたいリスト」を消化しようとするのだが、無駄なあがき。割り込み割り込みで順番がおかしくなる。読了した一冊に引きずられ、リストは何度も書き直される。 重要なのは、「あとで読む」は読まないこと。「あとで読む」つもりでリツイート・ブックマークしても読まないように、あとで読もうと思って読んだ試しはない。だから、チャンスは読もうと思ったそのときしかない。実際に手にとって、一頁でも目次でもいいから喰らいつく。勢いに任せて読みきることもあれば、質量と体力により泣く泣く中断する本もある。かくして積読山は標高を増す。 ここでは、2016年に読んだうち、「これは！」というものを選んだ。ネットを通じて知り合った読書仲間がお薦めする本が多く、それに応じてわたしのアンテナが変化するのが楽しい。わたし一人では、数学や経済学や歴史学、進化医学や認知科学の良本を探し出せな
上達の科学『「こつ」と「スランプ」の研究』
スポーツや演奏で上達するときに何が起きているか？ この疑問に、身体知の認知科学から迫る。 なにか上手くなりたい目標がある人にとって気づきがあるかも……と思ったが、本気で練習しているなら誰だって知ってる「身体知」の話だ。「体で覚える」とか「腑に落ちる」というやつで、"Don't think! Feeeel!"といえばピンとくるかも。 お手本をコピーするだけでなく、その時の周囲の状況や身体の各部位に意識的になり、ことばと身体の両方で「分かる」ところに持っていくことだ。本書が面白いのは、研究者自らが実験台となり、バッティングの練習に取り入れて実際に上達しているところ。様々な身体知研究の紹介をする一方で、自らの経験に基づいた実感が溢れ出ている。 本書の姿勢はこうだ。これまでのスポーツ科学では、運動力学研究により、身体各部位の動作を要素還元的に分析し、「モノ」としての身体のあり様を明らかにしてきた。
『心はすべて数学である』はスゴ本
心を数学で解く。または数学に現れる心の動きを明かすスゴ本。著者が見えている場所を想像して興奮し、著者が見落としている領域が分かって武者震いする。 「心とは何か」について、カオス理論の第一人者である津田一郎氏と、かなり近いところにいることが分かった。漠然と思い描いていたことが、わたしとは違う方法論で明示されており、何度もエウレカとつぶやかされる。心は閉じた数式で書けるものではなく、ゲーデルの不完全性定理やカントル集合など、不可能問題や無限の概念を作っていくプロセスを応用しながら接近していくアプローチが有効だという。 心は単独で形成されるものではなく、他者や環境とのコミュニケーションによって発達する。「私の心」と「他者の心」という区別は一種の幻想で、相互に影響しあっている以上、離散的なものにならざるを得ないという。 それでも、何らかの共通的な普遍項があるように見える。その共通項を、「抽象的で普
『思考の技法』はスゴ本
哲学するための装備を整え、著者自身の戦歴を踏まえながら自分のモノにする一冊。カタログ的なツール集というよりも、もっと大掛かりで強力な、知の増幅装置に近いイメージ。 「意味」「進化」「意識」「自由意志」といった、手ごわいテーマに対し、手ぶらで対峙しないための装備と考えればいい。オッカムの「かみそり」ではなく「オッカムのほうき」、藁人形論法ではなく「グールドの二段階藁人形」など、一般の思考道具よりも威力のある、77もの装備が手に入る。 たとえば、必要以上に多くの仮説を立てるべきでないとするオッカムの「かみそり」よりも、「ほうき」の方がより凶悪だ。なぜなら、自説に都合が悪いエビデンスや統計情報を掃き出して「なかったことにする」ほうきだから。著者ダニエル・デネットは、暗闇で犬が吠えなかったことが手がかりとなった、シャーロック・ホームズのあの推理を思い出させる。知的に不誠実な人が、不都合な事実を隠し
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
この書店がスゴい『TOKYO本屋さん紀行』『TOKYOブックカフェ紀行』
いわゆる、物量で圧してくるギガ書店ではなく、厳選され演出されたセレクトショップをご紹介―――というよりも、そのガイド本をご紹介。いつもの本屋を通り過ぎ、電車に乗ってでかける価値あり。 『TOKYO本屋さん紀行』に紹介されてる書店に共通するのは、「人と本のつながり」。本は単品で並べられるのではなく、ある意図をもって他の本との関連性のもとで棚が編集される。そこには店員の意思があり、店のポリシーまで手繰ることができる。興味を惹いた一冊や既読本、さらにはイベントを通じて、棚とスタッフに共感する。同調する人が集まってくる―――これからの書店は、そういう「場」を目指しているようだ。 たとえば、千駄木駅から5分の往来堂書店。丁寧に編集された棚が、読み手に「発見」の喜びを教えてくれるという。著者や出版社で分けるのではなく、意味のつながりがある本を並べてつなげてゆく、いわゆる「文脈棚」。これが十八番だった松
本好きが選んだハヤカワの170冊
オススメを持ち寄って、まったりアツく紹介しあう「スゴ本オフ」、今回のテーマは「ハヤカワ」！これまた楽しく美味しいだけでなく、積読山脈を成長させるスゴい回だった。 午後一時から夜八時、延々7時間のマラソン・オフ会、見てくれこの獲物。 本ばかりですまぬ。場の"ふいんき"はやすゆきさんの「早川書房さんシバリスゴ本オフは直球、変化球アリで「さとし」が大人気の楽しいパーティだった」でどうぞ。 まずはSF、「ハヤカワといえばSF」の通念をあえて外したのか、SFはあるにはあるが、期待したより少なめ。おすすめプレゼンでは、イーガンもホーガンも、ギブスンもレムもないのがちょっと驚き。代わりにブラッドベリやハインライン、クラークが熱く語られる。暫定的結論によると、「幼年期の終わり」はSFオールタイムベスト、「ハイペリオン」はSFのラスボス」になった。「幼年期の終わり」と「ブラッド・ミュージック」はペアで読むと
この本がスゴい！2011
今年もお世話になりました、すべて「あなた」のおかげ。 このブログのタイトルは、「わたしが知らないスゴ本は、きっとあなたが読んでいる」。そして、このブログの目的は、「あなた」を探すこと。ともすると似た本ばかり淫するわたしに、「それがスゴいならコレは？」とオススメしたり、twitterやfacebookやtumblrで呟いたり、「これを読まずして語るな！」と叩いたり―――そんな「あなた」を探すのが、このブログの究極の目的だ。 昨年までの探索結果は、以下の通り。 この本がスゴい！2010 この本がスゴい！2009 この本がスゴい！2008 この本がスゴい！2007 この本がスゴい！2006 この本がスゴい！2005 この本がスゴい！2004 昨年から始めたオフ会で、たくさんの気づきとオススメと出会いを、「あなた」からもらっている。目の前でチカラ強くプッシュしてもらったり、物語談義を丁々と続けたり
プロマネ必読！「アポロ13」
「アート・オブ・プロジェクトマネジメント」で強くオススメされてたので読む ―― これはスゴい。ドキュメンタリーとして夢中になって読めるだけでなく、プロジェクトが危機に陥ったときの「べき/ベからず集」しても、ものすごく有効な一冊なり。 どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策…プロジェクトがパニックに瀕したとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる。本書を通じて学んだ危機管理マネジメントは、次のとおり。 プロジェクトが危機的状況のとき、あらゆる手段を使って、自分の感情をコントロールせよ。感情は事実をゆがめ、判断を誤らせ、解決への手段の一つ一つに邪魔をする 「危機」は、すぐに数字にならない。必ずタイムラグが発生している。だから、危険な数値が今出ているということは、既に危機的状況に突入している、ということだ 問題に対処するとき、絶対
わたしが知らないスゴ本は、きっとあなたが読んでいる: 悪魔の詭弁術
「わたしと仕事、どっちが大事? はなぜ間違いか」の紹介エントリ[参照]でオススメいただいた詭弁本をいくつか。容易に悪用できるので、詳細はカンベンな。 詭弁術の実例は、fj や 2ch でさんざ見てきたので今さら感もあるのだが、こうして体系的に見せられるとなかなか興味深い。このテのは昔も今も変わらないもんだなぁ… まず qinmu さんにオススメいただいた「詭弁論理学」は、よくまとまっている。ナントカの一つ覚えのように主張を繰り返す小児強弁型、相手＝悪、だから、自分＝正しいとする二分法、論点のすりかえ、主張のいいかえ、ドミノ理論（風が吹けば桶屋）と、誰でも一度は聞いたことがある詭弁術が紹介されている。強弁が強盗なら詭弁は詐欺だという主張にナットク。例は多少が古めかしいが、中身は全く現役だ、今夜もどこかの板で議論されているハズ… そういや、2ch の詭弁のガイドラインに詭弁の特徴15条があった
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
わたしが知らないスゴ本は、きっとあなたが読んでいる: 火事になる前に読んでおきたい「火事場プロジェクトの法則」
問題プロジェクト・失敗プロジェクト・デスマプロジェクト ── 呼び名は沢山あれど、振り返ったとき、ああすればよかった、こうすればよかったという反省や後悔（?）は、これまた沢山ある。 「あの営業連中のコトバを鵜呑みにしなければ…」 「新技術に手を出す範囲を限定しておけばよかった」 「もっと顧客に張り付いて仕様を搾り出しておくべきだった」 「なんであのとき、SOSをださなかったのか！なんで問題を放置したんだ！」 … 過去のプロジェクトを眺めたとき、問題点はいくらでも出てくる。おそらく携わった人の数だけ出てくるだろう。 それにもかかわらず、これから出くわしたとき、どうすればよいかは、分からない。なぜなら、どんな問題に遭遇するか分からないから。プロジェクトが特殊性、一時性をもつように、それにまつわる問題も同様に、特殊性をもつ。したがって、その解決策は、常にその問題専用の解法でしかない ── ──
箱
復刊されますた（via:揮発性メモ）。いやー、めでたい。原題が "LEADERSHIP AND SELF-DECEPTION / GETTING OUT OF THE BOX" で、訳者が同じ人なので、「箱 ―― Getting Out Of The Box」と中身は一緒のはず。 本書は、巷に数多にあふれている自己啓発本のタネ本。成功本における「地上最強の商人」や「道は開ける」であったり、マーケティング・交渉術における「影響力の武器」と一緒。新刊出しては印税稼ぐ人は、これらの種本をネタにして、せっせと今風の味付けをするという仕掛け。味付けが違うだけの新刊をたくさん読むくらいなら、原液をそのまま読んだ方がずっと効く。 永らく絶版状態となっており、せどらーどもの暗躍を見るにつけ（中古価格 8,000円！）、苦々しく思っていたけれど、ようやく定価で買える。本屋にあほほど積んである啓発本は、本書の
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「わたしと仕事、どっちが大事?」はなぜ間違いか
タイトルで惹かれて一読、これはイイ！ これは使わせてもらおう。 ロジカルシンキングやMECEといった論理的思考ツールは、確かに仕事に使えるまで砥いできたが、肝心の議論に役立ってはいない。あ、いや、「自分の考えを的確に表現し、相手に理解させる」ツールとしては有効だけど、 ・議論が紛糾したとき ・自分の結論へ誘導したいとき ・自分の主張に言いがかりとつけられたとき これっぽっちも役に立たない。「おまえの意見はよく分かったが ── ── そんな話はここでは通用しないよ」 ── SEにはカネのことなんか分からないんだ」 ── 他の人もみんなそうじゃないと言っているよ」 と断言されると、一瞬、どう返していいか言葉に詰まる。議論は黙した方が負け、というルールに従って引き下がらざるをえなくなる。しばらくたって、その「反論」は何の根拠もないことに気づくが、議論はもうあさっての方向へ行っている。 仕事の場に
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「アート・オブ・プロジェクトマネジメント」読書感想文（その1）
最近、マネジメント系の仕事ばかり振られるようになったので、予習のつもりで一読 したが、これはスゴい。読んでる途中から振り返り読みを繰り返し、再読も再々読もしなければならないことに気づいた。本書で紹介されるアート（技芸）は、How to モノと大きく異なり、根っこから考え→実践に適用し→フィードバックが必要なものばかり。 あ、最初に結論を述べておくと、これは今年のNo.1スゴ本なり。ふり返ると「No.1スゴ本」の称号をいくつかの書籍につけてきたが、本書は間違いなくNo.1だと言い切れる。読み手の経験に応じ、必ず得るものがある。概要はamazon紹介文をどうぞ（太字はわたし）。 「ものごとを成し遂げるためには何を行う（あるいは行わない）べきか」という実用的な視点からプロジェクトを捉えて、ものごとを成し遂げるための考え方やヒントを、スケジュール、ビジョン、要求定義、仕様書、意思決定、コミュニケー
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
わたしが知らないスゴ本は、きっとあなたが読んでいる: 要求仕様戦争（その4）
■開発工程をどうこうする――「要求開発」というフェーズを設ける いったい何が作りたいのか?――この問答を真摯に行う作業がすっぽりと抜け落ちている。仕様凍結ギリギリまで曖昧なままにしておこうとする顧客と、早い段階で仕様をFIXさせてしまおうとする開発側の、両方から引っ張られ、要求仕様決めが考慮されていないのが実情。 これまで後工程に埋め込まれ、属人的に処理されている「仕様のカケラから要求を復元する作業」「経営課題から要求まで洗練する作業」に名前を付けよう。それだけでなくその作業を一つのフェーズとしてキチっと定義しよう…そんな提言を行っているのが要求開発アライアンス[参照]。 例えば、システムをいかに効率的に作るかについては、開発手法、プロセス、開発支援環境が編み出され、適用されている。例えば、Eclipse はコード書きのためのツールだけでなく、テスター、QC（品質管理）、生産物、バグトレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
