もちろん「V.」も「重力の虹」も持ってる。けど「持ってる」だけで、読み終えたためしがない。イメージの濁流に呑み込まれて読書どころでなくなる。注釈と二重解釈と地文と話者の逆転とクローズアップとフラッシュバックと主客の跳躍に翻弄され、読書不能。まれに、「読んだ」「面白かった」という方がいらっしゃるが、どうやって【読んだ】のだろうあやかりたい頭借りたい。過日、ようやく河出書房の世界文学全集の「ヴァインランド」をくぐりぬけたのだが、読書というより酔書でフラフラとなった。 で今回、辞書並み（しかも2冊）の「メイスン&ディクスン」は、ドーパミンあふれまくる読書と相成った。小説的瞬間とでも名付たくなる、小説内時空間のどこにでも言及され・見渡され・語られている、代えるものがない強烈な感覚に浸る。酒みたいなものだ、酔いたいから呑むのであって、結果、酔うから楽しいとは限らない。もちろん微酔の楽しみもある一方、

「正しい」根回しのやり方が分かる。 「論理的に正しい」からといって、自分の提案が通るとは限らない。社内ルールに則っているからといって、その部門の協力を得られるとは限らない。社畜も長いことやっていると、「根回し」や「政治力」の勘所が分かってくる。仕事をまわす、ティッピングポイント。本書は、こうした暗黙知をノウハウのレベルまで噛み砕いている。 米国はそんなの無用だろうと思ってたが、勝手な思い込みだったようだ。本書がバイブル扱いされているのは、必要性を痛感しているからだろう。動かないプロジェクト、死蔵される情報、コミュニケーション不全――ビジネス上の課題はどこも一緒ということか。 そして、その対策も共通している。権力を使わずに人を動かす原則を一言で表すならば、「お返し」になる。何かイイことしてもらったら、お返しに何かを返したくなる気持ちこそが、肩書きや立場を離れて人を動かす動機となる。 本書では

肩書、権威はないが、うまく周りを巻き込んだり上司を動かして、結果を出せる人がいる。いっぽう、呼び名は何であれ、その役職名に見合った影響力を発揮できない人がいる。いわゆる、「部下をちゃんと使えない上司」というやつ。 本書は、当人の肩書・権威とは別に、仕事をする上で充分な影響力を行使するための法則と方法がまとめてある。やり方を知っている人にはアタリマエというか、当然のコトばかりなんだけれど、ここまで徹底しているのは初。 例によって長くなったので、以下に目次。 ■1　最重要は、8章「上司に影響を与える」と9章「やっかいな部下を動かす」 ■2　類書との決定的な違い――カーネギー「人を動かす」 ■3　人を動かす前提として、相手の「性格」ではなく「環境」に目を向ける ■4　類書との決定的な違い――チャルディーニ「影響力の武器」 ■5　ビジネスの場で活用できるカレンシー（価値） ■6　相手との関係がこじ

もちろんハルヒでも洞爺湖でもなく、三菱東京UFJ。 勘定系統合「Day2」 ―― 開発工数11万人月、投資額2500億円におよぶ史上最大のシステム統合プロジェクトが正念場をむかえる日だ。 「5月にやったじゃん、ATMでトラブってた」という声があるが、あれは単なるバージョンアップで、難易度は低い。 旧東京三菱と旧UFJ、メガバンクを統合させるにあたり、新規システムを作るのはぶっちゃけありえない。だから、どちらかのシステムに片寄せすることになる。片寄せされる方は「のりしろ」を準備したシステムにバージョンアップするわけだ。 5月にやったのはこのバージョンアップで、旧東京三菱の250店が「のりしろ」付きシステムに切替えただけ。大山鳴動してトラブル262件だったのも頷ける。 しかし、7月7日から始まる実質正念場では、旧UFJの420店が、旧東京三菱システムを土台にした新システムに移行していく。言い方

