■

いやー、まいったよ。

多目的ホールって、グダグダするための場所かと思ってたら、実際はサブセッションとかいうのがフツーにはじまるし。こっちはブースに座ってモンハンでもやってるかくらいに思ってたんだけど、そんな雰囲気どこにもない。

なんかしんないけど、コミッター軍団（通りすがったたださんがそういってた）が、こっちでたむろってるし。

それにしても、マカーが多いね。予想はできたけど。

あと、ガイジンも多いね。楽しめてんのかな？

  • -

お、イケザワさんのトークスが終わったね。尻切れになっちゃったけど。

だから、自分はスゲーイケザワさんを尊敬してるんですよ。イケザワさんの熱意がなければtoRubyはなかったんですから。

だからね、結局、自分がどれくらい強く変わりたいと思うかなんですよ。強い思いが行動に変わって、それが人を動かす、人を変える、社会を変えるということなんですよ。

■

チームには、ボケというか、いじられ役というか、
そういう人物が必要なんだよな。


でも、そういう人物をどう評価するかは一般に難しい。
だって、そういう人物の能力や効果は数値化できないから。


よくいわれる2:8問題にしても、そういう視点が欠けているのは
明らかだし。


確か「デスマーチ」だったと思うけど、普段はフラフラしてる
けど、ケンカの仲裁が上手いっていう人物が描かれていた。


今っぽい言葉でいえばソーシャル・スキルってヤツだけど、
そんなカッコイイ言葉だけで表せられないものがあるよな。

  • -

http://itpro.nikkeibp.co.jp/a/biz/shinzui/shinzui0926/shinzui_03_1.shtml?ST=enterprise

先に「当初想定通りの品質と納期とコストで情報システムを手に入れられたか
どうかではなくて」と書きました。いくら想定通りにシステムを作れても、経
営上効果を生まなかったら設備投資としては失敗です。ところが、悲しいこと
に、情報システムの場合、そもそものシステム開発作業が想定通りに進まない。
極端な場合、「想定もしていなかった時間とコストを投入しても、まともな品
質のシステムを入手できない」といったことが起こりえるのです。費用対効果
を見る以前に、設備自体を作れないわけです。ここがまず、経営者が「ITはど
うも解らない」という理由です。


だから、先払いは止めましょうとXPはいっています。と同時に、納期や品質で
はなく、そのシステムがどれだけ顧客のビジネスに価値をもたらしたかを重視
します。


ここで「納期や品質」と書きましたけど、ビジネスに価値をもたらすのであれ
ば、品質が重要でないこともあり得ます。つまり、品質というのは、あくまで
も顧客のビジネスによって基準が設定されるべきものです。

ITの仕事をずっとしていると、こうした恐ろしい状況に慣れてしまいかねませ
んが、IT産業以外に目を向けて見ましょう。私達ユーザーは、自動車を買う場
合、その車がカタログ性能どおりに動かないということを心配する必要はあり
ません。ましてや、納入された車のキーを回して、エンジンがかからないなん
てことは想像もしませんし、実際そうしたことはまず起こらない。100万円で契
約した車が、途中で200万円になったり、1000万円になったりするなんてことは
考えもしませんし、そんなことは絶対にない。車のような完成製品ではない例
ではどうでしょう。注文住宅の契約後に「引渡し日が1年以上遅れる」とか、土
台ができたばかりの段階なのに「完成費用が当初の倍に膨らむ」と通告される
こともまずありません。


長年ITに携わっている方がこのような見方をされることが非常に残念です。こ
うしたことは何もITに限ったことではなく、たとえば映画業界でもよく起こる
ことです。他にも当初の予算をオーバーしてしまったプロジェクトは建築業界
などにも多くあるでしょう。


この文章のあとすぐに：

