というわけで，名古屋参上．
まずは寿がきやでラーメン食べます．
寿がきやってのは，名古屋を中心に展開するラーメンチェーン店．関東にも 一部熱狂的なファン がいて，今回一緒に行った後輩もその1人．私も子供の頃はしょっちゅう食べていたような気がするけど，今回20年振りぐらいに食べました．あー懐し．
ナゴヤドームに着きました．
私が通っていた中学から数分のところにあります．この近辺も懐しいなぁ．
試合前のセレモニー．
っていうか，人多すぎじゃね?
試合開始．中日ガンバレ．
勝ったぜー
あ，ちなみにこれは一緒に行った会社の後輩．決してジュゴンではありません．
いよいよ明日 (日付的にはもう今日ですね) から，今年のプロ野球日本シリーズが始まる．テレビ朝日のニュース番組，「報道ステーション」のスポーツコーナーで見た，日本ハムのヒルマン監督のインタビューより．
a big stage,
a lot of attention,
a lot of pressure,
um...but, you know...
at the end of the day, you still have to...
you have to find a way to enjoy
こう言いながら，彼はうっすらと笑みを浮かべていた．
仕事でも遊びでも，例えそれが春の厳しいキャンプからペナントレースを乗り越え，やっと手にできるかもしれない日本一がかかった真剣勝負であっても，やっぱり「楽しむ」ことが一番重要なのだ．私はプロ野球選手では (もちろん) ないが，昔真剣にスポーツをやっていた時も，今仕事をしている時も，楽しんでいる時，リラックスして取り組めている時が一番高いアウトプットが出せるような気がする．いや，気がするというか，絶対そうなのだ．
「どんな大舞台で，どんなにプレッシャーがあっても，(そして例えどんなに辛い負けであっても，) その日が終わる時にまだエンジョイできていること…」
昔から思っているけど，なーんかこの人の言うことって，いちいち心に残るんだよなー
ファンサービスの為にギターで弾き語りをしたりバック転を披露したりする野球監督のくせに，言うことが仙人のようというか，もの凄く辛いことや苦しいことを乗り越えて自分の悟りを開いた人間のような重みがあるというか，おそらく人として，もの凄く深い人なんだろうなーって思う．
"But, at the end of the day, you still have to find a way to enjoy."
「一外国人野球監督のひと言」で終わらせてはいけないと思う．仕事でもプライベートでも，恋愛でもスポーツでも，人生の全てのことにおいて，ものすごくシンプルで，ものすごく大切なことなんじゃないかって思う．
言い回しは全然違うけど，同じようなメンタリティーで，この Blog のサブタイトルには，"If it's fine rain or shine I don't mind I'll take it anyway" なんてつけていたりする．
…ま，私は大のドラゴンズファンなので全力で中日を応援しますがね．
(でもそんなこんなで，パ・リーグは日ハムだけには来てほしくなかったというのが正直なところ)
とある友人が紹介してくれた，「苦痛を伴なわない効率の良いコードレビュー」という記事．なかなか良いことが書いてある．
Effective Code Reviews Without the Pain
特に，コードレビューには，1) コードの品質を保証する，2) 開発者を教育する，という2つの目的があると前置きした上で，コードレビューに対するアプローチに言及している点がおもしろい．
1) 物事を断定するのではなく，質問を投げかけるようにすること
2) 「なぜ?」という質問を避けること
3) 褒めることを忘れないように
4) コーディングルールが確立されていること
5) 議論の対象はあくまでもコード，決してコーダー (開発者) になってはいけない
6) 解決方法は1つだけではないことを念頭に
そしてもしあなたが開発者ならば，
1) コードがあなた自身ではないことを忘れないように
2) 自分用のチェックリストを作成すること
3) コーディングルールを整備すること
とのこと．
(上記全て私なりの意訳なので，各々の説明も含めて詳細については原文を参照して頂きたい)
いずれにしても，「間違い探し」「犯人探し」や「誰が優れたプログラマーかコンテスト」ではなく，「参加者全員から何かを学ぶチャンスがあるフォーラム」といった雰囲気作りが大切なのだということ．
非常に参考になった．
ところで私が考える「効率の良いコードレビュー」は以下の通り．
まず基本的に，チームのメンバーを全員集めて対象ソースコードをファイルの頭から順番に舐めていくのは，あまり効率的ではないと思う．当然プログラムはその順番で動くわけではないし，ソフトウェアは時間概念を持って動くので，静的にコードを眺めていても絶対に抜けが発生する．いわゆる「文法チェック」に毛が生えた程度のチェックしかできず，それはそれで必要だが何人も集めて行うのは少しもったいない．
ということで，コードレビューは，「ペアレビュー」と「チームレビュー」に分ける．
ペアレビューでは，二人一組になって，レビューする側はレビューされる側のコードを基本的に全て見る．この段階では，ツールが見逃した「文法チェック」や「単純ミスがないか」，「コーディングルールに沿っているか」など，つまり「プログラミング言語として正しく書けているか」という観点でチェックを行う．レビューされる側は，レビューする側に，自分の言葉で全てのコードを説明する．レビューする側は疑問に思ったことはなんでも聞くことにする．
チームレビューでは，コードを順に追っていくようなことはせず，「抜き打ち試験方式」を取る．対象個所の仕様やシステムに精通したレビュワーが，事前に質問を10個程度用意する．例えば「ユーザーがこの操作をしている時にこのイベントが発生したらどうなる?」とか，「このデータとこのデータが同時に書き変わったらどうなる?」とか，「またその時にこの類のエラーが発生したら，どういう手順で復帰する?」みたいな．それで，例えばシーケンス図等の補助資料を使いながら (その場でホワイトボードに書いても可)，それらの質問に対して全てコードベースで説明していく．他のレビュワーも，その説明に対して追加の質問をどんどん投げかける．タスクやプロセス境界とそれらのプライオリティなども考慮し，あくまでも「動いているソフト」をイメージしながら質問することが重要．コードを書いた人は，もちろんそこの個所に一番詳しいはずなので，全ての質問に対して理路整然とコードベースで回答できなければいけない．
時間が許すなら，ペアレビューは違うパートナーと3セット程度，チームレビューはメンバーからの追加質問が「それはちょっと重箱の隅をつつきすぎじゃない?」というレベルになるぐらいまで，というのが理想だ．もちろんチームレビューの方は，考慮が足りないコードや明確に説明できない場合などは，「リベンジ」として対象範囲の第2回目以降が設定される．経験的にこの方法が，一番コードの品質が上がるような気がするし，不具合が出た時に追いやすくなると思う．
ところで上記引用記事の冒頭に書いてある，「開発者は他人のコードを指摘することで，いかに自分が優れているか誇示しようとする」というのは，どこの開発現場でも見られる光景のような気がして，思わず苦笑してしまった．
うちの娘は来年から幼稚園．
幼稚園選びは嫁さんに任せっきりなんだけど，今日はとある幼稚園の運動会で，未就園児も一部参加可能ということで覗いてみました．
行く前は，
あぁぁぁ…だっっっるぅぅぅー
と思ってたけど，行ってみたら，うん，まあ，楽しかったかな．
昨日 に引き続き，今日も SEI シニアメンバーとのテレビ会議．プレゼンは昨日で終了し，今日はリラックスした雰囲気の中で，半ば雑談のようなセッション．
SEI の一流アーキテクトと話す機会なんてそこそこ無いので，自分が聞いてみたかった質問をぶつけてみた．
1) 様々な手法がある中で，同じようなメソッドでも単純に「呼び方が違うだけ」のものがあるような気がする．このような「宗教論」が純粋なソフトウェア工学の研究の妨げになっているのでは?
2) 企業で働いていると，精神的に消耗してしまって鬱病のようになってしまう人を見かけるけど，そういう人に対してどう接すればいいと思う?
1) について補足すると，SEI は今日では有名な設計手法をいくつも定義しているが，他の団体や研究者が提唱しているものと，実はアプローチは良く似ているのに表現の仕方が違うだけのものもあるような気がして．
で，彼の回答としては，
「基本的に宗教論を展開する意図はない」
「むしろ他の団体と協力しようとしている」
「ただアメリカは『コピーライト』に非常にうるさく，同じ名前が使えないことがよくある」
「自分が表現したいことを明確に表現する為に，自分の言葉を選ぶことはある」
…といった感じで，まあ様々な事情があるのかな，と．特に「私自身が SEI の考えに合わない部分に関しては，SEI には関係なく自分自身の考えを本に書いている」と話していて，こちらからしてみれば「結局それってまた似て非なるものを作ってることにならないか?」と思ったり．
結局こちらが内容を理解して，似ているところと違うところを抽出するしかないんだろう．というか，自分の中できちんと各々の本質を消化できていれば自ずとそうなるだろうし，結局どんな本を読んでもそこに答えは無いように，「手法」を「実践」にどう適用するかは自分次第なんだろうけど．
2) について彼が話したことは，
「まず君自身が，自分が犯した間違いとその理由を忘れないこと」
「そういう人達のことを，『マシーン』ではなく『人間』として見ること」
「コミュニケーションスキルを大切にすること」
「そういう人達に，『自分ならできる』と思うことを期待しないこと」
「そして中には，救いの手をさしのべてもらいたく無いと思っている人もいる．そういう人達に対しては，もうどうすることもできないよね」
…ということで，彼にしては珍しく抽象的な表現だったが，考えてみればこのような課題は環境やシチュエーション，またその対象者個人によって対応方法が違うだろうし，一意に回答を用意する方が嘘くさい訳で，「それはマネージメントの問題だよね」なんて片付けずに，自分の経験から1つ1つ注意深く言葉を選ぶ彼の姿が印象的だった．
せっかくなので，他に彼が話してくれた中で心に残ったものを，差し支えの無い範囲でいくつか紹介しておこう．
ソフトウェアアーキテクトという職業に対する彼の持論 (心構え)
If you succeeded, team did succeed.
If team failed, it's your fault.
Don't be an architect if you can't live with that.
もし君が成功したなら，それはチームの成果．
もしチームが失敗したなら，それは君1人の責任．
それが受け入れられないならアーテクトになんかならない方がいい．
アーキテクトに必要とされるもの
1) Good technology...period!
2) Excellent communication skill, both in speaking and writing
3) Leadership
4) Organizational skill
3) について補足すると，「みんなが『この人について行きたい』」と思うようなリーダーシップが必要とのこと．そしてそれはどこから来るかというと，決して「役職」や「肩書」からなどではなく，その人が持つ「自信」からだと言っていた．
無能な上司を持ったらどうすればいいか
If life gives you lemons, make lemonade.
これはアメリカで良く言われる諺で，直訳すると「レモンが与えられたらレモネードを作りなよ」ってことだけど，レモンは "bad thing" レモネードは "good thing" を指す．「くよくよするなよ」的に使われることもあるけど，彼の意図は，つまり「逆にそれをチャンスに変えろ」「逆境に文句を言うのは誰にでもできるけど，それを強みに変えることが重要」ということだった．
大勢の利害関係者が集まる中，話が発散してしまう時のまとめ方
1) Identify
2) Describe
3) Show them alternatives, and their costs and impacts
4) Negotiate
5) Get everyone's agreement
1) 要件の整理・定義をきちんとして，2) それを説明して (その為に物事の最初からきちんと議論に参加させる)，3) 代替案 (とそのコストやインパクト) を示し，4) その上でネゴを行い，5) 全員の合意を得る．
この流れで話を進めることによって，内容をフォーカスしつつ，「お前が悪い」「俺の仕事じゃない」「自分はやってない」等の議論を避けることができるのだとか．
プレゼンを行う際に注意するべきこと
Know your audience and what they want.
例えば聴衆が，マネージャーの場合 (興味対象は，スケジュールがオンタイムかどうか，どれぐらいのコストを節約するのか)，マーケティングの場合 (興味対象は，どんな機能を実現するか，他社に対してどれだけ差別化ができるか)，ユーザーの場合 (興味対象は，「そのボタンを押したらどうなるか」)，プログラマーの場合 (興味対象は，自分の担当個所を実装するにはどうすればいいか) によって，適切なピースを切り取って説明すること．それを行う為に，アーキテクトの頭には開発の全てのピースが詰まっている必要がある．
これらの聴衆の中で，アーキテクチャに本当に興味があるのは?
→ "Nobody"
これらの聴衆の中で，アーキテクチャから影響を受けるのは?
→ "Everybody"
アーキテクトとして，開発を行う際に最も注意するべき点
Focus on risks and trade-offs.
It's absolutely essential to map the business case to the architecture.
Don't assume anything in the design space.
まず，分析においては「リスク」と「トレードオフ」に細心の注意を払うこと．
それから，ビジネスケースに沿ったテクノロジーを開発すること．ここはかなり強調していたが，"Architects put blinders on" という表現をしていた．
「あなたにどれだけ商品開発の経験があって，その道で成功してきたかは関係ないし興味がない．勝手に要求を変えないでくれ．私がカスタマーとして発注した要求は絶対なんだ．その要求通りの設計をしてくれ．」と．
あと「仕様変更は今日から○○週間受けつけますよ」と言ったら，「開発側から『変更を受けつける』と言うのは危険だよ」とアドバイスをくれた (実際には，冗談半分にありえない要求を次々に投げかけるというイジワルな示し方だったけど)．それを言うなら「何が変更できて，何は変更できないか」のスコープを明確にした上で提案するべきだと．
そして今日一番心に残ったこと．分かっていたつもりだったが，改めて言われると目から鱗が落ちるようだった．
Architecture design is not an event,
it's a process
それにしても，彼の洞察力はすさまじかった．ほんの少しの矛盾点も見逃さない．ごまかしは一切通用しない．豊富な経験に裏打ちされ，いくつもの引き出しから，分かりやすい言葉を選んで話すのは「脱帽」の一言だった．
あ，そうそう，ちょっと話がそれるけど，昨日発見した (というか彼に教えてもらった) Power Point の tips を1つ紹介．数十枚のパワポ資料を使ってプレゼンした後，質疑応答で例えば「25ページ目のところだけど…」とか言われて該当ページを見せようとした時に，わざわざスクロールしてそこに辿りつこうとしません? 実はスライドショーにしたまま "25" "Enter" とするとそこに飛ぶのでした．
ま，なんにせよ，とりあえず「一仕事終わった」ってかんじ．今夜の酒はうまかったなぁ．
Peace Pipe: もの事するときの心構え - 志村けん [memo]
今週は，アメリカの某大学教授，兼 SEI (アメリカ国防総省によって設立された連邦政府資金のソフトウェアエンジニアリング研究所) のシニアメンバーに，50分のプレゼンをする機会がある．この16週間の集大成のプレゼン．相手は筋金入った百戦錬磨のプロ中のプロ．今考えるだけでも手足が震えてくる．
--中略--
今から当日着ていく服装まで決めて，イメトレしてます．実は練習から吐きそうになるぐらい緊張しつつ，準備してるんです．こんなこと書いてるだけで，手足が汗でびっしょり…
がんばれー > 俺
完璧にこなしてやったぜ!!
ざまぁーみやがれ > 昨日まで緊張してた俺
志村けんの公式 Blog より．
ken's blog: 枕が変わると眠れない
私志村けんは実は凄いあがり性で緊張しいなんです。
--中略--
それに勝には、稽古、練習しかないのです。
練習で100％出来て本番で80％かな もの事するときの心構えと思います。
自信持てるまでやるしかありません ね
一時代を築いた彼の言葉だからこそ，重みがあるし，勇気付けられます．
昔テレビで本人が語っていたことだけど，「志村さんはなんで結婚しないんですか?」と聞かれた時に，「結婚するとお笑い以外に大切なものができてしまう．自分はお笑いのことだけを，いつも一番大切にしていたいから．」と話していたのが印象的だった．
もちろん家族ができて，守るもの，守られるものができてこそ仕事のアウトプットも高まるという考え方もあると思うから賛否両論かもしれないが，彼のプロとしての真摯な心構えはひしひしと伝わってきた．
そして今でもバリバリの現役，ホントにカッコいいと思う．
人にこう言うと決まって「意外」とか「嘘だ」とか言われるけど，実は私も凄いあがり性で緊張しいなんです．
今週は，アメリカの某大学教授，兼 SEI (アメリカ国防総省によって設立された連邦政府資金のソフトウェアエンジニアリング研究所) のシニアメンバーに，50分のプレゼンをする機会がある．この16週間の集大成のプレゼン．相手は筋金入った百戦錬磨のプロ中のプロ．今考えるだけでも手足が震えてくる．この3連休は資料作成 (というか資料はほとんどできていて，英訳と最後のチェックをしています)．
でもそれが，信頼できるメンバーと一切の妥協をせずに検討してきた内容を伝えると思えば，自然と自信が湧いてくる．
凄いあがり性で緊張しいの自分だけど，人には「プレゼンが上手い」と言ってもらえることが多い．内容に絶対の自信があって，部屋の大きさやオーディエンスの人数，また当日の形式などが分かっていて，予めプレゼンのイメージトレーニングができる時は，絶対に失敗しない自信がある．
「これ以上できない」というぐらいまで準備できれば，例え相手が誰でも気持ちで上に立てます．
うー，でも緊張するなー
今から当日着ていく服装まで決めて，イメトレしてます．実は練習から吐きそうになるぐらい緊張しつつ，準備してるんです．こんなこと書いてるだけで，手足が汗でびっしょり…
がんばれー > 俺
自信持てるまでやるしかありません，ね．
村上 龍の小説，「69」の中に，
うち、ブライアン・ジョーンズの、チェンバロの音のごたる感じで、生きていきたかとよ
というフレーズが出てくる．
「私はね、ブライアン・ジョーンズのチェンバロの音のような感じで生きていきたいのよ」
なんとも抽象的な表現だが，Brian Jones には個人的な思い入れもあったりして，その表現がとてもしっくり来るような気がしていた．
「自分だったら何と言うかな…」と考えてみて，それは John Lennon の歌声かもしれないし，Keith Richards のギターかもしれないし，Bob Dylan のハーモニカかもしれないけど，「音」よりも「曲」で考えると，何曲かそんな，こんな感じで生きていきたいな，と思う曲があるように思う．そしてその中の1つは，The Black Crowes の Wiser Time かな…と．
この曲が Crowes の中で一番好きな曲ではないかもしれないし，「1つだけ好きなバンドを選べ」と言われたらきっと Crowes では無いような気もするけど (そもそもそんなの選べないが)，なんかこの曲は自分の内面のリズムとマッチするような気がしていて．
はかない歌詞とそれを力強くも切なく歌い上げる Chris の歌声，Chris と Rich のハーモニー，ねっとりとしたリフ，Steve のカウベルを入れるタイミング，Rich のスライドから Eddie のオルガン，そして Marc のギターに流れていくソロの構成，その後またバンドの音が1つになっていく所，後半のサビの裏にかぶせているフレーズ，その全てが美しいんだけど…
そう，その全てが美しいんだけど，そんな説明できる1つ1つのパートなんかではなく，曲として持つ雰囲気というか，作り出される空間にそれを感じているんだと思う．
不思議なこと，書いてますかね?
こんな感覚って，実は誰にでもあるものなんじゃないのかな．
それは音楽じゃなくても，例えばいつか観た映画やドラマのワンシーンかもしれないし，絵画や彫刻みたいなものかもしれないし，マンガやアニメかもしれないし，いつか誰かと交した会話かもしれないけど．
On a good day, I know it ain't every day,
we can part the sea
And on a bad day, I know it ain't every day,
glory beyond our reach
-- Wiser Time / The Black Crowes
あなたが「こんな感じで生きていきたい」と思うものは何ですか?
Google で実践されている，効率の良いミーティングを行う為の tips．
How to Run a Meeting Like Google
1. Set a firm agenda.
2. Assign a note-taker.
3. Carve out micro-meetings.
4. Hold office hours.
5. Discourage politics, use data.
6. Stick to the clock.
日本語で分かりやすい解説をしてくれているのが，こちら．
B3 Annex: Google流会議のための6か条
"How to Run a Meeting Like Google" なんていう，たいそうなタイトルがついている割には，ごく当たり前のことが書いてあるように思う．というか，当たり前のことを当たり前にやることが重要なんでしょう．まわりを見渡してみると，いかに無駄な会議の多いことか…
1 に関連することだが，アジェンダは極力事前に配布して，出席が必要かどうか (もしくは他に参加が必要な人がいないかどうか) 各自判断できるようにしておいた方がいいだろう．あとは「議論をする」ミーティングと「決まったことを報告する」ミーティングは明確に区別した方がいいように思う．
ちょっと話はそれるけど，会議の場というのは基本的に人と人とのコミュニケーションなわけで，ものすごく場をまとめるのが上手い人 (もしくは下手な人)，誰も気付かなかった当たり前のことをいつも指摘する人 (もしくは逆にいつもツッコまれている人)，ジョークを交えつつ和やかな雰囲気で進めようとする人 (もしくはまったく話がツマらない人)…など，いろいろな個性が発見される．
時には，普段ちょっと話をしたり，仕事をしている時からは想像できなかった一面が露呈されることも．
複雑な内容でも全員が納得できるように分かりやすく伝えることができる人って，ソフトウェアの品質も高い気がするのは私だけではないはずだ．
