nDiki : 書き方

• マニュアルの書き方
• ビジネス文書の書き方
  • 議事録の書き方
  • アジェンダの書き方
  • 提案書の書き方、企画書の書き方
  • 報告書の書き方
  • アクションプランの書き方
  • ビジネスプランの書き方
• 手帳の書き方
• 万年筆の書き方
• 論文の書き方
• 履歴書の書き方
• 仕様書の書き方
• 年賀状の書き方
• 招待状の書き方
• ミーティングメモの書き方
• メールの書き方
  • ビジネスメールガイドライン案
• ドキュメンテーションガイドライン

ソフトウェア メモ Perl Word ほぼ日手帳 Palm 計画 RHODIA GTD 書評 日本語 開発 2008年 KDE 手帳術 reStructuredText 2007年 Wiki ノウハウ RFP 表記 C++ ソフトウェア開発 画像 GanttProject 正規表現 To Do インタフェース Web ガイドライン

■ 方眼手帳と方眼ミーティングメモ

ほぼ日手帳の使い道であるが、Palm でやっているスケジュール管理をこちらに持ってこようと思う。 スケジュールと、あとログ。

さて、そうとなったら書き方だ。 せっかくなので、何か自分流のスタイルで方眼上でびしっとキメてみたい。

方眼といえば RHODIA。 ミーティングの議事メモなんかは RHODIA No.19 にカリカリと書いている。 メモ毎に方眼上にチェックボックスを書いておき、ミーティングが終わったら Palm にスケジュールやアクションを転記したり、その場で処理したりしてそこにチェックを入れていって全部チェックできたらオシマイ。

ここでちょっともやっとしているのが「何でもかんでもチェックボックス」にしている点。これだと処理の必要のない項目までチェックボックスになってしまっており、後でチェック印がはいらないのですっきりしない。

ということで、ミーティングメモも含めて共有の俺スタイルを考えてみた。 基本的にはチェックボックスを踏襲することにした。

@ 種類マーク

チェックボックスの前にマークをつけて区別

• 「→」アポイントメント
• 「C」コミットメント
• 「A」アクション (To Do)
• 「W」待ち
• 「I」情報
• 「!」思い浮かんだこと。
• マーク無しは大項目、あるいはスケジュール欄における「→」の省略
• (→、C、A、W は要処理なので○で囲む)

写真撮ってから、→にも○があった方が整合性があることに気がついた。

@ 処理マーク

チェックボックスに入れるマーク。

• 「レ」完了
• 「→」転記済み (将来のスケジュール欄、Palm 上の GTD、プロジェクトファイル等へ)
• 「×」削除 (キャンセル他)
• 「−」アクション不要

アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。

@ その他

• 「UMLのアクターアイコン + 名前リスト」議事メモにおける出席者。
• 「UMLのアクターアイコン + 名前 + 時間」発言、コミットした人の名前と時間。
• 「スケジュール欄のスケジュール項目名の後に(MM/DD)」アポイントメントを取ったときの日付(TQ に書かれているテクニックより)。

とりあえずこんな感じ。

凡例を書いてほぼ日手帳の下敷きに貼り、しばらくはこれでやってみることにする。

• チェックボックスルール拡張 (2005-12-24)
• 2008年夏の GTD 運用ツール (2008-07-23)
• 渋谷のロフトにほぼ日手帳2006を見にいった (2005-09-11)
• GTD Next Actions リスト用ノートをやめる (2007-07-25)
• DELFONICS の Rollbahn Memo を GTD ツールに投入 (2006-03-27)

■ ほぼ Perl 手帳

ほぼ日手帳のカバー・オン・カバーにProgramming Perlのカバーをはさんでみた。

縦 16.5cm に調整してプリントアウトしたもの。解像度はあまり高くないのだが、ぱっと見はいい感じ。

@ この手帳についていないもの:

東京地下鉄路線図、世界通貨一覧表、時刻表、東北新幹線時刻表、世界地図、演算子優先順位表、正規表現の書き方、標準 Perl ライブラリ一覧、おしゃれ小鉢、などなど、

• 結局自分も MOLESKINE に行き着くのか (2005-12-15)
• 方眼手帳と方眼ミーティングメモ (2005-11-27)
• ポケットぽっこりだけれど、色に魅かれてマンダリンオレンジほぼ日手帳2007 (2006-09-15)
• 社内 Perl 勉強会 最終回 (第16回) (2006-09-11)
• ステーショナリーに手を出した - 私的10大ニュース2005 [ misc ] (2005-12-31)

