読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

朝会は文字通り朝にやれ

Agile Project Management

アジャイルではないソフトウェア開発プロジェクトでも一般化しつつあるプラクティスの一つに朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム)がある。正しい読み方は知らないけれど、「ちょうかい」ではなくて「あさかい」って言うのが通例のような気がする。要は毎日プロジェクトメンバーが集まって、簡単に現在の状況や問題点を共有するショートミーティングをやるということ。時間を短く保つために立ってやるため、デイリー・スタンドアップ・ミーティングと呼ばれることもある。Martin Fowler's Bliki in Japanese - 朝会のパターン:立ってるだけじゃないよの解説がお薦め。

朝会が朝会じゃなくなってしまうとき

朝会はアジャイル開発のプラクティスの一つだけど、ツールや既存の開発プロセスとも親和性が高いので導入もしやすい。日本の会社社会ではもともと朝の訓示や連絡などの風習があったことも大きい。そして朝会そのものがオフィスでも目立つアクティビティなので、すぐに他のプロジェクトに伝染していく(アラ奥様、あの人たちは朝から立ち上がって、ナニやってんのかしら?でも、楽しそうだし、そういえはあのチームはこの前表彰されてたわよ!真似しちゃおうかしら!)。

しかし、あまりコンセプト無く導入された朝会は劣化するのも早い。

  • マネージャーが参加する定例の幹部会議が早朝にある
    • 余計なことにカリスマ経営者などがメディアで自分の超早朝出勤を自慢するのが困る
  • エースエンジニアがハッカー気取りで朝出社してこない
    • 僕は夜型です、とか。

そのうち朝会を朝に開催するのを断念して夕方にやることになって、最終的にはただの会議になる。もっと非道いと「メールで報告しましょう」ということになって、もう最初の発想から三千里くらい離れている。

朝会はリズム

ソフトウェア開発プロジェクトはチーム活動だ。ときどき「わたしの担当はここまで」と線を引くメンバーがいるけれど、物理的制限なく状況が変化するソフトウェア開発では明確な線引きは不可能だ(ただし、これは役割分担することを否定するわけではない。防衛的な線引きは難しいという話)。線が引けないので、チームメンバーと常に間合いを調節しながら、三遊間のこぼれ球を発生させないようにする必要がある。

朝会はチームのリズムとか呼吸を整える体操のようなものだと思っている。だから、その日のアクティビティを始める前にやらないとあまり意味がない。

決断の場としての朝会

朝会は決断をする場でもある。前日の活動結果に基づいて、何かをやる/やらないの判断をすることがある(「た、隊長ッ!こんな課題が見つかりました」「落ち着け!作業は中止して前提の見直しだ!」)。判断を朝会でやらなければいけないという法はないけれども、判断力は一日の中で低下していくという説もある(情報過多の現代社会で「正しい判断力」を保つ秘訣は? « クーリエ・ジャポンの現場から(編集部ブログ))。

それに、朝会で判断を求められれば日中に追加の調査や検討の時間を設けることも出来る(「その問題は、少し整理をした後に17時くらいに決めます」「明日の朝まで検討します」)。というわけで、個人的には朝会で決断していくというスタイルが好きだ。

仕事にフォーカスさせる

ソフトウェア開発プロジェクトのボトルネックには「会議」や「急な割り込み」がある。作業の不明点や不安が高まってくると、つい「会議」を開催したり、誰かに対して「割り込み」をしてしまう。朝会によって、これをある程度制御することができる。小さな不安は「必ず行われる翌朝の朝会」で報告することができるので、不安が溜まるということはないし、簡単な意思決定や決断は朝会で行うこともできる。これは別に朝にやらなくても良いという意見もあると思うが、日中にしてしまうとタイミングとしてうまくない。

というわけで、朝会はやっぱり朝がいい。