会社からの帰り道、以前に会社を辞めた人とバッタリ出会った。やぁ元気ですかなどと挨拶をしつつ、互いに近況などを伝え合う。それほど長い時間が経ったわけでもないのに、双方とも周囲の状況が大きく変わってきているので話すネタが多い。 彼の場合、管理職とは言え会社都合の人員整理（つまりリストラだ）で首を切られた立場なので、会社に対する思いは複雑なモノがあるはずだが、もうその辺のことは吹っ切れたらしい。サラリーマンだから仕方ないし、いつまでも拘っていては前に進めないのだろう。この厳しい雇用情勢の中、再就職先を探すのは大変なはずだが、顔つきは明るくなんだか妙に楽しそうだ。その点について尋ねてみたら、こんな答えが返ってきた。 俺はもう45歳になる。これからどの位働けるのか考えてみたら、もう20年も無いことに気がついた。労働者としては既に折り返し地点を過ぎているんだよ。こんな事を意識してしまうと、残りの人生を

ソフトウェア開発において、受け取っても読む気が失せる仕様書の例： 文字ばかりで図表が無い 機械、電気、建築など他のエンジニアリングでは図面でのやり取りが普通なのに、ソフトウェア開発ではなぜ文章に頼った意思疎通が多いのだろうか？確かに文章にしなければ表現できない内容も有るけれど、UMLのような図面を使う方が一目で分かりやすいし、「全てのケースでの考慮漏れがないか？」を知るためには表を使って条件を網羅的に整理するのが確実だろう。文章だらけの仕様書は「何か記載されていない項目があるのではないか？」という疑いを晴らすことが出来ないように思う。 背景説明が無い やたらと詳細な仕様が書かれているのに、「全体構成」や「概要」が記載されていないので、一体何についての資料なのか全体像がなかなか理解できない。書き手にとっては「アタリマエ」のことだろうけど、それを読み手に伝えるのが仕様書の役割だろう。仕様書は、

ソフトウェア開発において、ありがちな品質対策の例。 テスト作業への人員追加 テスト期間の延長 テスト体制の見直し 経験的に言って、こんな素性の悪いソフトウェアに関わるとロクな事が無い。根本的な作りが悪いソフトウェアを、いくらテストでフォローしようとしてもそれは無理というものだ。出血が続いているからと言って、傷口に絆創膏を貼り続けても何も解決しない。対処療法が効くのはほんのつかの間に過ぎないし、それでカバーできる範囲は極めて限られている。やるべきなのは出血が続いている根本原因を突き止め、その出血を抑えるための施策を取ることだろう。テストによってマイナス10点がマイナス5点に上がったことを指して「品質が改善した」と主張するのは大きな誤解だし、そもそもいくらテストを続けても決してプラスの点にはなり得ない。スティーブ・マコネル氏がCode Completeの中で言っているように、テストは品質を改善

その昔、とある事情で転職コンサルタントの人と話をしたことがある。自分がやってきた仕事や経歴を説明し、自分の置かれている状況も説明し、会社に対する愚痴もいろいろぶちまけた（ような気がする）。私としては仕事そのものに対する不満よりも、社内に手本となるような技術者がいないことの方が大きな不満であった。ソフトウェア開発に関わる組織なのに、技術に関する議論が出来ないという寂しい環境なのだ。これならネットで掲示板を相手に議論した方がよっぽど面白いではないか。 コンサルタントの方はふんふんと頷きながら話を聞き（たぶん、よくある話なのだろう）、私の置かれている状況は理解できると答えた上で、このような話をしてくれた。 「確かにそれは技術者にとっては不満のある環境かもしれません。目標となる技術者が社内にいないのは残念なことです。でも、誰かが先頭を切り開いていく必要があります。それが貴方ではまずいのですか？」

