文化の違い

うちの会社は、仕事を中国にアウトソージングしていまして、その関係上 中国の人とメールでやりとりすることがしばしばあります。しかし、これがまぁ、めんどくさくてたまりません。

一応、こちらが発注側なので、中国側が日本にあわせて日本語を使ってくるものの、向こうは基本日本語をしゃべれませんし、こちらも中国語なんてしゃべません。基本的には翻訳サイトで翻訳しているようなレベルの文章がメールで飛び交うので、お互いに微妙なニュアンスが全然伝わりません。このせいでメールを読むのにほんまに時間がかかります。

あと、日本だといたって普通のやりとりが、向こうにとってはプライドを傷つけることになったりと、とにかく ややこしいです。

先日も中国の人(とりあえずAさんと呼びます)の作成部分の不具合を見つけたんで、それをメールで指摘して、わざわざ修正の仕方まで連絡してあげたんですが…
どうやらそれがAさんのプライドを傷つけちゃったみたいでして、指摘内容に対して、ガブガブ噛み付かれてしまいました。
基本的にはこちらの指摘内容はゆるぎようがなく、Aさんの反論はタダの屁理屈なので、屁理屈のたんびに論破したものの、論破のたびに 別の屁理屈をこねてきますんで、それに対して 毎回毎回正論で論破するのも時間の無駄というか疲れてしまいました。
本当に時間がもったいない！！

Aさんに関しては、先日彼が出した提案を私が却下したという経緯もあり、ひょっとしたら目の仇にされているのかもしれません。(これは私の被害妄想かもしれませんが…)

そんなこんなで苦労しているわけですが、個人的には中国へのアウトソージングそのものを止めて欲しくてたまりません。とは言うものの、このアウトソージングは トップダウンによる指令なんで、個人で騒いだところでどうしようもないんですが。
実際 日本の他社に発注だすより単価が安いのはわかるんですが、あがってくるソフトの品質が低いため、毎回日本で作りなおさにゃいけませんし、言うことなかなか聞かないしと、現場はほんとに迷惑こうむっています。

と言うようなことをホントは上層部に訴えたいんですが、本当に訴えたらこのご時世クビを切られかねません。ですんで、こんなところに愚痴を書いているわけですが、そんな自分に自己嫌悪です…

現実を見ない上司は疲れる...

目先のマイルストーンを後一ヶ月に控えて、いよいよプロジェクトがどうしても間に合わないことが見えてきました。
ちなみに マイルストーンってのは、ソフトウェア開発の中で工程遅延の許されないような大きな節目のことを言います。

ヤバいなぁと前々から思っていたものの、具体的に危機的状況であるという工程の試算がだせず、しばらくの間は悶々としていました。それが、ようやく具体的な数字がだせましたんで、それを上司に突きつけて「こんな納期で できるかー！！」みたいな感じで 納期を延ばしてクレーって交渉をしたんですが...

やれ「試験のムダを減らせ」だの「担当者の入れ替えをしろ」だの「効率化しろ！」だの「割り込み作業を減らせ！」だのと 全然話になりません。そもそも「割り込み作業を減らせ」って言ってるけど、割り込みを入れてるのはアンタやろ！？...と。
考えられる案をやりつくして、もうどうしようもないから納期延ばしてくれって言ってるわけで、その場で思いついたようなてきとーな案でどうにかなるわけがありません。

また、「何日足りないから、マイルストーンを何日にしてくれ！」って言っているのにもかかわらず、「キチンと不足分の見積もりをだせ！」とかいう訳のわからんことを言ってくるし。

基本的に納期を延ばす交渉をする場合、「何日足りないのか？」っていう数字は必須です。そのためにわざわざ バグ曲線まで書いて 何日まで納期が必要だ！って言ったにもかかわらず、「何日足りないのかわからん」と言われてしまうと、頭がわるいとしか思えません。

いや、今日は疲れました。

MSはもうちょっと開発者のことを考えてくれ...

VISTAが売れていなくて、MSがあせりだしたってニュースがちらほら出始めています.
売れてないという真の理由はわかりませんが、思うに問題点はこんなところでしょうか。
・XPからVISTAに敢えて乗り換える理由がない。(XPで十分)
・使っているアプリケーションに互換性の問題がある
・重い

個人的には VISTAは興味はあるものの、アプリケーションの互換問題が怖いです。
ですから、当分はVISTAは要りません。

...とは言うものの 仕事のほうでは VISTAイラネというわけにはいきません。
うちは主は組み込みソフトですが、Windowsアプリも作ってますんで、こいつのVISTA対応がいります。

しかしながら、わかる人にはわかってもらえると思いますが、VISTAのXP非互換部分への対応は辛いです。
MSが勝手に変えたOSの仕様を調べて、地道にあわせこむ作業をやらねばならないからです。
創造的な部分ってのは基本的にはないだけに精神的に苦痛です。
ぶっちゃけ、この手の得るものが無い作業はしたくないんですが、放置しすぎると製品そのものが市場から淘汰されかねません。

一応、昔に比べたら状況はましになっていて、ある程度 互換性を保つための情報は出てきています.
しかし、わかったことは細かい問題がたくさんあるってことなんで、結局 何をどんだけ直せばOKってのが わかりません。

どれだけ直せばOKになるという工数が見積もれていないっていう点では 最初の状態から進展なしです。
もう、どんだけ～ って感じです。
仕方が無いので製品の全機能の評価をやって、問題がでたところを片っ端からつぶそうか？ってな話になってます。もう力技全開です。

...嫌過ぎます。

やれ、Program Files配下が書込み禁止だの、レジスタ書き込みの仕様が変わっているだの、特定デバイスドライバがインストールできなくなってるだの、一部APIの仕様が変わっているだの...

もう 勘弁してください（ToT)

口先だけの重要プロジェクト

過去に経験した話です。

A君は ソフトウェア開発畑で 10年以上の経験を持つSEでした。
管理能力は今一つなのでリーダやサブリーダとしての適正は低かったものの、プログラマとしては熟練していました。

そんな A君ですが、事情があって 間接部門に左遷されてしまい、さらにその後 退職してしまいました。

この退職のきっかけとなる左遷の遠因には 私も絡んでおり これら一連の事柄は他人事には思えない出来事でした.

...

そもそもA君が間接部門へ飛ばされた原因は、ブリッジSEとして海外に数年赴任したものの結果が出せなかったためです。

当時、うちの会社は 海外に新たに子会社を作って、製品の製造だけじゃなく ソフト設計までもも人件費が安い海外にやらせたいという方針を立てていました。

「うちの会社の将来を背負う重要プロジェクトだー！」なんて、言われていたものです。

しかし、重要プロジェクトという割りには、その海外立ち上げプロジェクトに本格的に携わった人間は 数人に過ぎません。

その頃の開発メンバの主力は社内のプロジェクトできりきり舞いしているような状態で、とても海外向けにブリッジSEを派遣するような余力はありませんでした。

結果、開発部隊の中心にはいないような人や、そのときたまたま手が空いていた人ばかりが そのプロジェクトに携わりました。
A君はそんな中で 中心人物として白羽の矢がたった人です。(私も候補者になりましたが ドロ船には乗りたくなかったので逃げました...)

さらにたちの悪いことにその外国部隊というのが、素人に毛が生えた程度の集団でした。
そんな連中に 一人や二人のエンジニアを派遣しただけで まともな開発者まで立ち上げろというプロジェクト自体がそもそも破綻して当然です。もちろん、結果は無残でした。

最終的に この海外子会社は役に立たないというレッテルを貼られてしまいました。
実際開発を任せられるだけの技術力もなく 単なる お荷物部隊と化してしまいました。

そして この失敗の責任をとらされたのがA君です。
A君はこのプロジェクト中心メンバの一人でしたが、プロジェクトの失敗は彼一人の責任ではありません。
でも、彼は開発部隊をクビになり、間接部門に飛ばされてしまいました。
その後 しばらくしてから A君は 退職してしまいました。
...

