GTD では、収集バケツからのワークフローが有名である。 しかしあまり取り上げられることが少ないのだが、かなり重要だとここ最近思っているのが「自然に計画するためのモデル」である。このモデルでは、次の順に頭を動かしていく。
(仕事を成し遂げる技術 p.85)
ついとりがちなのは「反応型の計画モデル(不自然な計画モデル)」で、目先の行動で行き詰まって手遅れながら逆順にステップをあがっていくというものである。
GTD というと細かい「次の行動」をガンガン進めていくという印象があるが、それらの行動は(意識的に、あるいは無意識的に)目標からブレークダウンされたものでなければならない。
「自然に計画するためのモデル」はハワード・ゴールドマンの High-Performance OS に通じるところがある。 High-Performance OS でも
というように、目的・目標から始める。 重要。
大きなミッションでは、まず計画フェーズでこれらを熟考する(マズイ、何となくでいってしまうことも多々アリ)。
しかし比較的小さな規模の(GTD でいうところの)プロジェクトは、つい反応的に行動をとってしまいがちである。 依頼のままのアクション・思いついたアクション・やりやすいアクション・面白そうなアクションから手をつけて、結果的に忙しい割にはあまり成果が出ていないこともしばしばだ。
もっとゴールを見据えて効果的に行動していきたいところである。
先週ワークフロー改善内容についてレビューしたところ添付されていた仕様書フォーマットサンプルが Excel 方眼紙だったので、これを機会に止めましょうとお願いしておきました。 そうしたところ今日になってツッコミをいれた人と同じグループの別の人から「なぜ Excel 方眼仕様書だと駄目なのですか?」と質問されました。即答するとなんか適当なことを言ってしまいそうなのであとで回答しますねと答えておきました。
Excel 方眼仕様書をもらった時の嫌だなという感情は「ファイルでの管理だから」「Excel だから」「方眼スプレッドシートだから」など複数の混ざり合った理由からやってきます。
この中で「ファイルでの管理だから」「Excel だから」は環境によっては排除できない場合もあるし、ユースケースにあっている場合もあるので単純に良い悪いとはいえません。
しかしながら「方眼スプレッドシート」で書かれた仕様書というのはいつでも不便なので止めて欲しいです。書かれている文章の部分が論理的な入力になっていないのが一番嫌な点です。1文毎に別のセルに書くとか、字下げは次の列のセルからとか、箇条書き項目ごとに次の行のセルとか。仕様レビューや仕様変更での更新が非常にやりにくい。説明を書き足しにくい。
だからといってシート毎に大きな図形を貼ってその中にテキストを書けば良いといったものでもありません。それこそ方眼にする理由はないでしょう。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会5回目。今日は第5章 要件とユーザーストーリー。
「5.3 改良し続ける」では要件の詳細化について書かれています。
いつかやるかもしれない(やらないかもしれない)要件よりも、すぐに取りかかろうとしている要件のほうが小さくて詳細化されている。必要になったときにジャストインタイムで、詳細化されていない大きな要件を小さくて詳細化された要件の集まりにするのだ。
必要な範囲で要件の詳細度を上げていくということを明確にしているのがスクラムらしいですね。ただ直近取りかかるものばかり意識していると、破棄する要件は減るかもしれないですが作ったものを捨てる(か、そうでなくても変更しなければならなくなる)こともありえるので、そのあたりの絶妙なさじ加減が必要でしょう。
このあたりが「5.5 詳細化レベル」での「ユーザーストーリーの抽象化階層」の話でフォローされている感じです。
ユーザーストーリーの作り方としては「5.9 ストーリーの収集」で「ストーリーマッピング」というテクニックが説明されています。
抽象的なユーザーの行為を、詳細タスクによって組み立てられるワークフローに分解する、というものだ。
ストーリーを時系列と優先順位の2軸で作っていくというやり方でなかなか良さそうでした。ひとまとまりのサービス/機能を作る時は試してみたいです。
Mac ではもっぱらライティングアプリ Ulysses でノートをとっています。さっとメモをする時はあとで整理しやすいように日時がファイル名になっているファイル(シート)をぱっと新規作成して開きたいなと思っていたので方法を調べてみました。
Ulysses の Mac アプリケーションでも iOS アプリと同様に 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 3 for Mac から呼び出せるようにしました。
今日 Alfred を初めて入れてみたので workflow などの機能については良くわかっていません。まずは先のコマンド実行をアプリケーションにして Alfred から呼び出せるようにします。
これで option + shift で Alfred を表示したあとに new-note と入れて実行するれば、新しい日時ファイル名のファイルが作成されて Ulysses 上でシートが開いた状態になります。
これで Ulysses でさっとメモを取るのが一気に楽になりました。
[ ノート・日記はテキストファイルに ]
「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットしよう/リクエストしよう。
というのを自分の行動原則の1つにしています(完全に守れているわけではないのですけれども)。
今日、サービスの不具合管理のワークフローの見直しをチームでしていて、原案が気持ち悪いなと思ったのは「誰が」が不明確だったからでした。「気がついた人が」や「◯◯が役割の人が」は絶対誰もやらないケースが出てきます。思い切って個人に割り当てる(そして無理だった場合はエスカレーションする)ルールの方がきちんと仕事がまわります。
[ opinion ]
2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。
朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。
以下セッションタイトルは2月13日時点の公式サイトより。
株式会社アトラクタ 原田騎郎(@haradakiro)氏
やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。
*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7
GitHub 池田尚史(@ikeike443)氏
GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。
株式会社grasys 長谷川祐介氏
サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。
ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
前半永瀬氏による enPiT 事例紹介。
後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。
こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。
ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。
東工大生イジりが嫌味がないのも素敵。
株式会社コロプラ 廣本洋一氏
機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。
株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏
ECナビについて2年弱かけて AWS 移行した話。
サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。
別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。
株式会社ZOZOテクノロジーズ 塩崎健弘氏
BigQuery 移行事例についての、味わいのある発表。
今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。
高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏
技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。