October 30, 2008

システムエンジニアとか

記事全体で著者が言わんとしている、現状のIT業界における業界構造をどげんかせんといかん、というテーマについては、同意できるんだけど。

昔、コンピュータを買う、ということは、IBM等の大型機、汎用機といわれるコンピュータを導入する、ということだった。当然ながら、当時のコンピュータは、今のようなGUIはないし、そもそもでかいし、空調とかがしっかりした部屋に鎮座させないといけないし、それこそ、腫れ物を触るように接する必要があった。とすると、これも当然ながら、ユーザがコンピュータを買ったところで、使いこなせなきゃ意味がないが、使いこなせるわけがない。となると、使いこなせる人を調達する必要がある。で、どうしたか。IBMは大型コンピュータを売る一方で、その売ったシステムを使いこなす要員を一緒にセット販売したのである。そのセット販売された要員たちの職業をシステムエンジニアと言った。

つまり、コンピュータを買う、ということは当時、使いこなす要員を含めた、年間使用量の複数年契約だったわけ。

で、逆に、システムエンジニアさんたち自身からすると、IBMから送り込まれたので、IBMの社員ではあるんだけど、コンピュータを買った客先に常駐し、客が望むことを自社の売った製品である、コンピュータ上で実現することを生業とする。業務分析とか、設計、実装、テスト、リリースといった一連の流れで仕事をしていたことが想像できる(もちろん、開発プロセスとして確立されてたとは思わないが、似たようなことはやってたはず)。

今でいうと、情報システム部門の一括請負アウトソーシングみたいなものか。

そうすっと、今巷で言われている「システムエンジニア」という職業とそれほど、乖離していないということがわかる。

でも、当時のシステムエンジニアには、いまでいう、要件定義等を行う上流SE,あるいはその客先専用のアプリケーションを作る、アプリケーションプログラマ、運用、保守エンジニア、テスター、全てが含まれていた。じゃ、当時、プログラマは何をしてたか、というと、おそらく、IBMの社内で、OSとかコンパイラとか、リンカ、ローダ、あるいはデバイスドライバ、エディタ、といった、上述のアプリケーションプログラマ(当時のSE)が利用する基盤となるソフトウェアを作ってたはず。

そう考えると、システムエンジニアよりプログラマの方が偉いのは当たり前。そりゃそうだ。コンピュータサイエンスの高等教育を受けていないとできない仕事だから。

アメリカでなぜプログラマが偉いのか? 専門教育を受けた(つまり、育成にコストがかかっている)専門家だから。あるいは、そういう専門教育を受けていないとできない職業である、とみなされているから。

これは、グーグルがエンジニアを募集する際に、コンピュータサイエンスの修士号以上を保持するものに限定していたことからもあきらか。

翻って、日本。

SEは設計をする人、PGがコード書く人というのが一般的な解釈になってるし、現にそう理解している人も多いみたい。でも、PG書けない奴(書かない奴とは違う)が設計できないし、設計を理解しないで、プログラムが書けるわけがないのは明らかで、なんでそういう分類になったかというと、これはもう、企業内におけるキャリアパスの設計上のミスなんじゃなかろうか。日本の古いホワイトカラーなキャリアパスモデルになんとか、このコンピュータ系エンジニアを当てはめようとすると、こうなっちゃうのは仕方ないよね、とも思う。あとは、そういったエンジニア群を率いるのが、エンジニアを経験したことがなかったりすると、もうどうしようもない。

医者の世界で、医療事務のエキスパートたる事務局長のようなポジションの人が、いきなり医局のトップに降りてきて部下たる医者に指図したり、っていう光景はありえないはずなんだけど、コンピュータエンジニアの世界ではそれが当たり前になっている。

そういう組織なもんだから、コンピュータサイエンスの専門家を専門家として処遇するような会社は少ないし、今のIT業界でサラリーマンとして生きていくことを考えたら、コンピュータサイエンスの高等教育を受けたことによるメリットは、おそらくない。(実質的に、エンジニアとして活躍できるか、という観点ではなく、SEという職業について、食いっぱくれなく処世していけるか?という観点で。)

どっかの記事に、情報系学部に進学する学生が減っている、という記事があったけど、そりゃそうだ。メリットがみえないもん。技術系企業側も新卒採用の際には、文系学部卒でも、立派なSEやってますからあなたでも大丈夫、なんて誘い文句がそれほど腐るほどあるし。

たとえば、経済学部、経営学部のようなところに行って、大学時代は理系より楽、就職活動でも、あわよくば、金融系の高年収職業に、だめでもSEなら、って青写真が描けるのであれば、コンピュータサイエンス系学部に進んで、PG,SEに絞られている、という状況の方が選択肢が少なくリスクが大きいと考えてしかるべきだろう。

なので、情報系学部に進学する学生を増やしたいのであれば、コンピュータサイエンスの高等教育を受けた人材が活躍できる場をもっと作らないといけないし、コンピュータの勉強をしてたから成功できた、という成功事例を作んなきゃいけない。 ってことで、成功事例目指して頑張ってください。>誰か。僕も頑張ってますから。

Posted by money at 1:23 PM | Comments (0) | TrackBack

May 19, 2008

東京三菱UFJ銀行のシステム統合についてそろそろ一言言っておこうか

よく動かしたよなぁ。すげーよ。あんたたち。>担当者の方々

ん?不具合が発生して2万件の処理に影響があったじゃないか、って?

えっと、あのシステム全体で処理すべきトランザクションは1日何件だっけ?
そのうち、影響があったのって、何%?

あの程度のトラブルで済んだんだからよしとしなきゃ。
もちろん、向上心を持つことはいいことだし、現状に満足してても進歩がないので、さらに高みを目指すのはいいことだけど、100%の完成度しか認めないなんて、それこそ、現場の担当者に人間であることを認めないことになっちゃう。

それにその日のうちに復旧できたんでしょ?あんなでかいシステムの不具合が発覚して、さらにその当日のうちに不具合箇所見つけて、修正して、バイナリ作って、テストして、本番環境にデプロイして、さらに本番で動かして、復旧できたんでしょ?あっぱれじゃん。よくみっけたよねぇ。すげーよ。

いやぁ、デバッグしてたエンジニアってさ、きっと、何もわかってないやつらからのすごいプレッシャーと厳しい視線を一身に受けつつ、尋常じゃない精神状態の中で、コードを追いかけたんだと思うよ。そりゃ、コードを追いかけてる途中で、プレッシャーのあまり、トイレに駆け込んで、こっそりと吐いてるかもしれん。でも、そのまましれっと帰ってきてまた引き続きコードを追いかけてたんだよ。
この状況に耐えながら仕事できるような人って、世の中どれぐらいいるんだろうね。

それぐらい拍手喝采浴びてもいいと思うな。

ん?大騒ぎしたマスコミの記者にいいたいこと?

あなたの書いた記事に、誤字脱字が一文字でもあったら、それはその記事がリリースされると同時に必ず発見され、あなたは首を切られます。記事中に事実誤認が後日発覚しても同様です。
もし仮に、そんな条件があったとしたら、あなたはその記事、リリースできますか?記者稼業を続けていくことができますか?

なんでもかんでも100%の完成度を求める社会ってのは、とてつもなくコスト高な社会。いじめにも近い、それでいてあまり益の少ない完璧主義のために、国が滅んでしまっても笑うに笑えない。

ぜひ、今回の6000人とも言われる、中の人には、ぜひ、「中から見た東京三菱UFJ銀行システム統合プロジェクト成功の秘密」をどこかに書いてほしい。
適うのであれば、プレッシャーの中、コードを書いた人、繰り返しテストした人、上層部のプレッシャーに耐えつつ、プロジェクトをドライブした人、この人たちとワイワイ酒を飲みながら、苦労話をじっくり聞いてみたい。そんなすがすがしい気分。

ひとまず、お疲れ様でした。

Posted by money at 7:49 PM | Comments (0) | TrackBack

January 24, 2008

良いプログラマの探し方

〜 via Geekなぺーじ:良いプログラマの見分け方

「How to recognise a good programmer」という記事がありました。良いプログラマを見分けて雇用するためのTIPSが書いてありました。

昔同じようなことを考えたことがある。
今から約3〜4年前、前職エンタープライズでJ2EEな開発プロジェクトを立ち上げる際に、Java開発者を探す必要があったときだ。当時のプロジェクトの条件としては、


  • 開発スケジュールが厳しい。

  • 社内の独自フレームワークを使う必要あり。(パイロットプロジェクト的性格のプロジェクトだった)

  • 当然、上記フレームワークのデバッグも兼ねている。

  • でも、そのフレームワークのドキュメントは貧弱

  • 今でいう、アジャイル開発的な小刻みにプロジェクトをまわす方針である.

当時としても、junitをベースとしたユニットテストの実施に重きを置いたフレームワークであり、XP的な開発プロセス(小刻みに、Continuous Integration)に関するバックグランドがあれば、対応できる程度のもの。でも、その辺の知識が全くないレベルのエンジニアに一から教え込むだけの時間もマンパワーもない。また、今もそうかも知れないが、Javaの開発者を探すと、Javaしかできないプログラマ(?)がわんさか集まるわけで、Strutsで開発をしてたとは言うが、MVCって何?って聞いても答えが返ってこなかったり、なんでStrutsを選んだの?という話にも食いついて来なかったり(まぁ、当時としては、大規模開発の分野ではStrutsは大人気でしたからねぇ。)、お眼鏡に適うレベルのエンジニアがそうそう稼動が空いているはずはなく、どうしたもんかと考えた際に持ち出したのが、「Rubyの分かるエンジニア」。
つまり、


  • 当時、Rubyの仕事なんて皆無だったので、Rubyが分かるということは、少なくとも、業務以外にプログラムを書いている。

  • また、業務に直接必要ない技術を自分で習得している。

  • オブジェクト指向が分かっている


ということで、技術に対するエンジニアとしてのスタンスを見ようとしたわけだ。
結論として、やはりあの当時、SI業界に、「Ruby分かるよ」なんてエンジニアは僕の探した範囲では皆無だったわけで、このたくらみはうまくいかなかったんだけど、でも上記のエントリの中で言っている「良いプログラマの見分け方」って要するにそういうことでしょ。
逆に、SI業界のエンジニアを代弁すると、SI屋さんって基本的にお客さんから常に尋常じゃない納期を求められ、技術の分からないプロマネがそれを安請け合いした結果、みんな忙しくて、仕事以外にプログラムを書いてるだけの時間がなかったりして、それどころか生活そのものが破綻してたりということも稀ではなく、またそういうプロジェクトほど、気の利くスーパーエンジニアを囲い込んで彼の能力を浪費してたり、なんて事例がいっぱいなので一概に「Javaしかわからんエンジニアはうんこ」なんてことを言うつもりはないんだけど。

でも、Rubyが流行となり、Railsがないとプログラムが書けないプログラマが大量生産されている昨今、「良いプログラマ」を探すためのリトマス試験紙となる技術(あるいは条件)ってなんだろう?しばらくSIの現場から離れてしまっているので全く思いつかない。

Posted by money at 4:20 PM | Comments (0) | TrackBack

July 24, 2007

人材育成?

経産省と文科省が足並みを揃え、IT業界の人材育成に本腰:ITpro

なんか、とても違和感ありまくり。

なんか、何でもできて自分たちの思い通りに動くスーパーエンジニアを大量生産する、という夢想のような気がしてならない。

こういう会議の中で発言してる人の中で、本当にソフトウェアエンジニア出身で、自らも「スーパーエンジニア」として鳴らしたこともある、という経歴の持ち主はどれぐらいいるんだろう?IT産業からもエライ人が参加してるみたいだけど、エンジニア出身者はあまりいなさそうだし。

たとえば、仮に、今日本のプロ野球が低迷してる、とする。そのときに、その低迷理由を、「イチロークラスの選手がいないからだ。」という結論を出すのは簡単でも、イチロークラスの選手をそう簡単に産み出せないというのは理解されるので、こういう結論は出てこない。

USのシリコンバレーも、別に、IT業界の人材育成に力を入れた結果が出ているわけではなく、そういう人材を世界からひきつけているだけ。つまり、オールスター選抜を知らず知らずに作ってるってわけ。

官僚の天下りを全面否定するような話が出てくると、必ず出てくる話題に、「それじゃ、優秀な人材が確保できない」というものがある。
つまり、人材育成プログラムなんか必要なのではなくて、本当に必要なのは、優秀な人材を惹きつけるだけの「旨み」を用意することだ。

エンジニアも大金持ちになっていい、あるいは、大金持ちになれる可能性がある、ということはほりえもんが立証してくれた。 

日本という国は、何か失敗したり、失言したりすると、全人格が否定されたり、それまでの功績もすべて否定するような傾向があるけど、上記の意味でのほりえもんの功績はとても大きいと思うし、その点はエンジニアのキャリアパスの一例として評価されてもいいと思う。(その後の粉飾決算が悪かったんだろうけど、そういう意味で言ったら、日興コーディアル証券の方が額的には大きいし、正直、よくわからない。派手にいろいろやりすぎたので、ねたみ、やっかみの対象になったことは、この国の国民性からとても理解できるんだけど、そういった感情は認めたらダメでしょう。)

ってなわけで、エンジニアの皆さん、がんがれ(自分も含めて)。

Posted by money at 12:35 PM | Comments (0) | TrackBack

July 13, 2007

こんな経営者はいらない

そんなプログラマは必要ない!優秀なプログラマの8つの条件*ホームページを作る人のネタ帳

内容的に、ネタっぽいので、それに突っ込むのもどうか、とは思ったんだが、「ホームページを作る人のネタ帳」と言ってるので、ネタにさせていただくことにした。
私自身、とても微妙な立場なんだけど。。。

1)企画力のある人材 優秀なプログラマは得てして自己表現が下手だ。 我々にとって優秀という言葉は、あくまで我々の言うことを100%遂行する人材。
つまり、忠実なシモベ、ロボット、イエスマンが欲しいわけだ。この経営者は。
逆に、こちらから依頼したものに、プラス何かを付けてくれる人材は、プレゼンがうまい傾向にある。自己表現ができるのだ。
依頼したものにプラスアルファってのは、上記の表現を借りると、「われわれの求めたことの150%を遂行する人材」なんでは? まぁ、プラスアルファしたらしたで、欲しかったのはそれだったのだ、と後からほざくような奴も世の中いっぱいいるけど。だからソフトウェア開発って、仕様変更がなくならないんだけどね。まぁ、ただでさえ、目に見えないものを理解するのは難しいと言われているし、ソフトウェアが分かる奴なんて、本職以外にはほとんどいないに等しいんだから、エンドユーザが仕様検討なんてできるわけない、という前提に立てば、少しは改善できるのかも。もちろん、やりたいことを洗い出すことと、仕様をまとめることは違います。
3)網2.0って何だろうと聞いて、返事が返ってくるプログラマ これは非常に面白い質問をする人だと思いました。 網2.0って・・・。ただのウェブ2.0なんですけどね。それが理解できない人材は英語がからっきしダメということと、WEB2.0すら知らないことに繋がっているらしいです。
いやぁ、あかんでしょ。これで英語力を測られたって。というか、あかんでしょ。平気でこんな質問してくる経営者。それも、エンジニアの能力テストと称して。それに「網2.0って何?」って聞かれて、「ウェブ2.0ですね」って答えを期待してる経営者、僕はいやですねぇ。 とりあえずウェブ2.0という実体のないはやり言葉の本質を知りたくて、いろいろ調べた挙句、「ティムオライリーの言う、Web2.0の本質はどこにあると思う?」みたいな議論をふっかけてくる経営者だったらぜんぜんありです。でも、引用元のような質問する人に限って、ティムオライリーって言ってもきっと分からん。 あ、どうせなら、ウェブを「網」ではなく、「くもの巣」と表現して欲しい。個人的には。
5)新しいものにとらわれないプログラマ 常に新しい技術や情報を見つけ、さも自慢げに話すプログラマほど使えない。それよりも、今まで作ったプログラムの中から脆弱性の一つでも見つけるプログラマの方が優秀だ。
別に、相反することではないし、トレードオフすることでもない。どちらも大事。新しいものに対して興味を持たないエンジニアというのは、これまでいっぱい見てきたけど、すべて自分の知ってる技術範囲だけで問題を解決しようとする、あるいは現状に問題を見出せない可能性があるのでダメ。 かといって、過去の積み重ねもなく、単に目新しい言葉に惑わされているのは問題外。要するに、バランス感覚と、懐の深さ、そして、臨機応変、適材適所に技術を取捨選択する能力でしょう。そこには、新旧のみによる価値の違いはない。
6)仕様の話をしているときに黙って聞くプログラマ 今まであったプログラマ(下請けも含め)大体の人間が、製品、及びウェブサービスの話をしている時に、必ず技術的な話をしてくる。私にそんな話をされたってわからない。それが出来ない理由というなら、なぜ出来る人間がいるのか聞いてみたい。 黙って聞くプログラマは、頭の中で恐らくプログラムチャートが高速で作られている。そんなプログラマは、大体話し終えた後、時間をくださいという。帰ってチャートを作るというのだ。 技術の話はそれからだよね。やっぱり。
それはたぶん、自分で情報を整理して、チャートに起こしてみないと問題点が把握できないからなんでは?つーか、こういう人から「こういうものを作って欲しい」という依頼がある場合は、そのまんまプログラムなり、チャートなりのロジックに落とせるレベルまですっきり整理されていることなんてなくて、まずは、ロジックに落とす前に、何段階か、抽象レベルを落とす必要がある。そのあたりのいくつもの抽象レベルを行き来しつつ周りとコミュニケーションをとりつつ、ロジックに落とせるのが優れたプログラマである、と僕は思う。この引用のように、コミュニケーションを拒絶されるのもどうかと思うけど。
プログラム経験3年以上で募集しても8割は全くの初心者と思っていい人が来るのがこの世界だよ。
3年も初心者も実効は対して変わらんような。。。つーか、経験年数でプログラマの能力を測ろうとしてる時点でダメでしょう。
8)企画時に、収益の算段が出来るプログラマ
プログラマに企画を頼る経営者とは仕事したくないよね。つーか、エンジニアって、自分が尊敬する相手とか、信頼できる相手でないと、企画をぶつけたりしないよねぇ。「これ、こいつに言ってもどうせ分からんやろうしなぁ。。。」ってことはよくある話です。
それが成功するかどうかは別として、先を見れる人材がほしい。
そうだ。経営者は先が見える人でないと。。。

と一通り、突っ込みましたが、結論としては、
「エンジニアの皆さん、こんなへっぽこ経営者なんてものはさっさと淘汰してしまいましょう。」
ってことですかね。

まぁ、プログラムってことで限定するとして、あるウェブ上のサービス企画のようなものがあったとしよう。
ある経営者がウェブサービスの企画を思いついた。いろいろ検討したが、可能性がありそうだ。でも、自分ではシステムは分からないので、実際に実現可能なのかは分からない、とする。
彼が、この企画を実現へ持っていくには、システムが分かり、なおかつ信頼のおける上級のエンジニアをみつけ、この企画をぶつけ、彼に金を払ってさらに、プログラマ等をお金で確保してプロジェクトを起こすしかない。
これに対し、あるプログラマがこのような企画を思いついたとしよう。するとそのプログラマはどうするか、とりあえず、常時ネットにつながった自宅のLinuxサーバ上にRailsでもインストールして、しこしこ作り始めるだろう。
エンジニアの人たちには、この両者の違いがとても大きいことに気づいてほしい。片や、お金を投入して、リスクを背負って人を巻き込んで開発をしないといけない。それに対し、プログラマ君の場合、自分のプライベートな時間を少し犠牲にするだけだ。犠牲にしたといっても、エンジニアとしての経験値にはプラスなので、自己啓発の範疇でしかない。同じことを始めるのに、このリスクの違いは致命的だと思う。この立場を利用しない手はない(自戒を込めて)。

Posted by money at 8:58 PM | Comments (0) | TrackBack

May 10, 2007

抽象論と具象論



〜via atsushifxの七転八倒 - 同感、というか逃げます(Re: 無い方がマシな命名規則)

(


via 酔狂人の異説 - 無い方がマシな命名規則)

驚くべきことは、引用元の「プロジェクトを破壊するプログラマ」というエントリにおいてこのようなクラス名を擁護するコメントがあったことである。きつい言い方になるが、このようなクラス名を擁護するようではプロ失格だろう。


なんか話の抽象度がかみ合ってない感じ。

まぁ、もともとのエントリでは、意味のない命名規則なんてくそくらえ、ということを言いたいがために、「C001」なる味気ない記号のクラス名を例に持ち出してきていて、それに、対して、アプリケーションドメインによっては、C001なんて名前のクラスも意味がある場合がある、なんて反応してるわけで。

確かに、C001という文字列に意味を持たすのは簡単なんだけど、そういう文脈じゃないし。
例に出てきたC001という区画でどうこう、なんて話だと、「区画」っていうクラスを作って、C001という名前のプロパティを持たせばいいだけで、C001なんて腐ったクラスをわざわざ作る必要もない。

いや、そういうことを言いたいわけではなくて、
つくづくプログラマ(あるいは、あえてSEと言ってもいいけど)ってのは、抽象論と具象論のハザマで仕事をする人種なんだなぁ、と思った。
つまり、大きいプロジェクトでよくある、上流にしかタッチしない(タッチできない?)人種というのは、あくまで抽象論の域からは出てこない。また、言われたことをコーディングするだけのコーダーは、あくまでコードでしか話ができないから、具象論の域を出てこない。

そこで、この抽象論と具象論のハザマで、同時通訳を行いつつ、円滑にプロジェクトを進めるプログラマ(あるいはSE)という存在に光が当たる。もちろん、この役割を担う人物というのはプロジェクトにより様々で、コーダーの具象論レベルまで降りてくることができるプロジェクトマネージャ、あるいはSEとか、もしくは、プログラマの中から、自分の担当しているプログラムの具象論と並行して、抽象論レベルまで駆け上ってくる場合もある。 

なので、やはり優秀なエンジニアというのは、この抽象論、具象論を、相手に合わせて臨機応変に使い分ける、というスキルが必要であり、この『こなせる抽象度の幅』とでも言うべき範囲の広さが、そのエンジニアの優秀さを測るモノサシになるんじゃないかなぁ、と思ったんだが、そんなモノサシ、数値化できねぇ。

なんてことを、とても両者の隔たりのある仕事をやってる今、思いました。

以前に、僕もとある大きな開発プロジェクトのコーディング規約を作る仕事をしましたが、無意味な接頭辞(いわゆるハンガリアン記法的な話)をつける命名規則とか、やみくもに「goto文禁止」とか、って意味ないじゃん、ってことで却下しました。

最近のJavaなでかいエンタプライズ系のプロジェクトだと、へっぽこプログラマの割合が多いので、プログラマの自由を縛る方向で、コーディング規約をつくり、その結果としてバグを作りこまないように、という流れが多いが、それって、結局現場では、中途半端な理解の下でのこぴぺが氾濫するだけなんだよね。
あとは、コーダーの入力キーパンチ数を減らすことがいいことだ、みたいな変な考え方とか。

なので最近、魅力的なJavaなプロジェクトが減ったように思えてなりませんが本ブログ読者の諸賢はいかがなのでしょうか?

ってことで、魅力的なJavaなプロジェクトに興味のある方、ご一報ください。(笑)

Posted by money at 1:42 AM | Comments (0) | TrackBack

May 16, 2006

オフショアでアジャイル 改訂

アジャイルソフトウェアプロセスを使ってオフショア開発

Using an Agile Software Process with Offshore Development

ファウラ御大の原文が更新されているにも関わらず、追従できてなかった本稿ですが、ようやくアップデートしました。
・遠隔地には、ちゃんと人を派遣しろ、遠隔地から人を呼べ、一緒に飯食って、観光して、お互いに信頼関係を築け(直接会って、関係を築け)
・Wikiはいいぞー、どんどん使えー

という主に2つの教訓が追加されています。

Posted by money at 2:31 AM | Comments (0) | TrackBack

October 3, 2005

システム開発でビルを建てる方法


totoの販売システム
(中略)システム開発でビルは建たないよ。

システム開発でビルを建てる方法? それは、自分たちでシステムを作ることをあきらめるか、社員の幸せをあきらめるか。他になんか方法あるかな?

って、答えになってないか。

Posted by money at 2:14 AM | Comments (0) | TrackBack

March 1, 2005

RDBMSの夜明け

〜via 未来のいつか/hyoshiokの日記

The 1995 SQL Reunion: People, Projects, and Politics,

まだ、読み始めたところなので、全体像は見えてないが、ボイスコッド正規形のボイスさんの話がいきなりでている。こりゃぁ、データベース関係者は必読ですよ。>某大学のDB研関係者。

Posted by money at 5:40 PM | Comments (0) | TrackBack

February 7, 2005

[メモ] AOP関連ドキュメント

アスペクト指向プログラミング
〜via オレンジニュース

Posted by money at 4:37 PM | Comments (1) | TrackBack

November 25, 2004

組織

現場からやってきたXP - LO.GS*DI.GS 主人公の刑事が「リーダーが優秀なら組織も悪くない」と語っている。文脈は少しずれるが、現場だけですべてうまくいくことはないのも事実だろう。
組織というのは、リーダが優秀であることが前提だからこそ、リーダに決定権がある。で、そのリーダは、優秀であるがゆえに、完全にどっぷり現場につからなくても現場の立場で物事を考え、現場が抱える問題点を理解し、その対策等をジャッジできてしかるべき。ところが、優秀でない奴がリーダになっちゃうことが多い。例えば、ここで例に挙がっている「踊る大走査線」というドラマの中で出てくる官僚の偉い方々もそう。あとソフトウェア開発プロジェクトなんてものは最たるもので、技術に口を挟めない奴をマネージャに仕立ててその辺の雑多なプロジェクト管理業務(要は事務処理)をやらせたりするし、最近僕もどっちかと言うとマネージメント寄りの仕事が多いけど、社内のわかってない奴なんて、「あいつはエンジニアとしてはもう終わった」みたいなことを言ってるみたいだし。でも、ソフトウェアプロジェクトが本当に必要としている人というのは、技術がわかるリーダであり「エンジニア」としてのスキルをベースに持っているマネジメントが語れる人なんだと思う。っつってもなかなかいないけどねぇ。
Posted by money at 3:08 PM | Comments (0) | TrackBack

November 17, 2004

メモ: A lightweight nonintrusive EJB testing framework

〜via marsのメモ
A lightweight nonintrusive EJB testing framework[by Java World]

Posted by money at 11:27 AM | Comments (0) | TrackBack

November 11, 2004

ソフトウェア開発支援ツール

今日、仕事の関係で、とあるソフトウェア開発支援ツールに関する営業を受けた。まぁ、早い話が、これを使うと工数が削減できます。プログラムのクオリティが向上します。。。。

まぁ、そのツールそのものの話は、置いといて。

ソフトウェア開発支援ツールと言った場合、主に2通りあると思う。それは、
(1)敏腕プログラマが使うことによって、彼の生産性を向上させるもの
(2)ヘッポコプログラマに強制的に使わせることによって、エンバグの機会を減らし、できるだけ機械的に開発ができるようにするもの

本来必要なのは、当然(1)で、使いこなすのが難しかろうが、それを理解するのにいろんな背景となる知識なりを要求しても構わない。但しこれがあれば、本来はヘッポコプログラマを10人使って四苦八苦しながらコード書いてたのが、その10人を使ってる奴一人で、その10人分の仕事ができるようになるもの。(例えば、の話。もちろん実現できるかどうかは別)

でも、よくあるのって、例えば、難しい内部の仕組みをブラックボックス化して、「なんか知らんけど、こうやって使えば、クオリティの高いソースコードが自動生成できる」というものなんだよね。これだと、万が一の時に自動生成されたソースコードを追いかけることもできない(本来追いかけるべきではないとは思うが、そうとも言ってられん事情が現場のプロジェクトでは起きたりする。)し、そのコードを作ってる本人が、そのコードがわからない、なんてこともよくある話。「なんか知らんけど、できました」ってのが、僕はソフトウェア開発をやってて一番怖いと思っている。これだと、なぜ動いているかがわからないから必要以上にソースコードをいじることに恐怖心を抱く。下手にいじって動かなくなったら動くようにできるかどうかわからないからだ。 プログラマ/エンジニアの地位向上のためにも、ヘッポコプログラマは、壊滅させなければならない。例えば、開発そのものに携わるプログラマとは別に、彼らプログラマのお手伝いとか手足となっていろいろ作業をしてくれるような人(他の業界で言う、医者と看護士のような関係かな?もちろん、上下関係ではなく、業務に必要な知識量が違うんだから同次元で考えるべきではないのだ。)を総称するようないい名前がないかなぁ、と思う今日この頃です。

Posted by money at 7:32 PM | Comments (2) | TrackBack

メモ:EJB Design Pattern

EJB Design Pattern

PDFが無料でダウンロード可能。
Posted by money at 7:11 PM | Comments (0) | TrackBack

September 11, 2004

アジャイルを実践するには

はてなダイアリー - 今日の役に立たない一言 † Today’s Trifle! †

アジャイル関係の本って、アジャイルに興味を持ったプロジェクトマネージャみたいな人が読んでくれない限り、アジャイルが採用されるっことは無いだろうけど、

アジャイルのような開発プロセスな話というのは、技術サイドがどうこう言ってどうにかなる問題ではなく、やっぱりマネージャ陣や、お客さんとの関係、それに政治的な話が必ずついて回る。特にうちのようなウォータフォールモデル前提でしか話のできないところだと特に。
このままでは、いつまでたってもアジャイルはできないので、僕の場合は、コードを書くことを捨て、プロジェクトを立ち上げる側に回ることで、アジャイルの導入にこぎつけた。うまくいくかどうかは今後次第とも言える。まぁ、どう転ぼうが、楽しい実験の日々がまもなく始まる。知見が得られれば、そのうちここに書くこともあるでしょう。

Posted by money at 5:01 AM | Comments (0) | TrackBack

August 21, 2004

コンポネント

コンポーネントとは
人によって見ているものが違うので、「コンポネント」という言葉を無理やりひとつに決め付ける必要もないと思う。 ソフトウェアの世界でコンポネントというと、最近だと確かにEJBがそうだ、という意見が多いように思うが、その前のJava BeanもSunとしては、ソフトウェア部品として捕らえていたし、もっとさかのぼると、Roguewave社のTools.h++もソフトウェアの部品集としてビジネスが成立しているし、C言語のヘッダファイル+ライブラリも、ソフトウェアの部品を指向したものだし、CPANにあるPerlライブラリもそう。要は、見ているレイヤが違う、ということと、どこの層をターゲットとした部品を用意するか?というターゲッティングの話に帰着するような気がする。そういう意味で、ソフトウェアエンジニアじゃない人をターゲットにしてソフトウェアの部品を用意してEUCを実現しましょう、という話になると、まだまだ時間が必要だなぁ、って気がする。今世の中が目指しているのは、あくまでも、「(単価が安い)へっぽこエンジニアを使ってもそれなりに使える(レベルの品質の)ソフトウェアを作るための仕組みづくり」なのだから。
Posted by money at 1:39 PM | Comments (0) | TrackBack

August 16, 2004

エンジニアの集め方

The Python Paradox 〜via 電脳徘徊録
確かに協力会社等にエンジニアを要請する際の要求スペックにはいつも悩む。だって、まじめに書くと、必ず「そんなスーパーマンおらん」としか答えが返ってこないから。結局、本来求めるよりもスペック的に高めで要求を出して、結局採用の時点で妥協する、という形になるんだが。 でも、Javaエンジニア集めるのに、「Pythonできる人」という条件で要請かけたらどういう反応があるかはとても興味あるなぁ。日本だと、Pythonはマイナーだし、Rubyかな。
Posted by money at 4:41 PM | Comments (0) | TrackBack

August 13, 2004

J2EE Development without EJB

読書会のお誘いを受けました。是非是非、参加の方向で。
よろしくお願いしまっす。ところで、いつですか?(笑)

Posted by money at 2:48 AM | Comments (2) | TrackBack

内発的なモチベーションをセットできるような仕掛けを仕込んでおかないと動きません

e-Japan時代の情報政策(上):ソフトウェア産業の3つの課題:経済産業省 村上敬亮氏 - CNET Japan


言い得て妙。
この方は、確かファウラーたんのEA(Enterprise Architecture)セミナーにとあるホテル(半蔵門?)に言った時に、午後の一番最後のセッションで、EAに絡んだ政策執行者の立場で漫談(!失礼。)をされた方。関西弁コテコテで、しかも喋りがうまい。話の内容も論理に飛躍がなくとてもわかりやすい(内容的には、技術屋向けではなく、あくまでも経営陣、政策立案担当者側の視点)という点でとても印象に残っています。
この方のおっしゃることは基本的にAgreeなんだけど、kdさんと同様に、「分業を進めよ」という論旨には首をかしげる。そもそもコスト構造が違うというか。建築はあくまで製造フェーズにお金と期間がかかる。対してソフトウェアは設計段階にコストがかかる。(コーディング、テスティングは全て設計工程とする)。つまり、建築業界は、コストがかかる製造工程は、労働集約型であるのに対し、ソフトウェアでコストがかかる設計工程は知識集約型なんだよね。
村上氏が言及しているソフトウェア工学はあくまでソフトウェア開発を工学的にとらえる、という点で、この建築業界型の開発プロセスを目指そうとした(過去形?)ものではあるんだけど、結局昨今のアジャイル手法の隆盛は結局、ソフトウェア開発は全てがプロトタイピングである、と言っているに等しい。つまり、試行錯誤の繰り返しでしかないわけで、これを労働集約的にこなそうとすることは間違いだと思う。繰り返して言おう。ソフトウェア開発は、全てプロトタイピングである、と。ソフトウェアに完成はない。(なんか、話が飛んだなぁ。。。)

Posted by money at 2:16 AM | Comments (0) | TrackBack

July 12, 2004

オブジェクト指向と構造化プログラミング

via インデントさえあればって…[A.G.Labo blog]



jude-users ML での議論の続き[今日の役に立たない一言 − Today’s Trifle! −]
ストラクチャードプログラミング時代のCOBOLでは、パターンなど無くても、誰でもがどインデントなアプリを少しの勉強で、組めた。


あれ?COBOLって構造化プログラミングをサポートした言語なんでしたっけ?(僕は、COBOLを知らない)という話は置いといて。(インデントと構造化は話が違うでしょ!というのもこの際無視)
構造化プログラミングとパターンだとかオブジェクト指向ってのは粒度というかレイヤの違う話でそもそも比較するのがおかしいと思う。
構造化プログラミングはそもそも、逐次、分岐、繰り返し(ループ)を使ってプログラムを記述しましょう、ということだ。これも、レイヤは違うが、ロジックを記述するためのパターンと言えなくもない。確かに、COBOL全盛期のような頃は、そうだったんだろうが、それは、その程度の難易度の低いプログラムしか書いてなかった(書けなかった)だけであり、「パターンなんぞ知らんでもプログラム書けた」わけではない。つーか、その頃のそういった技術なり、知識なりだけではプログラムを記述することが困難になった(それだけ、アプリケーションに求められるものが複雑になった)という事実がまずあって、必要に迫られ、オブジェクト指向とか、パターンといった新しい考え方が生み出された(整理された)とするのが正しいと思う。プログラムの断片(サブルーチンと言ったり、最近では、メソッドかな)を記述するのに用いるのが「構造化」という考え方であり、そうやって組んだプログラム片をどのようにより大きなプログラムに統合するか、つなぎ合わせるかという観点で用いられる道具が、「オブジェクト指向」であり、「パターン」である、と考える。つまり、両者は相反するものではなく、視点が全く異なるものだと思う。

そういえば、僕が就職活動をしていた頃のことだ。とあるオブジェクト指向に強い会社に見学をさせていただき、実際にその部署の方とお話させていただく機会を頂いた。
当時、僕はOMTというオブジェクト指向ソフトウェア開発手法に関する研究に従事しており、日頃から感じていた、「OMTを始めとする開発方法論は難しすぎる。専門家はまぁいいとして全てのソフトウェア開発に従事する技術者がみな習得できるとは思えない。もっと簡単な方法論が必要なのではないか?」という疑問を失礼ながらもぶつけてみた。そのときに答えていただいた回答は、
「開発方法論は、全ての人が勉強する必要はないし。必要と思ってる人も限られるだろう。現状の技術なり、やり方なりで問題なくできる人はそのままでいいんだからどうでもいいし、相手にする必要はない。現状の技術ややり方では上手くいかない問題を持っている人がその問題を解決するために学べばいい。あくまで必要としている人にとって役に立つための道具であり、そういう人であれば、おのずと勉強するだろうから、難易度は問題とはならない。」というものだった。当時まだ開発現場を知らない学生の立場だった僕には目からウロコが落ちるほどの衝撃だった。それ以来、僕は「オブジェクト指向」を全てのソフトウェアエンジニアが学ぶ必要はない、と考えるようになった。

Posted by money at 7:12 AM | Comments (2) | TrackBack

プロジェクトのコスト計算

デスマーチが起きる理由 - 銀の弾丸は魔法ではない

『人件費をプロジェクトのコストとしてプロジェクト単位に集計することには、正当な根拠が無い』

本当なんだろうか?これが正しいとしたら、うちの会社のやり方は当然間違っていることになる。うーん。まだわからん。しばらく考えてみる。

Posted by money at 4:08 AM | Comments (0) | TrackBack

June 30, 2004

アジャイルでオフショア

この道はいつか来た道... REBOOTED: アジャイルを使ってオフショア開発

知らぬ間に、マーチンファウラー氏の原文がアップデートされてました。どうりで、ここ最近、原文から飛んでくる方が多数いらっしゃったわけですね。すいません。早急にキャッチアップします。しばしお待ちを。

Posted by money at 1:58 AM | Comments (0) | TrackBack

June 27, 2004

EJBの使い方

はてなダイアリー - koichikのひとりごと

