インターネットが及ぼす変化とは？

　「フォーサイトクラブ・セミナー「ウェブ社会『大変化』への正しい対応・間違った対応」梅田望夫さん講演ログ」を読むと、以前書いた「インターネットは高速道路」の内容を煮詰めている気がする。

【１】インターネットは能力増幅器

　計測データや考え方のフレームワークは、Googleで検索すれば、少なくとも集めることは出来る。インターネットは能力増幅器、というフレーズは鳥肌が立った。
　インターネットをうまく利用できれば、簡単に飛び級できる。梅田さんの話によれば、若い人ほど、そのツールをうまく使いこなせるし、それによって過去の世代よりも大きな可能性を秘めていること。

　ただ、これから問われるのは、知識よりも、論理的に自分の考えを組み立てて、仮説を作り出す能力だろうか？

【２】インターネットが人間関係の精神的距離を狭める

　上記の内容は、大前研一と似たようなことを言っていたなあと思う。
　「考える技術」を立ち読みしたけれど、こんな一節があった。
　大前研一の理論を研究している人達との会合で、ニュージーランドやヨーロッパでも、彼だけでなく奥さんの趣味まで知っていたことに彼は驚き、そして、初対面なのに色んな話が出来て、以前から友達だったような懐かしい雰囲気を感じた、と。
　この感覚は僕も分かる。メーリングリストやインターネット上のコミュニティで知り合った人達とネット上でやり取りした後、リアル世界で会ってみると、あまり違和感なく、以前から友達だったように、すぐに親しくなれる。

　インターネットがもたらす波及効果はまだまだあろうが、この2点が僕には、自分自身の経験も込めて、大きく感じる。

「リーンソフトウェア開発」～アジャイルとウォーターフォールを繋ぐミッシングリング

　とある勉強会で「リーンソフトウェア開発」第4章「できるだけ速く提供する」を発表した。
　レジュメを作りながら、そして、議論しながら、色々と考えさせられる所があった。

【１】「リーンソフトウェア開発」の読者層は、オブジェクト指向や反復型プロセスを知らない計画主導プロセス経験者である

　XPの解説本を読んでも、原則やプラクティスの本質が何なのか、ペアプロやイテレーションなどのプラクティスがどのように関連付けられているのか、分かりにくい。
　この本では、２２個の思考ツールを使ってアジャイルの本質を説明している。4章では、制約理論や待ち行列、リトルの法則などを使って、計画主導プロセスのどこに弱点があるか、アジャイルプロセスで気を気を付けることを明らかにしている。
　オブジェクト指向開発者やアジャイラーが当たり前に思っていることと、計画主導経験者がどうしても理解できないギャップを埋める本ですね、と仰った人がいたが、その通りだと思った。

【２】アジャイル開発の優位性を、もっと理論的な説明で補強できないか？

　制約理論や待ち行列、リトルの法則などを使って論理的に説明を組み立てているのは面白かった。
　でも、細かく疑問をぶつけてみると、アナロジーは分かるのだが、しっくりこない点がある。自分が説明できるほど理解し切れていないのかもしれないけど。
　もう少し理論的に補強できないだろうか？　また、他の理論を使って、説明を補強できないだろうか？

　久しぶりに面白い本だったな。

概念に正しい言葉を当てはめないと混乱の原因になる

　要件定義のプロセスで、コンサルタントが作った要求定義書から不明点を洗い出している時、「概念に正しい言葉を当てはめないと混乱の原因になる」ことを経験した。

　とあるシステムの要件で、データを論理削除する処理があったのだが、「この文脈では論理削除と言うべきではなく、法律用語に従って、廃棄とか廃止と呼ぶべきだ」と指摘を受けたことがある。
　論理削除という言葉では、削除という意味合いが強すぎて、本来は、データが別の異なる状態に移ったことを強調すべきだ、ということだった。

　要件定義では、用語集を作るのが大事ですが、その理由をもう一度再認識した。

　ネーミングは難しい。
　だが、XP祭りで会ったXPerたちはネーミングが上手かった。
　例えば「ふりかえり」「ペアボード」「ニコニコカレンダー」「あんどん」のように。

　以前、数セミで、数学者よりも物理学者の方が概念に対するネーミングがうまい、彼らは抽象的な方程式に隠れている物理的意味を知っているからだろう、みたいな記事があったのを思い出す。

