nDiki : アジェンダ

開発 すごい会議 キックオフミーティング ビジネス文書の書き方 Wiki 議事録の書き方 電話会議 ビジネス文書 ホワイトボード KPT メール 事後評価セッション 会議室 CVS リポジトリ 朝会 Apache ソフトウェア開発 グループウェア 書き方 レビュー 適応型ソフトウェア開発 Pod Skype reStructuredText 出張報告書 タイムテーブル Subversion ビルド 戦略的フォーカス 現場

■ ISO 週番号布教

ミーティングとかでスケジュールを決める際「6月28日の週…」などというのが面倒なので、社内で週番号を広めたい。

ホワイトボードやアジェンダなどに 2004-W27 などと ISO 8601 で書いてみたりしている。

• 「すごい会議」と問題解決のスコープ (2005-06-15)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• すごくない会議 (2005-06-29)
• 情報カードを使って高速すごい会議 (2005-10-27)
• すごい会議はじめての全手順(1/2) (2005-06-30)

■ 過去の今ごろ

過去の9月19日より。

• 会社にもWiki
  • 2年経過。最近は開発チーム用メモ(プロジェクトのプログラムのビルド方法とか CVS リポジトリの位置とか)と、アジェンダ・議事録の置場としての利用が中心になっている。あとそれから開発中のβ版置場としても。プロジェクト情報の共有としてはまだ活用が足りないが、それなりに役にはたっているといったところ。

• ドキュメンテーション大全 (2006-02-15)
• [ お仕事 ] 開発に投入 (2004-09-10)
• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• 「依存関係検査のしにくいモジュール」に依存するスクリプトをPARで実行形式化する (2005-03-08)
• 今日のさえずり - 京都の小学校のコンピュータ室にいったら、Squeak が (2008-03-06)

■ 1泊2日の出張確定

かなり以前から確認の連絡の返事待ちだった来週の出張が確定。 今日になってアジェンダが送られてきた。発表の枠があるならもうちょっと早く送ってもらわんと困るよ。

行きの新幹線を確保。あわせて、高速バス大磯号のチケットもとっておく。 1号車1番A席。 事前に取る必要もなかったようだ。

• 淡路島へ出張 (往路) (2004-10-25)
• Give me chopsticks - 淡路島へ出張 (復路) (2004-10-26)
• 修学旅行以来の京都 (2005-07-24)
• 京都日帰り出張、帰りは最終の新幹線で。 (2006-08-01)
• 帰省 - 東北へ (2004-12-30)

■ 「すごい会議」をしてみる

昨日購入した「すごい会議」が面白いので俄然実践してみたくなった。 出社してから午前中に残りを読み終える。

@ 「書いてから発表する」

「すごい会議」では「書いてから発表する」のが大きなポイントになっている。 別に裏紙でもいいのだろうが、進行役の自分も初体験のミーティング方法なので、書籍の付録を参考に TeX でミーティング用記入シートを作成しておいてみた。

これは作っておいた良かったと思う。今後調整を加えて使いやすいシートを作っておこう。 シートを作るのが面倒な人は、書籍の付録のシートをそのままコピーして使うだけでも良さそうである。

@ 会議開始

自分を含め開発者3人で、ミーティングを開始。 「すごい会議」のことをついつい「できる会議」と口にしてしまう。うーん、何と混同しているのだろう。

ミーティングは前半1時間、あいだに別のスケジュールをそれぞれした後、夕方に後半2時間弱。

以下雑感:

• 「書いてから発表」はそれぞれの考えの発表漏れが無いという点で良い。
• 書く時間をどれぐらいに設定すれば良いかが微妙。人によって書く時間に違いがあるので、待ちの人が出る。
• それぞれが発表した後の議論の進め方に工夫が必要。どういう雰囲気にするのがいいのかはまだ掴めず。
• 「達成したいことはなにか?」「この会議で、達成したいことはなにか?」という点では、3者3様。それぞれどのような立場・意気込みでプロジェクト・ミーティングに臨んでいるかがわかって興味深い。さて、興味深いことがわかったとしてそれらをどうまとめて議論していくのがよいのか、はたと悩む。
• 「どのようにすれば〜」への書き換えは、実際書いている途中で解決案がひらめきやすく効果を実感。
• 問題点リストアップのところでタイムアップ。全手順をするにはそれなりに時間が必要(それとも議論 or 不要なコメント交換の時間が多すぎ?)。「戦略的フォーカス決定」「分野の抽出と担当割り当て」「コミットメント・リスト」というプロジェクトをドライブするのに必要な部分まできまらなかった。

