ほぼ日手帳の使い道であるが、Palm でやっているスケジュール管理をこちらに持ってこようと思う。 スケジュールと、あとログ。
さて、そうとなったら書き方だ。 せっかくなので、何か自分流のスタイルで方眼上でびしっとキメてみたい。
方眼といえば RHODIA。 ミーティングの議事メモなんかは RHODIA No19 にカリカリと書いている。 メモ毎に方眼上にチェックボックスを書いておき、ミーティングが終わったら Palm にスケジュールやアクションを転記したり、その場で処理したりしてそこにチェックを入れていって全部チェックできたらオシマイ。
ここでちょっともやっとしているのが「何でもかんでもチェックボックス」にしている点。これだと処理の必要のない項目までチェックボックスになってしまっており、後でチェック印がはいらないのですっきりしない。
ということで、ミーティングメモも含めて共有の俺スタイルを考えてみた。 基本的にはチェックボックスを踏襲することにした。
チェックボックスの前にマークをつけて区別
写真撮ってから、→にも○があった方が整合性があることに気がついた。
チェックボックスに入れるマーク。
アクション不要マークを用意することで、処理後全部のチェックボックスにマークを入れた状態にできるのですっきりする。
とりあえずこんな感じ。
凡例を書いてほぼ日手帳の下敷きに貼り、しばらくはこれでやってみることにする。
ほぼ日手帳、RHODIA 上でのミーティングメモ用にチェックボックスの書き方ルールを1カ月ほど前に決めて運用してみた。 1カ月たって、改良点が見えてきたので以下の通り自分ルールを改良。
チェックボックスの前にマークをつけて区別。
予定 | メモ | マーク | 意味 |
o | 丸囲み S | 予定 | |
o | o | 丸囲み A | アクション |
o | 丸囲み → | 将来の予定(要転記) | |
o | 丸囲み C | コミットメント | |
o | 丸囲み W | 待ち | |
o | I | 情報 | |
o | ! | 思い浮かんだこと | |
o | ? | 疑問点 | |
o | R | 記録 | |
o | ⇒ | 記録 |
チェックボックスに入れるマーク。
マーク | ||
レ | 完了 | |
/ | 完了 | |
→ | 転記済み | 将来のスケジュール欄、Palm 上の GTD、プロジェクトファイル等へ |
→ + / | 転記済み(完了) | |
x | 削除 | キャンセル他 |
o | その場でアクション | 提案・リクエスト・質問 |
o + / | その場でアクション(完了) | |
- | アクション不要 |
「?」疑問点を追加。
自分の開発チームでは、 Subversion を用いて pLaTeX2e ドキュメントを共同執筆というスタイルが随分多くなってきた (自分が推進しているわけだが)。
チームメンバのほとんどは Windows 上で TortoiseSVN を使っているのだが、内蔵の差分ビューアを使っていると charset を自動判別してくれないので、いわゆる JIS コードで書いている TeX のソースファイルの扱いがちょっと不便である。
そういえば以前はこの問題の声が聞かれたけれど、最近誰も言わなくなったな。 解決したのか、差分とか見なくなったのか。
数行書き換えて、一つの変更点としてコミットメントログを残せる単位でガシガシコミットしてしまう私と一緒に作業している人は、いつもコミット負けしているはずなのだが。
ということで TortoiseSVN で外部差分ビューアとして使えるツールを調べておこう。 まずは差分表示アプリケーション Rekisa。
日本語のファイルの charset を自動判別してくれるし、表示が美しい。 差分を見るには良さそうである。
マージ作業もあわせてするとすると編集機能が必要だが、Rekisa 自身では直接編集できないようだ(外部エディタを呼び出すことはできる)。
マージまですると WinMerge が本命? こちらはまだ試していないので後日。
チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。
興味深いポイントについて:
今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。
先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。
ぐらさん言わく「見えない化」
開発中に発生する
などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。
後半「コミットメントリストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。
やはり基本は顔合わせということを実感。
またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。
どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。
できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。
(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)
複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。
通常開発中のコード内でのこのようなインタフェース変更については
のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。
ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。
変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。
「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。
関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。
チームのトータルのスループットを最大にするようにコミュニケーションしよう。
Jason Yip 氏による「朝会のパターン:立ってるだけじゃないよ (It's Not Just Standing Up: Patterns of Daily Stand-up Meetings)」という記事の日本語訳を、数日前に kdmsnr 氏が公開された。
あるソフトウェア開発プロジェクトで2月から朝会を行ってみているのだが、この記事をみてもっと工夫できそうだということで、良さそうな点を取り入れてみることにした。
一昨日にに新ルールをアナウンスしたのだが、昨日は私は休んでしまったので自分としてはスタートは今日から。
記事を参考に、以下のルールにしてみた。
見える化については、まずはコミットメントを A3 ホワイトボードに書き出すことにした。
3人のチームなので今日は、10分で終了。 いつもは問題解決をつい始めてしまい長引きがちであったが、こうして明確にルールを共有しておくと、互いに制止しやすくてなかなか良い。
しばらくこのスタイルでやってみて、また改良していくことにしよう。
日本語訳は以前は
にありましたが2017年2月2日現在以下にあります。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会3回目。今日は第3章 アジャイルの原則。
原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。
イテレーティブとインクリメンタルの話のところでは
スクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。そうすることで、両者を個別に用いる際の欠点を無視できるようになる。
とさらりと書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。
「3.3 予見と適応」では
コミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。
とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。
アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。
WIP にまつわる話
作業者の手持ちではなく、作業の手持ちに注目せよ
は、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。
「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。
勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。
タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。今までスルーしていたのですがここ最近クローズドリストの考え方を取り入れてみているので、その辺りの話が書かれている「仕事に追われない仕事術 マニャーナの法則 完全版 (Do It Tomorrow and Other Secrets of Time Management)」を読んでみました。
まずマニャーナの法則ですが
という2つの原則のこととあります。日本語ではマニャーナの法則と訳されていますが the mañana principle なので「(行動)原則」の方が適切に感じました。
すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。
「すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。
ただ「すぐやる」については
というメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。
個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。個人の稼働が最適化されるかわりに、作業の手待ち(idle work)が多く発生することになるからです。
このあたり要注意に思われます。
入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。
本書では「明日やる」がベスト。
これはすでに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つ。
ファースト・タスクに向いている仕事は
です。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。
実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。
ダッシュ法はポモドーロテクニックにつながるところを感じました。ちょっとマニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。
プロジェクトをタスクに分解する方法。 GTD でプロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。
その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。
全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。
最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。
というものです。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。ぜひ取り組んでみたいなと思います。
最後に本書の構成について。
本書では冒頭で「本書に登場する18のキーワード」として
が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。
本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリーと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。
『Hacking Growth グロースハック完全読本』を読む会の第8回目。今日は「第6章 活性化をハックする」。
アクティベーション (Activation) についての章。前半の発表を担当した。
まずアハ体験(顧客がプロダクトの価値を感じる瞬間、本書ではアハ・モーメント)までの顧客の行動とコンバージョン率を把握する。
コンバージョン率を高める方法としては
があるのだが、ほとんどのグロースチームは後者に注力しているという。欲求を高めるのはグロースチームとは別のプロダクトチームが担うのが効率的なのかもしれない。
新規顧客体験の最適化の話では、影響力の6つの原理・フロー状態・ゲーミフィケーション・フォッグ行動モデルといった心理に関する話が登場した。アクティベーションの改善には心理学の治験をいかしつつ実験するのが効率的そうだ。
新規顧客に対してアンケートを取ると回答している間に顧客のコミットメントが高まるという話には、そういう人の動かし方があるのかと感心した。ただ行動過程を削ればいいというものではないのだなあ。
ねぇ、帰ろう?#photography
— Naney (@Naney) February 12, 2022
RICOH GR IIIx #GR #GRIIIx #GR3x pic.twitter.com/kNDG6LWjce
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。