nDiki : コミットメント

コミットメント (commitment)

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

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日全て ]

2017年8月6日 (日)

仕事に追われない仕事術 マニャーナの法則 完全版

仕事に追われない仕事術 マニャーナの法則 完全版

タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。

マニャーナの法則

まずマニャーナの法則ですが

  • 原則1 新しい仕事は「明日やる」を基本にする
  • 原則2 クローズリストを使う

という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。

すぐやる」ことの弊害

すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。

すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。

ただ「すぐやる」については

  • 「後回しにしてチャンスを逃す」ことのないようにする。
  • 先送りすることで増大するコストを最小化する。

というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。

全員がマニャーナの法則をやるとどうなるか?

個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。

このあたり要注意に思われます。

緊急レベルを判断する

入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。

  • 緊急レベル1「今すぐ」
  • 緊急レベル2「今日中に」
  • 緊急レベル3「明日やる」(ベスト)

本書では「明日やる」がベスト。

これはすでに2週間前からRemember The Milk の優先度設定に取り入れてみています。

WILL DO リスト

その日にやるとコミットしたタスクを入れておくクローズリスト。自分は Remember The Milk でタスクの優先度を1にすることでリスト化しています。

処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。

1日の最後に何をおいても明日の WILL DO リストは作成することが必須とあります。仕事については実践していますが、プライベートでは翌日の WILL DO リストを夜に作るのがまだ習慣にしきれていません。

ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。翌日時間が足りず WILL DO リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。

やり残しをどうするか?

WILL DO リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。

これは今週から Remember The Milk で backlog タグを付けるようにして実践中です。

ファースト・タスク

ファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。

  • 原則1 とにかく、する (Do)
  • 原則2 一番始めに、する (First)
  • 原則3 毎日、する (Every day)

ファースト・タスクに向いている仕事は

  • 「やり残し」を片付ける
  • 仕事のシステムを修正する
  • プロジェクトを進める

です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。

実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。

ダッシュ法

ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。

二分等法 すべての仕事を半分にする

プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。

その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。

全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。

行動の合間に考える習慣をつける

最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。

  • 「毎日15分」など時間を決め確保する。
  • 邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。
  • 時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。

というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。

冒頭にキーワードが説明されているのが良かった

最後に本書の構成について。

本書では冒頭で「本書に登場する18のキーワード」として

  • 「クローズ・リスト」「オープン・リスト」「チェック・リスト」
  • コミットメント」「本当の仕事」「忙しいだけの仕事」
  • 「バッファー・ゾーン」「マニャーナの法則
  • 「タスク」「プロジェクト」
  • 「タスク・ダイアリー」
  • 「デイリー・タスク」「ファースト・タスク」
  • 「TODOリスト」「WILL DOリスト」
  • 「ダッシュ法」「期限の効果」
  • 「ラベリング」

が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。

本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。


[ 読書ノート ] [ お薦めの本 ]

[ 8月6日全て ]

2017年10月3日 (火)

半期毎の人事評価入力【日記】

メンバの1時評価の検討と入力を完了。

半期末に各メンバが自己評価をしたあと振り返り面談をし評価を入力するという制度、どうもイケてない気がしてきています。

  • 半期単位でのコミットメント設定がもはや非現実的
  • 半期末期初の負担が大きい
  • 結果を出してからフィードバックまでの期間が長い
  • 評価するされるの関係が強く心理的安全に対する影響が大きい
[ 10月3日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

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

follow us in feedly

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

月別インデックス
Process Time: 0.052897s / load averages: 0.65, 0.62, 0.66
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker