Skip to content.

Sections
Personal tools
You are here: Home » イベント » 第3弾2004Xmas » 目黒さん参加レポート

Document Actions
クリスマス企画・オブジェクト指向実践者の集い
参加レポート


メールでレポートをいただきましたので、こちらに掲載させていただきます。

マテリアル・システム・サービス株式会社 目黒秀峰 さん

1.カンファレンスのテーマ

今回のカンファレンスのテーマは、「ソフトウェア開発の見える化」です。
ソフトウェアというものは、具体的な存在を持たないために実体を捉えづらいものです。構造・品質・耐久性・安全性など、ハードウェアであれば把握することが比較的容易な情報であっても、ソフトウェアでは評価をしにくい、ということもあります。そのためにソフトウェアの開発には特有の困難が伴います。
また、(ソフトウェア分野に限らず)開発の進捗を計測したり予測したりすることには、常に不確実性や予測困難な部分が存在します。
そこで、ソフトウェアそのものやソフトウェア開発における不可視な部分をどうやって「見える化」するのか、そしてどのようにソフトウェア開発をしたら良いのかということが問題になります。
この問題を考えるのが今回のカンファレンスのテーマです。

2.カンファレンスの様子

年の瀬も迫る12月9日、オブジェクト倶楽部主催のカンファレンスが開催されました。
天気にも恵まれた当日、開催場所は新宿駅から小田急線でふた駅と、交通の便も良いはずだったのですが、その小田急線で列車事故が発生。動かなくなってしまいました。そのために遅刻者続出で、講師の方も時間通りに到着できなかったとか…。小田急線許すまじ。
そんな中でもスタッフの皆さんは終始にこやかに対応されていました。私は新宿駅から小田急線に乗れず、かなり焦ってしまったのですが、電話口で丁寧な対応をしてくださったスタッフの方のおかげで落ち着きを取り戻すことができました。感謝です。
会場に到着したときには(当然遅刻です)すでにたくさんの参加者が集まっていました。講演が始まる前から皆さん真剣な表情で、カンファレンスに対する関心の高さが伺えました。平日にもかかわらず大勢の参加者で、最終的には170名以上の方が参加されたそうです。
今回のカンファレンスはクリスマス企画ということで、会場はクリスマスの雰囲気に溢れていました。トナカイはいませんでしたが(実はどこかにいたのでしょうか?)、クリスマスツリーあり、サンタクロースの帽子あり。終始とても和やかな雰囲気でした。スタッフの皆さんの心遣いを感じます。
カンファレンスは、基調講演(平鍋健児氏)、主賓講演(大槻繁氏)、それから昼食をはさんでワークショップ(安井昌男氏、椿景子氏、原田洋子氏、平澤章氏 順不同)とライトニングトークス、という流れで進みました。充実した内容だったのですが、やはり最大の問題点は、4つのワークショップのうちの1つしか参加できないことでしょう。全部見たかった!と思ったのは私だけではなかったと思います。この点、次回のイベントではなんとかならないものでしょうか。
全体を通して、とてもいい雰囲気のイベントだったと思います。スタッフの皆さんの陰ながらのご苦労の賜物だと思います。本当にお疲れ様でした。

3.内容

カンファレンスの内容については、すでにたくさんの方がすばらしいレポートを書かれているので、私は、本筋から少し外れて、カンファレンスの中で興味深かったトピックをふたつ紹介したいと思います。

その1・豪邸の引越しというたとえ話(基調講演:平鍋健児氏)
30もの部屋がある豪邸の引越しをするというお話です。ウォータフォール型で作業をする場合と、アジャイルな作業をする場合に、どんな違いがでるのか?

30部屋もある豪邸の引越しをするとします。期間は4週間。各部屋を掃除して、家具をパッキングして、持ち出します。不用品は分別して廃棄します。ちなみに作業を始めるまで分かりませんが、この引越しは4週間では絶対に終わらないという(意地悪な)設定になっています。

水落(みずおち)さんの場合。
水落さんは、ウォータフォール型のこんな計画を立てました。
 1週目…用具を準備します。
 2週目…部屋の掃除をして、不要物をより分けます。
 3週目…パッキングをします。
 4週目…家具を持ち出します。

1週目と2週目、水落さんは絶好調で仕事をこなし、計画を超える勢いで作業は進みました。ところがパッキングをしている3週目の中ごろに、とんでもないことが分かりました―家具が多すぎて、パッキングがとても1週間では終わらないのです。
この時点で水落さんに残された時間はわずか1週間と少し。プロジェクトはデス・マーチへ突入してゆきました…。

瓶生(びんしょう)さんの場合。
瓶生さんは、アジャイルな計画を立てました。
 1週目…8部屋を片付けます。
 2週目…8部屋を片付けます。
 3週目…8部屋を片付けます。
 4週目…6部屋を片付けます。

