nDiki : コミットメント
コミットメント (commitment)
2005年11月27日 (日)
方眼手帳と方眼ミーティングメモ
ほぼ日手帳の使い道であるが、Palm でやっているスケジュール管理をこちらに持ってこようと思う。 スケジュールと、あとログ。
さて、そうとなったら書き方だ。 せっかくなので、何か自分流のスタイルで方眼上でびしっとキメてみたい。
方眼といえば RHODIA。 ミーティングの議事メモなんかは RHODIA No19 にカリカリと書いている。 メモ毎に方眼上にチェックボックスを書いておき、ミーティングが終わったら Palm にスケジュールやアクションを転記したり、その場で処理したりしてそこにチェックを入れていって全部チェックできたらオシマイ。
ここでちょっともやっとしているのが「何でもかんでもチェックボックス」にしている点。これだと処理の必要のない項目までチェックボックスになってしまっており、後でチェック印がはいらないのですっきりしない。
ということで、ミーティングメモも含めて共有の俺スタイルを考えてみた。 基本的にはチェックボックスを踏襲することにした。
種類マーク
チェックボックスの前にマークをつけて区別
- 「→」アポイントメント
- 「C」コミットメント
- 「A」アクション (To Do)
- 「W」待ち
- 「I」情報
- 「!」思い浮かんだこと。
- マーク無しは大項目、あるいはスケジュール欄における「→」の省略
- (→、C、A、W は要処理なので○で囲む)
写真撮ってから、→にも○があった方が整合性があることに気がついた。
処理マーク
チェックボックスに入れるマーク。
アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。
その他
- 「UMLのアクターアイコン + 名前リスト」議事メモにおける出席者。
- 「UMLのアクターアイコン + 名前 + 時間」発言、コミットした人の名前と時間。
- 「スケジュール欄のスケジュール項目名の後に(MM/DD)」アポイントメントを取ったときの日付(TQ に書かれているテクニックより)。
とりあえずこんな感じ。
凡例を書いてほぼ日手帳の下敷きに貼り、しばらくはこれでやってみることにする。
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日 追記
「?」疑問点を追加。
2006年3月23日 (木)
Rekisa で TortoiseSVN から日本語ファイルの差分表示
自分の開発チームでは、 Subversion を用いて pLaTeX2e ドキュメントを共同執筆というスタイルが随分多くなってきた (自分が推進しているわけだが)。
チームメンバのほとんどは Windows 上で TortoiseSVN を使っているのだが、内蔵の差分ビューアを使っていると charset を自動判別してくれないので、いわゆる JIS コードで書いている TeX のソースファイルの扱いがちょっと不便である。
そういえば以前はこの問題の声が聞かれたけれど、最近誰も言わなくなったな。 解決したのか、差分とか見なくなったのか。
数行書き換えて、一つの変更点としてコミットメントログを残せる単位でガシガシコミットしてしまう私と一緒に作業している人は、いつもコミット負けしているはずなのだが。
ということで TortoiseSVN で外部差分ビューアとして使えるツールを調べておこう。 まずは差分表示アプリケーション Rekisa。
日本語のファイルの charset を自動判別してくれるし、表示が美しい。 差分を見るには良さそうである。
マージ作業もあわせてするとすると編集機能が必要だが、Rekisa 自身では直接編集できないようだ(外部エディタを呼び出すことはできる)。
マージまですると WinMerge が本命? こちらはまだ試していないので後日。
2006年4月10日 (月)
ソフトウェアかんばん「見えない化」
チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。
興味深いポイントについて:
ソフトウェアかんばんが見えない
今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。
先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。
ぐらさん言わく「見えない化」
issue tracking
開発中に発生する
などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。
後半「コミットメントリストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。
やはり基本は顔合わせということを実感。
またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。
どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。
できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。
(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)
インタフェースを変更するなら、古いのも deprecated 扱いで残して
複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。
通常開発中のコード内でのこのようなインタフェース変更については
のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。
ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。
止まらないプログラミング
変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。
- 30分ルール
「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。
関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。
チームのトータルのスループットを最大にするようにコミュニケーションしよう。
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日現在以下にあります。
2016年11月8日 (火)
第3回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。
原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。
イテレーティブとインクリメンタルの話のところでは
スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。
とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。
「3.3 予見と適応」では
コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。
とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。
アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。
WIP にまつわる話
作業者の手持ちではなく、作業の手持ちに注目せよ
は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。
「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。
勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。
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 リスト
本書では「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章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリーと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。
2021年11月12日 (金)
第8回 『Hacking Growth グロースハック完全読本』を読む会 第6章 活性化をハックする
『Hacking Growth グロースハック完全読本』を読む会の第8回目。今日は「第6章 活性化をハックする」。
アクティベーション (Activation) についての章。前半の発表を担当した。
まずアハ体験(顧客がプロダクトの価値を感じる瞬間、本書ではアハ・モーメント)までの顧客の行動とコンバージョン率を把握する。
コンバージョン率を高める方法としては
- 顧客の欲求を高める
- 行動を妨げるもの(フリクション)を無くしていく
があるのだが、ほとんどのグロースチームは後者に注力しているという。欲求を高めるのはグロースチームとは別のプロダクトチームが担うのが効率的なのかもしれない。
新規顧客体験の最適化の話では、影響力の6つの原理・フロー状態・ゲーミフィケーション・フォッグ行動モデルといった心理に関する話が登場した。アクティベーションの改善には心理学の治験をいかしつつ実験するのが効率的そうだ。
新規顧客に対してアンケートを取ると回答している間に顧客のコミットメントが高まるという話には、そういう人の動かし方があるのかと感心した。ただ行動過程を削ればいいというものではないのだなあ。
2022年2月12日 (土)
今日のさえずり: 今夜はすき焼き! 我が家では寿司よりレア!
- 07:08 @takaphotoslog 足の爪を切るのに直線刃がいいらしいとと聞きまして、ちょっと試してみようかと。
- 07:43 ぴんっと。 池田山公園 #photography RICOH GR IIIx #GR #GRIIIx #GR3x https://t.co/zPyYt90Drk
- 07:44 おはようございまーす。
- 08:20 @blue12yyy おはようございます!
- 11:36 iPad Pro を iPadOS 15.3.1 にアップデート。 前回 15.3 にアップデートしようとした時にエラーになったの、やはりストレージ不足だった。写真を MacBook Pro に読み込んで消したらアップデート成功した。
- 19:08 今夜はすき焼き! 我が家では寿司よりレア!
- 19:10 ねぇ、帰ろう? #photography RICOH GR IIIx #GR #GRIIIx #GR3x https://t.co/kNDG6LWjce
- 23:03 TETRIS 99 の左右移動をLスティックに戻したら、もれなくハードドロップミス連発。ハードドロップをXボタンにしてみたけれど、これはこれで慣れるまでかかりそうで無し。
- 23:04 しばらくLスティックでやってみるかな。
- 23:21 2022年2月12日(土) やったこと - iPad Pro の写真を MacBook Pro に読み込み - iPad Pro を iPadOS 15.3.1 に - コミットメントと一貫性の原理のノートまとめ - すき焼き - TETRIS 99 の操作変更
ねぇ、帰ろう?#photography
— Naney (@Naney) February 12, 2022
RICOH GR IIIx #GR #GRIIIx #GR3x pic.twitter.com/kNDG6LWjce
About
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。