ここ最近テキストファイルでのノート環境が整ってきて、どこでも直接 Dropbox 上のファイルにメモする事ができるようになってきました。
直接テキストファイルに書いた方が後の整理が楽なのでここ最近 Google Keep を使わないで済ませるようにしていたのですが特に困ることはありませんでした。
もういいかなということで Google Keep に残っていたメモを全部テキストファイルに移しきり、Google Keep アプリ Xperia Z5 からアンインストール。ツールが一つ減ってすこし身軽になりました。
[ ノート・日記はテキストファイルに ]
スクラムでソフトウェア開発をしていて仕掛り(WIP)を減らすことのメリットを体感しています。そして考えてみるとプライベートを含め個人でやる事がどんどん増えてしまっている理由の一つに WIP が多すぎるのではと思えてきました。
GTD では次の行動を決めてリストに放り込み、あとはその時の状況で実行可能なものを選んでやっていきます。局所的には一番効率が良いように見えるのですが、気をつけないと WIP なプロジェクトがどんどん増えてしまいがちで、自分の場合、気がつくとあまり何もできていないなという状態になってしまいます。
Someday/Maybe リストが GTD にはあるので、すぐにやらないものはそこに入れておくという方法もあります。しかしこのリストはかなりぼんやりしたものも混ざっているので「既に ready だけれど WIP を上げないためにまだやらないプロジェクト」を一緒に入れておくのはかなり気持ち悪い。
ということでプロジェクトリストについて「(狭義のやっている/やる)プロジェクトリスト」と「バックログリスト」の2つに分けてみることにしました。タスク管理ツール Remember The Milk でバックログリストの方のタスクは拾わないようにスマートリストを修正。毎朝軽く眺めてバックログリストから今日仕掛ってもいいものをプロジェクトリストに移すようにします。
今日やり始めてみたところ前よりは集中して取り組めて捗りました。いいかも。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。
今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。
複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。
ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。
フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。
ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。
本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。
スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。
リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。
スクラムのプロダクトバックログリファインメントの時に、上位のプロダクトバックログはスプリントで完成させられるように分割詳細化していきます。
|-- P1 (分割詳細化済み) | |-- P1-1 | |-- P1-2 | `-- P1-3 |-- P2 (一部分割詳細化済み) | |-- P2-1 | |-- P2-2 | ... `-- P3 (未分割詳細化)
ツリーになるのだけれどどうするのが良いかなあという話になりました。大きな視点だと分割元もわかるようにしておきたいし、途中までしか分割されていないものはまだ残りがあることを忘れないようにしたい。
分割し残りがあるものは「残り」としてフラットにしてしまえばいいんじゃないということになりました。「残りプロダクトバックログアイテム」を作ればフラットなリストにしても漏れないよねと。
|-- P1-1 |-- P1-2 |-- P1-3 |-- P2-1 |-- P2-2 |-- P2-残り `-- P3
[ スクラム ]
Remember The Milk で予測時間を入力するための時間計測をするのに Task Coach を久しぶりに使ってみました。
Toggl を使えば Remember The Milk と連動してタイムトラッキングできるのですが、きっちり記録したい訳ではなくて繰り返しタスクの平均所要時間がわかればいいかなぐらいだったので、ローカルで実行できてデータ管理手間なしの Task Coach を使おうかなと。ただやはりタスクの入力が面倒。すぐ飽きました。 Task Coach でタスク管理自体をしているのでなければ無理。
普通にストップウォッチで時間を測って Remember The Milk タスクのノートにメモするぐらいで十分そう。
Jurgen Appelo 氏の Management 3.0 では「権限の7つのレベル(The Seven Levels of Authority)」として以下を挙げています。
権限が委任/移譲されているレベルが高いほど数字が大きくなります。委任/移譲が段階的であることなどを学ぶデリゲーションポーカーではこの7レベルを使ったり、デリゲーションボードでこの7レベルで共有したりします。
訳語は人によっていろいろあるようです。
http://qiita.com/harakachi/items/d75461402815d76b12c5
http://nuworks.jp/ja/2016/12/09/deligationpoker/
http://www.ryuzee.com/contents/blog/3669
今読んでいるエッセンシャル スクラムでも「7段階の権限」として取り上げられていて以下の訳語があてられています。
好みの範疇なのでどれでも良いといえば良いのですが、単語によって自分の感覚だとこの組み合わせかなというのを考えてみました。
こんな語感かなと。実際にチームで使う時は harakachi 氏が挙げている 1. にしようかなと思っています。
昨年10月にサインアップした Medium、何か書くのに良さそうなプラットフォームだとは思っているのですがまだ活用できてません。
Ulysses や iA Writer から直接下書きを投稿できるので、うまく使えないかとちょっと試してみました。しかし結局下書きを投稿できるに過ぎないんですよね。まあ Medium 側がポスト(ストーリー)について POST しか API を提供していないので仕方がない訳ですけれども。
Ulysses や iA Writer で Markdown 形式で書いて一度 Medium に上げた下書き(やそれを公開したもの)について、再度手元で修正して反映させることができません。
一度 Medium に送ってしまったら、あとは「手元の原稿と Medium 上の記事を同じように手で修正する」か「再度 Medium に新しい草稿として上げて Medium 上でまるっとコピー&ペーストする」とかしかないです。残念。
永続的に残しておくほどではないちょっとしたノートを置いておくスペースとして nNote を始めることにしました。
nDiki と同じく自作の DiKicker を使用しています。
Medium であったり note であったりその他の Blog サービスであったりと「何か」を書いて公開しておけるサービスを触ってみるたびに「この nDiki とは別に書くとしたら何だろう? 何を書きたいんだろう?」と考えを巡らせていました。
この nDiki は長く続けてきた中で
といった縛りが自分の中にできてきているので、もっと自由なスペースが自分は欲しいのではと思えてきました。
そういったノートを書き留めておく場所が欲しいんだなと。
そのためのサービス・プラットフォームで何がいいかと考えると、やはりテキストファイルでさっと新規作成・再編集をしてサーバに同期して公開・更新できるものがいいなぁという結論に至って、結局欲しいと思って自作して使っているこれ (DiKicker) じゃないですかと。日付有りノート中心になってしまいますが、まあいいかなと。
ということでさくっと設定だけ増やして nNote を立てるに至りました。
[ ノート・日記はテキストファイルに ]
去年の秋から何チームとかスクラムチームとして開発をするようになったこともあって「プロセス」に意識を割く割合が多い日がここしばらく続いていました。
ちょっと形になってきてプロセスの方の検査と適応はまわるようになってきたので、2月から、といわずこれからしばらくはよりプロダクトの方に意識を向けていくことにします。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。
スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。
ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。
マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。
チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。
本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。
チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。
後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。