瓶生さんはとんでもないことに気づきました。8部屋の片づけをするには、1週間ではとても足りないのです。これでは計画通りに4週間で仕事を終わらせることはとても無理―しかし幸いなことに、瓶生さんがこのことに気づいたのは1週間目で、残り3週間の時間がありました。
これだけの時間があれば、期間延長の交渉、メンバーの増員、プロセスの改善など、打てる手立てはいくつか考えられそうです。

ここで重要なのは、瓶生さんが、計画を細かいイテレーションに分けたことでしょう。プロジェクトのクリティカルなポイント(この場合、パッキング作業)をスケジュールの前方に持ってくることで、結果として問題点を早く洗い出すことができ、対応に必要な時間を確保することができました。
もっとも、上記の例からアジャイルな手法が必ずしも優れているということにはならないかもしれません。計画の無理に気づいてもなかなか方針転換がされないようなプロジェクト体制の場合(よくありそうなことですね!)、問題点が早期に発覚しても無意味になってしまいますから。:-)

その2・アフォーダンス(ライトニングトークス:懸田剛氏)
アフォーダンスというのは、「与える、生じる」という意味の英語"afford"から作られた造語です。
物体が持っている、形・色・材質などの特性そのものが、物体自身をどう扱ったらよいかというメッセージを発している、という考えです。そこから一歩進んで、アフォーダンスによって、説明を要しない直感的なインターフェイスを設計できるのではないかと考えられます。
例として、ドアの取っ手を考えて見ましょう。手前に引いてあけるドアには通常、取っ手がついています(ドアノブのようなロックをかけるタイプではなく、引っ張るだけの単純な取っ手をイメージしてください)。この場合、当然ながら、取っ手はドアを開けるために実際に役立ちます。
逆に、押して開けるドアはどうでしょうか。ドアに、手よりも少し大きいくらいの四角いプレートがついているところを見たことがないでしょうか?このプレートは、取っ手とは違って、ドアを開けるという動作に必須ではありません。しかしユーザーは、このプレートによって「ドアを押す」ということを直感的に理解できます。
このとき、このプレートは、ユーザーに「押すこと」をアフォードしている、と考えられます。
このように考えると、アジャイル開発に使う小道具の意味づけができるのではないでしょうか(理論武装ともいえる)。
図を大きく印刷して壁に貼ることは、自然に「見ること」をアフォードする。
“ソフトウェアあんどん”は「結果を真剣に受け止めること」をアフォードする。
XFDロボは「○| ̄|_」をアフォードする。などなど。

4.懇親会

イベント終了後には立食形式の懇親会がありました。いろんな人と話ができて楽しかったです。ただ、遠くからこられた方は、懇親会には参加できなかったようですね…。残念です。
懇親会では、全員参加の「ふりかえり」が行われました。今回のイベントについて、「KEEP(良かったこと)」「PROBLEM(悪かったこと)」「TRY(次回に挑戦すること)」を出し合うという内容です。それぞれ個性的な意見の中で、特に面白かったコメントをした方には本が贈られました。ちょっと早いクリスマスプレゼントですね。
私も、「朝、会場に遅刻しそうになったとき、イベント事務局に電話をしたら、美人(おそらく)の女性が丁寧に対応してくれました。うれしかったです。」というようなコメントで本を頂きました。こんなコメントでもらっちゃってよかったんでしょうか?
ちなみにその声の持ち主は、電話の声から想像したよりももっと美人でした。(^^

5.最後に

このカンファレンスで感じたのは、ソフトウェア開発というのは属人性の高い要素で成り立っている、ということでした。例えばメンバー同士でどのようにコミュニケーションをとるのか、ということは、プロジェクトに偶発的に発生するトラブルではなく、ソフトウェア開発の本質的な問題のひとつであると感じました。

ひとつ、疑問として残ったことは、アジャイルな開発では、外部との齟齬をどのように埋めたらいいのだろうか、ということでした。具体的には、ユーザー側との契約、人月計算、元請と下請けという関係、組織の中の職制など、従来のウォーターフォール型の開発では問題にならなかった(あるいは問題として見えてこなかった)部分をどのように取り扱ったらよいのか、ということです。たとえチームが良い雰囲気であり、高い成果を出していたとしても、ビジネスとのつながりを考えないわけにはいきませんから。
極端な話として、理想的な開発方法論を掲げて周りをそれにあわせていくのか、それとも現状を前提として開発プロセスを調節しながら運用するのか。あるいは択一ではない回答があるのでしょうか?

最後に、スタッフの皆様お疲れさまでした。ぜひまた参加をしたいと思います。
HOME