ソフトウェアさかば

[TiDD] 計画できないことの管理と計画できることの管理

さかば — 2009-12-06T01:06:35+09:00

知り合いのあきぴーさんのブログを見ていると、Redmineを用いたチケット駆動開発とTestLinkがお気に入りのようです。

それぞれの良いところはわかっているつもりですが、なぜこの2つなのか良くわかりませんでした。そして気付いたのは、この二つが対極にあることです。

チケット駆動開発はアジャイル開発に限らず、開発中に発生する作業を管理します。それは、計画的なものではありません。計画できないことだから、その作業が必要になるたびにチケットを発行して管理するものです。

そもそもRedmineのようなBTSは、BUGという予想できない事象を管理するものなので、計画できない予想外の事象を管理することに向いているのでしょうね。そして、プロジェクト内でその情報をいかに効率よく共有し、管理するかが、ポイントになるということなのでしょう。

一方、TestLinkが管理するテストとは、仕様を満たしていることを確認する作業です。仕様が定まった段階で、テストしなければいけないことが決まりますので、計画的にできる作業と言えるでしょう。

計画的にできる作業ですが、その作業中に計画できないBUGが発見されます。すると、これらを関連付ける必要がでてきます。

すべてのソフトウェア開発には、このような計画できない作業と、計画できる作業があります。それらをいかに関連付けて、効率よく管理するか、それがポイントになるのでしょうね。

玉の光山廃

さかば — 2009-11-08T22:52:39+09:00

大阪は梅田の阪急百貨店で見つけました。

玉の光は地元京都のすっきりしたお酒です。20年ほど前は「二日酔いしない酒(社長の人体実験による)」と言う宣伝文句にに引かれて飲んでから、値段も手ごろなのでお気に入りのお酒の一つです。

さて、この「山廃」(リンク先はWikipedia)というのは、しっかりと日本酒の味がするのにすっきりしている製法です。以前は菊姫の山廃吟醸が入手しやすかったので良く飲んでいました。でも、最近は手に入らなくなってしまいました。

まあ、お酒は他にも色々あるので困ってはいませんでしたが、やはり山廃も飲みたいもの、玉の光山廃はまさに求めていたお酒でした。お店の人によると、3年ぐらい前から売っていたそうですが、近所の酒屋では見たことがありません。しばらくは、梅田で買うことになりそうです。

値段は4合で1180円だったと思います。お試しあれ！

[TiDD] チケットの粒度に気をつける

さかば — 2009-11-07T22:52:39+09:00

チケット駆動開発の特徴は、管理的でなく自律的にプロジェクトを管理できることです。チケット駆動開発を実践すると、作業の抜けをなくそうと開発メンバー自身が進んでチケットを登録し、日々残チケットを確認しながら作業します。細かな作業ももれることがなく、きちんと行えます。

チケットに登録することは、作業工数が小さければ小さいほど有効です。大きな作業を忘れることはあまりありませんが、小さな作業は「うっかり」が発生しやすいからです。

管理者は全体の進捗と残業時間を管理するだけで日々の作業が進んでいきます。しかし、順調に進んでいるからとチケットを見ていないと危険な場合があります。

それはチケットの粒度がそろっていないとき、つまり作業時間のかかるチケットが混在するときに生じます。小さなチケットがたくさんあるとき、開発者は日々チケットをチェックして、作業対象と順序を決定して作業を進めます。しかし、作業時間のかかるチケットがあると、日々の作業のリズムが崩れます。作業工数の大きいチケットだけを気にするようになり、細かな作業のチケットがなおざりになりがちです。

チケット駆動開発は作業の抜けをなくします。しかし、チケットの粒度に気をつけなければうまくいきません。もし、細かなチケットに分けることが難しいなら、細かな作業のチケットを忘れていないか管理者が気をつけなければならないでしょう。

[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する-

さかば — 2009-10-03T22:25:17+09:00

あきぴーさんと書いた論文が公開されました(2-1、今週公開されたようです)。

引用していただける場合は、こんな感じでどうぞ。

小川明彦, 阪井誠, チケット駆動開発 - BTSでExtreme Programmingを改善する-, SQiP2009, 第28回ソフトウェア品質シンポジウム2009発表報告集, pp.93-96, 日本科学技術連盟, 2009.

<')))><

[TiDD] チケット駆動開発は見える化でもある

さかば — 2009-09-27T20:56:43+09:00

チケット駆動開発にはいくつかの側面があります。

開発者にとって大きいのは、ToDoリストとしての側面でしょう。忘れてしまいそうな細かな作業を、どんどんチケットにすることで忘れずに作業をすることができます。

以前、ある人が「備忘録」言われた際には、正直なところ抵抗を感じました。しかし、開発者が積極的にチケットを起こす動機は、やはり抜けなく作業をしたいと言うことに尽きると思います。

チームとして考えると、チケット駆動は見える化でもあります。チケットの発行は、これから解決しないといけない問題点(issue)を共有し、明らかにする行為です。

チケットによってプロジェクトの現状が明らかになり、コミュニケーションが向上します。また、だれが何をしているかも管理が容易になり、必要なフィードバックが可能になります。

作業の見積もりがきちんと行われているならば、アジャイルで必要となるタイムボックス管理も可能になるでしょう。

チケット駆動開発は見える化でもあるのです。

<')))><

[TiDD] チケット駆動開発の最初の一歩

さかば — 2009-09-09T13:00:00+09:00

チケット駆動開発で最初にすることは、「上司への報告！」というねたは終わったので、具体的に進めましょう。

前回書いたように、どのようなものをチケットにするかプロジェクト内で決めておくことはもちろん、チケットを参照する環境を整えなければなりません。

たとえばtracなら、既存のレポートをコピーして修正するだけです。とりあえず以下のようなレポートを作成してはいかがでしょう。

　　- bugのみ
　　- taskのみ
　　- その他

当初、品質管理用にbugのみを作成しましたが、すぐに作業管理がしやすいようにtaskのみというものを作りました。そうすると、抜けができるので、残りのみを参照する「その他」を作りました。抽出条件(WHERE句のところ)や表示項目(前に"_"があると表示されない)は自由に変更できますので、プロジェクトによって用意されると良いでしょう。

また、tracの権限の設定が堅いので、チケットを修正できるようにメンバーに権限を追加すると良いかもしれません。私のプロジェクトでは、memberにTICKET_ADMINの権限を与えました。それなりのリスクもありますので、よく検討して設定してください。

[TiDD] チケット駆動開発はじめました

さかば — 2009-09-07T23:45:40+09:00

あきぴーさんと共著で発表活動をしていますが、これまではチケット駆動開発の経験はありませんでした。とはいえ、今世紀の初めからBTSを遣っていますし、アジャイル開発の経験もありますので、あきぴーさんの経験を聞きながら一度はチケット駆動開発をしてみたいと思っていました。

しかし、現在のプロジェクトはウォータフォールで開発していますし、メンバーは7人と試行するには中途半端な規模、個人の趣味で仕事をするわけにもいかないので、あきらめていました。しかし、その時は突然訪れました。

プロジェクトはオープン系の事務システムで、外部システムとの連携があることもあり、色々と予想外のことが起きていました。これまでもWBSを変更することが多かったのですが、それはシステムテストの時期になってもおさまりそうにありませんでした。

ハンフリーさんは「TSPガイドブック：リーダー編」で、アイアコッカの言葉を引用して「ボスのスピードがチームのスピードだ」(p.9)と書かれています。また、司馬遼太郎さんの「龍馬がゆく」には、北辰一刀流の「気は早く、心は静か、身は軽く」と言う言葉が載っています(あんまり関係ないですが、、、）。

現状を見極めると、今こそチケット駆動開発を実践を決断するときだと思いました。不具合だけでなく、*新たに*必要となった作業は、必ずチケットに登録して作業することにしました(全ての作業をチケットにしないことで、チケット数を減らしました)。

実際にやってみると、結構使えます。日々新たに発生する作業が、手に取るようにわかります。メンバーも作業を忘れないようにと、進んでチケット登録をしてくれます。予想外の変化を抱擁しながら、管理が一元化され、コミュニケーションが効率的になり、そしてメンバーに適時支援(フィードバック)が可能になりました。勇気を持って導入してよかったと思います。繰り返し開発こそしていませんが、まさにアジャイルな開発です。

ただ、一つだけ失敗したことがあります。それは上司に報告していなかったことです。上司にtracのメールを流さなければよかったのですが、何も知らされない上司に「tracのメールが急に増えたけど品質は大丈夫？」と確認されました。

これからチケット駆動開発を始めようとするあなたに言っておきます。上司には必ず報告してください。

「チケット駆動開発はじめました」

と。

＃それって冷麺じゃないの？　いや、冷やしシャンプーのパクリです(笑)

<')))><

[TiDD] BTSによるコミュニケーションの効率化

さかば — 2009-09-06T10:14:00+09:00

BTS(Bug Tracking Tool)は、その名のとおり障害を管理するツールですが、その効果を考えるとコミュニケーションツールと言えるほど、プロジェクトのコミュニケーションを効率化します。

BTSを用いると、どのような状況にあるかを一覧で確認できるのは紙やエクセルで管理しているのと同じです。大きく異なるのは、メールやRSSで最新情報が通知できる点です。

まず、エクセルで管理している場合を考えましょう。大体こんな感じでしょうか？

1) 障害を発見する
2) 障害票を作成する
3) 上司に報告する
4) 担当者に連絡される
5) 欠陥が除去される
6) 障害票に追記される
7) 再確認
8) 完了

一連の流れにどのくらいかかっているでしょうか。仮に３の上司への報告が朝会などだと1日や2日はかかりそうですね。特に別グループの不具合だと調整に時間がかかり、その不具合に関係するテストは中断して、別の作業をしないといけないでしょうね。

実は現在私が管理しているプロジェクトでは、同じことが置きかねない状況でした。少人数の2つのグループに分かれて作業をしていたのですが、席の配置の関係でどうもコミュニケーションが悪い。見ているとメンバー間のコミュニケーションがIP Messenger中心で、グループでもプロジェクトでもなく、個人間で情報共有が行われていました。仲が悪くはないのですが、全員の一体感がない状況でした。

そこで、開発者全員のメーリングリスト(ML)を作成して、共有すべき情報はMLに流すようにしました。少しはコミュニケーションが改善したようですが、グループ間の調整になると、グループ長であるサブリーダを介して行われていました。

そして、いよいよシステムテストが迫ってきました。これまでの類似プロジェクトでは、エクセルで障害管理され、ファイル共有されていました。でも、上記のような流れで作業すると他グループの不具合の解決に、1日以上かかる危険性がある。これは危険です。

もう悩むことはありません。社内でtrac環境を支援してくれていましたので、それを使いました。ある程度はメール文化がありましたので、どんな障害でも強制的に全員に配布するようにしました。

