Hatena::ブログ(Diary)

TECH-moratorium : テクモラトリアム このページをアンテナに追加 RSSフィード

2011-02-25

[][]議事録を書くときに意識すべきこと

開発現場であってもそうでなくても議事録を書く機会は多いのですが、意外に役にたつ議事録を書くのは難しいものです。ということで、以下自著『プロジェクトを成功させる現場リーダーの技術』より議事録の書き方をまるっと引用。キーワードは「目的・課題・アクション!」です。

会議は避けられない

一口に会議といっても、あらかじめ計画されている定例的なものから、突発的に発生する小さなプロジェクト内ミーティングにいたるまで色々ですが、プロジェクトがさまざまな人との協調作業であり、プロジェクトの生み出す価値がたくさんの利害関係者の合意によって成り立つ以上、会議は必要かつ重要な活動です。実際、大規模プロジェクトでは、プロジェクトの計画段階でコミュニケーション計画として会議体が定義されます。世の中無駄な会議が多すぎると嘆かれながらも、実際問題として、プロジェクトは会議によって進んでいるというのも事実です。

現場リーダーをやるからには、これらの会議を避けて通ることはできません。むしろ積極的な関与が必要となってきます。現場リーダーとして議事を進行する場合もあるでしょうし、そうでない場合でも責任のある発言が求められます。このように何かとプレッシャーのかかる会議ですが、議事録を活用することでよりスムースな運営を行うことが可能です。

議事録の目的

まず参考までに、首相官邸の高度情報通信ネットワーク社会推進戦略本部による、「IT戦略本部」の議事録を見てみましょう。基本的なフォーマットは以下のようになっています。

  1. 日時:会議の開催された日程を15分単位まで細かく。
  2. 場所:開催場所について部屋まで細かく。
  3. 出席者:各出席者の肩書きまで細かく。
  4. 会議の模様:会議の出席者の発言内容や会議の段取りについて、詳細に記録。例えば、「担当大臣が有識者を紹介した。」や、総理大臣の挨拶について、出だしの挨拶から含めてもれなく紹介

いきなり言ってしまいますが、これでは0点の議事録です。ビジネスの現場でこのような議事録を書いてはいけません。これは、政府が国民に向けて行っている「サービスの一部」であるから許されることだと考えてください。

まず、日時や場所・出席者に関しては良いでしょう。これらの情報は忘れなければ問題ありません。出席者の肩書きは、間違いなく記述するよう気をつけましょう。

問題は、内容である「会議の模様」です。たしかに、発言についてもれなく記述はされていますが、いったい何のために、つまりどんな目的で、IT戦略会議を開催したのか、その意図が分かりません。内容を詳細に読んで、総理大臣や担当大臣の発言を追っかける必要があります。実際に私も呼んでみましたが半分も読まないうちに断念し、結局、目的と結論はわかりませんでした。IT戦略会議の議事録は、単なる発言集であって議事録とは呼べません。「朝早くからお集まりいただき云々」などといった挨拶の内容まで詳細に議事録として公開することに何の意味があるのでしょうか。

意義のある議事録を書くためにはポイントがいくつかあります。まずは、読み手を意識しなくてはいけません。会議の種類や参加者によって議事録の目的も多少は変わりますが、特にお客様やプロジェクトマネージャなどの重要な関係者が読む場合は、手短に、しかも正確に書く必要があります。お客様は暇ではないのです。

次に、ストーリーが見えること、しかもその会議中の流れだけでなく、プロジェクト全体を通じたストーリーが見えなくてはいけません。議事録を追うだけで、プロジェクトがどのような歩みをしてきたのか、簡単に追跡できるのが理想です。

最後に、それほど時間をかけずに書けること。会議が終わってから1週間後に議事録が出てくるのでは遅すぎるでしょう。また、議事録を書くために本来の作業ができなくなるのは本末転倒です。

議事録も「目的・課題・アクション」

では、このようなポイントを踏まえた議事録を書くにはどのようにすれば良いでしょうか。答えはおなじみ「目的・課題・アクション」です。プロジェクト自体を目的・課題・アクションで進行する以上、プロジェクトの記録である議事録も、この枠組みに沿って記述するのは理にかなっています。

議事録には、次の内容を必ず記入するようにします。

  1. 日時
  2. 場所
  3. 出席者
  4. 目的
  5. 結論
  6. アクション
  7. 議論の内容
  8. 次回予定

1番から3番に関しては問題ないでしょう。「首相官邸方式」で良いです。ただし、出席者を書く順番や、肩書きの書き方などについては組織の文化に合わせてください。基本的に「お客様から、偉い人から、肩書きは間違わないように」書けば間違いありません。

