nDiki : アイデア

メモ 会議 すごい会議 ホワイトボード コミットメント ミーティング コミットメント・リスト 開発 事後評価セッション Web Life Hacks 印刷 コラボレーション KPT デジカメ 情報発信 戦略的フォーカス メール 目標 ソフトウェア 議事録 コミュニケーション 仕様 プレゼンテーション ポイント Blog 仕事術 メモ術 ノート RHODIA

■ スピードライト SB-30 購入

先日届いたニッコールクラブ182号の記事「デジタルカメラで散歩第6回 スピードライトを使った撮影 金野 剛志」に、ニコンのスピードライト SB-30 が紹介されていた。

背面のダイヤルを「A」に設定すると、メインのスピードライトの発光に同調してスレーブ発光するのですが、その際、メインのスピードライトの発光波形を忠実にトレースしてくれるのです。 そう、メインがプリ発光すると、それに合わせてSB-30もプリ発光し、メインが本発光のときはSB-30も本発光、そしてメインの発光が停止されると、こちらも同時に発光停止となります。

おぉ! これはヒカル小町DiやリモートライトIIより上をいくじゃないの。 これらのスレーブ機能は、マスターのプリ発光を無視して本発光で同調するタイプ。 ヒカル小町Diをスレーブにした場合、当然デジカメは「本体のプリ発光だけからフラッシュの発光量を決定する」事になる。 したがってどうしても増灯した分露出オーバーになりがちだ(もちろん補正すれば対応できるが)。

P それに対して SB-30 はプリ発光にも同調して発光するということだから、デジカメのプリ発光時の測光にスレーブの光量が影響する。 そのため、デジカメ本体の本発光量が若干抑えられて全体としてバランスのとれた調光になるのではと想像。

うーん、もしそうならなぜそんな Good な機能をニコンはアピールしないのだろう。 まぁ、ニコンが優れた機能をアピールしそびれるのはかつてもあった話で、ありがちなのかもしれない。

何はともあれ期待大。 ということで、早速帰宅時に購入して帰る。 お値段はこの手のスレーブ用として使うにはちょっと高い。

@ DiMAGE X で実験

さてさて、実験。 マニュアルには2度フラッシュ発光する COOLPIX シリーズにもワイヤレス同調するとの旨は書いてあるけれど、記事にあったような「プリ発光にも同調して発光する」といった技術的な内容は見当たらない。 うちには COOLPIX はないので DiMAGE X でテスト。 というか、DiMAGE X 用に買ってきたんだし。

で結果から言うと「同調できる時もあるし、できないときもある」。 ちょっとガックリ。

• スピードライトを被写体方向にきっちり向けていないと、スレーブ発光しないことが多い(直線で40m以内の主灯の発光を検知できるようなので感度不足ではなく、プリ発光と本発光を区別できないのか?)。つまり天井バウンスさせようとすると、スレーブ発光しそびれるのである。
• スレーブ発光しても、写りが暗い事が多い(DiMAGE X のプリ発光を本発光と誤解して同調してしまい本発光時にはスレーブ発光せず、しかも DiMAGE X のプリ発光測光に影響を与えてデジカメのフラッシュ本発光が抑えられるというパターンか。この時SB-30はフル発光してしまっている)。

もちろん、これは DiMAGE X での結果であって COOLPIX との組み合わせではきちんと動作するのだろう。 微妙なタイミングの問題とかなのかなぁ。 メーカーの保証する動作ではないんだけど、期待していただけに残念。 やっちゃったか。

@ ということで

今のところ DiMAGE X との組み合わせでの使い勝手は圧倒的にヒカル小町Diに軍配。 SB-30 はどうしよう。 高かったのになぁ。 とりあえず DiMAGE X とはもう少し実験してみよう。

単体でもニコンF100で、使えるし(ってSB-28 も SB-22s もあるんだけど)。 SB-28 よりずっとコンパクトだから非常用に常備するようにしておくかな。 あっ、でも上方向にバウンスできないんだよね。痛い。まぁ主灯としてバウンスさせるほどの GN ではないけど。 本当にボン炊き非常用?

それから内蔵している赤外線フィルタ引き出してTTL赤外線リモートコマンダーにも一応なるね (手持ちの SU-4 + SB-28 でリモート灯が用意できるから)。

あぁ衝動買いしてしまった自分を正当化するアイデアばかり……

• DiMAGE X のフラッシュを殺して、ヒカル小町Diを使う (2002-09-07)
• フィルムスキャンできるインクジェットプリンタ PIXUS MP980 (2008-11-03)
• Wedding Photography (2006-11-11)
• フォト イメージング エキスポ 2005 (2005-03-18)
• デジカメ写真管理ソフトウェア digiKam (2006-03-10)

