今日退院してきました

　先週の土曜日には退院できるはずが、一週間延長されて本日退院して来ました。無事に退院できた今だからこそ言えますが、結構大変だった。1500人に一人といわれる合併症が出て痛みに耐えていたり、暗い病室で一人苦しんだり、仕事の締め切りがモロにかぶって無理やり引き継いでもらったり。
　細かい話はおいおい日記に書くつもりですが、おかげさまで今は元気です。来週から少しずつ仕事のペースをあげて行くつもりです。

4月の読書

ハーバード流交渉術

　実はすごく昔(8年くらい前)に当時の上司から薦められたのですが、積読に成っていました。その時も多少読んだのですが、今ひとつ実感が沸かなかったので、止めてしまいました。最近、某blogで薦められていたので再読して見ました。
　基本的なロジックはデッドラインで書かれていたものと変わらなく、大きな発見はありませんでした。しかし具体的な事例があったり、考え方のヒントがいくつかあったので、その点は参考になりました。やはり本は出会いで、タイミングが重要ですね。
　例によって、備忘のために一部を抜粋。

• 相手側とのブレストを計画する。関係者全員の利害を考慮に入れたアイディアを生み、共同で問題を解決しようという気運を生む。また互いに相手の利害を知るという極めて大きな利点がある。
• ブレインストーミング中の心得：横並びに座って問題に取り組む。共通の問題に共同で取り組む姿勢を心理的に強めるため
• 多くの人は正当性というものを重視する。したがって、相手方が受け入れやすい解決を図る一つの効果的な方法はそれらが正当に見えるように体裁を整えることである。
  (そうそう、相手の気持ちを推測する事が交渉の第一歩だよね)
• 利害の対立を私意で解決しようとすると結局高くつく。したがって、解決は双方の意思とは無関係の客観的な基準によってなされるべきである。
• 前もって、受け入れることのできる最悪の結果、つまり"ギリギリの線"を決めておいて方がよい。
• 交渉による合意が成立しないとき、それに代わる最良の案は何か。その代替案は、交渉相手から合意案を検討するうえで目安となるだけでなく、あまりにも不都合な条件を受け入れることを防ぎ、また有利な条件を拒否してしまうことを防ぐ、唯一の基準である。
  (相手の立場を推測する重要性は分かっていたけど、譲れるラインに関してはあまり考えていなかった)
• 合意が成立しなかった場合の、相手の代替案についても考慮すべきである。彼らは合意が成立しない場合の処置について楽観的に考えすぎているかもしれない。多分彼らにも、数多くの代替案があって、それらをいっしょくたにして漠然と考えているのだろう。
• 議論にのぼっている案を改良する方向へ相手の関心を持っていくことである。それには、仮に彼らの主張する立場を受け入れるとしたらどうなるかについて話し合うのがよい。
  (無茶な要求をする人はたくさんいるけど、気がつくように誘導するのは難しい)
• (たたき台を作って意見を求める)経済的制約内で双方の利害の最大限の調和を考え出すこの過程は、決定とは区別されているので、どちらも性急な約束をしてしまう心配はない。
  (たたき台の重要さは分かっていたけど、進め方を整理しておくのは良い事)
• (相手が汚い手口を使ってきたらどうするか)相手の手口を知ったら、次にそれらを正面から取り上げる。「ジョー、これは私の全くの誤解かもしれないが、どうも君とテッドはは好かれ役と憎まれ役を演じているような気がする。君たち二人の間に本当に意見の食い違いがあるなら、ちょっと休憩したらどうだろう」
  (これは戦術の一つとして心得ておくと良いかも)

　でも一番面白かったのは訳者の後書きかもしれない。そうなんだよねぇ〜。彼らはパワフルに交渉するんだよね。でも文化の違いらしいぞ。

• 日本人とアメリカ人は、そもそも交渉についてお互いに大きく異なるイメージを抱いていることに気がつかないままに、交渉のテーブルについているケースが多いのだ
• 日本人が特に反発を感じるのは、交渉中にけわしい顔で要求を突きつけていたアメリカ人が、交渉が終わったとたんに、ガラリと表情を変えて手をさしだし肩を抱いてくるようなときである。ひっかけられたのではないかと疑心暗鬼にならざるをえないからであり・・・

yom yom (ヨムヨム) 2008年 03月号 [雑誌]

　読んだのは、十二国記の新作「丕緒の鳥」が載っていたから。短編も良いけど、最後の長編はいつ出るのかなぁ。結構長らく楽しみに待っているので、早めにお願いします。

おもてなしの経営学 アップルがソニーを超えた理由 (アスキー新書)

　中島さんのblogをいつも楽しんで読んでいるので、買ってみました。元マイクロソフトの古川さんと対談がすごいという噂は聞いていたけど、本当にすごいね。パソコン黎明期における中島さんのキャリアがさりげなく書いてあるけど、時代を背負った人だなというのが伝わってきます。しかも「日本の」じゃなくて、「世界の」だもんな。
　えっと例によって一部抜粋です。

• 人事管理はしないけど、業務としては100人のエンジニアたちが何をやっているかを監督し、指示を与えなければいけなかった。でも、誰も僕の下に属していない以上、僕に命令する権限はない。なので、彼らに言うことを聞かせる唯一の方法が「エンジニアとして勝つこと」だったんです。
  (すさまじい自負ですね。不肖shodaiもミニチュアな同じ立場なので、心に染みました)
• (中島さんとの対談での中島さんの言葉)「グーグル礼賛者」とかよく言われているようだけど、みんなに向かって「グーグルという会社を正しく認識しようよ」と言っているだけなんです。10年足らずでこれだけ大きな会社になって、売り上げも利益も時価総額の伸びもすべて至上最速。
  (グーグルのすごさと不可思議さは、理解が足りない部分も多かったので参考に成りました)
• (1999年頃に)僕がビル・ゲイツに「半年ぐらいの短期間、3人程度のグループで好きなことをさせてほしい」と直談判したんです。でも彼は「それはベンチャー企業でもできる。マイクロソフトの役割はベンチャー企業ができないことをやることだ」と突っ返した。
  ゲイツはやはり経営の天才かも。時流を考えればなかなか言えないセリフだよね。正しいか間違っているかの判断は難しいけど、これを明確に打ち出せるのは本当にすごい。自分が何であるかを本当に理解した判断なのだろう。
• (中島さんの言葉)大学の先生のような既存の枠ではないところで活動して、20年後に「あの人は違う意味での『教育』を実施していたんだな」と言われるようなことをしたい。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

　半分くらい読んだところで、図書館の期限が来たのでタイムアップ。面白かったんだけど、手元に無いから抜粋も出来ない。小説風に書かれている本はとっつきやすいけど、飛ばし読みがしにくいから困るよね。

アイ・アム・レジェンドを見ました

アイ・アム・レジェンド 特別版(2枚組) [DVD]

　先日飛行機に乗ったら、たまたま上映していたので見てみました。だけど見終わった瞬間になんだこの落ちは？と叫びたくなりました。いや小さい声でつぶやいたかも知れない。
　藤子・F・不二雄の漫画に流血鬼*1という作品があるのですが、これと同じ物が元ネタに成っていると聞いた時から見たかったのですよね。昔読んだあの落ちは今でも鮮明に覚えています。こういう世界がひっくり返る話が好きなんですよね。未読の方はぜひ一度。短編集だから探しにくそうですけど。

　途中まで張ってあった良い感じの伏線はいったいどこに行ったのか？という疑問を持って徘徊したら解説文とPodcastを発見しました。ちょっと前置きが長いけど面白い。一度は作ったものの、映画会社からの要請で作り直したようですね。複雑な落ちは受け入れられないのかなとか想像します。
　リンク先を読む&聞くと原作に興味がわいてきたので、読むかなぁと考え始めました。とそんな時にDVDには「衝撃の別エンディング」があるというあおりが！悩むなぁ。評判はあまり良くないみたいだけど。

*1:流血鬼 - Wikipedia

千葉マリンまで行ってきました

　今シーズンの初観戦という事でロッテ戦を見に行きました。2対1で負け。しかも、7時過ぎに入ったので得点シーンも見られず。思えば去年は3試合見に行きましたが、全て完封負け。今年も前途多難だなぁ。

ホームゲーム無敗伝説

　今日も無事に継続できました。今日から連勝スタートです。
　それにしても半袖魔人(小山投手)の魔力がなかなか復活しません。心配ですね。長袖を着ているから駄目という噂がありましたが、今は半袖に戻したのかなぁ。

6連敗

　明日からホームなので、連勝開始です。ホームでは無敗。

2008年3月の読書 つづき

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

　さて本自体の感想です。筆者がシステム360*1を作った経験を基に20年以上前に書かれた本書ですが、その主張は普遍的ですね。「人」と「月」が等価交換で無いなんて、プロジェクトを管理する人なら誰でも知ってます。でも都合の良いように等価交換にしてしまうんだな。コミュニケーションが大事な事だって分かっているけど、ついさぼってしまう。それを解決する銀の弾は無いという話です。みもふたも無いようですが、真実でしょうね。
　新しいキーワードとしては「セカンドシステム症候群」がありました。新しいシステムを作るにあたり、既存システムの機能を意味無く捨てられない。よくある話ですが、概念として上手くまとまっています。
　また「ガレージプログラム」をプログラミングシステムにする労力が「システム統合インターフェイス」、「文書化、テスト等」を考慮すると9倍に達するという話は個人的に共感できるものの、近年のWebサービスにはあまり当てはまらない気がする。システムに対するイメージが異なるために、テストと文書化のコストを削っても平気なんでしょうね。全てがそうだとは思いませんが。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

