nDiki : 議事録

議事録 - minutes

できる人の会議に出る技術 - ココで同期に差をつける! 仕事の基本

2004年9月19日 (日)

■ 過去の今ごろ

スポンサードリンク

過去の9月19日より。

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

twitter.com/Naney の follower になってください。

[ permalink ]

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

[ 9月19日全て ]

2005年6月2日 (木)

■ FreeMind でマインドマップ

@ きっかけ

「企画書書いてみ」 →「いきなりプレゼンツールでゴリゴリではなくて、アイデアまとめからだよな」 →「そういえばマインドマップというのをたまに見かけるっけ。ちょっと前から気になっていたんだよね」 →「ツール探し。Linux でも Windows でも動く FreeMind が良さそげ。」

@ FreeMind を入れてみた

操作がシンプルですぐ覚えられる。キー操作によるインタフェースが良く出きていて、2次元的な図として書いていくのだけれど普通のエディタと同じような感覚で入力していける。このため変に思考を遮らないのが良い。

ただし HHK Lite には FreeMind で多用するカーソルや Insert キーがないのでちょっと不便。Fn と組み合わせて押さなければならない。慣れれば問題ないとは思うけど。

それか、FreeMind のキーストロークをカスタマイズするか。

@ 機能

HTML形式での書き出し機能あり。
アプレットを利用して、そのままデータファイルを Web サーバに置いて公開することも可能。プロジェクトメモ等で、関係者が全員アプレットを使用できる環境だと分っている時は、こちらの方が綺麗でみやすい。
何かと必要な画像形式でのエクスポートは 0.8.0 から(?)。安定版は現在 0.7.1 で、Debian GNU/Linux sid のもこれ。最初は 0.7.1 を使ってみたが、すぐ 0.8.0 rc3 にのりかえ。

@ 本とか

一応本屋とかで、マインドマップの本とか見てみた。

とりあえず、読まなくてもいいかなと。

特に系統的な方法論とかがあるような感じがしなかったし、そもそも、そういうのにしばられずに使うのが良いだろうし。

本でもWebでの紹介でも「脳のなんちゃら」とかって書いてあるけど、そんなのどうでもいいんじゃないか? 実際本当にそうなの? 「表でまとめて考えると良い」って時は脳も表形式で機能しているの? 「グラフにまとめている」時は?

@ 議事録x2に使ってみる

昨日と今日の2件のミーティングの内容をまとめてみる。テキストで書くと、時系列ベースから抜け出しにくい。かわりにマインドマッピングツールを使うとその場で木構造をいじって意見・提案・質問等に簡単にまとめなおすことができ、それにより話題のポイントが浮かびあがってくる。

なるほど面白い。すごく整理できてしまった感じ。

@ その他使ってみる

その他、頭の中で考えている内容をまとめたり、プロジェクトの問題点の洗い出しにちょっと使ってみたが、どんどんノードが増えていって面白い。

この記事もまず、FreeMind で下書きしてみた。これぐらいの分量なら、充分下書きになる。

なかなかいい感じなので、しばらく使ってみようと思う。

[ permalink ]

Evernote 使用開始 (2009-03-03)
「すごい会議」2度目 (2005-06-03)
Windows でも Linux でも動くタスク管理ツール Task Coach (2006-01-12)
今日のさえずり - 「深呼吸してください。」が無くなったのは残念 (2009-09-24)
Evernote は 1.1MB 中の 40MB (今月残り14日) (2009-03-18)

[ 6月2日全て ]

2005年6月3日 (金)

■ 「すごい会議」2度目

1週間前のとは別のプロジェクトで「すごい会議」を開いてみた。といっても参加者は、前回のメンバとほとんどかぶっていて、新たに一人加わった4人。 3人はすでに前回途中まで「すごい会議」をやっているので、勝手がある程度つかめているかなといった感じ。

@ いま、うまくいっていることはなにか?

最初の手順であるが、これが意外と時間がかかる。 4人で30分弱。ただ、雰囲気作りと書いて発表するという手順に慣れるという効果を得るにはそれぐらい費すべきか。

@ 達成したいことはなにか?

前回もそうだったが、本の通り「〜(精神的意味合い)となる」という形で考えるとなかなか困ってしまうようである。テンプレートを再考した方がよさそう。

@ この会議で、達成したいことはなにか?

それぞれの立場が列挙される。「自分自身が一番影響を与える」という意識に参加者を導くという意味合いがある手順であるが、ここであげられた各人のテーマを司会者としてどう組んでいくべきのか悩む。前回と同様の悩み。

@ いま直面している問題はなにか?

これが今回一番ブレイクした手順。今回は以下のルールのもと進めてみた。

「どのようにすれば〜」を順番にホワイトボードに書いていく時、思いついた解決策を思いついていればその場で赤で併記する。
すでに書いてある(自分の/他人の)「どのようにすれば〜」に対して、解決策が思いついたら好きなタイミングで赤でホワイトボードに書いてよいことにする。
赤で書いてある解決策について、問題点を発見した場合はそれをまた「どのようにすれば〜」という形にして、ホワイトボードに黒で書き足す。これの解決策が思い浮かんだら同様に赤で書く。

このルールによって、面白いようにホワイトボードにアイデアが書きこまれていく。「どのようにすれば〜」は分割統治法で問題を解くエンジンではないかとこの間ちょっと思ったのだが、今回それを実感。

残り時間が少なくなってきたので、忙がなければならない解決策は担当決め。後できちんとコミットメント・リストに入れる必要あり。

@ 時間切れ

結局ここまでで、今日の予定2時間が経過したので、終了。やはり、最低もう倍ぐらいの時間はないと最後までまとまらなさそうだ。

@ ホワイトボード

そういえばこのまえ雑談で「1人1台PC + プロジェクタ + Wiki」を使うことで、ホワイトボードに書く時間を減らして効率的にできるのではという話が出た。

1度はそいういう形式でやってみたいのだが、ホワイトボードに手を動かして書いていくというのも捨てがたい。

それから、噂のポスト・イットイーゼルパッドもぜひ使ってみたい。ホワイトボードだと、先に書いた手順は消していってしまうから後で参照できない。巨大ポスト・イットに書き込んでいって、会議の後の方でも壁に貼っていつでも参照できるようにするといった進めかたをしてみたい。

@ 議事録

全員がそれぞれノートを取るのはちょっともったいないかも。ミーティングのテンションが上がって、ホワイトボードへの書き出しが多くなるほどノート取りが大変になって、アイデア出しに使う頭が奪われてしまう。

デジカメで撮る (前回はそうしてみた)
イーゼルパッドを使う
誰かが書記担当になる (少人数だと専任というわけにもいかない)

あたりのルールを決めて始めた方が良いかもしれない。

そうそう自分は FreeMind でノートを取ってみた(結局自分も皆と同様ノートを取っていたのである)。どんどん追記されていくホワイトボードをメモるのは、紙に書くより圧倒的に楽(紙だと書くところがなくなる)。図がででくると困りそうだけれど。やはりその時は手書きやデジカメ併用で、後で清書するしかないかな。

[ permalink ]

すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
すごい会議はじめての全手順(1/2) (2005-06-30)
「すごい会議」と問題解決のスコープ (2005-06-15)
すごい会議の正しい手順 (2005-07-04)
すごいKPT事後評価セッション (2005-10-07)

[ 6月3日全て ]

2006年2月15日 (水)

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

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

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

最近はアジェンダ・議事録・開発メモなどを、積極的に 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 には見当らない。実はどっかにあるのだろうか。

[ 書評 ]

[ permalink ]