おのたく日記 YouTubeも始めました→
2004-05-19(Wed) 続・100万行のソフトの作り方 [長年日記]
■ [Blog] CNET Japan Blog - 梅田望夫・英語で読むITトレンド:続・100万行のソフトの作り方
石黒さんのゲストブログが好評だったので、石黒さんからのお返事が載っている。わんこ日記にもお返事を頂きリンクされてる♪
まずは、
「これってもうメディアかも」
[CNET Japan Blog - 梅田望夫・英語で読むITトレンド:続・100万行のソフトの作り方より引用]
そー、このようなプログラマとしてディープな多くの人の意見を聞けるのは、いままでなら滅多に無い事で、非常に勉強になっている。
梅田さんは、ビジネス的にも有意義な話を沢山後悔してくれているけど、わんこが反応できるのはテクニカル・ディープなものしかないけれどね。
■ 情報システム部門をITと呼ぶ海外
話は横道にそれるけれど、情報システム部門って、海外だとITって呼ばれていますよね。今日も、高校の先輩に飲みの席で「うちのITに来ないか」と誘われた。先輩の会社は、いつのまにか外資系になった会社なので、やはり、情報システム部門をITと読んでいたので、
実際にやった仕事はUNIXのシステム管理でした。シリコンバレーでは、会社によって呼び方が違うと思いますが、うちではITと呼ばれる人間がそうした仕事をやっていますね
[続・100万行のソフトの作り方より引用]
に、「ほー」と思ってしまった。
■ テストチームとQA
テストチームをQA(Quality Assurance)と呼んでいます。
-SNAP-
もしかすると、SEという職種の呪いがここにもあって、テストエンジニアという存在とQAという工程を隠してしまっているのかもしれませんね
[続・100万行のソフトの作り方より引用]
QA大国日本のQAって、SEの他に、ちゃんといるような気がします。
石黒さんのあげているような、ソースを書く開発チームの近くにいるテストチームではなくて、もう少しユーザに近くて、テスト&フィールドサポート部隊だと思っていました。SEの中にもテストチームはいるけど、そこはホワイトボックステストで、さらに後ろの工程にブラックボックステストのQAがいるのが、日本のQAだと思っていました。
二十代の頃には、請負のプログラム開発を受けて南武線沿線の各社に行きましたが、どこでも、こちらでのテスト完了後、検収としてブラックボックステストを行うQAの検査を受けた覚えがあるので、それが普通だと思っていたのですが、ちがうのかなぁ
■ 日本には天才プログラマ不要論
上のCNET Japan Blog - 梅田望夫・英語で読むITトレンド:続・100万行のソフトの作り方のトラックバックで、「ビジネス オン デマンド」を見つけた。「ビジネス〜」というだけあって、ちょっとスーツの香りがしたけど、なかなか、日本にも、すばらしい環境があるらしいので、書き留めちゃう。
まずは、これ
設計がよければコーディングで天才的なプログラミングは必要ないし
[ビジネス オン デマンドより引用]
すばらしい。確かに、完璧な基本・概要設計になっている開発であり。詳細設計は基本設計の解像度をあげると、手にとるように分かり。その詳細設計に基づいて、そのままコーディングできるようだったら、天才的なプログラミングなんていらないですからね。
しかし、いまやっているような「オープン系」と言われるような開発をしていると、利用するOSを含めて周りが怪しい「オープンな」ものなので、トライ・アンド・エラーや、実験が必要であり。さらには、良い設計が出来るには、プロトタイプの作成など、十分な期間が必要なのにかかわらず、開発コスト削減圧力が高くて、十分な開発期間もなく「設計が良い」なんて、ここ十年とか有った事が無いです。(煙の臭いが好きなわけではないけど、いつも火事場の仕事ばかりだし)
と言っても、最近は、この話の中でも例外とされているソフトウェア製品の開発しかやったことなく、個別業務システム開発について、自分が知っているのは5年以上も前にC++とか使っていた時代を思い出しながら書いているので、いまはマルチプラットフォームなJavaで、さらには素晴らしいCASEツール等があるから、現在の個別業務システム開発は、「普通は設計が良い」なのかもしれないですけれど…
さらに、うらやましかったのは、
いざとなれば人的リソースの大量投入による製作が当たり前
[ビジネス オン デマンドより引用]
という、コスト度外視のリソース投入。夢だぁ〜
でも、
質は良いが言葉が通じにくい海外と、質は最悪だが教えれば何とかなる国内ではどちらが良いのか?というところに行き着いてしまうのも事故が多発する原因ではないかと筆者は思うのです。
[ビジネス オン デマンドより引用]
ってことで、「設計は良い」プロジェクトだけど、
・海外に出すと言葉が通じなくてダメ。
・国内だと、プログラマの質が悪くてダメ。
あり、良い設計というのは、概要の設計のことで、もしかして、詳細設計・実装設計など、コーディングにより近いレベルの設計が入っていなかったのかな? コード一歩手前まで設計してあれば、言葉の問題も、コーダの質も関係ないと思うのだけれど。
あ、もしかしてコーディングに近いレベルの設計は、プログラマがやるもの? でも、だとしたら、概要設計から、詳細設計に落とせる天才的なプログラマが必要になってしまうから、「日本には天才プログラマ不要論」にならないし、文章読解力が甘い、わんこは、どこかで話を、ねじ曲げてしまったか。
|
トラックバックありがとうございます。<br>最後のところを補足させていただきますと、<br>私の言っている天才的プログラミングというのは職人芸的芸術性のあるコーディニスト(笑)をさしており、<br>概要設計から詳細設計に落とせる”優秀なSE”は必要です。これがいないと事故が起こります。こういったプロジェクト単位で動く場合はPMが重要になってくるってことです。<br>一人の化け物は要らないけど、10人の優秀な兵士はいるって事です。特に天才くんは我侭になりやすいし、コントロールが難しくなりますから、顧客要件に合わせたシステム開発にはむしろ害しか発生しなくなります。<br>ということで、再度見ていただくと天才プログラマは自分たちの理屈だけで作れるAPP開発なら必要だけど、顧客システム開発には必要が無いということにはなりませんか?<br>ということで、また何かありましたらトラックバックよろしくお願いします。