文章うまくなりたいくせに、ロクな努力をしていない。 文章読本や入門本、「○○の書き方」サイトを漁っては自己満足に淫する。量は質に転化するとはいうものの、駄文はいくら書いても駄文。カラまわりする向上心のギアをローに入れ、テクニカルな部分―― すなわち、「レトリック」に注力してみよう。 「レトリック」といえば、美辞麗句とか口先三寸とか、たしかに評判はよくない。「それはレトリックにすぎない」なんて、内容ゼロを非難する決り文句だし。 それでも、上手くなりたい。いままでの「書き方」だけでなく、違った彩りや味付けを目指したい。技巧が鼻につくかも恐れもあるけれど、さじ加減を考えて磨きたいもの。ネタ（選書）も大事だが、そのネタを引き立たせるのは技術だ。精進にちょうどいい本を読んだので、（わたしの勉強がてら）ご紹介～ ■　文章の目的 著者によると、文章の目的は「人を説得するために書くもの／書かれたもの」だと

marsさんが、「システム開発に関わる人はみんな読めー」と強力にオススメするにつられて読む。これはスゴ本。marsさん、良い本を教えていただき、ありがとうございます。 ■　どんな本? 本書は、開発現場で培われた「成果を出す習慣」を、45のプラクティスとして紹介している。開発速度を大幅に上げたり、高速納期を目指すような、「アジャイル開発プロセス」という決まったやり方は、存在しない。アジャイルな開発とは、現場でのさまざまな活動をアジャイルにしていく――つまり、変化に適応することを継続させていく―― 「習慣」だということに気づく。協調性+フィードバックによるプラクティスは、あまりにもあたりまえすぎて見過ごされがちかと。その反面、意識して実践するならばこれほど心強い金棒はないだろう。 ■　忘れがちな基本中の基本「成果をあげるのが仕事」 面白いのは、「悪魔の囁き」と「天使の導き」との間で揺れ動く「感

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

「なんで、こんな非効率なやり方なんだ?」この疑問、よくあるどころか毎日だ。 たとえば、情報がうまく共有されていないとか、ある人がボトルネックになっているとか。不平を言うと「じゃぁオマエがやれ」と押し付けられるので、最近では不言実行で最適化を図っている[参考]。 あるいは、評論家になっていっぱしのクチをきくが、現場を変える努力も勇気もないくせにブログで薀蓄たれ流す。ネット弁慶カッコワルイ（誰とはいわんが、わたしも含まれるので自戒）。 たしかに、「前と同じやり方」で仕事は回るが、「やり方」が改善されないまま。成果物はレビューされるが、仕事のプロセスはレビューされない。かくして非効率性は引き継がれ、不満は澱のように溜まってゆく。 こいつをなんとかする試みが、「アジャイルレトロスペクティブズ」。舌噛みそうな名前で、サブタイトルの「『ふりかえり』の手引き」というほうがピッタリだね。 つまり、プロジェ

60分で人生を変えるスゴ本。人間関係のキモが理解できる。どんな場合でも、最初にコミュニケートする相手、すなわち自分が「見える」。 あらゆる争いごとの根っこが「見える」。「あらゆる」なんて言っちゃうと、宗教や歴史といったセンシティブな話題まで振り幅が大きくなるが、無問題。夫婦喧嘩から中東問題まで、この原則で斬れる。 前作と同様、素晴らしいのは、主人公（オヤジ）の理解 = 読み手の理解となるような、ストーリー仕立てであること。オヤジの「ものわかりの悪さ」のおかげで、読み手の様々な反論が吟味される。フツーの天邪鬼が思いつきそうなものは、あぶりだされ、淘汰される。だから、腹の底から「わかった」といえる。 前作よりパワーアップしているのは、主人公（ = 読み手）に限定されないこと。問題を抱え、それを自覚していないのは、このオヤジだけではない。息子も、妻も、セミナーに参加するみんながそうだ。出身国も、

上長から「来週からコンサルタントとして○○社に入ってくれ」なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ（ [その1]、[その2] ）だが、ここらでまとめ。 システム開発チームのメンバーまたはリーダー 顧客の御用聞きを「コンサルティング」だと思っている　←これ誤り McKinsey や accenture といった「ファーム」と一緒に、顧客の中に入って仕事しなければならなくなった これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた（4冊目）のでまとめてご紹介。 ■最初に結論 コンサル会社がやっている「コンサルティング」は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持って