効果は突然現れました。それは、ある障害が別グループの問題で発生したときのことです。私が障害通知のメールを見たときは、上記の1から4までに相当する作業が完了し、グループ内で打ち合わせがすでに行われていました。そして、障害通知から20分もしない間に問題は解決され、障害対応は完了しました。

簡単な設定の問題でしたが、この問題が解決しないとシステムテストが継続できなくなり、グループミーティングを経て、作業の入れ替えをする必要がありました。たとえ10分の打ち合わせであっても人数分の工数がかかります。2つのグループの打ち合わせ、サブリーダ2人の打ち合わせ、それが早くて半日、下手をすると2日欠けて行われるのです。考えるだけで恐ろしくなります。エクセルにしなくて本当に良かったと思いました。

<')))><

[TiDD] 小規模開発の難しさを考える

さかば — 2009-08-29T22:50:00+09:00

もう20年以上前になりますが、私がソフトウェア業界に就職したとき、最大10人程度の小規模プロジェクト(当時は間違いなくそういわれていました)に配属されました。

当時はいかに大規模開発を管理するかと言うことが注目されていて、各社で開発標準が決められつつあったころです。当時、小規模プロジェクトの管理はあまり注目されていませんでした。大規模プロジェクトが不採算になると会社がつぶれますが、小規模プロジェクトの不採算なら何とか耐えられたようです。

大規模プロジェクトが難しいのはだれもが認めるところでしたが、小規模プロジェクトにもそれなりの難しさがあり、当時、それはなぜか、どうすればよいか、と考えていたことを覚えています。

時代は移り、大規模プロジェクトではプロセス改善に費用をかけることで、比較的安定した開発が行われるようになりました。特にTSP/PSPでは階層的な管理が行われ、個人からチームへと積み上げによって高い精度で定量的な見積もりと管理ができるようになりました。プロセス改善を進める企業においては、その枠組みに入りきらないようなプロジェクトが企業の利益を圧迫するとまで言われています。

一方、小規模開発に関しては、アジャイル開発があるものの、高い能力を持つ技術者が必要とされていて、全ての小規模プロジェクトを救えるかどうか、難しいところです。

さて、ここで小規模プロジェクトはなぜ難しいかを考えて見ます。規模の大小にかかわらず、外部環境の変化による業務要件の変更、外部仕様の決定遅れ、ミドルウェアなどの開発基盤により生じる問題、は同じように発生します。

リスクは一般に問題の大きさとその発生確率で表現されます。大規模プロジェクトでは、それらを乗じた予算をあらかじめ用意しておくことで、問題が発生しても解決できます。これはリスクが統計的に扱えるほどに、プロジェクトの規模に比して小さいからです。

小規模プロジェクトあるいはプロジェクトの規模に比べて大きなリスクの場合は、問題が発生することで危機的な状況に陥ります。品質低下、予算超過やスケジュール遅れ、といういわゆるQCDが守れなくなるからです。

リスクが問題化したプロジェクトを健全な状態に戻すには、
(1)発生している問題をきちんと把握する
(2)優先順位を決めて作業手順を定める
(3)全ての問題を確実に解決(あるいは対処)する
ということが実施できなければなりません。

これは、まさにチケット駆動開発(TiDD)が支援することです。ソフトウェア開発集に生じた問題や予定していない作業をすべてチケット化し、優先順位を決めて、確実に作業する、TiDDのプロセスそのものです。

このように考えると、TiDDは小規模プロジェクト、特に、仕様変更の多いプロジェクト、細かな仕様が多いプロジェクト、予想外の問題や作業がが生じやすいプロジェクト、に向いていると言えるでしょう。

[TiDD] プラクティスから方法論へ

さかば — 2009-08-24T00:14:14+09:00

「チケット駆動開発」というキーワードで検索すると、名古屋で勉強会が開かれていたり、実際の仕事で試されている方がおられたり、色々なところで注目されていることがわかります。

そんな中で気になったのが、「チケット駆動開発の研究と実践http://blog.livedoor.jp/techblog/archives/64874955.html」(livedoor 開発Blog)です。ここでは、チケットによる見える化http://sakaba.cocolog-nifty.com/sakaba/2009/07/tidd-1b90.htmlや達成感というメリットのほか、こんなデメリットも書かれています。

「チケットを発行するときは楽しいのですが、クローズしたりステータスを変更するときはチケットが多いほど手間がかかります。」

そして、管理者をつけたほうが良いとのこと。確かに、たくさんの作業を見える化できることがTiDDの特長ですが、管理作業そのものは従来と同じですし、全体の状況となるとチケットを容易に増やせる分だけわかりにくくなるかもしれません。

実は関連する議論をしたことがあります。題して「TiDDは方法論か、プラクティスか」。アジャイル開発やテスト工程などでTiDDをプラクティスの一つとして用いるならば、大きな効果を挙げると思います。しかし、方法論として考えると、チケット駆動開発の基本である「チケットなしではコミットを許さない」というルールだけでは規模が大きくなると開発できません。

そのような現実から考えると、厳密にはTiDDはプラクティスと言えると思います。では、みなさんはどうされているかというと、あきぴーさんなどは上流はウォータフォール、製造はアジャイルをベースにTiDDを用いられているようです。

では、あきぴーさんの開発方法はTiDD開発方法論であるかというと、そうでもあるし、そうでもない。本人がそうだといえばそうなるのかもしれません。しかし、詳細が定まっていないものを方法論というのもおこがましいので、私とあきぴーさんで外部発表した際には「TiDDをアジャイル(あるいはXP)に適用した」という表現を使っています。

方法論とするには、いくつかの定義が必要だからです。具体的には

チケットの管理の方法：ワークフローの一般化。役割と作業の詳細な定義が必要です。また、チケットの統合や分割の定義も必要です。

作業の管理：チケットと紐づいた作業を日々どのように管理するか。作業が増えた際にどう管理するか。

要件あるいはストーリカードとチケットの関係：チケットをXPのタスクカードとするならば、ストーリーカードはどうなるのか。何らかの参照が必要なことはわかりますが、具体的な方法を示さなければなりません。

ほかにも色々あると思います。実際には、現実のプロジェクトが目の前にあるのですから、色々工夫をしながら具体的な事例積み重ねることだと思います。そしてそれらを元に、まとめていければと思っています。

(事例の提供者おられませんか？もし、論文を書きたいのなら、お手伝いならしますよ～)

[TiDD] チケット駆動開発によるフロントローディング

さかば — 2009-07-31T22:40:53+09:00

カイゼンといえば「フロントローディング」という言葉もありますね。後工程で見つかる問題をなるべく早い工程で摘出することで、手戻りを減らすことです。リアクティブな活動からプロアクティブな活動への移行と言っても良いかもしれません。

TiDDではBTSを使いますので、障害情報と同じように「どの工程で問題が組み込まれたか」、あるいは、「本来はどの工程で摘出すべきか」、といった情報をチケットに登録しておけば、どの工程をカイゼンすればよいかが明らかになります。レビューの強化、ツールの導入、教育、などによって、あらかじめ不具合を作り込まないようにします。

西先生いわく、「武士道の究極は刀を抜かずに人を切る、テスト道の究極はテストをせずにバグをなくす」、まさに名言だと思います。

また、TiDD良いところは、作業漏れが生じた際にチケットを発行してから作業をするところです。どのような作業が考慮されていなかったか、一目瞭然です。類似の開発を行う際に、抜けていた作業をあらかじめ考慮すれば、問題の発生を減少させることや、見積もり精度を高めることができます。

このようにTiDDを用いることで、プロセス改善を行うことが可能です。それも、チケットによって、隠れていた情報が見える化されるからです。でも、TiDDを実践したけれども、難しい点もあるといわれる方もおられます。次回はその点に触れてみたいと思います。

[TiDD]チケット駆動開発と見える化

さかば — 2009-07-30T23:50:45+09:00

トヨタ式のプロセス改善でいう「見える化」というと

「見える化は一言で言えば，問題点が常に「見える」ようにしておく工夫のことである。正常と異常の違いがすぐに分かる仕事場とか，仕事するうえであれこれ迷わずに済む現場のことを指すと言ってもいいかもしれない。」(ITpro)

というように、問題を発見する環境作りをさすことが多いと思います。

トヨタ式の工場では整理整頓が徹底されていて、ごみ一つ落ちていません。そうすれば、本来留めなければいけないネジが落ちていたらすぐにわかりますし、作業の流れが滞ったり、無駄な移動があればすぐにわかるからです。

チケット駆動開発(TiDD)も見える化を促進しますが、以下の3種類があります。

　　・情報共有
　　・問題の発見
　　・作業状況

TiDDでは、BTSを使って作業を管理します。それは全ての開発者が使うものですので、プロジェクトの作業の進み具合をみんなで共有することができます。開発中はついつい自分の担当している作業だけに注目しがちで、他の人と助け合わなくなりがちです。開発者全員でプロジェクトの状況を共有しますので、自然と協力し合う雰囲気ができるでしょう。

チケットは作業の一覧として見るだけでなく、BTSによってはガントチャートなどのグラフ化も可能です。遅れている作業や、作業負荷の偏りも容易に発見できるでしょう。

作業がBTSのチケットになっているのですから、未完了作業の状況を一目瞭然で管理できます。全ての作業がチケットとして登録されていますから、それぞれの作業のステータスを管理することができます。また、様々な条件で抽出できますから、担当者毎の作業状況も容易に管理できます。

このように、TiDDでは従来の見える化を超えた見える化が可能です。これらはアジャイル開発だけでなく、ウォータフォール開発でも、効果が期待できるものです。

[TiDD] チケット駆動開発とXPの共通点

さかば — 2009-07-26T15:43:27+09:00

あきぴーさんがチケット駆動開発(TiDD)をXP(eXtreme Programming)に適用された結果を元に、共著で論文を書いて外部発表をしています(SPES、SQiP)。これらは、アジャイル開発を改善するためにTiDDを適用した論文ですが、なぜそのようなことが可能なのかを考えてみました。

実はチケット駆動開発とXPには共通点があります。それはXPの4つの価値です。それは、

- コミュニケーション
- シンプルさ
- フィードバック
- 勇気

です。この4つの価値がXPのプラクティスに影響を与えています。

TiDDの効果を考えると、このうち2つの価値を支援することがわかります。そもそもの提案者である、まちゅさんによるとTiDDの効果の一つは「開発メンバの仕事が把握しやすくなる」というものです。

全てのソース更新作業がチケットと関連付けられることで、どのような作業が残っているか、プロジェクト内で明確になります。これは、TiDDがプロジェクト内のコミュニケーションを改善するということです。

さらに、まちゅさんはもう一つの効果として「ソースコードのコミット単位が明確になる」とされています。これは、チケットなしのコミットを許さないことから来るもので、開発作業をシンプルにしたことによる効果です。

この二つの価値に対してXPでは、作業をタスクカードに割り当てるというシンプルなルールをつくり、そのタスクカードをタスクボードという掲示板に貼ることでプロジェクト内で情報を共有してコミュニケーションの向上を図っています(もちろん共同のプラクティスもコミュニケーションに重要です)。

ちなみに、フィードバックというのは、繰り返し(イテレーティブ)開発などによって、補正(フィードバック)をしつつ開発することができます。また、勇気というのは積極的な開発プラクティスの実施や担当作業のコミットメントなどによって実現されます。

このように考えるとTiDDはXPと矛盾しないだけでなく方向性が共通しています。繰り返し開発や開発プラクティスを導入すれば立派なアジャイル開発になりそうです。実際にXPJUG関西のTiDDの議論の中では「TiDDによってリズム感が生まれてアジャイルがわかった」という感想さえ出ていました。現実の現場では実現しにくかったXPが、より効果的に実現できるようになる、そんなパワーがTiDDにはあるようです。

ひかりTV：　PC-STB4の熱暴走=PM700に交換

さかば — 2009-07-25T11:38:28+09:00

今月になってから、ひかりTVのセットトップボックスPC-STB4(バッファロー)が熱暴走するようになりました。

予約録画の途中で画面が真っ黒になって固まります。STB4がかなり熱いので、設置場所をDVDレコーダの上から移動させましたが改善しませんでした。

真っ黒画面の状態で再起動すると10～15分ぐらいでまた固まります。ためしに扇風機から直接風をあてると、何とか動くようになりました。

こんなことをいつもやってられないので、ひかりTVのホームページからサポートに連絡しました。結局、PM700という機種に交換になりました。操作性が向上してS端子とNHKオンデマンドが増えました。

「STB4、熱暴走」で検索すると、同じ症例で交換してもらっている人は結構居るようですね。今月分の料金はサービスしてもらいましたが、ギャラクチカシーズン3の終盤が見れなかった方が悔しいですorz

TiDD：チケット駆動開発

さかば — 2009-07-23T22:54:32+09:00

「チケット駆動開発」という言葉を聞かれたことがあるでしょうか？
テスト駆動開発と似ているこの言葉は、最近、アジャイルに興味を持つ人たちの間で注目されています。今回は、この「チケット駆動開発」について書いてみたいと思います。

１．チケット駆動開発の始まり

「チケット駆動開発」は、TracやRedmineなどのBTS(Bug Tracking System：障害管理ツールなどとも呼ばれる)の利用から始まりました。まちゅさんが、たくさんの小さな修正を加えるシステムを開発されている中で、BTSのチケット(障害票)を用いて開発プロセスを改善されたことに始まります。

まちゅさんは「チケット無しでのコミット禁止」とすることで、全てのコード修正をチケットで管理できるようにされました(参考文献1：チケット駆動開発 … ITpro Challenge のライトニングトーク (4))。

まちゅさんによると必ずチケットを発行するというルールによって、2つのメリットが生まれるそうです(参考文献2：チケット駆動開発 (TiDD) とアジャイル開発)。

(1)開発メンバの仕事が把握しやすくなる

(2)ソースコードのコミット単位が明確になる (目的が異なる修正を同時に加えない)

２．アジャイル開発への適用

まちゅさんの講演を受けて、XPJUG関西の人たちが、TiDDがアジャイル開発に向いていることに気付きました。まちゅさんは「もう一つのTDD」と呼ばれていましたが、テスト駆動開発と区別するためにえと～さんが「TiDD」と名づけられました。

そして、あきぴーさんを始めとして、実際の開発現場でTiDDが実践されました。XP(Extreme Programming)のタスクカードをBTSのチケットに置き換えることで、XPを以下のように改善できました。

(1)タスクボードが必要ないので、職場の環境に関係なく多くの作業を管理できた

TiDDによるアジャイル開発では、XPのタスクカードをチケットに置き換えます。このことで、タスクボードと呼ばれる掲示板が不要になり、XPの実施が容易になりました。また、タスクボードを用いると、その大きさによって貼ることが可能なタスクカードの数が制限されますが、そのような制限がなくなりました。

(2)個人毎の作業管理が容易になった

タスクカードはToDo、Doing、Doneという3つの状態で管理されますが、それぞれのタスクの担当を容易に識別できません。タスクカードをオンライン化することで、個人ごとの担当作業を容易に抜き出すことが可能になりました。

(3)複雑な構成管理作業が抜けなく行えるようになった

XPでは繰り返し開発を行いながら複数回リリースするので、リリース後のソースコードと開発中のソースコードを同時に構成管理する必要があります。BTSのワークフロー機能を使うことで、作業の抜けをなくすことができました。

３．TiDDの二つの側面

このようなチケット駆動開発には、ツールの新しい利用方法という側面と、プロセスの改善という二つの側面があります。

３．１ ajaxのようなもの？

「TiDDはajaxのようなもの」と言われることがあります。昔からある機能ですが、考え方と使い方を少し変えるだけで世界が大きく変わる、という意味だと思います。TiDDではBTSのチケットを用いますが、それは障害を記録するものと言うよりは作業の管理単位になっています。

大昔に読んだマイヤースの本に機能とは何かについて書かれていました。時計の機能は現在の時刻を示すものですが、ユーザによっては１と３の間の数字を知るということもひとつの機能になると書かれていました。もちろんこれは本来の機能ではありませんが、TiDDとBTSの関係に似ています。

具体的にはBTSの状態管理、ワークフロー管理、構成管理ツールとの連携、といった機能を、作業管理のために用いています。そのように書くと、「BTSでなくても良いの？」とか「BTSがなくてもよいのか？」という疑問が出ると思います。実はそうなんです。

３．２アジャイル開発のプロセス改善

まちゅさんによると、そもそもTiDDはBTSを「みんなで使うToDoリスト」として使う開発法です。だとすると、ToDoリストがあればBTSはなくても良いはずです。いやいや、ワークフローの管理が必要だと言われるかもしれませんね。それなら、ToDoリストに判子欄を設けてはいかがでしょうか(そういえば、昔の障害票には判子欄のあるものがありました。順に押印していくことで、ワークフローを管理していたのですね)。あとは個人毎の作業管理が必要ですね。ToDoリストを色分けして、担当者がわかるようにすれば、すこしは便利かもしれません。

そんな風に考えると、チケット駆動開発はいったい何だろうと思われるでしょう。誤解を恐れずに書くと、TiDDはプロセス改善の手法です。

まちゅさんはたくさんの小さな修正を加えるシステム開発をうまく行いたかった。たまたまそこにBTSがあって、便利に使えたということでしょう。あきぴーさんは、アジャイル開発をうまく行いたかった。そこにBTSがあってTiDDを実践すると、いままでうまくいかなかったアジャイル開発がうまくいった。そういうことなのだと思います。

つまり、プロセスを改善する道具を探したら、そこにBTSがあったということなのだと思います。

４．チケット駆動開発はエンジニアリングの基本

巷では月着陸40周年と騒がれていますね。このアポロ計画が成功したのはWBS(Work Breakdown Structure)があったからだといわれています。かつてない巨大なシステムを構築するには作業を抜けなく行う必要があるので、WBSは非常に有効なツールだったと思います。

XPJUG関西の集まりで、チケット駆動開発をどこまで抽象化できるかを議論していたとき、ある方が「チケットは忘備録」と言われました。この言葉を聞いて、その程度のものかと正直思いましたが、じつはこれがチケットの本質だと思います。小さな作業がたくさんあるプロジェクトにおいて、作業を抜けなくきちんとやることは、とても大事なことなのです。

アポロ計画ほどの巨大なシステムでなくても、作業を細分化していけばその数は膨大なものになります。それをきちんと抜けなく、定められた手順でやる、それはとても大切なことです。

そのためには、(1)どのような作業があるかプロジェクト内で共有・確認し、(2)開発者が担当作業を把握し、(3)決められた手続きに沿って抜けなく作業する、ということが支援されなくてはならないのです。チケット駆動開発は、それを支援しています。まさに「エンジニアリングの基本」を支援しているのです。

５．まとめ：チケット駆動開発の魅力

「チケット駆動開発」は、アジャイル開発(を中心とした)プロセス改善手法です。もちろんBTSがあれば便利に使えますが、ツールが無くてもプロセスを改善することができるはずです。

このように書いていて、かつてオブジェクト指向分析がブームのころに話題になったOMT(リンク先はWikipedia)の本を思い出しました。この本の後半には、オブジェクト指向でない言語でのオブジェクト指向開発の方法が書かれていました。オブジェクト指向分析は、言語に関係なくのメリットがあるということなのでしょう。実際、この本に励まされて実践された方もたくさんおられるのでしょう。でも、環境の整ったオブジェクト指向言語の方がはやったように思います。

チケット駆動開発もたぶんそうです。便利なタスクカードや「チケット駆動開発環境」というものがあれば、それがブームになるかもしれません。でも、それ以前に良くできたBTSがあったのです。最近のBTSは高機能化が進んでいて、チケットの状態管理、検索、グラフ化、ワークフロー管理、などなど、様々なことができます。その機能はチケット駆動開発に十分なものでした。

そんなチケット駆動開発は現場で生まれました。研究所で生まれたなら、たいそうな概念があって、見た目重視の専用ツールがあったでしょう。でもチケット駆動開発は違います。解決したい問題が先にあり、目の前にあったBTSを使ってやってみたらうまくいった。

その概念もあまり固まっていませんでした。私がここに書いていることも人によっては「ちがう！」と言われるかもしれません。でも、実践したらうまくいった。それが「チケット駆動開発」なのです。

「チケット駆動開発」を育てたのは、技術に対して貪欲で、意欲的な人たちです。いまやアジャイル開発も普通のことになりましたが、数年前までは目新しい概念でした。どの程度役に立つのか、あまりわからない状態でしたが、現場に問題を抱えていた技術者たちはアジャイラーになりました。そして進んで実践し、問題にぶつかり、チケット駆動開発を見出したのです。

私が「チケット駆動開発」に魅力を感じるのは、そんな技術を実践する人たちが育てているからかも知れません。オブジェクト指向も、アジャイル開発も、そんな人たちが育てたから、良いものになりました。きっと「チケット駆動開発」も良いものに育っていくだろうと思っています。

古いThinkpadの青画面

さかば — 2009-06-29T21:39:55+09:00

自宅では調子よく動いていたThinkpad X40を職場に持っていくと青画面が出てリブートを繰り返しました。以前はLANや電源を疑っていました。ふと思いついてメモリーを追加した後は結構安定して動いていました。

しかし、週末に持ち帰って自宅の無線LANを使ってから、会社に持っていくとまた青画面が出ました。結局、BIOSで無線LANを切って安定しましたが、これって何なのでしょうね。

インターネットを検索すると、同じような例がありました。

無線ONでブルースクリーン。
http://blog.goo.ne.jp/pc_sugi/e/36880dc0fb18227a824d0664106c441a

『青画面ﾌﾘｰｽﾞの対処法。』のクチコミ掲示板
http://bbs.kakaku.com/bbs/00200311800/SortID=3741397/

取りあえず無線LANを止めて、CPU省電力動作を「オート」から「しない」にしています。

ソフトウェアタグ：ソフトウェアとレーサびりティの実現を目指した規格

さかば — 2009-06-09T00:42:46+09:00

「ソフトウェアタグ」という言葉をご存知でしょうか？

大阪大学と奈良先端大を中心にした産官学のStagEプロジェクトで進められている研究です。スーパーに行くと様々なもののトレーサビリティが実現されていますが、ソフトウェアはどのように開発されたかわからず、品質は大丈夫なのかよくわからないままに使われているのが実情でしょう。ソフトウェアタグは、ユーザには安心を、開発者にはエビデンスを与えるもので、オフシェアにも応用が期待されています。

6月12日(金)のSEA関西プロセス分科会
では大阪大学の井上克郎先生をはじめ、StagEプロジェクトの皆様をお招きして、エンピリカルソフトウェア工学の基盤であるソフトウェアタグとその事例について、講演していただきます。

当日はソフトウェアタグの規格書を配布していただけるようです。席には余裕がありますが、お早めにお申し込みください。
-----------------------------------------
第38回　SEA関西プロセス分科会のご案内

テーマ

　　ソフトウェアタグの規格とその応用について

講師

井上克郎（大阪大学大学院情報科学研究科教授）
松村知子（奈良先端科学技術大学院大学情報科学研究科STAGEプロジェクト研究員）
角田雅照（奈良先端科学技術大学院大学情報科学研究科特任助教）

主催

ソフトウェア技術者協会関西支部プロセス分科会
　http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/

日時

2009年06月12日(金) 18:30～21:00

会場
　　大阪市立大学文化交流センター
　　〒530-0001　大阪市北区梅田1-2-2-600
　　大阪駅前第２ビル６階　大セミナー室
　　Tel　06-6344-5425　/　Fax　06-6344-5524
　　周辺略地図

内容

　ソフトウェアタグは、ソフトウェア開発過程やプロダクト情報を可視化するためのメトリクス情報の集合で、ソフトウェアの発注者やユーザがソフトウェアシステムを客観的に評価するための手段を提供する。
　本講演では、ソフトウェアタグの規格としてStageプロジェクトでまとめたVer.1について概説し、その応用や適用事例についても説明する。

ご参考：Stageプロジェクト

参加費用

　　SEA正会員：1,000円，SEA賛助会員：1,000円，
　　学生：500円，一般：2,000円

定員
36名

申込方法

以下のページからお申し込みの受付を行っております。
http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/application.html
### 6/10（水）までにお申し込みください ###

　ご注意）
　・受付は先着順で，定員になり次第〆切とさせていただきます．申込受付後のキャンセルは原則としてお断りします．
　・メール，FAXなどWebページ以外からの申し込みは受け付けておりません．
　・お申し込みの受付け後，確認メールが自動的に返送されます．確認メールを印刷し，当日受付時に持参ください．
　・申し込み手続きについて不明点などございましたら，下記までご連絡ください．
　・参加費は当日会場受付にて現金でお支払いください．領収書が必要な方は，申し込み時に「領収書要」にチェックしてください．

世話人：（株）ＳＲＡ　阪井　誠

得正のカレーうどん

さかば — 2009-06-06T23:53:44+09:00

大阪では有名な得正のカレーうどん。いまさらですが、会社の近くの得正で食べました。系列の上等カレーも美味しいのですが、きちんと辛いものの口当たりが甘いので好みが分かれるかもしれません。このカレーうどんは、その甘さがプラスに働いていてとても美味しいです。きつねうどんなども甘いので、うどんと甘いものが合うのかもしれませんね。

カレーが飛ぶのが気になっていたのですが、食事前に焼肉屋のような紙エプロンが渡されますので安心です(と言いつつも私はひざに飛んで失敗しました)。

うどんの上に肉と天カスがのせられ、その上からカレーがかけられ、最後にねぎがトッピングされます。肉も良い感じですが、天カスやネギも良い感じです。カレーうどんだけでもそれなりにボリュームがありましたが、私は白御飯も頼みました。

うどんを中心に一気に食べたので、カレーとご飯だけが残りました。ふと思いついて、カレーをご飯にかけてみると、これが美味しい！少々汁っぽいですが、カレーライスも食べたような気になりました。カレーうどん700円、白御飯100円、十分楽しめました。

Ideapad S9e 新BIOS公開でファン音改善

さかば — 2009-06-06T23:36:31+09:00

気付いたら、新しいBIOSが公開されていました。早速、アップデートしたところ、「ヒュウン、ヒュウン」が「ヒュー、ヒュー」になり、少しましになった様な感じです。

このBIOSの修正項目を見ていると、「えっ」と言うようなものがあります。

(修正) 再起動時に断続的にハングする
(修正) バッテリー LED が青くフラッシュする問題
(修正) 蓋と閉じたときの動作を「なにもしない」に設定時にバックライトがオフにならない問題

などなど、ファン音以外にも色々ありますのでIdeapadユーザは要チェックです。

不況時のプロセス改善 - 脱ノルマ -

さかば — 2009-05-24T20:17:38+09:00

少し前になりますが、TV東京系の経済番組(WBS)で「脱ノルマ」という特集をしていました。不況が迫る中、ノルマを課して売り上げアップを狙っても限界があるので、ノルマをやめて利用者に好まれる販売に徹する様にしてリピータを増やしたというお話でした。これまでならノルマを考えて、推奨品や高額品を進めていたが、お客様に最も喜ばれる商品を勧めることができるようになったというお話でした。

さて、これをソフトウェア開発に当てはめるとどうなるでしょうか？ノルマと言うのはやはり生産性や経済性になるでしょう。そしてその延長の品質向上だと、手戻りが少なくなるような信頼性の向上と言うことになるでしょう。

そして、脱ノルマプロセス改善に当てはめるなら、顧客重視と言うことでしょう。品質＝信頼性ではなく、品質＝顧客満足となるような品質向上が必要なのでしょうね。そこでの問題をなぜなぜ分析してフロントローディングすると、結局は要求を如何に引き出すか、如何に顧客との信頼関係を築いて協力してもらうか、と言うところが改善のポイントになるような気がします。キーワードとしては、プロトタイピング、アジャイルのほか、狩野モデルあたりでしょうか。

Ideapad S9e で　Windows 7 のチェック

さかば — 2009-05-09T15:56:28+09:00

知り合いがDell mini9にWindows 7を入れたそうで、S9eでもWindows 7が動くのか、ちょっと気になっていました。すると、Windows 7が動作するかをチェックしてくれる
Windows 7 Upgrade Advisor Betaなるものが出たとの記事(リンク先はINTERNET Watch)を発見。私のS9eで動かしてみました。

バックアップしろとか動かないプログラムがあるとかは言われますが、システムもデバイスも問題なｼでした。

システムはメモリーも2GBに増設しており、最低限の1GBをクリアしていました。

デバイスは以下のものが確認されました(複数続くときはx2などで表しています)。

Realtek High Definition Audio
Broadcom NetLink (TM) Fast Ethernet
Broadcom 802.11g ネットワークアダプタ
Mobile Intel(R) 945 Express Chipset Family (x2)
Intel(R) 82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller
Intel(R) 82801G (ICH7 Family) USB Universal Host Controller (x4)
Intel(R) 82801G (ICH7 Family) USB2 Enhanced Host Controller
Intel(R) 82801G (ICH7 Family) Ultra ATA Storage Controllers
USB ルートハブ(x2)
USB 複合デバイス
Broadcom 2046 Bluetooth 2.1 USB Dongle
Realtek Card Reader(0158)

プログラムでは、EMONSTER用に導入したActive Syncがだめで、他はアップデートしろとのこと。Windows 7とWindows Mobileの接続が気になるところです。

外部接続機器も繋げてチェックしたほうが良かったのでしょうけど、まあ、何とかなりそうなのでひとまず安心しました。

さて、S9eのその後ですが、最近はファンの音が気になる時があります。常時動いてくれればなれるのですが、状態によっては2-3秒ごとにファンがON/OFFするときがあって、静かに作業しているときは、妙に気になります。

BIOSアップデートで改善されたとの書き込みもあるのですが、今は公開されておらず、しばらく我慢するしかないようです。orz

不具合摘出工数 - SEA関西プロセス分科会 -

さかば — 2009-05-07T23:28:05+09:00

ソフトウェア工学やプロセス改善に大きくかかわるのが、不具合摘出工数です。先日のSEA関西プロセス分科会の秋山先生のTSP/PSPの講演でも話題になりました。

コードレビューなら1欠陥を修正するのに2分ですむが、単体テストなら32分、システムテストなら1405分かかると言うものです。これは、バグを修正する時間だけでなく摘出する、つまりテストの時間を含めてバグ数で割ったものだそうです。

メアリー・ポッメンディーク他,リーンソフトウェア開発,p.82-84, 日経BP社, 2004.のよると、スパイラルモデルやアジャイルと規律で有名なベーム先生が言いだしっぺのようで、リリース後は開発中の100倍だとか5倍だとかの工数がかかると言われているようです。

秋山先生によれば、バグを見つける工数も含むと言われるのですから、テストが進むにつれて、すなわち品質が向上するにつれてバグが見つかる確率が下がる、見つける工数が増えるのは当たり前ですよね。しかも、一度に結合してしまう(ことが多い)ウォータフォール開発では、バグを見つけてから除去するために、問題箇所を突き止めるのも難しくなるのは当然です。

アジャイル開発は、段階的に開発・テストをしますから、バグの入っていそうなところを中心(というか古いところは自動テストされるので発見工数が不要)にテストされるので、常にほぼ同じ確率で発見できるでしょうし、バグが見つかっても追加したコードがおそらく原因でしょうから、バグの除去にかかる時間も安定しているのでしょうね(まあ、アジャイル開発でも、規模が大きくなればそれなりに工数は増えますし、品質保証部門のテストがあれば工数もかかり、デバッグも難しいでしょうけど)。

さて、この後の工程ほどバグの修正にコストがかかるというのは、プロセス改善の基礎になっています。「フロントローディング」などと言う言葉がありますが、後の工程で発覚しないように、前の工程でバグをつぶすような活動です。後工程ほど工数がかかるのだから、早めに見つけるのは当然だし、途中の作業を飛ばすなんて言語道断と言うわけです。実際にテスト工程のどれかを飛ばしてみると、その意味が良くわかります(良い子はまねをしないでね)。

