バタバタとしているうちに2009年も終わりになってしまった。簡単に今年の振り返りなどをしてみる。 新しいものにチャレンジして習得できたものがある一方で、来年に積み残した課題も多かった。ソフトウェア開発の現場は「そしてバグだけが残った」状態のまま…

日経エレクトロニクス（2009年12月14日号）に、東芝のCELL REGZAで使われている並列化技術「Molatomium」に関する記事が載っていた。マルチスレッドなど並列動作するソフトウェアの開発は厄介なものだが、この事例では開発現場で容易に使える開発環境として…

ソフトウェア開発において、車輪の再発明はするなと言う。同等のソフトウェアが存在するのなら、それを使うことで開発期間は短くて済むし、品質だって確保されていることが多い。わざわざ自分で苦労して作っても、その効果はあまり得られない結果になりがち…

仕分け作業の様子を見ていたら、ソフトウェア開発で行う障害チケットの分類作業に良く似ていることに気がついた。仕分け作業は予算の是非を決めるものだし、チケット分類はソフトウェア開発の品質を確保するためのものだから対象は全然違うのだけど、当事者…

ソフトウェア開発において、受け取っても読む気が失せる仕様書の例： 文字ばかりで図表が無い機械、電気、建築など他のエンジニアリングでは図面でのやり取りが普通なのに、ソフトウェア開発ではなぜ文章に頼った意思疎通が多いのだろうか？確かに文章にしな…

今週の日経ビジネスに興味深い記事が載っていたのでメモ。景気悪化に伴う業績の低下を人のせいにする経営者が多いけど、そのくらいの修羅場を乗り越えられずに社長と呼べるのか？という疑問を持つ人は少なくないはずだ。こんな経済状況だからこそ、優れた経…

ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローし…

ソフトウェア開発の管理にはTracを使っている。リポジトリのコミット状況やチケットの変更状況はタイムラインページに随時出てくるので、ここを見ていればよい。でも、沢山のプロジェクトへ同時並行で関わっていると、日々の進捗に追いついて行くのが大変だ…

ネットで本を買う時には、bk1を使うことが多い。理由は単純で「安いから」だ。書籍や雑誌は再販商品なので、どこの本屋で買っても同じ値段だ。最近では店独自のポイントが付いたり、再版切れの本が安売りされていたりするけど、店の場所や本の対象が限定され…

仕様書に書かれている内容や、tracのチケットにコメントされている記載をチェック。確かに日本語の説明文が書かれているけれど、何だか意味が通じないので担当者に問い合わせを行う。しかし、その回答はなぜか怒ったものが多い。 「この仕様書の記載は常識で…

久しぶりにVMware PlayerとUbuntuをメンテナンスしてみた。(Windows XP/SP2) VMware Player更新まずはVMware Player ver2.5.2をアンインストールし、ver3.0をインストールする。ver3.0に上がって、従来は不可能だった詳しい設定が出来るようになっている。 V…

昨日は久しぶりにSEA関西プロセス分科会に参加した。今回のテーマは「ソフトウェアプロダクトラインの意味するところ」、講師は書籍「ソフトウェアプロダクトラインエンジニアリング」の訳者でもある林好一氏だった。金曜日の夜だというのに参加者は多く20人…

自分では「「忙しい」は禁句」と思っているので、決して「忙しい」を口にしないようにしているのだけど、周囲を見ると「忙しい」人だらけだ。でも、本当に皆忙しいのだろうか？本質な作業で忙しいのなら分かるけど、実はどうでも良いことに忙しい人もいるよ…

その昔、とある事情で転職コンサルタントの人と話をしたことがある。自分がやってきた仕事や経歴を説明し、自分の置かれている状況も説明し、会社に対する愚痴もいろいろぶちまけた（ような気がする）。私としては仕事そのものに対する不満よりも、社内に手…

最近は派生開発とか保守開発がメインの仕事になってしまい、新規開発をやった経験が無いという若い開発者も珍しくないようだ。経験を積めないという点で気の毒なことだと思うが、それと同時に、これらの開発に対処するための確固たる方法論が無い点も由々し…

