nDiki : アイデア

メモ 会議 ミーティング ホワイトボード すごい会議 コミットメント 開発 事後評価セッション コミットメント・リスト KPT デジカメ 目標 印刷 戦略的フォーカス メール コラボレーション Life Hacks 情報発信 Web ソフトウェア A4 プレゼンテーション ノート GTD 発想法 思考法 メモ帳 計画 問題解決 FreeMind

■ 乱入OK! コラボレーションタイム

11月末にモノを発送できたプロジェクトの事後評価セッション。 手法は前回と同じくKPT法をとりいれた方法で。

セッションでは「質問したい時に、忙しそうにしていると話かけづらい時がある」という課題があがった。 あ、自分のことね。 忙しいと集中して(あるいは集中しているフリをして)そういう雰囲気を醸し出しているな。

こちらは案外好きな時間に声をかけているのだが、立場というダイオードが入っているのかもしれない。

集中とコラボレーション、どちらも大切。

ということでアイデアとして、時間を決めてその間はアポがはいっていたり極限状況にあったりない限り、チームメンバで御互いに話しかけたら誠実に対応するというルールを作ってみた。 15:00 - 16:00 をその時間に。その日にある程度作業をした後問題が発生した頃で、かつコラボレーション後実行してみる時間を残っている時間はこの時間帯かなと。

トリンプ・インターナショナル・ジャパンの「がんばるタイム」のように、各個人業務の集中時間を設けるという事例は聞いたころがあるが、こういうコラブレーション推奨時間を設けている話はまだ見かけたことがない。 多分いろんなところでやられていると思うのだけれども。

p.s.

基本的にそれ以外の時間には話かけるなということではないので、お間違いなく。

• すごいKPT事後評価セッション (2005-10-07)
• いまいちパッとしなかった「ふりかえり」 (2007-02-28)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• ソフトウェアかんばん (2005-10-28)
• 紙ベースのファイリング (2005-11-08)

■ 結局自分も MOLESKINE に行き着くのか

仕事やプライベートでの、Life Hacks だったり Tips だったりするようなものを持ち歩いていつでも参照できるようにしたいなと思った。 たとえば、「名言」だとか「問題解決手順」とか「会議の進め方」とかもろもろ。

PC 上の Wiki も悪くないが、PCを使えない時/使いたくない時もある。Palm ではというと、便利なところもあるがやはり1画面における情報量等の面で閲覧性が良くない。

そうするとやっぱり紙か。 12月から使い始めたほぼ日手帳という手もあるが、こちらはメモ的なものを雑多に書いていきたいから、自分の場合ちょっと共存しにくい。

TeX で組版して A6 ぐらいに印刷して閉じるという手もあるが、「閉じる方法」「(最初の段階での)手書きによる新しい情報蓄積」「追記」という点でどうもいいアイデアが思い浮かばない。

そうするとやはり丈夫な手帳に「手書き」「ある程度整理されたら TeX で組版して貼り付け」「手書きで追記したら、適宜 TeX ソースにフィードバックにして重ね貼り/新ページへ貼り」というのがいいのかな。

そういった用途には、やはり MOLESKINE?

MOLESKINE には手を出さないと思っていたのだが、やはり「自分もここへやってくるのか」。

1冊目は Squared Notebook の Pocket。 サイズは約9cm x 14cm。

何かをプリントして貼るとすると 7cm x 12cm ぐらいがいいのだろうか。 まずは、LaTeX のトンボとマージンの設定いろいろ試行錯誤して、良さそうなレイアウトを検討。

• Moleskine Pocket Squared Notebook

@ ギャバンダイナミック

フライヤーにあったアヴァンギャルドという語が目にとびこんできた。

「アバンギャルド」と聞くと「ギャバンダイナミック」と言う必殺技が頭の中でグルグルするのは自分だけだろうか?

[ 製品レポート ]

• A6 方眼ノート比較 (2006-01-06)
• 2008年夏の GTD 運用ツール (2008-07-23)
• DELFONICS の Rollbahn Memo を GTD ツールに投入 (2006-03-27)
• MOLESKINE でマニュアル作成 (2005-12-16)
• ダ・ヴィンチ ジャストリフィルサイズ システム手帳で GTD (2006-05-17)

■ 成功するビジネスプラン

新しいアイデアをもとに新しいソフトウェアを開発・販売あるいはサービス提供を行おう。

開発についてはいろいろ学んでいるけれど、もっと大きな視点でどう事業化していくかという点についてはほとんど理解していない。 どういったビジネスシステムでそれを実現していけばいいのかわからない。 どのようにプランニングし、提案していけばいいのか正直よくわからない。

何を分析して、何を考え、何を書けばよいのか。

まずは入門書にあたろう。ということでまずは「成功するビジネスプラン 日経文庫」を読んでみた。

