« 2007年9月23日 - 2007年9月29日 | トップページ | 2007年10月7日 - 2007年10月13日 »

嘘つき愛くんには痛んだ彼女たちがお似合い「嘘つきみーくんと壊れたまーちゃん2」

いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
かみさまのうそつき
いちめんのしたい

いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
こわれたまーちゃん
いちめんのしたい

いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
いちめんのしたい
ちみどろまーちゃん
いちめんのしたい

 という素晴らしいシーンがフラッシュバックする「嘘つきみーくんと壊れたまーちゃん」。物語として完成度高いなー、と思ったのは、本作が一回限りの「嘘」に支えられているところ。みーくんの戯言的会話や、まーちゃんの狂いっぷりは、この「嘘」のおかげで救われている(わたしのレビューは[ここ])。

 …もちろんネタバレしないので、安心して続きを読んでほしい。

嘘つきみーくんと壊れたまーちゃん2 で、その「嘘」がウソとして暴かれるとき、このネタは使えなくなるはず…だったのに、だったのにーッ、 まさか「2」が出るとは! しかも読んで二度ビックリしたのは、きちんと叙述系の続編に仕上がっていること。

 入口はこんなカンジ、時間軸は「1」の続き、ネタは過去に遡及する。

入院した。僕は殺人未遂という被害の末に。マユは自分の頭を花瓶で殴るという自傷の末に。
二人が入院した先では、患者が一人、行方不明になっていた。
その事件は当初、僕にとって問題となるべき事柄ではなかった。数日後に起きた出来事のほうがよっぽど衝撃的だったからだ。
数日後。マユは、頭部と花瓶を再度巡り会わされた。自傷じゃなく、誰かの手によって。マユは病室で血塗れになり、今回も気絶することなく自前の足で歩き、医者に治療を依頼した。
そして、治療から帰ってきたマユは、本題とは関係の無いことを僕に発表した。
死体を見つけた、と。
また、はじまるのかな。ねえ、まーちゃん。

 あいかわらず、二重底の一つ目はすぐ分かるんよ、「犯人」が誰かってね(この手の奴は、話としていちばん面白いキャラを犯人にする)。それで安心して読み進めると、二つ目の底にひっくり返されるんよ、うわー、そうキたかーってね。

 しかもやんわり心惹かれているだけに、人物相関の残酷さが余計に刺さるんよ。嘘だろーって、口走っちゃうんよ、人死にが出るんじゃなくて、最初から死体とご対面なんよ、そしてサイアクなことに、事件はちっとも解決しないんよ。嘘だけど。

 そうそう、「2」の表紙、まーちゃんの眼(まなこ)はしっかり見ておくように。瞳孔が縦長になっているのは、夜行性の特徴なんだそうな、爬虫類の。

| | コメント (9) | トラックバック (1)

わたしの7つの「ふりかえり」

 [チームリーダーは「アジャイルレトロスペクティブズ」から盗め]の続き。わたしの「ふりかえり」をふりかえってみる。

■01 定期的に、ふりかえる

 実は、定期的なふりかえりは、したことがない。たいていは、プロジェクト終了直後や、さらにずっと後になって、「あんな時代もあったね」と語ることはあっても。ただし、「笑って話せる日」は絶対こない。笑わず小声で真剣に「あの二の舞だよ」、あるいは「まだ学習してへんのかッ」と刺す。

Agileretrospectives そういうチーム運営を定期的にふりかえる必要性に気づいただけでも、本書に感謝しないと

 まずいチーム運営は、トラブルという見えやすい形でフィードバックをもらっていた。メンバーの不満や、作業プロセスのボトルネック、品質チェックの不備は、プログラマの喧嘩や明白なサボタージュ、収拾のつかないバグズライフに化す。

 そして、「トラブルの対処」という形で皆の不満を吸い上げたり、手順書を見直したり、試験観点を追加していた。遅きに失する「ふりかえり」だが、やらないよりはやったほうがマシなことを、経験的に知っている(better late than never!)。