■ チェックボックスルール拡張

ほぼ日手帳、RHODIA 上でのミーティングメモ用にチェックボックスの書き方ルールを1カ月ほど前に決めて運用してみた。 1カ月たって、改良点が見えてきたので以下の通り自分ルールを改良。

@ 種類マーク

チェックボックスの前にマークをつけて区別。

• (S、A、→、C、W は要処理なので○で囲む)
• 変更点
  • 「S」 を追加。「A」 だとちょっと違和感があったものあったので。
  • 「R、⇒」 を追加。記録を予定等と明確に分けて書いておきたいので。

@ 処理マーク

チェックボックスに入れるマーク。

• アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。
• 変更点
  • 完了マークバリエーションに 「/」を追加。「→、o」 とのオーバラップ用。
  • 「o」マークを追加。ミーティング時にその場で発言しておくべき点をメモした際に、すぐに探し出せるように。

@ 追記

「?」疑問点を追加 (2005年12月27日)

[ メモ術 ][ ノート術 ][ 手帳術 ]

• 方眼手帳と方眼ミーティングメモ (2005-11-27)
• 渋谷のロフトにほぼ日手帳2006を見にいった (2005-09-11)
• DELFONICS の Rollbahn Memo を GTD ツールに投入 (2006-03-27)
• 2008年夏の GTD 運用ツール (2008-07-23)
• GTD Next Actions リスト用ノートをやめる (2007-07-25)

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

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

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

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

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

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

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

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

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

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

[ 書評 ]

• PLANNING に違う期待をしてしまった「PLANNING HACKS!」 (2007-07-12)
• 開発の現場 Vol.004 「上流脳」をつくろう! (2006-04-14)
• Joel on Software - 必読書 (2008-08-14)
• 個人目標設定における課題 (2006-02-06)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)

■ 音楽再生にあわせて処理をする amaroK スクリプトを書いてみる

amaroK で聞いた音楽の情報を Last.fm に送って、最近聞いた曲を表示させてみたりアーティスト毎の集計を見てみたりしようと思っていたのだが、どうもこの機能がうまく動かない。

しょうがないので、自前でスクリプトを書いて遊んでみることにした。

@ 書き方

amaroK のスクリプトマネージャから、スクリプトをインストールし実行するとそのスクリプトが実行される。 イベントが発生する度に amaroK からスクリプトの標準入力にイベントの内容をあらわす文字列を送られてくるので、スクリプト側では標準入力を行単位で待ち受けて処理をしていけばよい。

amaroK が終了する際やスクリプトを停止した場合には SIGTERM が送られてくるので、これをキャッチして終了処理を行うようにしておく。 データの保存などの必要がなければ、特に何もする必要無し。

簡単。

http://docs.kde.org/...

スクリプトをインストールするには、一旦 .amarokscript.tar か .amarokscript.tar.bz2 にまとめおく必要がある。 スクリプトマネージャからこのファイルをインストールすると、~/.kde/share/apps/amarok/scripts/ 以下にインストールされて使えるようになる。

自分でいろいろ試す分には一旦形式的にインストールした後、直接このディレクトリの中のファイルを編集してスクリプトを改良していくのが手っ取り早い。

ただしスクリプトの編集をした後は、もちろんスクリプトマネージャでスクリプトを起動しなおす必要がある。 自分の場合はこれも面倒なので、(今回対象としたい)trackChange イベントがきたら特定のディレクトリの下のスクリプトを run-parts で走らせる最低限の amaroK スクリプトを作ってインストールしておき、あとは run-parts で実行されるスクリプトをいじって遊ぶことにした。 これだと毎回 run-parts が呼ばれて非効率は良いが、スクリプトをトライアンドエラーするには楽チンだ。

@ スクリプトから情報の取得

基本的な情報は DCOP インタフェースで取得できる。例えば amaroK で曲を再生中に

 dcop amarok player title

のように dcop コマンドを実行するとタイトルを出力させることができる。 dcop で様々な情報を取得したり、また再生・停止などの操作をしたりすることが可能。

@ 再生履歴を取得するプログラムを書いてみた

実行するたびに dcop を使って amaroK から再生中の曲情報を取得し、最後の10曲に関する情報を Storable でファイルに書き込んでおくスクリプトを作成。 あわせて、カバー画像も amaroK からもらって PerlMagick で縮小して保存しておくようにした。

