nDiki : 2017年01月下旬

Google Keep 利用完了 (テキストファイルに移行)

ここ最近テキストファイルでのノート環境が整ってきて、どこでも直接 Dropbox 上のファイルにメモする事ができるようになってきました。

直接テキストファイルに書いた方が後の整理が楽なのでここ最近 Google Keep を使わないで済ませるようにしていたのですが特に困ることはありませんでした。

もういいかなということで Google Keep に残っていたメモを全部テキストファイルに移しきり、Google Keep アプリ Xperia Z5 からアンインストール。ツールが一つ減ってすこし身軽になりました。

[ ノート・日記はテキストファイルに ]

今日のさえずり:

2017年01月21日

• 11:28 HDリマスター版 新世紀エヴァンゲリオン 第伍話・第六話観たー。
• 17:37 抜けていく人には抜けていく人の言い分がある。
• 21:43 Google Keep にあったメモをプレーンテキストファイルに移したので Xperia Z5 から Google Keep アプリをアンインストール。

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

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

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

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

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

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

今日のさえずり: お年玉付郵便はがき全滅

2017年01月22日

• 16:10 お年玉付郵便はがき全滅。
• 16:40 「年賀状は新PIXUS キャッシュバック キャンペーン」申し込みクエスト完了した。ハードだった。
• 22:16 やはり iOS 版 Ulysses は1万ファイルある Dropbox フォルダを外部フォルダに追加すると厳しい感じ。

「自分が良さそうだと思った映画を観る。みんなが観ている映画は観ない。」

自分が良さそうだと思った映画を観る。みんなが観ている映画は観ない。

前半はまあまあだ思います。出会えなかったものに出会う可能性を失ってはいますけれど。後半は残念な感じです。

今日のさえずり: 「そろばん」といえば「トモエのそろばん〜」と刷り込まれている。恐ろしい。

2017年01月23日

• 08:00 「そろばん」といえば「トモエのそろばん〜」と刷り込まれている。恐ろしい。
• 19:53 「今すぐ使える、春の最新作。」とかいらないの。冬物が欲しいの。
• 21:00 「ごめんください」使いこなしたい。
• 23:30 @yoshimot0 @YouTube もちょっと品の良い感じの。
• 23:51 久しぶりに Hootsuite にログインしてみた。なにか古臭い雰囲気。

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会12回目。今日は第12章 スクラムチームの構成。

今回の内容は主にスクラムチームメンバより上のレイヤーの人たち向けの内容です。

複数のスクラムチームによる共同作業が必要だと、いつかは思い知ることになるのだ。

ということで複数のスクラムチームの話。前半はフィーチャーチームとコンポーネントチームについて。本書ではフィーチャーチーム推しで、コンポーネントチーム構成からフィーチャーチーム構成へ徐々に移行する場合の体制の案を示しています。

フィーチャーチームかコンポーネントチームかという問題を解決する万能のソリューションはない。

ということで、ここはプロダクトと組織にいるメンバの状況に合わせて考えていくしかない感じです。

本章でも「同時に開発を進めるプロダクトの数を減らす」という話が出てきていろいろ考えさせられます。

スクラムオブスクラムについては、定期開催で開かれるのは良いとして現実的にはアドホックにどんどん相談していっちゃう方が早いんじゃないかなと感じました。

リリーストレインについてはかなり大規模なプロダクトが想定でしょうか。「スクラムのためのアクティビティで時間が奪われすぎないか」「末端のスクラムチームでは適応できる余地が少なくなってしまうのでは」などという疑問が湧きました。

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

今日のさえずり: まさか不思議惑星キン・ザ・ザがブルーレイディスクで出るとは

• 13:03 今日はタイミングが良かったので買いにきた。 (@ essen) https://www.swarmapp.com/c/5HklTi9S7eT
• 21:01 まさか不思議惑星キン・ザ・ザがブルーレイディスクで出るとは。 http://amzn.to/2jjvsu0
• 21:02 「自分が良さそうだと思った映画を観る。みんなが観ている映画は観ない。」 http://bit.ly/2jLGjM2
• 21:25 プロダクトバックログアイテムの分割、「CAR と CDR に分ければいいよね」という話になってちょっとすっきりした。