「バグの無いソフトを作るためには、そもそもバグを発生させなければ良い」というのはid:rabbit2goの名言だけど、モグラ叩きの如くバグを潰していくだけの開発では、一向に品質は向上しない。そもそも、障害が発生するのは開発プロセスやエンジニアリングに何らかの問題を抱えているからであり、その根本原因を突き止めて直す必要がある。 「ソフトウェアの欠陥予防」はそんな欠陥予防にフォーカスした書籍だ。著者は、ソフトウェア品質に対する取り組みとして「検出、分析、予防」の3つがあるものの、この中では検出に重点が置かれすぎている現状を指摘している。 多くの開発チームは、結果を防ぐことの必要性を認識し、欠陥を防ぐためのさまざまなテクニックを試みています。しかしこのようなテクニックのほとんどは、欠陥検出（テスト）の改善に焦点を合わせたもので、欠陥の予測や予防に焦点を合わせてものではありません。 既存の様々な方

昨日は久しぶりにSEA関西プロセス分科会に参加した。今回のテーマは「ソフトウェアプロダクトラインの意味するところ」、講師は書籍「ソフトウェアプロダクトラインエンジニアリング」の訳者でもある林好一氏だった。金曜日の夜だというのに参加者は多く20人ほどが集まっていた。以下、講演の要点より抜粋。 ソフトウェアプロダクトラインとは、ソフトウェア再利用を体系的、計画的に行う仕組み。（方法論ではなくパラダイムと理解するのが適切） オフショア開発行っても劇的な生産性向上は期待できない。ソフトウェアプロダクトラインのパラダイムに転換することで、100倍以上の生産性向上も期待できる。 変更可能点を識別、共有、管理する「可変点管理」が重要。可変性の表現として「フィーチャー」を使えば、ステークホルダーでの議論が可能になる。 共通性（コア）の持つゴール（資産形成）と、システムのゴール（資産活用）は異なる。 事業は

ソフトウェア品質を巡る議論にて、こんなやり取りがあった。 私：「やり方を改善しないのだから、品質が向上しないのは当たり前の結果です」 相手：「今までのやり方を守ったのだから、悪くならないで済んだと言って欲しい」 もちろん、絶対的な答えというものは存在しないけど、彼のような「今までのやり方にこだわる限り安心（だし、自分の地位も安泰）」という保守的な姿勢には、やや疑問を抱かざるを得ない。 なぜなら、自分が同じ場所に留まっている時でさえも、他の開発者（端的に言えば競合他社）は絶えず改善を繰り返しているのだ。時間が経てば、その差が開く一方であることは明らかだろう。競争のないソフトウェア開発なら、昔の方法論を守っていくことに意味があるのかも知れないが、絶えず競争にさらされている状態で、改善を進めないのは命取りだと思う。屁理屈をこねて現状に安住する開発者がいる限り、ソフトウェアの品質は上がらないだろう

ソフトウェア開発者と話をしていると首をかしげることが少なくない。曰く、 「これが社内の決まりだから、こうやるしかない」 「効率の悪い方法だが、グループの規則だから仕方ない」 「他に上手い方法はあるけれど、ガイドラインに従うと時間がかかってしまう」 単に社内やグループ内で決まっている開発ルールに過ぎないのだから、変えるべき確固たる理由がある場合、必要に応じて変えていくべきではないだろうか。自分たちの作業を効率化し、作業方法から属人性を排除するのがルールが存在する趣旨のはずだ。効率の悪いやり方がルールで定められているのなら、もっと効率の良い方法にルールに変えるべきだし、そもそもそんなやり方で効率を落とす事に疑問を感じないのは大きな問題だと思う。 特に日本人の場合、教育のせいなのか「ルールを守る」ことにはひどく頑固だけど、自分たちに都合の良いように「ルールを作り替えていくこと」には無頓着のような

小俣光之氏の本を読んでいたら下記の文章に出くわして、少々ドキッとする。思わず知り合いの顔を思い浮かべてしまいました。悪気は無いです。（たぶん） 開発現場に長年固定されたり、あるいは方々の現場に飛ばされたりしながら、目の前の仕事をこなすことだけを要求され、自分自身としては得意分野もできず、ノウハウも蓄積せず、管理や提案も経験しないまま40歳になってしまった、という感じです。 プログラミングでメシを食わせろ!!成功する開発チームのための技術と運営術 - はてなキーワード 本人は真面目に仕事に励んでいるつもりだし、会社も役に立つ人材と見なして評価するケースが多いようだけど、気がつけば「開発はその道一筋、だけど技術は過去の遺物」しか持っていないようだ。会社の仕事は所詮与えられものでしかないわけで、そこの分野だけに留まってしまうのは技術者として非常に危険だと感じる。会社での仕事はテキパキと片付ける一

周囲にはいろいろなソフトウェア開発者がいるけれど、彼らを観察していると、優れた開発者にはある共通の性質があることに気づく。例えば、こんな感じ。 質問ができる 渡された資料を噛み砕き、関連する情報を集め、何を作るのか認識できるくらいなら普通のレベル。優れた開発者は、そこから自分がやるべき事について意図を説明できるし、確認のための質問もたくさん出して来る。質問の量とソフト開発の実力は、そのまま比例するのではないかと思う位だ。逆に言うと、何も質問をしてこない開発者は、自分だけの理解で満足してしまっているので、その理解を他人に確認してもらうこともなく、要求されたものとは全く異なるものを作ってきたりする。 大局的なモノの見方ができる どうでも良いことを細かく突っ込むことが出来る人は多いけど、そのスタンスから一歩引いて広い視点から見た場合の課題を指摘できる人は少ない。例えば、過去に発生した障害を教訓と

ソフトウェア開発者の立場で、個人的に良いと思える会社の条件を幾つか挙げてみた。（題名は「会社」だけど、場合によっては「組織」「部署」に読み替えれば良い） 自由に何でも言える雰囲気があること 会社や部署によっては「上司の言う事は絶対」というところもあるようだ。そんな理不尽にNoと平気で言えるくらいの雰囲気や自由は欲しいし、あまりに頑固なリーダは尊敬できないように思う。立場に関わらず意見を戦わせなければ良いものはできないのだ。 自分で主導権を握った開発が出来ること ある程度の経験や実績は必要になるが、自分で開発のアウトラインを描いて作業を進められる立場になりたい。誰でも若い頃に割り当てられた仕事で「なんでこんな変な設計になっているの？」と疑問に思ったことは有ると思うが、他の人の言いなりで仕事をする限り、そのような呪縛から逃れることは出来ない。それなら逆に自分で主導権を握って好きなように開発出来

ソフトウェア仕様書レビューに参加。事前配付された資料に目を通しておいたので、質問が幾つか出てくるのは当たり前。これは本来のレビューの目的だから問題ない。しかしながら、実際にレビューが始まると「仕様書に書かれていないこと」を補足説明と称して説明し始めるのでややこしい。曰く、 「この仕様書を補足すると、...（以下、説明が続く）」 「この仕様が必要になった背景は、...（以下、説明が続く）」 「この仕様変更の理由は、...（以下、説明が続く）」 等々。そんな発言を聞いたら、こんな質問が出てくるのは当然だろう。 私：「説明の内容は分かるが、なぜ仕様書に記載されていないのだ？」 担当者：「…」 仕様書は、それ自体で完結すべき性質のものだと思う。口頭で補足が必要になった時点で、仕様書としては破綻している気がしてならない。他の資料が必要なら参照が必要な旨を記載すべきだし、仕様を理解するのに背景事情が必

ソフトの仕様についてプロジェクトメンバーと打合せ。 私：「…という案はどうだろう？」 同僚：「面倒くさそうだな。○×の運用とか、△□の保守とか」 私：「その分、ユーザは楽を出来る。だからこそビジネスチャンスがあるのでは？」 ユーザ側からみれば「面倒くさい何か」を解決してくれるからこそ、新しいサービスを導入したり、製品を購入してくれるのだと思う。その分、提供する側の作業負荷は増えるけれど、お金をもらっている以上、それは仕方がない。 作り手の論理で言えば出来るだけ「手離れの良いもの」を出したいが、サービスの内容によっては必ずしもそう上手くいくとは限らない。ライバル会社も当然同じことを考えているはずだ。手を出していないところを見ると、やはり後々の手間を嫌っているのかも知れない。でも、皆が面倒だと嫌っている所にこそ、実はビジネスチャンスがあるような気がする。