それよりも大事なのは、目的と結論です。どのような目的でこの会議を開いたのか、正しく簡潔に書く必要があります。そして、その目的に対してどのような結論が出たのか、これも簡潔に書きましょう。注意点として、目的と結論は読み手の立場から見て分かり易いように記述する必要があります。いきなり各論に入らずに、本質的な内容を書くよう心がけてください。

アクションも目的や結論同様に重要です。目的から課題を導き出し、適切にアクションを設定したのであれば、結論から次回の予定にストーリーがスムースにつながり、プロジェクト全体のストーリーも見えやすくなるはずです。もちろん、前節での定義に従い、アクションには担当と期限を明示してください。

各論や、議論の内容、重要な発言に関しては、補足に近い形で「議論の内容」に書きます。これが、首相官邸方式の「会議の模様」に相当する部分です。ただし、発言についても要約して書くようにしてください。議事録全体のボリュームが大きくなりすぎないよう気を払うことで、議事録を書く時間を短縮することができます。

議事録ドリブンな会議とは

次に、より積極的に議事録を生かすテクニックとして、「議事録ドリブンな会議」を提案しましょう。ちなみに、「ドリブン」とは駆動する、という意味で、議事録を中心にした会議運営術を意味しています。

ここまでの説明でお気づきかとは思いますが、「目的・課題・アクション」軸に沿った議事録を書くのは、実は簡単ではありません。かなり真剣に書く必要があります。

これはなぜでしょう?逆説的な言い方をすれば、それは会議自体がこの軸に沿っていないからなのです。実際問題、目的すら良く分からない会議が開催されることすらあります。このような会議に参加してしまった場合に、自分は関係ないや、と放っておくのもよいですが、あなたのプロジェクトに影響を与える会議の場合はそうもいきません。

以降、現場リーダーのあなたが仕切っている・仕切ることができる・仕切る責任がある「ホーム」会議と、あなたが仕切っていない・仕切れない・なぜか呼ばれてしまった(迷走気味の)「アウェイ」会議に分けて、議事録ドリブン会議の運営方法を「目的・課題・アクション」軸に沿って、それぞれ説明してみましょう。

特に迷走するアウェイ会議の場合は、議事録が書けません。それを、「議事録が書けない会議は困る」とばかりに、型にはめるのが議事録ドリブンな会議運営なのです。

目的を確認する … ホームの場合

定例のプロジェクト進捗会議の場合、まずは前回の議事録を使って、今回の目的について確認します。前回議事録の次回予定が、そのまま今回の目的になるはずです。また、前回から今回の間に新たな議題が発生している場合は、その件についても目的に加えて、事前に合意しておきます。

ホーム会議はあなたが進行を行いますので、この段階で目的をきっちりと確認することができますし、多少の問題提起による脱線もありでしょう。

目的に食い下がる … アウェイの場合

まずは、目的について食い下がってください。悲しいほど目的意識のない会議の場合がありますが、このような会議は結論が出ることは期待できません。あきらめずに、最低限の目的の共有と合意をして、会議の道筋を作ってあげる必要があります。ここでのポイントは、あまり話を広げすぎないことです、参加者の大半が理解でき、議論ができる範囲の現実的な目的設定が良いでしょう。今後も開催が必要な会議の場合は、会議の後の議事録を含めたフォローでストーリーを組み立てなおす必要があるかもしれません。

ただし、ここで目立ちすぎると余計な反感を買ったりして、いろいろと面倒なことになる可能性もあります。そういう意味からも、話は広げすぎずに抑えておくことも必要です。熱くなる気持ちを押さえ、冷静に淡々と話しを進めます。

課題を共有する … ホームの場合

進捗会議の重要な目的の一つとして、課題の共有が挙げられます。現在、プロジェクトはどのような位置にいて、どのような課題があるのか。それに対してそれぞれどのような活動を行っているのか、複数チームで構成されるプロジェクトの場合、特にこの課題共有は貴重な時間となります。

それぞれの課題がプロジェクトチーム全体にどのような影響を与えるのか、顧客満足志向の視点に立って、情報を共有します。

課題を掘り起こす … アウェイの場合

そもそも、課題が見えない場合が多くなります。目的がよくわからない以上、自然とそのようになってしまいます。何か会議らしいことをしているのだけど、何故か現実的な感じがしない場合は、課題がまだ見えていないことが多いのです。進捗会の場合であれば、プロジェクト固有の問題点などについて言及されずに、一般論に終始したぼんやりとした話が多く、単にやったことの羅列を報告しだした場合は要注意です。このような場合は、どのようなプロジェクト固有の課題があるのか、そしてそれがプロジェクトの価値にどのようなインパクトを与えるのか、そのあたりを切り口に、まずは「課題を重視する姿勢」を意識してもらうように働きかけましょう。

次のアクションを決める … ホームの場合