■02 わたしたち v.s. 問題

 のらりくらり言い逃れるクチをつまんで、「おまえのバグじゃボゲェ!」と怒鳴りたい。ヘラヘラ笑ってるか、逆切れしている顔を張り倒してその上でツイスト&シャウトしたい―― という非常に強い欲求に支配されることがある。

 こういうとき、わたしは何をするか?

 やおら背を向けて、ホワイトボードに書き出す。なければ巨大なクリップボード(いつも持ち歩いている)に絵を書き始める、「問題はこういう構図なのかなぁ?」といいながら。そして、「まずいところ」をギザギザ型にして、見せる。すると、どんなに逃げ回ってる奴でも、必ず見てくれる。

 「わたし v.s. あなた」の対決になるとどうしても感情的になってしまう。「攻撃 v.s. 防御」か、あるいは攻撃は最大の防御とばかりに、問題の押し付け合いになる。たがいに、「問題は相手が持っている」とみなすわけだ。

 これを回避する魔法の道具がホワイトボード。

    (問題)わたし   →→→ × ←←←   あなた(問題)

相手の向こう側に「問題」があるので、相手を口撃してしまうのが、ホワイトボードに書き出すことで、

    ホワイトボード(問題)  ←←←←← 「わたし and あなた」

アート・オブ・プロジェクトマネジメントに化ける。嘘だと思う方は、騙されたと思ってお試しあれ。火事場プロジェクトに落下傘部隊よろしく降下するとき、必ずこのやり方を使っている。だから、配属されて真っ先にする作業は、「ホワイトボードを確保して、自席の近くへ持ってくる」だね。(このへんの話は、アート・オブ・プロジェクトマネジメント」読書感想文に書いた)

 余談になるが、火を噴くプロジェクトは必ずといっていいほど、ホワイトボードがない。(あっても使っておらず、古い情報が消されずに残っている)。だから、配属された2番目の仕事は、「パリパリに乾いたインク跡を、丁寧に消す」やね。

■03 「問題」を持って、歩き回る

 「アジャイルレトロスペクティブズ」では、みんなが一緒の部屋で「ふりかえり」をしている。これも、あまり馴染みがない。みんないるところで、どんどん意見が出るものだろうか? 「アジャイル…」では、そうさせる仕掛けが紹介されているが、わたしのやり方は「問題を持って歩く」につきる。

 上の「■02 わたしたち v.s. 問題」で見える化したクリップボードを持って、ホットな人に会いに行く。メールも電話も×。直接会って「これについて、あなたの考えを伺いたいのですが、お時間をいただけますか」とお願いする。

 ポイントは、「これについてなんですけど…」と言いながら、問題の絵を見せるところ。チラっとでも見たらこっちの勝ち(人は字を読まないけれど、マンガは必ず見てしまう)。ホントに忙しかったら、空いている時を確保してくれるはず。しかも、人は「教えてください」に弱いもの。

 話が聞けたら、赤ペンでその「問題の絵」に書き足す。自分の意見が重視されるのは気持ちがいい。これを、チーム全員分する。わたしの場合、せいぜい5~6人のチームなのでこのやり方が可能だが、もっと大人数だったらどうしようかなぁ。

■04 人を集める

 ここまで下ごしらえした上で、メンバーを集める。全員分の意見・アイディアは書き出され、「○○というのがあなたのアイディアで合ってる? 足りないトコない?」という聞き方で進めるつもりで。

 開口一番は「○○の問題を解決するために、この場を設けました」で始め、かつホワイトボードにでっかく問題文(目的)を書いておく。また、全員の意見が書いてある「問題のマンガ」があるから、しゃべりすぎの奴にキッパリ「ちょっと黙って(ろこのタコ!)」と言える(丸カッコ内は心の中)。

■05 よい質問

 心がけている問いかけは、以下のとおり。

  • いま取り組んでいるのは、どんな問題なのかな
  • その問題が解決するとはつまり、○○ということになればOKなんだよね
  • 「○○になった」のは、どうやったら分かる?
  • それはいつ分かる?
  • それは誰が分かる?
  • あるいは、わたしが分かるためにはどうすればいい?
 ポイントは、問題を言い替え・分解すること。一言で「問題の対処」とはいっても、「原因を特定し、直す」ことと、「もう二度と発生させないようにする」ことと、「起きても無効化する」ことは、それぞれ分けて問いかける。超重要なのは次の二つ、
  • 他にない?
  • むかし、似たようなことがなかったっけ?
 この質問にどれだけ救われたことか。複数のインタフェースに跨るバグや、チームを横断する作業プロセスの改善は、似た事例が必ずあった。見たこともないような問題が立ちふさがり、スーパーな人があっという間に解決するのは例外で、でかい問題は昔から根を張っており、時間をかけて解きほぐす必要があるもの。