結局 この海外立ち上げプロジェクトは 役に立たない海外子会社を持つことになり、莫大な投資がほとんど無駄になり、A君という熟練工を失い、惨憺たる結果になりました。
本当に重要プロジェクトならば、当時進行中の国内プロジェクトを止めてでも そちらを重要視すべき だったのではと思います。実際に投入した人員を考慮すると 重要プロジェクトというの口先だけだったのではないかと思えてなりません。
A君もプロジェクトの中心人物ではなく、一プログラマとしてならば実力を発揮できたでしょうに 残念になりません。

一歩間違えば 私がブリッジSEとなり 責任を取らされた可能性もあるだけに、色々と考えさせられる出来事でした.

足かせが多すぎる

新プロジェクトが 本格的に動き始めました。

新プロジェクトが動き始めると やるべき仕事が俄然増えます。
自分自身の検討項目も忘れちゃいけませんが、チーム員の進捗も管理したうえで遅れたところはフォローしてあげないといけません。これが一人ならまだ楽なんですが数人いると人数に比例して手間が増えます。
他にも、他チームとスケジュールやら仕様やら色々調整もしなけりゃなりませんし、過去にリリースしたプログラムのバグが見つかれば それも調査したうえで直さないといけません。
本当に盛りだくさんです。

しかしながら、バグ対応と、チーム員の進捗管理をするだけで 定時は過ぎています。

こんな状況ですので自分自身の開発項目の検討は残業時間でせざるを得ないのですが、これまた一日１～2時間ぐらいしかまとまった時間がとれていません。それも 問い合わせやら質問が頻発するせいで 思考が寸断されてしまい、嫌になるほど自分の仕事が進みません。

足かせが多すぎです。

正味のところ、足かせが圧倒的に多いのは事前に見えていましたんで、思い切って 私自身の検討項目は外さしてクレー！と上司にお願いしていたんですが、こいつが却下。

涙目になりながら仕様検討をやっています。(ToT)

私だけではなく皆がこんな状況ですので、チーム員の進捗も私の進捗も芳しくなく、毎週ずんずん遅れていっています。これを上司に報告すると「遅れるのがあたりまえみたいな顔すんな！」と怒られたちゃったんですが、「いや、あんたが詰め込みすぎなんが悪いんやろ！」とも言う訳にもいかず。(言ったところで機嫌が悪くなるだけで無意味...)、もんもんとした日々を過ごしています。

