nDiki : コミットメント

スポンサードリンク

2005年9月6日 (火)

■ 南仏プロヴァンス料理 PATATI PATATA

スポンサードリンク

夜までかかかったミーティング終了後、GAKU氏と本社からきたスタッフと3人で夕食へ。最初に向かったお店が閉まっていたため、同じ清洲橋通りにある PATATI PATATA へ入ってみた。 2003年にお金を貯めてカリブを見にカナダへ旅立ったスタッフの送別会のとき以来、2年ぶり2度目。前回いったときと同じく、スタッフはフレンドリー。

夜のメニューはそこそこいい値段でちょっと気軽にこれるお店ではないが、今回はちょっとしたマネーがあるので(ありがとうございます)挑戦してみた。

全般的に濃い味であるものの、まとまっていて値段相応に美味。デザートの「レモンのタルト」がちょっとくたびれていたのが惜しい。

今日の話題は

最近の仕事の進め方について。社長と私が同タイミングで、コミットメント・次の行動などを踏まえたスタイルを取り入れたという話(社長は「特別に最近からというわけではない」とおっしゃりそうであるが)。Life Hacks など。
映画。ポケモン、ゴジラ、ゾンビ映画。

といったところ。

東京都台東区浅草橋5-5-5 キムラビル1F (Google マップ)

◇ Twitter やってます。この記事が気にいったらぜひ twitter.com/Naney の follower になってください。

[ permalink ]

新年会 + 送別会 (2005-01-12)
酒蔵駒忠浅草橋西口店 (2004-10-19)
浅草橋海運堂 (2004-06-23)
今日のさえずり - 昭和通りでホームレスがトロフィーかかげてる! (2008-08-31)
プチフレックスタイム導入 (2002-11-14)

[ 9月6日全て ]

2005年10月7日 (金)

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

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

*1 @IT: 初めてのプロジェクトリーダー(6) 「ふりかえり」でプロジェクトを改善する

@ 招待状

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

「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
各評価対象について「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分。ほぼ予定時間とぴったり。事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

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

[ permalink ]

すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
すごい会議はじめての全手順(1/2) (2005-06-30)
今日のさえずり - 壊れた金具の代わりに南京錠 (2009-04-14)
ソフトウェアかんばん「見えない化」 (2006-04-10)
いまいちパッとしなかった「ふりかえり」 (2007-02-28)

[ 10月7日全て ]

2005年10月19日 (水)

■ コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。コミットメント・リスト派とはまさに私の事である(多分)。いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。「ガントチャートは駄目」だとも思っていない。以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。両方同時に使っているケースもあるであろう。またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

@ モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

作業時間がある程度精度よく見積もれる
作業時間と成果が比例的である

であるような場合はガントチャートで計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

@ ガントチャートを利用したマネジメントの特徴

マネージャからのトップダウン的なスケジュール向き
リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
比較的多人数のチームでもいける
リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
人月計算/コスト積算できる
プロジェクト外からの割り込みの発生によって狂いやすい
成果がみにくい
チェックしにくい
- 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
ぱっと見、計画できている気がする
期間が長いと、チャートが見にくくなる
1日単位で見積もりたくなる
休日が気になりだす

@ コミットメント・リストを利用したマネジメントの特徴

担当の裁量を尊重・重視
コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
期日前にせっぱつまりやすい
依存関係が複雑だと把握しにくい
専用のソフトウェアがなくても可能
他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
線表派からみると計画だと思ってくれないかも

@ 自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

スケジュールの変更があった時に面倒
現状とあわなくなってくるとだんだん見なくなった
結局だんだんメンテナンスしなくなってしまう
進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

@ コミットメント・リストでうまくいっている点

成果が達成できているか、そうでないかが明確
達成できていないコミットメントのチェック、フォローができている
担当自身が忘れていたコミットメントもクロスチェックで再認識できる
コミットメント一つ達成するたびに「いい気分を味わえる」

@ まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。自分が扱っているプロジェクトがそういうものではないのだなと。

[ permalink ]

ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
すごいKPT事後評価セッション (2005-10-07)
情報カードを使って高速すごい会議 (2005-10-27)
Joel on Software - 必読書 (2008-08-14)
ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)

[ 10月19日全て ]

2005年10月27日 (木)

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

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

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

参加者は計4人。

@ 今回の方法

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

はっ、速い。

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

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

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

@ 感じたメリット

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

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

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

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

[ permalink ]

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

■ 影舞でのコミットメント・リストの状態を改良

影舞でコミットメント・リストを作成して運用している。

今までコミットメントに設定できる状態として

提案
割当済み
完了

を用意していた。

