nDiki : 書き出す

Blog Wiki 生産性 ホワイトボード 社内 Blog Web 情報共有 日本語 ミーティング コミットメント HTML GnuPG 公開鍵 コミュニケーション 発想法 WiKicker ユースケース図 コマンド プロンプト プロフェッショナル 仕事の流儀 インストール README Word 箇条書き OJT A3 情報カード B6 新入社員 dh-make-perl ノート

■ [ Perl ] Devel::Cycle

WiKicker のメモリ消費量を抑えるためにメモリリークチェック用モジュールをいくつか試してみる。

• Devel::Leak - リークをチェックするコードの最初と最後にサブルーチンを呼ぶ。リークはアドレスで表示される。
• Devel::LeakTrace - use すると勝手にプログラムのリークをチェックする。表示は Devel::Leak と同じタイプ。dh-make-perl でうまくパッケージ化できなかったので試すのやめ。
• Devel::ObjectTracker - perl -d:ObjectTracker ... として使用。プログラム実行のトレースをファイルに書き出す。デフォルトで標準出力にメッセージを吐くのでCGI プログラムでは困る。実行時ディレクトリに .objecttracer というファイルを置きその中に $Devel::ObjectTracker::verbose = 0; と書いておけば最初から出力を抑制しておける。が、試してみたらセグメンテーションフォルト。
• Devel::Cycle - 指定したリファレンスを辿り循環参照が無いかを検出するサブルーチンを提供。
• Test::Memory::Cycle - 上記のテストハーネス用のインタフェース。

結局うまく使えそうなのは、Devel::Cycle ぐらいかな。 循環参照を発見した場合の表示は見やすい。 WiKicker の何か所かでチェックしてみたけど、今のところ見つからず。

• www.naney.org サーバ断続的にダウン (2006-04-30)
• [ WiKicker ] 「最近のアクセスログ」処理思案 (2004-01-17)
• [ Perl ] Devel::Size (2004-01-21)
• [ WiKicker ] eval "use ..." (2004-01-23)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)

■ 情報カードを使って高速すごい会議

プロジェクトの後期フェーズのキックオフミーティングをすごい会議スタイルで開催。 もろもろの制約条件があって2時間程度しか時間がとれないので、今日はスピーディに進めたい。 幸い参加者はみなすごい会議慣れしていて、結束力もある。

今までのすごい会議では参加者が「各発言時にホワイトボードに書く」という部分に時間がかかっているようなので、今回は買ってきた情報カードを利用してみることにした。

参加者は計4人。

@ 今回の方法

• 「書いてから発表する」にあたりワークシートに書き出すのではなく、直接B6の無地の情報カードに書く。
• 基本的には1カード、1項目にする。
• B6だと(机に広げるには)大きすぎるので適宜切る。
  • 問題点などを書く時は、情報カードを半分に切って書く。
  • 担当分野を書く時は、情報カードを6つに切って書く。

はっ、速い。

今回はミーティングスペースの都合から前半ホワイトボードが使えなかったこともあり、発表はテーブルの中央に情報カードを披露する形で行うようにした。 ホワイトボードに書く手間だけでなく、立って移動する手間もない。

さすがに時間が短いし参加者が慣れているということで、いくつか手順をはしょろうかと思っていたのだが、結局フルセットやって2時間15分で完了した。

巨大ポスト・イットも使ってみたいけれども、コスト的にもスピード的にもカード式もなかなか良いことを実感。

@ 感じたメリット

• 速い。
• そのままカードが記録になる (後の手順で使える)
  • 担当決定後のコミットメント作成時に参照情報として、問題点カードを適任である担当へそれぞれ渡せる。
• 同じ発言を集めて整理できる。担当分野の抽出も非常に効率的。
• コミットメント・リスト作成時には簡単に日付順に並び換え、挿入ができる。

@ ルール化すると良さそうなこと

• 濃い目で太字のペンで書く。
• 字は大き目に書く。
• 手順名(キーワードでも可)を書く(あとでどれかわからなくなる)。
• 誰のカードかわかるようにする(発言者名、イニシャルなどを書く)。

4人で着席してやるならば、情報カードは最初からもう少し小さいものでもいいかもしれない。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• 「すごい会議」2度目 (2005-06-03)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」と問題解決のスコープ (2005-06-15)
• すごくない会議 (2005-06-29)

■ 「任せれば、人は楽しみ、動き出す」

テレビを見ていたら「プロジェクトX」の次の番組「プロフェッショナル 仕事の流儀」第1回の放送が始まった。

最初は寝転がりながらなんとはなしに見ていたのだが、今回登場した「リゾート再生請負人 星野佳路」氏の仕事に対するスタンスが興味深くて、気がつけばきちんと座って最後まで見てしまった。

