nDiki : ワークフロー

自然に計画するためのモデル(GTD) と High-Performance OS

GTD では、収集バケツからのワークフローが有名である。 しかしあまり取り上げられることが少ないのだが、かなり重要だとここ最近思っているのが「自然に計画するためのモデル」である。このモデルでは、次の順に頭を動かしていく。

1. 目的と原則を定義する
2. 結果を思い描く
3. ブレーンストーミングする
4. 整理する
5. 次の行動を明らかにする

(仕事を成し遂げる技術 p.85)

ついとりがちなのは「反応型の計画モデル(不自然な計画モデル)」で、目先の行動で行き詰まって手遅れながら逆順にステップをあがっていくというものである。

GTD というと細かい「次の行動」をガンガン進めていくという印象があるが、それらの行動は(意識的に、あるいは無意識的に)目標からブレークダウンされたものでなければならない。

High-Performance OS

「自然に計画するためのモデル」はハワード・ゴールドマンの High-Performance OS に通じるところがある。 High-Performance OS でも

1. ビジョン
2. 戦略的フォーカス
3. 何をするか? (what)
4. どうやってするか(how)

というように、目的・目標から始める。 重要。

日常ではどうか?

大きなミッションでは、まず計画フェーズでこれらを熟考する(マズイ、何となくでいってしまうことも多々アリ)。

しかし比較的小さな規模の(GTD でいうところの)プロジェクトは、つい反応的に行動をとってしまいがちである。 依頼のままのアクション・思いついたアクション・やりやすいアクション・面白そうなアクションから手をつけて、結果的に忙しい割にはあまり成果が出ていないこともしばしばだ。

もっとゴールを見据えて効果的に行動していきたいところである。

• 仕事を成し遂げる技術--ストレスなく生産性を発揮する方法
• すごい考え方

今日のさえずり: まあ、いわゆる管理は少なければ少ない方がいいわけですが

2011年09月14日

• 08:46 最近 Google+ からちょっと足が遠のきがちだな。なんだろな。 http://t.co/08raKgY #mixipage
• 09:19 事足りない部分は機能・人・アクティビティ? 何でしょうね。 RT @yuji0602: Twitterで充分事足りてるからじゃないっすかね～。 RT @Naney: 最近 Google+ からちょっと足が遠のきがちだな。なんだろな。
• 09:22 かなり個人的な部分では、フローだけでなくストックでもなければ嫌というのがある。 http://t.co/Z0b2CyG #mixipage
• 09:24 これを満たすのが Twitter(+ API + なにか)しかない。 http://t.co/I96ADeR #mixipage
• 09:26 リッチだったり、構造化されてたりすると、ストック的にシンプルじゃなくなる(面倒)。 http://t.co/TulrGut #mixipage
• 09:48 確かに「Tumblr 的*情報*」が多いというのもありますね。 RT @yasa_gurek0: あそこで流れている情報は別にG+じゃなく他で補充できるからですかね？ RT: @Naney 最近 Google+ からちょっと足が遠のきがちだな。なんだろな。
• 13:10 塩牛丼 400円。 (@ 神戸 らんぷ亭 渋谷並木橋店) http://t.co/N8KWqIT
• 13:14 管理のための管理が好きとか秘密。まあ、いわゆる管理は少なければ少ない方がいいわけですが。
• 13:17 いわゆるチェック的管理じゃなくて、ものごとを決めて前進させていくのが大切。
• 13:39 I'm at 金王八幡宮 (渋谷3-5-12, 渋谷) http://t.co/4vc0xHj
• 13:39 特別奉納「渋谷伝説・金王丸」 http://t.co/N8GHGUb
• 13:50 今日から始まって数日間いろいろあるようです。 RT @i47_rozary: 見たかったです…。 RT @Naney: 特別奉納「渋谷伝説・金王丸」 http://t.co/N8GHGUb
• 20:12 今日は IRC 追えてなかったので、今からチェック。
• 20:34 退勤。21時まで正面玄関開けておいてくれると嬉しいんだけどな。
• 20:47 のど風邪流行っているので、うがい薬強化週間にしよう。オフィスに置いてあるマイウガイカップ初投入だな。
• 21:00 BTS/ITS/ワークフローシステムには「無かったことにする」ボタンがあればいいのに。そして押すと足元の扉がパカッと開く。
• 23:46 指定した条件で Twitter リストを更新し続けてくれる Formulists 試してみてる。前からこういうの欲しかった。 http://t.co/lsCvqfj
• 23:49 Formulists で tweetmates という自動更新リスト作ってみた。 http://t.co/lsCvqfj

今日のさえずり: そういえば最近「ユビキタスキャプチャ」ってワード見かけないな

2013年11月27日

• 07:35 今年のスターバックスのレッドカップオーナメント。 http://flic.kr/p/hSDGuw
• 08:57 「お台場レインボー花火」 / “レインボーブリッジが虹色にライトアップ、週末に「レインボー花火」打ち上げも - 東京ベイ経済新聞” http://bit.ly/IrvpGA
• 08:57 「チームポリシーとしてのリベースは、クリーンアップとしてのリベースとは異なります。」「重視するのは、クリーンでリニアな履歴ですか? それとも、ブランチのトレーサビリティでしょうか?」 / “Git チームワークフロー: マー...” http://bit.ly/Irvt9f
• 09:11 10:00 からの焼きいも会、結構気にはなっている。
• 09:28 そういえば最近「ユビキタスキャプチャ」ってワード見かけないな。
• 09:46 渋谷で焼き芋。 http://flic.kr/p/hSMFra
• 09:47 焼きいも会。 (@ 金王八幡宮) http://4sq.com/1a24urq
• 11:58 初ピクニック。ちょっと高い。 (@ picnic 青山店) http://4sq.com/1a2op9D
• 21:06 AGFボトルコーヒーとか都市伝説か(どこも扱っていない)。

