今日は久し振りにお客さん先のサーバールームで、サーバーへのソフトウェア導入作業をしました。普段はあまりやらないんだけど、緊急で対応が必要だということで。
コンピュータ系な人はみんな知ってる通り、サーバールームってのは空気は乾燥してるし、気温が低いクセに隣のラックから熱風が吹いてくるし、耳障りなファン音(しかもサーバーごとにいろんな周波数があって共鳴したりしてる)が鳴り響いてるし、本当に気が滅入る空間です。1時間いたらすぐに頭痛くなった。
それに、こういうサーバー構築系の作業って、再起動やインストール中などの待ち時間が長くて、作業量自体は少ないのに時間がものすごくかかる。お客さんのサーバールーム内だから、ネット接続とかもできないし。
人それぞれ合う仕事・合わない仕事があると思うけど、僕は非効率な環境を強制されることが一番苦痛だと再認識。逆に、自分でやり方をコントロールできれば、ある程度難しいことを要求されても、結構前向きに取り組めたりする。そういう仕事をアサインしてもらえるように、努力・工夫していかないとな。
Microsoftがエンタープライズ向けのクラウド・コンピューティング・サービス「Windows Azure」を発表しました。解説記事はたくさん出ているけど、とりあえずこの2つを読めば全体像は理解できます。
【レポート】PDC2008 - 米Microsoft、クラウドサービスOS「Windows Azure」発表 | ネット | マイコミジャーナル
クラウドOS「Windows Azure」と対応サービスを発表、MS － ＠IT
Google App Engineのような.NETベースのアプリケーション実行プラットフォームに加え、Exchange/SharePoint/SQL Serverのようなエンタープライズ・サービスも用意されていて、MSが出しうるクラウド・コンピューティング・サービスとしては、これ以上ないカタチのものを出してきたな、という感じです。さすがはレイ・オジー。
また、MSはWeb版のOfficeについても発表。
［PDC 2008］ついに「ブラウザ版MS Office」が登場、無料Webアプリの波に抗しきれず：ITpro
これももちろんユーザーとしては諸手を挙げて歓迎だし、意地悪な見方をすれば、この記事のタイトルのように「まあMSとしてもそうせざるをえないよな」と言えなくありません。
が、MSのこの戦略、どの程度の勝算があるものなのか、読み切るのが難しい。死中に活を見出したのか、それとも単に流れに逆らえなかったのか。言い方を変えると、この新しいビジネスモデルで今までのように儲ける算段があるのか、それとも今までのようには儲からないのを承知でこうするしかなかったのか。
いずれにせよ、MSがここまではっきりと方針を打ち出したことで、ユーザー・アプリケーションのみならず、エンタープライズ・コンピューティングの世界でも、クラウド化の流れがいよいよ本格化してくるのは不可避でしょう。
僕がコンピュータの仕事をし始めて10年ほどですが、エンタープライズ・コンピューティングの世界は間違いなくこの10年で一番のドラスティックな転換期にさしかかっていると思います。正直言って、この先数年後、SIerやS/W,H/Wベンダーのビジネスモデルがどうなるか、さらには我々コンピュータ技術者にどんな仕事があるのか(もしくは無いのか)、全く読めません。こわいこわい。
経済情勢もめちゃくちゃだし、しばらくは動向を注視しつつ、ファンダメンタルなスキルを身につけながら、動勢を見極めたいとおもいます。
4年前に登場したときは結構騒がれたソフトウェアファクトリー。
この本も読まなきゃと思いつつ、いつかソフトウェアファクトリーという言葉もあまり耳にしなくなり、気になりながらも読まずじまいになっていたところ、@ITでかなり詳しい解説記事(＠IT：連載：次世代開発基盤技術"Software Factories"詳解)を発見。書いてるのは萩原さん@MSなので、内容の信頼性も高い。ボリュームも結構なもので、全部読むと2時間くらいかかる。
で、読んでみた。
うーん、ユースケースとフィーチャーの関連チャートとか、なかなか面白い点もあるけど、全体的な感想としては「現実のベストプラクティスではなく、机上で練り上げられた方法論」という印象。共通部分の開発原資をどう確保するのかなど、ビジネスの現実を無視した文字通りの「工学的手法」。複数プロジェクトを一社内で行う組み込み開発ならともかく、SIではちょっと現実的じゃない気が。DSLでの開発っていうのもどうかなー。DSLは開発生産性は理論上は高いかもしれないけど、開発者の要員確保とか保守体制とか教育とかモチベーションとか、色々考えると疑問。
世間的にも、ソフトウェア部品の再利用よりは、要求定義を中心に変化にフレキシブルに対応できるアジャイルなアプローチの方が主流になってるし、今から本を読んだりする必要は無いなという結論。でもなんとなく全体像くらいは見えたので、この@ITの記事くらいは読んでおいてよかったと思います。
というわけで、冷静になって「やっぱめんどくさいからやめとこ」と思う前に(そしてビールの酔いが醒める前にｗ)ここで宣言しておこう。期限は年内ね。＞俺
仕事の話です。コンピュータの話です。「うまく動かない！」と今週ずーっと悩んでいた問題が、製品のパッチ適用で解決しました。
合計20時間くらいは試行錯誤した気がするなー。疲れた。まぁ、パッチ適用なんてとりあえず最初にやれよという話なんだけど、コーディングとか設定とかにいまいち自信が無かったので、色々手を動かしてしまった。
==以下、ごく一部の方々のご参考までに==
WebSphere Application Server V6.0からJMSでWebSphere MQにアクセスするには、fixpackの6.0.2.5以降が必要です。JCAのサポートがこのバージョンかららしいのです。古いバージョン(6.0.0.x)でも、管理画面を見てる限りでは問題なく利用できそうに見えてしまうところが罪作り…。
最近、某製造業のお客さんのプロジェクトに、技術支援として参画しています。
そこで、今までシングル構成だったWebアプリケーション・サーバーを、(具体的にはWebSphere Application ServerのNetwork Deploymentという製品を使って)負荷分散構成にするにあたり、アプリケーションのアーキテクチャー上問題が無いかという検証をしているのですが、これが問題ありあり。
シングルサーバー構成だったときには露見しなかったアーキテクチャー上の問題、特にトランザクション設計の不備が、並列処理になることによって、これでもかというばかりに露見しています。
本来１トランザクションで処理すべき処理のUOWが複数に分割されていたり、本来独立しているはずの処理が何となく１トランザクションで処理されていたり。
普通のメソッド呼び出しのような感じで、EJBを起動していたりするから、本来は独立しているはずの100件のデータをまとめて引数としてEJBに渡し、そこで100件の処理が１トランザクションとして起動しちゃうような設計になってたりするんですよね。
なお、近頃「トランザクション」という言葉がすごくいろんな意味で使われていますが、ここで言っている「トランザクション」は、分離不可能な一連の処理のことです。単なるWebのアクセスのことじゃないです。
この辺のエンタープライズ固有の所は、@ITとかWEB+DB PRESSとかそういうところにはほとんど出てこないので、勉強するのが大変です。前から気になっているこの本、一度は読んでみるべきなのか・・・。
最初ここのシステム構成の説明を受けたとき、「いまどきEJB?」と(正直)思ってしまったんですけど、やってみるとかなり勉強になります。
今日は仕事でスキル不足のあまり恥をかいたので、ビールの勢いも手伝って、憂さ晴らしに以前から読まねばと思っていた技術書を、Amazonで衝動買い。
後者の方は日本語訳の購入も考えたんだけど、Amazonの書評を見ると訳が相当読みづらいらしいので、原著を購入。決してかっこつけたわけではありません！
机の上の飾りにならないよう、きっちり読まねば。
調べ物をしてた時に発見。
IBM WSDD | 使ってみたくなるEJB - 第2回 - Japan
エンジニアたる者、「自動的に」という説明を読んだら「勝手に」と読み替えて、その裏で何が起こるのかを確認する心構えが必要だと思います。「自動的に」というのはとても耳あたりのよい言葉ではあるのですが、お客様に「自動的に」とご説明する時には、裏で何が起こるのかを必要な範囲で理解してからするべきだと思うのですが、いかがでしょうか・・・？
うむー。名言だ。
先週のことですが、会社で開催された船川淳志さんのセミナーに参加してきました。船川さんはグローバルインパクトという会社の代表で、コンサルタントをしながら各方面でセミナーを開催されている方。以前はNHK教育テレビで「実践・ビジネス英会話」という番組の講師もされていたそうです。
テーマは「グローバルリーダーのマインドとスキル」。リーダーシップやスキルというものを、グローバル時代のなかでどう捉えていくかというお話です。グローバル時代というと漠然としていますが、そんなに大風呂敷を広げた話ではなくて、英語を使って外国人とビジネス・コミュニケーションする際に注意すること、みたいな感じ。船川さんはとにかくエネルギッシュな人で、お話はほんとに面白く、3時間のセミナーでしたがあっという間でした。
お話の中で一番印象に残ったのは、外国人のエリートと堂々と渡り合うには、「英語力と同時にIQLが必要」という話。IQLというのは、Interactive/Quick/Logicalの略。つまり、相手の話の要点を的確に捉えてそれに反応し、すばやく、論理的な話をする能力ということです。
これは難しい。英語力というものは勉強すれば何とかなるとは思うんですが、このIQLのような能力はファンダメンタルな「頭の回転の速さ」に基づく部分が大きいので、一朝一夕にはできるようにならないように思います。
でも、実際外国人のエグゼクティブや有名人なんかを見ていると、スピーチでもインタビューでも普段の会話でも、話が圧倒的にうまい上に相手の質問をうまく料理して答える術を知っているし、いわゆる「ユーモア」のセンスはあるし、話の論理展開もすっきりしていてわかりやすい、と感じます。やっぱり、こういう能力がエリートにとって必須のものであり、エリートを目指す人は学ぶべきスキルである、というコンセンサスがアメリカにはあるんでしょう。
セミナーの最後に、この本をおみやげとしてもらいました。ざっと見てみたところ、セミナーでお聴きした内容のかなりの部分がこの本にまとまっているようです。
もし可能であれば、どなたにもぜひ船川さんのセミナーを聴いていただきたいのですが、そういう機会が無い方はこの本でも十分エッセンスは理解できるんじゃないかと思います。
某転職系サイトいわく、プログラマ35歳定年説はあまり言われなくなったものの、「30代前半は、過去の資産に頼っているとあっという間に取り残される危険性のある年代であることは変わらない。」のだそうです。
確かに自分自身を考えても、それなりに知識と経験が蓄積されてきていて、その知識と経験をベースにすれば、しっかりとした勉強をしなくても、新しい技術がなんとなく理解できてしまうことがよくあります。
これは危険だ！！
今は、去年の知識と経験で今年の技術を理解してますが、そのうち10年前の知識で最新技術を理解しようとするようになるかもしれません。「基本の部分は変わらないんだよ！」なんて言い張ったりして。自分が取り残されているのを自覚しながら、強がりとか負け惜しみとしてそう言っているんならまだしも、そんなことを続けててるうちに、自分が最新技術を理解できてるのかできていないのかすら、判断がつかなくなっていくかもしれません。こわい。
過去の知識の蓄積があるからといって、現在の努力が免除されるわけでは決してないのですよね。過去の蓄積と現在の努力(つまり継続的な努力)の両方があって、初めて立派なベテラン技術者になれる、と。
20代の頃と比べると、コンピュータ技術について「もっと勉強しないと」という焦りが、だいぶ薄れてきた気がします。もう少し頑張らねば！
録画してあった、NHKスペシャル「デザインウォーズ ケータイ開発の舞台裏」を観ました。
とても濃い内容でしたが、なかでも印象に残ったのがNECの開発現場。NECでのケータイ開発は、以前は機能を盛り込めるだけ盛り込んで、デザインは最後に決める、というスタイルだったそうです。ところが機能での差別化が飽和状態になった今、ユーザーの8割はデザインでケータイの機種を選ぶため、デザイン主導で開発が行われるようになってきた…という話。
その開発会議では、デザインチームの持ってきたデザインをもとに、技術チームがどこまでできるかを確認するわけですが、その中でこんな問題が持ち上がっていました。
まず、「画面はできるだけ大きくしたい」「本体はできるだけ薄くしたい」というデザインチーム。技術チームは「それは難しい」と答える。
また、開発の当初から、ボタンにタッチセンサーを使う前提で議論が進んでいたのですが、技術チームがタッチセンサー前提で様々な作業をしてきた後で、デザインチームが「やっぱり通常のボタンにしたい」と言い、それに対して開発チームは「この段階で議論する内容ではない」と、今までの努力を無駄にする方針変更に反対する。
ここに見られるのは、マーケティングと開発が分離した組織において普遍的な、とても根源的で構造的な問題です。
マーケティングはユーザーのニーズを盾に技術チームに要求を出します。技術チームが頑張っていることはわかるのですが、その詳細まではわからないので、「技術チームにはもっと頑張る余地があるはず」と信じて、より高い要求を突きつけます。
一方技術チームは、ユーザーのニーズが重要なことは理解しながらも、マーケティングからの際限の無い要求に答え続けることの難しさに苦しみます。特に、小型化・軽量化に代表される、乾いたぞうきんを絞るような競争では、実際問題として努力による改善の余地がゼロにならないため、自己申告以外に努力の限界を設定しづらいのが悩みです。もちろん、モチベーションの問題も重要です。
この問題に対するもっともシンプルな回答は、マーケティングと技術を同一人物(チーム)がこなすことです。初期のWeb2.0サービスなんかは、こういう体制から生まれていることが多いと思います。
しかし、大企業ではそういう体制はあまり現実的ではありません。となると、マーケティングと技術がどれだけ視点を共有できるか、が問題になってきます。
一つは、マーケティングが技術チームの苦労を理解すること。ただ、マーケティングが「もう少し本体を薄くしてほしいんだけど、技術的に難しかったら無理しなくていいよ」なんて言ってたら、できあがったケータイは誰も買ってくれないでしょう。
となると、やはり技術チームがマーケティングの意識を持つ、ということが要求されてくることになります。実際、番組中のNECの議論でも、最終的にはマーケティングの方針に技術が従うことになっていました。
まあどう考えても、行き着く先はこういう形しかないと思います。技術者のはしくれとしては、なんだかため息が出てしまいます。
ユーザーのニーズを考えるマーケティング。ユーザーのニーズと技術の両方を考えないといけない技術チーム。
こうなると、製品開発における優先事項が技術からマーケティングにシフトしつつある現在、マーケティングの重要性は言うに及ばずですが、いかに技術者のモチベーションを高く保つかが非常に重要になってきます。いくらマーケティングがユーザーニーズをつかんでも、技術者がモノを作らないことには商売にならないのですから。
ソフトウェア開発で言えば、古典的な営業とSEの問題、たとえば「お客様の要求とその変更」と「開発期間・コスト」の対立が同じ構造だといえます。
で、まとめ。技術の優先順位が相対的に下がりつつある今だからこそ、技術者の高いモチベーションが必要になるのではないか、ということ。技術者のモチベーションは、僕の勤め先でも(たぶんどこの会社でも)問題になっていますが、やはり相当にクリティカルな問題なんだな～と、番組を観て(苦悩するNEC技術チームの顔を見て)再認識させられました。
日経SYSTEMSの最新号(8月号)に、「すごい現場」というコラムが載っていました。著者はITコンサルティング会社を経営されていて、書籍も多く執筆されている方です。
そのコラムの内容を要約すると、こんな感じです。
日本からのオフショア開発を請け負う中国人の会社社長。1ヶ月ぶりに会ったら、げっそりと痩せていた。日本のベンダーから発注された仕事が修羅場だったらしい。スタートが遅れたのに納期は変わらず、仕様変更はいつまでたっても収まらず、相談しても「顧客の要求だから何とかがんばれ」だけ。あまりの悲惨さに開発メンバーは夜逃げしたが、社長は探し出して連れ戻した。また開発メンバーのストレスが溜まっていたので、定期的に大宴会を開き、酒を飲ませた。社長本人は下戸で一滴も飲めないにも関わらず。
そしてこのコラムの結びの言葉。
「このような泥臭いマネジメントを粘り強く行うことでチームをまとめ、無事に納品にこぎつけることができた。システム開発の人間臭さは、中国でも日本でも変わりがない。オフショア開発で納品されたプログラムの裏にはこのようなドラマもあるのだ。
僕は、こういう人がいる限り、システム開発の現場から残業や休日出勤やメンタルヘルスの問題が無くなることは「決して」ないだろうな、とつくづく感じました。
このコラムに共感する人が多くいることは僕もわかってはいますが、こういう状況を「無事に納品にこぎつけることができた」とか「ドラマ」と表現する神経には、少なくとも僕は全く共感できません。
「システム開発の人間臭さは、中国でも日本でも変わりがない。」のではなく、今まで日本で末端のSEに押しつけられていた労苦を、そのまま中国人SEに押しつけただけだにしか思えません。
ソフトウェア開発に関する「名著」と呼ばれる本はたくさんあり、僕もまだ全然読めていない本が山ほどあるんですが、そういった名著を一つでも読むたびに、僕は「自分が疑問に思っていたことの多くには、ちゃんと賢い答えやアイデアがあって、それはいろんな形で世の中に公開されていて、単に自分の勉強がたりなかったんだな、もっと勉強をしないといけないんだな」とつくづく感じます。
僕は、もし度重なる仕様追加でプロジェクトが火を噴いているのであれば、夜逃げした人を捕まえたり酒を浴びるほど飲ませるよりは、プロジェクト管理とか要件定義とか交渉術とかの知識やスキルを身につけ、なんとか問題に対処できるような能力を身につけたいと、少なくともそういう考え方をする人間でありたいと思います。
もちろん、それでも目の前の仕事はこなさないといけないし、よく言われているように万能の「銀の弾丸」は存在しないわけですが、それでも「そんなふうに頭使うよりは、徹夜と気合いでしのぐ方がマシ」と考えてしまったら、SEというよりも知識労働者として終わりなんじゃないかと僕は思います。
徹夜や休日出勤を「ドラマだ」と思う人本人が徹夜や休日出勤をするのは、勝手にやっていただければ結構ですが、自分の部下に徹夜や休日出勤をさせた話を「ドラマだ」と思うような人に管理されているSEは、本当に気の毒です。
(注：このコラムでこれを「ドラマだ」と言っているのは著者であり、中国人社長本人がどう感じていたかはわかりません。)
「徹夜はドラマ」派な方の多くは、今までずっとそういうやり方で仕事をされ、「成功」してきたのでしょう
(ちなみに、このコラムの著者は、以前は今の僕の勤務先で働いておられたようです)。そして、そういう方は「上品なやり方では、システム開発は決して成功しない。結局最後は努力と根性だ。」とおっしゃるかもしれません。
でも僕は、そうまでしないと成功しないような仕事なんか、やる価値は全くないと思います。
もちろん、自分で夢や目標があって、それに向けていろんな物を犠牲にしてがんばる人は、それはすばらしいと思います。でも、繰り返しますが、自分の部下にいろんな物を犠牲にさせてがんばらせることを「ドラマだ」と思う人たちは、本当に有害だと思います。
仕事のせいで体調を崩したりメンタルヘルスで苦しんでいる人を見ると、心の底から僕はそう思います。
C/C++はともかく、Adaですか…。Adaなんて、「プログラム言語の歴史」とかでしか見たこと無いです。防衛分野では今でもそれなりに使われているんでしょうか。
あと、金融系でSEをやっている人なら誰でも知っているとおり、金融機関では今でも普通にCOBOLやPL/I(アイじゃなくてワン)が使われています。保守だけじゃなくて、新規開発でも。
ちょっと話はずれますが、この記事を見て僕が思い出したのは、就職活動で某超大手ITコンサルの面接を受けたとき。時は1998年。相手は40くらいのエラソーなおっちゃんでした。「大学でなんかプログラミングとかしてるの？」と聞かれ、「研究で使うのはCとFORTRANですかね」と答えたところ、「FORTRAN？いまだにFORTRANなんか使ってるところあんの？オレが学生の頃ですらもうFORTRANなんか使ってるやついなかったよ」と嘲笑されました。
「バカかお前は。NASAは今でもFORTRAN使ってるぞ？お前みたいなのがやってたカスい研究と一緒にすんじゃねえよ！」とは思いながらも言わなかったけど、腹のそこでは相当ムッときたので、その後の面接はひたすらケンカ腰になり、結局その超大手ITコンサルは不合格になりました。今となっては行かなくてよかったけど。あー、若かった。
で、結局何がいいたいかと言うと。
インターネット上ではRubyだPythonだPHPだとか言って、「もうJavaは古いよ」なんていう話になっている一方、世の中のインフラを支えるシステムではCOBOLとかFORTRANがまだ現役で、「そろそろこの世界でもJavaが使われはじめるか」みたいな話だったりする。
要するに今、コンピュータ業界で求められるスキルエリアの戦線が延びちゃっている状態なんじゃないかと思うのです。
そんな中でどんなスキルを身に付けていくべきかというのは、すごく難しい問題です。ここ数年、COBOLプログラマの単価が急上昇中なんだそうです。一方、これは想像ですが、PHPプログラマなんていうのはものすごく安く買い叩かれてるんじゃないかと。もちろん年齢層も扱うシステムの重要性も違う(と思われる)ので、単純比較はできませんが。
お金の面だけで言えば、最先端の技術についての知識を他人と競争しながら身に付けるより、最後尾の知識をじっくりと学ぶほうが、もしかしたら得なのかも知れません。ただ問題は、最後尾の知識はいつかコンピュータ業界の崖っぷちから零れ落ちていくだろいうということ。ただもしそうなったら、たとえばCOBOLがコンピュータ業界から完全に消え去ったら、そのときはその時点でレガシーになっているJavaのスキルを身に付ければいいのかもしれません。技術的なやりがいとか、見栄えとか、労働市場の流動性とか、いろいろ難しいところはありそうですけど。
とりあえず僕が思うのは、技術の最先端で勝負するにせよ、最後尾でやっていくにせよ、技術の世界の全体像と自分の今の立ち位置、そして今後の趨勢を、きちんと理解しておくことだと思います。それさえできていれば、世の中がどう流れていっても落ちこぼれちゃうことはないかな、と。
「いまだにFORTRANなんか使ってるところあんの？」と言ったあの超大手コンサルのおっちゃん、あれが僕のアンチパターンです。
今日、会社で「新しく展開するソリューションの案を考え、それをPowerPoint1枚にまとめ、各々がミーティングでそれを発表する」という仕事がありました。
こういう「アイデア出し」的な仕事は、僕にとってはものすごく難しい仕事です。単にアイデアを「思いつく」「考え出す」ことはできても、それを他の人を含めて検討する場に出せるレベルにまで「磨き上げる」のには、かなりの根気と時間が必要になります。
ただ困ったことに、ただ思いついただけで磨き上げてない状態のアイデアでも、PowerPointに書き出せば、なんとなくそれっぽくなってしまいます。ぱっと見では、時間をかけて磨き上げたアイデアとあまり変わらないように見えます。でも、当然見る人が見ればすぐわかるし、話し合いのたたき台にしようにも、中身がスカスカなのでまったく議論が深まらなかったりします。
今日の僕は、そんな感じの磨き上げてないアイデアを持っていってしまいました。なんとも情け無い気分で、反省しているところです。
僕の好きなパレートの法則(80%-20%の法則)に当てはめると、「PowerPointの80%は20%の努力で埋められる」ということになるでしょうか。でももちろん、大事なのは80%の努力で埋めなければいけない、残り20%なんだろうと思います。明らかに、差がつくのはこの部分。そこを頑張るには、かなりのモチベーションが必要なんだけど…。まあ、だからこそ差がつくんだとも言えるかもしれません。
明日は「ある他部門と自部門とのコラボレーションで出せる有意義なアウトプット」の案を考えないといけません。最近歳取ったせいか、こういう仕事が多いな…。なんにせよ、とりあえず明日はもうちょっと時間をかけてアイデアを磨き上げる作業に、自分なりに取り組んでみたいと思います。
仕事でRuby on Railsの調査をはじめました。んで、Ruby/RoRがらみの本を2冊購入。しかしコンピュータの本は高いなぁ…。でも、僕の場合は身銭を切らないとダメなので、そこは投資と割り切って。
RoR自体はとてもシンプルなアーキテクチャなので、特に難しいことはなさそう。でもRuby自体が、まだいまひとつつかみきれない。DelegateとかReflectionとかの概念が、JavaとかCみたいな旧世代(！)言語しか使ったことの無い僕にはまだしっくりきません。もうちょっと自分でいろいろ書いてみないとな。
そして、「JavaからRubyへ」というこの本。まだ読み始めたばかりだけど、かなり重要な提言をしている本なんじゃいかという気がします。いろんなところでいろんな人が言っていることだけど、見ようによってはもうJavaは破綻している、とつくづく思います。
いまどきJavaでWebアプリを作ろうとおもったら、StrutsとHibernateを組み合わせたり、SpringにJSFを絡めたり、ServletコンテナはGeronimoでEJBはJBossとか…。フレームワークやミドルウェアのフランケンシュタイン状態。しかもそれらフレームワークも、結局Javaコードを減らした代わりに膨大な数のXML設定ファイルの山ができあがっただけだったり。基幹システムにおいては、XML設定ファイルだって気軽に書き換えるわけにはいかないんだから、「コードを変更することなく、XML設定ファイルで動作が変更できる」ってのは大したメリットにはならないと思うのです。Seaser2関連のプロジェクトには「これは確かに便利かも」と思わされるものがありますが、それ以外のフレームワークはある種の混乱を別の種類の混乱に置き換えただけじゃないか、と。
もうちょっと勉強して、「JavaからRubyへ」を読み終えたあとで、またあらためて考え直してみようと思います。でもほんと、現在のJavaがフランケンシュタイン手術でギリギリ持ちこたえている状態だというのは、間違いないんじゃないかな…。
テレビを見ていて思ったことをずらずらと書きます。結論は特にありません。それではゴー。
--
「ガイアの夜明け」でリッツ･カールトンの特集を見る。今日たまたま東京ミッドタウンに初めて行ったこともあって(もちろんリッツ･カールトンに泊まったわけじゃないけど)、興味深く観た。
リッツ･カールトンのホスピタリティ(おもてなし)は、他の超高級ホテルとリッツ･カールトンを差別化する最大の要素としてあまりにも有名。
番組ではこんなシーンが紹介されていた。ドアマンが客の荷物を受け取ると、すぐに名札をチェック。ヘッドセットで他の顧客係にすぐ客の名前を伝える。初めての利用であるにも関わらず、客は「○○様、お待ちしておりました」と声を掛けられ、驚く…。
ほかにも、「そこまで？」と思うくらいのおもてなしが多々。リッツ･カールトンの接客係には、「おもてなし予算」として上司の許可なしで使えるお金が、一人当たり20万円あるのだそう。
こうしたおもてなし行動の一つ一つについて、投資対効果を計算をすることは不可能だし、意味が無い。あくまで、そういうおもてなしをする総体としてのリッツ･カールトンが確立して初めて、顧客は他のホテルと比べて格段に高い宿泊料であっても、そこを利用する。「あのホテルと比べてこのサービスがあるから、3,000円余分に払ってもいい」とかいった話ではない。いわゆるオンリーワン戦略。
ホテルというサービス業の中のサービス業であるからこそ、その重要性が際立つわけだけど、「すべてのビジネスはサービス業だ」とすると、こういうホスピタリティはどんな仕事にも重要なものになりそう。もちろんコンピュータ技術者にも。
よくインターネットや雑誌で「SEの悲哀」みたいな感じで「顧客にいじめられた」「顧客に不当な契約を押し付けられた」という話を見かけるし、実際に似たような話を耳にするし、僕自身も少なからずそんな経験はある。でも、もし自分がリッツ･カールトンのホテルマンになったような気分で仕事ができたら。客が「勝手なことばかり言うわがままな客」ではなくて、「ホスピタリティを発揮して、最高の体験をお届けしたい相手」と思えたら。そんなコンピュータ技術者は、リッツ･カールトン型SEになれるかも。
もちろんリッツ･カールトン型SEになるには、一流のスキルが必要なことは言うまでも無く、予算や方針について決断する権利を持つ顧客と、直接フェースできる立場にいないといけない。もしかしたら、会社勤めのSEでは難しいかもしれない。でも、それだけがインド・中国を巻き込んだコンピュータ技術者の価格競争(ていうか価格下落圧力)と違うところで生き延びるための唯一の方向じゃないかという気が、なんとなくした。
もうひとつ、録画してあった「情熱大陸」で若手建築家の中村拓志の話を見る。
アーキテクチャとかアーキテクトとか、システム設計と建築の世界はよく対比されるけど、その成熟度には雲泥の差があるなあとつくづく思う。
コンピュータの世界は日々複雑になってきて、制約と要件を満たすシステムを設計するのはますます難しくなってきているのは確か。ただ、今日行った東京ミッドタウンを見ていても思ったんだけど、あれだけの巨大な建造物が、1つ1つのネジや、数cm四方のタイルから構成されているということにつくづく驚く。法律、強度などの制約を満たしつつ、建築家は「芸術家」として創造性を発揮する。当然、無数のステークホルダーの要件を満たしつつ。
僕は建築についての知識を持ってないので、実際の仕事の仕方はわからないけど、作業の分割、要件と制約の複雑さ、関連する法律の数、計算の量、必要とされる知識の幅、部品点数、関わる人の数など、その難しさはコンピュータシステムの開発とは桁が違うんじゃないかなあと想像。
ほんと、ああいう超巨大建築物の設計って、どうやってやってるんだろう。CADみたいなツールがあるのかな。いつか誰かに聞いてみよう。
「なるほど」と思いながら読みました。
その一方、ソフトウエアエンジニアリングの知識に乏しいユーザーは、どのようなソフトウエアを開発したいのか、「要求仕様」が書けない。あるいは書きたがらない。取りあえず派遣プログラマーを雇って、「作っては直し」を繰り返してシステムをアドホックに仕上げていく。バグだらけなのは当然で、効率も悪いのだが、もともと効率を競う感覚に乏しいので問題にならない。かくして、ベンダー、ユーザー両者が望むので、日本にプログラマー派遣業が定着してしまった。日本のソフトウエア産業の労働力ピラミッドは、人海戦術で働く派遣要員で支えられている。
つまり、ベンダーとユーザー双方の甘えが、派遣という責任を明確にしない契約形態に結実し、結果として日本のソフトウェア産業の質を落としている、ということかな。
「ソフトウエアを一つの産業セグメントと見るのは危険です。（中略）どの産業も増え続けるソフトウエアで動いているのです。ソフトウエアの競合性は、既存のある産業の競合性の問題なのではなく、産業全体の競合性に関わるのです」
ベンダーで働く身としては、「お客様の声を聞き、お客様の立場に立って」というのももちろん大事なんだけど、ベンダーとユーザーがお互いにレベルを高めあうような緊張感がないと、日本の産業全体の競争力がどんどん落ちていってしまうのではないかと、少し心配になります。
でも、ベンダー側の供給過剰である現状では、価格下落圧力→品質低下という全体的な流れは避けられないような気も。
自分も含めて、日本はソフトウエア産業では二流国なんだという意識を、もっと強く持たないといけないと思います。
今日、予定をダブルブッキングして人に迷惑を掛けてしまいました。反省です…。
僕のスケジュール管理ツールはというと、仕事用のLotus NotesとGoogle Calendar、そして買ったけどあんまり使っていない手帳の3つ。
仕事で他の人とスケジュールを共有する以上、Lotus Notesへの入力は必須。でもNotesにあまりプライベートな情報は入れたくないので、Google Calendarも利用。で、Google Calendarは携帯でも見れるけど、やっぱり使いづらいので手帳を買ってみた。という感じです。
この3つをなるべく手間をかけずに同期させる手は無いか…と色々考えていたんですが、考えを改めました。
毎朝、ひとつひとつ目で確認しながら手作業で同期を取るのが一番です！たぶん！
こうすることで、自分のスケジュールがちゃんと頭に入るし、時間の使い方を見直したり考えるきっかけになるし、何よりもっとも確実に同期がとれます。
無駄な作業はどんどんツールで自動化すべきだけど、ものによってはあえて手間をかけたほうがいいものもあるということですね。
インストールメモとか、設定メモとか、作業記録とか、そういうのは以前はWikiに書いたりしてたんだけど、最近はもっぱらこいつです。
特にDocsの方は「Ctrl + S」でセーブできるのがうれしいです。
明日、お客さんの前に「Javaに詳しいヒト」として登場しないといけなくなったので、あわてて一夜漬けで話題に出そうな技術を勉強中。ていうか、JSP0.91とかググっても全然情報がねーよ。
相当やばいけど、今まで「やらなきゃ」と思いつつ放り出してた勉強がザクザク進む。やっぱ、「はったり」→「ピンチ」→「がんばる」ってのが、新しいスキルを身に着けるのにはもっとも効果的かも。
それにしても、Java界隈はこの2～3年で様子ががらっと変わっちゃって、久しぶりに携わるとその変化ぶりに驚く。今日DB Magazineの「JavaEE開発」特集を立ち読みしてたら、囲み記事に「久しぶりにWeb開発に携わるベテランと若手エンジニアの会話」みたいなのがあって、ベテランが「僕が昔やってたのは、HttpServletクラスを継承してServletを書いてたんだけど」みたいなことを言うと、若手が「まじっすか！Servlet書くんすか！」と驚く、みたいな掛け合いをしてた。そうかー、フレームワーク時代のヒトだとそういう感じなのか。
Developerｓ Summit 2007(略してデブサミ…って、この略称なんとかしてくれ)に行って来ました。場所は目黒の雅叙園。2日間の開催の初日です。
以下、参加したセッションの感想文。
大規模ウェブサイトのスケールアウトモデル by バタラ・ケスマ氏(mixi)
mixiの中の人のスケールアウトアーキテクチャの説明。多段クラスタープロキシとか、DBサーバーのパーティショニングの話とか、エンタープライズ向けではあまり見かけないけどかなり参考になりそうな話がたくさん聞けた。特にDBのパーティショニングについては、DB2なんかだと製品の機能としてやっているところを、手作り(ハッシュ計算したり、パーティション分割を管理するDBサーバーを別途用意したり！)してるところがすごいというかかなり衝撃を受けた。ずいぶんトリッキーというか不恰好なやり方にも見えるけど、LAMPでやろうとするとこうするしかないわけだし、やっぱりDBのスケールアウトってのは永遠の課題なんですね。
メトリクスを使用したプロジェクト運営とソフトウエア エンジニアリングの実践 by 岩出智行氏(Microsoft)
バグ数とかテスト通過率などのメトリクスの話。最近個人的に興味深く感じてるはなしです。Visual Studio Team Systemの機能とかを紹介しつつ、メトリクスは時系列で分析して初めて意味があるんだよ、と。「今週のテスト通過率は80%でした」といっても、「先週は70％で今週は80%」なのか「先週は90%で今週は80%なのか」で全然意味が違う、と。
PlaggerによるRSS/Atomフィードのマッシュアップ by 竹迫良範氏(サイボウズ・ラボ)
衝撃を受けました。今日最大のヒット。
とりあえずプレゼンがむちゃくちゃうまい。面白い。スピード感が全然ちがう。やっぱ"2.0系"の人のプレゼンはすごいなあ。Wiiリモコンでプレゼンやってるんだけど、それに触れすらしない。恥ずかしながら、LDR(livedoor reader) Hackのことは全然知らなかった。LDRにGreasemonkeyをかまして、LDRのAjaxバリバリインターフェースを使って2chを読み込む、というのを紹介してた。これまでのマッシュアップはMVCのVを書き換えるものだったけど(GoogleMapを自サイトに組み込むとか)、LDR HackはVを活かしてCをいじることによって好きなMを使うものだと。
VisualBasic, Delphiから10分でJava+Flex2にポーティング by 比嘉康雄氏(ISID)
「有名人を生で見たいので出てみた」セッションその1。Seaserのひがさんですが、今日のテーマはSeaserではなくてFlex。Flexは会社でもよく話題になってるので気になってたんだけど、今日のデモはマシントラブル連発で、かなりグダグダな感じになってしまっていました。かわいそう。
ところで、WEB+DBP RESSSで読んだんですが、ひがさんは開発はすべて会社でやっていて、自宅にはPCがないんだそうです。すごい！！！
ビジネスモデリングを極める!（4+1）x1ビューで見える化する by 羽生田栄一氏(豆蔵)
「有名人を生で見たいので出てみた」セッションその2。ビジネススコアカードだとか戦略マップとかビジネスの5W1HとかRUPとか、そんな超上流エンタープライズの話。正直、途中で帰ろうかと思うくらい退屈だった…。
こんな感じでした。
今日一番印象に残ったのは、竹迫さん@サイボウズ・ラボのプレゼンと羽生田さん@豆蔵のプレゼンの「違い」。竹迫さんはWiiリモコン使ってものすごいスピードでスライドをめくって、毎日ネットを見てる人じゃないと理解できないようなネタをポンポン出して、Greasemonkeyとかいう言葉を説明無しで使う。いっぽう羽生田さんは、ビジネススコアカードの説明をレーザーポインタを使いながら語る。レーザーポインタって久しぶりに見た気がするけど、これ使ってるとずいぶん「おじさんプレゼン」ぽい雰囲気が漂うね…。
いずれにせよ、この「2.0系」と「おじさん系」のギャップに橋をかけれる人材は、この先数年間IT業界(おじさん系、というかエンタープライズ系のほうの)で貴重な存在になるんじゃないのかなと思います。
いろいろ刺激を受ける一日でした。明日は仕事があるので参加できないのが残念。
ふむ、SE35歳定年説なんかよりは、格段に真実味がある気がする。
半減期が5年ということは、10年後には今持っているスキルの3/4が使い物にならなくなるということか…。そもそも35歳定年説も、新人研修以来ほとんど自己研鑽をしてこなかった人の10年後ということも言えるかも。
やべ～。
Slashdot : 多数の社内ブログ/SNSの導入企業から「2ちゃんねるへの書き込みが減った」との声
昨今かまびすしい企業内SNSの話。
よくmixiなんかで、高校生が喫煙や飲酒の話題を日記やコミュニティの掲示板に書いてたりする。もちろん単にアホなだけというのもあるだろうけど、ある世代の人たちにとって、SNSへの書き込みが「公共へのpublish」だという意識が無いのかも、とも思う。みんな、友達へメールをするような感覚で書く。でもあくまでメールじゃなくてSNSなので、それが少しだけじわっと他人にも漏れ出す。
2chは「王様の耳はロバの耳」の世界だから、偽悪的になったりエゴがむき出しになったりする一方、blogはちょっとかっこつけてまじめに書く感じ。SNSはその中間で、特定少数の視線があるので滅茶苦茶にはならないけど、ちょっと本音というか素がでる。そしてその素は、不特定少数にも実は覗かれてたりして、そこから新しい関係性が生まれてくる。この特定少数＋不特定少数っていうのが、SNSが実社会に近い、ほどほどで安定的な世界を作る秘密なのかな。mixiが荒れるのは、2hcやコミュで個人たたきが始まったときですよね。こういう風に、不特定少数じゃなくて不特定多数の視線に個人が急にさらされると、穏やかならざることになる、と。
言うまでもないことだけど、企業内SNSってのは会社が管理しようとしないことが成功の秘訣だと思う。同期の社員同士が飲み会の企画に使うところから始まって、仕事の情報交換や、仕事の悩み打ち明けにまで広がっていけば、かなり有用なコミュニケーションツールになりそう。仕事の情報交換のインフラとしてだけではなく、個人としてのコミュニケーションもOKにしてあげないと、誰も使わないんじゃないかな。仕事のツールじゃなくて、福利厚生として考えるくらいのノリで。もちろん時には仕事のグチもでるだろうけど、そこは特定少数の目があるから、ほとんどの場合はある程度自然に収束するはず。
もちろん問題は、自然に収束しないような「困ったちゃん」のケースなんだけど、そういった人は実際の仕事でも周囲に迷惑をかけてるだろうから、まあそういう人なんだなということで割り切るしかない気がする。SNSでの発言を理由に懲戒とかってのをアリにしちゃうと、やっぱり誰も本音を語らなくなっちゃうだろうし。
ほんとは大企業にこそこういう企業内SNSみたいなツールは必要なんだろうけど、SNSを活性化させるために必要な「おおらかさ」は大企業ほど少なくなりがちなので、その辺が普及のための課題かな。
どうでもいいけど、「脳内ブレスト」って脳が再帰的だなー。
おちゃめクールの周回遅れブログ : [社会]なぜ過酷労働を自慢するか
特にコンピュータ業界は、この傾向がすごく強い。
ともあれ、今回の「これで過酷労働かよ！」的発言は、実は自らの生物的な優位性の主張なのではないかと思われる。ようするに、「俺はもっと過酷な労働をこなしている」と主張することによって「俺は生物的に優れた個体」であることを誇示しているのではないだろうか。私はこれらの一連の「これで過酷労働かよ！」的発言が単純に僻みや妬みから来るものではないと思う。
今まで、こういう「過酷労働自慢」をする人を疎ましく思いながらも、正直言って何となく「言い返さないと」的な気分も味わっていた理由が、少しわかった気がしました。
あとは、この「生物学的優位性」論以外にも、「無償の労働は尊い(の勘違い)」論もありそうですね。つまり、「見返りを求めずに努力することは尊い」が転じて、「見返りが与えられないのに、過酷な労働に耐えている俺は偉い」という発想です。
過酷労働な状況においては、「過酷な労働に耐えているのに、見返りが求められない俺はかわいそう」が本来自然な発想なんでしょうけど、やっぱり「かわいそう」では自分がかわいそうですもんね…。見返りの無い(少ない)過酷労働を支えるプライドは、見返りの無い(少ない)過酷労働に対する自己評価(≠自己憐憫)だということでしょう。
なんていう文章を一生懸命考えている自分は、やっぱり過酷労働自慢に引け目を(若干なりとも)感じているということなんだろうなあ。これを克服するには、やっぱり過酷労働自慢をする人たちとは違うステージで、自分の満足いくアウトプットを出し続けるしかないのだろうなと思います。難しいけど。
