2006年があと少しで終了

2006年も残すところ、あと数時間となった。
2006年を振り返ると、色々なことがあったが、いい年だった。
今年は、最近見ていなかったレコード大賞も久しぶりに見た。
たまたまテレビをつけたらやっていた。そうしたらなんと司会が蛯ちゃんではないか。
やはり今年は、蛯ちゃんに始まり蛯ちゃんで終了かな？
いや今年最後のメインイベント、格闘技が今晩あるから酒を飲みながら見なくては？
誰が勝つかな？楽しみだ。
今年もいい年だったので、来年はもっといい年になるように毎日を大切にして過ごしていこう。
最後に、マリオブラザーズも買ったしね。

買うかどうか迷っている

NintendoDSのソフトで百ます計算・マリオブラザーズ・マリオカート
のどれを買おうか非常に迷っている。
そのほかにもウイイレ・ゼルダの伝説がある。
一番優先順位が高そうなのが、マリオブラザーズかな。

今はXbox360のお姉チャンバラをやっているからやる時間がなさそう。

年末年始の休暇で色々とやろうと思っているが、まだほとんど実行できていない。
大掃除や実家に行ったりと何かとやることがたくさんある。
夜な夜な色々とやろうと思っていたことを実行するとほとんど寝る時間はないだろう。

まあ、できる限りやってみよう。

年末の賑わいを感じる

今日、午前中に家の大掃除を行い、午後に子供と近所のスーパーに買出しに2人で行ってきた。
そうすると、いつもの倍以上の人がいたり、お飾りやお餅がおいてあったり、
カニを売っていたりと、年始に向けての準備がこういった身近なところで感じる。

ここ数年、年末の賑わいを個人的に感じなくなってきた。

昔は、テレビで特番をやったり、親が準備をしている姿を見ていたので感じていたが、
最近はテレビもあまり見ないし、親とも暮らしていないので、そう感じるだけかもしれない。
もしかしてマスコミや周りに踊らされているだけかもしれないということに気がついた。

だから、特に年末年始は、周りは急いでいても俺はのんびり迎えるように気持ちだけはゆとりを持っている。

こんなときに、交通事故など起こしても気分がいやだから、気持ちにゆとりを持って過ごしていきたい。

今日が仕事納め

今日が今年の仕事納めの日だった。今年1年を振り替えてみると、今までの一番きつかった。

複数の製品が同時リリースがあり、工期はきついという中で、ようやくリリースまでこぎつけることができた。

それにしても同時に製品が出荷されるのは、独立したテストチームができてから初めてのことだった。
人も投入したし、テストケースも何十万件という数になり、一時期は、睡眠時間が4時間ということがずっと続いた。
修正が追いつかないと、昼間テストして、夜、修正部隊として修正を行うことが時々あった。

それでも今年は、俺の人生で2人のすげー人物にあった。その2人と出会い、モチベーションがあがり、やる気にもなった。

今後、数年経過したときに、この2人の人物との出会いがあったからこそ、今の俺があると言えるのかもしれない。

ビジネスマンとしても人としても今年は自分で成長したなと感じるくらい成長したと思う。

成長させてくれた、周りの人たち、2人の人物である、Hさん,Sさんありがとうございました。

セル生産方式における問題点

以前、このブログでセル生産方式で、プログラマ・テストエンジニア・テクニカルライタが
ひとつのセルとして作業をすれば、うまくいくと書いたが、最近問題点に気がついた。

問題点とは、テストエンジニア・テクニカルライタがプログラマよりも
人数比率的に少ないのはどこの企業でも同じことだろう。
そうなると、テストエンジニア・テクニカルライタがマルチタスクになってしまう。
マルチタスクになった時点で、どうしてもテストエンジニア・テクニカルライタが先に進めていた作業をすることになるので、
次の作業に取り掛かろうとしたときに、要件の確認、テストケースの作成、マニュアルの作成の作業が入れなくなってしまう。

対策としては、作業をする人とは別の人が要件の確認、テストケースの作成などを行う必要がある。
マニュアルに関しては、ちょっと思いつかない。

このようにしていかないと、うまくいかないことが最近わかった。

セル生産方式における制約条件は、人というリソースになることだ。
すべてはこの速度に合わされるので、プログラマが早く作業をしても意味がないことが色々と試してみてわかった。

よいアーキテクトとは

よいアーキテクトとは、ソースコードを見たときに何をしているかをぱっと見ただけで理解できる構造であると考える。

1.オブジェクト指向設計に基づいて内部構造が理解しやすい。
2.テストしやすい。
3.フレームワークを提供されている場合にそれを無視しない。

