7/7(火)にオブジェクト倶楽部 2009夏イベントが開催されました。今回は中の人としての仕事は、ほとんどなにもせず、「プロジェクトポートフォリオ」のワークショップをやりました。

当日使ったカードのデータはプロジェクトポートフォリオにあります。プレゼン資料はSlideShareにあります。

アイスブレークについて

さて、自分のワークショップの冒頭で、こういう簡単なゲームをやりました。

これから6つのマスを左から順に埋めていきます。
内容には、3つの法則があります。
法則を当てた人にはプレゼントを差し上げます
(テーマが「ゲーム」ということで、サイコロのセットを準備していました)。

こう宣言して、手書きで順次、6つの数字を書いていきました。答えがわかったという人にはその場で挙手して、法則を当ててもらいます。何人かが挑戦してくれたのですが、完全な正解は出ませんでした。

6つの数字は以下のものです。

2 4 16 64 256 512

「2の乗数！」「左から2倍、4倍、2倍…と繰り返す」など、もっともな答えが出たのですが、残念ながら外れ。参加者の皆さんは、かなり真剣な表情で頭がぐるぐるしている様子でした。

ここが、わたしがアイスブレークをするときに大事にしているところです。もちろん、笑顔でリラックスすることは大事なんですが、同時に参加者の頭脳を活発化する、普段とは少し違うところで脳みそに汗をかく準備をする、ちょっとドキッとさせられる、"ギアを上げる"、こんな感覚を持ってもらってから、本編に入って行くようにしています。そのために、小さなことでもなにかひとつ伝える、気づきやアイデアを植え付けるのが有効と考えています。

講演にしてもワークショップにしても、日常とは違う、新しいことを受け止めたり考えたりする時間です。そのための準備運動として、わたしの感覚ですが、柔軟だけでなく、心拍を上げて体温を高くすることが必要。場を温めてにこやかになるだけでなく、ちょっとした山(盛り土程度かな)を越えておく、そうすれば最大のパフォーマンスを出せるようになると思っています。

さて、先の問題の答えは以下になります。怒っちゃダメですよ。

1. 1以上の整数である (自然数である)
2. 偶数である
3. 左の数よりも大きい

どうでしょう、考えていたよりずっと単純ではないでしょうか。「えー」と思わないでしょうか。このスライドを出したときの反応は「ぽかーん」でした。こういうちょっとしたショックも、アイスブレークでは重要です。次に話すことがすっと入るようになります。こういう方法をJoltと呼びます。

それでですが、当日はここで失敗しました。言いたいことをちゃんと言えず、参加者のみなさんが「ぽかーん」のまま本編に入ってしまったんですね。仕掛けはよくてもやり方が拙くては効果半減。やれやれ。

本当に伝えたかったのはこういうことでした。

• ゲームはルール(法則)に則るものである
• ルールに縛られるのではなく、ルールを活用する思考が大事
• 現実にもいろいろな法則があるが、実際以上に複雑に考えてしまうことがある
• 今回は法則を使ってみなさんを引っかけた

このゲームは元ネタがあります。The Thiagi Groupが公開しているBy the Numbersというゲームです。今回はもっと単純化していますが、ネタとしての応用はいろいろできるものです。

今回、ちょっと久しぶりにプロジェクトゲームのワークショップをやって、やっぱりかなり効果が高いと再認識しました。もっとたくさんの場所で、上手く活用して広めていきたいなあ。

3月27日に、第24回XPユーザー会をおこないました。タイトルは「アジャイルな見積りと計画づくり」ということで、翻訳をした角谷さんと私とが話をし、後半ではプランニングポーカーのワークショップをやりました。

私は「陽の巻」ということで、特に計画づくりの大切さに焦点を絞った話をしました。あまのりょーさんが動画を公開してくれています。

角谷さんは陰の巻、本には書いていないけれど本が訴えている大切なことを話してくれました。個人的には角谷さんの話が聞けて良かったなあ。こちらも動画があります。

プランニングポーカーのワークショップは、チームごとに分かれての見積りをします。ネタにはさんざん悩んだんですが、

• 2009年のゴールデンウィーク、海外旅行の行き先ごとの行く人の割合は？
• 今日の参加者で、技術者、マネージャ、その他はそれぞれ何人？

というお題を出しました。いろいろな意図があって、正解がわかることだったり、人によってバラバラの関連知識を集約すると見積りがよくなるとか、質問をすると精度が上げられること(いかにいい質問ができるかもポイント)、見当もつかないときでもポーカーをすればなんか進められるということ、などを実感してもらえたんじゃないかと思います。こちらも資料を公開しています。