■ 本当に使えるのか? 「ボ撮ルンです」

FinePix F10を買ったおまけにボトルキャップスタンド「ボ撮ルンです」をもらった。

ボトルキャップに雲台がついているアクセサリー。 アイデア商品で、Webでも比較的評判になっているようだ。

しかし、これ使えるのか(運用できるのか)?

「写真撮りたいなー。固定したいなー。ボ撮ルンですがあるよー。」

さてここでペットボトルどうする? 撮りたくなった時に手元にある? なければ買いにいく? (いかない)

いざという時のためにボ撮ルンです持ち歩いで、その場でさらにベットボトルを調達するよりも小さい三脚を持ち歩いた方が良いと思う自分はカメラバカか?

[ 製品レポート ]

• 撮りたいものは、撮れていたか。FinePix F10を購入。 (2005-03-21)
• シカゴ・サンフランシスコ出張 2006 ログ - 1日目 (2006-08-13)
• HDRI 用撮影とボールペン探し (2006-04-15)
• つつじ咲く根津神社と谷根千散歩 (2006-05-01)
• PIXUS MP980 で初フィルムスキャン (2008-11-08)

■ 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 で下書きしてみた。 これぐらいの分量なら、充分下書きになる。

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

• flickrfs で Flickr をマウントして写真をコピーする (2008-02-21)
• Windows でも Linux でも動くタスク管理ツール Task Coach (2006-01-12)
• 「すごい会議」2度目 (2005-06-03)
• 研究室 OB Twitter-ers と秋葉原で飲んだ (2008-09-11)
• TrueCrypt で USB メモリに Windows と Linux ... (2006-12-14)

■ 「すごい会議」2度目

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

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

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

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

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

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

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

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

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

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

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

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

@ 時間切れ

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

@ ホワイトボード

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

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

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

@ 議事録

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

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

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

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

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• すごい会議の正しい手順 (2005-07-04)
• 「すごい会議」と問題解決のスコープ (2005-06-15)
• FreeMind でマインドマップ (2005-06-02)

■ すごい会議はじめての全手順(1/2)

6カ月間のプロジェクト*1のちょうど半分ということで、担当とコミットメントの再確認を含めたすごい会議を開催。 このプロジェクトでは約1カ月前にすごい会議をしてみているが、その時は「いま直面している問題はなにか?」の手順を終えたところでタイムアップ。

今回は長めに時間を用意して、全ての手順をやってみるというのもミーティングの一つの目的。

出席者は自分を含めて4人。

@ いま、うまくいっていることはなにか? 13:05 - 13:25 (20分)

前回より時間短縮。 皆慣れてきている感じ。

@ 達成したいことはなにか? 13:25 - 13:40 (15分)

やはり実務者ほど、短期間で設定する傾向がある感じ(いい悪いではなく)。

@ この会議で、達成したいことはなにか? 13:40 - 13:50 (10分)

実験。 今回はホワイトボードではなくA4の紙 (RHODIA No.19) 1枚を 4つに区切りそれぞれの達成したいことを書いてもらって、その後ミーティングのあいだテーブルの真中に置いておくことにした。

「ミーティング中それぞれ自分の達成したいことを意識できるようになるのでは?」という狙いであったが、結局あまり見返さなかった様子。

紙に書いたという点では:

• 席を立ちホワイトボードの前に移動してそこで書くより圧倒的にはやい
• 各自ノートする必要がない (後でコピーできるものが、その場にできるから)

というメリットはあるようである。

• A3以上のより大きい紙
• 大きい字で
• 太ペンで書く

にすればもっと目について効果があるかもしれない。

@ いま直面している問題はなにか? 13:50 - 14:35, 休憩, 14:45-14:50 (50分)

前回同様「解決案があれば赤で併記する(自分の/他人のどちらにでも)」というルールで。 それなりにアイデアが出る。

今回は別途担当者決め手順を行うので、終了後ホワイトボードをデジカメで撮って次へ。

この手順は皆の発言個数が増えるので、書き込みシートも余白を多めにしておいた方が良さそうだ。

@ 言えない問題はなにか? 14:50 - 15:35 (45分)

ここからは、今まで実施しなかった手順。

第一印象は「もっと過激なものが出てもいいのでは?」

いや「どのようにすれば～」形式にすることで、過激さが柔らいでいるのかもしれない(かつ、問題解決へ思考が向いた状態になっていると)。

それほどドラマチックな展開にならなかったが、「2段階で問題出しをする」ことで確かにより深く本質に近い問題が目にみえるようになるようだ。

@ あなた自身のひとい真実はなにか? 15:35 - 15:45 (10分)