■06 お菓子は、重要なのかもしれない

 昔は、机の引出しにお菓子を常備している奴をバカにしたものだが、なかなかどうして、これは使える。議論が白熱してきたとき、お菓子(キットカットや一口チョコ、アメ)を出して、休憩にする。

 これはわたしの経験則なんだけど、一緒にモノを食べてると、敵じゃないという気になれる。なぜか説明できないが、食べながら話しをすると生産的になれる。口に甘いモノを入れていると、相手に寛容になれる。少なくとも喰ってる間は黙ってるし。

 昔は、赤ちょうちんで一杯やりながら同僚と「この仕事のやり方ではダメだダメだ」とサラリーマン模範生のようにクダ巻いてられたが、一杯やってるヒマすらない。そんなとき、この小道具は使える。

自分の小さな「箱」から脱出する方法■07 Getting out of the Box

 「ふりかえり」の際、一番陥りがちなのが、お互いが「箱」に入ってしまうこと。

 だから、まずわたしが、「箱」を意識して、その外に出ていること。「自己正当化の正当化」の罠にハマらないこと。自己欺瞞→自己正当化→防御の構え→他者の攻撃→他者のモノ化のルートに陥らないこと。

 メンバーを感情的な目で見るとき、どうしても「問題に対する自己防衛本能」が働き、その結果、相手の言動をそのまま受け取れなくなる。真意の底に悪意を探し始める。いわゆる「箱の中に入る」やね。

 その「箱」を意識することで、無効化させる。大丈夫、燃えるプロジェクトが飛び火して火だるまになっても、うんこプロジェクトの残糞を舐めとらされたりしても、死ぬわけではない。罵倒されようが無能呼ばわりされようが、構えない。

 なぜなら、わたしは、問題を解決するために、ここにいるのだから。