「なぜ Excel 方眼仕様書だと駄目なのですか?」

先週ワークフロー改善内容についてレビューしたところ添付されていた仕様書フォーマットサンプルが Excel 方眼紙だったので、これを機会に止めましょうとお願いしておきました。 そうしたところ今日になってツッコミをいれた人と同じグループの別の人から「なぜ Excel 方眼仕様書だと駄目なのですか?」と質問されました。即答するとなんか適当なことを言ってしまいそうなのであとで回答しますねと答えておきました。

Excel 方眼仕様書をもらった時の嫌だなという感情は「ファイルでの管理だから」「Excel だから」「方眼スプレッドシートだから」など複数の混ざり合った理由からやってきます。

この中で「ファイルでの管理だから」「Excel だから」は環境によっては排除できない場合もあるし、ユースケースにあっている場合もあるので単純に良い悪いとはいえません。

しかしながら「方眼スプレッドシート」で書かれた仕様書というのはいつでも不便なので止めて欲しいです。書かれている文章の部分が論理的な入力になっていないのが一番嫌な点です。1文毎に別のセルに書くとか、字下げは次の列のセルからとか、箇条書き項目ごとに次の行のセルとか。仕様レビューや仕様変更での更新が非常にやりにくい。説明を書き足しにくい。

だからといってシート毎に大きな図形を貼ってその中にテキストを書けば良いといったものでもありません。それこそ方眼にする理由はないでしょう。

編集を阻む仕様書は、仕様の品質を上げるコストを高くするのです。

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会5回目。今日は第5章 要件とユーザーストーリー。

「5.3 改良し続ける」では要件の詳細化について書かれています。

いつかやるかもしれない(やらないかもしれない)要件よりも、すぐに取りかかろうとしている要件のほうが小さくて詳細化されている。必要になったときにジャストインタイムで、詳細化されていない大きな要件を小さくて詳細化された要件の集まりにするのだ。

必要な範囲で要件の詳細度を上げていくということを明確にしているのがスクラムらしいですね。ただ直近取りかかるものばかり意識していると、破棄する要件は減るかもしれないですが作ったものを捨てる(か、そうでなくても変更しなければならなくなる)こともありえるので、そのあたりの絶妙なさじ加減が必要でしょう。

このあたりが「5.5 詳細化レベル」での「ユーザーストーリーの抽象化階層」の話でフォローされている感じです。

ユーザーストーリーの作り方としては「5.9 ストーリーの収集」で「ストーリーマッピング」というテクニックが説明されています。

抽象的なユーザーの行為を、詳細タスクによって組み立てられるワークフローに分解する、というものだ。

ストーリーを時系列と優先順位の2軸で作っていくというやり方でなかなか良さそうでした。ひとまとまりのサービス/機能を作る時は試してみたいです。

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

Alfred から一発で日時ファイル名のファイルを新規作成し Ulysses で開けるようにする

Mac ではもっぱらライティングアプリ Ulysses でノートをとっています。さっとメモをする時はあとで整理しやすいように日時がファイル名になっているファイル(シート)をぱっと新規作成して開きたいなと思っていたので方法を調べてみました。

x-callback-url が使える

Ulysses の Mac アプリケーションでも iOS アプリと同様に x-callback-url に対応しているようなのでこれを使うことにしました。

• https://ulyssesapp.com/kb/x-callback-url/

ターミナルで

 open ulysses://x-callback-url/new-sheet?group=/home/workspace/note\&index=1000\&text=`date +@:%Y-%m-%d-%H%M%S`

とすると外部フォルダ home の中の workspace/note の中に今の日時に合わせて 2017-08-24-130102.md のようなファイルが作成され、 Ulysses がアクティブになりそのシートが開いた状態になります。便利。

ちなみに Ulysses の外部フォルダ上のシートを新規作成して開くなら、同様の日時ファイル名のテキストファイルを作成し

 open -a UlyssesMac ファイル名

で開くようなスクリプトを書くのでも OK です。

Alfred から呼べるようにする

動作することがわかったので Alfred 3 for Mac から呼び出せるようにしました。

• https://www.alfredapp.com/

今日 Alfred を初めて入れてみたので workflow などの機能については良くわかっていません。まずは先のコマンド実行をアプリケーションにして Alfred から呼日出せるようにします。

アプリケーションを作る

1. Automator を起動
2. 新規ワークフローを作成
3. 「シェルスクリプト実行」アクションを右のペインにドラッグ&ドロップ
4. シェルスクリプトとして前述の1行コマンドを入力
5. 右上の実行ボタンを押して動作することを確認
6. フォーマットに「アプリケーション」選択し ~/local/Applications/new-note.app として保存(Alfred の初期設定ではホームディレクトリ以下ならどこでも OK)

これで option + shift で Alfred を表示したあとに new-note と入れて実行するれば、新しい日時ファイル名のファイルが作成されて Ulysses 上でシートが開いた状態になります。

これで Ulysses でさっとメモを取るのが一気に楽になりました。

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

ワークフローを作る時は「誰が」「いつまでに」「なにをするか」を明確にする

「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットしよう/リクエストしよう。

というのを自分の行動原則の1つにしています(完全に守れているわけではないのですけれども)。

今日、サービスの不具合管理のワークフローの見直しをチームでしていて、原案が気持ち悪いなと思ったのは「誰が」が不明確だったからでした。「気がついた人が」や「◯◯が役割の人が」は絶対誰もやらないケースが出てきます。思い切って個人に割り当てる(そして無理だった場合はエスカレーションする)ルールの方がきちんと仕事がまわります。

[ opinion ]