ITの世界では最近、次のような問題も起きています。情報システムの基盤に
使っている基本ソフトと呼ばれる製品の保守サポート期限が切れる、新しい基
本ソフトに入れ替えて欲しい、とソフト・メーカーが通告してきます。ところ
が、言うとおりにすると今まで使ってきた業務アプリケーション・ソフトが使
えなくなる。やむを得ず、基本ソフトの入れ替えと同時に、業務アプリケーショ
ンを作り直す。これを車に例えますと、おたくが今使っているエンジンを取り
替えなさい、ついては車の内装から何から全部やり直すので、その費用も負担
しなさい、ただし乗り心地や車の性能は前と何も変わりません、といった話で
す。こんな奇妙なこともIT以外の世界では起こり得ないのではないでしょうか。


という文章も書かれています。でも、こういうこともIT業界だけでなく、他の
業界でも起きています。たとえば、昔よく聞いていたレコード。今聞こうと思っ
てもレコードプレーヤーは入手しにくくなっていますよね。VHSやベータといっ
たビデオテープも同様です。自動車だって、古くなりすぎたら、故障に対応し
てくれるとは限りません。修理しようにも部品がなくなっている可能性があり
ます。


先日読んだ記事では、こうした問題に対応するために、トヨタはできるだけ独
力でシステムを構築するように方針を決めたそうです。自分はそれが現実的な
解とは思いませんけど、それも1つのやり方でしょう。あるいはオープンソー
スを利用するのも考えられますよね。オープンソースなら、最悪でもソースは
自分で管理することができす。

私が考える役割分担はこうです。我々ユーザー企業は、ビジネスにおけるIT 投
資の費用対効果を考え、どんなビジネスをして、ITをどう使ったらいいかを考
え抜く。できあがったシステムを使いこなしてビジネスを遂行し、所定の効果
を出すところに力を注ぐ。


一方、ITや情報システムの開発については、ITベンダーに責任をもって担当し
ていただく。情報システムの開発局面に必要とされるスキルとして、要件定義、
システム設計、ソフト開発、全体のプロジェクトマネジメントなどがあります
が、これらはすべてＩＴベンダーが持っているべき専門スキルと考えます。要
件定義とは、どういうシステムを作るのか、諸条件を整理することです。この
要件定義に基づいて、実際に開発するシステムを設計し、ソフトを開発します。
要件定義、設計、開発、テストといった各工程の進捗状況を把握し、問題があ
れば対処するのがプロジェクトマネジメントです。


自分は役割分担を明確にすることが必要だとは考えていません。役割を分ける
ことで、顧客のビジネスの成功と開発側の成功とが別問題になってしまうから
です。顧客のビジネスの成功こそが唯一の成功であり、顧客のビジネスの成功
こそが開発側の成功でもあるべきです。


そういう視点に立てば、要件定義を顧客がやろうが開発側がやろうが些細なこ
とだと気づくでしょう。もちろん、開発側に要件定義のテクニックは必須です
が、そこにはユーザの協力が欠かせません。お互いがビジネスを理解せずに要
件定義ができるでしょうか。

ITに関することは全部、IT産業の担い手であるITベンダーの方が全責任を負う。
「プロの俺たちがなんとかする」という気概で取り組んでほしいのです。


今まで書いてきた話と矛盾するかもしれませんけど、こういう気概は当然必要
です。開発側が技術のことをおろそかにしてしまっては本末転倒です。けれど
も、お互いが長くシステムを使っていれば、開発側だけでなく、顧客でもその
システムの設計というものがわかってくるはずです。そもそも設計というのは
ビジネスの価値と切り離せないのですから。そこで、もし顧客から開発に設計
についてアドバイスできなかったとしたら？ システムはビジネスの価値から離
れていってしまいます。


冒頭で「ITは費用対効果が見えにくい」と書かれています。でも、当たり前で
すけど、投資というのは必ず回収できるとは限りません。設備投資しても、そ
こで作る商品が売れなければ、その設備投資はムダになります。さらに、費用
対効果というのは、過去の数字と比較してはじめて意味のあるものになります。
新しいIT案件をはじめる前、あるいは導入した後に、現在の費用というものが
きちんと計れるものなのでしょうか。


