nDiki : コミットメント

コミットメント (commitment)

「誰が」「いつまでに」「なにをして」「どんな成果を出すか」

2005年10月7日 (金)

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

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

招待状

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

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

セッション

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

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

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

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

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

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

完了

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

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

スポンサード リンク
[ 10月7日全て ]

2005年10月19日 (水)

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

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

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

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

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

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

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

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

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

モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

[ 10月19日全て ]

2005年10月27日 (木)

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

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

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

参加者は計4人。

今回の方法

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

はっ、速い。

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

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

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

感じたメリット

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

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

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

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

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

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

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

  • 提案
  • 割当済み
  • 完了

を用意していた。

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

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

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

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

[ 10月27日全て ]

2005年11月1日 (火)

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

naney:58508089

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

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

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

[ 11月1日全て ]

2005年11月27日 (日)

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

naney:67408112

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

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

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

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

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

種類マーク

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

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

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

処理マーク

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

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

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

その他

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

とりあえずこんな感じ。

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

[ 11月27日全て ]

2005年12月24日 (土)

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

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

種類マーク

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

予定メモマーク意味
o丸囲み S予定
oo丸囲み Aアクション
o丸囲み →将来の予定(要転記)
o丸囲み Cコミットメント
o丸囲み W待ち
oI情報
o!思い浮かんだこと
o?疑問点
oR記録
o記録
  • (S、A、→、C、W は要処理なので○で囲む)
  • 変更点
    • 「S」 を追加。「A」 だとちょっと違和感があったものあったので。
    • 「R、⇒」 を追加。記録を予定等と明確に分けて書いておきたいので。

処理マーク

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

マーク
完了
/完了
転記済み将来のスケジュール欄、Palm 上の GTD、プロジェクトファイル等へ
→ + /転記済み(完了)
x削除キャンセル他
oその場でアクション提案・リクエスト・質問
o + /その場でアクション(完了)
-アクション不要
  • アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。
  • 変更点
    • 完了マークバリエーションに 「/」を追加。「→、o」 とのオーバラップ用。
    • 「o」マークを追加。ミーティング時にその場で発言しておくべき点をメモした際に、すぐに探し出せるように。

追記

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


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

[ 12月24日全て ]

2006年3月23日 (木)

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

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

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

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

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

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

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

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

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

[ 3月23日全て ]

2006年4月10日 (月)

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

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

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

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

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

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

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

issue tracking

開発中に発生する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 30分ルール

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

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

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

[ 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!)

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

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

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

追記

日本語訳は以前は

  • http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ItsNotJustStandingUp

にありましたが2017年2月2日現在以下にあります。

[ 4月6日全て ]

2016年11月8日 (火)

第3回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。

原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。

イテレーティブとインクリメンタルの話のところでは

スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。

とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。

「3.3 予見と適応」では

コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。

アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。

WIP にまつわる話

作業者の手持ちではなく、作業の手持ちに注目せよ

は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。

「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。

勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。

[ 11月8日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・PO をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.088778s / load averages: 0.99, 0.77, 0.73
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker