git checkout -b <ブランチ> git commit --allow-empty # '[WIP] 作業内容' でコミットメッセージを書く。 git push origin <ブランチ>
して GitHub / GitHub Enterprise 上で pull request を作成する。
2週間ほど前からタスク管理に TaskPaper を使い始めています。アウトライナーとしてプロジェクトやタスクをいろいろ検討しながら分解していけますし、近くにノートを書けるフォーマットなので気軽に補足を書いておけたりするしで、とても便利に使っています。ただ1点不便だなと思うことがあります。検索による絞り込みで今日やるタスクをざっと眺められる点は良いのですが、それらを今日やりたい順番に並べることができないのです。
一方 GTD をしている中で「状況」「時間」「エネルギー」「優先度」の順の基準で次の行動を選んで実行していくと、 WIP がどんどん増えてしまうなと最近思うようになってきました。やはり仕掛かるプロジェクトを減らしてその中のタスクをどんどん進めた方が良いなと最近感じています。
そんなことを考えて手動で TaskPaper 上に Doing リストを作ることにしました(過去にもたまに紙でやったりしたことがありました)。ルーチンワークのリストアップなどが面倒かなと思っていたのですが、雛形からコピーするのが思ったより苦ではなさそうです。あとはプロジェクトの中からどう抜き出してくるか(プロジェクトごと Doing リストに移動してくるか、 Doing には端的に書いておいて詳細はプロジェクトの方を参照するのか)がちょっと迷っていますが、ここはやりながら考えていくつもりです。
フィルタされてきたタスクリストから実行していくよりも Doing リストから実行していく方が「自分で決めたことを上からやっていくぞ」と覚悟を決められので、ガッツのいるタスクを先送りを減らせそう。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。
スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。
そんなメッセージを本章から受け取りました。
第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。
「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。
エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。
ふりかえって出てきた話題としては
などが上がりました。
また実際に読む会と並行してスクラムを行ってきた中で
などの話が出ました。
スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。
3月下旬にタスク管理ツールを Remember The Milk から TaskPaper に替えて1カ月弱経ちました。基本 MacBook Pro を開いている仕事に関するタスク管理では引き続き TaskPaper を使い、逆に PC を開いていない時間も多い個人のタスク管理はメインを Remember The Milk に戻すことにしました。
今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャル スクラムの「16章 ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャル スクラムを読む会をやって以来なので久しぶりです。
今回の自分のパートは以下。
「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は
がポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。
仕掛品の戦略は作業中のプロダクトについて
を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。
16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら
だとのこと。参考にします。
やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。
読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。
とある複雑な領域のプロジェクトについてスクラムがいいのではと思って準備したんだけれど、メンバがコミットできるエネルギーを考えると失敗する可能性が高いと思えてきた。
事業全体での WIP を下げた方がいいなと。
昨日から週次レビューをかねてタスクをしっかりめに棚卸し。それから最近課題に感じていたところがうまくまわるように Remember The Milk のリスト・スマートリストの構成をいじってみた。
あれこれやった方がいいとちょっとずつルーチンワークが増えていくので、たまに見直しが必要。昨日はがっつりルーチンワークを掃除。 one-on-one 定例ミーティングの前日準備はタスクから外して、やったあとの事後整理の中で一緒にやってしまおう。
仕掛り(WIP)なプロジェクト減らして、もっとプロジェクトをどんどん終わらせるようにしたい。プロジェクトを入れておく Remember The Milk リストを以下に分けてみた。
優先的にやるのを active に分けて明確にして進めていけるようにした。
それから確実にやることなのだけれど、すぐにはやらないものを later に分けることにした。someday だと「やれたらいいなあ」というのと混ざってしまって嫌だし、かといって今のうちに詳細化するコストを払いたくないなあというものを入れておく場所にした。 later にある次の行動タスクが someday のと同様に全体の行動タスクリストに上がってこないようにして、クローズドリスト作成時に負担にならないようにした。これで日次レビュー・週次レビューもスムーズにできるようになるといいな。
昨日 iA Writer のライブラリ機能もいいなと感じたので、今日は iA Writer メインで作業してみた。
iA Writer は登録したロケーション以下にあるファイルのハッシュタグがオーガナイザー(一番左のペイン)に一覧表示される。 #WIP とファイルに書いておけば、1クリックで仕掛中のファイルがリストに表示されるので便利だ。
Ulysses for Mac で「すべて」で #WIP 検索をかければ同様に探せるが、ショートカットを作っておけないので iA Writer の方が楽でいい(Ulysses でフィルタを作るという手があるが、その場合外部フォルダ単位でしか絞り込めない)。
一方 Ulysses は「複数ファイルをまとめて選択してあたかも1ファイルのように編集できる」という強力な機能があるため、複数ファイルをどんどん整理していくのは Ulysses 方が圧倒的に便利。それからライブラリでフォルダをツリー表示できるのでファイルの移動も Ulysses の方がずっとやりやすい。
複数フォルダ・複数ファイルにまたがって作業する時はやはり Ulysses for Mac の方が便利だな。 横断的にハッシュタグを利用する時と1つのファイルをじっくり編集する時、それからテキストファイル以外が混在するフォルダでの作業は iA Writer も使うというのが良さそう。
(あとはアウトライナーが使いたい時は TaskPaper を使ったり、気がつけば Emacs を使っていたり……)
[ Mac アプリケーション ]
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。