プログラミング C# - 翔ソフトウェア (Sho's)

上記に参加してきたので、レポートしてみたい。

■ 詳細

■ 参加目的

• オブジェクト指向を現実的に実践する方法を知る
• オブジェクト指向実践者と交流を持ち知恵を得る

■ はじめに

当日の朝。
北陸自動車道から小松空港に向かい、始発の羽田行きに乗って会場に向かった。
計算では、どんなに急いでも開始10:00には間に合わない。10:15 頃の到着になる予定であった。

新宿駅までは完璧に予定通りに乗り継ぎ。
余計なロス時間はゼロ。飛行機の座席の位置から電車の何両目に乗るかの選択まで、我ながら完璧に近かったと思う。

ところが、小田急新宿駅の改札口に着いてみると、全ての券売機が止まっている。
小田急になんらかのトラブルが発生した様子であった。
ここで10秒ばかり躊躇(ちゅうちょ)。タクシーで会場へ向かうことにした。

結局、予定通り 10:15 ちょうどに会場に入ることができた。
ところが、着いてみると、小田急が動いていなかったことで、15分遅れで開始とのこと。 奇跡的に間に合ってしまった。

サンタ帽をかぶったスタッフが迎えてくれた。
会場は既に人で一杯。
なんでも 170 名以上の参加者だとか。毎回少しずつ大きくなっているそうだ。

・会場の入り口付近。後述する XFD が妖しげに光を放つ。

■ 参加内容

○ コンセプト紹介等

初めにスタッフである安井 力 氏から「見える化」というコンセプトの紹介があった。
「見える化」とはどういうことか。その意味するところを、水に色を付けたりする実演で「見る」ことができた。

○ 基調講演 平鍋 健児 氏
『リーンソフトウェア開発と「見える化」』

・平鍋 氏 による基調講演の様子。

基調講演は、主催者であるオブジェクト倶楽部の主宰者である平鍋 氏。

先ずは、リーンソフトウェア開発について。

トヨタのかんばん方式をはじめとする「リーン生産方式」の短い紹介があった。

そしていよいよ「見える化」の紹介。

• ソフトウェア開発は「不可視」・「intangible」な部分が多い。
• 見えないことによる難しさがある。
• 見えなければ制御も改善もできない。
• 見える工夫をすることで、開発が判り易くなる。
• 見えるようにしよう。

「見える化」を行った実際の例が、いくつも写真で紹介された。

例えば、「ソフトウェアかんばん」。

ホワイトボードを「Todo (未実施)」・「Doing (実施中)」・「Done (テスト完了)」の三つの領域に分けてある。そのそれぞれに、色分けされ作業が書かれたポストイットが貼られている。

現在のプロジェクトの状況が一目でわかるようになっている。
この前で毎日「朝会」をするそうだ。

紹介された「例えばこんな風にやってみたら良いのではないか」という「見える化」を表にまとめてみる。

これは導入しやすく強力なやり方ではないだろうか。
持ち帰って提案してみたいと感じた。

○ 主賓講演 大槻 繁 氏
『アジャイル開発とインタンジブル・アセット ―伝統的開発へのインパクト―』

アジャイル開発が伝統的な開発方法に与えるインパクトの話。

特に考えさせられたのは、「組織のモジュール化」の話。

• 各モジュール内の知識は、インタンジブル (見えない)。
• モジュール間のインタフェイスはタンジブル (見える)。

「見えない知識をどう貯めていくか」が重要とのこと。

○ ワークショップ 平澤 章 氏
『「モデリング道場」ライブ ～要求モデリングの過程 見せます!』

もう、なんというか、ライブ最高。

題材は、「八百屋の POS (Point Of Sales) システム」。
顧客役である天野 勝 氏にヒアリングしながら、ライブでモデリングしていく。

「コミュニケーション芸人」を自称する平澤 氏 と 天野 氏の掛け合いは、テンポといい間(ま)といい、感動的ですらあった。
さらに、時々絶妙なタイミングで平鍋 氏が質問を入れる。

二時間のライブが一時間くらいに思えたくらい、楽しむことができた。
本や Web を読むより、はるかに判り易い。
まさに「見せる」方法によって、全然判り易さが違ってくるという例だ。
こんなセミナーは初めて。是非もう一度体験したいものだ。