「最近の若者はダメだ」は昔から言われているが、特に今の若者はひどい。まず、当事者意識が完全に欠如している。さらに、独り立ちをしようとせず、常に何かに依存し、消費し、批判するだけの「お客さま」でいつづけようとしている。これはゆゆしき事態であり、日本社会のありかたにかかわる重大な問題である。 最近の若者は、定職に就きたがらない。あるいは、会社に入っても一定のポジションで身を立てようとしない。なぜなら、社会的なかかわりを、全て暫定的・一時的なものと見なしているからだ。 彼らに言わせると、本当の自分は別のところにあり、現実の自分は仮の姿に過ぎないんだそうだ。本当の自分は棚上げしておいて、いつまでも立場を替え、考えを変え、自分自身をも変身させる余地を残しておく。一貫した主義主張をもたないか、もたないふりをする。特定の党派、集団に全てを賭けることを避けようとする。 その結果、今の若者は、全ての価値観か

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

プロジェクトの火消し屋を長年やっていると、キナ臭い匂いを感じ取れるようになる。郵政解散までやって耳目を集めた「郵政民営化プロジェクト」、中の人はとってもデスマーチだと勝手に忖度して、合掌、礼拝、南無～。 先週、日本郵政公社は、かなり重要な決定を下した。 つまりこうだ―― 「2007.10.1の民営化スタートまでに、システム開発が間に合わないと判断された場合、閣議決定を経て民営化を半年延期する」―― 郵政民営化法には、こんな特例条項がある。社会的に巨大なインパクトを持つプロジェクトだから、GO/NOGOは法律＋閣議決定を要する。 しかしだ、1末時点での開発状況を分析した結果、「一部のシステム開発に遅れがあるものの計画の日程には十分間に合うと判断し、この条項を適用しないことを決めた」という。郵政公社の生田総裁によると、「開発はおおむね順調で、民営化の工程が押されるものではない」（※1）。要する

いま、わたしがガンで死んだら、けっこうな額の保険金が出る。交通事故に遭ってもしかり、不随状態になっても同様だ。大黒柱である以上、リスクヘッジは保険で対処している。 しかし、精神的なものに相当する「保険」はかけていない。大きな病気やケガをしたり、後遺症に悩まされるような状況になったとき、わたしの心は耐えられるのだろうか? 受け入れるのに時間がかかるだろうし、ガンのような「期限つき」の場合、パニックになるかもしれない。 あるいは、家族や周囲へのインパクトも大きい。保険金という「カネ」はあれども、治療費がどこまでいくのか見えない。そもそも大黒柱を失った（失いそう）な状況に、精神的にまいってしまうかもしれない。 さらに、病気やケガそのものは医者にまかせるとしても、その医者を信用するためにわたしはどうすればいいのか? という疑問は残る。思考を停止して医者任せがいいのか、Dr.google を読み漁る

「アート・オブ・プロジェクトマネジメント」で強くオススメされてたので読む ―― これはスゴい。ドキュメンタリーとして夢中になって読めるだけでなく、プロジェクトが危機に陥ったときの「べき/ベからず集」しても、ものすごく有効な一冊なり。 どうしようもない状況、限られた時間、非常に高いリスク、疑わしい解決策…プロジェクトがパニックに瀕したとき、優れたプロジェクトマネージャは何を考え、どう行動するかを知ることができる。本書を通じて学んだ危機管理マネジメントは、次のとおり。 プロジェクトが危機的状況のとき、あらゆる手段を使って、自分の感情をコントロールせよ。感情は事実をゆがめ、判断を誤らせ、解決への手段の一つ一つに邪魔をする 「危機」は、すぐに数字にならない。必ずタイムラグが発生している。だから、危険な数値が今出ているということは、既に危機的状況に突入している、ということだ 問題に対処するとき、絶対

結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小

長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」

■仕様書をどうこうする――「要求」の見える化 「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。 著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1～n を実装すれば要求Ａが実現する、という仕掛けだ。 ┌───┐ │要求Ａ │ └┬──┘ ├─仕様1（スペック1-1,1-2,1-3...） ├─仕様2（スペック2-1,2-2,2-3...） ├─　… └─仕様n（スペックn-1,n-2,n-3...） まぁ、こんなにキレイにならないだろうが、「このスペック（群）で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う（実際に目配りするかどうかは別として）。 本

■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体

■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか（書いた本人も）分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる