富士通の島田さんによるパッケージソフトウェア開発におけるアジャイル開発の取り組みについて紹介がありました。ここで開発しているパッケージは大学・教育向け統合業務パッケージ(たぶん Campusmate)とのことです。各バージョンのパッケージ開発は半年から2年、Javaを使っていて新パッケージ開発に取り組むときはほぼ全面作り直しているそうです。

チームは18名から24名、サブチームが3つで平均年齢は27.8歳。富士通という会社を思うとかなり若いのではないかと思います。開発チーム以外に顧客プロキシチームがいて、社内他部署・営業・顧客からの声を吸い上げてまとめ、パッケージの仕様を決定する権限があるチームがあるそうです。

アジャイルの取り組みは社内で 平鍋さんの講演を聞いてから、これならできるかもと思ったのがきっかけ。アジャイルに取り組む理由としては主に4つ。

• 最高の製品を作りたい
• チーム内にスキル保有者を育てたい
• チーム力(結束力?)を高めたい
• そして何より楽しくやりたい。

開発の基本単位となるイテレーションは2週間単位。

• 1イテレーションが2週間
• 3イテレーションごとに内部リリース
• 7イテレーションで正式リリース

という基準がある模様。ただし開発の段階でイテレーション内で注力する内容はばらつきがあるらしい(序盤は設計、後半はテスト中心とか)。

タスクは1タスクを1人日程度に分割している。Excelで管理していて自動でタスクカードを印刷するような工夫も取り入れている。イテレーション中のタスク入れ替えは原則として行わない。タスクはソフトウェア看板を使って見える化を実践。完了前には必ずレビューが入るようにしている。

朝会は毎日行う。司会者は持ち回りで3分間スピーチもあり。昨日やったことや今日やることを各自が報告する(Martin Fowler’s Bliki in Japanese – 朝会のパターン：立ってるだけじゃないよ)。

面白い取り組みとして “ちょっと気になること” がある。文字通り気になったことをホワイトボードに付箋で貼り付けるようにしている。内容は毎日の朝会で確認する。これにより仕様上の矛盾や障害の予兆を早めに気づくことができる。

見える化は大事、でも見えてるだけにならないようにしないといけない。例えばタスクの完了を バーンダウン・チャートで見ているが、アジャイル開発に取り組み始めたばかりは目標の未達成が数イテレーション続いた。これはバーンダウン・チャートを使っていてもタスクが未達成になりそうな進捗が見ていただけで、実際の対策を何も行わなかっただけ。見える化とはいっても、基本はPDCAなので対策が重要。Checkに入るタイミングをアジャイルで支援しているイメージ。

最後に富士通が考えるアジャイル開発のポイントをおさらい。

• 形式的なものは意味が無い。
• 定期的な振り返りから。
• イテレーションは短く、タスクは細かく。
• ストーリーの優先順位が重要
• 自ら実践すること。

Joelさんを考慮に入れなければ、文句なしベストスピーカー賞だと思います。勉強になることが多かった発表でした。

CodeZine：Developers Summit 2008 – デブサミ2008でJoel Spolskyさんが行った講演のメモです。内容は”Great Software”をいかにして作るか、Joelが考える法則についてです。

最初に人物や製品の比較をするJoel。世の中には多数の人・製品があるけど一位と二位以下では大きな差がある。

David Beckam >Landon Donovan
iPod > Zune
ハーマンミラーの椅子 > ハーマンミラーのデザインを模した椅子

優れた一位の製品(Blue Chip)と二位以下の製品(Offbrand)を分けるものは何か、Joelが考える法則は以下の3点からなる。

1. 人を幸せにする
2. 感情を考慮する
3. 美学にこだわる

1.人を幸せにする
ペットの写真をブログにアップロードするにも

Windowsを起動して
→起動したらパッチを当てろという
→Windowsが再起動を促す
→再起動したらようやくデジカメをつなげた
→今度はドライバのインストールが必要だって?
・・・

といった具合で、たかだか写真をアップロードするだけで管理者の作業をしなくてはいけない。しかもユーザに支配権が無い。ユーザに支配権を与えないと失敗したときに学習性無力感を与え、ユーザのやる気をそいでしまう。

この悪循環を抜けるためにはユーザに主導権を与えればよいとJoelはいう。例としてあげていたのはショッピングサイトの購入手順。多くのサイトでは注文個数の確認、届け先、支払方法を順に入力させるがAmazonは1つの画面にまとめ、ユーザが好きな順序で操作できるようにしている。 他にAjaxなどを用いて操作に対するフィードバックを瞬間的(1秒ではなく０秒で!)に与えることも有効である。

2.感情を考慮する
理屈・理論ではなくて人の心理を考えることも時には大事。

例としてあげていたのはSUV車の販売方法について。SUVは車高が高く、他の車と比較して不安定である。そんなSUVを安全な車として販売するにはどうしたらよいか? 答えは車高を高くすること。理論では車高が高いと不安定になるが、人の深層心理は高いところにいると安心を感じるようになっている。他にもやわらかみがあると安心するとか、温かみがあると安心するとか、カップホルダーがあると安心するとか・・・

WindowsのUIが2000からXPに変わったときに丸みを帯びたデザインになったけど、これもユーザの深層心理に安全性をアピールしているのかもね。

3.美学にこだわる
Joelは携帯電話にサムスンのBlackJackを使っているけど、去年話題になったのはやっぱりiPhone。機能的な優劣は置いておいて、一番の違いは電池の交換方法。iPhoneは継ぎ目の無い美しいデザインを実現するために電池も交換できない製品にした。

モダンアーキテクチャ(現代の建築の流行?)では無駄なものは排除したほうがいいということで四角い形をした建物が多数建てられている。でもソフトウェアの世界では無駄を排除したUNIXのシェルのようなUIよりもMac OS Xのような見た目が派手なものが好まれている。ソフトウェアの世界はまだ無駄を含むものが好まれているようだ。

最後にこれだけは覚えて帰って欲しいと“Misattribution”という単語を紹介。原因は違ったところにあるんだけど効果を与えているという意味の言葉。例えばプレゼンの見た目が悪いと内容とは違ったところでケチがつくことはよくあること とか。

Joelさんの講演は終始笑いが絶えず、好評のうちに終了しました。ここまで書いて気がついたのですがIT Proにも記事があがっていますね。こっちのほうが講演の内容が細かく書いてあったかも・・・あわせて読むと講演を聞けなかった方も内容がよくわかるのではないかと思います。

• 「Joel on Software」の筆者が語る“人を幸せにする”ソフト開発のポイント：ITpro
• すばらしいソフトを作るには、カリスマが講演 － ＠IT

P.S.
会場でBEST SOFTWARE WRITINGが先行発売されていて、購入者にサインサービスがありました。自分も購入 & サインしてもらいました。