http://d.hatena.ne.jp/aureliano/20090626/1245981276

挙げられていたのは次の7つです。

その1「テーマカラーを決める」
その2「四隅を押さえる」
その3「文字のジャンプ率を心持ち高めに（見出しは大きく本文は小さく）する」
その4「用紙に透かし文字を入れたように見せる」
その5「ガイドを使って配置を規則正しくする」
その6「ページ番号の字体を変える」
その7「読ませたい文言をキャプション化する」

なるほど、その4については少し疑問がありますが、それ以外は概ね同意できるポイントです。これらを踏まえてスライドを作れば、 きっと見栄えの良い資料を作ることができるでしょう。

うなずきながら、その結果出来上がった資料を見てビックリ。

これは・・・・・ちょっとムリです。このような企画書をクライアントに見せたら、なんてムダの多い資料なんだと怒られてしまいます。

私が企画書を見せる相手は、企業の経営層、事業部門の実務管理層、IT部門の全層のいずれかになることがほとんどですけど、 彼らに上の企画書を見せたら私の見識が疑われてしまうでしょう。

なぜダメなのか？

それは必要以上にレイアウトを重視していることで、1枚あたりのコンテンツ量の不足を招いていることです。 いまやタイムイズマネーが一般的になった日本のビジネスの現場では、「要するに何なのだ」 と言われないような効率的な企画書作成が求められているのが現状です。

上記のテクニックが許されるのはどういった業界なのでしょうね。広告業界に近いところなのでしょうか？　素朴な疑問です。

グリーンダムに関する以前のエントリー：
http://it-ura.seesaa.net/article/121862697.html

ZDnetの記事によれば、外部からPCを制御できてしまうようで、すでにゼロデイ攻撃コードが出回っています。

※ゼロデイ攻撃コードとは、セキュリティホールの対策ができていないうちに公開されてしまった攻撃プログラムのことです。

ミシガン大学の専門家は、「Green Damをインストールしてしまうと、ユーザーの訪問先となるウェブサイトは、 これらの脆弱性を突いて、コンピュータを乗っ取れるようになる」と述べています。

以下、一部文章を引用します。

『Green Damの公式ウェブページによれば、 依然として脆弱性を持っている最新のバージョン3.17は、すでに42万6138回ダウンロードされており、 それ以前の脆弱性のあるバージョンのダウンロード回数が717万2500回であることと併せて考えると、現在の状況では、 ウェブマルウェア悪用キットにこの脆弱性を利用する手段が組み込まれると、「ボットネット王国中国」のシナリオを、 理論上のものから現実になってしまう可能性がある。』

ミシガン大学の研究チームはミシガン大学の研究チームは、たった1日のテストでこの脆弱性を発見しましたが、 中国政府はこの問題点に気付かないまま製品の出荷を進めてしまったようです。

ミシガン大学の研究チームはGreen Damを実行している人に対して即時アンインストールを勧めていますが、「はい、そうですね」 と素直に応じる中国政府とは思えません。どのような対応を取るのか注目ですね。

『日米の認識格差については、こんな話もあります。日本企業はITに投資して減価償却の法定耐用年数（サーバーは5年）を経過した段階で、 「やっと償却が終わった、ようやくこれから利益を享受できる」と考える傾向があります。よって、10年、20年と古いシステムを使い続け、 時代の流れに対応できなくなった機能だけを追加していく方法を非常に好みます。ただ、 後付けの機能追加の繰り返しはシステム全体としてのバランスを欠き、 結果的には抜本的なシステム開発と比して開発期間もコストも割高になってしまうケースがあります。

一方、米国では5年を経過し、 償却が終了すれば当り前のようにバージョンアップやシステムのリプレースを行います。システム構築に1～2年を要するために、 彼らは新システムを導入してからわずか3～4年で、さらに利益性の高い有効なITソリューションを模索し続けているのです。 私の知る国内企業で“次世代ITシステム検討プロジェクト”を5年以上にわたって続けておられる企業があります。 10年以上使用したシステムを刷新するのに、検討するだけでさらに5年もかけるという話を米国企業のIT部門の責任者や役員にすれば、 彼らは爆笑するでしょう。

