Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

soudai sone

August 23, 2023
Tweet

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 適切な問題設定と
    小さくリリースするということ
    合同勉強会

    View full-size slide

  2. 先に読んでおいてほしい



    What is it?

    View full-size slide

  3. https://speakerdeck.com/soudai/first-step-for-good-development

    View full-size slide

  4. https://speakerdeck.com/soudai/necessary-mindset-for-software-developers

    View full-size slide

  5. “「いい質問だ。定義が『売上』となっているのは、必ず『納品』までを考慮しな
    ければならないためだよ。 仕掛品や完成品の在庫をどれだけ作っても、『納
    品できなければマネジメントが成功したとは言えない』からね」

    確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫と
    は?この業界に在庫なんてありませんが?」

    私の言葉に、ジョナサンは悲しそうに首を振る。そして言った。

    「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだ
    ろう。ものづくりをしている業界で、納期遅れが起きている職場で、現場に在
    庫が無いなどと考えるのは大きな誤りだ」

    「『在庫』とは、将来納品するために存在する、作りかけの未完成品や納品
    前の完成品のことだ。 そのままでは納品できないもの、全てが在庫だ。

    例えばIT業界での『在庫』とは、『書きかけのコード』『未テストのコード』『別の
    コードの完成を待っているテスト済みのコード』 『完成していても顧客に納品
    されていないコード』を指す。もちろん、『完成していても顧客に納品されてい
    ないドキュメント』も在庫だ」”

    https://gist.github.com/voluntas/9c1d9d51e86a853fed6889f743a12145

    View full-size slide

  6. 我々は素早く価値を届けたい



    What is it?

    View full-size slide

  7. 我々は素早く価値を届けたい

    ↓

    そのためには素早くリリースしたい

    What is it?

    View full-size slide

  8. どうやって沢山リリースするか


    どうやって価値を素早く届けるか

    What is it?

    View full-size slide

  9. 顧客に価値を届ける


    そのために必要な話をします

    What is it?

    View full-size slide

  10. 1. 自己紹介

    2. 適切な問題設定とタスクへの分解

    3. 失敗できる仕組み

    4. 素早く、小さく、リリースする

    5. まとめ

    あじぇんだ

    View full-size slide

  11. 1. 自己紹介

    2. 適切な問題設定とタスクへの分解

    3. 失敗できる仕組み

    4. 素早く、小さく、リリースする

    5. まとめ

    あじぇんだ

    View full-size slide

  12. 自己紹介

    曽根 壮大(38歳)

    Have Fun Tech LLC 代表社員

    株式会社リンケージ CTO


    そ

    ● 日本PostgreSQLユーザ会 勉強会分科会 担当

    ● 3人の子供がいます(長女、次女、長男)

    ● 技術的にはWeb/LL言語/RDBMSが好きです

    ● コミュニティが好き
    たけ

    ね
 とも


    View full-size slide

  13. 突然の宣伝

    