職場の雑談で、週末に読んだ技術書の話をしたことがある。特に難しい本でもないし、気軽に読めるものだったのだけど、その時の相手の反応は「休みの日に本なんか読んで勉強しているのですか？」だった。自分では本を読むことくらいアタリマエの事であり、特…

物事に白黒を付けたがらない人がいる。議論をしても、自分の主張よりはまず他人の意見を聞いてからという方針だし、その主張も相手の意見によって平気で変えたりする。おまけに、自分の信念がないものだから、前回の打合せでは「○×を...する」と言っておきな…

上手くソフトウェア開発が出来るチームは、開発プロセスも良好だし、技術・スキルもそれなりに高いようだ。細かく見ていけば問題が無いわけではないけれど、それらは許容範囲内に収まっているし、絶えず改善活動を行っているせいか昨年の状態より良くなって…

世間で「職人芸」と言うと、他の人には出来ない何か高い技能のことを指すと思う。例えば、伝統工芸の職人芸などがその一例だ。長年の努力で培った技術は賞賛されるし、本人も優れた人として崇められることが珍しくない。しかしながら、ソフトウェア開発の世…

「自業自得でしょ」と一言で片付けてしまうと文句を言われそうなので、噛み砕いて説明してみた。 ソースコードが長くて複雑度が高い以上、それなりの品質しか出ない。 ややこしい処理方法を使っている以上、それなりのパフォーマンスしか出ない。 効率悪いや…

様々な開発プロジェクトを横断的に見ていると、情報共有という面で大きく2つに分類されるようだ。 プロジェクトに自信が有るところは「情報を見せる」 プロジェクトの進捗、問題等が一目で分かるようにTrac等で公開されている。 Trac等を参照することにより…

少し前の日経コンピュータに特許庁のプロジェクトが載っていた。もちろん、プロジェクトの成功事例ではなく、失敗事例としての記事だ。133億円規模の開発が予定より2年遅れていながら、まだ稼働できないどころか設計すら出来ていないらしい。 特許庁の基幹シ…

最近、ASCII.technologiesの記事が面白い。昔のUNIX Magazineも悪くはなかったけれど、リニューアルしたことでコンテンツの対象範囲がぐっと広がったように思う。2009年12月号ではこんな解説記事が載っていた。 GPGPUによる並列処理 CUDAの仕組みはもちろん…

終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップ…

ソフトウェア開発の振り返りにて、反省点を検証してみる。 「仕様書のレビューを行いました」→しかし、後で仕様書の不備が発見された。 「ソースコードのレビューを行いました」→しかし、後でコーディングミスが発見された。 「テスト手順書のレビューを行い…

「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに…

最近の開発状況はこんな感じ。 企画→経営コンサルタントに丸投げ 開発・設計→外注業者へ丸投げ 評価→検証業者へ丸投げ プロセス改善→専門コンサルタントへ丸投げ これでは「社員はいったい何をやっているのか？」と聞かれるのも当然だ。自分一人ではソフト一…

長い資料をプリントしてみることがある。エコロジー推進派には目の敵にされそうだけど、全体像を把握するにはこれが一番だ。確かに、24インチディスプレイなどの大型画面では一度に表示できる領域が広いとは言え、たくさんのプリントを机の上に広げた時の情…

モノ作りの品質というと、どうしても製造現場にフォーカスしたもの（品質管理）が多いけど、この本は開発現場での品質（品質工学）を取り上げている。品質工学を毛嫌いする人は少なくなく、知名度や普及度は今ひとつのような感じがする。でも、この本に難し…

ソフトウェア開発において、やたらと感情面に訴えるリーダーがいる。曰く、こんな感じ。 頑張れば出来るはずだ。 確実に対処していきたい。 納期を守る意識が必要だ。 注意すれば防げるはずだ。 品質確保が最優先だ。 開発グループにハッパを掛けるのは必要…