書籍「実践バグ管理」執筆体験記(1) - 執筆プロジェクトのミーティング
どうも、あかさたです。本記事は「実践バグ管理」の執筆の流れを時系列に追いながら、書籍執筆プロジェクトをどのように進めていくか紹介する連載の第三回目です。前回は見積もり(工数とスケジュール)と執筆環境の構築について紹介しました。今回は、執筆プロジェクトのミーティングをどのように進めたのか紹介します。
執筆作業
開発環境を整え、目次を決定すると、執筆作業が本格的に始まります。ソフトウェア開発で言えば、プログラミングを始めるようなものです。もちろん、書籍執筆活動で最も重要な作業です。
執筆作業は、共著といえども個々人の自宅でWikiに原稿を書き出していく個人作業です。黙々と進めればよいのですが、クジラ飛行机さんも私も割り込みの仕事が多く、集中して執筆時間を確保することができませんでした。
また、実践バグ管理の問題は類書があまりないことです。このため、参考にできるものがあまりありません。何を書けばいいのかわからず、原稿を書こうとして詰まってしまうことも多々ありました。また、片方が「この内容で書くべき」と考えてももう片方がそう考えていない場合もあります。
執筆は以下のことを考えながら進めました。
- 意識の共有
- モチベーションの維持と向上
- 難しい問題に対する解決策
- 進捗のコントロール
本記事(もしくは次回の記事)では、上記を実現するために行った以下について紹介します。
- 書籍執筆プロジェクトのミーティング
- 記事内容を考えるためのブレインストーミング
- 執筆時間を確保するための執筆合宿(次回紹介します)
- 書式をそろえるためのパターンテンプレート(次回紹介します)
書籍執筆プロジェクトのミーティング
複数人で作業する場合、ミーティングは非常に重要なものです。ミーティングには進捗確認という目的もありますが、作業の進め方を検討したり、執筆内容を決めるための「意識の共有」を行ったりするという目的もあります。往々にして、考え方、経験、スキルの異なる人間が共同で執筆を行うと、内容はばらばらのものになってしまうものです。
しかし、意識のすりあわせを目的にしたミーティングというものは時間の無駄遣いになりがちです。誰も考えを言わずに実りの少ないものになったり、話が脱線しすぎて時間ばかりかかってしまったり。このような傾向は書籍執筆に限りません。ソフトウェア開発でもよく見られる光景です。
私はフリーランスになってから(2007年2月 ~ )それほど長いミーティングにつきあうということはなくなってきましたが、以前勤めていた会社ではほとんど一日中ミーティングをしていたこともありました。と、思ったら、去年(2008年)にとある仕事で6時間ぶっ通しでミーティングをしていたという記録を見つけました。全く非効率なものです。
書籍執筆のミーティングは議論すべきことが多く、底なし沼のようなものです。この執筆でも必ずしも手短に済ませられたわけではないのですが、心がけたことを紹介します。
ミーティングの進め方
ミーティングは、始まってからよりも始まる前が重要です。事前に議事録を作成し、当日議論すべきことを明らかにします。また、ミーティング前には、まず食事をして世間話や雑談を済ませ、ミーティング中の脱線を防ぎます。食事中に軽いブレインストーミングを行い、事前にテンションを上げておくことも有効です。
ミーティングは、タイムキーパーを決めて時間を管理することが重要なのですが、時間が来たからといって、たとえば進捗確認のようなひとかたまりでやらないと意味のない議題を中断できるものではありません。進捗確認のようなルーチンワークと議論/ブレインストーミングなどの非ルーチンワークをわけることが大切です。
もちろん、適したミーティングのやり方は、チームによって変わってきます。最初から最適な方法を行うことはできないので、ミーティングの最後にはKPTを行いました。KPTとは、良かったこと(継続すべきこと、Keep)、問題だったこと(Problem)、次やってみたいこと(Try)を整理する方法です。KPTを行うことによって、ミーティングを繰り返す度に、チームはカイゼンしていきます。
まとめると、ミーティングは以下を心がけました。
- 議事録を事前に作成する(議題を事前に明らかにする)
- 事前にテンションを上げておく(ただし、雑談は済ませておく)
- 進捗確認のようなルーチンワークと議論/ブレインストーミングなどの非ルーチンワークをわける
- どちらかがタイムキーパーになる
- 最後にKPTを行い、カイゼン活動を行う(15分程度)
議事録の付け方
さて、ミーティングを行う以上、議事録を作成しなくてはなりません。最初のうちは難しいかもしれませんが、議事録の書式をあらかじめ決めておくと良いでしょう。
議事録の例(抜粋)
■2008/10/24 ミーティング in 八角研究所3F(17:30 ~ 19:30) ■議題 ・[継続]目次の確認 ・・目標:125項、決定:97項、3章:18項不足、4章:10項不足 ・インタビュー ・[継続]題材の確認(コラムや本文に格上げできるものを格上げする) ・スケジュールの再確認(年内には片付けたい) ■前回の宿題 ・ケーススタディ書いてみる → 様子見 ・××様インタビューセッティング → 完了 ・2章書き始める(二週間くらいで下書き) → 開始 ・八角研究所会議室予約 → 完了 ■次回以降 ・チートシートを入れておく(各節ごと、下書きが完了してから) ・レビュワーの声掛け ・編集担当さんに会った時に、PDFをもらうようにする★ ・最後にWordを使って文書校正をやる ・最後の仕上げは、2・3日とって一気にやる ・合宿について ・目次の仕上げ★ ・ミーティングのやり方(コラム行き) ■ KPT ● Keep ・ブレスト ・八角研究所(静か) ・食事(食べているときにブレストをして盛り上がる) ● Problem ・遅れ気味 ・変化がなくなった ・マンネリ ● Try ・合宿をする ・はじめにブレストを入れる(テンションを上げるため) ・宿題を守る ・Skypeミーティング(10/31 Skype ミーティング 14:00 開始)
議事録のKPTを見ると、「変化がなくなった」「マンネリ」などという問題点が挙げられています。執筆開始から約2ヶ月、開始当初の盛り上がり(企画開始当初は何でも盛り上がって楽しいものです)は沈静化し、執筆ペースも思っていたよりも上がらず、モチベーションの低下が出始めた頃でした。
「宿題を守る」というような「がんばって作業する」的な解決策もありますが、合宿やブレインストーミングを活用して雰囲気を盛り上げる方法も提案し合いました。(そしてそれは実際に行われました。)がんばるだけでなく、具体的な改善策を示すことが重要です。
ミーティングの数字
さて、ミーティングの議事録には開始時間と終了時間が書かれているため、ミーティングにまつわる数字はそれなりのものが揃っています。作業時間の全体が2人合わせて約500時間です。ミーティングに100時間、つまり全体の中の2割かかっているわけですから、ミーティングをうまく進めることがいかに重要なものであるのかわかります。
| 項目 | 数値 |
|---|---|
| ミーティング回数 | 23回 |
| 合計時間 | 52時間(2人なので工数としては104時間) |
| 頻度 | 1週間に1回程度 |
ミーティングの内訳は以下の通りです。
- 喫茶店:5回(カラオケルームで1回やってみました)
- 八角研究所会議室:3回
- 飲み屋:2回
- Skype:7回
- 合宿(クジラ飛行机さんの家):6回(合宿中はカジュアルに小会議をしていたので、便宜上、1日を1回と数えました)
もっとも、週に一回というというペースでミーティングを行っていたため、執筆期間が長期化(2008/8 ~ 2009/2)しなければ、ミーティングコストももう少し小さなものになっていたでしょう。
記事内容を考えるためのブレインストーミング
さて、前述の通り、実践バグ管理には類書が無く、本の内容や構成について参考にできるものがあまりありませんでした。特定のバグ管理システムやツールに依存しない内容を書くという、ある意味高すぎる目標を設定してしまったこともあり、執筆中、書くことに詰まってしまうことも多々ありました。
目次は最初の時点である程度決まっているわけです。しかし、その中に何を埋めるのか思いつかないことがあります。また、本に書くには、思いつきだけでなく、ある程度の網羅性が求められます。以下のような場合、ブレインストーミングは有効です。
- 書く内容は思いついているが量が乏しい
- 手法や原因などを網羅的に列挙したい
- 本文は書いたが、サンプルに困っている
以下に、ブレインストーミング結果のサンプルを紹介します。
p34「ヒューマンエラー」向けのブレインストーミングより抜粋
■疲労の原因 ・個人の環境の変化(転職、結婚、引っ越し) ・労働環境の変化(人事異動、オフィスの移転、部署替え、席替え) ・評価 ・対人関係 ・・ハラスメント ・・・パワハラ ・・・セクハラ ・・派閥 ・・意見の相違、喧嘩 ・・コミュニケーション ・長時間労働 ・・目、肩、腰 ・仕事内容の変化 ・・OJT担当 ・・プロジェクトメンバーの入れ替え ・・・頼っている人がいなくなる ・・・困った人(マイナスX人月の人) ・オフィス環境 ・・騒音 ・・空調の故障/仕様、温度争奪戦 ・・狭い、臭い ・ストレス ・病気、睡眠不足 ・飲み会が続く ・不得意・不本意な仕事を任される
合議型執筆と発想型執筆
少し脱線しますが、合宿中に冗談交じりで合議型執筆と発想型執筆などという話をしていました。目次の検討や、肝になる部分は内容を慎重に話し合いながら進めて(合議型執筆)、3章4章に書かれているようなノウハウやパターンについては、ブレインストーミングを活用して内容を一気に決めてしまう(発想型執筆)という考え方です。
この命名は適当というかいい加減なものではあるのですが、ブレストを行った節・項の執筆ペースは異常に速く、少なくとも発想型執筆は有効なようです。合議型執筆は、コントロールが難しく、話し合う時間がかかる割には得られるものが少ない場合もありました。
ブレインストーミングと時間
ブレインストーミングはあまり長時間やっても仕方ありません。30分位を目安にすると良いでしょう。もっとも、普通にブレインストーミングを行えば、30分に収まるかどうかはともかく、一定時間の経過とともに収束していくものです。もし、収束しないとすれば、それは議題の設定方法に問題がある可能性があります。
議題が曖昧もしくは発散しすぎている場合、つまり、目的意識が散漫なブレインストーミングは、ともすれば発言者の演説大会になり、数時間があっという間に経ってしまいます。それはそれで楽しいのですが、進捗は得られないでしょう。
まとめ
以上、執筆プロジェクトにおけるミーティングの運用方法についてでした。会議術については、さまざまな本や手法が発表されているので(実践バグ管理でも、p199でKPTの手法について紹介するなどをしています。)、そういったものを参考にしながらプロジェクトによってさまざまな工夫がされていると思います。「実践バグ管理」執筆プロジェクトでも一つ一つは目新しいものはありませんが、さまざまな工夫をしました。
次回は、今回紹介できなかった合宿やパターンテンプレートについて紹介します。それでは!
TrackBack URL :
