Index: [Article Count Order] [Thread]

Date:  Wed, 6 Jun 2001 13:02:31 +0900
From:  "Hirohide Yazaki" <firo@....jp>
Subject:  [XP-jp:01975] Re: XP=A.Davis+E 番外編
To:  <extremeprogramming-jp@....jp>
Message-Id:  <036601c0ee3d$826d49b0$3701a8c0@FIRO>
References:  <001501c0ee2d$49688720$3e3b6c0a@handava50j> <20010606123830.14945760.1364882534@....jp>
X-Mail-Count: 01975

矢崎です。

----- Original Message -----
From: "ITO" <itohitoshi@....jp>
To: <extremeprogramming-jp@....jp>
Sent: Wednesday, June 06, 2001 12:41 PM
Subject: [XP-jp:01973] Re: XP=A.Davis+E 番外編


> マーケティングではないのですが、先日読んだ日経新聞に
> IBMが製品開発にWEB上で自由に参加できるという
> 方式を採用したという記事が載っていました。
>

矢崎です。私も関連する話を1つ。

先日 「問題解決プロフェッショナル」斎藤嘉則著 ダイヤモンド社
という本を買って、パラパラっと読んでいる最中なのですが、
ちょっとおもしろい記述がりました。

この本はソフトウエアをテーマにしている本ではなくて、ビジネスにおけ
る問題解決をテーマにしているものです。その中で仮説思考という章が
あって、以下の記述がありました。

問題解決についてもスモールリリースで、フィードバックで、あるいは問題
はよくわからなかったり、常に変わるものだから意思決定そのものも「変化
ヲ抱擁」しなければならない、ということですね。
XPの適用を上司や顧客に説得するときの材料になるかもしれません(って、
そんなに甘いものじゃないか^^;;)

#なお、著者は元マッキンゼーの人です。

<引用>
P38
3 「ベスト」を考えるよりも「ベター」を実行する

背後の理由やメカニズムを同時に把握しながら結論を出す。しかし、
どの時点を結論として具体的実行に移していけばよいのかという疑問
がつきまとう。それは、とにかく実行に移せるレベルでの結論ということ
なのだが、その場合、実行することにより、いまよりもベターな状況が想
定されれば、とにかく実行に移すことを考えればよい。実行した人の勝
ち、と思っていい。
 なぜかというと、まず、ビジネスの現場には絶対的正解はありえない
からだ。
<略>
 環境の変化が激しく、競合の打ち手も日々変化するビジネスの現場では
1つだけの正解などないし、まずは競合のベスト・プラクティスをベンチ
マーキングしてからなどと、マーケット・リーダーの表面的な動きばかりを
意識しすぎては、どこかで足元をすくわれる。
 現在の置かれている状況に何か問題があるとすれば、ベストは難しくて
も、何かしらベターな解決策は必ずあるものだ。さらに、だれでも「ベター
な解決策」であれば考えられるはずだ。ベターな解決策を見つけたらすぐに
実行すればよいのである。そして、どんどん軌道修正すればよい。
 ベストな策というものは、追いかければ追いかけるほど時間もかかるし
<略>
ベストが見つからないまま時間だけが過ぎ、
<略>
時すでに遅し、というケースもある。
<略>
もしそのベター案を批判する人がいたら、その人にもっと優れた代案を出し
てもらえばいい。
<略>
ベターな解決策でも現場を動かし始めると、じっくりとベスト案を求めて
分析するよりも、精度の高い、すぐに役立つ情報が自動的に入ってくるの
だ。したがって、結果的には成果に到達する時間が短縮されるだけでなく、
成果自体も当初の期待値を上回り、一石二鳥となる。GEのジャック・ウェ
ルチ会長の言う「走りながら解決する」というのは、企業活動を止めて問題
を解決するわけにはいかないというよりも、むしろ走りながら解決したほう
が非常に効率的で、よい結果が出やすいということを言っているのだ。
<略>
成功した創業者が何年か後に、その完成された理念と素晴らしい事業コンセ
プトを体系づけて講演することはよくあるが、明確な事業コンセプトのほとん
どは必ずしも始めにありきではなく、試行錯誤と現場での実践の中から生ま
れている。つまり、大成功したビジネスマンでさえ、ベストが本当に見えた
のは最後の最後ということだ。
</引用>