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 ]

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。