繰り返しますけど、開き直っているわけではありません。やり方を変えましょ
うといっているんです。初期投資は少なく、顧客と開発側がともにビジネスの
価値というものを理解しつつシステムを大きくしていきましょうと。

また、IT関連の基本技術は、“個別最適の究極化”を基本的な性質として持つ
ものであります。このため、差異化を競争戦略とする事業領域のソリューショ
ンのケースでは、この基本的性質を十二分に認識したうえで自社のIT適用を決
定すべきものであります。


したがってITソリューションはユーザー企業自らが、詳細に、克明に、実現可
能な形で描ききることによってのみ、実現できるものです。ITはその目指すべ
きソリューション・ツールの選択肢にすぎません。失われた10年の間に、我々
ユーザー企業は、自ら果たすべき本来の役割の多くを、ITベンダーとパッケー
ジ・ソフトに過度に依存してしまったのではないかと考えています。


例によって我田引水ですけど、だからこそ企業自らがプログラマを抱え込めと
いっているのです。ITはその企業のアイデンティティを補強するものでなけれ
ばなりません。アイデンティティの維持補強を外部に任せるものではないでしょ
う。

一方、市場変化は結構激しいものがあって、旅行業界も激しいのですが、変化
に対応しようとすると、今まで作ってきた情報システム基盤がかえって足かせ
になってしまう。旅行業界を見ていると、まったく新規ビジネスモデルを作っ
た新興企業のほうが、はるかにうまく情報システムを使っているように見えま
す。


今後、JTBはこういうやり方を考えています。老朽化してきた、いわゆる基幹情
報システム基盤の再構築をする必要がある。その時に新しいビジネスモデルを
まず先に考えて、このビジネスモデルを前提としたIT投資を考え抜く。要する
に古いものを単純に移し変えたところでしようがないわけですから。


まず第一に、IT投資を考え抜くためにはITのことをよく知らなくてはなりませ
んよね。それは「役割分担説」と矛盾します。


第二に、「考え抜く」といいますけど、その間にもライバルはどんどん新しい
ビジネスモデルで挑んできますよね。どうしますか？


歴史というのは資産であって負担ではないはずです。今となってはレガシーと
なってしまったシステムといえども、まだ価値を生み出しているからこそ使わ
れているわけです。歴史を資産として活かすためにも、システムを刷新すべき
ではありません。「再構築」というなら、本当に今のシステムを使いながら再
構築するべきです。顧客はそれを求める権利があり、開発側はそれに応える義
務があります。


「失われた10年」という話が出ています。この10年というのは、顧客にとって
開発のイニシアチブが失われていた10年でした。XPでは顧客を車の運転手にた
とえます。システムの方向を決めるのは顧客であり、開発側は車やハンドルで
す。お金を出せば目的地まで運んでくれるようなプロジェクトはどこにもあり
ません。

  • -


ビルド終わんねぇ (笑)

■

当たり前ですけど、XPのpractice全部を実施できたとしても、
そのプロジェクトが成功する保証はどこにもありません。


XPに限ったことではなく開発全般においても、A, B, Cという
手順を踏めばプロジェクトが成功するといった方程式めいた
ものはありません。


人の組織と似たようなものです。人をかき集めれば組織として
成り立つというわけではありません。もし各人がバラバラに
動いてしまえば、その組織はすぐに自滅します。その組織を
維持するためには、理念や歴史といったものが必要であり、
そういう基盤があればこそ組織が組織としての意思を持つ
ようになります。

■

「察する」ようになることが大切。


わざわざ観察しなくても、微妙な変化にすぐに気づく。


メンバの顔色、チームの雰囲気、顧客のビジネスへの気持ちの変化。


矛盾するようだけど、察するためには普段から観察していることがやっぱり大切になる。
観察を繰り返すうちに「観」が取れるのだろう。