参加していただいたみなさん、どうもありがとうございます！企画してくれたpapanda、GJ！撮影してくれたあまのりょーさん、4qです！開催準備、受付、懇親会運営などスタッフのみなさんいつもありがとうございます！

2月から3月にかけて、InfoQの記事を2本翻訳しました。

• SpolskyとBobおじさんの対決
  • http://www.infoq.com/jp/news/2009/02/spolsky-vs-uncle-bob
  • これはすごい。筋金入りの元祖アジャイラーと若きアジャイラーの対決。SOLID原則は知ってるよね？
• バグトラッキングシステムなんて捨ててしまえ？
  • http://www.infoq.com/jp/news/2009/03/testobsessed-on-agile-bugs
  • バグトラッキングシステムが必要なほどバグが多いのは、それ自体が問題なのでは？という提言です。

基本的には、自分で「これはいい！」と思った記事しか訳してないです。そして訳すからには、できるだけ読みやすく、同時に原文の意図を余さず伝えるように努力しています。InfoQの記事の翻訳というのは、量的にも内容的にも練習にちょうどいいですね。練習とは言ってもちゃんとした仕事なのです。

マイコミさんの主催で、アジャイルな見積りと計画づくりの打ち上げをしてもらいました。

今回の翻訳では、共同して翻訳した角谷さんはもちろん、レビューワーのみなさんや編集の方にたいへんに助けてもらいました。内容や誤訳のチェックはもちろん、「読みやすい日本語にしたいしたい」とわたしは言うだけで、実際に自然で読みやすい日本語の文章になったのは、助けてくれた皆さんのおかげです。あらためて、ありがとうございます。

翻訳する、本を作るという仕事の中で、会社の仕事ではなかなか関われない人と共同作業ができたというのは素敵な経験でした。昨日は会えなかったけれど、昔の仲間もレビューに参加してくれたりして、これもまた嬉しかった。関わってくれた人が、それぞれのメリットを得られていたらいいなあとも思います。コミュニティから得られたつながりでできたチームですが、これはこれで、ひとつのコミュニティ活動なのかもしれません。

I'm writing this and I'm aware my writing is quite weak and missing some points. I hope I have time to revise this article. Yet it's rather healthy practice to make some (stupid) ideas open, I believe. And so here it is.

From Uncle Bob's years-old yet intriguing article, (it was published in 1996) the merit of ISP (Interface Segregation Principle) is about time.

But it’s just a recompile.
True. But recompiles can be very expensive for a number of reasons. First of all, they take
time. When recompiles take too much time, developers begin to take shortcuts. They may
hack a change in the “wrong” place, rather than engineer a change in the “right” place;
because the “right” place will force a huge recompilation. Secondly, a recompilation
means a new object module. In this day and age of dynamically linked libraries and incremental
loaders, generating more object modules than necessary can be a significant disadvantage.
The more DLLs that are affected by a change, the greater the problem of
distributing and managing the change.

I feel ISP itself is still holds good but those merits sounds too weak in these days, especially on dynamically typed languages like Python and Ruby.

If a class has, say, an aggregated interface, it can mean two things.

1. The class extends another class which does inner working of the first class.
2. The class has two or more separate responsibilities.

In the first case, obvious answer is 'It should have been delegated, not extended.' Such a class breaks LSP and loses clarity when read. It will have confused code of processing its own logic while using super class's functionality without clear distinction between those. Usually code in a subclass can be complex even if LSP is uphold.

Also, the class extending another might expose some functionality inherited from its super class unintentionally. Those unnecessary methods can be marked someway, but it's fragile when the super class is modified to have new methods. There can be tests showing the right way and wrong way to use the target class, but it's very hard to write a test that shows certain methods should not be used at all!

In the second case, the said class have aggregated responsibility or functionality. Typically a Facade is such a class, usually delegating those functionality to outside to avoid confused code in it. In this case, the problem is aggregated interface itself. Single class with many responsibility does not necessarily have single fat interface. This is the time when you should have segregated interface.

ISP is a good design policy with good reason nowadays.

いま一緒に仕事をしている若者が作った、略語？アクロニム？です。

去年からアジャイル開発をしているチームですが、わたしはアジャイルコーチとして、特にプロセス的な部分を中心に支援しています。単なる「アジャイルプロセスの導入」にとどまらない、「アジャイルな態度を身につける」ことを、チームとして達成したことが、このWKTSにも現れていると思っています。

