朝会を15分で終わらせるには理由がある：初めてのプロジェクトリーダー（3）

1. 朝行う
2. 15分以内で行う
3. 全員が参加し、全員が発言する
4. 各自は、昨日やったこと、今日やること、問題点の3点のみ簡潔に話す
5. 立ったまま行う

　これ以外の具体的な運営方法については、オブジェクト倶楽部（ファシリテーション）を参考にするとよいでしょう。ここでは、リーダーとしてどのように朝会にかかわるとよいか、ポイントだけを説明します。

［朝会のポイント1］ チームの状況を語る

　 まずは当たり前の話なのですが、個人タスク以外に、チームがいまどういう状況なのかを簡単に語ってください。登山に例えるなら、いまは何合目にいるのか、天候はどうなのか、を伝えることになります。具体的な例だと、「お客さまとのユースケースのレビューは順調に消化されていて、10本中、5本が完了している」「揺れている要件がある。仕様の変更がありそうだ」などです。

　ただし、あまり詳細に語り過ぎると、かえってメンバーが混乱する場合があります。それは、仕様や方針の変更の揺れ幅が大きいプロジェクトの場合です。この場合、情報が日単位で矛盾してくるため、メンバーがお客さまや、プロジェクト、それに、あなたに不満を持ちやすくなり、チームのモチベーションが低下します。

［朝会のポイント2］ メンバーの顔色をうかがう

　朝は、メンバーのモチベーションが一番よく分かる時間帯です。仕事が楽しくなってきて「早くコード書きたいなあ」と、うずうずしているメンバーもいるでしょうし、仕事が進まなくて、暗い顔をしているメンバーもいるでしょう。うずうずしているメンバーばかりの場合（開発のピーク時など）は、さっさと朝会を切り上げてしまってもよいでしょう。暗い顔のメンバーが増えてきた場合は、朝会の時間を長めに取る、あるいは朝会の後すぐに別のテーマで集まります。会話を増やし、「いま、どんな問題が起きているのか」を、話し合いましょう。

［朝会のポイント3］ アクセル＆ブレーキ

　朝会は、チームのスピードを上げる（アクセル）、下げる（ブレーキ）貴重な場だということです。ここでのスピードとは、成果物を生み出す速度だと考えてください。スピードに乗っていない（スケジュールに遅れが出ている）場合は、問題点をメンバーから聞き出したうえで、正直に、速やかに終了させてほしいことを伝え、スケジュール最優先で作業を進めることをお願いしてください。

　ここで大事にしたい原則は、「管理というよりは演出」です。時と場合にもよりますが、ベテランのメンバーには、頭ごなしに「早く終わらせろ」と、命令するのではなく、「無駄な作業を行っていませんか？ 現時点で本当に必要なのは、○○機能だけですよ」と、状況を説明し、作業目的をクリアにします。経験の少ないメンバーの場合は、タスクの分割を検討し、作業手順をクリアにします。逆に、スピードを下げたい場合は、「今日はさっさと帰りましょう」と伝えてください。ついつい前倒しで作業を進めたくなる気持ちは分かりますが、特に、仕様などが安定していない場合に、先に進んでしまうのは危険です。勇気を持ってスピードを落とすことも必要です。

・進捗会

　次に、大きな会議の代表として、進捗会を取り上げます。ここでは、お客さまを交えての進捗会を想定していますが、以下に説明するポイントは、内部の進捗会にも、もちろん役立ちます。

・成果物ベース

　進捗報告の単位は、極力成果物ベースで行います。成果物とは、つまり要件定義書などのドキュメントであり、XYZアプリケーションなど「動くもの」で、両者ともお客さまにとって価値あるものです。「何々をしていました」などいうやったことの羅列は、お客さまに直接的な価値を直感していただきにくいものです。

　ドキュメントや、アプリケーションを徐々に提供する場合は、バージョン番号（第1版や、β版など）を使って分割し、進捗度の目安を提供します。 また、報告すべき項目として、担当者、期限、状態（「作成中」や「完了」「レビュー結果待ち」など）は、最低限必要でしょう。

・課題の共有

　進捗会の重要な目的の1つとして、課題の共有があります。課題を選択するうえでのチェックポイントは、お客さまの価値を損なうような問題、つまりシステムの要件を満たせなくなるような問題が発生していないかどうか、です。お客さまが直接興味を抱かないようなことを事細かに説明するのは、意味がないどころか逆効果です。今回の連載で想定しているようなWebアプリケーション開発プロジェクトであれば、以下のような技術的な問題が発生する可能性があり、これらをクリアすることがそのまま課題となります。

• 採用したアプリケーションサーバと、データベース製品の組み合わせでは2フェーズコミットが利用できないことが分かった
• 他システムとの連携が必要だが、接続試験をしたところ、十分なパフォーマンスが出ない
• Webブラウザの能力を超えた操作性を実現する必要がある

　本来ならば、このような問題が発生しないように、あなたは事前に技術的な検証を行う必要がありますが、場合によってはあなたがリーダーとして着任した時点で、すでに「すべて決まったこと」状態となっていることもあるでしょう。

　問題は技術面だけで発生するとは限りません。技術だけでは解決できず、お金や政治の問題になりそうな場合は、早めにプロジェクトマネージャや、お客さまと相談してください。リーダーだからといって１人で抱え込んではいけません。

・次のアクション

　進捗を確認し、課題を共有した後は、次のアクションを決める必要があります。課題が新たに見つかった場合は、それをつぶすのがアクションになりますし、課題がない場合にも次の成果を生み出すためのアクションが必要になります。もちろんアクションは、あなたのチームだけではなく、会議に参加しているお客さまや、ほかのチームも割り振られます。会議を終えてしまう前に、参加メンバー間でそれぞれが認識しているアクションを洗い出し、アクションリストを作成する時間を設けましょう。次にすべきことが分からなくなるような会議にしてはいけません。もし、うやむやに会議が終わりそうになったら、あなたが食い止めてください。

・議事録

　朝会に議事録は必要ありませんが、進捗会など、お客さまとの会議には議事録が必要です。もちろん、議事録もいったことの羅列になってはいけません。目的、課題、アクション原則に従って「とても真剣に」書く必要があります。

　会議に、誰が何の目的で集まったのか、そこでどのような結論が出たのか、どんな課題が発生していたのか、その解決に向けて、誰が、いつまでに、どのようなアクションを取る必要があるのか、これらの情報が漏れなく、簡潔にまとめられているのが理想です。しかも、会議に参加しなかったメンバー（主にお客さまや、プロジェクトマネージャ）が「さっと」読んで理解できなくてはいけません。

　文書のフォーマットは、お客さまや組織の文化に合わせればよいですが、書く内容は常に、上に挙げた基準を満たしているかチェックしてください。質の高い議事録を書くのはかなり大変ですが、質の高い議事録を書こうと意識していると、目的や、結論がうやむやだったり、アクションが見つからないような会議に参加した場合に、会議を正しい方向に導くことができるようになります。本末転倒のようですが、「議事録に書けないような会議は困る」というわけです。

・誰が議事録を書くべきか

　あなたが育てたいと思っている若手がいるなら、その人にぜひ、議事録を書かせてください。ただし、あなたがまだ本当の議事録を書いたことがないのであれば、まずあなたが書くべきです。

　特に予算の都合で、リーダーが、設計、実装などの開発作業を行うことも珍しくありません。極力リーダー業に専念できればベストなのですが、そうはいってられないことが多いのは事実ですし、まだまだ「現場で開発したい」というリーダーも多いでしょう。次回は、兼任リーダーとしてどのように振る舞うのがよいのかを説明する予定です。