　最後に関係ないけれど、ウイスキー「Early Times」がありますが、どのような言葉を当てはめるべきか？
　僕は、「早すぎた日々」などとトンチンカンな訳をした。
　後輩の子は「若気の至り」と訳していた。さすが文系出身(^^)

ITの技術革新はOSよりもWebソリューションへ移っている

MSが次期WindowsOS　Vista　を来年に売り出すらしいが、盛り上がってないように見える。
理由は、OSの技術革新の衝撃が薄くなっていて、むしろGoogleのようなWebソリューションへトレンドが移行しているからではないか？

WindowsOSやOfficeのバージョンがUPしたからといって、我々ユーザの環境が劇的に変わるわけでもない。バージョンアップを煩わしいと皆呟いている。
ActiveDirectoryの導入で余計に手間がかかっていないか？

むしろ、Googleが生み出すサービスの方が我々のWebの使い方そのものを劇的に変化させている。
例えば下記のサービスがある。

１．容量１GものWebメールサービス　GMail
２・デスクトップ検索サービス　GoogleDesktop
３．地図検索サービス　GoogleMaps

【１．容量１GものWebメールサービス　GMail】
GMailをまず使ってみて驚いたのは、勝手にリフレッシュし、メール一覧を更新してくれること。
さすがAjax。

【２・デスクトップ検索サービス　GoogleDesktop】
以前まで、ローカル内のテキスト・Office・PDFファイルを検索できるようにするために、Namazuをインストールし、定期的にバッチファイルでインデックス検索させるようにしていた。
ActivePerl＋Kakashi＋Namazuを入れて、日本語で検索できるように設定するために結構手間取った。
GoogleDesktopなら、ファイルだけでなくメールまで検索で来てしまう。

【３．地図検索サービス　GoogleMaps】
GoogleMapsは面白い。
市販の地図情報システムは今だにC/Sアーキテクチャの古いシステムが多く、有料のため使っていて楽しくない。
記事「渺望と俯瞰　：keyhole　が　3D地図と検索を関連づけるか：Google　Earth　スタート」ではGoogleMapsの威力を下記のように説明している。

（引用開始）
(前略)
GoogleMapを見ればわかるが、日本の地図表示・検索サイトよりも遥かに豊かな情報が関連付けて閲覧できる。
１．Mapまたは衛星写真
２．現在のレストランなどのWebコンテンツ
の２つを、検索エンジンが、位置座標と関連付けてView+スクリプト表示しているだけである。
一方、多くの一般の地図サイトは、なんと時には有料で、サーバーに入力させて、（労力と費用を使って）、ほとんどのレストランが参加していないレストランガイドサイトとなっている。
このGoogleMapと同様の機能をMyサーバー上に、実現できるのが　GoogleWebAPIである。思わぬアイデアが出現しそうなので、お楽しみである。
（引用終わり）

つまり、日記を手軽にUpできるBlogのように、自分オリジナルのレストラン地図とか、自分の地区の選挙マップとか作れる。

例えば、GoogleMapsEditorを使えば、こんなに簡単に地図が作れてしまう。

なにわのお笑い劇場：ワッハホール

他にも、AmazonのWebサービス、ライブドアが提供したWikiサービス、Skypeもワクワクする。

次から次へと現れるWebソリューションに触れると「IT技術は、コスト削減のようなつまらないことに使われているが、本来は、新しい産業を生み出すことに使われるべきだ」とXP祭り2005で講演したMSの萩原さんの意見を思い出させる。

XP祭り2005の公式記事

XP祭り2005の公式記事は下記が一番詳しい。

http://itpro.nikkeibp.co.jp/article/NEWS/20050905/220618/
XPの祭典「XP祭り2005」開催，「顧客にすらわかっていない要求をいかに引き出すか」が大きなテーマに

XP祭り2005の感想

9/3にお台場で開かれたXP祭り2005に行ってきました。
面白かったー。
朝5時に起きて新幹線で東京へ向かい、夜12時まで講演＋懇親会＋2次会で騒いだので、1日がすごく長く濃かった。
代表の倉貫さんほかスタッフの皆さん、感動をありがとう。

受けた刺激があまりにも多すぎて整理し切れていないので、感想を箇条書きで残す。