わたしはWKTSを良いプラクティスとして強く推しますが、反対されることもあります。得てして新卒社会人は「質問する前によく調べる・考える」なんていう指導をされがちですし、そういう文化の職場も数多くあるし、自分で調べることはそれはそれで重要です。わたしも、調べるスキルを身につけなくては、まともな技術者にはなれないだろうとも思います。

わからないことがあったとき、自分で調べて解決できれば、他の人には迷惑がかかりません。自力でやったという達成感もあるし、人の時間を奪うこともないし、苦労したことは忘れずに身につくでしょう。しかし、それはチームワークとチームのパフォーマンスを無視した、身勝手な意見であったりは、しないでしょうか？

わからないことがあったとき、すぐに気軽に聞いて、聞かれた側もわかれば即答する、わからなければ「わからんから自分で調べて」と即答する、そんなことができるチームは、確実にチーム全体の時間を節約しています。初歩的なことであれば「ググレカス」と言えば済む。お互いイヤな気持ちにならずにそういったやりとりができるためには、チーム内に信頼関係と太いコミュニケーションパスが必要です。

新人が気にかかった疑問が、実はプロジェクト全体に関わる大きな問題の一端であることもあります。そうした疑問を表面化して共有することは、重要なリスク管理の手法となります。信頼関係があれば、新人に限らずベテランの人でも「ん？」と思ったとき、人と相談できるでしょう。そこからリスクを発見できるかもしれないし、場合によっては直ちに解消できるかもしれない。表面化したリスクをまた見失わないように、解決した疑問を記録して共有する仕組みも用意するべきです。

誰かが疑問に思ったことは、他の人もまた疑問に思う可能性が高い。いったん解決した問題は、フォーマットにこだわらず記録して共有すれば、プロジェクトの知識という資産として残ります。網羅的な説明資料よりも、ピンポイントで役に立つ、しかも作成・維持にかかるコストが小さいプロジェクトナレッジベースとなります。疑問を埋没させず表面化し、さらに解決したときにはちゃんと記録するように促す(システム的にも、人的にもそうした仕組みが必要)。解決にかかった時間から、「個人の成長」という曖昧な効果を期待するだけでなく、プロジェクトの資産という目に見えるリターンを得ることができます。もちろん、個人的なメモをするだけではなくなるので、プロジェクトの記録を残すという作業からより深く客観的に疑問と解決を整理できるという効果もあるでしょう。

「わからないことはとりあえず質問する=WKTS」が、ひとつのプラクティスとして成立するかは微妙かもしれません。ですが、そうした文化を醸成できるチームは、コミュニケーションの薄い個人主義的メンバーの多いチームより、確実に高いパフォーマンスを出すことができます。

「xUnitとかで書いた自動化テスト」について価値と原則を考えてみたいと思いました。

テストという言葉が悪い、というまさにその典型例なんだけど、 TDDやテストファーストに限らず、その周辺をぼんやりと取り巻いた 「テストと呼ばれているもの」についてのことを考えたいのです。 これってデベロッパーテスト、と呼んでいいのかしらん。

• 価値:
  • 品質
  • 自信
  • コミュニケーション
• 原則:
  • よりよい設計を追求する
    • テストはプロダクトコードの設計をよくするために書く
  • 不安がなくなるまでテストを書く
    • テストはセーフティネット。どれだけ書くかという指標は、書いた人がいちばんよく分かる
    • とはいえテストを書くべき分量の感覚と裏付けは、身につけなくてはいけない
  • テストの読み手を意識する
    • なにをテストしたいのかがあいまいだと、テストコードもあいまいになる
    • テストしたいポイントはどこか、枝葉はどの部分かを、テストコード上で表現する
  • テストが書きやすいようプロダクトコードを変える
    • 設計を改善するガイドとしてのテスト
    • シンプルなテストを書き、それに応じてプロダクトコードを書く(変更する)。結果としてシンプルなプロダクトコードが得られる
  • プロダクトコードをテストが説明する
    • テストによって、プロダクトコードの仕様を説明できる
  • 常に実行し、結果をオープンにする
    • テストは実行しなくては価値がない。結果を見なくては、その価値を伝えられない
    • コーディング中、コミット時、常時結合、運用保守中など、常にテストを走らせて、問題がないか確認できるようにしておく
  • テストの価値を維持しつつ、高める
    • テストは資産。書いたまま放置すると不良資産化する
    • テストの有効性を検証し、不要なテストを消したり統合したり、実行時間を短縮したりという継続的努力が必要となる