......(-_-#)

あ～、やだやだ （　`Д´）
進捗管理、ツマンネー　(ﾟДﾟ)！！
純粋に仕様と格闘していた頃の１プログラマに戻りたいデース！！

インターンへの給与

インターンシップについて、給料を払う/払わないって話が出ていますが...
http://q.hatena.ne.jp/1188871542

インターンシップはあくまでも「学生が一定期間企業等の中で研修生として働き、自分の将来に関連のある就業体験を行える制度」であって、その主目的は、採用におけるミスマッチの軽減と、それに伴う離職率を減らすことのはずです。

そのように考えると給与を払う理由はないと思います。
仕事をして成果を挙げてもらうことではなく、あくまでも「体験」してもらうことが目的ですし、ようするに「体験学習」してもらってるようなものです。「体験学習」に来ている相手になんで給与なんぞ払うのか！？って話です。

また、給与を払ってしまうとインターンの給与に釣られる学生がそれなりに混じるでしょうし、この場合 スキルミスマッチが発生する可能性があがると思います。

というわけで、個人的には給与は払うべきではないと考えます。

ちなみに、インターンへの給与についてのコメントで「時給より成果報酬のほうがいい」ってのがありましたが、うちの場合 成果報酬にしてしまうと、インターンへの報酬は０になります。(インターンシップに来ている期間程度では、何も成果はだせませんので、こうなってしまいます。)

参考までにうちのインターンの事例を少し紹介します。
うちの場合、期間が2週間なんですが、こんな短い期間では本格的に仕事をやってもらうことができません。仕事に必要な知識を教えている間に終わってしまいます。

そうなると、立ち上げ期間がほぼ不要となる、細かい雑用をやってもらうしかないわけです。
しかし、2週間しか在籍しない素人にさせられるような仕事は雑用であってもあまりありません。

このため、インターンがくると、インターンでもどうにかできるような作業を割り振るのに苦労させられます。
というか、やってもらうことがないんで、無理やりに インターン用の作業を作っています。(-_-;)

ちなみに、うちの職場にもインターンの学生が来ていますが「給与」を払うどころか むしろ我々に手間賃を払って欲しいぐらいです。

えーと、インターンへの愚痴ばっかりになってしまいましたが...

一応インターンの意義そのものや、会社にとってのメリット、学生にとってのメリットは理解しているつもりです。

ただ、実際の現場の人間として インターンへの意見を言わせてもらうと、自分のところへ配属するのは勘弁してくれってのが本音です。
インターンは戦力として まったく役に立ちませんし、余計な作業が発生する分 思いっきり足手まといです。

正直、インターンは ちょっと愛社精神にあふれた人のところに配属したほうがよいです。
私のところに配属された学生は可哀想です...

...といいますか、うちの会社にくることは多分ないでしょうねぇ...

社会に出た後で私が学んだ12のこと

Debugさんに触発されて書いてみました。
組み込み系SE/PGを経験して私が学んだことになります。

1.宵越しの金は持たないこと。余分な金を持っていると身内の借金や泥棒等、物騒な出来事があったときに失う金もでかい。

2.できるヤツから潰される。己を守るためにわざと上司からあきれられるような仕事をすることも時には必要。

3.努力が報われるなんてのは幻想。いい意味でも悪い意味でも報われるのは要領の良い奴。

4.必要以上に丁寧に仕事をしないほうがいい。適度に手を抜くことが大事。

5.上司や周囲の人間に必要以上に信頼されてしまうと仕事が増える。適度に無能を装ったほうがいい。

6.SE/PGになるのに理系である必要はない。文系出身者もたくさんいる。

7.違う会社の人と給与の話はしない方がいい。条件が激しく違うような場合に双方気まずくなる。

8.この業界は意外と狭い。どこでつながりがあるかわからないので転職する場合は気をつけたほうがいい。

9.彼女を作るのは本当に大変。つか、この業界で女探すのはあきらめたほうがいい。

10.やりたい仕事と自分に向いている仕事が合っているとは限らない。仕事が楽しいと思えたらそれはものすごく幸運なこと。

11.上司からの意見/命令にはとりあえず従うこと。ただし、上司の意見を真に受ける必要はない。上司はその場の思い付きでテキトーなことを言う。

12.年をとってもPGのままでいるのは難しい。何故なら「年上の部下」は扱いにくいからで、SEが年上の部下(PG)を雇うことを敬遠するようになるため。

なんか、ネガティブなネタばっかりになってしまいました…orz

優秀なプログラマの8つの条件?

うーん…こちらの記事で
ネットビジネスをされている経営者に優秀なプログラマを尋ねられていますが、
そもそも質問する相手を間違っている気がします。

プログラマをよくわかっていない人に、優秀なプログラマ像をたずねても、とんちんかんな答えが返ってくるのは当然かなぁと。

１）企画力のある人材
開発部門が企画部門を兼務しているというならば、まぁわかります。
でも、ある程度の規模を持った会社の場合、これは企画部門の仕事ですね。

２）デスクトップとマイドキュメントが綺麗な人材
うーむ…
整理整頓ができる人間は優秀で、整理整頓が上手ならデスクトップとマイドキュメントは綺麗なはず。だから、デスクトップとマイドキュメントが綺麗な人材は優秀と言いたいのでしょうが…
全然話がつながっていません。

３）網2.0って何だろうと聞いて、返事が返ってくるプログラマ
意味不明です。

４）期日はいつですかと聞いてくるプログラマ
これは納得。唯一の素直にうなずける項目です。

５）新しいものにとらわれないプログラマ
YESともNOともいえませんね。
変に新しいものに捕らわれて、肝心な開発能力がないようなプログラマは確かに困り者です。でも、新しいものへの興味が無いプログラマも困りものです。

６）仕様の話をしているときに黙って聞くプログラマ
これは駄目でしょ。
仕様に関する話をするときに一番怖いのは仕様の認識がずれることです。
これをよくわかっている人は、その変を補完してくる質問をしてくれるんですが、黙られると わかっているのかわかってないのか判断できません。

７）過去になにかを作って公開しているプログラマ
これはわかりますが、公開できるようなものを作れるひとはほとんどいないでしょう。

８）企画時に、収益の算段が出来るプログラマ
開発するソフトウェアの規模が小さい場合ならばわからないでもないですが、普通は１）と同じで企画部門の仕事でしょう。

…というますか冷静に振り返ると、これって"必要なプログラマ像"じゃないですね。
「優秀なプログラマ」と書かれていたんで過剰反応してしまいましたが、単に"ネットビジネスをされている経営者"が欲しい人材の条件を言っているだけですね。

…ということに気づいたら、釣られてしまった感がでてきて、なんかどっとつかれました…

組み込み系技術者の年収

経済産業省の情報処理推進機構のホームページに、
昨年度の組み込み系技術者の年収についての詳細資料がでています。

詳細はこちら(PDFファイルが開きます)
(出典元「独立行政法人　情報処理推進機構　ソフトウェア・エンジニアリング・センタ－」)

私の場合年齢が30代で年収が6Mちょいですから、上から40%ぐらいの位置にいるってことなります。

転職前の全盛期は年収が7M超えていただけに、今の年収にはちと寂しいものがあります。給料目当てで前の会社に戻りたいなんて気持ちはさらさらないものの、寂しいものは寂しいです。

それにしても、このグラフを見ていると、なんだか将来の年収が見えてしまって お先真っ暗です。
今と同じように上から40%ぐらいのままで年収が推移すると仮定すると、50歳以上になってもせいぜい年収は7M～8Mぐらいにしかならないってことになります。

やっぱ、お金持ちになりたければ 組み込みエンジニアでは 厳しいと再認識した次第です。別の収入源を見つけない限りはお金持ちへの道はありえません。

一千万プレーヤーを目指したいんですが、道のりは遠く厳しい…！！！

ITSSとETSSに基づく無料スキル診断 - IT・組込み技術者スキル調査2007（第6回） - ITスキル研究フォーラム

去年に引き続き、今年もITSSの季節が来ました。

結果はこんなんでした。
スキルレベル＝LV3.1

えーと、去年がLV3.6だったんで、下がってます。 …orz

とりあえず、この二つの低さが際立っています。
パートナーシップ
(人との対話を通じて相手を理解し、要望に応えながら人脈を形成する)
チームデベロップメント
(メンバーを支援・指導し、前向きに動機づけ、チーム/組織力を向上する)

まぁ、こうやって内容を見たら数値が下がったのも納得です。

最近は 本当にうんざりしながら仕事してるんで、
それが数値でも はっきり出てきたって感じですね。

いつになったら不具合地獄から抜け出せるのやら…

こりゃひどい…

最後まであきらめないココロ

うーん… @IT自分戦略研究所の記事なんですが 内容が酷いです。
この記事の筆者の野村隆って人、デスマーチを生み出す典型的な駄目リーダにしか見えません。

下からの「無理」というアラームに対して、「駄目な理由なんぞどうでもいい。とにかくどうにかしろ。」と言っているようにしか見えません。無茶苦茶です。

”会話がかみ合わずに、最後は相手が怒ってしまいました”って、そりゃ 相手も怒るでしょ。

”「こうすればできる」という前向きな発想”を持つこと自体は正論ですし、否定する気はありません。でも、現場では どうやっても解決できない問題があります。普通の現場ならばできる限りの対策は当然実施します。そのうえで、もう万策尽きてしまったときの最後の手段として、上に対して「無理」というアラームを上げるわけです。

このようなアラームに対して、筆者は”思考停止”だとか、”リーダとして許容できない”だとか、報告者が悪いような論調ですが そもそも考え方を間違っています。

下から「ギブアップ」宣言が来た場合、それをどうやって助けるかというのがリーダまたは上司の仕事のはずだと思いますが…
この筆者は下の報告者に対して苦言を呈していますが、むしろ 筆者 の方こそ猛省すべきだと思います。

どうして仕事を断らないのか

悪態のプログラマさんのエントリへのTBです。

仕事を頼まれたら断れない人がいる。傍から見ていて出来そうもないと思うような仕事でも引き受けてしまう。つい横から口を挟みたくなるが、本人が「出来る」と言っているのに、他人が「出来ないだろう」などと言うのも失礼だと思い、黙っている。しかし、案の定、期限が来ても仕事は終わっていない。

そういう人がいると、周囲は振り回される。その仕事の依頼者はもちろん、その人に次の仕事を頼もうとしている人にも影響が及ぶ。また、遅れた仕事がクリティカルパス（※）の一部であれば、より大きな仕事のスケジュールがまるごと遅れてしまう。

少し前までは、私も「そういう人」を見たときに同じような感想を持っていました。
特に私が振り回されてしまったような場合は、こいつ何考えているんだ？と思っていたものです。
しかしながら、最近では 私は自分自身が「そういう人」に成り下がっています。

（´・ω・`）

自分なりに原因は考えてみたんですが、要因はいくつかあるものの、一番の元凶はこれだと思っています。

できない仕事を断ったところで、私自身が楽にならない

最近の私は仕事量が多すぎて パンク状態に陥っています。このため、いくつかの仕事が期限に間に合わず、周囲に悪影響を与えている元凶の一人です。
そんな状況でも 新しい仕事は振ってきます。
頑張って断っても 上司に「やれ」といわれると立場上受けざるを得ません。

キャパシティを超える量の仕事を請けた場合、全ての仕事を捌くことはできませんので、そうなると 優先度の低い仕事が手付かずのまま どんどん溜まっていきます。

本来、全体スケジュールへ悪影響を与えないためには、そういった優先度の低い仕事や 他人でもできる仕事を 他の人にどんどん振る必要があります。

しかし、ここで、ふと 気づいてしまった訳です。

全体スケジュールへの影響を与えないように自分では捌ききれない仕事を他人にきちんと振った場合と、できない仕事を断らずに受け入れ続けた場合と、どちらの対応をしたところで、私自身が忙しいという現実は変わらない ということに。

どちらの対応をしても、自分の仕事の忙しさが変わらないのであれば、より楽な対応をとりたくなります。スケジュールをきっちり維持管理するよりも、とにかく目先の作業を裁き続けたほうが楽です。結果 周りを振り回してしまうわけです。

付け加えると次のようなことも考えています。

ぶっちゃけていうと、上司や周囲の人間に信頼されてしまうと、仕事は増えます。(理由についての詳細はこちら)

まわりの人間や上司と話しをしていて、それなりの信頼は得ていると思っていますが、
自分の仕事の負荷を下げるためには、この信頼が邪魔です。

ということは、できない仕事を受け続けて周りに悪影響を与えたほうが、自分は楽になるはずです。まぁ、信頼を落としすぎるとリストラされかねませんが、それはそれで面白いとも思っています。

…えー、自分で書いていて、すっごい自己嫌悪に陥るエントリですが、できない仕事をかかえこんで、周りに迷惑振りまいている奴の、考え方の一例として、私みたいなヤツもいるってことで。

プログラマーが息を引き取る前に綴った詩

今の私の心境はよく表している一文がありました。
はてな からの引用。

・プログラマーが息を引き取る前に綴った詩

非常に淡々とコードのみを書いてある。
過酷な現場に慣れるというのは、動物になることに近いのだと思った。
次に起こることを予想する余裕はない。今、この瞬間を生き延びるだけ。
食い物があれば、できる限り食う、飲み水があれば、叶う限り飲む。
手足が取れても、頭が吹っ飛んでも、リリースできるだけリリースする。
考えることをしなくなり、感覚を研ぎ澄ませて自分を守るだけ。

私はコードを書いているわけではありませんが、状況は近いです。
開発の本流から外れてしまった いわゆる間接作業ばかりをひたすらやり続けていて、しかも負荷は高く、精神的になかなか過酷な状態が続いています。また、そんな状況に突入してからすでに一年以上経過しており、いい加減慣れてきつつあります。

で、こういう精神状態になったらどうなるかと言うと、やっぱり上記引用と同じです。

次起こることを予想する余裕はないので、とにかく今起きている問題のうち、一番やばいやつから処理していきます。後は、ひたすらそれの繰り返しです。
何が最善とか、正論としてどうするべきとか、そんなことを考える気にもなれません。
とにかく自分を守ること、他人がどうなろうと自分に降りかかる作業を避けることだけを考えるようになってきます。

なんといいますか、考えることを放棄している時点で、私自身はもう ＳＥとしては終わったかなぁ 思ってるんですが…

とにかく、もううんざりです。

あ～、早く セミリタイアしてぇ～！！！

開発部隊とは名ばかり

私は一応開発部隊に所属しているんですが、もうかれこれ一年以上、開発やってません。

不具合対応やら、レビューやら、社内の各種手続き用の書類作成やら、開発の本筋から外れた仕事ばっかやってます。

やりたくない仕事ばっかり ず～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ぅっとやらされているわけでして、もぅええ加減にせんかい！という心境です。

やりたい仕事と、やらないといけない仕事が一致することはめったにないことは十分認識しているつもりですが、こんな状態が長く続いているために、最近は、ヤサグレ状態です。

やりがいもとめてこの業界にきたはずなんですが、そんなもん感じたことって、ほとんどないんですよねぇ…

今から思えば、やりがいなんてありもしない幻想を求めずに、素直に公務員をめざしておくべきでした。

まぁ、もう年齢制限にひっかかってますし、いまさら後戻りはできないわけですが。

不具合多すぎ

「『ですよ。』最近～不具合多すぎるんです。市場不具合はレビューしないといけないんで、レビューだらけになるんで・す・YO!」
「そしたら～SO!レビュー時間が多すぎて、新機能開発の時間がとれませ～ん。約束した機能を落としちゃった～！！」
「あ～い、とぅいまてぇ～ん!」

…最近 こんな状況です。
なかなかツライところです。
退社時間はそんなに遅くないので肉体的なキツさはあまりありませんし、
昔に比べればだいぶ楽になっています。
昔は退社時間が24時をまわるなんてことはしょっちゅうでしたしね…

でも、この状況はやっぱ精神的にツライです。

約束したことができないっていうのがね。

何より、この状況から脱出できそうな気が全然しないってのが
輪をかけてキツイですね。

はぁ～

Windows Vista対応について

Windows　Vista対応についてなかなか面白い記事がありました。

戸田 覚のPC進化論

ようやく、Windows Vista対応のドライバーが登場し始めている。
～中略～
アプリケーションと周辺機器はちょっと怪しい。
～中略～
市販アプリケーションの対応具合もお粗末なものだ。

ごもっともな指摘だと思います。
うちの製品も、Vista上では動きませんし。( ´・ω・`)

しかしながら、OSのバージョンアップなわけですから、XPで動作しているソフトであれば、ある程度はVista上でも動くと期待していたわけですよ！
まさか、開発環境のVisual Studio .NET 2003 がサポートされないとは思いませんでした…

開発環境を変えるということは必然的にそれなりに開発工数が発生してしまいます。

しかしながら、我々はメーカですので、他の製品開発も当然実施しているわけです。
すぐにvistaに対応しろと言われてもスケジュールの関係上難しいんです。

「そんなモン予測しとけ！」といわれればそれまでなんですが、この手の作業って問題が明確にならない限りは開発予算がとりにくいんですよね…

小さなメーカーの画面キャプチャーソフトは、Windows Vista対応のアナウンスすらない。フリーソフトならいざ知らず、きちんと市販されているソフトがこれではいただけない。だが、そんな会社がいくつも見受けられるのだ。

うちの会社もそんな会社のうちのひとつです。(^^;)
あー、耳がいたい…

　さらにあっけにとられるのが、Windows Vista登場と時を合わせた便乗値上げ的なバージョンアップだ。ある画像キャプチャーソフトは、Windows Vista対応版としてバージョンが３から４へと上がった。追加コストを支払ってダウンロードして使ってみたのだが、機能向上はほとんどないのである。それでいて、バージョン３はWindows Vista非対応のままで、事実上使えないのだ。

こんな商売をしているメーカーの製品は絶対に使うべきではない。Windows Vista対応のバージョンを手に入れるときには、必ず機能の向上ポイントを調べてほしい。追加コストを支払わせながら、ほとんど機能が変わらないメーカーの製品は、対応が疑問だ。

一般ユーザとして、「新しいOSをお金だして買ったにもかかわらず、旧OSで動いてたソフトが動けへんってどういうことやねん！」と思うのは至極当然だと思います。
私も同じ思いは持っています。

何を言っても、責任転嫁にしかならないんですが、メーカ側にも簡単にVista対応ができない事情があることは察してください。

とりあえず、マイクロソフトには
頼むからもうちょっと上位互換のことを考えた製品を
作ってほしいところです…

なんでできないのか考えろ！

最近 若手エンジニアと話をすると感じることが多いのですが、「それは無理です」とか「それはできません」とか、可能性を全否定するような言葉をあまりにも簡単に言います。

しかしながら、もう少し深く考えてさえくれれば、別の方法が存在することがほとんどですし、そもそも 若手に実現不可能と思われるような仕事を振ることはありません。

で、こういうコメントを聞くたびに もうちょっと考えて欲しいなぁと残念に思ってしまう訳です。

本来「できません」というのは自分の中でありとあらゆる可能性を検討したうえで、
まったく解決策がだせない場合に、仕方なしに最後に言うべき言葉だと思っています。

ですから、そう簡単に言える言葉では ないはずです。

実際、少し突っ込みを入れたり、ヒントを与えてあげれば
気づいてくれることが多いだけに、もうちょっと頑張って欲しいなぁと思うしだいです。

でも まぁ、私も若い頃は「無理や！」とか「ありえへん！」とか
よく上司に食って掛かっていただけに、あまり人のことは言えないのですが(^^;)

プログラマの労働条件を過酷にしているのは、過酷な労働条件を受け入れるプログラマです

プログラマの労働条件を過酷にしているのは、過酷な労働条件を受け入れるプログラマです(分裂勘違い君劇場)
同感する部分が多いです。
が、敢えて持論を展開してみます。

私が気になったのは、「できる人はどんどん待遇の良い会社に移るべき。」のところです。
確かに、より良い条件へ転職することが簡単にできるならばガンガン転職すればよいと思います。しかしながら、現実問題、転職ってかなりの精神力を使いますし、そう簡単にホイホイできるものでもありません。

私も転職経験者ですが、できることなら 再転職は避けたいですしね。

更に転職先のことを考えると、この業界内で転職する限りは どこに転職しても 似たようなところになる可能性が高くなります。また、転職に多大な精神力が必要なこと、転職後も同じ目にあるリスクのことまで考えると、転職回数は少なく抑えたいところです。
それならばいっそ「とっとと この業界からの脱出を検討すべき」ではないでしょうか。

少なくとも 私は再度 この業界内での転職(転社)をしたいとは思いませんし、次転職するならば別業種か 独立かしかないとないと考えています。
この業界での今後も仕事を続けて行きたいとはとうてい思えませんし。

…なんと言いますか、元々 プログラムを組むのが好きで 入ったこの業界になんですけど、もう この業界には正直 希望を持てません…

SEからの脱出

この頃はどうすれば SE から脱出できるのか よく考えています。

というのもSEになってからというもの 製品を作り上げても、達成感がまるで感じられないんですよね。PG時代にはまだ自分の範囲内ではそれなりのものを作り上げたっていう自負が持てたんですが…

リーダーやサブリーダーと呼ばれるようになって、自らは物を作らず、人に物作りをやらせるようになってからというもの 仕事に面白みが感じられなくなりました。ひとつのプロジェクトが終わっても、それは所詮 他人に作らせたシステムであって、「自分で作った！」という感覚が感じられないんです。

実際問題、ひとつのプロジェクトが終わったときに感じるのは疲労感のみです。
そして、ひとつの開発が終わったら 休む間もなく次の開発が迫ってきます。

製品をリリースした場合 しばらくはその製品の不具合対応が必要になりますが、たいていの場合はそれと同時に 新機能の追加開発も必要になります。
しかしながら、両方同時にやれるほどのマンパワーをもてることは残念ながらまずありません。

そんなわけで、製品の不具合対応をしつつ、新機能の開発をするためには人をどう配置して…ってなことに毎回頭を悩ましています。

…そして そんなことを考えていると思ってしまうわけです。
こんな仕事やってて、何が楽しいねん？…と。

どうせ仕事がつまらんのならば、なんか残業のない別の仕事にありつけないかなぁとか妄想しつつ ウダウダしている今日この頃です…

営業担当者がSEに抱く不満とは

IT Pro のこの記事にコメントします。

(1)「お客様の目の前で“それはできません”と即答しないでほしい」
(2)「お客様を満足させていくという顧客指向を持ってほしい」
(3)「指示・依頼を待つだけでなく、自分で考え積極的に提案してほしい」

上記３つが 「営業からSEへの本音」として述べられています.
で、この３つは確かに正論だとは思います...

ですが、敢えて 反論します。

(1)「お客様の目の前で“それはできません”と即答しないでほしい」

まず 実現可能な仕事に対して「できません」と答えるのは論外ですし、
代替案が提案可能ならば それは提案すべきです。

ですが まったくできそうにない仕事 や 代替案すらだせそうにないような仕事も多いです。
このような要求に対して「できます」と回答することのようがよっぽどプロとして不誠実だと思います。

「できない仕事」に対して代替案を提案してこそのプロとありますが、
代替案が提案可能ならば 普通のSEなら代替案だすでしょ？

代替案すらだせないから「できない」と答えるんです。

それなりに仕事ができるSEの多くは 毎日大量の残業をしても
捌ききれないような仕事を大量に抱えている状態です。

営業に対しては まともに働いただけでは 捌ききれないような量の仕事を とってきておいて、前向きな回答をよこせというあたり、その神経を疑ってしまいます。

「できない」ものを「できない」というのは当たり前です。

(2)「お客様を満足させていくという顧客指向を持ってほしい」

これは同意します。 反論の余地はありません。

(3)「指示・依頼を待つだけでなく、自分で考え積極的に提案してほしい」

微妙なところですね。
指示を待つのではなく、自分で積極的に動くようにありたいとは 思っていますが
本当に積極的に動くと 十中八九 自分の首を絞める結果になります。

積極的に動く →仕事たくさん振ってくる →やってられるかー！！

ってな感じです。
その結果 年々 指示待ち型になる自分がいるんですが...

これも上記(1)と同様で、積極的に動いて欲しいというのならば、
動けるような環境を作って欲しいところです。

...最後に、この記事の感想です。
正論を言っているとは思います。ですが、SEが抱えている無茶な仕事の量を考慮せずに SEへの頑張りが足りないと言われている気がして 正直 不快でした。

不具合減らねぇ...

年明けからずっとやってきたプロジェクトがようやく終盤に 差し掛かってきたんですが、不具合の多発に悩まされています。

前回のプロジェクトも同じように不具合の多発に悩まされたので、同じ方法じゃぁ まずい ということで 色々と手を打ってみたんですが 思ったほど効果はあがりませんでした。

とりあえず、今の職場のソフト開発方法には 特に手法が存在せず、プログラマに「これ作って」「あと任せた！」方式でした.
で、この結果進捗が見えんとかの 収拾がつかないことに陥っていたというのもあり、 主に開発プロセスにテコ入れをしてみたんですが...

進捗は確かによく見えるようになったんですが、肝心のソフトの品質はあまり変わっていません...orz

で、リリース間近になって不具合がドンドコ発生してバタバタしている...と。

こんな状況になって実感するのは、プロセス改善だけでは駄目で やっぱり 設計＆実装も変えないと品質は上げられないよなぁということです。

今更タラレバを言ってもしかたがないんですが、ここにテコ入れしなかった(というか できなかった)のが やっぱり敗因...かなぁ

何をしくじったんだろう？

えーと、このGWですが思いっきり出勤になってしまいました。
元々の予定では GWまでに不具合を全部 改修しないといけなかったんですが 結局間に合わず、休日出勤にて対応せざるを得なくなってしまいました。

この事態だけは避けようと努力してきたつもりだったんですが、結局GWを削るはめになってしまいました。
一体 何をしくじったんでしょう？

今回 私が担当したソフト開発の主目的は 外注から納品された使い物にならない糞ソース を作り直すというものでした。(前回プロジェクトは外注に丸投げしていたんですが、その結果とんでもないものが納品されてしまったもんで…)

今回は その反省を踏まえて 自社で開発するようにして、さらに行き当たりばったり型開発を止めて ウォータフォールタイプでやってみました。

ですが、結果は当初想定以上に不具合が発生し、こんな羽目になってしまいました。
小さい数時間程度で直せる不具合が ある程度発生するのは覚悟していたんですが、
一週間程度の手戻り発生させるような大きな不具合が複数でたのが大きな 期間のロスになってしまいました。

しくじった点としては、開発プロセスを変えたところまでは良かったんですが、肝心の中身…つまり 仕様を細分化して 噛み砕いていく作業がほとんどできなかった…というか手を抜いてしまった…ところが敗因でしょうか。

当たり前の話なんですが、何をつくるか決めずに、「前回開発した装置に仕様をあわせてつくってくれー」ってやってしまったのが我ながら最悪ですね。いくら納期まで時間がなかったとはいえ、ここで手を抜いたのは本当に失敗でした。
大きな手戻りのほとんどは 「前回と同じにしてくれ」と言ったところで出ています。

納期をとるか、品質をとるか…というか両方とらないといけないってところが厳しいところです。

いやはや、ソフト開発って本当に難しい…

3Kだけど 全米NO.1

日本じゃ ソフトエンジニア(SE)って3Kっていわれてます。
ちなみにキツイ キツイ キツイの頭文字をとって3Kらしいです。

知らない方にとっては 実際のところ どれだけキツイの？

と思われるかもしれませんが、本当にキツイです。

仕事の内容のキツサの割りに、
年収はみどりのおばちゃんにすら負ける始末ですし 日本のSEは残念ながら あまり旨みがありません。

片やアメリカ。
この記事を見てください。

「ソフトエンジニア職は自身の仕事への満足度がナンバー1」だそうです。
給与も平均年収が800万円強ですし、もう日本のSEは手も足もでませんな。

私の場合だと、仮に部長になっても800万なんぞいきません。

なんで 国が違うだけで 職種の差が ここまで生まれるんでしょ？

先のことを考えると 暗くなってしまいます...

人を見る目

恐れていたとおりこの週末は出勤するはめになってしまいました。
ある程度 バグがでることは予想していましたが、とんでもなく大量のバグが発生して、まさに想定外の状況です。

ぶっちゃけた話し、安い外注を使ったつけを思いっきり 食らっています。
今回のバグ改修に使った費用を考えれば、もうちょっとマシなところに発注するだけのお金があったのにもったいない限りです。

このごろ思うんですが、外注に払う金額とその能力はある程度の相関関係があるとみたいです。あくまでも私の経験上ですが、やっぱり高いところは それなりにしっかりと仕事をしてくれます。

前職で使っていた外注と今使っている外注のお値段を考えると 今のほうが格段に安いんですが その分 役に立たない人がくる確率も高いです。昔 値段の高い外注を使っていたころは、役に立たないからクビを切るなんてことは稀だったんですが、今では首切りなんぞ しょっちゅう やっててめずらしくありません。

派遣会社の営業が結構てきとーな事もあり、スキルミスマッチな人が来てしまうんですが、
このような場合 雇う側にとってはお金と期間をドブに捨ててしまうようなものですし、雇われる人にとっても精神的に苦痛でしょうし 双方にとってメリットがありません。(派遣会社的にはお金が入るのでおいしいのかもしれませんが…）

人を見る目ってのは重要ですが、なかなか難しいところです。

クソース フォー！！！

  害虫…もとい 外注から引き継いだソースがバグでまくりで、どうしようもありません。
  総合試験がもう3順目に突入しているにもかかわらず、新しいバグがバカスカでる始末です。

  おんなじ試験を繰り返しているというのに、何で毎回新しいバグが発生するのやら 正直信じられません。
  一応外注内で試験を行ったうえで 納品したと言って来ているんですが、あまりにも品質が低く とても試験してから納品されたとは思えません。

 
  あまりにも酷いので どのように納品されたのかちょっと調べてみたんですが、ここで とんでもない事実がわかりました。

  確かに、単体試験書は納品されていて、全部OKとはなっていました。

  OKとなってはいたんですが…
  明らかに動いていないところが OKになっています。
 
  …どうやら NGがあるくせに全部OKと偽造していたみたいです。
 
  正直、ソースコードがどうとか SEとしてどうとか それ以前の問題で論外です。
  というか、詐欺だと思うんですが！？

  ったく…
  オノレは姉歯建築設計事務所デスカーーー？？？？

  はぁぁ、とんでもないものを引き継いでしまいました…

腐れソース

なんか、デスマーチに突入したっぽいです。
とある害虫…もとい 外注に発注してつくらせたところを引き継いだんですが、これの品質が酷いのなんのって もうありえないレベルです。

非常につらいのが 既に製品として世に出しているために 既存ソースのサポートを放棄するわけに行かないところです。とてつもない腐れソースなんで 本当は とっとと廃棄して一から作り直したいんですが しばらくはこの腐れソースと付き合っていかざるを得ません。

仕方が無いので、腐れソースの不具合対応をしながら 一から作り直そうとしているんですが あまりにも元のソースにバグがでまくるので、バグ対応だけでアップアップ状態です。
作り直しが全然できません。

はぁ… 今週末は土日が無さそう…

くそース・苦ソース

　最近、仕事がややはまり気味です。
　ということで 気分転換に 少しでも妙案は無いものかと こんなワードでググってみたところなかなか興味深いものが落ちてました。
　「デスマーチからの脱出」

　ここにおいてある パワーポイントの資料がなかなかいい感じです。

　特に、人間的デスマ対策PPT　と　プログラム的デスマ対策PPT が気にいりました。

　酷いソースを くそース というのはなかなかいい感じです。

　人に言われたらしばらく立ち直れなくなりそうな きっつい言葉なんで 本当に使うことはないんでしょうが、汚いコードを見たら 一回 仕事で言ってみたいもんです。

　「この　くそース どうにかせぇ！！！！」

　……って やっぱり駄目ですね。キツ過ぎますわ。

IT技術者の2人に1人は“プロ未満”

ITスキル標準（IT Skill Standard：ITSS）ってものがあります。
ＳＥのスキルを客観的に計測・判定してくれるというものです。
(今は計測できませんが、ときどき無料で計測してくれます。)

少し前に一回計測してみたのですが、ちょうど昨日そのフィードバックの連絡がきました。

私の測定結果はＬＶ３．６で、順位は約2000人中で約400位という数字でした。

ちなみに計測結果は、最小値がＬＶ１，最大値がＬＶ７で評価されていて、
ソフトウェアエンジニアの平均値は ＬＶ２．６となっています。

これが１００％正しい計測結果とも思えませんが、客観的に自分がどの位置にいるかを知るのはなかなか面白いです。

私としては、とりあえず真ん中よりは上にいるということで面目は保てたかなぁという感じです。
もしビギナーなんて判定されていたら寝込んでいたかもしれませんしね…

外注を雇う本当の理由

Ｌｖ１からのＳＥ成長日記さんへのトラックバックです。
外注さんを使う側の立場からどんなときに外注さんを雇うかまとめてみます。

ソフト開発の元請が、外注さんを使う理由は主に次のようなものです。
(1)自社要員だけで開発するには人数が足りないようなプロジェクトの場合に,人数の不足分を補うため。
(2)自社にプロジェクトを実現できる技術がない場合に、該当技術を補うため。
(3)自社社員よりも給料の安い外注さんを雇うことで開発費用を減らすため。

ちなみに、(1)や(2)の場合は、単純に外注さんを雇うのではなく中途採用 or 新人採用という選択肢もあります。

ただ、開発を行うために人を増強すると 開発の元請は大きなリスクを負うことになるため 普通は外注さんを雇います。

リスクを負う理由を説明すると、例えば大きな開発案件があったとします。
その案件を開発している間は大量の人員が必要になるわけですが、開発が終わってしまえば今度は大量の余剰人員が発生してしまいます。
この場合に、その余剰人員をどうすべきかという問題にぶちあたるわけです。

ここで、労基法第２０条の問題がでてきます。
自社の社員は簡単には解雇できないという法律です。

開発案件がないのに余剰人員を抱えてしまうと赤字を垂れ流してしまいますので、普通はそんなことできません。
となると 必要に応じて人員を増強する場合 自社社員を増やすのではなく、外注さんを増やそうという話しになります。
目的は いざというときの人減らしを簡単に行うためです。

…えーと、見も蓋も無い結論ですが 自社社員ではなく外注さんを使う最大の理由はこんな感じです。

Windows系プログラマと組み込み系プログラマ

とある外注先に発注したソフトの出来が惨憺たるもので困っています。
ちなみのその外注先は 組み込み経験がない、Windows系のプログラマです。

プログラムの動作スピードが遅すぎてつかいものにならないのに加えて、バグがやたらめったら多くて、新しい機能を動かすたびにバグがでます。

実際に問題のソースを追いかけると、クラスの階層が深すぎるし、おんなじ名前のメソッドが山ほどでてくるし、コメント皆無だし、やたらめったらnewしまくるのにdelete忘れてるし、メンバー変数とローカル変数がごちゃごちゃでトリッキーな値の渡し方をしているし、等々…
いちゃもんを付け出したらきりがないほど酷いです。

とにかくもうぼろぼろなんですが、中でもたちが悪いのがメモリリーク(メモリの開放漏れ)です。すぐに症状がでないため追いかけにくいのに加えて、どこがリークしているのかを突き止めるのもかなり苦労します。

　メモリの獲得・開放を一対一できちんと行うですとか、担当者レベルでの単体試験を確実に行うですとか 組み込み系プログラマには常識だと思うのですが...
　
　ウィンドウズ系プログラマが皆こんなんだとは思いませんが、Windows系の実装経験はあんまり組み込みの役には立たないのでしょうか？
　まったく、やれやれです。

シンプルさの原則

ここになかなか面白いことが書かれていました。

■■シンプルさの第2原則：「サイバラの原則」■■
1＋1＝2
123×456＝たくさん
12÷34＋56÷78＝そんな問題を解かなければならない状況に自分を持っていかない

計算の複雑さを ソフト開発のバグの量と対比させると非常に共感できる意見です。

ソフトの開発してて、やっぱり一番大事なことは、
不具合に埋もれるような状況に自分を持っていかないことにつきます。
如何に不具合を発生させないか が大事で、どれだけ事前に危険を察知できて 事前に手を打てるかが重要です。

とは言うものの、「そんな問題を解かねばならない状況に自分がほうりこまれてしまった」場合はそんなことは言ってられません。

　残念ながら、この状況に落ちてしまった場合、とにかく嵐が過ぎ去るまでは 耐えざるを得ません。
　でもまぁ、ただ状況に流されていてもしかたがないので、せめて状況を整理して どの程度遅れているのかを明確にすることで、秩序を持った状態には持っていきたいところです。

　同じ遅れている状況でも、無秩序に遅れている遅れているよりは、秩序を持って遅れているほうがまだましですから…

不具合の隠蔽

　自分や自分のチームから不具合がでたときの話しなんですが、闇でこそっと改修したいとか、できるならオープンにしたくないとかそんな誘惑にかられることがあります。
　個人的に不具合を隠したことはありませんが、チームメンバの改修状況をヒアリングする限り 結構闇改修って行われていたようです。
　今の上長も、不具合は結構隠したいみたいですし。。。

　大掛かりな話しになると、私の所属した会社(もしくは私の所属するプロジェクト)では、客先に特定の不具合を隠したことが何度かあります。
　下手に大量の不具合を客先に公開すると、そうでなくても落としている信用をさらに落とすことになるために公開なんぞできない…という理屈からです。
　で、これが客先にバレるともう、とんでもないことになるわけなのですが…（ちなみに今のところはバレタことはありません。）

　ただ、ちょっと前の三菱自動車のリコール隠しや 雪印がつぶれた件なぞみていると、細かい隠蔽を繰り返していると そのうち取り返しがつかなくなるような気がします。

　不具合を隠蔽する
　→自分にとって都合の悪い情報が集まってこなくなる
　　→過去の問題を分析して、同じ問題を繰り返さないための対策を立てられなくなる。
　　　→改善ができなくなる…

　えーと、なんで不具合を隠しちゃいかんのか自分なりにまとめてみましたがこんな感じでしょうか？

　なんで、こんな話しをまとめたかというと、
　最近新しい不具合がでると隠したくて隠したくて仕方がないもんでして…

　我ながら精神力が弱い…なさけなや。

見積もり方法

(前回の続き)

私の見積もりに対する基本的な考えは次のようなものです。
100%完璧な見積もり(誤差なしの見積もり）をだすのは不可能
　→但し、見積もり誤差を少し減らすことは可能。
　　→どうすれば少しでも誤差を減らすことができるか考える。
　　　→小さい誤差を減らすことの積み重ねで大きな誤差をちいさくする。

これを踏まえたうえで、見積もりを正確にするためには２つのアプローチが必要だと考えています。

(1)今見えている作業に対する見積もり精度を高くする。

   これは日々の訓練で初めて身につくと考えています。
   
   ・自作業を分類できる限界まで 細分化して、各項目を見積もる。
   ・見積もった結果と実際にかかった時間を比べる。
   ・これをとにかく続ける。
   
   これを毎日やるのは最初は結構つらいです。
   ですが、慣れればそれほど苦になりませんし、それなりに見積もり精度は上がってきます。

(2)見えていない作業をできるだけ減らす。

　問題はこちらです。
　ちなみに、ここでの見えていない作業とは 不具合や作り直し・手戻り、無駄な作業によるロスコストを発生させるものです。

　少しでも見えていない（＝見積もり対象に入っていない）項目を減らすために必要なことは、
　できるだけ自分作業を細分化して、「ざっくり見積もりはこれだけ」ではなく、
「Aはこれだけ、Bはこれだけ、Cはこれだけ」というように自作業を極力小さく、
　イメージできる単位まで小さくすることだと思います。

　とは言うものの、現実問題として見えてない作業はやっぱり見積もりようがありません。

　なんかよい方法ってないものかとよく考えてはみるものの、妙案は思い浮かびません。

　…どっかにいい方法転がってないもんでしょうか…？

見積もりってよく外れます…というかまず当りません

新規開発や追加開発をする場合 見積もりをだすのはいつも苦労します。
私自身 バッチリと正確な見積もりをだせたことはほとんどありません。

昔 上長や先輩等に見積もりのコツを聞いたときには、「少しずつ見につけて行くものだ」などと 言われたものです。しかし、未だに「これだ！」という見積もり方法は見つかっていません。
また、上長や先輩方の運営するプロジェクトはいつも苦労していましたし、私のまわりのプロジェクトを見渡しても見積もりは外れることがほとんどです。ということで、実際のところ、正確な見積もり方法は誰も習得していないのかもしれません。

そんなこんなで私のまわりでは外れまくっている見積もりですが、そのわりにいつも絶対視されます。
「とにかく、この納期は死守しなければならない！！！だから休日出勤よろしく～」ってな感じで…

正確な見積もりを出せたからといって、そのプロジェクトが成功するとは限りませんが、
見積もりを少ない方向へ外すと非常に苦労するのは確かです。

じゃぁ、どうすりゃ 少しでも正確な見積もりをだせるのかってところが重要なんですが、
次に私なりの見積もりに対するアプローチを書きたいと思います。

長くなってきたので、続きは明日…

コピペコーディング

コードレビューや、不具合調査で人のコードをみるたびに思うんですが、コピーペーストのコーディングが非常に多くて見苦しいです。なんで、同じような記述を何度も繰り返しているのにルーチン化(関数化)しないんでしょうか？

似たような処理だからコピペして変数の部分だけ 変更すればいいという安直なコーディングはデメリットのほうが大きいです。

具体的には、次のようなルーチン化のメリットが失われます。

＜ルーチン化のメリット＞

• 複雑さを減らせる

  ルーチン化の最大の意義は、プログラムの複雑さを減らすことができる点です。

  話題がやや飛躍しますが、与えられた課題からいきなり具体的なことを考えるのは不可能に近いです。
  ですから、与えられた課題の範囲を限定して考えること(細分化)により、そのときに設計を行っている範囲に無関係なことを考慮せず済むようにする必要があります。

  具体的には、関連する処理をルーチン化することで範囲を限定していきます。
  これにより十分細分化ができれば、各ルーチン内では考えることを減らすことができ、余計なことを考えなくてすむようにできます。

  自分でコーディングする場合、ルーチン化しなくても 細分化は可能ですが、
  他人のコードを見る場合、ルーチン化による細分化が行われていないと解析が非常に困難になります。

• 変更漏れ

  改修が発生した場合に、修正する箇所が一箇所ですみます。

  これについては逆にルーチン化した箇所を改修するのは、そこが複数箇所から呼び出されているため怖い  (だからルーチン化したくない）という人がいます。
  これは甚だしい勘違いです。
  改修を実施する場合 その改修がどの範囲まで影響を及ぼすのかを考えるのが当たり前で、改修が必要箇所はすべて改修する必要があります。
  仮にルーチン化していない場合、改修漏れに気がつけない可能性が高くなります。
  さらに、コピペコーディングした箇所が枝分かれした日にはお手上げ状態になります。

• 変更の及ぶ範囲を限定する

  変更される可能性のある部分をルーチンの中に分離することで変更の及ぶ範囲を限定します。

コーディングする人にとって コピペコーディングが楽であることは認めますが、後々のメンテナンスのことをもう少し考えてほしいものです。

日本のソフトウェアエンジニアは不幸か ？

IT起業家日記さんの2005年06月13日のエントリです。

私の考えは残念ながらYESです。

・　業務改善をしない

・　待遇が悪い

・　スキルアップ努力を評価しない

色々問題点を指摘されていますが、特に上位３点には激しく同意します。

・業務改善をしない

前回失敗したにもかかわらず 次回も同じ方法で開発すれば 同じような失敗するのは当たり前です。
なんで過去を分析して、問題点を改善しようとしないのでしょうか？
精神論でどうにかしようという人が多いですが、気合や精神論ではどうにもできないことになんで気づけないんでしょう？

・待遇が悪い

最近の小学生の将来就職したい職業ランキングの上位にプログラマが入っているらしいです。
いったいこの業界の惨状をどの程度の子供が認識しているのでしょう？

新婚旅行から帰ってきて空港から実験室に呼び出された人や、念願のマイホームを購入したはいいけれど単身赴任中で引越にも参加できない人とか、子供に顔を忘れられた人とか 身近にいますが…

労働時間が長くても給料が高けりゃまだ報われますが、みどりのおばさんにすら遠く及びません…

・スキルアップ努力を評価しない

評価しづらいというのもあるかもしれませんが、まったく評価されませんね。
スキルに差があろうとも給料は横並びなので 頑張れば頑張るほどに損をします。

…なんか、自分で書いていて暗くなってしまいましたので、このへんで止めておきます。

レビューって難しい

土曜日だというのに、休日出勤してソースコードレビューをやってきました。
しみじみと疲れました。

それもこれも、不具合対応で改修した場合に、改修に伴い新たなバグを埋め込んでいないかを確認しなければならないってルールがあるからなんですが、レビューって本当に難しいです。

難しさの最大の要因は正解がわからないことです。

内部仕様書がないのに加えて、他人が改修したコードです。
そもそも、内容を理解するのだけで精一杯で とても不具合を指摘するところまでいけません。

熟練したレビュアーは製品の欠陥を7割以上指摘できるってな話しを聞いたことがありますが、今の私には7割もバグを見つけられるなんて信じられません。

まだまだ精進あるのみですが、レビューってつくづく難しいです。

良いバグレポートの書き方

バグレポートには「わかりやすさ」が求められます。
改修担当者がそのレポートを見るだけで、バグの調査に入れるのが理想です。

しかし、このレポートの日本語が意味不明であったり、必要な情報が抜け落ちていたりすることは多いです。改修担当者がそんなレポート受け取ってしまうと まず意味不明なレポートを読解する作業から始めますので 調査によけいな時間がかかってしまいます。

ある程度の規模の試験チームを持った場合、わかりやすいレポートの書き方を理解できない試験者がどうしてもでてきます。そんな人は、何回バグレポートを書きなおさせても、毎回 最初は意味不明なレポート提出してきます。

毎回 書き直しを要求するのも不毛な作業ですので、その対策として次のようなテンプレートを用意したことがあります。(実際は他にも項目があるのですが…）

　(1) 期待した結果     
　(2) 期待に反した結果
　(3) 再現手順        

このテンプレに沿っても、まだ駄目なレポートを提出してくる人はいましたが、全体的にはわかりやすいレポートが増えたので、これはこれで正解だったと思っています。

ちなみに上記のテンプレのもとネタはこちら(Joel on Software)です。

「注意します」という対策

ソフトウェア開発を行っている会社ならば、
客先で発生したバグの内容はデータベース化していると思います。
そのデータベースのなかには、暫定対策…発生したバグそのものへの対策であり(ようするに改修方法) と 恒久対策…今後同様なバグを発生させないための対策 があるはずです。

ここで重要なのは恒久対策なのですが、過去のデータベースを覗いてみると情けない恒久対策に遭遇することがあります。

たとえば、メモリリークのために発生したバグへの対策が「メモリリークを起こさないようにする」
NULLポインタへのアクセスによるアクセス例外への対策が「NULLポインタへのアクセスを起こさないようにする」

………見た瞬間に何ともいえない気分になります。

どちらの対策もバグに対して、「今後バグを発生させないようにします」あるいは「今後注意します」と言っているのと同じで、何の具体策も示していません。
データベース化されているということは、その対策はレビューを受けているはずなんですが…
よっぽどレビュアーの質が低かったのでしょうか？

失敗に対して「今後注意します」という対応は、何の対策にもなっていない

昔、まだ新人だったころに上長に言われた言葉です。
悪態のプログラマさんをみて思い出しました。
ちなみに、「今後バグを発生させないようにします」「以後注意します」というのも同類です。

「注意します」も「気をつけます」もどちらも心構えを言っているだけですし、「今後失敗しないようにします」は心構えすら言ってません。どの回答も具体策が無いので失格です。

問題に対する対策を立てる場合、具体的かつ実際に行動可能な対策を立てないといけません。
ただ、いざ実践するとなるとこれが非常に難しく、そもそも対策のたてようがないものもあります。
(たとえばC言語を使用している限り、NULLポインタを完全に防ぐのは多分無理です。ポインタを使うなともいえませんし…)

だからと言ってあきらめてしまったら、その時点でSEとしては終わりだと思います。
完全に防ぐのがが無理ならば、少しでも減らす方法ないのか等、日々考え続けたいものです。

バグか試験手順ミスか

試験の結果がNGとなった場合 テスターは まず それがバグなのか試験ミスなのかを判断する必要があります。試験手順書のとおりに実施した結果が手順書どおりでなくても、試験ミスが一定の割合で入ってしまうため、一概に試験NGとはいえないからです。

私の経験上、一番最近担当したプロジェクトでは、１～２割程度の試験ミスがあり、一番酷かったプロジェクトでは４割程度の試験ミスがありました。
はっきり言って無視できない発生頻度です。

一言で試験ミスと言っても、いくつかパターンがあります。
たとえば、試験手順書作成者と試験実施者、試験データ作成者が別れているような場合、ミスはこんな感じで発生します。
　・試験手順書作成者：
　　　試験手順書誤記
　・試験実施者　　　　：
　　　試験結果の見間違い、試験手順書の内容誤解
　・試験データ作成者：
　　　試験データの誤り

やっぱり、人間はどうしてもミスをしてしまいますので、ミスを減らそうと思えばレビューを増やすしかありません。
でもレビューを増やすと目先の効率が落ちてしまうためなかなか時間が取れません。
だからといって放置すれば試験ミスが増えるし…

何かよい方法はないものか、思案の日々です

素人のテスター

ソフトウェア開発が佳境にさしかかると、いよいよソフトウェアテストが始まります。
このテストが本格化すると大量に発生するバグとの格闘が始まるわけです。

自分で設計からテストまで行う場合は、バグを見つけるー>修正->バグを見つける->修正…の流れを自分自身で繰り返すため、一つのバグが原因で複数の症状が発生することはあまりありません。

逆に他人にテストをしてもらう場合、障害が見つかってもそれが同一の原因によるものか否かの区別がつかないため、一個のバグが原因で大量のバグレポートが発行されることがあります。
仕方ない部分は多いにあるとはいえ、同一の原因に対する2枚目以降のバグレポートは、バグ改修担当者にとっては作業量が増えるだけの代物で、はっきり言って無駄です。

開発経験のある人やある程度テストに慣れている人ならば、似たようなバグが連続発生すればそこで「おや？」と気づいて、そのタイミングで実装担当者へ連絡するとか、似た傾向のテストを止めるようなことをしてくれるんですが…

まれに、ほぼ同一の症状に対して大量のバグレポートを発行してくるテスターが存在して困ります。テスターの仕事はバグを見つけることですが、バグの件数を増やせばいいというものではありません。同一の原因から発生する事象毎に大量のバグレポートを発行しても、それが作業量を増やすだけだということがわかっていません。

高度な要求をテスターに求めるつもりはないですが、せめて 足を引っ張るのだけは勘弁してもらいたいところです。

仕様変更と不具合対応

私の経験上、お客さんや親会社からの改修依頼は内容が不具合対応であっても無理やり仕様変更とみなすことが多いです。実際、不具合対応だとお金がもらえませんが、仕様変更ならば開発費等の名目でお金をもらえますのでこの違いは大きいです。
しかし依頼の内容を冷静に考えると仕様変更と呼びつつ、実はただの不具合対応というのもしばしばあります。
正直なところ何を仕様変更とみなして、何を不具合対応とみなすかというのは難しい問題です。

客観的に考えてみると、ソフトを開発していて、開発中に「本当の意味での仕様変更」にであったことはほとんどないような気がします。
よく「仕様変更」とよんでいるものが実はただの不具合対応ではないかということです。

どういうことかと言うと、開発が進むにつれて開発当初は見えていなかった問題が見えてきたり、今の設計や実装では当初要求されていた「仕様」を満たせないことが発覚することがよくあります。
こんな場合、お客さんに対して「今の実装方法だとこんな制限がつきますよ」
という風に話しを持っていきます。

それを受けたお客さんや親会社が「それじゃぁ困るよ」ってな話しで設計方法の変更を要求してくればしめたものです。
「それは仕様変更ですので、開発費をいただきます」という方向へ話しを持っていけます。

でも、ふと思うんです。
こんな作業の進め方って、ほんとうに正しいのだろうか？と。
かと言いつつ、不具合と認めてしまうとお金がもらえないので、なかなか認められないのですが…

最近の開発期間

ソフト開発を長年やっていると、よく修羅場に出会います。開発スパンが長いプロジェクトの場合はある程度まったりできるのですが、短い場合は最初から悲惨な状況だったりします。

昔は1年～２年ぐらいの長いプロジェクトがありましたので結構楽ができていた気がするのですが、世の中はどんな感じなんでしょう？

私のまわりでは確実に短期間、短納期なプロジェクトが増えてきています。
できることなら修羅場な期間と同程度のまったり期間が欲しいのですが、なかなかそううまいこと世の中回ってくれません。 先のことを考えると頭が痛くなってくる次第です…