会議の締めはアクション決めです。ここまで順調に進んでいるのであれば、自ずと、誰(あるいはどのチーム)が、どの課題について担当するのか、明らかになっているはずです。担当と期限を決め、次回の開催についての決め事を行って会議をクローズします。順調に進んだ会議であれば、議事録を書くのにそれほど時間はかからないはずです。想定していたストーリーにそって議事が進行している場合は、その内容を議事録という形で外部記憶化しておく感覚で進めることができます。

今のアクションを確認する … アウェイの場合

おそらく、迷走するアウェイ会議の建て直しは一回ではできません。根気よく付き合っていく必要があるでしょう。できれば関わりたくないところですが、そうはいきません。このような状況では、いったん立ち止まるのが良いでしょう。次のアクションを急いで決めるのではなく、今何ができるのか、どのようなことを行う必要があるのか、「今のアクション」を決めるよう提案してみましょう。

ただし、ここで「議事録ドリブンでいきましょう」などといって、明示的に型にはめてしまってもうまくいきません。議事録ドリブンとはいっても、それは進め方を表す表現の問題であって、会議は議事録に書くために行うものではありません。

誰に議事録を書かせるか

議事録を重視する以上、議事録係は重要な役割となります。あなたのチームのメンバーのうち、最も期待するメンバーに書かせてください。質の高い議事録を書くのは難しい作業なので、とてもためになります。議事録で鍛えた能力は、あらゆるビジネス文書に応用することができます。

もちろん、あなたがまだ本当の議事録を書いたことがないのであれば、まずはあなたから始める必要があります。

改定版である『チームビルディング』には具体例など内容が追加されてたりしますので、興味ある方は読んでみてください。

2010-11-06

[][]組込みプレスVol20

本日発売の組込みプレスVol20の特集2「ICTから学べ〜これからの組込み開発者に求められるスキル&マインド」に、永和システムマネジメントのメンバーが執筆しています。

組込みプレス Vol.20

組込みプレス Vol.20

「第2章 コンポーネント指向による要求分析/ 設計の実際〜UML/DFDの活用」と「第3章 組込み開発でテスト駆動開発は有効か」がそれです。いずれも現場で主導的な立場で動きつつ、バリバリ開発をしているメンバーによる実践的な内容が特徴となっております。

まず第2章。コンポーネント指向は組込み開発でも取り入れられつつあります。筆者の藤井さんはそれを現場で実践し、UMLだけでなくDFDを組み合わせたモデリングをしています。実情に合わせた工夫をしているのがユニークで実戦的です。

第3章の筆者森さんは、アジャイルの肝となるテスト駆動による開発が、組込みでも使えるのかどうか、テストツールやカバレッジツールの説明を交えながら解説しています。

また、今回の特集のもう一つの特徴は「コラボ」です。第1章では、自動車業界におけるTier1サプライヤである三井金属アクトさんによる「MBDを品質確保とコスト削減に利用する」という取り組み。第4章は全社的に要求開発に取り組まれている大阪NDSさんによる、「組込み分野における要求開発」という取り組み。いずれも弊社とのご縁から、今回の特集に協力していただいております。

第1章・第4章とも、「これからの組込み開発者に求められるスキル&マインド」という大きなテーマにフィットするように、それぞれの業務における実体験を抽象化し書いていただきました。

組込み開発者に求められるスキルは年々高まり、必要となる知識もIT関係だけでも広がる一方である。機能が複雑になればなるほど、コアロジックや特定分野の制御技術だけでなく、ネットワーク機能やユーザインターフェースといったレイヤの機能開発も避けられない。ひと言でいうなら、組込みデバイスとPCの境界がますますあいまいになり、それぞれの応用分野におけるオーバーラップが大きくなっている。

このような大規模開発では、専門分野ごとにモジュールコンポーネントの分離、分業が進んでいるが、製品やシステムの設計者、マネージャは全体を把握する必要がある。現場の開発者も、プロジェクトの規模によっては、自分がカバーしなければならない領域が得意分野や専門分野とは限らない。

この特集では、ICTというアプリケーション開発やシステムインテグレート(SI)という視点から、組込み開発にも応用できるプラクティス、開発スキームはないだろうかということを掘り下げる。

以上は特集の扉ページからの引用ですが、あらためて第1章から第4章まで読んでみると、随分幅広いテーマになったものだと感じます。エンジニアには当然スキルが必要ですが、同様に「もっとよいものを、もっとよいやり方で作りたい」というマインドも大切です。具体的なスキルについては第1章から第3章が、マインド面については主に第4章がカバーします。現場で実際に開発をされているエンジニアから、マネージャ層まで、幅広く読んでいただける内容になっていると思いますので、是非一度手に取ってみてください。

2010-01-16

[]仮面ライダーSE