それぞれが感じている倦怠感などが明らかに。 それぞれ何となく笑える感じ。本質に近づけているのか? いないのか?

自分自身としては、襟を正して気合いを入れなおさねばなという思いを持ったので意味はそれなりにあった。

ただし今回は

会議室のセットアップ (3) やばい話ができるぐらいのプライバシーがキープできる -- すごい会議 p.20

が実現されていなかったというマイナス要因があった。 会議の出席者ではない、別のスタッフ(特に上の人)がふらふらと来てのぞかれる可能性があると思うとなかなかズバンと書きにくい。

@ これからの6～12か月で、このチームが達成する成果はなにか? 15:50 - 16:20 (30分)

残り後3カ月に対する戦略的フォーカス決め。 てっきり全員最終日をターゲットに指定すると思っていたのだが、そうではなかった。

総意的には大きなブレが無かったのは助かった点。 既にチームとしての目標がしっかり共有できているということかな。

そうだとすると素晴らしい。

@ 今日はここまで (計3時間20分。休憩約10分を含む)

明日残りを行う予定。

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

■ すごい会議の正しい手順

すごい会議FAQによると、付録の手順には誤りがあるらしい。

「最初の1、3、5が準備段階で一人でやる部分で、2からが参加者と一緒にやる部分」 すごい会議FAQより。

とのこと。すっきり!

• 手順5がミーティング前に行うというのは自明なのでミーティング時にはパスしていた(事前の招待メール時に適用)。
• その前に手順1、手順3 がくる事で手順5がパワフルかつ明確にできるようになると。
• 手順3。どおりで出席者が悩むわけだ。今回は既に走っているプロジェクトのメンバだった事からある程度方向性を共有していたのでそれなりに書けていたんだけれど、これは1人でやる手順なワケね。手順3と手順9がかぶっていて進をちょっと迷ったのだが、これですっきり。

@ 答えを作らない場所

また次の点も非常に参考になった。

ここでは、手順6、7、8は答えを作る場所ではないのです。 問題を前向きな形でたな卸しするだけです。 「答え」を提示する人がいたら、それはストップします(経営者自身がやってしまいそうになることも多くみます) ここで、誰かが「答え」を言ってしまうとドチッラケなのです。その答えが、各自、意識的または無意識のうちに手順11でコミットメントとしてその解決策が約束される可能性を最大化するためにやっているとお考えください。-- すごい会議FAQより。

もしや、思いっきりドッチラケだった?

さすがに手順8では答え作りしなかったけど、手順6、手順7では思いっきりアイデア出しに利用しちゃってたからなぁ。

• 初期の頃やっていたミーティングでは、手順6までしか時間的に進まなかったこともありそこでコミットメントに落としてしまっていた(担当と期日設定)。
• 先週の木金でやったミーティングでは、全手順を通してやるために手順6、手順7ではアイデア出しまでやった後、先に進めてみた。手順11でコミットメントを作る際、手順6、手順7で上がったアイデアを漏らしてしまわないかちょっと心配だったんだけれど、もともと答を作る場所でなかったのでなければ構わなかったということか。

@ リストにしてオシマイ

光栄な事にまた著者の大橋禅太郎氏よりコメントをいただいた。

初期のころの「この会議で達成したいことはなにか」を発表してもらってから、司会者がどうすればいいか? といったところがありましたが、司会者は特にそれについてはなにもすることはありません。そのほかにもグループとしての統一した「意思決定」がなくても進むやつは、リストにしてオシマイです。

ありがとうございます。非常に参考になります!

手順を眺めてみると、参加者と一緒にやる部分のうち前半はリストにしておしまいだ。確かにすごい会議の本文でも、実際に出席者が順に発言するところが描かれているけれどそれ以上は書かれていない。

そこに書かれていない何かをしているんじゃないかなとも思ったのだが、本当にリストアップだけで良かったのか。安心。

となると合意は

• 戦略的フォーカス
• 担当分野と担当
• コミットメント・リストと、そのチェックのしくみ

となる。

やはりすごい会議は最後の手順までやらないとオイシイところが食べられないわけだ。 ふむふむ。

はやく次のすごい会議の機会こーい。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• 「すごい会議」2度目 (2005-06-03)
• 「すごい会議」をしてみる (2005-05-27)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• すごいKPT事後評価セッション (2005-10-07)

■ すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく?

すごい会議をしてみて

• ホワイトボードに書き出したもののうち、後の手順で参照できるようにしておけるようにした方が良いのはどれ?
• ホワイトボードに書き出したもののうち、会議終了後に参照できるようにしておけるようにした方が良いのはどれ?

という点が悩ましい問題であった。

その点について大橋禅太郎氏に質問して教えていただいた。 回答を私のサイトで掲載することのお許しをいただいたので、以下にとりまとめ。