テストしやすさとはどういうことだろうか？
まずはテストをしにくい構造とは、
テストコードを記述することができなかったり、
凝縮度ではないが依存関係が非常に高いことがあるだろう。
もしかしたら気がついていないだけで、その他にもあるかもしれない。

まあもっとも重要なことは、変数名やメソッド名を見たときに
どういった振る舞いをするかを理解できないものは非常に分かりづらいことは言うまでもない。

子供のおもちゃは進化している

昨日買ってきた子供のクリスマスプレゼントを今日渡した。
買ってきたものは電車の積み木だ。
中を空けてあげて、渡すと非常に喜んで遊んでいた。
買ってあげてよかったなと思う。こんなに喜んでくれると、買ったかいがあった。
それにしても選んだところのお店に、色々と積み木のオモチャが沢山あり、選ぶのに迷った。
個人的には、積み木を色々な形のものに変えられるものが良いと思ったが、まだ早いということになった。
来年の誕生日かクリスマスプレゼントはそれが良いだろう。
それにしても子供のオモチャも昔に比べて色々と進化していると思った。

ドリームプラザに行ってきました

今日、家族で清水にあるエスパルスドリームプラザに行ってきました。
今朝、俺の思いつきで行くこととなった。

お昼頃に到着して、駐車場から降りて向かう途中に、なんと息子がスカウトされた。
何の事務所からよくわからないので、面接の話はこちらから連絡するということになったが、ビックリした。

ご飯を食べた後に、外を歩いていると、清水港の辺りをオーシャンプリンセス号で約40分程度の遊覧船があるということで乗ってきた。
サンタが登場したりして初めて船に乗った息子は大喜び。
2階の席に移動して、手すりにつかまりながら、体を前後にゆすりながらかもめを見ていた。
これはもうすぐ終了してしまうが、割と楽しいのでお勧め。

それからクリスマスプレゼントと、お年賀のお酒の「磯自慢」を買って帰宅。
磯自慢を買っているときに、うちにもたまにはということで合計3本の磯自慢を購入。

久しぶりにドリームプラザに行ってみて、家族でたまに行くにはいいかと思った。
すしミュージアム、ショッピング、映画などがあるので、カップルでも家族でも楽しめる場所のひとつだ。

小さなリリースによる弊害

小さなリリースをすると、開発部隊は非常に速度が速く進み、
他のものが制約条件になることが多々ある。
ここでいうリリースは社内向けのリリースとして考えてもらいたい。

今までの製品開発では、このバージョンにはこれとこれを組み込むと決めて作業をしていることがほとんどであると思う。
しかし、今回俺のプロジェクトとあるプロジェクトで試していることがある。
このバージョンではこれを組み込むと決めるのではなく、できてたものを仕係り品として蓄えておき、市場への投入はこれとこれと決め手ゴーサインを出す。

なぜそのようにしているかというと、
1.これらの要求を組み込むまでリリースできないと決めてしまったら、工期遅れが発生し、
市場が冷めてしまっていて利益を生まない製品になってしまう可能性があること。
2.早めにフィックスすることで開発者のモチベーションをあげて製品の開発速度を向上されることがある。

これらを行ってみた結果、大体今までの工期の半分くらいには縮まっている。
ただ、その弊害として、他部署がついてこれなくなってしまっているということがある。
制約条件が開発部隊から他の部隊に移っていった。
いい意味で期待を裏切りながら開発を進めているから、喜ばしいことではあるが、
こういった弊害が生まれるということはまったく予想していなかった。

最近考えていること

最近、いつもテストの完了基準（出荷基準）を明確にするためにはどうしたらいいか考えている。
よくある完了基準として
1.工期
2.テストケースが終了した
3.信頼度成長曲線が安定した
4.目標のバグ摘出数がクリアできた

などである。

1.に関してはどうでも良いわけではないが、あまり考えていない。
2.に関しては、テストケースから漏れている場合があるのに、これも無理だ。
3.に関してはまあある程度いいだろう。しかし、どこで安定したといえるのか？
テストケース自体が悪かったらあまり意味がない。
4.に関しては、目標数が本来の50％程度だと仮定したら終了できない。

2、3、4が組み合わさり総合的に判断しなくてはならない。
そこでの前提条件がテストケースの漏れがないような気がしてならない。
そもそもテストケースが漏れていないのだとしたら、
「バグがないソフトウェアは存在しない」ことに反することになる。
だとしたら何を見て判断していけばよいのか俺にはわからない。
今までの経験や感だけを頼りにしているのは非常に危険だ。
どうしたらいいのか？最近考えれば考えるほど頭が痛い。