「スタッフ自身が主体的に考えられる環境を提供」し「権限を委譲」することで力を引き出す。 コンセプトには「正解」はなく、スタッフが「共感」するものが強い推進力を持つ。

そういった事が語られていた。 成功者の多くが持つスタンスを氏も持っているのだなあ。

斜陽になった旅館の従業員が会議室の一室に集められ、コンセプトの抽出を行うミーティングに参加するシーンがある。 最初とまどい気味であった従業員が、促されて自分の考えを配られた模造紙に書き出しはじめると目の輝きがみるみる変わっていく。

「書き出す」ことの威力をあらためてみた。

その他、星野氏が「どうしますか」と連発しスタッフ自身の考えを引き出す様子など、(番組のフィルタがかかっているとはいえ)他の組織のミーティング風景を垣間見ることができ非常に面白かった。

さて自分。 自分のところのスタッフの力を引き出すために「どうしますか?」

• キックオフミーティング1日目 (2004-10-25)
• キックオフミーティング2日目 (2004-10-26)
• 情報カードを使って高速すごい会議 (2005-10-27)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 去年の今ごろ (2002-12-16)

■ 私が情報発信を勧める理由

「社内 Blog」をまわりのスタッフに勧めているのだけれど、

• 「やってみてメリットを感じている人」
• 「とりあえず(私に)勧めらたので書いてみてくれている(のかな?)という人」
• 「Blog という形態にメリットが感じられないので、やる気がしない人」

と様々だ。

話を聞いているなかで、情報発信のメリットやポイントについて自分でも整理してみたくなったので思うところを列挙してみた。

• あなたが発信すれば、あなたにも発信してくれる。
• 発信のための「とりまとめ」や「書き出す」という作業は、自分の中での理解を深めることにつながる。
• 迅速に。情報の多くは時間とともに価値が下がる。
• 送り手ではなく受け手が選別する。
• 「受け手は知っているはずだから」と遠慮しない。実は知らないということも多い。
• Web ページ・Wiki・Blog・あるいは張り出しなど、うまくメディアを選ぶ。
• 情報発信そのものよりも、その情報でいろいろな事が良くなること(生産性の向上など)が重要。

すぐに思い受かんだ点はこんなところ。

どれもすでにいろいろな人に語られているようなものであり、やってみれば実感できるものである。

人のためのようで、一番自分のためだったりするのが情報発信。

[ アウトプット主義 ]

• すべての情報を共有する。情報閲覧者が判断する。 (2006-05-15)
• 新幹線でウェブ進化論を読み終えた (2006-05-25)
• Hyper Estraier で社内 Web コンテンツ検索 (2006-06-01)
• キックオフミーティング2日目 (2004-10-26)
• Google Desktop の web clips で RSS を読む (2006-05-18)

■ ソフトウェア開発プロジェクトにおける朝会をカイゼンする

Jason Yip 氏による「朝会のパターン:立ってるだけじゃないよ (It's Not Just Standing Up: Patterns of Daily Stand-up Meetings)」という記事の日本語訳を、数日前に kdmsnr 氏が公開された (記事)。

らあるソフトウェア開発プロジェクトで2月から朝会を行ってみているのだが、この記事をみてもっと工夫できそうだということで、良さそうな点を取り入れてみることにした。

一昨日にに新ルールをアナウンスしたのだが、昨日は私は休んでしまったので自分としてはスタートは今日から。

@ ルール

記事を参考に、以下のルールにしてみた。

• 立ってやる。(New!)
• 15分以内でやる。
• 最後に来た人から話す。(New!)
• 時計回りで発表する。(New!)
• 以下のフォーマットで話す。(New!)
  • コミットしたことを達成できたか? (昨日はどうだったか?)
  • 今日コミットできることは何? (今日はどうする?)
  • コミットメントを達成するための問題点は何?
• 話す内容は前日に準備しておく。(New!)
• 見える化する (New!)。
• 講演会にしない。問題解決に集中しない。プロジェクトに関係ある話のみにする。(New!)

見える化については、まずはコミットメントを A3 ホワイトボードに書き出すことにした。

3人のチームなので今日は、10分で終了。 いつもは問題解決をつい始めてしまい長引きがちであったが、こうして明確にルールを共有しておくと、互いに制止しやすくてなかなか良い。

しばらくこのスタイルでやってみて、また改良していくことにしよう。

• すごい会議はじめての全手順(1/2) (2005-06-30)
• 情報カードを使って高速すごい会議 (2005-10-27)
• すごくない会議 (2005-06-29)
• ソフトウェア開発プロジェクトで朝会をすることにしてみた (2007-02-15)
• Rekisa で TortoiseSVN から日本語ファイルの差分表示 (2006-03-23)