平澤 氏によると、モデリングには「機能先行型モデリング」と「モデル先行型モデリング」があるとのことで、今回は「モデル先行型モデリング」。

解説していただいたモデリングのポイントを少しあげてみる。

• そのクラスが表しているものが、「現物(ブツ)」なのか「種類」なのかをはっきりさせる
• ヒアリングしながら、システムに関係のないものをはじいていく。
• 名前を付けるときは、視点を固定。店側からの視点で命名。
• クラスでなくインスタンスの単位をとらえる。多重度で確認。
• ノート アイコンが重要。ノートアイコンは種類によって色分け。
• クラス図はつながりだけでなく、「形」も重要。

・「掛け合い」でばんばんクラス図が描かれていく。

・ライブでホワイトボードに手描きされていったクラス図。これと並行して リアルタイムで UMLツール "Jude" による清書も行われていた。

○ 見える化ライトニングトークス

一人持ち時間五分。延長なし。五分過ぎると容赦なく銅鑼(どら)が鳴る。

・XFD ネタは、最高の盛り上がりをみせた。

私も、「TDDPlayer」というネタで参加。

• 「『TDDPlayer』 ~テスト駆動開発ってどうよ~」 資料 (PDF)
• TDDPlayer Demo ムービー (WMV)

※ 尚、講演やライトニングトークスの資料は、オブジェクト倶楽部のサイトで公開されている。

○ 懇親会～二次会

懇親会に只で出させていただいた上、本まで頂いた。
『はじめてのアジャイル開発』、『PM magazine 第1号』の二冊。

懇親会では、皆が参加して、今回のイベントに関して「ふりかえり」を実際に行った。
私も、「Keep (良かったこと、続けていくこと)」と「Problem (問題点)」、「Try (次回挑戦すること)」をポストイットに書いて、八枚くらいを模造紙に貼った。

懇親会及び二次会では、沢山の知人と話し、新しい知人と話した。

■ 「見える化」について考えたこと

最後に、今回このイベントに参加して、「見える化」について考えたことをいくつか。

○ プロジェクトの見える化

例えば、プロジェクトの状況を知らせる方法として、以下の三つを比較してみたい。

1. プロジェクトの状況については、プロジェクトの構成員からプロジェクト マネージャに定期的に報告が行く。
   状況を知りたい人は、プロジェクト マネージャに尋ねれば知ることが出来る。
2. プロジェクトの状況は、プロジェクトの構成員によってオープンな会議室に逐一アップされる。
   状況を知りたい人は、会議室を見に行けば、知ることが出来る。
3. プロジェクトの状況は、部屋の入り口付近に貼り出してある。
   出社する人はいやでも目にすることになる。

3 のやり方が、「見える化」を取り入れた例といえる。

今回の基調講演で、平鍋 氏 が次のように言っていた。

・エラーの与える影響の大きさ = エラーの大きさ×エラーの滞在時間

上の例で言うと、1 より 2、2 より 3 の方法が、エラーの滞在時間を短くすることができるのでベター、ということになる。

○ 見せ方

見せるにしても、なるべく「わかりやすく」見せることが重要なようだ。
シンプルなグラフを使ったり、直接手書きして壁に貼ったり、色分けしたり、動きや光、音を取り入れて五感に訴えるようにしたり、等等。
見せる工夫が重要だ。
それから「バーンダウンチャート」や「ペアボード」のように、ネーミングが重要。

○ 「見える化」と XP

この「見える化」というのは、アジャイル開発手法の一つである「XP (エクストリーム プログラミング)」の精神とも一致していると思った。

図にしてみると、こんな感じだろうか。

■ 関連リンク

• @IT ― ソフト開発は目に見えないから難しい、オブジェクト倶楽部
• オブラブクリコン20041209 - オブジェクト指向実践者の集い(第3弾)
• CoffeeDiary ― オブラブクリコン行ってきた
• 清水川記 ― オブジェクト指向実践者の集い

前々回、前回の様子はこちら。

• クリスマス企画 オブジェクト指向実践者の集い ～オブジェクト倶楽部が街にやってくる～ (2003/12/16)
• 納涼イベント オブジェクト指向実践者の集い 第二弾 ～本当にあった怖い話～本頁内 (2004/07/09)