これであとは Web サーバを更新するようにすれば、最近聞いた曲を Web サイトに表示できるようになるはず。

• FreeMind でマインドマップ (2005-06-02)
• Flickr::UploadでLinuxから画像アップロード (2005-04-22)
• Greasemonkey で XMLHttpRequest を使ってみたら... (2005-10-16)
• [ www.naney.org ] 23:00 明日に移転先サーバの設定完了予定 (2002-01-22)
• Template Toolkit + PAR (2004-09-13)

■ ビジネスメールガイドライン案

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

@ 1. 考える

• 【伝え手】伝え手は誰? (自分)
• 【受け手】受け手は誰?
• 【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
• 【答え】 テーマに対する答え(テーマに対する説明)は何?
• 【期待する反応】受け手に期待する反応は何?
  • 誰に、いつまでに、何をどうして欲しい?
• コミュニケーション手段としてメールは適切?

@ 2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目

@ サブジェクトを書く

• 見ただけでわかるようにする
  • □ 具体的に書く

@ 導入部を書く

コミュニケーション設定を行う。

• □ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
• □ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
• □ 【テーマ】を書く。
• □ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
• □ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
• □ 【期待する反応】を明記する。
  • □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
  • □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
  • NG 「ご意見があればお願いします」 → ない場合は?
  • NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
  • NG 「ご検討ください」→ 検討した後どうして欲しいのか?
• □ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
• □ 特記事項があれば書く
  • □ 答えの情報源など

@ 答え (結論)

結論を書く。

• □ 詳細まで読まなくても済むようにする。
  • NG 「以下のように……」 → 要旨を書く
  • NG 「添付ファイルの通り」 → 要旨を書く

@ 答え (詳細)

根拠・資料などを書く。

• □ 受け手から見て必要十分な情報を書く
  • NG 「添付ファイルの通り」 → 要旨を書く
• □ 受け手が読みやすいように書く
  • □ リスト化する

@ 全般

• □ 具体的に
  • NG 「来週までに……」 → 「×月×日までに……」
  • NG 「先日の……」 → 「×月×日の……」
  • NG 「この間の……」 → 「×月×日の……」
  • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
• □ 論理的に
  • □ 構造化する
  • □ リスト化する (箇条書き化する)
• □ 受け手が読みやすいように
  • □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)

@ 3. 送信する

• □ 送信する前に見直す
  • □ typo チェック
  • □ スペルチェッカ通す

@ A. メールを受信した時

@ まず返信する

どれか

• リクエストを「受ける」 / 返信で処理する (意思決定を返すなど)
• リクエストを「断わる」
• 「別の提案をする」
• 明確化の質問をする

メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。

@ B. 返信する時

@ サブジェクト

• □ テーマが変わったら書き換える

• メールによる社内コミュニケーションの問題 (2006-04-12)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

■ 社内 Perl 勉強会 最終回 (第16回)

リャマ本を使用した社内 Perl 勉強会の16回目を開催。 今日は8人全員。

今日は「初めてのPerl 第3版」第17章「上級テクニック」が範囲。 17章では、「Perl らしい」機能 (Perl 流 eval、grep、 map、スライス)が盛沢山。

@ 今回の反省点

robust なプログラムを書くには Perl では eval 必須の機能なので押さえておきたいところ。 grep、map は何だかんだいって自分が練習問題の解答で使ってしまっているので、他の人もある程度見なれているはず。

練習問題の解答としてはスライスは今回は使用せず。

逆にスカラーコンテキストとリストコンテキストについては、まだ理解が不完全な部分があるようなので解説をしておいた。

@ 最終回を終えて

Perl については

Perl の理解が進んだ (「正規表現」が何か少しわかった、使い方がわかった、知識が増えた)

という一方

Perl の気持ち悪さが理解できた。

という意見があった。

プログラミング言語の勉強会としては

他の人の書き方を見ることが参考になった。実際に書くことで覚えた。

等、定期的に練習問題をやってくるというスタイルに対する評価が得られた。

4月21日から始めて5カ月弱。勉強会でスキルアップをはかっていこうという雰囲気ができてきているのはいい傾向だと思う。

今後もテーマを選んで継続していきたい。

次のテーマをより実用重視のものにするか、基礎固めのものにするのかは悩みどころである。

• 第6回 社内 Perl 勉強会 (2006-06-05)
• 第2回 社内 Perl 勉強会 (2006-04-28)
• 第1回 社内 Perl 勉強会 (2006-04-21)
• 第7回 社内 Perl 勉強会 (2006-06-12)
• 第8回 社内 Perl 勉強会 (2006-06-30)

