昨日 に引き続き，今日も 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" とするとそこに飛ぶのでした．
ま，なんにせよ，とりあえず「一仕事終わった」ってかんじ．今夜の酒はうまかったなぁ．