プロダクトバックログを分割詳細化した時にエピックを「残り」で残す

スクラムのプロダクトバックログリファインメントの時に、上位のプロダクトバックログはスプリントで完成させられるように分割詳細化していきます。

 |-- 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

[ スクラム ]

久しぶりにタイムトラッキングに Task Coach を使ったけれどすぐ飽きた

Remember The Milk で予測時間を入力するための時間計測をするのに Task Coach を久しぶりに使ってみました。

Toggl を使えば Remember The Milk と連動してタイムトラッキングできるのですが、きっちり記録したい訳ではなくて繰り返しタスクの平均所要時間がわかればいいかなぐらいだったので、ローカルで実行できてデータ管理手間なしの Task Coach を使おうかなと。ただやはりタスクの入力が面倒。すぐ飽きました。 Task Coach でタスク管理自体をしているのでなければ無理。

普通にストップウォッチで時間を測って Remember The Milk タスクのノートにメモするぐらいで十分そう。

今日のさえずり: Remember The Milk ならやはり Toggl なのかな

• 23:02 Task Coach を久しぶりにインストールして使ってみたけれど入力が面倒ですぐ飽きそう。 Remember The Milk ならやはり Toggl なのかな。

「権限の7つのレベル」の訳語

Jurgen Appelo 氏の Management 3.0 では「権限の7つのレベル(The Seven Levels of Authority)」として以下を挙げています。

1. Tell
2. Sell
3. Consult
4. Agree
5. Advise
6. Inquire
7. Delegate

権限が委任/移譲されているレベルが高いほど数字が大きくなります。委任/移譲が段階的であることなどを学ぶデリゲーションポーカーではこの7レベルを使ったり、デリゲーションボードでこの7レベルで共有したりします。

訳語は人によっていろいろあるようです。

1. harakachi 氏・NuWorks合同会社の場合

http://qiita.com/harakachi/items/d75461402815d76b12c5

http://nuworks.jp/ja/2016/12/09/deligationpoker/

1. 命令する(私が彼らに決定を伝える)
2. 説得する(私が彼らに売り込む)
3. 相談する(彼らに相談し私が決める)
4. 同意する(私と彼らが合意して決める)
5. 助言する(私は助言するが彼らが決める)
6. 尋ねる(彼らが決めた後で私が尋ねる)
7. 委任する(私は彼らに完全に委ねる)

2. Ryuzee.com の場合

http://www.ryuzee.com/contents/blog/3669

1. 指示する: 管理者として意思決定を行う
2. 売り込む: 意思決定についての人々を納得させる
3. 相談する: 決定する前に、チームからの意見を得る
4. 同意する: チームと一緒に決定を下す　
5. アドバイスする: チームによる意思決定に影響を及ぼす
6. 問い合わせる: チームの決定後のフィードバックを求める
7. 移譲する: 特に影響を及ぼさずチームに任せる

3. エッセンシャル スクラムの場合

今読んでいるエッセンシャル スクラムでも「7段階の権限」として取り上げられていて以下の訳語があてられています。

1. 通知
2. 説得
3. 相談
4. 合意
5. 助言
6. 確認
7. 移譲

しっくりきそうなもの

好みの範疇なのでどれでも良いといえば良いのですが、単語によって自分の感覚だとこの組み合わせかなというのを考えてみました。

1. 指示する
2. 説得する
3. 相談する
4. 合意する
5. 助言する
6. 確認する
7. 移譲する

こんな語感かなと。実際にチームで使う時は harakachi 氏が挙げている 1. にしようかなと思っています。

今日のさえずり: メンバ側からデリゲーションポーカーやりましょうかって言える間柄、良好だと思う

2017年01月27日

• 09:46 ストップウオッチが欲しい。100円ショップかな。
• 20:56 Tell, Sell, Consult, Agree, Advise, Inquire, Delegate
• 21:21 highest minority はポイントをもらえないゲーム。
• 21:41 メンバ側からデリゲーションポーカーやりましょうかって言える間柄、良好だと思う。