参加者全員が慣れれば、事前にアナウンスしたアジェンダに対してすごい会議流に準備できて、よりスムーズに進むのかもしれない。 そもそも今までもミーティング開催アナウンスを効果的にできていないから、ここら辺も含めて見直す必要あり。

• すごい会議の正しい手順 (2005-07-04)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• すごくない会議 (2005-06-29)
• 事業方針を「どのようにすれば〜」化すれば何かが見えてくる (2006-01-05)
• 「すごい会議」と問題解決のスコープ (2005-06-15)

■ 効果的な複数人電話会議は?

年初あたりから社内で Skype が利用されはじめて、複数人による電話会議もよく行われるようになっているようである。 離れている拠点のスタッフ間での連絡が密になるなど、効果はあるようだ。

しかし自分は特に複数人における効果的な電話会議手法を見い出せていないので、積極的に利用していない。

@ 長所

• 物理的に離れているスタッフを含めた会議が可能
• 既存のインターネット接続上で Skype を使う分には通信コストが余計にかからない

@ 短所

• 顔が見えない
  • 聞いているのか、理解できているのわからない
• 通常の会議より時間がかかる / 同じ時間で決まることがすくない
• 回線断などがあると、しらける

@ 効果的に行うには?

アジェンダにしても参加者の下準備にしても、集合して行う時以上に周到に準備しておく必要があるであろう。 Skype だと気軽に召集できる感があるが、ミーティング中に伝達できる情報量は少ないのだからそれぞれ事前に資料を用意してメールなり、Wiki なりで情報を共有しておく必要がある。

たとえば、共同創造に必要な情報は顔を突き合わせてやり取りしたほうが効果的なのに対して、情報伝達に必要な情報は紙や電子ファイルの形態でも直接やり取りするのと同じぐらい効果的である。-- 適応型ソフトウェア開発 p.119

普通の会議と同様、情報伝達と共同創造の区別が重要である。

いわゆるミーティング、特にコラボレーションが、否定的に捉えられがちなのは、共同創造と情報伝達という2種類の基本的な相互作用が区別できていないためである。--- 適応型ソフトウェア開発 p.118

ほとんどの組織では情報伝達を濫用している。--- 適応型ソフトウェア開発 p.119

• すごいKPT事後評価セッション (2005-10-07)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• ノート PC を持たずに会社に行きたい (2006-12-21)
• 2008年夏の GTD 運用ツール (2008-07-23)

■ 本社にいた「すごい会議」読者とミーティング

新しいプロジェクトにおける開発作業開始に向けて、本社から1人きていただいてミーティングを行う。 今回はキックオフミーティング的な位置付けなので、「すごい会議」スタイルで。

「本社のその人とは『すごい会議』をまだしたことないから、ワークシートは1枚ずつ渡していく流れにしよう」と思っていたら、なんかちょっと知った風。

も、もしや?

と思ったらやはり。「すごい会議」を既読であった。 昨日私がメールで流したアジェンダで「今日はすごい会議でくるな」と察知していたらしい。 嬉しいやら、ちょっと逆に緊張するやら。

実際にやるのは初めて(?)のようだったが、さすがに一読していると流れがスムーズだ。 問題点を挙げる手順の前にプロジェクトの現状の説明をする時間を挟んだのと、途中15分の休憩を行ったのを含めても3時間半で最後の手順まで完了。2人だったということと、情報カードを使用したということもあるかな。

@ ふつうの会議

すこし時間をあけてから、その人とさらにもう一人でこちらはふつうの会議。 「すごい会議」の直後だと、ギャップが大きくもどかしい。

今までいろいろ議長のポジションからの会議の改善をトライしてきたけれど、今後は1出席者という立場の時にどのようにすればいい会議にもっていけるかということを考える必要がありそうだ。

