More Related Content
Viewers also liked
Viewers also liked (20)
More from Shin Semiya
Recently uploaded
Recently uploaded (7)
Exercise Backlog 1
- 1. バックログの話 前編
- 2. まずは自己紹介
- 3. あんただれ
- 5. こんにちは
- 7. マネジメントの話
- 8. 詰将棋やるよ
- 9. 将棋知っている人 挙手！
- 10. どう動かす？
- 11. これ盤ね
- 12. ちょっと変えるよ
- 13. 三手詰めね
- 14. これだと？
- 15. ヒント：初手は馬
- 16. 初手はこれ
- 17. おや？
- 18. バラバラだった 意見が一つに
- 19. ほとんど指示なしで
- 20. とりあえず解けた
- 22. これだけ
- 23. 問題が変わっても できるでしょう
- 26. 仕事って打合せ 多いよね
- 27. みんな打合せが 好きなの？
- 30. なぜできる？
- 31. コンテクストの共有
- 33. 前提の共有
- 34. 「常に王手」 「n手で詰ませる」
- 35. 目的の共有
- 36. 「玉を詰めろ」
- 37. 情報の共有
- 38. 盤面の明示
- 40. これが 成り立た ない場合
- 41. コンテクストの共有 の不成立
- 42. 将棋を知らない 人間には無理
- 43. 前提の共有 の不成立
- 44. 王手にならない ３手で詰まない
- 45. 目的の共有 の不成立
- 46. 詰将棋を知らないと わからない
- 47. 情報の共有 の不成立
- 48. 盤面見ずに 解けない
- 50. つまり
- 53. これを分割
- 55. 従来だと (主に90年代)
- 62. MVPキャンパス 作らないと
- 63. 迷う 止まる 迷走する
- 64. 会議を何回も 開催する羽目になる
- 65. 作るのは大変？
- 66. 必要なコスト
- 67. そもそも
- 68. 初めてやる作業って
- 69. 時間がかかる ものじゃないの？
- 70. 時間はかかる
- 71. MVPキャンパスは 遊びじゃない
- 75. 今明かされる真実
- 76. バックログは
- 77. ２つある
- 79. 用途の違い 具体度の違い
- 81. フォーマット
- 84. フォーマット
- 87. なぜ２つある？
- 88. UX品質を高く 保てるから
- 89. 変化に強いから
- 96. ところが
- 98. 具体化しないと？
- 100. 作業サイズが 大きくなる 開発速度の低下
- 101. 作業がブレる 作業の一貫性の低下
- 102. 各人が好き勝手にやる 作業の集中性の低下
- 103. つまり
- 104. 実装には具体化が必要
- 105. ユーザー要望 と システム実装
- 106. 背反する
- 110. 食材のメタファ
- 111. 食材の保存
- 112. 食材の保存
- 113. 保存は大きい単位で 行う
- 114. 食べるには一口大 まで小さく切る
- 115. このまま食べる？
- 116. 小さく切ると 食べる用途が決まる
- 117. すき焼き？ カレー？ ステーキ？
- 119. 保管は大きいサイズ
- 120. 調理の寸前に 小さいサイズに 切り分ける
- 122. タスクが大きいと
- 124. タスクが小さいと
- 125. 細かすぎて 管理するコストが 大きいし
- 126. あとから 実装手段を 変更できない
- 127. 切り分けるのは 調理の寸前
- 130. プロダクトバックログ
- 131. UX品質が高い
- 132. それはわかる ユーザー目線 だからね
- 134. んん？
- 135. 変化に強い？
- 136. ユーザー目線 イコール 変化に強い
- 137. どういうこと・・・
- 139. そこでこちら
- 144. 手段はどうでもいい
- 145. 手段は変化しやすい
- 146. 状況は変化するから
- 147. 真実は次々に 明らかになるから
- 149. 目的は変化しづらい
- 152. それじゃあ
- 153. 従来の形は
- 154. なぜ変化に弱い？
- 155. なぜUX品質が 悪化する？
- 157. なぜ変化に弱い？
- 158. 従来のかたち (20世紀型)
- 159. タスク リスト
- 161. 手段しか書いていない
- 162. フォーマット
- 165. 目的が暗黙的
- 166. 誰がなんのために つかうの？
- 168. ユーザー欲求は 比較しやすいが
- 169. 手段は比較しづらい
- 170. 優先度がつけづらい
- 171. 結果
- 172. 「優先度の低い 機能を削る」 ができない
- 174. また
- 175. チームは学習する
- 178. 状況が変化し
- 179. 陳腐化した 手段があっても
- 180. 代替手段の用意が 簡単ではない
- 181. 目的が暗黙的だから
- 182. 手段を変えると
- 183. 抜け漏れが 簡単に発生する
- 184. 結果
- 185. 変化が発生する イコール 死亡フラグ
- 187. なぜUX品質＝悪化？
- 189. 従来の形は
- 190. なぜUX品質が 悪化する？
- 191. 従来のかたち (20世紀型)
- 192. タスク リスト
- 193. フォーマット
- 196. 目的が暗黙的
- 197. 誰がなんのために つかうの？
- 198. 実装者によって ブレる
- 199. むしろ実装が 目的化する
- 200. UXが悪化しがち
- 201. 納得感のある UXの検証ができない
- 202. UXの品質保証が困難
- 204. ちょっと 想像してほしい
- 205. 「xx日までに この機能実装して」
- 206. 実装する
- 207. 提出
- 209. ハァ？
- 213. むしろ
- 214. このケースはまだマシ
- 215. レビュワー複数は 地獄
- 216. 基準が暗黙的だから
- 217. レビュワーごとに UX品質がブレる
- 219. さらに
- 221. 結果
- 222. 明示的な納期や工数の ほうが重視される
- 223. これが
- 224. つかいづらい システムができる理由
- 226. 他にも主語が常に
- 228. 開発チーム
- 229. この画面はどんな ユーザーが使うの？
- 230. というのが
- 231. 明示的ではない
- 232. 迷子になりやすい UIを作りやすい
- 234. ふーん
- 236. つまり
- 237. TODOリストを捨てて
- 238. バックログに すればいいんだろ？
- 239. 開発速度が遅い 打合せが多い
- 240. ユーザーに受けない 変化に弱い
- 241. これで全部解決
- 242. 以上終わり