本書は、事業や顧客の分析といったビジネスプランを立てる上でのフレームワークから、具体的な事業計画書の書き方、財務計画の立て方までを解説。-- (表紙裏 [POINT] より)。

新書サイズということで深くはないものの、ビジネスプランを作成する上で必要な分析のフレームワークが一通り紹介されているので、どんな事を考えなければならないのかが分かってきた。

さらにビジネスプランの構成が説明されているので、まずはこれに従ったアウトラインで書きはじめることができる。

三色方式で線を引きながらでも1日で読めてしまうので、急にソフトウェア製品/サービス企画を具体化する必要がでてきた時に、慌てて読むのになかなかよい1冊である。 で、書きながら詳細を知りたくなった点を他の書籍で補っていけばよいだろう。

ただ財務計画についてやはり別途基礎知識がないと駄目だな。

[ 書評 ]

• Joel on Software - 必読書 (2008-08-14)
• 開発の現場 Vol.004 「上流脳」をつくろう! (2006-04-14)
• 仕事のヒント (2005-11-26)
• PLANNING に違う期待をしてしまった「PLANNING HACKS!」 (2007-07-12)
• 個人目標設定における課題 (2006-02-06)

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

• モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
• ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

@ 止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

• 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

• すごいKPT事後評価セッション (2005-10-07)
• ソフトウェアかんばん (2005-10-28)
• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• WiKicker でソフトウェアかんばん (2007-03-01)
• すごい会議の正しい手順 (2005-07-04)

■ WikiPage 編集画面で Ctrl+S を押すとプレビューするようにしてみる

「ついつい保存しようとして Ctrl+S を押して Web ブラウザの保存ダイアログを開いてしまうんだよね。Ctrl+S で (WikiPage を)保存してくれると嬉しいんだけれど。」