• 「すごい会議」をしてみる (2005-05-27)
• すごいKPT事後評価セッション (2005-10-07)
• 情報カードを使って高速すごい会議 (2005-10-27)
• すごい会議の正しい手順 (2005-07-04)
• 効果的な複数人電話会議は? (2005-10-24)

■ ドキュメンテーション大全

プロジェクトの後半で納品用ドキュメントの整備を始めるのだが、その時はたいがいもう切羽詰りはじめていて構成やら体裁やらマネジメントやらを工夫する余力が無かったりする。 ついつい(次回は改良しようと思っていつも思っている)前回のプロジェクトの手法を踏襲してしまいがちだ。 ともすれば劣化コピーになりかねない。

やはり、忙しくても日頃からの改善は重要である。

最近はアジェンダ・議事録・開発メモなどを、積極的に Wiki や Subversion で共有するようにし、その点では以前より改善してきている。

今後はさらに、出荷ドキュメントのレビュープロセスなどを確立し品質を高めていきたいところである。 現状でもチームメンバでのピアデスクチェックやパスアランドを非形式的に行っているのだが、「チェックの程度」やその後の「修正」および「修正の確認」については、まだなんとなくやったかなという具合。この辺りを工夫したい。

先月発売されていて気になっていた「開発の現場 Vol.003」に、何かヒントがあるかなと思って買ってみた。

• 開発の現場 Vol.003 効率UP&スキルUP ドキュメンテーション大全

パラパラと見た感じではテクニカルライティングの話はあまりなく、主にソフトウェア開発における中間成果物としてのドキュメントや開発者間ドキュメントをどうとりまとめていくかという話が中心のよう。 Wiki による開発資料のライトな共有など、うちのチームでも進めている話など。

「(最初から)完全なドキュメントを書こうとしない」というのはもっとも。 状況はほとんどの場合変わるし、最初の段階では未確定の部分も多い。 だからといって、いつまでたっても手元で温めていてもしょうがない。

技術的な話では Perl の Pod を活用しようという話。 Perl 以外の言語のコメント中に Pod 形式でドキュメントを書こうという提案や、Apache で動的に Pod ドキュメントを整形しようという話とか。

テキストフォーマットとしての Pod は =over / =item / =back によるリスト表現など、最近のフォーマットに比べてすごく読み易いわけではないが、たしかに他の言語のコメントに埋め込んでおいて処理するのは、標準の Pod 関連のモジュールでできるな。

自分も Pod でドキュメントを書くけれど、(Perl 以外は) 個人的には reStructuredText にしたいと考えている。 ただ Pod みたいに他のテキストの一部に埋め込んでその部分のみ処理する記法およびツールがが標準の reStructuredText / Docutils には見当らない。 実はどっかにあるのだろうか。

[ 書評 ]

• 今日のさえずり - 京都の小学校のコンピュータ室にいったら、Squeak が (2008-03-06)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• 過去の今ごろ (2004-09-19)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• bundle を作成して Perl モジュールをまとめてインストール。 (2004-10-21)

■ いまいちパッとしなかった「ふりかえり」

開発プロジェクトの一つが一区切りついたので、時間を作って「KPT ふりかえり」を行ったのだがイマイチ盛り上がらなかった。

問題点:

• Try 項目がカイゼンではなく、To Do に対するアクションになりがちであった。
• Try 項目が Problem 項目の裏返し (～ができていない → ～をする) で、具体的アイデアに乏しかった。

原因としては以下が考えられる。

• 事後評価セッションではなく中間地点なので、細かいタスクに目が向きがちだった。
• ホワイトボードがなかった。

アジェンダで中期的なプロセス改善につながる Try を挙げてもらうように、最初から行っておいた方が良さそうだ。

次回以降「ふりかえり」については工夫の余地あり。

• すごいKPT事後評価セッション (2005-10-07)
• 乱入OK! コラボレーションタイム (2005-12-06)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 今日のさえずり - 壊れた金具の代わりに南京錠 (2009-04-14)
• Evernote 使用開始 (2009-03-03)