　スゴ本*2さんのお勧めに従って読んでみました。私はトラディショナルな局面開発の経験の方が多く、アジャイルな開発というのをみたことがありません。採用の要否はともかくそのメリットを理解する事が一番の目的です。
　掲げてある原則が練れていることもさながら、それとあわせて記述してある個人の経験や「バランスが肝心」として記述されている注意事項が分かりやすい。例によって備忘としていくつかあげます。

• 「コードが汚い！きれいにするんだ」という原則に対して、「経営陣や事業家に納得する理由を示すこと。コードがすっきりするから、では理由にならない」という注意事項が書いてある。
  うーん、まったくそのとおり。最近同じような主張を聞いたなぁ。
• 「設計とは指針であって指図ではない」。「最初に詳細に要件定義を行い、続いて詳細な設計を行い、それから実装、統合をすませてから、最後に、(天に祈りつつ)テストする」というのはウォーターフォールの誤解された姿。
  そうだった。局面は戻らないといっている分けじゃない。全てのステークホルダーの合意を得て、そこを基点とするだけなんだ。アジャイルな開発と局面開発は対比するものでは無く、補完するものもしくは発見させるものなんだな。
• 「Planに価値は無く、planningが肝心なのだ」設計する事で得られた知見こそが重要なのだ。
  最近これは実感しています。問題は得られた知見を以下に次の工程につなげるかです。知見をドキュメント化しないことで失われる事は少なくない。それでは設計していないのと一緒だ。
• 継続的インテグレーションツールを活用しよう。コードのチェックアウト、ビルド、テストをバックグラウンドで定期的に実行する
  いい気がするのだけど、やったこと無いから良く分からない。一度試してみたいな。
• インクリメンタルに開発するんだ。NASAですら、スペースシャトルの複雑なソフトウェアをイテレーティブかつインクリメンタルに開発したんだ。*3
  インクリメンタル開発を嫌がる人への反証として抑えておきたい。でも無条件では使えないはずだから、リンク先は読まないと。でも、英語か。
• コードよりも先にテストを書く。いわゆるテスト駆動開発(TDD:Test Driven Development)。テストを先に書くことで、実装者としての視点ではなく、利用者としての視点コードに接する事になる。
  この具体例が書いてある。テスト駆動開発とかテストファーストって言われた時に、コードをとりあえず書いてテストする意味だと想像したのは私だけですか?
• パスカルの言葉、「長い手紙をお許し下さい、短くする時間が取れなかったのです」
• ブタとニワトリ。レストランで朝食にベーコンエッグを出すとすれば、ニワトリは卵を産むだけでいいが、ブタの方は命がけだ。チームメンバー=ブタとマネージャ=ニワトリは明確に区別すべき。
  いいネーミングだけど、実際に使ったら揉め事が起きるかな。
• スタンドアップミーティングをしなさい。長さは10から15分くらい。一人は2分程度。
  興味はあるんだけど、使う機会が無い。次にチームを作ったときは必ずやろう。
• PowerPointでコードは書けない。アーキテクトとは設計と指導はその本分であるはずなのに、肩書きに値しない人が多い事。小ぎれいな図を描いたりパターンをやたらと使うのはアーキテクトじゃない。
  パワーポイントで書かないなんて当たり前じゃん、と思ったら自分を指していた。ガツンときました。そうだplanningで得られた知見は必ず次の工程につなげなきゃいけないんだ。
• ペアプログラミングは効果的なメンタリングを自然に行える環境である。
  ペアプロの価値が少し分かりました。ペアプロで稟議を通す自信は無いけど。
• コードをレビューする。
  レビューするのは当たり前。でもどうやって？その効果はどれくらいあるのか？が理解できた。
• アジャイルへ踏み出す。一気に導入してはいけない。胸の痛みを訴える患者に、「さっさとベッドから出てランニングマシンで一汗かけ」とは言わないよね。
  そうですね。でも自分の仕事に少しずつ取り入れたいと思います。

　けっこう気づきが得られましたね。いい本でした。

*1:って知ってますかぁ〜、みなさん。Wikipediaを見てね

*2:「アジャイルプラクティス」はスゴ本: わたしが知らないスゴ本は、きっとあなたが読んでいる

*3:リンク先の参考文献はまだ読んでない。 http://www.amazon.com/Design-development-integration-shuttle-software/dp/B0006Y7724/ref=sr_1_2?ie=UTF8&s=books&qid=1207494667&sr=8-2　pdf版？