要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

会議の種類は2種類のみ、プロジェクトを成功に導く会議の進め方

はじめに

会議は踊る、されど進まず

という言葉がある。

ウィーン会議は、フランス革命ナポレオン戦争終結後のヨーロッパの秩序再建と領土分割を目的として、オスマン帝国を除く全ヨーロッパ各国代表が集まり、1814年9月1日から開催された。

(省略)

1792年より以前の状態に戻す正統主義を原則としたが、各国の利害が衝突して数ヶ月を経ても遅々として進捗せず、「会議は踊る、されど進まず」と評された[2][3]。

出所:wikipedia ウィーン会議

とあるように、会議をするものの、状況が全然進展しないことを揶揄した言葉だ。日本でも、会議はネガティブなイメージを持たれることが多い。会議で検索すると、「会議 無駄」という言葉が関連キーワードで出てくるぐらいだ。

しかしながら、筆者は会議が無駄ではないと思っている。使い方次第では、仕事の進捗を大きく進めるのに役立つものだからだ。今日は、会議の進め方について紹介する。

会議とは何か

wikipediaで確認すると、会議とは、次のような意味であることがわかる。

会議(かいぎ)は、関係者が集まり、特定の目的(議題)に関して意見交換・審議し、合意・施策などの意思決定をすること、およびその物理的構成員の集まりを意味する。

出所:wikipedia 会議

会議というのは、関係者が集まらないとできないことについて開催されるものだ。関係者を集めなくて良いならば会議をする必要はない。会って議論するから、会議なのだ。

会議の種類は2つしかない

会議の種類は大きく分けて2つある。ネットなどで調べると色々な種類の会議が紹介される。が、覚えきれないので、筆者は2種類に分類している。会議の種類は、下記の2種類だ。

  • ①認識合わせ
  • ②意思決定

①認識合わせ

会議というのは、関係者が集まって議論すべきものだ。議論すべき対象は、もちろん問題の解決についてである。問題とは何かについては下記参照。

req-definer.com

問題はあるのかないのか?何が問題なのか?を関係者で認識を合わせなければならない。認識を合わせる対象は

  • 本来あるべき状態
  • 現状どうなっているか
  • あるべきと現状で差異はあるか

である。上記の3つを常に確認することで、問題があるのか?問題は発生しそうか?を関係者で共有できるようになる。問題について関係者で認識を合わせなければ、そもそも問題に対して適切な打ち手を考えることができない。だからこそ、会議で認識合わせが必要なのだ。

よくある認識合わせの会議としては、定例進捗会議などが該当する。

例えば、

  • あるべき:3月までに、機能Aが完成している
  • 現状:2月末時点で進捗80%

というふうに、進捗の認識を合わせる機会は多々あるであろう。順調でも順調でなくても進捗会議は開催される。順調になると進捗会議が必要なのか、という意見が出てくるかもしれないが、順調である(すなわち、現状は問題が発生していない)という認識合わせも、今後のうち手を検討する必要があるのかないのか明確化するうえで重要なのだ。

②意思決定

問題がなければ良いのだが、問題が発生している、もしくは、発生しそうであるならば、対策を打たなければならない。対策を打つということは、お金を使う、もしくは、人を動かすことを意味する。それらの承認権限のある者の合意を取り付けることが、意思決定の会議でやるべきことだ。

例えば、機能Aの開発進捗が遅れているとする。遅れがあるならば、進捗を挽回しなければならない。進捗が勝手に挽回されることはない。挽回する対策を打って、はじめて挽回される。対策として、機能Aの開発スコープを縮小するのか、納期を遅らせるのか、内製で進捗を加速するのか、委託で進捗を加速するのか、対策案は色々ある。それらのメリデメを検討して、意思決定者に決めてもらう必要があるのだ。

会議の進め方

会議の進め方を説明する。認識合わせの会議でも、意思決定の会議でも、やり方は同じだ。

会議前にやること

会議前にやることは、会議および会議後の作業をスムーズに進めるために必要なことだ。段取り八部という言葉がある通り、会議前にやることが1番大事だ。

アジェンダの用意

会議をスムーズに進めるためには、何について議論をしたいのか、あらかじめ認識を合わせる必要がある。たいてい、それらはアジェンダと言われる。書籍の目次みたいなものだ。アジェンダのない会議は、出席者を不安にさせる。何を議論すれば良いのか、何かアクションは必要なのか、それらがわからなければ、会議は発散するし、進まない。だから、アジェンダを用意しよう。

議事録の用意

議事録は会議後に書くものではない。日時、予定参加者、議題がわかっているのだから、会議前に書いてしまえばよい。理想的には、想定される結論も用意しておくと良いだろう。そうすると、次のアクションを想定して準備することができる。筆者の場合は、アジェンダをベースに議事録を作っておき、結論だけ埋めて議事録を展開するというやり方をしている。

資料の用意

最近は、ありもので構わないという風潮があると感じているが、筆者としては、会議資料に関しては、なるべくしっかり作ったほうが良いと考えている。必要だから会議を行うのに、使用する資料はありものでいいという理屈は理解しかねる。ただし、聞き手がその資料の概要をすぐに理解できるならば、資料は使いまわしても良い。実務者向けの資料を幹部向けに見せるのは良くないと考える。見るべきポイントが違うからだ。ありもので良いとしても、最低限、どの資料を参照して、誰が、どんな意思決定したのかをわかるようにしておくべきだ。そうしないと認識合わせや意思決定の履歴が残せないからだ。

資料として記載すべきことは、あるべき状態と現状、および、そこに差異があるかないかだ。差異が有れば問題あり、差異がなければ問題なしとなる。問題があるならば、なぜこうなったのか、今後どうしたいかを記載する必要がある。会議は問題解決に向けてアクションを決める場だ。意思決定者に何をして欲しいのかわかるような記載をしよう。

システム開発の現場で例えると、顧客の要件(いつまでに、何を)とシステムの現状を資料として用意し、進捗通りかそうでないかを記載する。進捗通りでなければ、人が欲しいのか、お金が欲しいのか、他の協力を仰ぎたいのか、書くこととなる。

会議中にやること

会議でやることはシンプルだ。認識合わせと意思決定。これができればそれで良い。ファシリテーションスキルなんて無くても良い。

上記の作業を徹底をすれば、会議として成立するであろう。関係者間で、認識合わせと意思決定ができればそれで良いのだから。

会議後にやること

会議後の作戦会議(社外との会議後の場合)

会議中、宿題事項が出る場合がある。その宿題の対応について、上司と相談が必要な場合があるため、会議後にすぐ相談できる場を持とう。進め方を相談するだけなので、15分で良い。

議事録の発行

議事録をすぐに出そう。会議前に作った議事録に書き込むだけで良い。あまりかしこまった会議でない場合は、会議後30分以内にメール展開できると良い。

社外との打ち合わせならば、上司の承認が必要なので、次の日くらいに出せると良い。大切なのは、速さだ。間違っているなら指摘してもらえばいいだけの話だ。割り切って発行しよう。

宿題事項の刈り取り

会議で出てきた宿題事項を刈り取ろう。この刈り取りをしっかりやらないと、会議をした意味がなくなる。役に立たないと言われる会議は、ここが甘いのだ。宿題を刈り取らねば、まさにやっただけの会議となり、問題解決を進めることができない。しっかり宿題を刈り取ろう。

終わりに

会議をする理由は、問題解決を関係者で効率的に行うためだ。

req-definer.com

炎上(上記記事参照)を起こさないためにも、会議をうまく活用していこう。

結論:会議を主導しよう