おのたく日記 YouTubeも始めました→

■ シリコンバレーのプログラマーは本当に凄いのか？続き

5月7日の日記「シリコンバレーのプログラマーは本当に凄いのか？」に沢山のreferと、トラックバックが有った。やっぱり、このあたりには日々感じる事が多い人が沢山いるんだと思った。

この一連を読み始めることになった日記である吉岡さんの日記でも5月1日のシリコンバレーのプログラマーは本当に凄いのか？で「refere を頂いて休日にはそれを眺めるのを楽しみにしている」って事で、いろいろ感想を書いてくれている。しかも、この中では、わんこの5月4日の日記にもリンクを頂いた。

吉岡さんも「Cagylogic blog: 単純に真似すると痛い目を見る」については、「なかなかいい感じである」とのことで、「みんな感じるところは同じなんだなぁ」と思った。

■ Cagylogic blogの続きを読めてなくて残念

ちょっと残念なのは、Cagylogic blog:必要な製品のクオリティからもトラックバックを頂いたけど、ゴールデンウィークでサーバが止まっているのか読めてない事。

■ 単価を高くするためにSEにする

スキルではなくて、年数や経歴で単価を決めてしまう業界の仕組みが、すばらしいプログラマが育たないことについて、

ネットワークやOSやデータベース周りのスキルがない技術者が高い単金を取得するためにSEとして売り込まれている現場

[サイボーグ戦士の日記:Re:シリコンバレーのプログラマは本当に凄いのか？より引用]

と現場の例をあげて「サイボーグ戦士の日記」さんから熱い同意のトラックバックを頂いた。

■ ソフトウェア製品の輸出

吉岡さんの5月2日の日記を読んで、自分がなんで、今の会社で仕事を続けているかの理由がわかった気がする。古臭いソフトウェア製品製造手法がメインだし、収入も安いのにいる理由は、

1. お客の要望によるアプリケーションプログラムではなくて、 ソフトウェア製品。

2. 北米はもとより世界中に輸出される。

この二点を持っていながら、日本で開発を行っているからだ。

望んでここに来たというわけでない。この仕事へは、たまたま流れ着いただけだし、本当は「シリコンバレーに行きたい」と思っていたる。それに、去年の前半までは、輸出はするけどオフショア開発のための製品の担当だったので、本格的に製品として輸出するソフトウェア開発にかかわることが出来たのは、去年の9月からのこと。これも、必然性があったわけではなく、たまたま輸出できる製品の担当になるチャンスがあったからなんだけれど…

20代のころは、金になる新しい仕事があれば、次々と仕事を変えていたのに30代になって変わらなくなったのは、「おれも年を取ったのか」と思っていたけど、もし次の仕事を探そうして、こんなソフトウェア開発の仕事はなさそうだから、もう少しつづけてもよいと思えるんだな。

日本では、吉岡さんも指摘するように、「輸出されているソフトウェア」一歩譲って「ソフトウェア製品」を開発できる場所って限られているからな。

■ 「日本の凄いプログラマを生かす場所を作る」という意気込み

話は変わるけど、この日の吉岡さんの日記に出てくる

日本にも凄いプログラマはいる。間違いなくいる。しかし今まではそのスキルや専門性を生かす場所がほとんどなかったのである。

であるならば、小さくとも当事者として自分がその場を作る。そーゆー意気込みである。

[はてなダイアリー - 未来のいつか/hyoshiokの日記より引用]

という、吉岡さんの意気込みには感服した。

一応、輸出できるソフトウェア製品の担当だけど、自分は、今の仕事もプログラマとしてはプロモートされない。でも、大学で国に1,000万円以上の税金を使わせて「100名以上のトップになる」教育を受けていたのだから、自分ではプログラマーでなく、プロジェクトマネージャーとしての道を進むのも合っていると思っている。

もしプログラマで生きていくような人生だったら吉岡さんのようなパイオニアが道を開いてくれる事は、絶対に必要だと思うだろう。

プログラムって楽しいし、サービスではなく「物を作り出す製造業」しかも「頭を使って、物を作り出す」ということは、資源が無い日本では大切だから、これは日本にとっても必要な道だと思う。

■ バグ分析

吉岡さんの5月2日の日記:Tバックで、バク分析についての解説が有った。

バグデータベースに記録されているオープンなバグ数、クローズしたバグ数などをマクロに見ていくことによってプロジェクトの進捗を知ることができる。またバグを一つ一つ検討することによって、どのようにしてバグを発見したか、どのようにバグを修正したかを知ることができる。バグを分析をするのは最終的にはどのようにしてバグを作ったかを知ることであるが、そのレベルまで深くバグを分析している例は少ない。

[はてなダイアリー - 未来のいつか/hyoshiokの日記より引用]

いままでは、ソース管理についての話が出てきていたけど、今度はバクデータベース。

ソース管理はCVS, Subversion, ClearCaseだけど、バクデータベースは、どんなものがよいのか、いまの仕事でも、使っているのは素晴らしいけど、特別製のアプリケーションで、一般的なものでないので、世界的にはどんなものが良いのか気になった。

やっぱりJavaのBugパレードや、SourceForgeのBrowse Bugsみたいなものが、今のトレンドなのかなぁ。これらで気になるのは、バグとソースコードの連携が出ない事「このバグは、ソースのココとココで直したぜ」と出ないとプログラマとしては困るし…

バグ分析については、旧来のソフトウェア開発手法であっても、最終的にテストを行いバグをみつけているのだから、旧来からの手法で分析ができるはず。先達に教わる事も多いだろうから、自分自身も、まだまだ勉強が必要な範囲だと思った。

吉岡さんの日記では、最後に「続く」となっているので期待。

■ テストエンジニアの育て方

また、この吉岡さん日記からリンクされているblogで

更に別なテスト方法を考えられるようなテストエンジニア養成に必要な事。

今、自分はバグの調査目的のプログラムを作成する事もあるんです。それって結局テストパターンの作成なんで、こういうところから仕事以外で何かやれないかなって思っています。

[はてなダイアリー - tmpfile::dialyより引用]

というのが有った。

ソフトウェア製品のサポートをやっていると、障害調査のなかで、再現という作業があるけど、ここで、うまくリグレッションテストのテストパターンを見つけたり、ここでテストエンジニアを育てていけないものだろうか。

■ プロかノンプロか

tmpfile::diary「"プロかノンプロか" ですか．」からのリンクの「この道はいつか来た道... REBOOTED: プロかノンプロか」

で「プロなんだろしっかりやれよ」という、熱い話が載っているのを知った。

「あーレビューの目的は、技術の試合じゃなくてゴールは、お客さんの満足するものを作ること、プロジェクトの成功なのになぁ。折角すばらしい腕を持っているのに」と思った。