2009年12月17日

朝会のアンチパターン

この文章は、Twitterでちょっと盛り上がった朝会のアンチ・パターンについて、勝手にまとめ、補足したものです。

朝会のあり方については、M・ファウラー氏の「朝会のパターン:立ってるだけじゃないよ」や、オブジェクト倶楽部の「プロジェクトファシリテーション実践編:朝会ガイド」(PDF)を参照してください。

運営に関するアンチパターン



座ってやっている


フォース


報告が詳細になりすぎている。時間がかかりすぎている。そもそも場所がない。

対策


立って開催することを呼びかける。
ただし、諸事情でどうしても立ってできない場合は、なるべく短くなるように全員が心がける。

シーンとしている


フォース


朝会全体に威圧的な雰囲気、または陰鬱な雰囲気ができている。プロジェクト進行がうまくいっていない。

対策


朝会を行う意義をもういちど全員で確認する。

その他


朝会以前にプロジェクトの建て直しをはかる。

誰も他人の言う事を聞いてない


フォース


朝会で報告することが毎回多すぎる。他メンバーの状況を把握すると自分に仕事が降りかかる。

対策


朝会で言うべきことを整理し、意思統一する。
ファシリテータは朝会が仕事振り分けの場ではない事を徹底する。

最初か最後にリーダーのご高説が入る


フォース


朝会をトップの意思を伝達する場と勘違いしている。

対策


朝会を朝礼と勘違いしない。
ファシリテータはリーダーが演説を始めたら止める。
上記参考文献をファシリテータ・リーダー自ら読み直すこと。

責められる


フォース


朝会が進捗の責任追及の場に転化してしまっている。

対策


他者が報告中は口を挟まないように徹底する。
ファシリテータはリーダーの言動に暴走が見られた場合、注意を喚起する。

その他


リーダーは報告者が報告してくれたことにまず感謝するクセをつける。

そもそも二度手間


フォース


他に日報・時報で作業状況を提出しなければいけない。その時間が業務時間内に保障されているわけでもない。
メンバーが状態を共有するのを苦痛に感じている。

対策


週報、日報をやめる。

その他


諸事情でやめられない場合、週報、日報を全員に開示する方法を検討し、そちらを優先する。

しゃべるメンバーが偏っている


フォース


朝会を自分の意思を伝達する場と勘違いしている。自
己アピールの場と勘違いしている。

対策


ファシリテータは報告の時間を短く区切り、計測する。(30秒以内が妥当)
他者の報告への口出しは朝会の解散後とするよう、徹底する。

@holic



報告内容に関するアンチパターン



問題点のあり/なしを言わない


フォース


うまくいかないのが自分のせいか対象のせいか切り分けできていない。作業報告の中に混ぜてしまっている

対策


問題点はどんな小さなものも報告するよう徹底する。
ファシリテータが報告のなかから問題点をみつけ、指摘する。
本人が問題点に気づくよう、粘り強くファシリテートする。(「困ってることはありませんか?」と尋ねるなど)

@kkd



遅れているか、進んでいるかが重要ポイントになっている


フォース


朝会を進捗掌握の場と勘違いしている。

対策


朝会の報告内容を「やった事」「やる事」「問題点」に絞るよう徹底する。
ファシリテータは朝会で進捗の話が出たら、注意を喚起する。
その他
リーダーは普段から「進んでいるか/遅れているか」と聞くのではなく、「期日に間に合うか」と聞くクセをつける。
そもそもの進捗管理をパーセンテージ主義から成果物主義へ移行する。

メンバーに関するアンチパターン



実施に反抗的なメンバーがいる


フォース


朝会の利点が理解できていない。
朝会が朝礼化してしまっている。

対策


朝会の意義をメンバー全員で徹底的に論じ合う。
上記テキストも活用する。

恒常的に特定メンバーがいない


フォース


ムリが続いてプロジェクトが疲弊している。
朝会が形骸化してしまっている。

対策


特定メンバーに高負荷がかかりすぎてないか注意する。
特定メンバーというのが大多数ならば、朝会の意義、重要性を再確認する場を設ける。
特定メンバーの悪癖の場合は、ファシリテータがきちっと注意する。

恒常的にリーダーがいない


フォース


ムリが続いてプロジェクトが疲弊している。
朝会が形骸化してしまっている。

対策


リーダーに高負荷がかかりすぎている場合、リーダーは積極的にメンバーに仕事を任せるように対策をとる。
リーダーの悪癖の場合は、ファシリテータが注意する。もしくはリーダーに対する監督権限がある人物に相談する。

朝会はプロジェクトがうまくいくための重要なプラクティスですが、それでも「うまくやるひとつの方法」でしかありません。
もしメンバー全体が朝会そのものに疲弊してしまっているなら、いちど廃止することも検討しましょう。

なお、各内容についてはご意見上等です。
posted by 未知夢 at 13:49| 東京 ☁| Comment(2) | TrackBack(0) | Agile応援団 | このブログの読者になる | 更新情報をチェックする

2008年03月30日

試験駆動開発雑感

知人のblog記事ながら。

[TDD]id:t-wada先生のつぶやきメモ(ただぶろぐ)の内容に全面的に賛成。

TDDの是非はともかくとして。

TDDが好きな人は、テストを書きながら対象のクラス・メソッドの仕様を設計しているし、メソッドのインタフェース仕様(インプット・アウトプット)を決定している。
体感的には、テストを記述しているときにこそけっこうぐだぐだとテスト内容を見直したりテストの構成を変えたりと試行錯誤を繰り返すけれど、実コードはせいぜいリファクタリング程度で、あまり大きな見直しはそうそう起こらない。
だから、コードファーストで書くよりはコーディング時間は確かに長いが、本人の開発リズム感はけっこういいテンポになっている。リズム感の充実は快感に変わる。

TDDが嫌いな人は、TDDを押し付けられるとまずいつも通り頭の中で仕様を考えてしまう。
その後テストコード書きに移る律儀な人は、必ず「わかっている仕様を記述しているだけ」という退屈感を感じ、実コード書きにすぐにでも移りたくなる。これが開発者自身のリズム感をとにかく崩しまくる。リズム感の崩壊は苦痛に変わる。

開発者がまず第一に考慮しなきゃいけないのは、このコーディングリズム感であり、リズムが崩れるとコードが崩れる。
なので、TDD主義者ながらあえて、TDD脳を培うことのないTDD押し付けには反対したい。

続きを読む
posted by 未知夢 at 18:00| 東京 ☀| Comment(0) | TrackBack(0) | Agile応援団 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。