――「箱」って何のこっちゃ、という方は「自分の小さな「箱」から脱出する方法」を激しくオススメ(レビューは[箱1][箱2]

 以上が、わたしの「ふりかえり」のふりかえり。緊急度が比較的低く、チームで根気よく取り組む問題は、こんな風にやっている。もっと緊急度が高いトラブル(パターン青!使徒です!)の場合は、「最悪の事故が起こるまで人は何をしていたのか」で5原則を説明してある。

  • 原則1 : 情報を集める場所と、判断する場所を、物理的に分ける
  • 原則2 : 重大な問題が発生したとき、メンバーをどのタイミングで休ませるか? を最初に考える
  • 原則3 : トラブルの原因を探す/被害を最小限する/プロジェクト目標へ軌道を戻す目的を分ける
  • 原則4 : 「外の目」を取り入れる
  • 原則5 : 現場を責めるな!
 成果物に出る「問題」と、作業プロセスに生じた「問題」を混ぜて書いてしまったが、両者を分けられない。プロジェクト・メンバーの士気と、「ていどひくい」バグの発生率は、かなりの相関関係があると思うぞ、測ったことないけど。

| | コメント (0) | トラックバック (1)

チームリーダーは「アジャイルレトロスペクティブズ」から盗め

Agileretrospectives 「なんで、こんな非効率なやり方なんだ?」この疑問、よくあるどころか毎日だ。

 たとえば、情報がうまく共有されていないとか、ある人がボトルネックになっているとか。不平を言うと「じゃぁオマエがやれ」と押し付けられるので、最近では不言実行で最適化を図っている[参考]

 あるいは、評論家になっていっぱしのクチをきくが、現場を変える努力も勇気もないくせにブログで薀蓄たれ流す。ネット弁慶カッコワルイ(誰とはいわんが、わたしも含まれるので自戒)。

 たしかに、「前と同じやり方」で仕事は回るが、「やり方」が改善されないまま。成果物はレビューされるが、仕事のプロセスはレビューされない。かくして非効率性は引き継がれ、不満は澱のように溜まってゆく。

 こいつをなんとかする試みが、「アジャイルレトロスペクティブズ」。舌噛みそうな名前で、サブタイトルの「『ふりかえり』の手引き」というほうがピッタリだね。

 つまり、プロジェクトの要所要所でチームそのものを「ふりかえり」、作業そのものをレビューしようという発想。この「ふりかえり」のためのアイディアやヒントが本書。

 「ふりかえり」を短期に組織的に行おうとするのが斬新だ。小さいチームを想定した手引きで、学級会のようなノリに戸惑うが、たくさん盗ませてもらった。「いま、チームに何が起きているのか」を知るための強力なツールになる。ファシリテーター必読。

 以下わたしの収獲。

■ 感情にフォーカスする

 いちばん驚いたのがこれ。「仕事に感情を持ち込まない」のがルールだろう。そりゃぁ、罵倒したり爆発したりすることもあるが、マナー違反として扱われる。本書では外に出すことが奨励されており、その方法まで紹介されている。

自分の感情について話せる仕組みを作ることで、感情的に負担のあるトピックを取り上げることに抵抗がなくなる。感情的な内容に言及することを避けていては事態は進展しない。問題は表面化されず、エネルギーとモチベーションが徐々に吸い取られていくだけだ。

 その具体的方法は以下のとおり。まぁ、ヤなことをハラに溜めて仕事するよりも、出しておいたほうが精神衛生上いいことは確か。「どう感じたか?」ではなく、「○○と思ったのはいつか?」というすりかえ質問。うまいやり方。

エンジニアは自分の感情を話したがらないものだ。だからレトロスペクティブで感情について尋ねるようなことはしない。ちょっとした工夫がある。感情について直接尋ねるのではなく、別のやり方で尋ねてみるのである。会社に来るときにワクワクしたのはいつか? 仕事が「単なる仕事」になったのはいつか? 会社に来るのが怖かったのはいつか?

■ 厳禁句「おまえのバグだろ!」

 すげー耳に痛いのが「あなたが言葉」(You Language)。チームの約束が破られたとき、絶対に、絶対に、ぜったいに「あなたが言葉」を使わない。さもないと、自己防衛と逆ギレによる負のスパイラルでレトロスペクティブが崩壊する。主語を "You" にすると、途端に責任追及の場になってしまう。いわゆる「おまえのバグだ(゚Д゚)ゴルァ!」だねッ

 どうすればよいか? 「私が言葉」(I Language)を使えという。主語を「私が」にすることで、「話し手の気づき」がメッセージの重点になる。決め付けではなく、気持ちについて議論ができる。

あなたが言葉 : 「ビルドを壊しやがって、お前がちゃんとやっていれば目標を達成できたんだよ!」
私が言葉 : 「私が怒っているのは、目標を達成できなかったことだ。あのビルドを修正するのはとても厄介なんだよ」

問題がビルドにフォーカスしているのが「見える」。少なくとも、「私が言葉」の方が前向きな流れになるはず。

■ ドットによる優先づけ

 アイディア出しの技法はどこかで聞いたものばかりだったが、その優先づけの方法が興味を惹いた。価値基準による重みづけあたりが出るのかなーと思っていたら、書いてない。代わりに、もっと素朴な「ドット貼り」が面白い。こんなカンジ…

 目的 : 課題/アイディア/提案の優先づけをする
 方法 : メンバーにカラードット(丸いシール)を10個配って、

  • 優先度1には4ドット
  • 優先度2には3ドット
  • 優先度3には2ドット
  • 優先度4には1ドット
 と、それぞれのアイディアの横に貼ってもらう。みんながやるべきだ、と支持しているものが「見える化」できる。声の大きい人の提案が通るのではないところがポイント。

 すると、素朴な疑問が頭をもたげてくる。みながやりたい案が採用されるのであって、最もやるべき案とは必ずしも一致しないのではないかと。著者は用心深くこう述べている。

人は、重要だと分かっていても、まだ手をつけたくないことがあるものだ。エネルギーがあるときに取りかかればいい。必要なのはチームが支持するアクションや決定だ。みんなが実行してくれなければ意味がないのである。

「ふりかえり」のための沢山のアイディアやヒントを読むうちに、チームの今を察するために、どういう姿勢でいればいいか(いるべきか)が分かる。言い換えると、「よい質問」が発せられるようになる。

 最後に。献本ありがとうございます。翻訳に「あそび」があって楽しめました。「これはひどい」や「家に帰るまでがレトロスペクティブです」といったcool(?)な訳に噴きました。本書は会社でたっぷりと使わせてもらいますぞ。

| | コメント (0) | トラックバック (5)

« 2007年9月23日 - 2007年9月29日 | トップページ | 2007年10月7日 - 2007年10月13日 »