（中略）

一言で総括すれば、「必要最低限のIT投資」の認識が日米の企業で、 まるで異なるのです。日本企業は、「忙しくなった」「新しい法律ができた」「会計制度が変わった」「買収を行った」 「子会社を統廃合することにった」「ハードウエアが老朽化した」「システムサポートが無くなった」などなどと、 困った問題が表面化してからITに投資する「泥縄式スタイル」に陥っています。

15年前に海外とのビジネスなど皆無だった企業が現在は進出しているケースは多いと思います。15年前に戦略的IT投資として多言語・ 多通貨・コンソリデーション(統合）・コンプライアンス（法令順守） 対策に対応できるERP(統合基幹業務)などのシステムの導入を進めていた企業がどれくらいあるのでしょうか？

自分たちの会社は将来どの方向に向かって行くのか？という大方針があり、 そのためにどのようなITシステムを構築すべきかを考える――。このような習慣を持たない限り、日米の10年のIT格差は埋まりません。 IT戦略はそのまま企業の経営戦略です。』

製造業などモノを作っている企業では、サポート対象期間が終わってもサーバを使い続けているところが比較的多いと私も感じます。 けっして問題が発生していないわけではないのですが、現場の担当者がちょっとした工夫で凌いでしまっているのです。

でも、これって実は凄いことなんです。通常、6年目以降の保守は割増費用が掛かるのですが、 なぜ欧米企業の多くがその時点で新たな投資に動くかといえば、その方が人件費を含めたトータルコストが安くなるからです。 古い機能を使い続けていても競争力が劣っていくだけだから、新規投資をせざるを得ない。

逆に、割増保守費用を支払ってでも使い続けた方がトータルコストに優れるというのは、 古い機能を創意工夫でうまく活用しているからに他なりません。これって現場レベルのスタッフが優秀でなければできないことですよ。

後手後手のIT投資に回っているという状況も、見方を変えれば、 ギリギリまで追加投資をしなくても済むような資源効率の高い運用を実現していると言うことだってできます。 資源効率性が悪化するから新規投資を行う、それが典型的な日本企業の発想です。

この話、もう少し大きな視点で捉えると、父性社会と母性社会における考え方の違いであると言えるのですが、それはまた別の機会に。

ともあれ、ITというのはあくまでも企業戦略の一手段に過ぎないわけで、 手段を新しくしなければ目標を達成できないというのは視点が違うように思えます。目的を達成する上で、 まずは既存のリソースの有効活用を検討し、それでは不十分だと分かったときに新規投資を行うというのが正道でしょう。

欧米と日本のIT投資に対する姿勢の違いというのは、既存リソースの有効活用余地の違いだと私は認識しています。

NASAは数年前から地球温暖化の原因が産業活動にあるという仮説に疑問を提示してきましたが、 ここにきて確証を持ったという感じを受けます。

以下、レポート内容の翻訳（by Google）です。

一部の研究者たちは、太陽周期、地球の気候変動の影響と考えています。彼らは、 最近の周期的変化に温暖化の傾向属性。懐疑派は、太陽が少し手の確かな証拠に、最近の気候変動の主張している。

今では、意外なソースからの新しい調査報告書へのこの懐疑的な見方をするに役立つことがあります。 NASAのゴダード宇宙飛行センターのグリーンベルトは、メリーランド州からの研究では、過去1世紀以上の気候のデータを見ては太陽、 地球の気候変動に大きく影響していると結論づけています。レポートの先頭にまでさかのぼることができるの気候変動に基づいて、 太陽放射の産業革命は、証拠と結論づけている。

過去の研究では、太陽の11年サイクルを通過しています。サイクルのピークでは、太陽の活動、特に強烈な太陽の黒点の近くには、 太陽の暑さの中で発生する地球日なたぼっこ。ロバートCahalan 、ゴダード宇宙飛行センターの気象学者は、 "今のところによると、 我々にある大きな氷の年代は、完新世と呼ばれている期間の間。 "

トーマスウッズは、コロラド大学ボールダーでは、太陽の科学者は、 "摂氏約0.1度で、 太陽の中の太陽の最大値と最小涼しい時に少し熱い太陽周期に与える影響は、地球の世界的な温度の変動を終えます。太陽は現在、最低でも、 して、次の太陽活動極大期は2012年に期待されています。 "

この調査には、静かな太陽太陽エネルギーの1平方メートル当たり1361ワットに達し、地球の外側の雰囲気の期間中によると。 さらに強烈な活動の時代平方メートル（ 0.1 ％ ）より多くのエネルギー当たり1.4ワットをもたらした。

一方、 NASAの研究温暖化やパターンの冷却には太陽の影響力を認め、それを悪いトラックが鳴った。独自の証拠を無視すると、 男は一引数は、現在の温暖化の原因としては、太陽を置き換えていたパターンに戻った。多くの研究と同様に、この結論を以下になり、 問題の相関関係や不正確なデータモデリング手法の詳細に基づいている。

は、不換実際、ここでも、 NASAの自身の研究では、過去には、太陽の変化、気候変動を起こしていることを認めている。 さらにこの調査のメンバーは、 AGW理論のほとんどが熱心なサポートには、 太陽の将来の気候変動に大きな役割を果たすことができることを認めます。

---------------------------------------
ソース：DailyTech NASA Study Acknowledges Solar Cycle

地球温暖化を阻止するためにIT業界も色々な取り組みをしています。チームマイナス6％やグリーン調達、グリーンITなど。しかし、 そもそも人類の産業革命以降の活動と地球温暖化が無関係だったとしたら、こういった活動は不要になるのでしょうか？

以下、Yahooニュース一部引用です。

『中国で販売するパソコンに当局指定の“検閲ソフト” 搭載が７月１日から義務づけられる問題で、国内外のパソコンメーカーや販売店、ネットユーザーに混乱が広がっている。 ポルノなど有害サイトへの接続を遮断するとされるソフトだが、「搭載後のパソコン全体の品質を保証できない」と日系メーカーは困惑している。 ユーザーが組み立てるキット型パソコンの場合は搭載を免れるなど、問題も数多く残された中での“見切り発車”に、 国内のネット上では批判が渦巻いている。

　検閲ソフト搭載の義務化は、工業・情報化省が５月１９日付で関係部門に通達した。「グリーン・ダム・ユース・エスコート」と名付け、 青少年保護をうたってはいるが、有害サイトの定義はあいまいで、“フィルター” には政府や共産党を批判するサイトや発言も引っかかる可能性が高い。

　同省が４１７０万元（約５億９２００万円）で国内企業に発注したとされるソフトには、米ソフト開発会社のソリッド・オーク・ ソフトウエアが１３日、「ソフトの開発コードが盗用された」と主張し、差し止めを請求する考えを表明した。』
http://headlines.yahoo.co.jp/hl?a=20090620-00000131-san-int

つまり、中国でPCを購入すると、もれなく当局による検閲が行われるということです。 民主主義国家でこれをやると人権侵害になりますが、中国は他の国とは違うということを再認識させられるニュースですね。

今のところ自作PCは適用外ということなのですが、大多数の中国国民は共産党仕様のPCを購入せざるをえない状況だと思います。

まあしかし、「上に政策あれば、下に対策あり」という言葉がある中国です、きっと抜け道は多数用意されることでしょう。

ところで、実は私がこの記事で一番気にしているのは、引用箇所の最後の文。

ソリッド・オーク・ソフトウェアの開発コードを盗用した可能性があるとのことで、 このエントリーの冒頭で触れた中国当局へのソースコード強制開示が実現すると、こういった盗用が多発することが容易に考えられます。

（中国がジャイアニズム全開で理不尽な情報公開制度を実施）
　→ http://it-ura.seesaa.net/article/117995133.html

中国との取引があるIT企業は、2010年までに真剣になってチャイナリスクを考えるべきだと思いますよ。

このため、色々な会社や組織に提案する機会があるのですが、 その組織の方たちが自分達を呼ぶ際に使う表現が業界や会社によって結構違うのです。なかなか新鮮な表現もあり面白いので、 自分が所属する組織を表現するとき、どのような呼称があるのか調べてみました。

（会社、店、団体など）
・弊社／小社／本社／当社
　※店も同じ

（官公庁、団体など）
・弊省／本省／当省
　※庁、局も同じ
　※団体も同じ

（金融機関など）
・弊行／本行／当行
　※金庫、信用組合も同じ

（出版社／新聞社など）
・弊紙／小紙／本紙／当紙
　※誌も同じ

（学校法人など）
・弊校／本校／当校

（他団体など）
・弊会／本会／当会
　※当協会も同じ

とても基本的なことですが、改めて考えてみると新たな発見があります。

まず、「弊～」という表現は全ての組織で用いられています。「弊」というのは、自分を貶めたマイナスの意味を持った漢字であり、 謙譲表現です。外部の相手に対して話しかけるような状況や、それに類した状況で使われる文書の中で使うことが一般的です。

「本～」「当～」も自分達を示すのに使います。こちらはへりくだった表現ではなく、単純に自分達を示しているだけです。

ビジネスマナーの先生に聞くと、口頭でのやりとりは「弊社」、文面では「当社」で使い分けるのが正しいとのことですが、 電子メールのような口頭と文面の双方の性質を持ったコミュニケーションでは積極的に「弊社」という表現を使う人が増えています。また、 提案書を外部の人にプレゼンする場合、口頭で伝えることを意識して「弊社」という表現を使うのが当たり前になっていますね。

これは「御社」と「貴社」にも当てはまる状況です。

参考までに、「幣社」という誤字表現が散見されますが、「幣」は神様への貢物という意味がある尊敬表現です。「弊」と「幣」 はまったく逆の意味を持った漢字ですから、この誤字はとても恥ずかしい表現になるのでご注意あれ。 以下のサイトで詳しく説明しているのでご確認下さい。

（誤字等の館）
　→ http://www.tt.rim.or.jp/~rudyard/jiji022.html

少し特殊なのが「小～」という表現。私の知る限り、会社・店・新聞社・雑誌社でしか聞いたことがありません。私の個人的な感想としては、 この表現は「弊社」よりもさらに卑下した呼び方に思えます。だから、官公庁や金融機関では使われていないのでしょうか。 理由をご存知の方がいたらご連絡下さい。

社外の人に対する自組織の呼び方をご存知の方がいらっしゃいましたらコメント下さい。

『若い時にプログラムを書こう、必ず人生の豊かさにつながる』
http://itpro.nikkeibp.co.jp/article/Interview/20090527/330760/

前半ではプログラミングの重要性を説いて内製率を高めたいと述べているあたり、 NTTデータの社長にしてはずいぶんと思い切った話をする方だと感心していたのですが、話が「24時間開発」 に移ってきたところから同社らしい考え方が垣間見えました。

『倍速、できるものなら3倍速でやりたい、というお客様に応えるために、 開発プロセスの抜本改善と、ソフト生成の自動化に取り組んでいます。色々やった結果、開発工数の3割はほぼ削減できることが見えてきた。 もう少し頑張って開発工数を5割削減したい。

（中略）

　画面はほとんど自動生成が可能で、ロジックのところができないけれども、 ある程度チューニングしておけばロジックも自動生成できる。手で作っていたから試験が必要だった訳で自動化すると試験も劇的に下がります。  

（中略）

　要件定義と設計の方も今、色々なツールを作っています。結局、 いくら自動生成しても、要件に問題があって手戻りが起きてしまうと倍速どころではなくなる。なるべく手戻りを起こさないような仕組みで、 要件定義での見やすさ、モックアップをぱぱっと紙芝居のように見せるとか、そういうツールがそろってきました。

　これがうまくいくと、要件定義の精度が上がり、 それにかける時間も今よりは少し短くなる。ただし、要件定義まで短くしようとすると、問題を起こしやすいから、 3なら3でしっかり時間をとり製造工程で減らせばいい。

　今お話したようなことをなんとか後1～2年で実現させたい。 さらに開発プロセスの実態を自動モニタリングする仕組みを一緒に盛り込んだりするので、ざっと40億円ぐらいかけようか、ということです。』

つまり、ソースコード自動生成のフレームワークをベースにして、ウォーターフォール型の開発を世界３極（インド、ブラジル、日本） で回していきたいという話です。

いわゆる、内製率を下げる典型的なケースじゃないですか。

このことは、以下の発言からも分かります。

『例えば、日本で8時間設計したら、インドかヨーロッパで8時間製造し、 それを南米に持っていって8時間試験をする。日本から見ると、朝来ると、自分が設計したソフトが製造され、 一通りの試験が終わって手元に来ている。 』

冒頭でプログラミングが重要だと述べながら、結局日本の社員には設計書を作るところまでしかやらせない、 と理解してよいのでしょうかね。

純粋に、話に一貫性が無くてとても気になりました。

結局、内製率を高めるのであれば、自社内に工数単価の割安な開発グループ会社を設けて、 若いうちは出向させてプログラミングの経験をさせるというやり方しか残されていないのではないかと個人的には思っています。残念ながら、 NTTデータはコストが高くなりすぎて、末端の仕事を社員にやらせると採算割れを起こしてしまうのです。

最後に、はてぶにとても興味を引いたコメントがありました。

『 プログラミングは製造業でいう設計。本当の製造はmakeだけ。 ／ 製造業に 『設計を世界3拠点輪番で24時間行う。CADファイルはネットワークで共有。』 なんてアホなことを言ってる会社はない。 大部屋ワイガヤこそ大事。』

確かにその通り。そして、システム開発で経験を積んできた人が行き着く答えであると思います。

それに、3拠点で時間差開発を行うくらいなら、同じ人員を東京と大連とマニラに配置して、 3拠点並行開発をやった方がリアルタイムコミュニケーションがスムーズになる（時差があまりない）ので効率的だと思いますよ。

最初からインドとブラジルに社員を抱えて余っているならともかく、新設するならオススメしません。 これは外資系のSIerやコンサルティング会社がすでに辿っている道だったりします。

日本屈指のSIerであるNTTデータだからこそ、これら企業を反面教師にして、 世界に名だたるグローバルカンパニーになってほしいです。

※美味しんぼで海原雄山がそう言っていた気がします。

同様に、私達が普段から使っているPCキーボードも長らく使っていると、その表面に指の脂が次第に染み込み、 何とも言えないテカテカな様に変化してゆくのです。

普段から仕事でPCに触れている人はもとより、ワンストロークで地道に打つのをモットーとしている人にも、 親指キーボードに慣れすぎて普通のキーボードに戻れない体になっている人でさえも、 キーボードのどこかしらのキーは指の脂がしみこんでテカテカしているのではないでしょうか。

私の場合、テカテカしているキー第1位は「N」キーでした。

日本語入力するときに最も頻繁に出てくるのが「ん」だからなのだと思います。アルファベットの入力でも結構使うところですよね。

以下、このようなランキングになっています。

2位：　「A」
3位：　「Enter」
4位：　「Alt（左側）」
5位タイ：　「S」「F」「E」「I」「O」「Space」

私はワードやパワーポイント、エクセルで文章を入力する機会が多いため、自然言語で使用頻度の高い文字、 または変換に利用する特殊キーのテカテカ具合が進んでいるのでしょう。

皆さんのキーボードはどの文字キーがテカテカしていますか？

基幹系システム、特にホスト絡みの調達を経験されている方は、その不透明な提案金額に苦労した経験をお持ちではないでしょうか。

今でこそオープン系の開発案件は透明度が増してきましたが、数年前はこれさえも不透明な金額で契約がなされていました。 このことを理解するのに最適な記事を4年前のCIOマガジンで見つけたので抜粋します。

『同社（ある大手製造業）は、コンサルティングからアプリケーション開発に至るまでの全工程を、大手ITベンダーに委託していた。 それまでのフェーズ（約1年間）で、同社は数千万円をそのベンダーに支払っていたのだが、 開発段階に入るに際して出された見積もりは十億円を上回る金額であった。この見積もりを承認し、発注を担当する購買部では、 この十数億円の妥当性に疑問を持ったのである。

しかし、システム開発の工数の妥当性も、SEの単価の相場も、 購買部では評価するすべがない。情報システム部に確認しても、それぐらいだと言われると返す言葉を持っていない。そのときに購買部が発した 「情報システム部は、まるでベンダーの手先のようだ」という衝撃的な言葉は、今でも耳から離れない。

かくして、開発フェーズの見積書を客観的に評価することと相成ったが、 購買部から見せてもらった見積書は、「システム詳細設計一括：○億円、ハードウェア一式：○億円……」といった様式の、 驚くほどずさんなものであった。』
（CIOマガジン：SIerを取り巻くこれだけの不満）
　→ http://www.ciojp.com/contents/?id=00002477%3Bt=12

ひどいですよね。でも私が今出くわしている案件もこれと同じレベルです。 こんな見積りを押し通そうとしてくるベンダー担当者には参ってしまいますが、私の場合は幸い、 様々な指標や比較対象を手元に用意しているので、なんとか費用を分解して提示してもらえそうです。

しかし、そういったデータが手元に無く、ベンダーがもっともらしくプレゼンをしてしまえば、 調達にあまり詳しくない担当者は抵抗する術もなく言いくるめられてしまうことだと思います。

2009年現在であれば、オープン系システムの見積りに必要な客観的な指標はいろいろと公開されています。 CPUスペックや一般的な可用性ポイント、作業工数やその割合など、JUASを初めとするいくつかの機関を調べればすぐに分かります。

しかし、ホスト導入に関する客観的な指標というのは、開発生産の観点でファンクションポイントやライン当たりのステップ数、 MIPSなどを用いて比較することしかできません。こういったデータはなかなか一般公開されないことに加え、 基本的にホストシステムはオーダーメードが基本になりますから、それも当然だと言えましょう。

ベンダー側からすると、単価を開示することは企業競争上、譲歩できないポイントだと主張するところもあるかと思いますが、 一般的な単価が公開されているこのご時世では、いつまでもそういった秘密主義を続けていると、 競争力云々の前に顧客からの信頼を失うことになるでしょう。

はてなダイアリーではこのような指摘をしている方がいます。

（日本のIT業界はなぜ重層的な階層構造をとっているのか）
　→ http://d.hatena.ne.jp/ktdisk/20090201/1233493964

競争原理と淘汰のメカニズムが十分に働いていない理由を簡単に紹介しておきます。

『結局のところ最終的にサービスを受ける企業側にきちんと下請けを評価する能力とノウハウがないことが一因としてあげられる。 担当者が無能とかそういう単純な議論ではなく、 流動性を保つためにそういうことができる機能を外だしせざるをえなかったというのが実情だろう。

（中略）

今親密に付き合っているパートナーと一緒に開拓するのではなく、 ターゲットとなる商圏で既に顧客とリレーションのできているパートナーを探すほうがパートナー戦略としては正しい、との話を聞いたが、 確かに日本において既存の取引関係を短期的な経済合理性だけで突き崩すのは難しい。』

たしかに過去の付き合いを重視するクライアントは多いですが、それを当たり前と思いすぎているベンダーは、この先、 生き残っていくことは難しいでしょうね。

ただし、国を商売相手にするなら、また別の話ですがね。
（皮肉です）

このとき役に立つのが交渉学のBATNA（バトナ）という考え方です。

BATNAとは、Best Alternative to a Negotiated Agreementの略で、 最初に提示した条件で交渉が決裂した時に採用する最も良い代替案という意味です。一言で表現するなら「次善の策」でしょうか。

交渉学では、相手のBATNAを知って対策を立てることで、BATNAを使えない、もしくは使っても意味が無い状況に持っていき、 自分を有利な立場に置くことを考えますが、 ファシリテーターにとっては意見が対立する人々の間を取り持って議論をまとめるためにBATNAを使います。

例えば、次のようなシチュエーションを考えてみましょう。

『営業部門のA課長はどうしても取りたい案件があり、開発部門で発言力の　あるB主任に引き受けてもらいたかったが、B主任は、 この案件によって　開発部門の作業負荷が高まり、デスマーチになる可能性が高いと判断し、 　3ヶ月の納期延長が認められなければ引き受けないと突きかえした。

B主任は、この案件を引き受けることは可能であったが、この案件がダメ　になっても現在取り組んでいる別案件の仕事でしばらく忙しいので、 当面の仕事には困らないが、A課長が納期延長に1ヶ月でも応じてくれれば、引き受けても良いと考えていた。
　
一方のA課長は、B主任が納期の2ヶ月延長で妥協してくれるなら何とかクライアントを説得してみようと思っていたが、 どうしても3ヶ月延長を主張するなら、今回は案件を諦め、今後はB主任に仕事を回すのをやめようと考えていた。』

交渉が成立しなかった場合の選択肢がBATNAですから、このケースでA課長とB主任のBATNAを整理すると次のようになります。

　A課長のBATNA：
　　　「今回は案件を諦めるが、今後はB主任に仕事を回さない」
　B主任のBATNA：
　　　「今回は協力せず、別案件の仕事に集中する」

議論の落としどころを見つけるためには、双方のBATNAを無効化して議論のテーブルから逃げられないようにすることが重要です。 このケースでは、A課長とB主任のBATNAを無効化するならば、次のような状況に持っていく必要があります。

　A課長のBATNAを無効化：
　　　「今後もB主任に仕事を依頼せざるを得ない状況を作る」
　B主任のBATNAを無効化：
　　　「別案件の作業負荷を下げ、A課長の依頼を断る理由をなくす」

1つ目は、特定領域の開発は全てB主任が絡むようにするといった方法が考えられますし、2つ目は、 B主任と開発部門が担当する一部業務を別の人間に付け替えることで実現できるでしょう。 こういったアクションは事前に様々な調整が必要になりますから、それを根回しで対処するのです。

こうすると、A課長もB主任も議論から逃げる理由を失うので、あとはお互いが譲歩できる範囲で刷りあわせを行うことになります。 ここでZOPA（ゾーパ）というものを考慮します。

ZOPAとは、Zone Of Possibe Agreementの略で、交渉学では交渉可能価格帯という呼ばれているものですが、 ここでは「譲歩による合意が可能な範囲」と理解して下さい。

B主任は納期の延長が1ヶ月でも認められれば受注しても良いと考えていました。つまり、 B主任のZOPAは納期の1ヶ月以上の延長になるわけです。

一方、A課長は2ヶ月程度の延長ならクライアントに嫌な顔をされても何とか説得できると踏んでいたとしましょう。すなわち、 A課長のZOPAは納期の2ヶ月延長までです。

ということは、納期延長が1ヶ月以上2ヶ月以内であれば両者が合意できることが分かります。

一方で、A課長、B主任ともできるだけ良い条件を通したいとも思っています。このとき、自分のZOPAを相手に知られてしまえば、 相手は自身のZOPAと照らし合わせ、最も自分が利する選択肢を主張するでしょう。

事前にBATNAが潰されていれば、相手は交渉に応じざるを得ません。そうなると、無駄な駆け引きで会議の時間を浪費し、 時間切れに達しなければ結論が出ないという不毛な状況に陥ることもあり得ます。

もしファシリテーターが意見対立者それぞれのBATNAとZOPAを探り当てることができていれば、 皆が納得できる折衷案を速やかに合意することができるでしょう。

※詳細はEnterpriseZine連載の記事をご覧下さい。
http://enterprisezine.jp/article/detail/1417

「仮想環境に重要なネットワーク・サービスを移行させた企業はかなり多い。しかし、多くの組織が適切な監視ツールを導入していないという現実には驚かされる。適切なツールがないとアプリケーションのパフォーマンスが不必要に低下し、ネットワーク管理チームが問題解決のため何時間も作業をしなければならなくなる。」

「これまでCitrixは、簡易版の「XenServer Express Edition」を無料で提供してきたが、新たに無料化するXenServerでは、マルチノード管理、複数サーバーでのリソース共有などの機能が利用できるという。また、ラボ自動化、動的プロビジョニング、「Cirtix StorageLink」を利用したストレージ統合、ワークフロー・オーケストレーション、高可用性などの高度な機能は、Essentialsで有料で提供する。」
　→ http://enterprise.watch.impress.co.jp/cda/foreign/2009/02/24/14990.html

簡単に言うと、「パワーポイントの脆弱性が見つかったので、Windows版の修正パッチを発表したら、犯罪者の仲間呼ばわりされた」 ということです。

従来、セキュリティ修正プログラムをリリースするまで関連情報を一切公開しないというのが暗黙のルールだったそうですが、 今回のマイクロソフトの対応はそれに違反しているとのこと。

以下のメッセージをもってセキュリティアナリスト、 フランツェン氏がマイクロソフトを非難しているとコンピューターワールドで述べられていました。

『「Office for Mac 2004」と「Office for Mac 2008」にも同様の修正プログラムが必要とされているにもかかわらず、 MicrosoftがWindows版のほうを優先して修正プログラムをリリースしたことで、脆弱性の詳細が公になってしまった。これは、 責任ある情報公開というルールに反する行為』
http://www.computerworld.jp/topics/ms/145590.html

ISCに掲載されている原文はこちら。
http://isc.sans.org/diary.html?storyid=6379

マイクロソフト・セキュリティレスポンスセンターの責任者は次のように回答しています。

『エクスプロイトのサンプルを分析しても、 Mac版のエクスプロイトは作れないということがはっきりしていた。Mac版のセキュリティ・ アップデートが完成するまでWindows版のリリースを伸ばすことはしたくなかった』

ちなみにISCに掲載されているオンライン投票では次のようになっています。
https://isc.sans.org/poll.html?pollid=262&results=Y

・Mac版のパッチを無視したのは無責任　：　47％
・同社は最良の判断を下した　：　4％

ステークホルダーの動きをよく考えて行動しなければならないことを再認識させられた出来事で、 何でも手早く提供すれば良いというわけではないという話でした。

• 結局、PGの上がりはSEルートで明確な道を分けたせいで、要求を要件に落とせるのはいるが、設計者がいない。 OO設計なんてそれこそ上から下まで、経験し尽くさないと出来ないため、日本にその技術者がいない。 単純にインタフェースだけ決めて個人に投げるから。個人の力量次第で出来がバラバラ。 詳細設計のドキュメントを作らなくなったのはまさにそれが理由。
  
  基本設計に、出力項目とテーブルのカラム名しか書いてない。単純なWebアプリでフレームワークで相当な階層構造なんだから、 出力項目とカラムが結びつくわけないだろう。
  
  糞システムなおかげで保守が発生し、保守性がない糞のおかげでリプレースが発生することで、飯が食える。
  
  これがシステム開発の真理
  
• 海外じゃ基本設計レベルで、
  概念上のエンティティと、詳細なエンティティやライフサイクルを書く。だからそもそも詳細設計なんていらない。 ていうかDBの方が後になる。
  
  日本じゃDFDで要件定義して、DB考えて画面とデータ結びつけた基本設計と、 糞ソースから自動生成した誰の役にも立たないJavaodcが詳細設計。
  
• 日本のIT企業には不思議な会社があってな。エンジニアが一人もいないんだ。全員が営業。で、何をやっているのかというと、 自分とこより大きいSIや同等規模の会社からくる「案件票」っていう紙を他の会社に回すのが仕事。紙を回すと、 その紙がまたいろんな会社を巡りめぐって最終的に「この案件にこの人を投入しよう」という事になる。 すると一番最後に紙を受け取った会社のエンジニアが紙を回したのと逆順に会社に面接していって、 最終的には大手のプロジェクトに投入される。
  
  IT業界は、案件情報と人間を転がすだけのブローカーが跋扈してる暗黒世界だ。