適切な問題設定と小さくリリースするということ / release small

[質とスピードを追求する開発チームでの取り組み] の登壇資料です
https://drobe.connpass.com/event/292061/

# 参考資料
- https://speakerdeck.com/soudai/first-step-for-good-development
- https://speakerdeck.com/soudai/necessary-mindset-for-software-developers
- https://gist.github.com/voluntas/9c1d9d51e86a853fed6889f743a12145
- https://speakerdeck.com/soudai/developer-lifehack
- https://speakerdeck.com/soudai/release-safely
- https://speakerdeck.com/soudai/release-safely-2
- https://amzn.to/33QPAdv

Transcript

1. 適切な問題設定と 小さくリリースするということ 合同勉強会
2. 先に読んでおいてほしい
 
 
 What is it?
3. https://speakerdeck.com/soudai/first-step-for-good-development
4. https://speakerdeck.com/soudai/necessary-mindset-for-software-developers
5. “「いい質問だ。定義が『売上』となっているのは、必ず『納品』までを考慮しな ければならないためだよ。 仕掛品や完成品の在庫をどれだけ作っても、『納 品できなければマネジメントが成功したとは言えない』からね」
 確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫と は？この業界に在庫なんてありませんが？」
 私の言葉に、ジョナサンは悲しそうに首を振る。そして言った。
 「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだ ろう。ものづくりをしている業界で、納期遅れが起きている職場で、現場に在 庫が無いなどと考えるのは大きな誤りだ」
 「『在庫』とは、将来納品するために存在する、作りかけの未完成品や納品 前の完成品のことだ。 そのままでは納品できないもの、全てが在庫だ。
 例えばIT業界での『在庫』とは、『書きかけのコード』『未テストのコード』『別の コードの完成を待っているテスト済みのコード』 『完成していても顧客に納品 されていないコード』を指す。もちろん、『完成していても顧客に納品されてい ないドキュメント』も在庫だ」”
 https://gist.github.com/voluntas/9c1d9d51e86a853fed6889f743a12145
6. 我々は素早く価値を届けたい
 
 
 What is it?
7. 我々は素早く価値を届けたい
 ↓
 そのためには素早くリリースしたい
 What is it?
8. どうやって沢山リリースするか
 
 どうやって価値を素早く届けるか
 What is it?
9. 顧客に価値を届ける
 
 そのために必要な話をします
 What is it?
10. 1. 自己紹介
 2. 適切な問題設定とタスクへの分解
 3. 失敗できる仕組み
 4. 素早く、小さく、リリースする
 5. まとめ
 あじぇんだ
11. 1. 自己紹介
 2. 適切な問題設定とタスクへの分解
 3. 失敗できる仕組み
 4. 素早く、小さく、リリースする
 5. まとめ
 あじぇんだ
12. 自己紹介
 曽根 壮大（38歳）
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

13. 突然の宣伝
 
予防医療のリンケージ
 
 
 • リモートワークの不安を数値にするストレスチェック • 女性の健康課題をサポートする • リモートワーク、ちょっとした心配を相談できる安心をご提供 

14. 1. 自己紹介
 2. 適切な問題設定とタスクへの分解
 3. 失敗できる仕組み
 4. 素早く、小さく、リリースする
 5. まとめ
 あじぇんだ
15. 問題を解決するために
 
 解決手段としてリリースする
 適切な問題設定とタスクへの分解
16. 問題のサイズが大きさに比例して
 
 リリースのサイズも大きくなる
 適切な問題設定とタスクへの分解
17. 問題のサイズが大きさに比例して
 
 リリースのサイズも大きくなる
 適切な問題設定とタスクへの分解
18. 問題が大きくても
 
 リリースのサイズには関係ない
 適切な問題設定とタスクへの分解
19. 適切な問題設定とは？
 
 
 適切な問題設定とタスクへの分解
20. 適切な問題設定とは？
 ↓
 ユーザーストーリーにすべて書いてある
 適切な問題設定とタスクへの分解
21. • Why 
 ◦ そのタスクはなぜ必要なのか 
 • What
 ◦ そのタスクの実現したいことは成果物はないか 
 ◦ 完了の定義
 • When
 ◦ タスクの期限
 • Where
 ◦ ビジョンやゴールはどこか、どこで実行されるか 
 • Who 
 ◦ ステークホルダーは誰か、利用者は誰か 
 ◦ 例えば依頼者は誰か、レビューは誰にお願いするか、とか 
 • How
 ◦ どのように実現するか 
 ◦ 実装のための制約や方針なども含む 
 ユーザーストーリーに書いてあること
22. もし、チケットそのものが大きいなら
 
 チケットを見直す
 適切な問題設定とタスクへの分解
23. • 最も実現したいことにフォーカスする
 • 実現したい体験を複数の方法に置き換えてみる
 • 実現する場所、実装する場所を置き換えてみる
 • 体験を届けたいペルソナを絞る
 • 実装上の制約を減らす方法を検討する
 • 今、やるべきことか検討する
 ユーザーストーリーを見直す