@ ホワイトボードに書き出したもののうち、後の手順で参照できるようにしておけるようにした方が良いのはどれ?

手順6,7,8,9,10,11。コミットメントリストをつくる際に、手順6,7,8,9,10の内容が見えればOK。 ホワイトボードでやるとはまるので、やはり巨大ポスト・イットを使うのがよい。

@ ホワイトボードに書き出したもののうち、会議終了後に参照できるようにしておけるようにした方が良いのはどれ?

• 戦略的フォーカス　
• 担当分野と担当
• コミットメント・リストと、そのチェックのしくみ

@ 手順6で思い浮かんだアイデアを活用するには?

目標達成に今役立つなら「コミットメント・リスト」に日付を入れた形で入れる。 そうでなければ(もしどうしても残したければ)どこか個人的にメモに残しておくのがお勧め(扱う情報は少ない方がよいとのこと)。

@ ぜんたろう節

上は私が要約しちゃったけれど、メールでいただいた返信は本の文章と同じ気さくでやさしい感じの文調であった。 いやむしろ、普段の雰囲気がそのままうまく本になっているというべきなのかな。

p.s.「すごい会議」で大きな敵は、「薄いホワイトボードマーカー」ですね。

には

そのとうりです。で近くにいいゴミバコがないことがほとんどなので、薄かったら、「床にすてる」が手順です。(あとでゆっくりゴミバコに入れればいいです)

とコメントいただいた。最高!

• すごい会議はじめての全手順(1/2) (2005-06-30)
• すごい会議の正しい手順 (2005-07-04)
• すごいKPT事後評価セッション (2005-10-07)
• 「すごい会議」2度目 (2005-06-03)
• 情報カードを使って高速すごい会議 (2005-10-27)

■ すごいKPT事後評価セッション

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

@ 招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

• 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
• 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
  • スコープ、スケジュール、リソース、欠陥レベル
  • プロジェクト運営
  • コラボレーション (スタッフ間)
  • 個人・チームとして学習した点
  • その他 (開発手法など)
• 問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
• 良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
• 問題点は Problem です。(KPT法流)
• 問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
• 問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
• 注意点 (「適応型ソフトウェア開発流」)
  • 良かった点を必ず書いてください。(すごい会議にも通じる)
  • 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
  • 特定の個人を批評はいけません。
• 事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

@ セッション

メンバは4人。 ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。 次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出れば ホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。 「担当」と「期日」を明確に設定 (すごい会議流)。

@ 完了

合計90分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。 成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議の正しい手順 (2005-07-04)

■ 紙ベースのファイリング

自分のかかわっているプロジェクト関連ドキュメントの管理を、今年の春ぐらいから紙でのファイリングベースに移しつつある。

会社でも家でもPC漬けの生活であり基本は電子的な管理が中心ではあるのだが、人からもらう資料が紙であることも少なくない。 結局ミーティングでは紙を広げた方が効率的だし、印刷された資料に書き込んだ手書きメモを後で全て電子化するのも面倒。 図なんかもアイデアレベルでは手書きの方が圧倒的にはやい。

ということでまだまだ紙ベースのファイリングも捨てたもんじゃない、というかファイリングしておかないと情報が散逸してしまうという感じだ。

• 「すごい会議」2度目 (2005-06-03)
• 結局自分も MOLESKINE に行き着くのか (2005-12-15)
• FreeMind でマインドマップ (2005-06-02)
• 2008年夏の GTD 運用ツール (2008-07-23)
• ホワイトボードも A3 ならコピー機でコピー可能 (2005-12-21)

■ 早速 reStructuredText から LaTeX へのコンバータを書く

要求仕様書を書くのに reStructuredText を使ってみることにしる。 reStructuredText の文法の上で、あるルールに従って書いた特定のセクションやフィールドリストを要求レコードや要求仕様レコードとし、自前でコンバータを書いて LaTeX へ変換する形。

まずは最初のアイデア通り rst2xml で XML に変換してから、Perl スクリプトで読み込んで処理することにする。

Perl 側の処理は XML::LibXML で (何となく XML::DOM より好き)。 しかし毎度ながら DOM 面倒くさい。 とりあえず、今必要な要素のみ変換コードを書く。 reStructuredText を XML へ変換した時の DTD があるので、おいおいこれを見ながらきちんと埋めていかねば。

最低限のものができて、早速コンバート。

これで生 LaTeX で書くより随分楽になった。よし。

• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
• JavaScript でのプログラミングやっぱり面倒くさい (2006-07-23)
• Docutils の reStructuredText から LaTeX ... (2005-12-07)
• Progect -> XML -> text, HTML (2004-04-16)