それでもEJBは注目と期待を集め続けてきたようですが,多くの人が必要としたのは「ビジネスコンポーネント」を実現する技術としてのEJBではなく,単に宣言的トランザクションやO/Rマッピングを使いたかっただけというのが現実のようです.不幸にも,それらを実現する最も身近な存在がたまたまEJBだった,というだけのこと.


この文を読んで思い出した、とある人がおっしゃってたことば。
「みんなねぇ、ITだITだって騒いでますけど、だれも、インフォメーションなんか求めてないのです。みんなが求めてるのは、あくまでもデータです。」と。

つまり、データかを有機的に結び付け、それが情報になるのだが、そんな高度で抽象的なことを望む人はいなくて、あくまでも、データであり、テーブルであり、ちょこっと便利な、SQLクライアントが欲しいだけ。だから、本来はもっと使われるはずのEJBが、しょせん、宣言的トランザクションだとか、ORマッピングだとか、そういう、小手先の技術をまかなうものとしてしか使われなかった、というのが真相なのではないだろうか。
僕は、元(?)OODB屋なので、ユーザにデータベースを直接触らせるべきではないと考えているが、データベースを直接触りたがるユーザが多すぎるような気もする。

Posted by money at 5:59 PM | Comments (0) | TrackBack

EJB論

はてなダイアリー - koichikのひとりごと
以前に、koichikさんの「EJBはすでに死んでいるというエントリを読ませていただいて、とても面白かった。でも、それが、とあるメーリングリストで物議となっているようで、いささか宗教論争のようだ。でも、我々エンジニアはそれぞれの要素技術を道具としてソリューション(あるいは現実に動くシステム)としてアウトプットを出すことが重要なんであって、その道具として使える、使えないというのは、それぞれの置かれている立場や、解決しようとしている問題、あるいはコストだとかいろんな面で判断するんであって、koichikさんの「EJBは死んでいる」という発言に対し、外野が「それは間違っている」と反論するのってなんか筋違いのような気がする。koichikさんは、彼の立場から「EJBは使えないー」と判断しただけであって、もちろん、使えると判断する人もいるだろう。それは、その人が、EJBを使って素晴らしいシステムを作ってしまえばよくって、「ほら、EJBって使えるでしょ? これがあれば、楽できるし、信頼性の高いシステム作れるんだよよ。まぁ、使う、使わないはあなた方の勝手だけどね」でいいんだと思う。それをどう評価してどう取り入れようがそれは、その人の責任でやればいいわけで。僕は、使える、使えないの不毛な議論なんかではなく、「使えるんだ」という人による、「実績」だとか、実際に動いているものだとか、あるいはこういう風に使うといいよ、とか「適用事例」だとか、もっと先の話を知りたいと思うのだ。

Posted by money at 5:49 PM | Comments (0) | TrackBack

June 13, 2004

テスト軽視

で、ソフトウェアというものはちゃんと動いているかを確かめるのがとても難しい部類に属するというところじゃないでしょうか?

本来はそのために受け入れテストやQA部門があるのでしょうけど、ちゃんと動いてない気がする。

日経ITプロでもなぜテストは軽視されるのか?という記事があるくらいですし。


・有能な人材を人海戦術的に見える(?)テスターに回すだけの人的リソースがそもそもない。(テストするぐらいなら設計とか検討してよ!と思ってしまう。) →この時点でテスト工程が軽視されている。
・実は、他の産業に比べて試験工程の重要度が高い
・でも、検討、設計にウェイトを置けば試験の重要度が軽くできる、という妄想がはびこっている
・試験は、プログラム書いたものと別の人間が実施すべきだ、という仮定に立つと、プログラム書ける人間を試験工程に温存させる余裕がない。→結果、プログラムが書けない人間が試験にあたる。 → プログラム書ける奴はプログラム書け、書けない奴は、試験要員に回せ、というロジックが成り立つ?
・理想は、設計者が試験することだろう。
・でも、試験工程やってるころって、設計担当って、次のフェーズの検討やってたりしない?
・あと、有能な人材って、試験工程時は、バグ発生時の解析担当だったりするなぁ。
・やっぱり、それらに回せない人間が試験やるしか
・試験って、ブラックボックステストと称して実装を知らない人間を当てるべき、という風習もあるねぇ
・でも実装を知らない=何も知らないじゃないはずなんだが。
・プログラム書けない、コンピュータの基本すら分からない新人が余ってるんだけど、なんか仕事ない? → 試験のオペレータでもやらせとけ。
・QA部門がちゃんと機能するためには? → 要件定義からQA担当をプロジェクトに張りつけなきゃ。 → そんなに人いるわけないだろ。 → でも、出荷前にチェックはするよ。それがQAの仕事だもん。 → 要件知らずに、何をチェックするの?

ざっとこんなもんではないかと。うーん、デフレスパイラル。何とかしたいな。

P.S.
どうやら、ソフトウェアへの情熱は失ってないようです。じゃ、なんでモチベーションが落ちてるか。それは、ちとここでは書けません(笑)。でも、ありがとう。>K氏

Posted by money at 12:53 AM | Comments (1) | TrackBack

June 9, 2004

マーチン・ファウラー特別ラウンドテーブル 現場レポート [前編]

ファウラー 基本的に、一括請負契約という考えは危険な幻想だと思っています。

平澤 それは開発者側の立場から?

ファウラー 開発者と発注者、両方の立場から。(中略)一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。

一同 (笑)。

いやいや、こんだけ早々たるメンバが集まっていながら「一同 (笑)。」って。笑ってる場合じゃないだろ。
一括請負契約(僕の会社でいう、製造請負)がダメだとすると、残るは業務委託、つまり、人貸し頭数ビジネス、要するに人月計算ということになると思うんだが、マーチンは本当にそういう意図だったんだろうか?
一括請負契約がダメのは、GOALが見えない段階で見積もりをし、GOALが確定しない段階でGOALを保証する契約だからだ(これが、マーチンが言うところの『一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。』という言葉)。
だから一括請負契約は、開発側が全てのリスクを背負う契約とも言える。それを顧客、開発側双方でそれなりにリスクを分担しましょう、というのが、アジャイルの基本姿勢だと思う。そうすることで一方的に押し付けるのではなく、両者が協調する、と。
でも、実際は開発側も一括請負契約であることをエクスキューズに使うことが多い。曰く、「あれだけわがままな仕様変更に対応したんだから、少しぐらい品質は目をつぶってよ」とか。
ケントベックだったか誰だかは忘れたが、アジャイルで細かく刻んだイテレーション単位で契約するんだ、という話を以前にどこかで読んだ記憶がある。こうすることにより、あるイテレーションの中では、これまでの一括請負契約の形にはなるが、仕様変更は次のイテレーションに回すとか柔軟に対応でき、イテレーションの中では、GOALが明確になるのでリスクは減るというわけだろう。でも、これってベースになるシステムは既にあって機能追加がどんどん発生している状況ではとてもうまくいくだろうけど、最初のベースとなるシステムを開発するフェーズでは難しいような気もする。僕は、このフェーズをうまく回し、継続的イテレーションを軌道に乗せるまでのうまいやり方が知りたい。

Posted by money at 2:36 PM | Comments (0) | TrackBack

ITは職人の世界?

 しかし話を聞いていると、ITプロジェクトのお客さんは素人が多いようだ。

 さらにITプロジェクトはベンダーも素人である場合が少なくないのではないか。

 素人同士が仕事を進めて上手くいくわけがない。
上司に恵まれないSEのために〓自分戦略策定ブログ α

まあ、今のITプロジェクトが職人芸なのは誰しもわかっていることでしょうが…

I現状は、ITの素人とITの素人が無い知恵を絞りながらなんとなく作ってるような気になってる、というのが正解ではないかと。
では、ITのプロフェッショナルはどこにいるか?というと、僕はベンダの製品開発チーム、研究機関にしかいないのでは?と思っている。開発ツールで商売しているベンダの売り文句は、必ず「だれでも簡単に使えます!」であって、「素人が触っちゃ、怪我するぜ」なんてツールは基本的にない。(実際は、そんなツールばっかりだけどねぇ) まぁ、本来職人技であるはずのシステム開発を素人集団作業になったのはソフトウェア工学が製造業のメタファをソフトウェアに持ち込み、工場のベルトコンベアー式流れ作業よろしく単純作業にブレイクダウンしようとした結果、その建前だけが一人歩きしてしまったのが原因ではないだろうか?と勝手に想像している。製造業メタファで語るとすると、例えば、テレビの設計というのは、電子工学が分かってないと当然ダメなわけで必然ながら、電子工学のプロフェッショナルが行うことになる。でも、工場の生産現場は、電子工学のプロがいる必要はない。
翻ってソフトウェアの開発を考えると、ソフトウェア工学を学んだプロフェッショナルにしかソフトウェアの設計ができないか?というとそうでもない(本当は、できないといいたいところだが)し、テレビの設計というのが、設計図(つまり、回路図)を書いて、試作して動作確認して初めて、どうやって大量生産のラインにのっけるかを考えるのに対し、ソフトウェアの設計と言った場合にその粒度は人それぞれ。しかも、製造工程にコストがかからない(つまり、ファイルコピーだけ)ので、ハードウェアで言う、設計、試作工程(研究所内で特定のプロフェッショナルだけが携わる工程)をソフトウェアの製造工程にマッピングしてしまっている(さらに、ここはマンパワーを要することもある)のでごっちゃになっているのだ。ソフトウェアの開発を工学的見地から研究する、というソフトウェア工学のテーマは必要なことだと思うが、実際の開発現場としては、「工学という言葉を使ったことが全ての誤解の始まりである」と思わずにおれない。ソフトウェア工学の研究者出身の現場デベロッパとしては、とても歯がゆい思いである。

話は戻るが、ITプロジェクトの場合、最高意思決定者がド素人なんだよなぁ。昔、(社会人1年目のころ)偉い人に、「君、プログラム書けるの? どれぐらい書けるの? すらすら書けるの?」と聞かれたときは、めまいがしますた。この一言で、ソフトウェアというものが、世の中で理解されていないことを痛感したことがあります。文法さえ知ってればプログラムが書けると誤解してる方も多数いらっしゃいますし。日本語かける奴は、日本に1億人ぐらいいるが、小説書ける奴は限られるんだ、ということを理解していただくにはどうすればよいのだろうか。