VS(バーサス)、じゃなくてフォームチェンジするみたいにしなやかにやれたらいいと思うんだ。

プログラミングフォーム

変身アイテムはスマートフォン。プログラミング言語を武器に闘う攻撃的フォーム。戦うたびに「言語」のスキルが向上し、しばしば複数の言語スキルを持ったライダーが生まれる。

通常は帰宅すると変身を解除するが、まれに変身状態のまま日常生活を送る者もあらわれる。彼らは時に「世界の変革者」となり、さらに「世界の破壊者」となる者も。

必殺技
  • 「ソーシャルネットワーキング」

スマートフォンとネットワークを駆使し、仲間のライダーから情報と知恵を授かることでパワーアップする。

マネジメントフォーム

変身アイテムは名刺カード。プログラミングフォームからフォームチェンジする。「肩書き」と呼ばれるシンボルによってパワーを変化させることができる防御的フォーム。プログラミグフォームに比べるとやや丸みを帯びた形態となる。

「ステークホルダ」と呼ばれる者たちとの調整が必要となるときに現れるプロジェクトの守護神との伝説があるが、フォームチェンジしただけでは、その能力を全て発揮することは難しい。このフォームにも訓練が必要なのだ。

必殺技
  • 「伝家の宝刀」

マネジメントフォームのまま、プログラミングフォームの技を発動させること。難局を乗り越えることができるが、自身やプロジェクトを弱らせる副作用もある。

最後に

すっかり明けてしまいましたが、2010年もよろしくお願いします。今年は軽やかに、しなやかにいきたいものです。

2008-11-08

[]日経コンピュータフォーラム2008で講演しました

180人の前、地に足がつかない状態でお話しさせていただきました。

f:id:HappymanOkajima:20081107142117j:image

いっしょに講演したNRIの永井さんのお話も、グローバルナレッジネットワークの田中さんのお話もとてもためになりました。内容についてはid:mnishikawaさんの日記が詳しいので一度ご覧ください。

http://d.hatena.ne.jp/mnishikawa/20081107/1226072999#tb

永井さんは、経営者も含めたリーダーシップ、田中さんは若手育成がテーマで、私のうけもちは「開発現場」でした。朝会やふりかえりの紹介と、私のチームビルディグに対する考えを発表させていただいてます。できるだけ泥臭い感じにしたかったのですが少し一方的に話し過ぎたと感じています。今思えば途中で一度ワークを入れた方が良かったかも。(永井さんと田中さんのワークは良かった。流石です)

3人ともテーマは違えど、共通していたのは「何か変えたいならまず自分から」ということ。自分を変えることならいつでもスタートできます。『受託開発の極意』の裏テーマはそうなのですが、ますますその想いを強くすることができました。

ちなみに、私の勤め先・私の著作を知っている方は会場の10%程度の人でした。どちらもまだまだ潜在マーケットがあるということで嬉しくなりますw。

最後になりましたが、参加していただいた皆様、ありがとうございます。何か少しでも皆様の現場の参考になれば幸いです。そしてスタッフの皆様、ありがとうございます。丁寧な対応で、気持よく参加することができました。永井さん田中さん、お話もさることながら、緊張しがちな場で気さくに接していただきありがとうございます。また、このような場に推薦いただいた西河さん、ありがとうございました!

2008-07-17

[][]計画に生命を吹き込むフォローアップ〜『計画の科学』

「計画力を強くする」の加藤昭吉さんの本だったので、古臭いと思いつつ買いました。この本は1965年に書かれており、当時アメリカで熱狂的に流行っていたというPERTについての解説本です。

計画の科学―どこでも使えるPERT・CPM (ブルーバックス)

計画の科学―どこでも使えるPERT・CPM (ブルーバックス)

『計画力を強くする』でも感じたのですが、加藤さんの本は熱いところがいいです。「科学する」というと機械的な感じがしますが、むしろ人間くささを感じます。特に第6章「フォロー・アップ(計画の追跡)」は必読でしょう。とても印象に残った一説を引用します。

仕事の上の計画もこれと同じで、できあがったネットワークを格好がいいからというので壁にはって見ているだけでは<人生計画>を立てて努力を忘れたようなもので、待っているのは酔生夢死の末路である。したがって、計画を計画通りに運ぶ努力を怠ってはならないが、場合によっては条件の変化に調和して計画の内容を修正しながら所期の目的を達成する技術をしっておかないといけない。

この後に、実際にPERTのネットワーク図をフォローアップする方法が説明されています。米軍のポラリス・ミサイル計画では、2週間に一度フォローアップを繰り返したらしいです。(具体的なやり方に興味のある方は本を読んでみてください)。

他にも「三点見積と確率」など、現代のソフトウェア開発者にも役立つ手法も説明されています。オススメです。