AGFボトルコーヒーとか都市伝説か(どこも扱っていない)。方眼紙だったので、これを機会に止めましょうとお願いしておきました。方眼仕様書だと駄目なのですか?」と質問されました。即答するとなんか適当なことを言ってしまいそうなのであとで回答しますねと答えておきました。」「方眼スプレッドシートだから」など複数の混ざり合った理由からやってきます。」は環境によっては排除できない場合もあるし、ユースケースにあっている場合もあるので単純に良い悪いとはいえません。「方眼スプレッドシート」で書かれた仕様書というのはいつでも不便なので止めて欲しいです。書かれている文章の部分が論理的な入力になっていないのが一番嫌な点です。1文毎に別のセルに書くとか、字下げは次の列のセルからとか、箇条書き項目ごとに次の行のセルとか。仕様レビューや仕様変更での更新が非常にやりにくい。説明を書き足しにくい。いってシート毎に大きな図形を貼ってその中にテキストを書けば良いといったものでもありません。それこそ方眼にする理由はないでしょう。編集を阻む仕様書は、仕様の品質を上げるコストを高くするのです。スクラム」を読みたい人が集まる勉強会5回目。要件とユーザーストーリー。改良し続ける」では要件の詳細化について書かれています。いつかやるかもしれない(やらないかもしれない)要件よりも、すぐに取りかかろうとしている要件のほうが小さくて詳細化されている。必要になったときにジャストインタイムで、詳細化されていない大きな要件を小さくて詳細化された要件の集まりにするのだ。必要な範囲で要件の詳細度を上げていくということを明確にしているのがスクラムらしいですね。直近取りかかるものばかり意識していると、破棄する要件は減るかもしれないですが作ったものを捨てる(か、そうでなくても変更しなければならなくなる)こともありえるので、そのあたりの絶妙なさじ加減が必要でしょう。詳細化レベル」での「ユーザーストーリーの抽象化階層」の話でフォローされている感じです。ストーリーの収集」で「ストーリーマッピング」というテクニックが説明されています。抽象的なユーザーの行為を、詳細タスクによって組み立てられるワークフローに分解する、というものだ。ストーリーを時系列と優先順位の2軸で作っていくというやり方でなかなか良さそうでした。ひとまとまりのサービス/機能を作る時は試してみたいです。ノートをとっています。メモをする時はあとで整理しやすいように日時がファイル名になっているファイル(シート)をぱっと新規作成して開きたいなと思っていたので方法を調べてみました。対応しているようなのでこれを使うことにしました。アクティブになりそのシートが開いた状態になります。