まずは、ソフトウェア開発から「製造工程(いわゆるメイク、テスト工程」という言葉をなくし、ソフトウェア開発は全てが設計工程なんだ、というところからスタートしないとダメか。

でも、「コーヒーとソフトウェアは素人が作るもの」という言葉もどっかで聞いたことあるしな。素人が作るという前提で開発環境(ツールや、理論等)を整備しないとダメなんだろう。

Posted by money at 2:21 AM | Comments (0) | TrackBack

May 20, 2004

ソフトウェアエンジニア教育

そこで、何を教えるかですが・・・『武士道』です。つまり、プログラマとしての道徳や精神性を教えるべきです。
去年、新人が入ってきたときの技術研修としてオブジェクト指向を教えた。といっても、継承が、とかクラスは、、みたいなことを喋ったところで、頭の片隅に残る確率は、ほんのわずか。そこで、オブジェクト指向の話はほどほどにして、「ソフトウェア開発で伸びる人,伸びない人」と題してしゃべった。ネタは、当時のSoftware Peopleという雑誌の特集。これをネタに、どういう姿勢で技術を身に付け、考え、仕事と接していくべきか、という話をした。たぶん、自分たちがこれからつこうとしている職業はどういうもので、それを武器に今後食べていくにはどういうマインドが必要か、というのはきっと入社してすぐ、という不安な中で語ってあげるのが効果的だと思う。でも、彼らにとっては、研修で講師が「こんな奴いらん!」と言ってたような奴が、直属の先輩になったりして困ったりするんだろうな、と思ったことも事実。
Posted by money at 10:56 PM | Comments (1) | TrackBack

May 19, 2004

ジャクソン法とOO

ジャクソン法とオブジェクト指向 09:47

根っことなる部分は同じような気がする。

コメントが書けなかったのでこちらにて。
学生の時に、ジャクソン法をかじった頃の記憶ですけど。OMTのジェームズランボーがどこかでジャクソン法に言及してたような記憶があるのですが、、、定かではありません。

個人的には、オブジェクト指向におけるモジュール化、データの局所化の考え方は、ジャクソン法に影響を受けているように思います。

名前からしてもっと有名になってもいいと思うんだけどな。>マイケルジャクソン

オブジェクト指向を嫌がるぐらいならせめてジャクソン法を...と日頃思うこともしばしば。ジャクソンクラッシュがネガティブな印象を与えるのでしょうか?


Posted by money at 12:05 AM | Comments (3) | TrackBack

May 13, 2004

情報隠蔽とカプセル化って違うもの?

遅ればせながら、この話題。
僕には正直、未だその違いがよく分からない。
一般に、物事の複雑性をコントロールする、つまり、単純化するということはよく行われていて、そのために手段が、分類とか仕分けと言われるもの。その分類した結果、全体の1集合から複数の部分集合が得られる。その部分集合の中の要素各々の共通的な特徴を引っ張り出して、その部分集合の特徴として位置付けることを抽象という(僕の理解だとこんな感じ)。
さて、オブジェクト指向とは何かと言われると「抽象データ型とメッセージパッシングによる現実世界のシミュレーション」という答えを出すまでもなく、そもそもシミュレーションがきっかけとなり、オブジェクト指向が生まれた。そこでは、實世界の登場人物(人である必要はないけど)をオブジェクトという、ある固体として表現し、メモリ上で現実世界を模した。その際にオブジェクトという「何かしらの生存物」という固体として表現し、その中身を隠蔽した。
つまり、あるドメイン領域に注視する際に、本質を得るために、複雑性を排除するには、余計なものを隠すのがまず行うべき戦略である。これを情報隠蔽という(というのが僕の理解)。
例えば、役所(銀行でもいいけど)の窓口を考えると、住民が役所に行って行うことはある程度想定できる。その想定要件ごとに窓口を設け、必要なデータさえ(紙に書くなりをして)提出すると、望みの書類が入手できる、ということになっている。ここで、住民に、役所の内部のワークフローなり、組織なり、書類発行のための仕組みなりを知らせる必要はなくて、単に書類に必要事項を書いて提出することのみを求める。この、役所内部の仕組み等を隠す、ということが情報隠蔽に他ならない。GoFのデザインパターンで言うところの「ファサードパターン」だ(僕は、ずっと、フェケイドパターンって読むんだと思ってたけど、最近になってようやくファサードってかな書きを見るようになった次第)。
で、話を戻してオブジェクト指向でシステム、特にソフトウェアを考える、というのは結局のところ、複雑性を減らすことが一番の目的であり、この情報隠蔽が当然有益となる。では、オブジェクト指向設計における「隠蔽すべき情報」とは何か、というとこれは、各オブジェクトのもっている属性とか内部のロジックだったりするわけだ。そこで、抽象データ型という概念が出てくる。
一般に、オブジェクト指向の入門書によくある抽象データ型の説明として、属性を隠蔽し、属性へのアクセスを可能とする関数(メソッド)を用意し、その関数を経由しないで、直接触らせることを認めないようにしたもの、というのをよく見かけるが、「抽象データ型」というのは文字通りデータを抽象化した型であり、「なんかよーわからんけど、ここ(あるオブジェクト)にそのデータはある、実際にどういう型で定義してあるかなんてどうでもいいやろ? この関数使えば、関数に指定された型で返すから、それでいいやん」なんじゃないかと(僕は勝手に理解している)。
つまり、この抽象データ型をプログラム上(言語仕様上)実現しているものがすなわち「カプセル化」という機能であり、そのカプセル化を実現するための言語仕様上のメカニズムが「クラス」というものであり、クラスは個々のインスタンスを抽象化して定義したものだ。(と、勝手に理解してまつ)。

というわけで、僕の中では、情報隠蔽とカプセル化というのは、本質は同じもの、だったりするのです。
つまり、プログラミング上、情報隠蔽を実現するための言語仕様上の機能としてカプセル化というものがある、と。
でも、インタフェースだけ見せて実装を隠蔽する抽象クラス(Javaでいうインタフェース)、あるいは前述のファサードパターン、どれも粒度こそ違えど、情報隠蔽の手段であり、やってることはカプセル化を実施することで、ぶっちゃけ「中身を隠している」という意味で同じ、と僕は理解しておるのです。

#間違ってるのかな? あ、ひょっとして、情報隠蔽とカプセル化というのは、クラスとインスタンスの違い? だったら、やっぱり全然違うじゃん。 やりなおーし。見事玉砕。

Posted by money at 7:03 PM | Comments (0) | TrackBack

プロジェクトの目的

以前、『本プロジェクトの目的は、速やかに納品して1日でも早く検収をあげることである』と本気で言われて、「じゃあ開発しなきゃいいじゃん」と口まででかかったことがあるなんていう話はフィクションです。

こういうお馬鹿さん、実際にいる、いる。基本的にこういうなんでもいいからとにかく早くやれ、でも品質の低下は許さない、みたいなスタンスの人間は、中身がわからないから中身に対するこだわりもないし、なぜそれだけ期間や、人的コストがかかるのかが理解できていない。とにかく、リーダとしてプロジェクトをどうするかとかってビジョンは全くなくって、単にアウトプットを早く出してお客さんに、「いい子でちゅねぇ〜。なでなで」して欲しいだけだったりする。まぁ、精神構造が子供なわけだ(得てして、おじさんばっかりなんだが)。まぁ、日本の高度経済成長は、自分で考えて行動できる人間を排除し、何も考えずにがむしゃらに動く人手を大量生産してきたからだろうけど。でも、本人の立場にたって考えると、えたいの知れないソフトウェアというものを作るプロジェクトの責任を押し付けられ、でも、プロジェクトマネジメントするための教育も受けたわけじゃなく、自分もそれまでにそういう経験をやってきたわけでもなく、言ってる内容はよくわからないけど、お客さんは、とにかく早くって言ってる、部下はそんなんじゃできない、もっと期間が必要だとは言ってるが、なんで必要なのかもわからない。プログラムって書くんでしょ?書けばいいじゃん。文法は決まってるんでしょ?何を悩んでるの?お前らプログラマだろ?プログラム書けるんだろ?さっさと書けよ、俺はよく分からないけど、なんて風になると、どうしてもそういう姿勢になっちゃうってのは理解できるんだよなぁ。

そういや、デマルコのデッドラインにも最初は、120日かかります、って言ってた開発に、100日でやれ、って命令して、なんとか100日でリリースできるよう目処ができました、って話になると、じゃぁ85日でやれ、ってどんどんエスカレートしていく話があったように記憶してる(数字は適当)が、まぁ、努力と根性と献身的な姿勢だけが重んじられるこの世の中で、PMBOKのよなプロジェクトマネジメント技術が生かせるところがあるのかはなはだ疑問。

あ、当然ながら、この物語はフィクションでございます。登場人物、組織等は全て架空のものだと思われます。

Posted by money at 2:32 PM | Comments (0) | TrackBack

組織とリーダーシップ

小沢氏の受諾の可能性については「今のところ中立的だ」と述べた。

 調整の焦点となっているのは、執行部人事や新代表の任期だ。小沢氏周辺によると、小沢氏は岡田氏との会談で、挙党態勢確立と人事の一新を求めた。これに対し、党執行部内では、「国会対策委員長の交代はやむを得ないものの、幹事長や政調会長など現執行部体制の骨格は維持すべきだ」との声があがっている。また、小沢氏側は、党規約を改正し、9月の代表選を行わず、2年4か月の任期を要求した。折り合いはつかず、調整は13日以降に持ち越された。

 党幹部の1人は12日夜、「小沢氏に全権委任しろというものだ」として強く反発した。


民主党、菅代表が自ら墓穴を掘り退陣したのを受けての後任人事に、小沢一郎氏が要請を受けたらしい。それに対する小沢氏の執行部刷新の要求に対し、「横暴だ」という反発をしてる輩がいる、とのこと。
なんというか、日本的というか、分かってない、というか、まぁ、うまいこと世渡りして勝ち馬に乗りつづけないと生きていけない政治家先生たちでさえこうなんだから、世間だともっとダメなのは当然か。
民主党は党としての総意として、小沢氏に代表就任を要請した。小沢氏としては、この要請を受け止め、自分が代表になる以上、責任もって民主党を率いていかないといけない。だからこそ、自分がリーダーシップを発揮できる条件を整える、という意味で、執行部刷新を挙げたのだと思う。それに対して「横暴だ」といってるバカは、おそらくリーダーシップというものが分かっていない。つまり、この「横暴だ」といってる奴は、「小沢の好きなようにはさせん。でも、ダメだったら責任だけはちゃんととれ」と言ってるようなもんだ。これじゃリーダーシップも何もない。日本の組織というのは得てしてこんなもんだと思う。
ソフトウェア開発のプロジェクトを任せられ、プロジェクトを成功に導くのがプロジェクトのリーダたるプロジェクトマネージャの役割だ。ところが、そのプロジェクトにおいてプロジェクトを成功に導くために必要な権限が与えられない、ということはよくある話だ。つまり、責任を取らされる立場にたたされながら、自分の責任を果たす以前に、上役の意向の実現を強制させられるのだ。そういうときに口を挟みたがるものは責任を取りたがらないが口を挟みたがる、という奇妙な性質を持つことが多い。そうしt、日々そういった横槍に左右させられながら、プロジェクトをなんとか軟着陸に持っていく。順調にプロジェクトを進めていると、暇そうだな、と、新しい案件やれ、とか、要員を剥がしにかかったりして、当初の予定通りのリソースが与えられることはまずない。結果、プロジェクトを成功に導くために、順調であることを隠さなければならないとか、プロジェクトが火を吹いているように思わせないといけない、という本末転倒の状況におちいりがちなのだ。

あと、昔にあった話だけど、システム間でデータを渡しあう必要が出た際に、お客さん、というか上位のSEが何も考えずにNFSとFTPを使う案を提案した。こちらとしては、そんな状態管理すらできないプロトコルは将来のトラブルの元なので、反対したのだが、エンドユーザのお客さんにとっては、使い慣れたプロトコルだし、なじみあるし、NFSが信用ならない仕組みだなんてことは知らない(普通のSEも知らないらしい)ので、押し切られた。あとでどうなってもしんないよー、とか思ってたら、案の定、ファイルが渡ってるはずなのに、渡ってないとかって変なトラブルが後日発生することになる。ここで、仕様です、しかたありません、というのは許されなくて、でもFTP,NFSの採用を取りやめて別の信頼性のある方式を取る、ということも許されなくて、今のこの仕組みをつかって、データ転送を保証せよ、というむちゃくちゃなオーダになる。

そういや、前に田中真紀子が大臣のときに、「総理が自由に活動しろ、と言いながらも後ろで、本人がスカート踏んでるのよ」なんてことを言ってたが、「がんばって手腕を発揮してくれ」といいながら、手足には手錠をはめられているような状況のように感じる今日この頃なのである。

#オチはない。

もちろん、与えられたリソースの中で、最大限の成果を出すのがリーダだ、といわれればその通りだとは思うんだが、実際は、そんなことはなくって、「与えられた限られたリソースの中で、『もし、理想的なリソースが投入された場合に実現可能な最大限の成果』を求められている」ような気がしている。で、もし、その充てられたリソースの中でなんとかうまくプロジェクトを回していると、暇そうに見えるようで、リソースを減らされ、あたかもプロジェクトを順調に動かすことはいけないことのような仕打ちによくあう、のは僕だけなんだろうか? いや、もちろん、プロジェクトマネジメントとは何ぞや、って話が通用しない奴らが相手なので理屈が通らない人種であることは理解してるんですが。(この物語はフィクションです。登場人物その他は、似たような事例があるかもしれませんが、あくまでも架空なはずです。)

Posted by money at 11:45 AM | Comments (0) | TrackBack

May 2, 2004

ソフトウェア開発を語るためのメタファ

先日のエントリで、プロジェクトを野球に例えた件について、「例えが悪い」というご指摘をいくつか頂いている。まぁ、その件については、当事者同士では通じているので構わないんだが、昔からソフトウェア開発を語る上でいろんなメタファが使われてきたが僕はどれもしっくり来ない。今回はそれについて少し考えてみたい。
ソフトウェア工学という面で見る場合、よく出てくるのは製造業のメタファであり、実際の開発プロジェクトのマネジメントを議論する上でも、あるいは実際のソフトウェア開発プロジェクトを考える上でも必ず出てくるものの1つだ。つまり、作るべきものをはっきりさせ(分析、要件定義)、それをどのように作るかを考え(設計)、実際に作る(製造)、というあれ。製造業をメタファとすることの弊害等については、以前にも触れたのでここでは触れない。また、クリストファーアレクサンダーのパタンランゲージに代表される建築の世界にも例えられることが多いがこれも僕にはしっくりこない。
以前に、ドラマ、「白い巨塔」を見てるときに、カンファレンスの中で財前教授が言った「ナースは黙ってろ」という言葉を聞いてはっとした。
ソフトウェアの世界は個人の資質等によって生産性には大きく違いがでる、とはよく言われる。優秀なプログラマとそうでないプログラマでは、最大*倍(この数字はいろいろ説あり。仮に10倍としておこう)の開きがある。だから、優秀なプログラマを2倍の給料で雇えば効率がいい、と。じゃ、そもそもなんでそれだけの開きが生じるのか? これはソフトウェアに特有のものなのだろうか、と。 で、先ほどの「ナースは黙ってろ」という言葉なのだが、僕の昔の一時的な入院経験とか医療ドラマ(「振り返れば奴がいる」が好きだったりする)といった断片的な知識でしかないのを最初にお断りしておく。
医療の現場では、医者、ナース、アテンダント、病院事務、薬剤師、放射線技師等いろんな方が従事しておられる。それぞれが役割を持ち、それぞれに応じた専門教育がなされている。翻ってソフトウェアの世界はどうだろう? 実は、先ほどのカンファレンスを例に言うと、医者とナース、アテンダント、病院事務局長、薬剤師、放射線技師と言った経験も立場もバックグランドも全然異なる人々が一同に会し、あるクランケの病状と治療法を議論している、というのがソフトウェアの世界で実際に行われていることなのではないだろうか?つまり、幸か不幸かこれまでソフトウェア業界では、人月という言葉にあるように、人間の頭数と作業にかかる時間で規模等を測ってきた(いる)。そこでは頭数が重要であり、資質とか前提知識は問われない。また日曜プログラマが存在するように、素人と玄人の区別がつきにくいのも特徴だ(日曜外科医なんていない。。。)。 でも、冷静に考えると、ナースがいくら経験を積んでも医師にはなれない(もちろん、医師以上に、クランケの容体に敏感な洞察力のあるナースは実際にいらっしゃるであろう。しかし、ナースにメスを持たせることはないはずだ。そういう教育をされていないから。また、日曜大工が趣味という人がいくら経験を積もうと、あるいは土木作業員の経験をいくら積んでも例えば超高層ビルや巨大橋梁の設計に携わるようになるか、というとこれもありえないだろう。これもそういう教育を受けていないからだ。
ところが、ソフトウェアの世界ってこれと似たようなことを実際にやっちゃってる、ような気がしているのだが、これって僕の周りだけ?まぁ、病院の医療事務局長が、ドクターのオペ技術を評価しないとは思うが、たぶん、ソフトウェアの世界では似たようなことやってるよなぁ。でも、誰が言ったかは知らないが、「ソフトウェアとコーヒーは、素人が作るもの」とも言うし。

Posted by money at 8:01 PM | Comments (1) | TrackBack

(続)プロかノンプロか

とても多くのコメント、トラックバック、リファラありがとうございます。こんなに反響あるとは思いませんでした。一部で誤解されてるところがあるので、本人の名誉のためにも補足しておきます。件の「若い同僚」が悪者のように捉えられている節がありましたが、それはありません。メタファーが悪い、とのご指摘も頂いてますが、あえて前回と同じメタファーで例えると、彼だけが僕の剛速球を受けていた、と言ってもいいでしょう。で、今回彼が、僕に指摘したことは、「エンジニアに成り下がってんじゃねーよ。プロマネの仕事忘れるなよ?」ということなので、僕としては、参謀からの進言としてとても納得してるんですが。これも僕の文章力の至らなさかが根本原因かと。 とても反省。
Posted by money at 6:14 PM | Comments (0) | TrackBack

April 29, 2004

プロかノンプロか

今やってるプロジェクトで設計レビューを実施したのだが、レビュー会場に向かう前に、上司から
「レビューでは、優しく対応してやってくれ。そうでないとボスのところにクレームが来てるんだ。頼むよ。」
と釘をさされた。
「それは手を抜けってことですか? 他社の一線で活躍するソフトウェアエンジニアさんをプロのエンジニアとしてのプライドをもった人として扱うな。新人のように丁寧に扱え、ってことですか?それって相手をバカにしてません?」と聞き返すと、
「いやいつも僕と対応する時のようにやさしく言葉を選んでくれればいいだけだよ」
「ああ、エンジニアとしてではなくド素人だとして対応しないといけない、ってことですね。だったら、僕は出ない方がいいですよね。僕は出なくてもいいでしょ?」
「いや、出て欲しい。」
「なんじゃそりゃ?」
「出て、ちゃんと気づいたところを指摘して欲しい。いてくれないと僕が不安なんだ」
「手を抜け、って言っておきながら、結果としてmoneyも了承したレベルのクオリティのアウトプットを期待してるだけじゃん。言ってること分からないですよ。どうせ僕が参加しても進捗阻害要因にしかならないですよ」

当然ながらレビューではいろいろと怪しいところというか、「何考えてんだ?」ってなところが見つかり結果的にいろいろ指摘した。
「なんで、わざわざ、ちゃんと決まってる仕様をわざわざ崩して曖昧な表現に書き換えるんだ? そんなことしてるから後々問題が見つかるんだ。何考えてんだよ?」とか、「てめえで判断できねえんだったら、できる奴連れて来い」とか。(言葉尻はもう少し丁寧です。)

その後の休憩時間中に、若い同僚からご指摘を頂いた。
「moneyさん、リトルリーグ相手に大リーグが剛速球投げてはいけません。相手が打てないのはもちろんのこと、味方のキャッチャーすら取れないじゃないですか。」
「いや、おれは、少なくともソフトウェアを作る、ということで飯を食ってるプロ同士だから、お互いが同じプロ野球のマウンドに立ってると考えている。だから、自分のベストの球を投げないと、相手に対して失礼だろ。」
「それ、間違ってます。じゃ、moneyさんが仮にプロ野球だとしましょう。相手は高校野球ですらありません。リトルリーグです。これは、親善試合なんです。ガチンコじゃない。だから相手が打ち返せるレベルの球を投げてあげないといけないんです。moneyさんの指摘したことは全て正論です。正しいです。本当はそうあるべきです。でも、誰も分かってないですよ。うちの連中も相手側も。誰も理解できてないです。だからどうせ、まともな試合になんかならないんです。手を抜かなきゃだめ。どうせ、いくらがんばっても相手の100%のレベルにしか到達できないんです。ここでプロ野球レベルの剛速球を投げることになんの意味もない。それを取り入れて成長することすらできないレベルです。大人気ないだけ。その辺、ちゃんと分かってください。」

つまり、別に誰もちゃんとレビューすることを求めているのではなくて、結果としてレビューを実施した記録が残っていればいいだけなんだ。僕は勘違いしてました。レビューとして実りあるものにすべきだと思ってました。ソフトウェア開発ごっこができればいいんですね。とても反省してます。。。。

#いいのか?これで。 てtいいんだろうなぁ、きっと。

Posted by money at 2:37 PM | Comments (4) | TrackBack

April 19, 2004

ソースを読もう

もうかなり前になるが、社内のWebサイトにこんなコラムを書いた。


生涯一プログラマ


そんな当時読んでいたシリコンバレー日記が装いも新たに帰ってきた
で実は、当時のシリコンバレー日記に書かれた、某O社のデイリービルドに関する記事を元に僕は、自分のプロジェクト(当時プロジェクトは始まったばかしでまだソースコードが存在しないプロジェクトだった)にCVSを核とするソースコード管理の仕組みを導入した(新人のくせに偉そうな奴であった)。まずは、CVSを調べるところから始まった。その過程でぶつかったmozilla.orgCVSに関するドキュメント日本語訳を社内の啓蒙用として作ったことがきっかけでもじら組に係わることになった。
そのときのプロジェクトに導入したCVSを核とするデイリービルドの仕組みは未だにプロジェクト内で脈々と受け継がれており、件の某DBカーネルにはかなわないが、社内史上最大規模のソフトウェア(某キャリア向け大規模ネットワーク管理システム)の構成管理、リリースエンジニアリングをささえるインフラとして定着した。
つまり、今の僕があるのは、シリコンバレー日記のおかげである、と言っても過言ではない。そんな氏の手による日記が再び読めるようになった。かつて嬉々として読んでいたコラムを再び読み返して感じたことは、「ソースを読まなきゃ。」であった。

Posted by money at 4:35 AM | Comments (0) | TrackBack

April 6, 2004

PofEAA パターンカタログ

誰でも参加可能、ということで僭越ながら1日1パターンを目標に。
Posted by money at 1:22 AM | Comments (1) | TrackBack

April 2, 2004

CMMI1.1 公式日本語版V1.1

出てたので、メモ。
Posted by money at 2:46 PM | Comments (0) | TrackBack

情報学

科研費に「情報学」という領域ができたらしい。
いまだに情報学=情報科学/工学という日本の常識(=世界の非常識)を打ち破ることができるか!?


「情報学」と聞いて、日本初の情報学の学会を作っちゃった、うちの研究室の大ボスが何やらがんばってるのか?と思ったけど、レジュメを見た限り、ちと分野が違うような。たぶん、違うでしょう。そういや、自己組織化情報がどうこう言ってたなぁ、と最近創発―蟻・脳・都市・ソフトウェアの自己組織化ネットワーク スティーブン・ジョンソン (著), 山形 浩生(訳)を読みながら思いを馳せている今日この頃。

でも、山形さん,仕事速すぎ。出版流通に乗らないものをあれだけ訳していながらこう次から次へと。読むのが追いつきません。

Posted by money at 3:26 AM | Comments (0) | TrackBack

March 28, 2004

仕事は趣味ではない

というのは、フツーの文脈では、「遊びじゃないんだから真剣にやれ」という意味であるとか「遊びじゃないんだから規約を守れ」というどちらかといえば積極的にプラス方向へモノゴトを進めるために使うべきものなのだが、ことプログラムに関して言えば、「手を抜け」であるとか「後先を考えちゃおしまいよ」とか「目先の利益優先」とか「形式さえ合っていれば内容は問わない」とマイナス方向へ進めるために利用されているのではなかろうか。


昔、同じセリフを違う部署の部長に言われたことがある。そのとき彼が言いたかったことは、「仕事は趣味ではない。だから仕事で楽しみを求めるのは不謹慎だ。」というような文脈だった。そのとき僕は、「この人は可哀想だなぁ。」と思い、何も突っ込まなかったと同時に、この人とだけは仕事をしたくないな、と思った。

Posted by money at 2:13 AM | Comments (0) | TrackBack

March 27, 2004

ITアーキテクトへの道

新入社員相手の研修のネタに使えそう。
Posted by money at 10:33 PM | Comments (1) | TrackBack

SIer(死語)とは?

それは、(当たり前ですが、名前のとおり)SI企業は、システムを「つなぐ」
ことが一番大きな使命であり、価値の源泉だということです。


元々は、顧客の要望に沿ったプログラムの開発を請負うという立場から、顧客の要望の複雑化、ハードウェア、ソフトウェアの複雑化等により、システム化の実現、導入、運用までもを請負い、その対価を頂くのが本来のSIerの立場か。そういう意味では、

視点や立場、目的が違うもの(組織も人も、システムもですが)同士をつなぐことはとても難しく、失敗する可能性が高く、これは期間の限られたプロジェクト形式の活動内では大きなリスクとなります。この部分を専門的に担当することで失敗を減らして作業のリスクを軽減し、顧客からはリスクを引き受けることに対する対価をもらう。(軽減済みの)リスクを担保する費用と、顧客から得る"リスクを引き受けることに対する対価"との差分を利益とするのがSI企業ではないかと思います。



というのは自戒を込めてとても納得できる。(顧客のもつ)リスクを代わりに請負うことでその対価をいただく。顧客は対価を払うことでリスクをヘッジする。SI屋は、その技術力によりリスクを抑え、コントロールすることでそのリスクをヘッジする。あれ?うちにそんな技術力、あったかな?

Posted by money at 10:31 PM | Comments (0) | TrackBack

March 9, 2004

仕様のFix

業務仕様とは、どこでFixさせるべきなのでしょうか.
  1. ウォータフォールならば、上流工程でFixさせる。
  2. 最後まで決まらなくて、プロジェクトがデスマに陥るのがこの業界の慣例
  3. 流行のXPやRUP等を用いて変化に対応する。
  4. 無理やりFixさせて客に仕変をせまる。

うーん、理想はやっぱり、(3)なんだろうけど、お客さんを選ぶ必要があります。というのも、最近、むやみやたらとXPやれ、と迫るお客さんが多い。個人的にもいろいろ試してみたいことがあるので、嬉しくなって話を進めようとするとどうも、話がかみ合わない。よくよく話をつっこんでみるとなんてことはない。XPのことなんて少しも分かってなくて、ただ単に、「変化を抱擁せよ」tと言う言葉を勘違いして「XPって、仕様変更の無理が利くんでしょ?」とか、「テストファースト」を勘違いして「いきなりテストからやるんでしょ?メイク工程省けていいね」とかその程度の理解でしかない。そこで、「テストファーストというのは、まずテストプログラムを書いてそのテストがちゃんと動くようにコードを書け、ということです。テストプログラムが通るということは、まずこれさえできればOK,という仕様を決めていただかないと、テストプログラムは書けません。」とか、「最大限、仕様変更には対応しますが、手戻りの工数は全てご請求させていただきますがよろしいでしょうか?」といった話をすると、途端にトーンダウンしてしまう。あと、オンサイト顧客やってくれ、って話もまずは聞いてもらえない。まだまだお客さんに対する啓蒙が必要です。でも、お客さんさえ了承が取れれば、上司は押し切れるんだがなぁ。結局、開発側としては、現時点では自己防衛も含めて、(4)しかなさげ。コツは、お客さんに、「申し訳ない。こちらの検討ミスが見つかったので、お願いだから仕様変更させて!」と思わせること。何事も主導権を取ったもん勝ち、ということで。
でも、自分が開発側であることを一歩離れて考えると、「Fixしないから仕様なのだ」と思う。仕様が全く変わらない開発なぞ面白くありません。仕様とは生き物なのだ。

Posted by money at 3:51 AM | Comments (0) | TrackBack

March 6, 2004

ITプロジェクトの実態

笑えます。でも、笑えない。。。 問題は、どうやってこの「タイヤ」を導くか、なんだが。ひとごとではありません。
Posted by money at 6:24 PM | Comments (0) | TrackBack

プロジェクトと情報共有

ソフトウェア開発に限らず、プロジェクトを円滑に運営していくための鍵としてよく挙げられるのが「情報共有」であり、多くのグループウェアはこの情報共有を如何にコストをかけずに円滑に行うかに焦点をあてたものが多い。僕が大学院で「グループウェア」をテーマにしてた頃は「グループウェア」といえば「ホワイトカラー(つまり事務系)向け」のものが主流(Notesが流行り出したのもこの頃か?)で、僕が趣向してた、ソフトウェア開発チームのためのグループウェアはどうあるべきか?というのは当時はよく分からず、結局挫折したんだが。結局、巷のオープンソースプロジェクトによくある、CVS Webポータル、ML、掲示板等というとこに落ち着きつつあるが、このWebポータルと掲示板の双方を兼ね備えたようなWikiの有効性を最近よく耳にする(目にする?)。かのMartin Fowler氏もUsing an Agile Software Process with Offshore Developmentの中でオンショア(本国側)とオフショア側の両チーム間の情報共有の手段としてWikiの有効性に言及している。ただ我々のような受託開発の場合、Wikiを開発プロジェクトの情報共有ツールとして採用するのに二の足を踏んでしまう理由が1つある。Wikiに蓄積した情報を納品物、あるいはドキュメントとしてまとめる手段だ。もちろん、内部の要員に対してはそのままWebサーバを運用しておけばいいので、それほど問題とはならない。僕が欲しいのは、Wikiに書いてあるものがそのまま例えばSmartDoc形式のファイルに落とすことができて、最終的に体裁の整ったドキュメントに変換が可能にする機能だ。この辺の、プロジェクト内情報共有ツールとドキュメント生成あたりがもう少しシームレスにつなげることはできないか、と思うのである。(でも、マーチン氏は上記の記事の中で「ドキュメントを最新のコードに追従しようとはするな。必要に応じてその都度作れ」とおっしゃってるので、それに反するような気はするけど、でもドキュメント作業を少しでも簡略化しようというマインドは同じような気もする)。何かいい手は無いものだろうか?

Posted by money at 1:23 AM | Comments (0) | TrackBack

March 4, 2004

IOCコンテナ?

最近話題のIOC, Inversion of Control コンテナ。概念的な説明は、こことかこことかを参照してもらうとして、さて、これどういう日本語訳を充てればしっくり来るんだろう?最近、悩み続けてます。
今時点の案では、「制御の裏返し」コンテナなんだけど、これだと概念の中身を知らない人に説明しようとすると何がなんだか訳わからんからボツ。

Posted by money at 11:14 PM | Comments (0) | TrackBack

February 23, 2004

続 ワールドワイドにアジャイる

i以前に触れさせていただいた、マーチンファウラー氏がコラムの中で触れていた、記事の翻訳をお届け致します。といっても、正式には、翻訳許可を頂いていません(何やら、プレンティスホールのフォーマットを提出する必要があるらしい)。勝手が分からないので、無差別公開をやめてご希望の方にお送りする形にしたいと思います。ご希望の方は、こちらまでご請求くださいませ。お手数かけてすいません。

Posted by money at 9:24 PM | Comments (0) | TrackBack

February 17, 2004

エンジニア道

豆蔵の荻本さんのコラム。荻本さんが昔考えていたDROPが巷の理論先行型の開発方法論とは異なり、「で、実際に開発プロジェクトをどう運用するよ?」ってところにちゃんとフォーカスしてたのに気に入って以来個人的には注目している人だ。 さて、このコラムも云々うなずけるところ満載でとてもいい。この中で、荻本氏曰く、「エンジニアの仕事は、ソフトウェアを通して展開される仮想世界に、何らかの構造を作り出し、人が理解できるように見せることである」と。 この構造というのは、ソフトウェアのアーキテクチャであり、UMLでいうところのクラス図のことを想定しているのだろう。 ソフトウェアという見えないものをアーキテクチャ、クラスというフィクションを使って構築し、それを動かすというのは、頭の中で多数のオブジェクトがお互いに協調し、メッセージパッシングを介して動いている。その集合体としてソフトウェアというシステムの動作を説明する、ということだ。先日、同僚と話していたときに「オブジェクト指向設計の優秀なエンジニアというのは、オブジェクト間の協調作業の構築に長けているので、彼が経営学を学び、「人の組織」を作る側に回せば、いい経営者になれるよね」と言ったのを思い出した。拙著のソフトウェアプロジェクト組織論では、ソフトウェア開発プロジェクト、開発チームを動かす、作り上げるのに経営学の考え方って有効なんでは?と言及しているが、ソフトウェアを作ることと。人の組織を作ることは本質は同じかも、というのは自分でも新しい発見だ。でも、世の中の偉い人(ソフトウェア開発プロジェクトを指揮するような、『ソフトウェアを知らない人』)って、ソフトウェアを作ることって、(プログラムは、プログラム言語の文法さえ知っていれば書けると思っているので) こういう発想にはならないだろうなぁ・・・ ただ、ひとつつらいのは、オブジェクト間の協調作業を考える際、オブジェクトは文句を言わないし、実装さえすれば、オブジェクトの能力は無限だが、人の能力は有限だし、文句言うし、金かかるし、いらなくなったからってdelete()できないし、必要に応じて新しいのをnew()できないし、、、なんだ、システム作るのって、簡単じゃん。(笑)
Posted by money at 10:57 PM | Comments (0) | TrackBack

February 14, 2004

分散開発

ちょうどいいときに分散開発ネタが出たので少し本題から外して反応してみる。 さて、先日のFowler氏の論文にもあるように、オフショア開発のような国境、時差を越えて分散しなくても、例えば同じ社内でも拠点の違う部署どうしのコラボレーションや、事業部等組織の壁を越えたプロジェクトや、協力会社との共同開発もそうであるが、つまるところ、コミュニケーション、情報共有が重要である、という結論には反論できない。Fowler氏の論文では、Wikiの可能性や、ThoughtWorks社で利用しているらしい、CruiseControlの有効性に触れられている。 また、モジュール間どうしの結合でうまくリンクできないというリスクを低減させる方法として、「継続的インテグレーション」、つまり、結合を実施する機会を可能な限り増やすこと、リファクタリングにより、常にソースコードの品質を高めることで対処せよ、とのこと。 つまり、情報共有を効率よく高めるために、(共有の開発支援ツールも含めての)コミュニケーションツールが重要だ、ということだ。 これらのツールに求められる機能としては、いろいろあるだろうが、ひとつ挙げるとするならば、情報の一元管理だと思う。分散開発において一番困るのは、情報伝達のタイムラグが発生すること、伝わった情報、伝わらなかった情報にムラができることだ。後者は、古き良き時代のおじさん方の中には、意図的に利用することもあると思うが、ソフトウェアプロジェクトにおいては、これは致命的だろう。そこで、「常にマスター情報にアクセスできるようにするための仕組み」である、Webの利用は誰もが思いつく。分散開発の典型例、オープンソースソフトウェアプロジェクトを支えているのも、ソースコードのバージョン管理、リポジトリを一元化する、CVSとそれへのWebインタフェースがあればこそだ。だが、実際の業務で、これがなかなか敷居が高い。なぜか? 内部のプロジェクト情報を外部のNWに流すのはもってのほか。社内のOA用NWとも切り離して、孤立したNW内での開発を強要するプロジェクトリーダ、協力会社とのそうした風通しのよい状況を作ることに抵抗する中間管理職等の存在だ。 まぁ、CNETのこの記事にも、Fowler氏の論文にも、「一番の問題は、カルチャーだ」と言ってるし、結局、道具じゃなくて、どういうマインドを持つ構成員によってプロジェクトが構成されるか、ってことに行き着いてしまう。 おっと終電だ。続きは、別の機会に。
Posted by money at 1:03 AM | Comments (0) | TrackBack

February 12, 2004

ワールドワイドにアジャイる

先日、翻訳版を公開した、martin Fowler氏アジャイルソフトウェアプロセスを使ってオフショア開発の最後のところで、Fowler氏が言及しているマット氏の論文がこれ。なかなか示唆に富んでいて参考になるのですが、どうやら翻訳許可を得るのが大変。(Prentice Hallのサイトのフォームを書いて提出せよ、とのこと。なにやら、Webサイトに使う場合は、コピーをFAXせよだの結構大変。しかもフォームがハンディキャップ学生向けのフォームだったりなんか”?”)めんどくさいので、どうするか、翻訳が完成してから考えます。 おおっぴらに公開はできないと思われるので、個人的に欲しい方いらっしゃったら、個人的にこちらまで連絡くださいませ。(っているのか?)
Posted by money at 6:06 AM | Comments (0) | TrackBack

February 7, 2004

アジャイルを使ってオフショア開発

以前に、予告してましたが、翻訳もあがり、御大からも許可をいただけましたので、リリースします。当然ながら、誤訳等のご指摘は大歓迎でございます。
アジャイルソフトウェアプロセスを使ってオフショア開発[HTML版]
アジャイルソフトウェアプロセスを使ってオフショア開発[PDF版]

公開してすぐ、お二方から誤訳等のご指摘を頂きました。ご指摘いただいた内容を反映して、すでに2回更新しました。

Posted by money at 8:26 PM | Comments (2) | TrackBack

February 6, 2004

オフショア開発

まぁ、以前にもオフショア開発には触れたことはありますが、検索エンジンからこのアーティクルに飛んでくる人が後を絶ちません。やはり需要はあるんですな。そんな方に朗報。ただいま、かのマーチンファウラー御大がオフショア開発に言及したアーティクルを鋭意翻訳中。もう少しであがりますので、御大からの許可が得られ次第、ここで公開します。オフショアする人も国内で外注使って開発する人も得るものがある示唆に富んだものです。乞うご期待。
Posted by money at 3:22 AM | Comments (0) | TrackBack

ソフトウェアプロジェクト組織論

僕のここ数年のテーマとして、「ソフトウェア開発をミッションとするプロジェクトはどういう体制で望むべきか?」というのがある。まぁ、日頃仕事をしながら「なんか違う」という悶々としたものを抱えつづけているだけなんだろうけど。以前にもソフトウェア開発組織論と銘打ってうだうだと書いたこともある。昨今も、プロジェクトマネジメントブーム、つーか、PMBOKブームというか、要するにPM業をこなせる人材不足が叫ばれつづけていて、以前のソフトウェアクライシスで叫ばれていたプログラマ不足にも似た様相だ。ところでプログラマは今は足りてるんだろうか? 「プログラマ」と称する職業を生業としている方は数多くあれど、、、って感が捨てきれないんだけど。プログラマですら足りないのに、そいつらのトップに立つPMがそう簡単にいるわけないか。
で、話を戻して、巷に数多くある「プロジェクトマネジメント論」。僕の今現在の感想は、「製造業のメタファから離れたプロマネ論は無いの?」である。結局、三角形を書いてプロジェクトマネージャを頂点とするあの、軍隊形式のプロジェクト組織体系だ。組織を動かす、という意味では理想的な組織体制であることは理解できるが、ソフトウェアはやはり組織力じゃない。ソフトウェア工学を専門分野として選んではや○年、やはりソフトウェアは工学になり得ないような機がしている。やはり、どちらかと言うと、小説、マンガ、雑誌、等の出版業界の方が近いのでは?と考えていた。そうして今時点でたどり着いた結論は、「少数精鋭の優秀なエンジニアたちによる自治組織」なんだな。ソフトウェアの品質というものは、例えばどこまでエラーチェックを厳密に検討し、記述するか、という「防衛的プログラミング」という言葉もあったが、結局、書いた本人がどこまで注意深く書くか、でしかない。つまり、作業者個人のモチベーションどこまでを高め、そして維持できるか、に全てがかかっている。いくら回りから「それじゃだめだ」と言ったところで、本人にその気がなけりゃ、暖簾に腕押し。

なんてことを今のプロジェクトでちと思ってしまったのさ。

さて、この「自治組織」モデルについては、おいおい考えていくことにする。

Posted by money at 3:07 AM | Comments (0) | TrackBack

January 24, 2004

「リファクタリング!= 手戻り」をリファクタリング?

ありがたいことに、誤訳や分かりにくい部分を指摘いただきました。謹んで訂正させていただきます。いやぁ、勉強になりました。ありがとうございました。この場を借りて(って自分のサイトじゃんか)お礼申し上げます。

ついでといっちゃなんですが、PDF版も用意しました。これもSmartDocだからこそできること。

PDF版はこちら

Posted by money at 3:00 AM | Comments (0) | TrackBack

January 21, 2004

リファクタリング != 手戻り

以前にとあるところで見つけたドキュメント。リファクタリングは決して手戻りなんかじゃないんだよ、ということをリファクタリング過程の例を挙げながら述べている。でも、リファクタリングと手戻りを区別できないおじさんたちを説得するにはちと難しい。

Posted by money at 4:10 AM | Comments (0) | TrackBack

November 8, 2003

エンジニアの限界

今日、恥ずかしながら、お客さんとの打ち合わせで、自社の(別部署の)エンジニアと(かるーい)喧嘩をした。信じられない提案をしたので、それをつぶそうとしたのだ。サーバとクライアントでデータをやり取りするときの通信に何使う?という話の中で、まぁよくあるのは、WebベースでHTTPにしましょう、とかデータもXML化してSOAPにしましょうとか、あるいは柔軟性を担保するために、CORBAにしましょう、とかって話かと思うが、奴はよりによってソケットで直接やります、と言い切った。確かにプロトコルスタックを自前で実装するとか、カリカリにパフォーマンスを求めるとか、ソケットという選択肢がないこともないとは思うが、今のご時世、クライアントサーバ間のデータのやり取りでソケットでやる奴いないって。曰く、「うちはこれで10年以上やってきてるんです。膨大なソフトウェア資産があるんです。好きにやらせてくれればいいじゃないですか。」と言ったもんだから、「あぁ、こいつには何言ってもダメだ」と思って言葉を続けなかった。これが他部署とはいえ自社の実態かと思うと、情けない。
でも、よくよく考えると、エンジニアというのは、自分の持ってる駒の範疇でしか提案できないし、自分の知らない技術を提案するなどありえないものだ。そこで、自分の持ち駒の範疇でしか考えられないと、いつまでたっても技術に幅は出てこないのでずっと同じ技術で何でも済ませようとする。それが客にとって多大な無駄だとしても本人はそれがベストなソリューションだと思ってる。
では、この殻を破るには何が必要か? 新しい未知の分野、技術に手を出そうとする勇気ではないだろうか?エンジニアたるもの、勇気なきところに死あるのみ。

改めて、がんばらなあかん、と思ったと同時に、「俺のことを知らんエンジニアがまだ社内でのおのおとでかい顔してたか?」とちょっと反省(タカビー過ぎ)。

Posted by money at 12:34 AM | Comments (0) | TrackBack

November 5, 2003

エンジニアの卵の場合は?

10/29 日経夕刊 人間発見より ジャン・クロード氏の言葉 「卵は外から温めてもらわない限り、ひとりでかえることはない。温度が高くても低くてもだめ。今、卵の中で何が起こっているか知るすべはない。それでも温めるしかない。援助はそれと同じ。」

エンジニア教育もこれと似たようなもんなんかな?でも、卵と違って、本人の意思によるところが大きいと思うが。

Posted by money at 2:08 PM | Comments (0) | TrackBack

October 27, 2003

オフショア開発

「タイトなスケジュールのもと、開発基盤となるフレームワークの整備やプログラム部品の活用に関する体制が整わないまま中国の提携ソフト会社に外注した。結果、テスト時にパフォーマンスが極端に低いことが分かり、日本の本社内で最初から作り直すことになってしまった」(広報)


別にオフショア開発が失敗したんじゃなくって、最初から国内で開発やってても失敗したんでは? そもそも人件費ベースでしかソフトウェア開発を考えないからこうなるんであって、本当にコスト削減をしたい場合は、ちゃんとしたスキルのあるエンジニアを集めて少数精鋭ですべきだと思う。どうでもいいエンジニアを数集めれば開発を乗り切れる、という発想自体が間違ってる。
例えば1人月100万円で50人月の仕事を受けたときに、これを1人月60万円のエンジニアを10人で5ヶ月でこなせば利益が、、、なんて発想にするからダメなんだ。それよりも人月200万円のエンジニア3人でなんとか回せないか?とか、人月150万のエンジニア10人で3ヶ月で、とかって発想できれば結果は違ってたと思うのだが、どうなんだろう? もちろん、そもそも人月という考え方がダメなんだ、というご意見をもたれる諸賢もいらっしゃるかとは思いますが、これが日本の開発(特にぼくのところのようなソフトウェア開発請負)の現状ですから。

でも、日本の開発プロジェクトの考え方ってのが、人をできるだけ大勢養った(つまりそれだけの仕事を作った、あるいはそれだけの人を食わせた)方が評価される、ってのも間違いなんだけどね。同じ売上だとすると、1人で高付加価値なアウトプットを出すよりも、普通のアウトプットでいいから少しでも大勢に仕事を与えた方が評価が高い、というのも結局日本の企業(特に大企業、あるいは大企業グループ)というのは、人海戦術ベースなビジネスモデルでしかない、ということか。人海戦術、という発想、嫌いです。要員は全て同じ能力で、誰がやっても同じ、均質的な能力、スキルの人材がいっぱいいるという前提はソフトウェア開発という分野には本当に向いていないと思います。
10人のエンジニアがいて、それぞれの能力が1〜10まで10段階にあるとする(トップのスキルを10とする)。このチームでソフトウェアを作るとどうなるか、見積もり的にはスキル5レベルのエンジニアが10人いるとして見積もりを立てる。しかし出てくるのは、レベル1の品質のソフトウェアでしかない。おそらく、レベル1〜4ぐらいのエンジニアが担当した部分というのは使い物にならなくて、レベル10〜8ぐらいのエンジニアが自分の担当分を終えた跡に、もう一度彼らの代わりに作り直すことになるのでしょう。じゃぁ、なぜ、そのレベル1〜4のエンジニアを首にしないか? できないんだよなぁ。。。
それとよく言われるのが、1.5流のエンジニア100人が束になっても1流のエンジニア1人には及ばない、というのもソフトウェアに特殊な性質でしょう。
こんなに特殊な性質を持ったプロダクトを作るんだから、工業製品のメタファはさっさと捨てようよ。

Posted by money at 2:42 AM | Comments (5) | TrackBack

October 25, 2003

プロジェクト管理

PMBOKのような科学的技術的なプロジェクト管理方式が根付かないわけとして僕が考えているのは、
  • そもそも「プロジェクト管理」というものは技術論ではない、と信じている方が多数いらっしゃる。
  • そういう技術体系の存在を知らない
  • プロジェクト管理は技術論である、という結論を持ち出すと、仕事がなくなる人がいっぱいいる。
  • プロジェクト管理は、長年の経験がものをいう、といういわゆる年功序列制を否定してしまう。
  • プロジェクトが失敗しても、「担当者にスキルがなかった」「客がわがままだった」「納期が短すぎた」等の言い訳が通用し、「プロジェクトの管理の仕方のみがまずかったからプロジェクトは失敗した」という状況にはなかなかならない。
  • そもそも、技術論的もしくは科学論的客観判断に基づき、「これこれにより不可能ですからできません。」という答えは「誠意がない」と取られる。
  • 結局、汗水流し、必死こいてがんばることだけが尊重され、頭を使って効率よくプロジェクトをまわすと、サボってるようにしか理解されない。また、プロジェクトを仮に余裕を持って成功裏に収めると、「ぼったくった」という解釈になってしまう。
なんてあたりではないかと思っています。 あとは、とにかく目の前のトラブルを解決することだけにしか目がいかないので、ロングタームで物事を捉えられるような視野の広い人材が圧倒的に不足しているような気がします。また、ソフトウェア開発プロジェクトによくある例として、プロジェクト開始時点では、受注側も発注側も誰もプロジェクトのGOALを明確にイメージできている人はいません。GOALが明確になっていない、ということは、「そのGOALを達成するためにあらゆるリソース配分を最適化して施策を行う」というプロジェクトマネジメントのメソッドが適用できないことになります。それに対して、アジャイルプロセスというのは、「顧客の要求仕様は変わるものだ。顧客の心変わりを認めよう。」というところからスタートしているので、両者にはどうしても相反するところがあるのではないかと考えます。僕は、諸悪の根源は、
  • ソフトウェアは、変更が容易という前提が間違っている
  • そもそも製造業のメタファでソフトウェア開発を語ることそのものが間違っている
ってあたりなのではないかと考えてはいるのですが、それに対する解を持ち合わせていません。せいぜい、「本、雑誌、マンガという出版物をつくる」というプロセスに学ぶべき点があるような気がしてることと、「プロジェクト体制は少数精鋭でなければならない」ことは確かであるような気がしてるぐらいです。僕の経験則だと、ソフトウェア開発に仮に10人でプロジェクトを組んでたとすると、実際に開発を進めているのは1人〜2人、彼らの開発を助けているのが2人〜3人で、残りは、一生懸命バグを埋め込んでいる、というのが実情ではないかと思ってます。このバグを一生懸命埋め込んでいる人々の首を切ることが本当に可能であれば、何か好転するかも知れませんが、現実的には不可能ですので、彼らにいかに仕事をやった気になっていただきつつ、なおかつプロジェクトには関与させないようにするにはどうしたらいいか? なんてことを考えてたりします。 なんてことを書くと、極悪非道みたいだな。
Posted by money at 3:13 AM | Comments (1) | TrackBack

September 29, 2003

中央線トラブルとプロジェクト管理

中央線が大変だったみたいです。確かに、土曜夜の三鷹駅は駅員総出+警察からの応援でごった返してました。だって、電車が到着するたびに、「振り替えバスをご利用の方はこっちでーす」って叫んでるんだもん。

で、大変なのは実はこのあと、翌朝だったようで、予定通りに作業が終わらず、昼過ぎまで止まってたそうな。まぁ、思いがけない故障が発生した、とかいろいろ理由はあるだろうし、JR側の謝罪の際にも「見通しが甘かったと言われれば言い返す言葉もない」と認めているようではありますが、ここに昨今のプロジェクトマネジメントの甘さが露呈しているのではないだろうか。

さて、「見通しが甘かったと言われれば返す言葉もない」と言っているが、ではこの見通しって何だ?

まず考えられるのは、作業量の見積もり精度が甘く、予想外に時間がかかった、というもの。次は、思いがけないトラブルは発生したことに予想外に時間がかかった、というもの。そして、そもそもプロジェクトとして技術的な理解が浅く、起こるべくして起こったもの。
今回の中央線のトラブルについては、2つめのようではあるが、配線ミスという情報もあるように、最後の可能性も捨てきれない。
で、これと同じようなことは、ソフトウェアの世界では日常茶飯事なのであるが、技術的理解が追いついていないことが原因で起こっているものが圧倒的に多いと感じるのは小生だけだろうか?
そもそもソフトウェアが分かってるマネージャがまれであり、その分かってないマネージャが分かったような気になって、全体を指揮し、分かってないのに分かったような気になってる技術者が現場で作業している、というのが実情ではないだろうか?
もちろん、そんなことはない、とおっしゃる恵まれた環境で開発をされている方も多数いらっしゃるかと思いますが、少なくとも、人月の神話がはびこる世界でまだ悪戦苦闘する私としては、そう考えずにはいられないのである。この理解の浅はかさが、システムを不安定なものにし、トラブルを絶え間なく招き、また根本的な解決をせず、表面的に解決した気になっててさらに次のトラブルを招く、という悪循環。産業の空洞化という言葉があるが、知的ノウハウも空洞化してるのではないだろうか?システムが複雑になりすぎている、危険だ、と警鐘が鳴らされることもよくある話ではあるが、一番危険なのは、システムが複雑すぎることではなく、システムを理解せずに作っている、今必要とされている技術の本質を理解できるだけの優れたエンジニアが絶対的に不足している、いや、育てていないということである。

Posted by money at 5:50 PM | Comments (0) | TrackBack

June 3, 2003

設計とは(とあるところから再掲)

「つくりながら考える 使いながら作る」という本の冒頭にこのような記述を見つけた。

『(中略)会話がうまく成り立たなかったら、それは建築の設計組織にとっては致命傷である。言語は決定的に重要なのである。たった1つのことを伝えられなかったために、取り返しのつかないミスを犯すということがあり得る。もしそのようなことが起きたら、そのために計り知れないダメージを多数の人たちに与えることになるわけである。(中略)建築の設計をするということはコミュニケーションそのものなのである。』

なんだ、建築もソフトウェアも一緒じゃん。

でも、建築とソフトウェアが一番違う点は、「建築は所詮、既存のものの再生産とリファクタリングしかやってない」ということ、と言い切っちゃうと建築の人から怒られちゃうかな?

Posted by money at 11:30 PM | Comments (0)