自分で知っていること、理解していることの整理として。

あらためて、デブサミ2009の感想を書きたいと思います。

今回、自分にとっては「話してきた」ということが一番大きいわけです。いままではセッションの受講とコミュニティとしての参加だったわけで、まあコミュニティは「身内」感もあるけれど、それでも待遇はお客様なんですよね。まあ、コミュニティはコミュニティで、微々たるものですができる範囲でデブサミに貢献してます(宣伝とか客寄せとか)。

いっぽう、スピーカーとしての参加をしたことで、デブサミの「骨身」に近い部分に入り込んだ気がしています(もちろん、本当の中の人からしたらまだお客様なんだろうけど)。id:IWAKIRIさんやコンテンツ委員の人々からデブサミの想いを聞いたり、その中での自分の位置づけを考えたり、そのうえで「やりたいことやるんだもんねー」という言い分を聞いてくれる懐の深さがあったり。中の人には申し訳ないんだけど、キャッチフレーズ(今回は「つなぐ、つながる、そして未来へ」)をちゃんと意識したのって、初めてだったかも。

そんなふうに、デブサミの(ちょっと)内側に入り込んで思ったのは、デブサミって一枚岩でできてるわけではないんだなーということ。XPJUGの(良くも悪くも)内輪な感じではないし、オブジェクト倶楽部の「いまやりたいことがテーマだ！」というフラフラ感でもないのだけど、デブサミはデブサミという「場」であって、そこにいろいろな人が引き寄せられていくのだと感じました。多様性があって、スーツもギークもわりと仲良くしていて、絢爛なバザールのよう。そうでありながら一本のブレない幹があって、葉のように広がる多様性が多様なままでいるのは、id:IWAKIRIさんはじめ中の人の想いが作る求心力なのかな、と思ってみたり。

ゲームやってきました

初日午後のセッションで、最近凝っているプロジェクトゲームという、ゲームでプロジェクトのことをいろいろ見てみようよというアイデアから、プロジェクトポートフォリオというゲームを

1. 紹介し、
2. みんなで実際にやってみて、
3. その気づきを共有する

ということをしました。

ゲーム、カードやサイコロを使うアナログなゲームというのものは、やって楽しいだけでなく、なにかを伝える媒体になり得ます。それに、ゲームは人と人のコミュニケーションを促進します。誰でも人生ゲームや、ババヌキや、オセロで興奮して一喜一憂した経験があるはず。

今回紹介したプロジェクトポートフォリオ、こんなことを伝えたくて作りました。

• プロジェクトマネージャは楽じゃない
• ユーザと開発者(ベンダー)が協力しなければプロジェクトはうまくいかない
• 計画は大切、でも計画通りには行かない
• 「これはゲームだけど現実にはなあっ」という話を現場でしてほしい

詳しくはslideshareの資料を見てください。

• プレゼン資料 http://www.slideshare.net/yattom/12e3-pm-games
• 施策カード(画面だとなぜか見れませんが、ダウンロードすれば使えます) http://www.slideshare.net/yattom/project-portfolio-measure-cards
• リスクカード http://www.slideshare.net/yattom/project-portfolio-risk-cards
• 状況シート(B6版) http://www.slideshare.net/yattom/project-portfolio-situation-sheet

ゲームと気づき共有がメインなので、自分ではあまり話さなかったのですが、後半ふつふつとわき上がってきたのが「楽しさ」というメッセージでした。私のポリシーとして、楽しいことは上手く、効果的に、継続してできる、と思っています。だから、仕事を楽しくすれば、よりよい仕事ができるはず。

終わる前に、「楽しかった人？」と聞いたら、ほぼ全員の手が挙がりました。ありがとうございます。楽しさの中でなにかを伝えることを、感じてもらえたのではないかと思います。

朝のセッションで匠Labの萩本さんが、「この業界はクリエーティブなはずなのに、そうでなくなっているのが残念」という意味のことをおっしゃっていました。クリエーティブな仕事は、楽しさのある仕事だと思います。楽しさを取り戻すことが、IT業界の活性化につながる。そう信じています。

** 「開発プロセスの心」 **

参加したセッションから、印象的なものを。基本、コミュニティブースにいて、あんまり聞いてないんですよね。

匠Labの萩本さん(豆蔵は辞めちゃったのかな…)のセッション。デブサミは、まあこれだけ聞けば元を取ったようなもんですね(タダだけど)。