担当は「割当済み」コミットメントを達成すると状態を「完了」に変更するのだが、そうすると割当済みリストから消え、よく見る影舞のプロジェクトトップページに表示されなくなる。メンバにメールで通知がいくものの、全員で完了の合意が取れていないのがちょっとよくないな。なので、

提案
割当済み
確認待ち
完了

のようにしてみた。担当が達成したと判断したら「確認待ち」とし、コミットメント・リストの進捗チェック時に皆で確認した上で「完了」とする流れに。これでより、プロジェクトの状態を皆で共有できるのではないかと。

ちなみに「提案」は一度も使われていないので不要のようだ。

[ permalink ]

すごい会議の正しい手順 (2005-07-04)
すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
すごい会議はじめての全手順(2/2) (2005-07-01)
TQ - 心の安らぎを発見する時間管理の探究 (2005-06-16)
情報カードを使って高速すごい会議 (2005-10-27)

[ 10月27日全て ]

2005年11月1日 (火)

■ もっとバラエティグッズを置いて欲しいドン・キホーテ 秋葉原店

昨年8月14日にオープンしたドン・キホーテ秋葉原店であるが、まだ1度も足を運んだことがなかった。

開発チーム内で疑問点が出た時に気兼ねなく声をかけて質問できるように、なんかウルトラハットのようなグッズが欲しいと思っていたので(というか調達がコミットメントになっている)、昼休みにちょっといってみた。

思ったよりバラエティグッズが少なくてがっかり。

[ permalink ]

今日のさえずり - フロスティ食べたい (2009-12-10)
今日のさえずり - これ Emacs なのよね (2010-01-26)
今日のさえずり - ささやかな気持ちDES (2008-11-07)
今日のさえずり - Twitter ずっと見てたら仕事の効率落ちるんじゃない? (2008-10-31)
12:15 今日の秋葉原 - HDD購入 - (2001-09-20)

[ 11月1日全て ]

2005年11月27日 (日)

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

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

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

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

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

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

@ 種類マーク

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

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

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

@ 処理マーク

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

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

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

@ その他

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

とりあえずこんな感じ。

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

[ permalink ]

[ 11月27日全て ]

2005年12月24日 (土)

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

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

@ 種類マーク

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

予定	メモ	マーク	意味
o		丸囲み S	予定
o	o	丸囲み A	アクション
	o	丸囲み →	将来の予定(要転記)
	o	丸囲み C	コミットメント
	o	丸囲み W	待ち
	o	I	情報
	o	!	思い浮かんだこと
	o	?	疑問点
	o	R	記録
	o	⇒	記録

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

@ 処理マーク

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

マーク
レ	完了
/	完了
→	転記済み	将来のスケジュール欄、Palm 上の GTD、プロジェクトファイル等へ
→ + /	転記済み(完了)
x	削除	キャンセル他
o	その場でアクション	提案・リクエスト・質問
o + /	その場でアクション(完了)
-	アクション不要

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

@ 追記

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

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

[ permalink ]

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

[ 12月24日全て ]

2006年3月23日 (木)

■ Rekisa で TortoiseSVN から日本語ファイルの差分表示

自分の開発チームでは、 Subversion を用いて pLaTeX2e ドキュメントを共同執筆というスタイルが随分多くなってきた (自分が推進しているわけだが)。

チームメンバのほとんどは Windows 上で TortoiseSVN を使っているのだが、内蔵の差分ビューアを使っていると charset を自動判別してくれないので、いわゆる JIS コードで書いている TeX のソースファイルの扱いがちょっと不便である。

そういえば以前はこの問題の声が聞かれたけれど、最近誰も言わなくなったな。解決したのか、差分とか見なくなったのか。

数行書き換えて、一つの変更点としてコミットメントログを残せる単位でガシガシコミットしてしまう私と一緒に作業している人は、いつもコミット負けしているはずなのだが。

ということで TortoiseSVN で外部差分ビューアとして使えるツールを調べておこう。まずは差分表示アプリケーション Rekisa。

http://hp.vector.co.jp/.../Rekisa/

日本語のファイルの charset を自動判別してくれるし、表示が美しい。差分を見るには良さそうである。

マージ作業もあわせてするとすると編集機能が必要だが、Rekisa 自身では直接編集できないようだ(外部エディタを呼び出すことはできる)。

マージまですると WinMerge が本命? こちらはまだ試していないので後日。

[ permalink ]

[ 3月23日全て ]

2006年4月10日 (月)

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

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

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

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

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

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

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

@ issue tracking

開発中に発生する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30分ルール

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

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

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

[ permalink ]

[ 4月10日全て ]

2007年4月6日 (金)

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

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

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

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

@ ルール

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

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