WiKicker を使用している同僚からのアイデア。 自分にとって C-s は Incremental search forward (`isearch-forward') であって保存ではないので、あまり関係ないといえばないんだけれど、その気持ちは良くわかる (C-p で 印刷ダイアログが開くのうざい)ので、試しに実装してみることにした。

ただしいきなり Ctrl+S で保存はちょっとデンジェラスなので、プレビュー画面に移動するようにしてみる。

例によって Web ページ上の JavaScript におけるイベント処理は、Web ブラウザ依存バリバリなのね。 テストが面倒(自分でできない/自動化困難)なので、できるだけ近付きたくはないのだけれども。

とりあえず、Firefox 1.5.0.2 on Debian GNU/Linux と、Internet Explorer 6 on Windows 2000 では動くことを確認するところまできた。

喜べ松下君。

• Debian に RSS リーダ「フレッシュリーダー」をインストール (2006-03-06)
• 「s」文字をキー入力できない WikiEngine (2006-05-24)
• 紙copi 試したけれど Windows メインではないので使わなさそう (2007-03-06)
• 朝日新聞講読申込み (2005-01-31)
• FreeMind でマインドマップ (2005-06-02)

■ 新幹線でウェブ進化論を読み終えた

帰省の時に車中で途中まで読んだウェブ進化論の残りを、これまた新幹線で読み終えた。

後半で興味深かった点を挙げてみよう。

@ Blog

本書の中で「知的生産性のツールとしてのブログ」からの引用に非常に共感を得た。

「自分がお金に変換できない情報やアイデアやは、溜め込むよりも無料放出することで(無形の)多きな利益を得られる」 -- ウェブ進化論 p.164 (「知的生産性のツールとしてのブログ」から引用)

まず個人にとってのオープンソースとかブログは何か。それはポートフォリオであり、面接であり、己の能力と生き様がそのままプレゼンテーションの装置として機能する。 -- ウェブ進化論 p.164 (「知的生産性のツールとしてのブログ」から引用)

自分が(大した内容ではないにせよ)書き続けているのも、やはりそれによって有形・無形の利益を得ているからである。

情報をとりまとめて発信し続けることは時間もエネルギーもかかることであるが、かけた分だけ得るものも多い。 でなければ、続くわけがない。

どんどんアウトプットする。 この気持ち良さ。

[ 情報発信 ] [ アウトプット主義 ]

• 私が情報発信を勧める理由 (2006-07-26)
• 今日のさえずり - 金メダルのネックストラップには、ケータイ用のヒモが付い... (2008-08-24)
• すべての情報を共有する。情報閲覧者が判断する。 (2006-05-15)
• 新幹線用「ウェブ進化論」 (2006-05-13)
• 面接 (2004-10-19)

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

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

問題点:

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

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

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

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

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

• すごいKPT事後評価セッション (2005-10-07)
• 乱入OK! コラボレーションタイム (2005-12-06)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• ソフトウェアかんばん (2005-10-28)

■ [ DVD 鑑賞 ] 博士の愛した数式

原作を読んでいない人はどのようにこの映画を受けとったのであろうか。

先日原作を読み終え映画ではどのように描かれているのだろうと気になって、DVD を借りてきた。

原作では家政婦(母)の視点で話が進んでいくのだが、映画では息子の視点になってしまっている。 映画では難しい数学的な内容の説明を見せる方法として、アイデアとしては分からなくもない。しかし、そのことによって家政婦が数式の美しさに魅せられていく心理描写が抜け落ちてしまった。

また原作では謎めき具合がよかった未亡人が、バンバン説明されてしまってこれまた分かりやすい平凡な内容になってしまっている。

映像化・映画化のためにいじったところが裏目に出た感じ。 原作を読んで良かったと思う人には、あまりお薦めできない1本。

• 博士の愛した数式

• [ DVD 鑑賞 ]「何とかする」 - 時をかける少女 (2007-05-20)
• [ DVD 鑑賞 ] スキャンダル Untold Scandal (2005-06-25)
• 劇団四季 ミュージカル オペラ座の怪人 (2005-07-30)
• ちょっと演出感がありすぎだったか、ドラマ「東京タワー」 (2006-11-18)
• 母の年賀状文面作成 (2004-12-12)

■ PLANNING に違う期待をしてしまった「PLANNING HACKS!」

本屋で探していた本が無かったので、タイトルに魅かれて買ったのがコレ。 プランニングという言葉について(本書の狙いとは)違うイメージと期待を持って読んだため、「パッとしないと感じ」というのが読んだ仮想。

自分の仕事がら、プランニングというと「計画」的な意味合いをイメージしてしまうんだけれど、こちらは「企画」の方の話なんだよね。 読み終わってから、表紙のタイトルの横に「企画ハック!」と書いているのに気がついたよ。

ということで本書はプロジェクトの計画のハックではなくて、企画のハック本。内容は

「プランニング・システムとアイデアの二段階抽出法を使えば、誰でも優れた企画が量産できるよ」-- p.40

に集約されている。 企画のために普段から準備しておくというのはごく自然な発想だが、なかなかできていないことなのでこのようにあらためて気づかされるというのは良い。 本書では「準備」と「アウトプット」の2段階を基本軸に仕事術を展開している。

発想法については何でも「二段階抽出法」に結びつけているののがちょっと違和感があった。 本書ではそのテーマにきちんと絞っているといえばそうなのかもしれないが、やはり「それだけ?」と思えてしまう。

本書では、企画を考え出し続けるのに必要なテクニックが紹介されている。 どう違うかと問われると困るが、本書に書かれているのは「ハック」ではなく「テクニック」というかそういうような感じがする。

いわゆる Life Hacks 系で言うところのハックとは香りが違う気がするのはなぜだろう。文体からだろうか。 本書自体が、パワポスライド的なテイストだからかもしれない。

プランナーとして、日々アイデアを出してプレゼンテーションをする人向けの1冊。

• PLANNING HACKS!

[ 書評 ]

• Life Hacks PRESS で Life Hacks をおさらい (2006-03-28)
• 成功するビジネスプラン (2006-01-08)
• 問題とは「あるべき姿」と「現状」の「ギャップ」である (2006-10-13)
• テスト駆動開発入門 (2004-08-02)
• 結局自分も MOLESKINE に行き着くのか (2005-12-15)

■ 今日のさえずり - Google ドキュメント、フォントでP明朝指定したら PDF にもきちんと変換できた

• 09:30 近日オープンするエクセルシオールカフェの囲いがとれてる。L:大井町[mb]
• 10:06 最近 Google デスクトップ Linux が、サスペンド/リジュームすると終了している。前はそうではなかったのだが。v1.1.0.0068
• 11:49 deb http://apt.wxwidgets.org/ etch-wx main を APT ラインに追加。
• 11:56 Task Coach 最新 Debian パッケージ(0.66.2-1)入れたけれど動かない。Python 2.5 用のパッケージらしいのでそれもこれから入れる。
• 12:02 うーん動かない。2.4 と 2.5 がごっちゃになってる。
• 13:23 Todoist に入れたプロジェクト/タスクを Task Coach に移した。 *Tw*
• 16:14 RTM と Task Coach をうまく連動させるいいアイデアはないかな。 *Tw*
• 17:53 Google ドキュメント、フォントでP明朝指定したら PDF にもきちんと変換できた。そういうことか。 *Tw*
• 19:21 同時プリント受け取り。後ろに並んでた人、APS フィルムだった。L:秋葉原[mb]

• 買物ぐるぐる (2003-06-01)
• Windows でも Linux でも動くタスク管理ツール Task Coach (2006-01-12)
• Google Desktop Linux 版をインストール (2007-07-02)
• 今日のさえずり (2007-10-04)
• LaTeX でプレゼンテーション (2005-06-21)