【XP祭りの会場　お台場】
「お洒落なお台場」のイメージがあったが、場所はちょっと離れたオフィス街。
会場は、円形劇場の座席に講演者が舞台で発表するため、場の雰囲気がどんどんヒートアップしていく感じだった。
スタッフによると200人もの来場者が来たとのこと。遠く沖縄（！）から来たエンジニアもいた。
大阪から来たエンジニアは、僕を含めて6人ぐらいだろうか？

【平鍋さんのProject Facilitation】
最近よく聞く「見える化」のお話。
ソフト開発はプロセスも成果物も見えにくいという難点を解決するために、こんな手法を考えてみました、という話。

ビルドが失敗したら赤ランプが付く「ソフトウェアあんどん」。
開発者の気分を1日の最後に赤と青でカレンダーに張っていく「ニコニコカレンダー」。
こういうツールがあると、開発者のモチベーションも上がるだろう。何よりも楽しい。

劇団ぺけぴー（XPを日本語で読み直したみたい(^^)）による朝会のアンチパターン例は面白かった。
・一人の話が長い
・リーダーがメンバーの話を遮る
・誰も喋らない
朝会だけでなく会議でも、場の雰囲気が建設的でないケースによく当てはまる。

PFの価値や原則、アンチパターンの解決方法など、もう少し詳しく聞きたかったなあ、というのが率直な感想。

【ひがさん】
今日のひがさんはオールバックの金髪に、黒Tシャツとジーパンでカッコイイ(^^)

講演する時は、会場の雰囲気に呑まれないように「スター」になりきるために、いつも外見を大きく変えるらしい。他の講演者がひがさんのなりきりメガネを借りてました。

業務マニュアルを作ることで上流工程を進める話は興味深かった。

僕の現場では開発プロセスそのものが標準化されていないため、ひがさんのやり方がおそらく一番しっくり来る気がする。
きちんと仕様書が揃った環境でないとプログラミングできない若手がいるし、マニュアルや仕様書が最終的に納品物に含まれるから。

でも、話はXPにあまり関係なかったかも。

【ディスカッション】
豆蔵の荻本さん、MSの萩原さん、Seasarのひがさん、関さん、平鍋さんを交えて、言いたい放題のディスカッションも面白かった。

ひがさんも関さんも萩原さんも皆揃って、フレームワークは嫌いだ、という発言はビックリ！
理由は「俺様が作ったフレームワークを、下々のPGに押し付ける」のが嫌いらしい。
「メンバーがフレームワークとアプリケーションのチームに分かれるのが嫌だ」
「アプリ開発者が見つけたFWのバグをすぐに直せない。だから、そのFWのバグを回避するようなぐちゃぐちゃのプログラムを書いてしまい、後でメンテナンスするのが大変」
という関さんの話が最も率直だった。

MSの萩原さんの話が興味深かった。

「私はソフトウェアアーキテクトであってITアーキテクトではない」
「アジャイルはソフトウェア工学ではない。工学的基盤の上でアジャイルのプラクティスがあると理解している」
「今の私の興味はSoftware Factoriesにある」

「個々の日本人は技術者として能力は高いが、集団になると質が落ちる」
「欧米人はマネジメント能力が比較的高い」

ソフトウェア開発の動機は何ですか？というコメンテーター倉貫さんの質問に対し、MSの萩原さんの答えが一番印象に残った。

「ITを使って革命を起こしたい」
「現在は鉄道が普及し始めた時代と同じ。百貨店は鉄道という産業が興隆して作られた。鉄道によって、消費都市と生産都市が結ばれ、都市の拠点に百貨店が作られて、新しい産業ができた」
「ITも同じで、ITの普及によって新しい産業を作り出せるはず。今はコスト削減とかつまらないことにITを使っている」

「ソフトウェアで世界を変えたい」と言った(はずの)ビルゲイツの言葉を思い出させる。
ITエンジニアもこれぐらいの気概を持たないとね。

最後に、劇団アンプラーズ（Anti-Practiceからひねたらしい）の活劇が面白かったので、2コマほど載せます。関西人ならボケツッコミを入れて、もっとひねることができるかも。

弟：あにきー、ペアプロって何だ？
兄：ペアプロっていうのはな、ペアで入る風呂のことなんだよ。





The End

IT業界は残業が多いのですか？