24. つまりユーザーストーリーが
 
 適切か見直すこと
 適切な問題設定とタスクへの分解
25. 開発のリソースや実装速度は
 
 一朝一夕では早くはならない
 適切な問題設定とタスクへの分解
26. リリースするために調整するのは
 
 スコープ
 適切な問題設定とタスクへの分解
27. 適切なサイズな問題であれば
 
 タスクに分解できる
 適切な問題設定とタスクへの分解
28. 1つのチケットが
 
 1回のリリースに紐づく
 適切な問題設定とタスクへの分解
29. 1つのチケットが
 
 1回のリリースに紐づく
 適切な問題設定とタスクへの分解
30. 1つのチケットで
 
 何回リリースしてもよい
 適切な問題設定とタスクへの分解
31. リリースの単位が
 
 最小になるようにタスクを分解する
 適切な問題設定とタスクへの分解
32. https://speakerdeck.com/soudai/developer-lifehack
33. 解決したい問題にフォーカスして
 
 タスクを小さくすると自然と
 
 適切な問題設定のサイズになる
 適切な問題設定とタスクへの分解
34. 1. 自己紹介
 2. 適切な問題設定とタスクへの分解
 3. 失敗できる仕組み
 4. 素早く、小さく、リリースする
 5. まとめ
 あじぇんだ
35. 何度もリリースしたい
 
 なのになぜ、リリースまとめるのか
 失敗できる仕組み
36. 失敗したくない
 
 
 失敗できる仕組み
37. 失敗したくない
 ↓
 失敗のリスクがでかい
 失敗できる仕組み
38. • リリースのための準備が多いので1度で済ませたい
 ◦ QAやレビューなどの品質担保
 • リリースの影響範囲が広いでの1回で済ませたい
 ◦ リリースのテスト範囲が広い
 ◦ APIや画面の複雑度が高い
 • とにかくリリースが怖い
 リリースをまとめたくなる要因
39. リリースを怖くしない
 ↓
 失敗できる仕組みを作る
 失敗できる仕組み
40. 失敗できる仕組みの例 https://speakerdeck.com/soudai/release-safely-2 https://speakerdeck.com/soudai/release-safely
41. ここで時間があれば
 
 上のSlideを紹介する
 失敗できる仕組み
42. 1. 自己紹介
 2. 適切な問題設定とタスクへの分解
 3. 失敗できる仕組み
 4. 素早く、小さく、リリースする
 5. まとめ
 あじぇんだ
43. Small is beautiful.
 
 小さいものは美しい
 素早く、小さく、リリースする
44. Small is beautiful. 小さなプログラムという発想 1. 小さなプログラムはわかりやすい 2. 小さなプログラムは保守しやすい 3. 小さなプログラムはシステム リソースに優しい 4. 小さなプログラムは他のツールと組 み合わせやすい https://amzn.to/33QPAdv
45. Make each program do one thing well.
 
 1つのプログラムには
 1つのことをうまくやらせる
 素早く、小さく、リリースする
46. Make each program do one thing well. 一つのことに集中することで プログラムに不要な部分をなくせる。 不要な部分があると、 実行速度が遅くなり、 不必要に複雑になり、 融通が効かない。 https://amzn.to/33QPAdv
47. Build a prototype as soon as possible.
 
 できるだけ早く試作する
 素早く、小さく、リリースする
48. Build a prototype as soon as possible. ソフトウェアには常に改善の余地はあるの はもちろんだし、時間的な制約などでその ソースコードは必ずしも最高の状態が保た れているわけではない。 ほとんどのソフトウェアは妥協の産物だ。 完成することはなく、ただリリースがあるだ けだ。 https://amzn.to/33QPAdv
49. Build a prototype as soon as possible. UNIXの考え方では、なるべくはやく第三のシス テムを構築するために、すばやく試作 することをおすすめしている。 直接、第三のシステムをつくることは できないのだ。 1. 短い機能仕様書を書く (3〜4枚程度) 2. ソフトウェアを書く 3. テストして書き直す。 満足できるまで、これを繰り返す。 4. 詳細なドキュメントを (必要なら)書く https://amzn.to/33QPAdv
50. Unixの哲学を
 
 どうやって実現するか
 素早く、小さく、リリースする
51. リリースしなくても解決できるなら
 
 それが最速で最小の方法
 素早く、小さく、リリースする
52. 1. 自己紹介
 2. 適切な問題設定とタスクへの分解
 3. 失敗できる仕組み
 4. 素早く、小さく、リリースする
 5. まとめ
 あじぇんだ
53. 仕事は段取り八分の
 
 仕事二分
 まとめ
54. 失敗をできる仕組みを作る
 
 やる気の問題にしない
 まとめ
55. 仕組みで問題を解決する
 
 
 まとめ
56. まとめ
57. 目の前のコードを直すことができるのは
 
 自分たちだけ
 まとめ
58. リリースして価値を提供しましょう
 
 
 まとめ
59. ご清聴ありがとうございました
 
 
 まとめ