nDiki : WIP

WIP でmixi日記を書いてみた

一昨日からつぶやかないでmixi日記を書くことにした流れで、今日は朝に WIP (Work In Progress) なmixi日記エントリを作って追記・編集するスタイルで更新してみました。

• WIP でmixi日記を書いてみる日 (マイミクまで)

やってみた感想

• 朝にこれをやってみよう思いついた時は勢いがあったけれど、結局あまり大きなネタもなくそれほど書き足さなかった。
• age られないので予想通り時間とともにイイネ！などのフィードバックが減ってくるのでモチベーションが下がる。
• 多分完成版を見ている人はあまりいない。

やはり今の仕組みでは書き上げてから投稿した方が良いです。

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

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

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

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

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

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

「3.3 予見と適応」では

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

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

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

WIP にまつわる話

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

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

• ゆとりの法則

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

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

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

WIP を下げるために GTD でプロジェクトリストからバックログを分ける

スクラムでソフトウェア開発をしていて仕掛り(WIP)を減らすことのメリットを体感しています。そして考えてみるとプライベートを含め個人でやる事がどんどん増えてしまっている理由の一つに WIP が多すぎるのではと思えてきました。

GTD では次の行動を決めてリストに放り込み、あとはその時の状況で実行可能なものを選んでやっていきます。局所的には一番効率が良いように見えるのですが、気をつけないと WIP なプロジェクトがどんどん増えてしまいがちで、自分の場合、気がつくとあまり何もできていないなという状態になってしまいます。

Someday/Maybe リストが GTD にはあるので、すぐにやらないものはそこに入れておくという方法もあります。しかしこのリストはかなりぼんやりしたものも混ざっているので「既に ready だけれど WIP を上げないためにまだやらないプロジェクト」を一緒に入れておくのはかなり気持ち悪い。

ということでプロジェクトリストについて「(狭義のやっている/やる)プロジェクトリスト」と「バックログリスト」の2つに分けてみることにしました。タスク管理ツール Remember The Milk でバックログリストの方のタスクは拾わないようにスマートリストを修正。毎朝軽く眺めてバックログリストから今日仕掛ってもいいものをプロジェクトリストに移すようにします。

今日やり始めてみたところ前よりは集中して取り組めて捗りました。いいかも。

今日のさえずり: 「スクラムチーム外によるコードレビュー」の待ちがボトルネックになるの、全体での WIP が多すぎるんだな

2017年03月24日

• 19:21 今日は大安ですぞ。
• 25:15 「スクラムチーム外によるコードレビュー」の待ちがボトルネックになるの、全体での WIP が多すぎるんだな。

TaskPaper で Doing リスト

2週間ほど前からタスク管理に TaskPaper を使い始めています。アウトライナーとしてプロジェクトやタスクをいろいろ検討しながら分解していけますし、近くにノートを書けるフォーマットなので気軽に補足を書いておけたりするしで、とても便利に使っています。ただ1点不便だなと思うことがあります。検索による絞り込みで今日やるタスクをざっと眺められる点は良いのですが、それらを今日やりたい順番に並べることができないのです。

一方 GTD をしている中で「状況」「時間」「エネルギー」「優先度」の順の基準で次の行動を選んで実行していくと、 WIP がどんどん増えてしまうなと最近思うようになってきました。やはり仕掛かるプロジェクトを減らしてその中のタスクをどんどん進めた方が良いなと最近感じています。

そんなことを考えて手動で TaskPaper 上に Doing リストを作ることにしました(過去にもたまに紙でやったりしたことがありました)。ルーチンワークのリストアップなどが面倒かなと思っていたのですが、雛形からコピーするのが思ったより苦ではなさそうです。あとはプロジェクトの中からどう抜き出してくるか(プロジェクトごと Doing リストに移動してくるか、 Doing には端的に書いておいて詳細はプロジェクトの方を参照するのか)がちょっと迷っていますが、ここはやりながら考えていくつもりです。

フィルタされてきたタスクリストから実行していくよりも Doing リストから実行していく方が「自分で決めたことを上からやっていくぞ」と覚悟を決められので、ガッツのいるタスクを先送りを減らせそう。

第23回 エッセンシャル スクラムを読む会 (最終回)

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

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

エッセンシャル スクラムを読む会のふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

• 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
• チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
• 原則大事(第3章・第14章など)。
• WIP を下げる重要性をあらためて学んだ。
• 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

• プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
• スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
• スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
• 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

• 2016年10月25日 第1回 第1章 イントロダクション
• 2016年11月01日 第2回 第2章 スクラムフレームワーク
• 2016年11月08日 第3回 第3章 アジャイルの原則
• 2016年11月15日 第4回 第4章 スプリント
• 2016年11月22日 第5回 第5章 要件とユーザーストーリー
• 2016年11月29日 第6回 第6章 プロダクトバックログ
• 2016年12月06日 第7回 第7章 見積もりとベロシティ
• 2016年12月13日 第8回 第8章 技術的負債
• 2016年12月20日 第9回 第9章 プロダクトオーナー
• 2017年01月10日 第10回 第10章 スクラムマスター
• 2017年01月17日 第11回 第11章 開発チーム
• 2017年01月24日 第12回 第12章 スクラムチームの構成
• 2017年01月31日 第13回 第13章 マネージャー
• 2017年02月07日 第14回 第14章 スクラムのプランニングの原則
• 2017年02月14日 第15回 第15章 さまざまなプランニング
• 2017年02月21日 第16回 第16章 ポートフォリオプランニング
• 2017年02月28日 第17回 第17章 エンビジョニング (プロダクトプランニング)
• 2017年03月07日 第18回 第18章 リリースプランニング (長期計画)
• 2017年03月14日 第19回 第19章 スプリントプランニング
• 2017年03月21日 第20回 第20章 スプリントの実施
• 2017年03月28日 第21回 第21章 スプリントレビュー
• 2017年04月04日 第22回 第22章 スプリントレトロスペクティブ
• 2017年04月14日 第23回 第23章 未来へ

Remember The Milk のかわりに TaskPaper を使って気付いたこと

3月下旬にタスク管理ツールを Remember The Milk から TaskPaper に替えて1カ月弱経ちました。基本 MacBook Pro を開いている仕事に関するタスク管理では引き続き TaskPaper を使い、逆に PC を開いていない時間も多い個人のタスク管理はメインを Remember The Milk に戻すことにしました。

Remember The Milk を離れて TaskPaper を使って気付いたこと

• ソート機能で並べられたリストよりも、主体的に手で並べたリストの方がより重いタスクをやる気になる。Doing リスト良い。
• そのかわり Remember The Milk で「日時順にソートしてやることを確認できる」「開始日時指定を使って夕方以降のタスクを隠しておける」などはあらためて便利だと思った。
• 「次の行動(GTD)」を抽出したリストでタスクを進めていくと「重いタスクを後回しにしがち」「WIP が増える」。 TaskPaper で Doing リストに「プロジェクト(GTD)」を入れるようにしたら同じプロジェクトのタスクをまとめて取り掛かりやすくなった。
• TaskPaper ではメモも気軽に一緒に書いておけて便利。
• TaskPaper はサブタスクを展開した状態で見渡せるのも良い。 Remember The Milk ではサブタスク単位でしか見られないのでサブサブタスクまであまり使わずにできるだけフラットにした方が良さそう。
• TaskPaper ファイルは1つにしておいた方が煩雑でなくて良い。

TaskPaper のメリットというよりは Doing リストのメリットに気付けたかなという1カ月でした。