リリース後の品質が悪くて工数がかかって仕方がないなら、プロセス改善のチャンスです。改善結果が利益に直結するので、きっと楽しい活動になると思います。

スパゲティプロセスからの脱却を目指そう

さかば — 2009-04-15T12:00:00+09:00

システムのリプレスは業務プロセス改善のチャンスです。スパゲティのように混乱したプロセスを見直せば、シンプルで効率的なプロセスになり、システム開発・維持費を減らすことも可能でしょう。

システムのリプレスの際に良く出る条件として「現状のシステムと同等機能を有すること」というものがあります。この言葉は、暴走しがちです。現場のユーザに一切の負担をかけることなく、システムを導入する話に摩り替わるからです。

時には、全システムのバグをエミュレートさせられることもあります。苦労してシステムをモデル化しても、現実世界のスパゲティプロセスが足を引っ張ってしまいます。

俗に「2割8割」などとパレートの法則のことを表現しますが、2割の問題が8割の負担を生むことは間々あることです。現実世界を変更しないことでシステムの開発費は膨れ上がってしまいます。

このことは、システム導入の効果も下げてしまいます。現実世界を変えないなら、システム導入の効果は、そのシステムの範囲内に限られます。しかし、現実世界も見直すなら、複雑なプロセスによって膨大になってしまっている人件費を、もっと有意義に使うことができるでしょう。

見直すべきはシステムだけでなく、業務プロセス全体なのです。

クヌース先生の本の選び方

さかば — 2009-04-05T20:53:55+09:00

SEA関西の勉強会でコンピュータサイエンスで有名なクヌース先生の本の選び方を話したら、予想外に評判が良かったのでまとめてみます。

ことのきっかけは、XP祭りでバグなし本の児玉さんが紹介された「コンピュータ科学者がめったに語らないこと」という本です。

この本は、クヌース先生が長期休暇中に行った「3:16プロジェクト」について語られたMITで講演内容が書かれています。「3:16プロジェクト」は、聖書の概要を知るために聖書を構成する各文書の3章16節(3:16と表記される)について、その翻訳や解説をとことん調べるというものです。

まだ、あまり読み進んでいませんので詳しくはかけませんが、コンピュータ科学者が聖書の知識を、人工知能やロボットなどのアイデアとして利用されることがあるようです。そういえば、ユビキタスという言葉も「いたるところに偏在する(神)」という神学用語で、日本ではそれに対抗して「八百万(やおよろず)プロジェクト」という名前の研究プロジェクトもありました。

クヌース先生はルーテル派(プロテスタント運動を最初に起こしたルターの流れを汲む教派、倫理社会で習いました:-)のクリスチャンではありますが、聖書についてのプロではなく、また、聖書は多くの文書で構成されるので、それをすべて知ることができません。そこで、各文書の3章16節を調べて聖書の各文書の傾向や聖書の概要を調べようとされたのです。

この方法は、ランダムサンプリングと呼ばれる方法です。全体を網羅できないときに乱数を用いて部分的に調べて全体像を知る方法です。乱数を聖書に単純に適用すると、ページ数の多い文書によって全体の傾向が決まってしまいます。

そこで、各文書のうち1節だけを抜き出すという方法をとられました。これは層化抽出方式というもので、アンケートなどでも年齢層ごとや地域ごとに一定人数を集めるなどされていますが、それと同じ統計的手法です。

通常なら各文書に乱数を当てはめるのですが、前過ぎる節や後ろ過ぎる節に当たるとその文書の内容を示さなくなってしまいます。そこで、あまり前過ぎず、後ろ過ぎず、多くの文書にあるという理由から3章16節が選ばれました(実は、ヨハネによる福音書の3章16節が非常に有名な言葉なので、そこだけは得ることがあるだろうと選ばれました)。

この方式、実はクヌース先生が実生活で書籍選びに用いられている方法らしいです。書店に行って、面白そうな本があると、その本の100ページを読まれるそうです。あまり前過ぎず、後ろ過ぎない100ページというのは、その本の大まかな傾向を示しているそうです。

たまたまそのページが、見出しだけの意味のないページだったり、100ページない本の場合もありますが、その場合は直前や一定量ずらすということが行われました。3:16プロジェクトでも同じことをされました。

これまで、「目次」や「はじめに」を見て決めることがあったのですが、一度この方法を試してみようと思います。

エンピリカルソフトウェア工学の研究事例

さかば — 2009-03-28T22:06:51+09:00

とあるプライベートショーで講演してきました。共催企業様のページでPDFが公開されていますので、ぜひご覧ください。

「エンピリカルソフトウェア工学の研究事例」

エンピリカルソフトウェア工学は実証的ソフトウェア工学とも呼ばれ、定量的なデータに基づいてソフトウェアの生産性や品質の向上を目指す諸技術です。近年、注目されているエンピリカルソフトウェア工学の研究事例のうち、開発履歴の収集と分析を行う「Empirical Project Monitor」とソフトウェアの開発プロセスや成果物に関する規格である「ソフトウェアタグ」について紹介します。

lenovo ideapad S9e はお買い得！

さかば — 2009-03-19T23:45:13+09:00

【購入】
プライベート用のPCが必要になったのでネットブックを買いました。
MSIあたりを検討していたのですが、ideapad S9eがとにかく安い！少々重いものの6時間もバッテリーが持つのは魅力です。どこで見ても4万円弱＋ポイントでしたがNTT-X storeで現金値引きだったので10％ほど安く買えました。HDDは160GB、メモリーは1GBながらも2GBまで増設できるので言うことなしです。

もっとも気になったのは液晶です。やはり9インチというのは小さいと思ったのですが、店頭で見ると意見が変わりました。他社の10インチ液晶はノングレアでややぼけて見えるのですが、ideapadはグレア(いわゆるピカピカ液晶)なので、はっきり見えます。もちろん、ideapadの10インチ版の方が見やすくて値段もそう変わらないのですが、こちらは縦のドット数がさらに少ないのでパスしました。

【増設】
そのままでも不満はなかったのですが、価格.comの情報にしたがってメモリーを2GB増設しました。購入したのはTranscendのJM800QSU-2G(DDR2 800(PC2-6400) SODIMM　200Pin)をPCワンズで買いました。1,870円で相性保障つきでした。ちなみに元々刺さっていたのはhynix 512MB 1Rx16 PC2-5300S-555-12でした(オンボードの512MBは無視されます)。

今のところ増設予定はありませんが、HDDはSATA2の2.5インチ、厚さ9.5mmのものが入るようです。

【使用感】
インプレスの記事にあるように、ネットブックは十分使い物になります。同程度のCPU能力を持つ古いノートPCと比べてもメモリーとハードディスクが高速・大容量になっている分だけ快適です。特にメモリーを増設してからは、MS Wordもさくさく動くので、文句なしです。

唯一不満なのは、PageUp/PageDownが独立キーとして上のほうにあることです。他のノートPCだと、ファンクションキーとカーソルの上下でPageUp/PageDownになるので、ページのスクロール量を容易に変更できたのですが、PageUp/PageDownキーまで移動するのが面倒です。ideapadでは、タッチパッドの右サイドにある青い線の上を上下にこするとスクロールできるので、それで代用しています。

細かなところでは、タッチパッド下のボタンのクリック音がカチカチと少し気になります。ファンのほうは風きり恩がするものの木になるほどではありません。

あと、便利なのか不便なのかわからないのがVeriFace 認識 IIIというLenovoが独自に開発した顔認識ソフトウェアです。顔を登録しておくと、パスワードを入力しなくてもログオンできます。ただし、照明の状態によってはログオンできないときもあり、VeriFaceの起動を待つ時間や終了させる時間を考えると、照明の状態が悪いところでは顔認識をやめた方が良いかもしれません。

【画面を広く使う】
値段相応として割り切るしかないのが、画面サイズです。縦600ドットはやはり狭いです。そこで、いくつかの工夫をしました。

「タスクバーを自動的に隠す」にチェック

デスクトップのテーマを「クラシック」にする

Webブラウザをgoogle Chromeにする

これで縦方向が少し広くなりました。タイトルバーを狭くすることもできますが、弊害が出るといやなのでやめておきました。

【より見やすく】
アプリケーションによってフォントサイズを大きくしたり、ブラウザではタッチパッドを2本の指で広げると、文字が大きくなるという機能がありますが、Thunderbirdのフォルダやメール一覧の文字は大きくなりません。こちらの「Thunderbird 文字の大きさ」を参考に少し大きくすると使いやすくなりました。

これまでVistaを使っていたのでMSゴシックが気持ち悪くて仕方ありませんでした。メイリオとかIPAフォントを入れてみたのですが、どうも線が細くて気に入らず、ほとんどMSゴシックで使っています。

【その他】
Lenovo Quick Startという機能がついていて、Windowsを立ち上げずにブラウザや音楽再生などを使うことができます。Lenovo Quick Startを最初に動かすと、Linuxのセットアップが始まりました。当たり前ですけど、ちょっと驚きました。

確定申告でふらふら

さかば — 2009-03-05T23:50:49+09:00

去年引っ越したので、生まれて初めての確定申告に行きました。実は子供が生まれた時にチャレンジしたのですが、必要なものを忘れたのと申告コーナーの熱気にやられて避けていました。今年は、住居の譲渡損、住宅ローン控除、株式の譲渡損と3つそろったので初チャレンジしました。

自宅のパソコンでプリントアウトすると便利だとは聞いていたのですが、税務署から送られてきた用紙を見ているとわからないことがありました。たぶん他にも確認したいことが出てくるだろうし、面倒なので必要な書類を持ってとりあえず行きました(これが失敗でした)。

入口で申告内容を告げると、どうも対応が変です。用紙も記入要領も足りないし、封筒は間違っていました。どうも、あまり詳しくない人を動員しているようです。会場の説明要員の方は親切で、わからない時はきちんと確認してくれました。

私は2時頃に行ったのですが、終了時刻の5時近くまでかかってしまいました。まず、全体の構成や記入する順番、さらには用語がわかりません。初めは質問に答えるだけだった説明員さんも、3時を過ぎる頃から手が空きだして、チェックして抜けているところを記入してくれるなど、入れ替わり立ち替わりに積極的に手伝ってくれました。

そして4時を過ぎたころにようやく明細がかけると、今度はパソコンで入力しませんかとのお誘いです。明細も無駄にならないようなので、お願いすると、ほぼすべて入力してくださいました。終了時刻が近付くと、こんなにも親切なんですね。おかげで何とか間に合いました。

一連の作業で気づいたことをあげると、

記入項目が正規化されていない。同じ項目が何度も出てきます。これなら、パソコンの方が絶対有利でしょう
申告会場のパソコンで出力する際はe-TAX端末で、最初に8文字以上のパスワードを決めます。これが画面にそのまま表示され、さらにはIDとともに共用プリンターに出力されます。おおらかなシステムです
記入用紙には書かなくて良いところがある。記入例に書かれているところでも、空白で良いところがあるようです
さらには、計算方法でも適当で良いところがあります。私のように取得費用を建物と土地に計算で分ける場合は登記費用も案分すべきですが、別に良いとのこと
契約書の写し、登記事項説明書、ローン残高、住民票(除表)、源泉徴収票は納めますが、それ以外は計算に必要なだけです。自宅で明細を書いておけばよかったのですね
譲渡した家に何年住んでいたかを証明するために住民票の除表が必要(除表には、移動履歴が載っています。知らなくて普通の住民票を出しましたが、後から提出を求められるかもしれません
明細以外の申請がe-TAXだったので印鑑が要りませんでした。実は、忘れていたのでドキドキしていました
e-TAXで申請した場合は、問題がなければ3週間ぐらいで税金が還付されるらしい。手書きで申告するのは疲れるだけで、メリットがないようです。

ちなみにわからなかったのは、購入住宅が増築されているときに取得価格に影響するかどうかでした。中古で購入していたので建物と土地の区別ながありませんでした。こういう場合は、建物部分の価格を単位面積当たりの基準価格から決めます。しかし、基準価格が新築年と増築年で10倍ほど違ったので、確認したかったのです。結局、購入してからの増築以外は気にしなくて良いとのことで、建物価格はメチャ安になりました。

あと、来年以降に、住宅ローン控除を会社に出して、譲渡損の特例を使う場合、ローン残高はコピーで良いそうです。ローン控除の用紙は自宅に送られてくるので、譲渡損の特例が受けられる間は、コピーしなくて良いので確定申告で両方申告した方が楽かもしれません。

最後に教訓です。立ちっぱなしなので疲れます。明細は自宅で記入すべきです。なるべく手書きは避けましょう。説明員さんは親切でしたが、3時間立ちっぱなしで、帰るときはふらふらでした。

今日は上司から人事異動の連絡もあり、激動の一日でした。

TiDD：チケット駆動によるアジャイル開発法

さかば — 2009-02-14T00:36:18+09:00

3月6-7日にあるソフトウェア信頼性研究会の第5回ワークショップ(申込み締め切りが２月２０日まで延びました)に参加します。良い機会なので、チケット駆動開発(TiDD)についてまとめてみました。

「TiDD：チケット駆動によるアジャイル開発法」(PDF)

文字ばかりのポジションペーパーですが、コメントがいただけるとうれしいです。

必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-

さかば — 2009-02-01T11:36:50+09:00

XP祭り関西2009でもっとも興味深かったのはチケット駆動開発(TiDD)です。関連する発表としては中西さんの「ゼロ機能リリースのもうひとつの側面」とあきぴーさんの「チケットファーストでアジャイル開発！」がありました。

中西さんの発表はサブタイトルが「ワーキングスタイルを変える開発基盤をまず構築しよう」ということで、開発を始める際に機能のない(ゼロ機能)ものをリリースできるようにビルド環境を整えるという「ゼロ機能リリース」で、どのような環境を整えれば良いかというお話でした。

具体的には

Tracなどのチケットを用いて、要求から発生するタスクや、バグの管理をする
構成管理ツールでバージョン管理する
ビルドを自動化する

の3点でした。

まず、1.はチケット駆動開発をしようという意味で、チケットファーストにすることで

無駄が排除できる
コミュニケーションプロセスが改善できる
成果物による進捗管理できる
問題が早期発見できる(問題の大きさではなく滞留時間で管理できる)

という効果を述べられました。

次に、2.の構成管理については、メインラインの開発からリリース(メンテナンス)ラインのブランチをリリースごとに起こしていくことや、機能追加、バグ修正、コードのクリーンアップなどタスクレベルでコミットすること、を話されました。

最後の3.ビルドの自動化では、システムの要のテストであるスモークテストは日中のビルドで行い、細かな回帰テストはナイトリ・ビルドで行う、また、必要にプライベートシステムビルドを行うとのこと。

Q&Aでは、チケットに関する質問がありました。マイルストーンは3カ月程度、チケットはなるべく小さく2時間単位でも良いが、分類する必要がある。管理者が閉じることができるマスターチケットと、各開発者が閉じられるタスクチケットに分類すれば、分類してレポートできるようになるとのこと。

これらの一連の自動化を見ていると、新しいことなのに当たり前のような、凄く良いアイデアのようなのに「そうしなければならない」という印象を受けました。

それは、あきぴーさんの発表で意味がわかったような気がします。あきぴーさんのサブタイトルは「チケットに分割して統治せよ」で、TiDDの歴史、背景と効果、経験を語られました。この中で、「TiDDはWeb2.0のようなもの」と言われました。古い技術を使って新しいことをするという意味で言われていたのですが、これが実はTiDDをよく表していると思います。

上に書いたように、TiDDはある意味「当たり前のことをしていったら、こうなった」という印象があります。でも、何か新しく、開発の苦しみを和らげてくれそうな魅力を感じます。

その意味を考えているうちに、かつて川端さんにお願いしたソフトウェアシンポジウムのチュートリアルを思い出しました。このセミナーはXP入門ということでお願いしたのですが、実際はEclipseの実習が中心でした。これは、少人数でソフトウェア開発に向き合うと、ツールを中心に効率化を図るしかないということを意味しているのだと思います。

TiDD(チケット駆動開発)は、その背景の思想から生まれたものではなく、ツールを用いながらプロセスを改善していったら、必然的にそうなったものだと思います。かつての方法論が、背景の思想を元にツールを開発したために実践する際にやりにくい点が生じたのに対し、実践している中で生まれた方法論は、その体系をきれいにまとめられれば従来にない力を発揮できると思います。

今後、そのあたりをまとめたいと思いました。

プロジェクト型でない開発 - XP祭り関西2009 その２-

さかば — 2009-02-01T01:46:46+09:00

XP祭り関西2009の2番手は土屋さんの「マネジメントから自律へ」でした。

日ごろの開発はプロジェクトとしてやっているが、実はプロジェクトの前提にあっていない、とのこと。確かに、ゴールも明確にではないし、人もゴールに合わせて集めるのではなく、そこにいる人でやっています。そのために、毎回ドメイン知識の学習や、最適解の模索に多くの時間を使っています。

プロジェクトは形式知を元にゴールを目指しますが、プロジェクト型でないので、共通の目標を持つチームが暗黙知で迅速な対応をする方が良い。技術を磨くと言いますが、磨くとは削ることで、それは無駄をなくすこと。アジャイルのライトウェイトとも一致するとのこと。それは、仕事に合わせて人を集めるのでなく、人がいるところに仕事が運ばれてくるようにすることで実現できるようです。

プロセス改善の目的は良い物を早く作ることで、アジャイル開発ではない。PDCAサイクルにアジャイルのプラクティスを取り入れて、短周期で、回せばよいとのこと。アジャイルかウォータフォールかの議論ではなく、実際の問題に合わせて良い物を取り入れることが現実的な改善であると思いました。

ところで、同じ人の所に仕事が来るというモデルですが、これはかなり効果が上がると思います。昔ながらのプロジェクトでは、途中で人をどんどん追加して、製造が終わるとどんどん減らします。これは、大きな負担だと思います。人が入るたびに説明をするのも大変ですし、担当に合わせて最低限の説明をしているつもりが不十分だったり、議論の度に背景の説明が必要になります。せめて、工程単位、できれば早い時期から同じ人間で開発できれば、非常に効率よく開発できると思います。

アジャイル開発は予算とスコープのトレードオフ - XP祭り関西2009 その１-

さかば — 2009-02-01T01:22:29+09:00

ことしのXP祭り関西は、塚口で行われました。キーノートは平鍋さんでAgile2008の報告でした。

まずはAgile UXの話題から。UXはuser experienceの意味で、UIよりも上の概念らしい。ユーザからフィードバックをもらわないと良いユーザインタフェースはできない、とのこと。当たり前といえば当たり前なんですが、アジャイラーからではなくUIの分野で開発法を探したらアジャイルにぶつかったとのこと。会場でUXが実践されている様子が色々と紹介されていました(その一部が平鍋さんの記事に紹介されています)。

また、トヨタ式のカンバンについてもWIP(Work in Process)の観点で説明されていました。WIPにある(つまり開発中の)カンバンの数を制限することで、工程中の物を少なくできるとのこと。これは、いわゆる後工程の引き取り、すなわち使われるものだけを作るということで、アジャイルでいうところのYAGNI(You Aren't Going to Need It )と共通する。さらに鎖のメタファで、後ろから押すと途中で溜まってしまうが、前から引っ張るとスムーズにいくと言われていました。なるほど。

あとは、Dear XPを外人さんと共に英語で歌ったことの報告と、木下さんの飛び入り発表がありました。木下さんは発表だけのつもりだったのに論文を書くことになって急遽書かれたらしい。やりますね。木下さんの発表はいつもながら面白かったです(関西人への期待値が上がりすぎるのではないかとの若干の心配も感じました:-)。木下さんのスライドはslideshareで見ることができます。

色々と興味深い発表でしたが、最も印象深かったのはQ&Aでした。一つ目は日本と海外との違いです。欧米では本などで知っている人が多く、採用は25％ぐらい。ビジネスと作る人との距離が近く、同じリスクをとる、また、コンサルタントも多い。一方、日本は40-50%ぐらいはアジャイルを知っているが、5-10%しか採用しない。これは、ビジネスと作る人の距離が離れているので、ウォーターフォールの方が発注しやすいからだそうです。

二つ目の質問は発表内容と関係なく、たぶん平鍋さんだからこそ出た質問だと思うのですが、アジャイルがうまくいくイメージがわかないので教えてほしい、とのこと。アジャイルは顧客とゴールを一緒に持ち、それぞれの利益の綱引きでなく、運命共同体になっている。作っても使われないものや、うまくいかないものより、コスト削減や新ビジネスなど、うまくいくものを作る。まず、予算と期限を決めて、予算とスコープとのトレードオフで決定していく、との回答でした。

なるほど、と思いました。従来の方法では、スコープが先にあり、無理な予算でも一度決めたら変更せず、ずるずるとリリースが遅れるのでしょうね。

Googleに警告されました:-)

さかば — 2009-02-01T00:15:44+09:00

Googleがおかしくなりました。
何を検索しても

このサイトはコンピュータに損害を与える可能性があります。

と表示されます。試しにこのブログを検索するとこんな感じです。

何を検索しても同じ表示であること、海外でも発生していることから、世界共通で組み込んだサイトチェックプログラムのようなものがあり、何らかの不具合が生じているのでしょうね。

Googleの発表によると、ブラックリストに間違えて「/」を登録してしまって、すべてのURLに一致するようになったみたいです(2/1 11:16追記)。

MZ3.i/MZ4でTwitterする！

さかば — 2009-01-29T20:00:00+09:00

Firefoxでmixiを見ていると、なぜか重くなりました。ローソクが揺らめく広告が原因だと思うのですが、画像を非表示にしてもだめなのでひとまずFirefoxで見ないことにしました。

とはいえ、mixiには仕事関係の知り合いも多く、情報源の一つであるmixiを見ないわけにはいきません。そこで、導入したのがMZ4(リンク先はmixi&Twitter クライアント MZ3.i/MZ4 公式サイト)です。

これは、イーモンスターS11HTで使っているMZ3.iのWindows版です。テキスト中心の表示なので画像の多い記事ならブラウザが便利かもしれませんが、仕事中に見るにはコンパクトですし、(遊んでいるわけではないのですが)目立たないのでなかなか良い感じです。

ちょうどこれを導入したのが同僚の出張中だったので、その状況を確認すべくTwitter(一行ブログのようなもの)も使うことに決めました。 MZ.i3/MZ4ではRSSで誰かのつぶやきを見る事も可能ですが、Twitterをユーザとして利用可能です。具体的には、タイムライン(自分とフォローしている人の書き込みの)表示や書き込み、お気に入り、メッセージのやり取りなどができます。

そこで、急きょIDをとってTwitterユーザの仲間入りをしました。まずは、MZ4のインストール時の確認画面でTwitterにチェックを入れておくと、Twitterのタブができます。ログイン設定でTwitterのIDとパスワードを入れれば、もう準備は完了です(Twitterの細かな設定は Webからします)。

さて、TwitterユーザになったならMZ3.iでも操作したくなるのが人情です。MZ3.iでも設定からIDとパスワードを設定して「完了！」と思ったら、Twitterのタブがありません。そうです。Twitterなんて使わないと思っていたので、インストール時にTwitterにチェックを入れなかったのです。ちょっと焦りました。

MZ3.i/MZ4のタブはユーザがカスタマイズ可能です。それを知っていたので「エディタで編集するのか！」とも思いましたが、「そんなはずはない」と思いなおしました。そして見つけたのが、メニュー->設定->一般->表示にある[タブの初期化]画面です(画面はMZ4です)。このボタンを押すと、インストール時の確認画面が出てきて、Twitterにチェックを入れて[OK]を押すと、Twitterのタブが表示されました(メイン画面の上部ペインで右ボタン(右メニュー)を押して適当なタブに追加する手もあります：1月30日追記)。

いや～便利です。日記もろくに書かない私がTwitterなんてしないと思いましたが、メモ代わりに使い出すと、なかなか良いものです。ちなみに S11HTでMZ3.iを使っているとたまに通信途中で詰まってしまいます(特にニュースとTwitter)。そんな時は右上の[X]を流押しするなどして、いったん終了して再起動すると良いようです。

デスクトップが2個！！

さかば — 2009-01-27T20:00:00+09:00

あるツールをデスクトップにダウンロードして、それをいつもの場所にコピーしたつもりでした。するとなにやらWindows Vistaのデスクトップがおかしくなりました。

デスクトップのショートカットをクリックすると、ツールをコピーしたパス＋Desktop＋ファイル名がありません、などと言われます。そこで、エクスプローラでデスクトップの下のユーザフォルダをクリックすると、「デスクトップ」フォルダが2個もあります。しかも、一方は実行しているコマンド以外のショートカットが無くなってます。

なんか壊れたようです。仕方がないので、昔のデスクトップフォルダらしきものからショートカットなどを移動した後に、昔のデスクトップを削除して再起動しました。デスクトップのショートカットは動くようになりましたが、デスクトップは2個のままです。う～ん。

そこで、気を取り直して検索するとokwaveに良さそうなコメントがありました。これを元に、regeditで

HKEY_CURRENT_USER/Software/Microsoft/Windows/
CurrentVersion/Explorer/User Shell Folders/Desktop

を見ると、ツールをコピーしたフォルダー＋Desktopになっていました。

そこで、これを「%USERPROFILE%\Desktop」に修正してリブートしました。
すると、今度はショートカット移動後の昔のフォルダの内容がデスクトップになりました。ここまでいけばあとは簡単です。後でできたデスクトップフォルダからショートカットを戻してフォルダを削除。再び再起動すると、元の状態になりました。

途中であせってショートカットを移動したのでややこしくなりましたが、それがなければレジストリの修正と新しいデスクトップフォルダの削除だけで良いはずです。実際には識別用にフォルダ名をいったん変えたりしましたが、それもたぶん関係ないはずです(まあ、自己責任ということで、必要に応じてバックアップをお願いします)。

思い起こすと、デスクトップにあるフォルダをコピーしたつもりで、デスクトップそのものをコピーしていたのでしょうね。そのさいにWindowsが属性もコピーして、関連するレジストリも気を利かして修正したのでしょう。GUIは親切なのが売りですけど、そこまで親切にする必要ないし、一言ことわってからフォルダを変更して欲しかったです。

40代もあと3年

さかば — 2009-01-27T12:48:13+09:00

早いもので40代もあと3年になりました。30代の時は定年を考えることはほとんど無かったのですが、40歳を過ぎた時に5年間のプロジェクトに配属されたときに、働ける期間が短くなってきたことに初めて気付きました。

そういえば30過ぎのころ、身体にガタがきて40代の上司にぼやいていたら、その上司に「40過ぎるとそんなもんじゃない」と言われて少々ビビったのを覚えています。しかし、実際に経験すると、まあ脳天気な性格ですのでどうということはありません。30過ぎは「ガクッ」ときて驚きましたが、40過ぎは諦めている中で「じわじわ」と迫る感じですね。まあ、なるようにしかならんという諦めがある分だけ気楽なもんです。

去年の誕生日は「定年まで15年を切った！」と達成感を感じて少し喜んでいたのですが、定年は65まで延長されるとかいう話もあり、今年はそんな喜びがありません。なんか損した気分です。

とは言うものの、家族もお祝いをしてくれたことはうれしかったです。実のところ風邪をひいていたのであまり食欲はありませんでしたが、食事に喜ぶ子供の顔が見れたので良しとしておきます。

最後に、MIXIやGREEでお祝いのメッセージをくださったみなさん、ありがとうございました。まとめてで申し訳ありませんが、お礼を申し上げます。

＃もしかすると、今までで最も日記らしい内容かもしれません。

SQAは最後の砦 - ソフトウェア環境の変化とSQA -

さかば — 2009-01-20T22:41:12+09:00

ソフトウェア技術者協会に品質保証分科会(SEA-SIGSQA)が発足するのを記念して、2月6-7日にSEA ソフトウェア品質保証ワークショップが開かれます。テーマは「ＳＱＡは時代の変化と今の要請に対応できているか？」ということで、私も参加することにしました。

私のポジションペーパを載せておきます。感想などをいただけるとうれしいです。

SQAは最後の砦 - ソフトウェア環境の変化とSQA -

１．概要

ソフトウェアを取り巻く環境は大きく変わり、新しい技術やプロセスへの支援への要望が大きくなる反面、新しい技術やプロセスの変化によって、関与できる支援が限られてきている。本ポジションペーパーでは、ソフトウェア環境の変化とSQAの位置づけを整理し、今後のSQAの在り方について考察した。また、考察の結果を元にインタビューを行い、SQAは最後の砦として最低限の品質を守りつつ、開発部隊の自律的な品質活動を支援する事が望ましいと思われた。

２．ソフトウェアを取り巻く環境の変化

SQAに関する議論では、低コストと短納期、さらに、ほどほどの品質がSQAの活動を困難にしているとされている。これは近年のソフトウェア開発の特徴であるが、その背景に90年代から始まったダウンサイジングの流れが、大きく影響していると考えられる[4]。

PC等を用いたダウンサイジングのシステムでは、小規模な組織での開発が多く組織的な品質向上策が困難である[1]、最新技術に対する経験が少ない、自由度が高いので仕様の決定が困難であるという特徴がある。また、従来のソフトウェア開発において重要視される品質特性は主に信頼性であったが、90年代以降の開発では使用性や機能性など従来よりも多くの品質特性を考慮しなければならなくなった。

このような環境の変化の中で、ソフトウェア開発は以下のように変化してきた。

実装重視
ユーザによる判断の優先
工程の不明確化

新しい技術を利用する目的や、自由度が高い中で様々な品質特性を満たす仕様を決定する目的で、早期にプロトタイプを作成したり、アジャイル手法を用いた実装重視の開発が増えている。また、企業責任としての最低限の品質保証を除いては、ユーザとの合意に基づく品質判断も増えてきており、ユーザによる判断を優先する傾向がある。さらにこれらの影響で仕様がなかなか確定しないなど、工程の境界が不明確になっている。次の工程の作業を許さないことが現実的でなくなり、ウォーターフォールモデルと言いつつも柔軟な開発が増えている。

このような傾向は、開発中にSQAが関与する機会を奪いがちである。具体的には

現場はより具体的な技術問題の解決を期待している
ユーザが認めればそれで良いという風潮
工程会議などで支援する機会の減少

ということがあり、近年はさらに

低コスト
短納期

のプレッシャーから

ほどほどの品質で良い

という風潮も生まれ、SQAは軽視されがちである。また、景気後退局面に入った事から、ユーザは「新技術の育成から、これまでの投資の刈り取り[3]」に向かっており、ユーザのコスト低減圧力はさらに強くなると思われる。

３．開発部隊が求めている支援とSQAの特徴

新技術や新しい品質特性への対応が求められているが、対応しなければいけない情報が増えるにつれて、従来のようにあらかじめ準備しておくことが困難になっている。網羅的な技術を得ることが困難な現実を考えると、必要に応じて学習する方が効率的である(Learning on demand[2])と考えられる。そこで、開発部隊が支援組織に求めるのは、

具体的でインタラクティブな支援
観点、戦略といった抽象度の高い支援

の2種類であると思われる。

ここでSQAの特徴を考えると、「第三者」であること、そして「プロジェクト横断的」であることの2点である。第三者であることで、出荷時の検査を客観的に、ユーザ目線で行うことができる。また、プロジェクト横断的な組織なので、組織的な支援や教育を行うことができるのである。

しかし、開発部隊が求めているものは、現状のSQAの活動とは若干異なる。具体的でインタラクティブな支援をSQAが直接行うとすると、担当者の負担が大きくなりすぎると考えられる。仮に支援を行うなら、文献[4]の作業報告書を元にした経験データベースのように、ツールを中心とした支援が現実的であると思われる。また、支援する内容は生産技術の支援が多いと思われるので、SQAが担当すべきでないかもしれない。一方、抽象度の高い支援を行うのであれば、組織の戦略を担うPMOが担当することも可能である。

以上のことから考えると、SQAという組織を残すのであれば、第三者としての検査が必要であるかどうかを検討する必要がある。これは、特に開発部隊からは求められていないように思われるが、実際にSQAの現実を知る必要がある。

４．SQA経験者へのインタビュー

そこで、SQA経験者に上記の考察を踏まえてインタビューを行った。その結果、

SQAとそれ以外の境界はあいまいなので、なくそうと思えばなくせる
当たり前のことができていないので、SQAの必要性はある
逆にSQAがなくなった方が、自分たちで品質向上ができるようになる気もする

というコメントが得られた。このコメントから考察すると、すでにSQAが存在する組織においては、SQAの存在が当たり前になっている。このため、ある日突然にSQAをなくすことは企業の信用を落としかねない。SQAをなくすのではなく、SQAに依存しない自律的な開発組織になる事が重要だと思われる。その上で、最低限の品質確保をすることが望ましい。

このことは、ほどほど品質の実現とも整合性がとれる。ユーザが求めるほどほどの品質とは、小さな問題はあるものの致命的なトラブルのない品質である。そのような品質を検査だけで実現することは困難であり、致命的な問題が入りこまないように作りこまなければならない。そのためには開発者のスキルアップが重要である。

５．まとめ

SQAには多くの仕事があり、ソフトウェア環境の変化を考慮すると他の部門に移管するべきものもある。しかし、企業の信用を守る最後の砦として、最低限の品質を確保することはSQA以外にはできないことである。ほどほどの品質を実現するには、致命的なエラーを埋め込まないような教育をするなど、開発部隊のスキルアップのほか、SQAによる最低限の品質保証が重要である。

[1] J. G. Brodman and D. L. Johnson, "What small businesses and small organizations say about CMM", In Proc. of the 16th ICSE, pp. 331-340, 1994.

[2] Fischer, G., "User Modeling in Human-Computer Interaction," User Modeling and User-Adapted Interaction (UMUAI), Dordrecht, The Netherlands: Kluwer Academic Publishers, 11(2), pp. 65-86, http://l3d.cs.colorado.edu/~gerhard/papers/umuai2000.pdf, http://swiki.cs.colorado.edu:3232/dlc-2004/uploads/um-lod-hfas-march8.pdf, 2001.

[3] 垣内郁栄, フラット化するIT予算, http://www.atmarkit.co.jp/news/200901/15/gartner.html, @IT.

[4] 阪井誠，松本健一，鳥居宏次, "ダウンサイジング時代のプロセス改善モデル", ソフトウェアシンポジウム'95論文集，pp.131-140, 1995．

謝辞：

ポジションペーパ作成にあたり、議論に参加してくださったTさんに感謝します。

「ナムコ通信事業部」さんからお手紙ついた♪

さかば — 2008-12-04T20:00:00+09:00

さかばさんたら読まずに捨てた
しかたがないのでブログに書いた
「さっきの手紙のご用はなあに？」

「ナムコ通信事業部」で検索するといろいろ出てきます。アダルト系の架空請求はメールも電話も受けたことがありますが、ゲーム会社と紛らわしいものは初めてでした。

「本日の弊社営業時間内迄にご連絡の無い場合」などと書いているので、使い捨て番号を使った知能犯かと思いましたが、連絡先の電話番号はWebに出ているものと同じでした。同報メールの規制が厳しくなったので、薄利多売を狙っているのでしょうか？

赤霧島

さかば — 2008-12-01T20:00:00+09:00

去年知った「赤霧島」。霧島というとどこにでもある焼酎だと思っていましたが、この「赤霧島」はいけます！ロックやストレートでもいけますが、やさしい水で割ってやると、まろやかさが増して最高です。

何でも紫芋で作られていて限定生産、幻の焼酎だそうです。楽天で見るとすでに2千円以上のものしかないようですが、安く入れば何本でも欲しいところです。私の場合、行きつけのディスカウンターのレジに予約受付の案内があり、7本だけ入荷でそれ以上の予約があれば抽選とされていましたが、運よく1,200円ほどで一本入手できました。

教えて！gooによると、蔵元に聞くとか、百貨店が穴場などと書かれています。案外、近くの酒屋さんにもあるかもしれません。

ネットワークに距離はない

さかば — 2008-11-30T01:01:26+09:00

ネットワークはドラえもんの「どこでもドア」のように、距離を感じさせずに通信をすることができます。しかし、それは従来のコミュニケーションとは、大きく異なるものです。距離がないことに気をつけなければなりません。

従来から、メールなどの電子媒体を介すると感情が強く表れるとか、誤解を与えやすい、などと言われています。これらは、表現に気をつけるとか、用件のまとめを最初に書く、引用を多用しない、といったことで対応できるでしょう。

しかし、最近はmixiやGREEといったSNSが普及するにつれて、別の問題が発生しています。SNSでは日記、メール、コミュニティなどの情報交換が可能で、友人、友人の友人などの関係によって、日記の交換範囲を決めることなどができます。

そんな仲良くする仕組みが色々とある反面、相手と距離をとる方法は「アクセス禁止」だけしかありません。ある人をアクセス禁止にすると、その人に日記が読まれなくなるほか、その人からはメールを出せなくなりますので、いわば、絶交の状態になります。

合理的な仕組みかもしれませんが、これだけしかないということから混乱の元になります。通常の人間関係は、親友、友人、知り合い、など、いろいろな距離があります。また、その距離も単純な一次元ではなく、仕事、趣味、同郷、など色々な分野への広がりがあります。それを友人(および友人の友人)、一般、アクセス禁止、という3つの距離だけを定めていることから、問題が生じるのです。

どこかのコミュニティで知り合って軽い気持ちで友人になると、大変なことになります。その人は親友になろうとしているかもしれません。はじめは日記を見られても良いと思っても、自分とは異なる価値観で「良かれ」と思って色々書かれると、わずらわしくなります。はじめは無視していても、相手は親友になろうと執拗にコメントしたり、メールをしてきますので、いやになってしまいます。そして、距離を置いてくれるように頼むと、善意で書いているのにと怒られることもあるでしょう。

そこで、最後の手段としてアクセス禁止をせざるとえなくなります。それで終われば良いのですが、たまにこじれることがあります。アクセス禁止にする人は、距離を置きたいだけで、その人が嫌いと言うほどではないのかもしれません。しかし、アクセス禁止にされた人は、全人格を否定されたような気がするのか、共通のコミュニティで個人攻撃が始まることもあります。

もうできるのは耐えることだけです。耐えられなくてアクセス禁止にしたのに、アクセス禁止に効果がなかったことになります。仕方なしにSNSを退会して入り直す人もいます。そうなると、他の人間関係を一旦リセットすることになります。

日記を友人にのみ公開している場合を考えましたが、日記をすべての人に公開している場合は、友人でなくても同じ問題が生じます。恐ろしいことです。

このような混乱は、現実世界ではあまりありません。うまが合わない人には近づかないでしょうから、問題が生じないのです。ある程度の付き合いは許容する場合、たとえば仕事上だけの付き合いなら、「ちょっとプライベートな用事がある」と言うだけで、それなりの距離を置くことができるのです。

しかし、ネットワークには距離がありません。メールを出せばほぼ間違いなく届きますし、人前で行う行為は誰にでも見えます。誤解や行き違い、わずらわしさやストレスも、直接あなたに向かってくるのです。ネットワークに距離がないことを意識して行動しないと、次にトラブルに合うのはあなたかもしれません。

＃メールが来ても、コメントされても無視するという仕組みがあれば、ある程度の距離がとれるのではないでしょうか。SNS開発者の皆さん、いかがでしょうか？

祝！JR桂川駅開業

さかば — 2008-10-25T22:30:54+09:00

以前、名前のない駅として紹介したJR桂川駅(リンク先はWikipedia)が開業しました。
個人的には、もう少し桂川に近い所にできるとありがたかったのですが、キリンビールの敷地の再開発が可能なことや、駅のすこし桂川寄りから貨物線が在来線の外側から東側にならぶのでコスト的に有利、洛西口を介して洛西ニュータウンに交通機関を整備できるなど、諸条件からここしかなかったのでしょうね。

駅の東側と西側(正面)に駐輪場があるほか、正面にはバス・タクシー乗り場が整備されています。バス路線も整備され、洛西方面、南区方面、そして少ない本数ながら下津林から阪急桂駅経由で地下鉄太秦天神川駅にも通るようになりました。

あと、特筆すべきはJRの線路と自衛隊の間に歩行者・自転車専用道ができました。この道のお陰で、桂高校東側の周辺だと桂駅よりも桂川駅が近くなったと思います。桂駅東側の自宅からも歩いて行けなくはないようです。

ソフトウェアさかば

[TiDD] 計画できないことの管理と計画できることの管理

玉の光 山廃

[TiDD] チケットの粒度に気をつける

[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する-

[TiDD] チケット駆動開発は見える化でもある

[TiDD] チケット駆動開発の最初の一歩

[TiDD] チケット駆動開発はじめました

[TiDD] BTSによるコミュニケーションの効率化

[TiDD] 小規模開発の難しさを考える

[TiDD] プラクティスから方法論へ

[TiDD] チケット駆動開発によるフロントローディング

[TiDD]チケット駆動開発と見える化

[TiDD] チケット駆動開発とXPの共通点

ひかりTV： PC-STB4の熱暴走=PM700に交換

TiDD：チケット駆動開発

古いThinkpadの青画面

ソフトウェアタグ：ソフトウェアとレーサびりティの実現を目指した規格

得正のカレーうどん

Ideapad S9e 新BIOS公開でファン音改善

不況時のプロセス改善 - 脱ノルマ -

Ideapad S9e で Windows 7 のチェック

不具合摘出工数 - SEA関西プロセス分科会 -

スパゲティプロセスからの脱却を目指そう

クヌース先生の本の選び方

エンピリカルソフトウェア工学の研究事例

lenovo ideapad S9e はお買い得！

確定申告でふらふら

TiDD：チケット駆動によるアジャイル開発法

必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-

プロジェクト型でない開発 - XP祭り関西2009 その２-

アジャイル開発は予算とスコープのトレードオフ - XP祭り関西2009 その１-

Googleに警告されました:-)

MZ3.i/MZ4でTwitterする！

デスクトップが2個！！

40代もあと3年

SQAは最後の砦 - ソフトウェア環境の変化とSQA -

「ナムコ通信事業部」さんからお手紙ついた♪

赤霧島

ネットワークに距離はない

祝！JR桂川駅開業

玉の光山廃

ひかりTV：　PC-STB4の熱暴走=PM700に交換

Ideapad S9e で　Windows 7 のチェック