サードパーティーアプリからは Medium のストーリーはポストしかできない

昨年10月にサインアップした Medium、何か書くのに良さそうなプラットフォームだとは思っているのですがまだ活用できてません。

Ulysses や iA Writer から直接下書きを投稿できるので、うまく使えないかとちょっと試してみました。しかし結局下書きを投稿できるに過ぎないんですよね。まあ Medium 側がポスト(ストーリー)について POST しか API を提供していないので仕方がない訳ですけれども。

Ulysses や iA Writer で Markdown 形式で書いて一度 Medium に上げた下書き(やそれを公開したもの)について、再度手元で修正して反映させることができません。

一度 Medium に送ってしまったら、あとは「手元の原稿と Medium 上の記事を同じように手で修正する」か「再度 Medium に新しい草稿として上げて Medium 上でまるっとコピー&ペーストする」とかしかないです。残念。

• https://medium.com/@Naney

今日のさえずり: ジャバ始めました

2017年01月28日

• 10:25 ジャバ始めました。

nNote 始めました

永続的に残しておくほどではないちょっとしたノートを置いておくスペースとして nNote を始めることにしました。

• https://www.naney.org/note

nDiki と同じく自作の DiKicker を使用しています。

Medium であったり note であったりその他の Blog サービスであったりと「何か」を書いて公開しておけるサービスを触ってみるたびに「この nDiki とは別に書くとしたら何だろう? 何を書きたいんだろう?」と考えを巡らせていました。

この nDiki は長く続けてきた中で

• 永続的に残すことを前提にきちんとした URL (記事 ID) にする。
• 誤読されないように、ある程度自分なりに推敲する。
• AutomaticLink のために正確な用語で書く。
• フィードが拾われて消費されることを前提に、きちんと書けてから公開する。

といった縛りが自分の中にできてきているので、もっと自由なスペースが自分は欲しいのではと思えてきました。

• 必要が無くなったら 404 を恐れずさくっと消して良い。
• まだ自分としてこうだという結論に至っていない考えだったり何かの断片だったりを書いて良い。
• 最初から用語の正確性を追わなくて良い。
• 頻繁に更新して良い。

そういったノートを書き留めておく場所が欲しいんだなと。

そのためのサービス・プラットフォームで何がいいかと考えると、やはりテキストファイルでさっと新規作成・再編集をしてサーバに同期して公開・更新できるものがいいなぁという結論に至って、結局欲しいと思って自作して使っているこれ (DiKicker) じゃないですかと。日付有りノート中心になってしまいますが、まあいいかなと。

ということでさくっと設定だけ増やして nNote を立てるに至りました。

[ ノート・日記はテキストファイルに ]

これからしばらくは「プロセスではなくプロダクト」

去年の秋から何チームとかスクラムチームとして開発をするようになったこともあって「プロセス」に意識を割く割合が多い日がここしばらく続いていました。

ちょっと形になってきてプロセスの方の検査と適応はまわるようになってきたので、2月から、といわずこれからしばらくはよりプロダクトの方に意識を向けていくことにします。

今日のさえずり: デリゲーションポーカーも良さそうですがインディアンポーカーも良いものです

2017年01月30日

• 13:16 日差しが暖か。 (@ クーポール 島根イン青山店 in 港区, 東京都) https://www.swarmapp.com/c/e33X6TRJx4s
• 13:59 ショップは関係者のみとのこと。 (@ 日本コカ・コーラ 株式会社 本社 in 渋谷区, 東京都) https://www.swarmapp.com/c/gRJ5xzTyRL1
• 16:24 デリゲーションポーカーも良さそうですがインディアンポーカーも良いものです。
• 17:42 朝会/デイリースクラムはやはり「各メンバ」が順に「やったこと」「やること」「困っていること」を話すのがいいな。誰かがタスクをチェックして質問していくのではなくて。

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。

スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。

ファンクショナルマネージャー

ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。

• チームを編成する
• チームを育てる
• 環境を合わせてなじませる
• 価値創造の流れを作る

マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。

チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。

本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。

チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。

プロジェクトマネージャー

後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。

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