　今日、母校の大学へ会社説明会に行ってきました。
　3回生の人から
「IT業界は残業が多いと聞いたのですが、本当ですか？」
と尋ねられて、返答に正直困りました(^^;)
　この業界のビジネスマンは、後輩から上記の質問をされた時、どのように答えているのだろうか？

　僕の少ない業界経験では、1年に1回は修羅場が津波のようにやって来る。終電帰り、休日出勤、徹夜の開発が1ヶ月くらい続いて、本番システムリリース後、ようやく落ち着いて元の生活に戻る。初めて徹夜で作業させられたときは、皆さんこんな安月給でよく仕事しているなあ、と他人事のように思っていた。

　この業界、1ヶ月200時間労働なんて当たり前。
　はぶさんの本
では「月40時間程度の残業が3ヶ月続いたくらいで過労死なら、この業界の人間90%は死んでいます」と書かれていますが、同感。
　青色ダイオードの中村修二さんは、その業績にもかかわらず低収入だったため、「スレイブ中村」と言われたそうだが、IT業界で働いている人達も奴隷と言われても仕方ないのかもしれない。

　学生さんには、「確かに残業する時はありますが、普通は1時間程度の残業で退社できますよ」とかわしておいたが、最初から最後までそんなプロジェクトは滅多にない。
　学生さんにこれだけIT業界の評判が悪いと、今後、優秀な頭脳はこの業界に入って来ないかもしれない。

＃余談ですが、最近の日本に犯罪が多いのは、日本人男性の働きすぎに原因があるんじゃないかと思う。
＃つい20年前までは、こんなに残業して働いている人はそんなに多くなかったのでは？
＃親子夫婦そろって朝ご飯、夕ご飯を毎日取っている日本人の家庭って、今の日本に存在するのだろうか？
＃多分、存在しないと思う。
＃殆どの日本人の家庭は壊れていると思う。多分、普段は母子家庭になっている。最近は共働きが主流だから、たまたま一つの住居に住んでいるだけで、皆バラバラに生活していないか？
＃そんな生活は人間的（むしろ、本能として自然）なのだろうか？　子供の成長にとって悪い影響しか与えていないのではないか？

　経営者だけでなく、現場のエンジニアも今の環境を改善していくことを考えないと。

システム開発のボトルネックはメインフレームに有り

　システム開発のボトルネックは、メインフレーム（ホスト）の存在そのものにあるのではなかろうか？
　JavaでWebシステムを開発していると、いつもそんなことを感じてしまう。

　どこの大企業に行っても、必ず10年以上稼動し続けているメインフレームが既に存在している。メインフレームなしでは企業活動そのものが存続できないようだ。最近の流行であるそのメインフレームをオープンシステムへリプレースすることは、どこの大企業でも殆どありえないように見受けられる。
　そもそも何故メインフレームが存在するのか、本当の理由を僕は知らないが、とあるBlogでは、「企業の基幹システムは最終的に財務諸表を作るために存在する」と書かれていた。
　しかし、財務諸表や損益売上決算書などは、オープン系システムでできないのだろうか？

　普通、どこの大企業でも、メインフレームは顧客データや請求・契約などの会計に関するデータを管理している。つまり、企業にとって死活的に重要なデータは、必ずメインフレーム内で管理している。
　いくらOOAをフルに使ったWebシステムを作ったとしても、Webシステムは、集めた受注データをホストへ送り、入出荷や請求のデータをホストからもらうだけ。業務的には、入り口のシステムに過ぎない。
　Webシステムがダウンするのは当然困るが、企業活動そのものが止まってしまうわけではない。

　僕がメインフレームを毛嫌いする理由は、OO技術者にとって、メインフレームがブラックボックスだから。メインフレームでデータをどのように加工し出力しているのか、全く意味不明だから。

　更に、ホストとのやり取りのために、無駄なインターフェイスが必要になる。
　例えば、受注データをリアルタイムにホストへ送信したり、月次請求や四半期決算のデータをホストから特定の日に受信する処理がある。
　仕組みとしては、ホストはバイト長データしか扱えないため、バッチプログラムがバイト長データを変換してRDBのワークテーブルに一旦保管し、Javaが扱うテーブルへ移し変える。そのプログラムは、典型的なCのプログラムで、オブジェクト指向以前の古い設計に基づく。しかもテストしにくい。

　オブジェクト指向をフルに使った設計やオープンソースのフレームワークを適用したオープン系システムを開発しようとしても、結局、メインフレームとの整合性を取るためのシステムテストがボトルネックになる。
　何しろ、受け入れテストに必要なシナリオやテストデータを洗い出し、実際の業務をシミュレーションするために、1週間とか1ヶ月も時間を費やす。オープン系システム内部で閉じたシステムなら、システムテストは楽なのに、ホストと連携するテストを行うために、無駄なコストがかかる。

　「メインフレームはオープンシステムに取って代われる」という記事を随分昔から見てきたけれど、未だに実現されているとは思えない。それらの記事は、単なるデマだったのだろうか？

【参考記事】「5年後，メインフレームはなくなる」　日経コンピュータ2003年3月24日号

　IT業界に入って、結局いつもぶち当たる壁は、ORマッピングとメインフレーム。
　それらを再考し直すと、結局、メインフレーム・RDB・オブジェクト指向プログラムの3つはどれも思想的に全く異なるシステムであって、それらのインターフェイスを合わせる為に、ORマッピングやバッチプログラムという無駄な中間レイヤーが必要になる。
　企業システムとは、結局、これら３つの相容れない混合システムであるべきものなのか？
　多分そうでないはず、と思うし、皆そう感じているのではなかろうか？

　メインフレームが今もなお存在する理由は、IBM・NEC・富士通・日立等のような大手ベンダーが過去あるいは今までメインフレームを製造し続けてきたからだろう。
　メインフレームというハードを中心にしたビジネスが長らく続き、そのビジネススタイルからなかなか脱皮できない所に原因がある気がする。

大いなる力には、大いなる責任が伴う

　プロジェクト管理者にいざなると、割り込みの仕事に忙殺されて、モチベーションが落ちてしまう時がある。
　そんな時に、自分の使命（？）を思い出させて、奮い立つ言葉を見つけた。　

　「大いなる力には、大いなる責任が伴う」

　スパイダーマンが亡き叔父さんから言われた言葉。
　カッコイイ。。(^^)
　確かスパイダーマン１で、スパイダーマンとなった主人公の乱暴な振る舞いに見かねて忠告した場面だったように思う。
　
　プロジェクト管理者になると偉くなった気がするが、実際はそんなことはない。自分がプログラミングすれば早いのに、メンバーにお願いしてプログラミングしてもらっている。理由は、リーダーがプログラミングに携わるとチームが回らなくなるから。
　過去のプロジェクトを思い出しても、リーダー自らが実装していたプロジェクトは殆ど破綻していた経験がある。

　自分ならメンバーの2倍以上のタスクはこなせる自信はあるが、それを内に秘めて、チームの人数分の責任を感じて、チームを回している。
　その責任の重さに疲れる時があるけれど、その言葉を肝に銘じていると自分がスパイダーマンになったような気がして、何故かやる気が出てくる。

　しかし、自分も単純だよなあ(m_m)

「ソフトウェア企業の競争戦略」

　「「ソフトウエア企業の競争戦略」」の本が、ここやあそこに紹介されていた。
　内容は、ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」である、ということで興味津々。しかし、立ち読みしてみたが、いまいちピンと来なかった。

　ソフトウェア・ビジネスは製造業や小売業などのサービス業と異なるのではないか、と漠然としたイメージは常々持っていたが、本質はまだ分からない。
　僕の少ない現場経験を整理すると、システム開発は普通の製品開発と異なるプロセスなのに、現場の環境が古いため、ちぐはぐな印象をずっと持ち続けている。
　例えば、いくらJavaでWebシステムを作ったところで、請求処理など一番大事な基幹システムはメインフレームで動かしているため、データ転送で無駄なインターフェイスを作ったり、オブジェクト指向技術が徹底できなかったりする。
　更に、Webチームとメインフレームチームに分かれているため、Webチームがいくらオブジェクト指向に則った開発プロセスを応用しても、旧式プロセスでやっているメインフレームチームと共同作業せざるを得ない。
　又、日本のITビジネスは土建業界のような下請構造で成立しているため、いくらアジャイル開発をやろうとしても、ウォータフォール型プロセスから脱却できない。
　この辺りの矛盾をきちんと説明しているのか、と思ったがよく分からなかった。どこかにいい本はないのだろうか？