ウォーターフォール、繰り返し型、アジャイルと、開発プロセスについてこれだけきちんと把握して整理した上で、バランスの取れた見方をできる人はあんまりいないんじゃないかなあ。最初は冷静な感じだったけど、(やっぱり)段々アツくなってきて、かっこよかった。

アジャイルについて。メリットはおいておいて、横展開ができないことがデメリットであるという指摘は、2つの意味でもっともだと思います。

+アジャイルはチームごと、プロジェクトごとに異なるのが本質。スポンと切り出してコピーしたら、その時点でアジャイルではない。 +アジャイルのプロセス導入やトレーニングやコーチや、ノウハウはあっても、「アジャイルになる」ためのプロセスが確立していない。コピーできないことを言い訳にせず、「アジャイルに育てる」ことは模索すべき。

http://www.infoq.com/jp/news/2008/11/decline-of-agileのような話を、まあ当然ご存じなんだろうけれど、アジャイル界(ってなに)への鋭いツッコミでした。

「パネルディスカッション 帳票開発の肝」

これは小井土さんと鋤柄さんによる、帳票を軸とした「ソフトウェア開発というお仕事」の話でした。「銀の弾丸はない」(出た！)、アーキテクチャ、ツールやテストからユーザーとの交渉の話まで。帳票からそんなに話を広げるなんて、ズルい！

小井土さんの普段のお仕事の話が聞けたのも面白かったなあ。最近は(幸運にも？不幸にも？)帳票に関わっていませんが、エンジニアたるもの帳票の100や200作ってみるべきですね。

コミュニティブース

全体に、コミュニティブースにいた時間が長かったですね。ここはここでいろいろな人と会えたり、なにげに熱い議論が巻き起こったりする楽しい場所でもあります。それに今回は、コミュニティブースで。。。

「アジャイルな見積りと計画づくり」サイン会

サイン会なんてやってしまったりしたわけです。もちろん初めて。角谷さんと並んで(2日目は木下さんも)、訳書にサインをしました。来てくれて、並んでまでくれたみなさん、ありがとうございます！

アジャイルな見積りと計画づくり、おかげさまで好評で、会場では完売となりました。ありがとうございます！

オブジェクト倶楽部のふりかえり

2日目最終セッションは、オブジェクト倶楽部によるデブサミ全体のふりかえりというid:m_pixyプレゼンツによる野心的なセッションの、スタッフとして参加してきました。

参加人数は少なかったのですが、地味に熱く話が盛り上がり、自分が参加していないセッションの情報が聞けたり、人によって背景によって受け取り方が違ったり、とても刺激的でした。やはりふりかえりという場で、体験や考えたことを口に出したり紙に書いたりと固定化することで初めて、あとあとまで残る経験となります。やってみてわかる、貴重なセッションとなりました。

ヒゲ＋スーツ

えーと、デブサミデビューだし、PMトラックだし、ということでスーツ。ちょっと気合い入れた。id:t-wadaさんに[http://d.hatena.ne.jp/t-wada/20090212 ホメられた]のでいい気になってます。

今日はデブサミ2日目ですが、昨日の午後イチのセッションでプロジェクトポートフォリオをやってきました。最初はちょっと心配だったけれど、参加者の人もけっこう楽しそうに遊んでもらい、気づきの共有もできて、自分としてはかなり満足のできる結果となりました。

ゲームのコンテンツやプレゼンは、週末くらいに公開予定です。

今日はデブサミ2日目。昨日は気合い入ってたけれど、今日は気が抜けまくってます。だいたいコミュニティブースにいます。

作っただけでなーんもしてないサイト(Trac)に、とりあえず明日のデブサミで話すのに備えて最低限、ProjectGamesのコンテンツを入れてみました。コンテンツ、というほどのものもないけれど。まあ、プロジェクトゲーム自体がまだまだこれから作っていこう、という段階なので、いいよね。

デブサミが終わったら、なるはやでプロジェクトポートフォリオのコンテンツをアップロードします。

ていうか、明日は楽しみだなあ。萩本さんのセッションもあるし。午後しばらく抜けないといけないのが残念。

アジャイルな見積りと計画づくりも会場で販売します。なんと50冊搬入らしい！売れるといいなあ。買ってくださいね。サイン会もします。

• サイン会
  • 1日目(12日) 16:15～16:35
  • 2日目(13日) 12:20～12:50
  • 場所: オブジェクト倶楽部ブース (コミュニティエリア内)

yattom.jp を自分のサイトにしてブログも作りたいので、FullBlogPluginを入れてみた。

現在はまだやっとむでぽんがメインのブログです。あんまり書いてないけれど。