ちょっと話題の記事

議事録を制する者がプロジェクトを制する(かもしれない)

2013.05.07

スライド096

  • なぜ議事録が必要なのか

「プログラマ、半年経ったら自分も他人」という格言?があります。コードを書いたのが自分だとしても、半年も経ったら何でそのような処理を書いたのかは自分ですらもわからなくなることを指していて、コメントの重要性を認識するための言葉です。

プロジェクトについてもまったく同様で、むしろ情報の風化速度はプログラミングよりも早いものです。プロジェクト中における「言った、言わない」問題しかり、そもそも一つのプロジェクトに関わるステークホルダーの数を考えたら誤解が生じる要素はそこかしこにあります。その誤解から生じるトラブルを可能な限り防ぐ必要があります。

また情報伝達を可能な限り効率的に行う必要もあります。前エントリーに貼ったスライドにも記述しましたが、コミュニケーション自体は何も生産しません。コミュニケーションはプロジェクトを成功させるための手段であり、なるべくなら時間を節約してその分ものづくりや要求の引き出しと合意形成に時間を費やすべきです。

  • 議事録の神話

まず原則を確認しましょう。議事録に求められる最も重要なことの一つは「速報性」です。新聞記者が書くような国会答弁レベルのものを目指すと時間がいくらあっても足りません(新聞もけっこう要約になってます)。議事録そのものを手早く仕上げるための工夫をしましょう。

完璧である必要はないのです。そもそも完璧な議事録など存在しません。自己満足を除けば。

  • 準備重要!

気持ちよく手早く議事録を書くためには、事前に準備をすることが大事です。本エントリーは「議事録」について書いていますが、議事録が上手くかけるかどうかは事前の準備にかかっています。

  • 準備1. ツールとファイルの用意

まずノートPC利用前提です。紙のノートにゴリゴリ書いて、それをPCで入力し直すのは時間がもったいないです。エディタはなんでも構いません。使いやすいものを使ってください。私はいろいろ試した結果、Evernote で落ち着きました。満足はしていませんが、こういったツール類の中では(割りと)動作がキビキビしていて(ただし文書量が増えるともっさりしてくる)、簡単な装飾もできます。画像や図表を貼り付けることが出来、そのままPDF出力が可能なことも良いです。ブラウザから編集すればアプリのインストールも不要なので、環境が変わっても即、過去の議事録を参照できます。

利用するエディタで新規ファイルを作りましょう。打合せが始まってからファイルを新規作成するのではちょっと遅いです。

私はファイル名と見出しまでは事前に用意しておきます。以下、項目の説明とサンプルです。

 

■ファイル名

「◯◯様_△△△△プロジェクト_yyyymmdd」

場合によっては議題を日付の後に付けることもありますが、基本的にはこれぐらいシンプルで十分です。お客様に議事録を送る際は、メールのタイトルを「お打ち合わせ議事録をおくります(◯◯様_△△△△プロジェクト_yyyymmdd)」とします。()内はコピペ。時間節約です。

 

■見出し

  • 【日時】……(1)
  • 【場所】……(2)
  • 【参加者】……(3)
  • 【配布資料】……(4)
  • 【打合せにより決まったこと】……(5)
  • 【議事内容】……(6)

(1)日時

実施日、開始時間は決まってるから事前に書いておけますね。終了時間だけブランクで用意します

(例)2013年5月1日(水)10:00〜hh:mm

(2)場所

訪問する先のお客様の社名も当然わかっているので書いておきます。

(例)株式会社hogehoge様 △△△△室

(3)参加者

行ってみたら大勢でてきたなんてこともありますが、わかる限りは事前に書いておきます。

(例)

hogehoge ホゲ山様、ホゲ川様

クラスメソッド フガ岡、タケハラ

(4)配布資料 

これも当日になって増えることはありますが、項目として設けておきましょう。ないなら「とくになし」と明記しましょう

(例)

・hogehoge様

 ◯◯◯◯システムリニューアルに関する要求仕様書(仮)

・クラスメソッド

 課題リスト_20130501

(5)打合せにより決まったこと

これは打合せが終わった後に、決まったこと、今後やるべきことを抽出して箇条書きにします。

(6)議事内容

ここから先を打合せ中に書いていきます。 

  • 準備2. アジェンダの用意

打合せには目的があります。絶対あります。打合せに目的がないなら即刻中止にするか、目的をちゃんと作ってください。たまに「今日は一日中打合せで何も生産していない」という発言を耳にします。エンジニアは特にそのように思う傾向がありますが、数人集まって何も生産しない打合せなんてありえません。同席するメンバーと「今日は◯◯を話し合って決めてこよう」、「検討事項だった△△について、お客様が判断するための材料を提示して決定をしてもらおう」といったように打合せのゴールを設定してください。打合せがお客様先で行われるのなら、移動中にメンバーで相談ができますね。そういう時間を有効に使いましょう。もちろん機密情報や顧客名については注意して会話をしましょう。

さて、話がそれました。目的が明確になればアジェンダは自ずと作れるはずです。

★Point!

伝えるべきことを事前に書きだしておきましょう!

打合せ前にどういったことを話し合うのか…、だいたいイメージができているとは思いますが、イメージがそのまま正確に過不足なく伝えられるとは限りません。伝える能力が優れている人は即興でも上手くやりますが、私も含めてほとんどの人はそうではありません。そこで事前に、何を伝えるのかを書きだしておくことをオススメします。特に「言いにくいこと」を事前に書きだしておくと良いと思います。

更に、実際に伝えてみて思ってもみない(望ましくない)回答を得た時に、どうしておくかも事前ですり合わせができるとベストです。

打合せによっては事前にアジェンダを共有することもあります。もしくは「□□の件でご相談させてください」とお知らせしておくのも良いやり方です。打合せに参加するお客様を含めた他の人も、事前にどういった内容を話すのかわかっていれば、それなりに準備ができ(資料はなくとも心の準備ぐらいはできる)、より生産的な打合せができるようになります。

  • 準備3. 和やかな雰囲気づくり

お客様との打合せとなると、どうしても緊張しがちです。そして緊張は相手にも移ります。打合せはそもそも、お互いのもっている情報を出し合い、問題解決に向けて意見交換を図る場なので(そういう目的じゃない打合せもある)、遠慮しあって言いたいことも言えないのでは大切な時間をムダにしてしまいます。

有意義な打合せのためには、アイスブレイクなどのテクニックもありますが、最初から上手くやるのは難しいです。これは慣れの要素が大きいのですが、打合せ前にどんな話から入るかを考えておきましょう。アイスブレイクのネタを考えるのは、当然、準備1「ツールとファイルの用意」、準備2「アジェンダの用意」ができていることが前提です。

以上、ここまでが準備です。ここからが議事録をとるところになります。

取り方はいろいろあると思いますが、私のスタイルをご紹介します。

・基本スタイル

私の場合、議事録における発言の記述方法は下記のスタイルです。

<構成>

発言した内容。(発言者の名前)

<例文>

昨日、メールで検討依頼をいただいた件について相談したい。

提案いただいたA案、B案のうち、A案をベースに進めたいが、その場合、実装にかかる工数と期間はどの程度を見込んでいるか?(hogehoge ホゲ山様)

このスタイルは私の以前の職場にいらっしゃったベテランの社員さんの書き方を真似したものです。役員や弁護士など偉い人達の会議議事録で使っていたので、おそらく書き方としてはオーソドックスでどこに送っても失礼がないと思います。

この後の説明はこのスタイルがベースになります。

  • 編集に費やす時間を最小限にする

議事録をしっかり書くのは大変な印象があると思います。実際、大変なのですが、そうであればなるべく手間かけずに書ききる手段を見つける方が良いはずです。まず文末につける発言者の名前ですが、いちいち「(hogehoge ホゲ山様)」とタイピングしているのはもったいないです。打合せ中は、若干心が痛みますが「(ホゲ山)」で十分です。打合せが終わった後、エディタの置換の機能で「ホゲ山)」を「(hogehoge ホゲ山様)」に変えればいいだけです。

ちなみに主旨とはズレますが、これをやると議事録の見た目が一気に格調高くなります(そんな気がします)。

  • 要約しながらメモをとること

会話の速度と同じ速度でタイピングができればいいのかもしれませんが、そんなこと出来る人は稀です。そうでなければ速記者という専門職は成立しませんよね。会話に対してタイピングが追いつかないのは当たり前です。

だから要約をします。これはコツが必要ですが、いくつかのポイントを抑えるとできます。

まず、口頭で喋る発言は文章にするとだいたい冗長になっています。先ほどの例文が口頭で発言された時を文章化してみましょう。

<例:口頭の発言をそのまま文書化(極端に冗長)>

昨日、メールで送ってもらった、いくつかの案から選ぶ件について、検討するように依頼をされたわけだが、その件について話をしようと思うのだが…。

昨日のメールで送ってもらって提案してもらったA案とB案の2つのうち、私としてはA案をベースに進めたいと思っています。が、A案にした場合、こちらとしてちょっと考えているというか、どんなものなのか気になっているのは、仮にそれで進めた場合、実装にかかる工数とか期間って、例えば何人日とか、何日間といったそれぐらいの単位で、どの程度の工数と期間をいまの時点で見込んでいるかを、だいたいでかまわないので教えてもらってもいいですか?(hogehoge ホゲ山様)

これで275文字です。

人は発言をする際、相手にわかって欲しくて伝えたいポイントを同じ文章の中で繰り返し言うものです。形容詞や修飾語も繰り返し登場しがちです。また、相手に気を遣って発言することがほとんどなので、表現がどうしても冗長になります。

こういった要素は議事録においては必要ではないので(あえて入れる場合もあるけど)基本的にはタイピングしません。

<例:要約した場合>

昨日、メールで検討依頼をいただいた件について相談したい。

提案いただいたA案、B案のうち、A案をベースに進めたいが、その場合、実装にかかる工数と期間はどの程度を見込んでいるか?

これで87文字です。

このように、大幅に削ってタイピングの量を減らしていきます。会話の雰囲気を入れたい場合は削る量を減らすこともありますが、発言の主旨を押さえることと前後の流れが最低限必要なので、それを優先します。

要約をするには、ちょっとくどいようですが、打合せ前の準備をしっかり行なって、どういった発言がでるのかある程度予測をしておくことが必要です。また、発言主旨が変らないことが前提で作文してしまうこともあります。

いずれにしても完璧に書き写そうとすると苦労するわりには確実に破綻します。もしくは速報性が損なわれて議事録の意味がなくなります。なるべく最小限の労力で、楽して書くくらいの気持ちでやりましょう。

  • 内部レビュー

議事録に限った話ではありませんが、一人で文章を書いてそれを完璧に仕上げるには結構な時間がかかります。1時間の打合せなら、ヘタするとその倍はかかるかもしれません。そもそも議事録をそんな時間かけて作っていては肝心の速報性が損なわれるので、書いたらさっさと内部レビューに回します。内部レビューの対象者は打合せの同席した人達です。

内部レビューを行うことで、議事録の抜け漏れや間違いに気が付くことができます。レビューを依頼された人もなるべく早く対応しましょう。

またこのレビューの時に「【打合せにより決まったこと】」を抽出しましょう。議事録は、記録に残すことも大事ですが、打合せで何が決まり、何をやることになったのかを共有することも大事です。

  • 議事録の共有

1時間の打合せ議事録なら内部レビューは5〜15分もあれば読めますよね。指摘したことを修正してもらって更に5〜15分。打ち合わせ中に要約しながら書くことができていれば、打合せ終了後30分以内で議事録を送ることができるわけです。30分間費やすことで情報伝達が円滑にできるようになるならそれはとても良い投資と言えます。こうすることでチームメンバーとのやりとりも要点が絞られるのでコミュニケーションも効率的になるでしょう。

  • まとめ

ここまで議事録をベースに打合せに対してどのように準備を行うかを説明しました。プロジェクトというよりは、そもそも仕事をする上での基礎的なことではありますが、こういったことを丁寧にこなしていくことでプロジェクトにおけるコミュニケーションのムダを省くことが出来ます。また、お客様上層部、社内上層部へタイムリーに情報を共有することで、プロジェクトが軌道から逸れた時の軌道修正を迅速に行うことができるようになります。プロジェクトの後期で「言った、言わない」の不毛なやり取りを避け、いざというときにステークホルダーで協調して問題解決にあたるための最低限の準備です。

また、議事録はお客様も含めて情報伝達の中心になることもあります。情報伝達の中心になるということは、プロジェクトをコントロールするのに最も有効は手段でもあります。

「情報を制するものが世界を制する」

というのは昔から言われていることですが、議事録を制してプロジェクトを制しましょう。

次回は、作成した議事録をベースにプロジェクト計画のたたき台を作る方法を解説します。