■ DiKicker に n 年日記機能を追加

久しぶりに DiKicker に機能追加。

@ n 年日記機能

hns で書いていた旧 Web 日記である Naney's Diary の記事を nDiki に移すにあたり、n 年日記にあたる表示がなくて困るので実装した。

最近はぱったり「過去の今ごろ」を書かなくなったけれど、たまには n 年日記を見て振り返るのも悪くない。

n 年日記へのリンクをどこに置くか迷ったが、とりあえず1日の一番最後に置いてみた。 tDiary テーマとの兼ね合いもあって思案中。

@ diary-article:

記事書き用には

 [[diary-article:記事ID]]

という記法を追加。 今までは他の記事へのリンクは URL で指定するしかなかったのだけれど、これだと可搬性がないしスマートでなかったので、あわせて実装してみた。

過去記事も全部この書き方に直したいけれど、それなりに数があるので面倒くさい。 もちろん今のままでも問題はないんだけれど。

過去の(膨大|それなり)のデータをいつまでも利用できるようにシステムを維持することの重要性(と手間)を再確認。

• 21:00 [ nDiki ] hnsからDiKickerへ (2004-02-22)
• 私的10大ニュース2004 [ web ] (2004-12-31)
• hnsのキャッシュを有効に (2004-03-03)
• nDiki に「はてなスター」をつけてみた (2007-07-11)
• www.naney.org が書籍で紹介される? (2004-05-28)

■ ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。

Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

@ テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。

@ TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

@ 印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

@ 面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

@ ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

• http://www.taskjuggler.org/

• コミットメント・リスト vs ガントチャート (2005-10-19)
• amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
• GanttProject で開発スケジュールを作成 (2004-08-26)
• フォト イメージング エキスポ 2005 (2005-03-18)
• Adobe Reader for Palm OS バージョン3.0 (3.... (2004-07-14)

■ Google ドキュメントでソフトウェアかんばん

ソフトウェア開発の見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。

今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。

@ 他の検討候補

TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。

• TRICHORD - 本命。使ってみたいが予算が。
• Firefox + Internote (light-board.com ライク) - カード感は十分。しかし共有に難。
• 影舞用に新しくソフトウェアかんばんテンプレートを作る - 影舞を使い慣れているという点では○。ただストリーカードとタスクカードをどう扱うかが課題。
• Wiki - 以前やって失敗した。
• XPlanner - インストールと学習が手間。それと開発止まっている?
• その他 Agile Project Management Tool - カードメタファで良さそうなのはあるが、予算が。
• Google ドキュメント プレゼンテーション - 矩形をカードにしようとしたが文字は別オブジェクトで書かなければならず×。文字の背景を設定するというのも試したが見栄え・操作性が良くなかった。

スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。

@ スプレッドシートの作成

以下のようにスプレッドシートを作る。

• 1シート目はインフォメーションシートにする。ソフトウェア概説・かんばんルール・通信事項などを書くのに使う。
• 2シート名以降をかんばんにする。複数ソフトウェアならシートを分けてもよいかもしれない。
• かんばんシートE列の背景を「条件をに応じて変更」で本日より前だと赤くなるように設定する。
• かんばんシートF・G・H列の背景を「条件に応じて変更」で @ と書くと背景がそれぞれ赤・黄・青くなるようにする。

• ソフトウェアかんばんサンプル rev. 1

@ カードの書き方

• 各行にはストリーカードかタスクカードを書く。
• ストーリーカード行は目立つように罫線をつける。

TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。

@ 運用

• カード番号は重複しないように。
• カードの状態にあわせて @ を書き換えていく。
• DOING から TODO に移る時には、開始日と担当者名を消さないで残しておく。
• 列単位でソートしないこと。
• タスクの粒度はできるだけ揃える(例えば半日～1日にする)。

@ 課題

• カードが増えた時に使いにくくならないか? 終わったカードを別シートに分けるルールなどを考える。
• タイムボックス等にあわせて並び換える時の手間。
• カード番号が手動。
• 集計について考慮していない。

• ソフトウェアかんばん (2005-10-28)
• WiKicker でソフトウェアかんばん (2007-03-01)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 京大式カード (2005-10-26)
• 今日のさえずり - SO905iCS おそれていたほどは厚く感じなかった (2008-02-08)