予防医療のリンケージ



    ● リモートワークの不安を数値にするストレスチェック
    ● 女性の健康課題をサポートする
    ● リモートワーク、ちょっとした心配を相談できる安心をご提供

    View full-size slide

  14. 1. 自己紹介

    2. 適切な問題設定とタスクへの分解

    3. 失敗できる仕組み

    4. 素早く、小さく、リリースする

    5. まとめ

    あじぇんだ

    View full-size slide

  15. 問題を解決するために


    解決手段としてリリースする

    適切な問題設定とタスクへの分解

    View full-size slide

  16. 問題のサイズが大きさに比例して


    リリースのサイズも大きくなる

    適切な問題設定とタスクへの分解

    View full-size slide

  17. 問題のサイズが大きさに比例して


    リリースのサイズも大きくなる

    適切な問題設定とタスクへの分解

    View full-size slide

  18. 問題が大きくても


    リリースのサイズには関係ない

    適切な問題設定とタスクへの分解

    View full-size slide

  19. 適切な問題設定とは?



    適切な問題設定とタスクへの分解

    View full-size slide

  20. 適切な問題設定とは?

    ↓

    ユーザーストーリーにすべて書いてある

    適切な問題設定とタスクへの分解

    View full-size slide

  21. ● Why 

    ○ そのタスクはなぜ必要なのか 

    ● What

    ○ そのタスクの実現したいことは成果物はないか 

    ○ 完了の定義

    ● When

    ○ タスクの期限

    ● Where

    ○ ビジョンやゴールはどこか、どこで実行されるか 

    ● Who 

    ○ ステークホルダーは誰か、利用者は誰か 

    ○ 例えば依頼者は誰か、レビューは誰にお願いするか、とか 

    ● How

    ○ どのように実現するか 

    ○ 実装のための制約や方針なども含む 

    ユーザーストーリーに書いてあること

    View full-size slide

  22. もし、チケットそのものが大きいなら


    チケットを見直す

    適切な問題設定とタスクへの分解

    View full-size slide

  23. ● 最も実現したいことにフォーカスする

    ● 実現したい体験を複数の方法に置き換えてみる

    ● 実現する場所、実装する場所を置き換えてみる

    ● 体験を届けたいペルソナを絞る

    ● 実装上の制約を減らす方法を検討する

    ● 今、やるべきことか検討する

    ユーザーストーリーを見直す

    View full-size slide

  24. つまりユーザーストーリーが


    適切か見直すこと

    適切な問題設定とタスクへの分解

    View full-size slide

  25. 開発のリソースや実装速度は


    一朝一夕では早くはならない

    適切な問題設定とタスクへの分解

    View full-size slide

  26. リリースするために調整するのは


    スコープ

    適切な問題設定とタスクへの分解

    View full-size slide

  27. 適切なサイズな問題であれば


    タスクに分解できる

    適切な問題設定とタスクへの分解

    View full-size slide

  28. 1つのチケットが


    1回のリリースに紐づく

    適切な問題設定とタスクへの分解

    View full-size slide

  29. 1つのチケットが


    1回のリリースに紐づく

    適切な問題設定とタスクへの分解

    View full-size slide

  30. 1つのチケットで


    何回リリースしてもよい

    適切な問題設定とタスクへの分解

    View full-size slide

  31. リリースの単位が


    最小になるようにタスクを分解する

    適切な問題設定とタスクへの分解

    View full-size slide

  32. https://speakerdeck.com/soudai/developer-lifehack

    View full-size slide

  33. 解決したい問題にフォーカスして


    タスクを小さくすると自然と


    適切な問題設定のサイズになる

    適切な問題設定とタスクへの分解

    View full-size slide

  34. 1. 自己紹介

    2. 適切な問題設定とタスクへの分解

    3. 失敗できる仕組み

    4. 素早く、小さく、リリースする

    5. まとめ

    あじぇんだ

    View full-size slide

  35. 何度もリリースしたい


    なのになぜ、リリースまとめるのか

    失敗できる仕組み

    View full-size slide

  36. 失敗したくない



    失敗できる仕組み

    View full-size slide

  37. 失敗したくない

    ↓

    失敗のリスクがでかい

    失敗できる仕組み

    View full-size slide

  38. ● リリースのための準備が多いので1度で済ませたい

    ○ QAやレビューなどの品質担保

    ● リリースの影響範囲が広いでの1回で済ませたい

    ○ リリースのテスト範囲が広い

    ○ APIや画面の複雑度が高い

    ● とにかくリリースが怖い

    リリースをまとめたくなる要因

    View full-size slide

  39. リリースを怖くしない

    ↓

    失敗できる仕組みを作る

    失敗できる仕組み

    View full-size slide

  40. 失敗できる仕組みの例
    https://speakerdeck.com/soudai/release-safely-2
    https://speakerdeck.com/soudai/release-safely

    View full-size slide

  41. ここで時間があれば


    上のSlideを紹介する

    失敗できる仕組み

    View full-size slide

  42. 1. 自己紹介

    2. 適切な問題設定とタスクへの分解

    3. 失敗できる仕組み

    4. 素早く、小さく、リリースする

    5. まとめ

    あじぇんだ

    View full-size slide

  43. Small is beautiful.


    小さいものは美しい

    素早く、小さく、リリースする

    View full-size slide

  44. Small is beautiful.
    小さなプログラムという発想
    1. 小さなプログラムはわかりやすい
    2. 小さなプログラムは保守しやすい
    3. 小さなプログラムはシステム
    リソースに優しい
    4. 小さなプログラムは他のツールと組
    み合わせやすい
    https://amzn.to/33QPAdv

    View full-size slide

  45. Make each program do one thing well.


    1つのプログラムには

    1つのことをうまくやらせる

    素早く、小さく、リリースする

    View full-size slide

  46. Make each program do
    one thing well.
    一つのことに集中することで
    プログラムに不要な部分をなくせる。
    不要な部分があると、
    実行速度が遅くなり、
    不必要に複雑になり、
    融通が効かない。
    https://amzn.to/33QPAdv

    View full-size slide

  47. Build a prototype as soon as possible.


    できるだけ早く試作する

    素早く、小さく、リリースする

    View full-size slide

  48. Build a prototype as
    soon as possible.
    ソフトウェアには常に改善の余地はあるの
    はもちろんだし、時間的な制約などでその
    ソースコードは必ずしも最高の状態が保た
    れているわけではない。
    ほとんどのソフトウェアは妥協の産物だ。
    完成することはなく、ただリリースがあるだ
    けだ。
    https://amzn.to/33QPAdv

    View full-size slide

  49. Build a prototype as
    soon as possible.
    UNIXの考え方では、なるべくはやく第三のシス
    テムを構築するために、すばやく試作
    することをおすすめしている。
    直接、第三のシステムをつくることは
    できないのだ。
    1. 短い機能仕様書を書く (3〜4枚程度)
    2. ソフトウェアを書く
    3. テストして書き直す。
    満足できるまで、これを繰り返す。
    4. 詳細なドキュメントを (必要なら)書く
    https://amzn.to/33QPAdv

    View full-size slide

  50. Unixの哲学を


    どうやって実現するか

    素早く、小さく、リリースする

    View full-size slide

  51. リリースしなくても解決できるなら


    それが最速で最小の方法

    素早く、小さく、リリースする

    View full-size slide

  52. 1. 自己紹介

    2. 適切な問題設定とタスクへの分解

    3. 失敗できる仕組み

    4. 素早く、小さく、リリースする

    5. まとめ

    あじぇんだ

    View full-size slide

  53. 仕事は段取り八分の


    仕事二分

    まとめ

    View full-size slide

  54. 失敗をできる仕組みを作る


    やる気の問題にしない

    まとめ

    View full-size slide

  55. 仕組みで問題を解決する



    まとめ

    View full-size slide

  56. 目の前のコードを直すことができるのは


    自分たちだけ

    まとめ

    View full-size slide

  57. リリースして価値を提供しましょう



    まとめ

    View full-size slide

  58. ご清聴ありがとうございました



    まとめ

    View full-size slide