今日から仕事。新年の挨拶もそこそこに、今後の作業方針について打合せを行う。昨年からの宿題は残っているし、未解決の課題も残っている。しかし、それは順次片付けるものとして、新しいプロジェクトも別途始めていかなければならない。メリーゴーランドのように同じ所をグルグルと回っているわけにはいかないのだ。あれをやりたい、これはやるべき、それは是非とも必要等々、新規案件のネタを次々と出す。最近はこんな形で提案をすることが多い。もちろん、組織として顧客のニーズや要望を吸い上げるための仕組みは有るけれど、開発者として手持ちの材料を使って何ができるのか、と言った提案も同じように重要だ。 しかし、周囲を見る限り、目標や方針が決まればそれに従って仕事を進められる人は多いものの、どのような方向に進むべきか明確にビジョンを示せる人は少ないようだ。見方を変えれば、一部の人が敷いたレールの上を、他の人たちは乗っているに過

ソフトウェア開発の現場で起こっている一例。 最初の開発では開発リスクを考慮して熟練メンバーが開発に割り当てられる。ベテランなのでデザインパターンを駆使した高度な設計となるが、精鋭揃いのメンバーなので皆これが当然と思っており何も問題は起こらない。 時間が経ちメンテナンス段階になってくると「OJTを兼ねて」若手が担当することが増えてくる。当然のことのながら当初の設計の意図などを無視して「動けばよいコード」を追加するため、当初の設計が徐々に崩れてくる。 さらに時間が経つと、教育用には相応しくないボロボロ状態のコードになる。しかし、OJT用教材の定番という位置付けになっているため、多くのこんな開発者が「これが当たり前」と思って学習してしまう。こんな開発者は、やがてさらに出来の悪いコードを量産するようになる。 優れたソフトウェアアーキテクチャは、それなりに技術を持つ人がメンテナンスしてこそ意味を持つ

ソフトウェア仕様の打合せを行うと「あの仕様は難しくてね」とか「この仕様書は内容が難しいから...」と自慢気に話をする人がいるけれど、そもそも仕様はそんなに難しくて良いものなのだろうか？確かに要求内容に矛盾があるとか不足があるというには（残念ながら）当たり前のことだけど、その内容を噛み砕き、理路整然と整理してまとめたものが仕様のはずだ。難しい要求を、素直にそのまま難しい仕様に変換しているだけでは、そもそも要求を取りまとめる意味がない。仕様とは簡潔にして明快なものであるべきだし、仮にその中に何らかの難しさを抱えているとすれば、それは要求を全て理解した上で仕様をとりまとめる作業に失敗している気がしてならない。仕様の難しさを自慢するのではなく、その難しさをいかにシンプルな仕様にまとめ上げたのかを自慢して欲しいものだ。

今日、思考が停止していた人たち。 上司 メールの回答がトンチンカンだったので直接聞いてみたら「未読メールが200件溜まっているので片付けている」とため息混じりの返事。たくさんのメールの波が押し寄せてくるのは今の時代では当たり前。これをいかにテキパキと片付けていくかが重要なのだ。未読メールの件数は、自らの処理能力を端的に示しているような気がする。返信の数だけはどうにかこなしているようだけど、その内容について話が出来ないなんて、あなた大丈夫？ ソフト開発担当者 「△という理由により、バグを見つけることが出来ませんでした」との発言。自分でテストコードを書いて動作を検証してみれば、すぐに分かる不具合なのだけど？バグの発生をいかにして防ぐか？という姿勢を取ったことがないのか？長年ソフトを作ってきてもバグの発生率を低下させることに失敗しているのなら、それは進歩のない証拠でしょ？単体テストすら導入できな

「ソースコードが設計書。だから別の設計資料なんか要らない」と言っている人がいた。Webでも同じような見解を見ることがあるし、こんな運用ルールで事足りる開発現場も有るのだろう。確かにこれはこれで一理あると思う。私だって個人的に作っているソフトに、必ずしも設計書を作っているわけではない。 しかし、100万行単位のレベルで組織的にソフトウェア開発を行っている現場（うちのことだ）では、こんなやり方は通用しない。理由は下記の通り。 ある機能が100万行のソースコードの何処に入っているか分からない。 そもそも、ある機能が100万行のコードの中に含まれているのか分からない。 機能追加・変更・修正に伴う影響範囲が、100万行のコードの何処まで及ぶのか分からない。 例えば、開発現場に入ってきたばかりの協力会社の人に応援を頼む場合、100万行というコードの海を直ぐに泳げと言うのは、無理な相談だろう。そこで作業