Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Upgrade to Pro — share decks privately, control downloads, hide ads and more …

仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal

soudai sone
September 23, 2024

More Decks by soudai sone

Other Decks in Technology

Transcript

  1. 自己紹介
 曽根 壮大(39歳)
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO


    
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

  2. “「いい質問だ。定義が『売上』となっているのは、必ず『納品』までを考慮しな ければならないためだよ。 仕掛品や完成品の在庫をどれだけ作っても、『納 品できなければマネジメントが成功したとは言えない』からね」
 確かにそうだ。だが、耳慣れない言葉に、私は思わず聞いていた。「在庫と は?この業界に在庫なんてありませんが?」
 私の言葉に、ジョナサンは悲しそうに首を振る。そして言った。
 「いいや、在庫の山はあるのだよ。残念なことに、それこそ山のようにあるだ ろう。ものづくりをしている業界で、納期遅れが起きている職場で、現場に在 庫が無いなどと考えるのは大きな誤りだ」


    「『在庫』とは、将来納品するために存在する、作りかけの未完成品や納品 前の完成品のことだ。 そのままでは納品できないもの、全てが在庫だ。
 例えばIT業界での『在庫』とは、『書きかけのコード』『未テストのコード』『別の コードの完成を待っているテスト済みのコード』 『完成していても顧客に納品 されていないコード』を指す。もちろん、『完成していても顧客に納品されてい ないドキュメント』も在庫だ」”
 https://gist.github.com/voluntas/9c1d9d51e86a853fed6889f743a12145
  3. 1. 要望 
 2. 要求 
 3. 要件 
 4.

    仕様
 要望・要求・要件・仕様 上から下にブレイクダウンしていく 場合によっては往復もする 要求と要件は一緒として扱われることも多い
  4. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 要望・要求・要件・仕様
  5. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 ステークホルダー(顧客やPO)が持っている要望の例 - 会員制のECサイトがやりたい(機能) - 高速に表示したい(非機能) - 商品を沢山売りたい(機能・非機能) 要望・要求・要件・仕様
  6. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 要望・要求・要件・仕様 ステークホルダーと決めること - 会員登録できること(機能) - 商品を注文できること(機能) - 在庫を管理できること(機能 - 素早く表示できること(非機能要件) - 世界中のユーザが利用できること - Webとスマホアプリとして動作すること(機能要件) …etc
  7. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 要望・要求・要件・仕様 要件定義 - 会員登録機能 - 保存したい情報とか - マイページ - 表示したい内容とか - 管理画面 - CSV登録の有無とか - 実行環境 - Chromeだけでいいのかとか - 表示速度の基準値 - 表示して100ms以内に表示するとか …etc
  8. 1. 要望 → 欲しいもの
 2. 要求 → 欲しいもの達成の条件
 3. 要件

    → 達成するためのシステム的な条件
 4. 仕様 → システム的な条件の実現方法
 要望・要求・要件・仕様 各要件を実装するために必要な仕様の定義 - 会員登録はSSOに対応すること - 会員登録時に生年月日を取得すること - 氏名は姓と名で分けて保存すること - パスワードは20桁以上の半角英数字を使うこと - パスワードとメールアドレスは暗号化して保存すること …etc
  9. • Why 
 ◦ そのタスクはなぜ必要なのか 
 • What
 ◦ そのタスクの実現したいことは成果物はないか

    
 ◦ 完了の定義
 • When
 ◦ タスクの期限
 • Where
 ◦ ビジョンやゴールはどこか 
 • Who 
 ◦ ステークホルダーは誰か 
 ◦ 例えば依頼者は誰か、レビューは誰にお願いするか、とか 
 • How
 ◦ どのように実現するか 
 ◦ 実装のための制約や方針なども含む 
 タスクを整理する際に大切なこと
  10. 判断と決断の違いとコツ 処理A 120(60) 処理B 140(60) 処理C 100(60) 数字は1日に処理出来る処理量 
 赤数字は実際の処理量


    1日目
 2日目
 処理A 120(120) 処理B 140(120) 処理C 100(100) 処理Aが生産した量以上は 
 処理できない

  11. 判断と決断の違いとコツ 処理A 120(60) 処理B 140(60) 処理C 100(60) 数字は1日に処理出来る処理量 
 赤数字は実際の処理量


    1日目
 2日目
 処理A 120(120) 処理B 140(120) 処理C 100(100) 最大処理能力は処理能力が 低いところに依存する 

  12. 判断と決断の違いとコツ 処理A 150(120) 処理B 100(100) 処理C 140(100) 数字は1日に処理出来る処理量 
 赤数字は実際の処理量


    1日目
 2日目
 処理A 120(130) 処理B 100(100) 処理C 140(100) 在庫 20 在庫 50 前後の工程が頑張っても在 庫が増えるだけで最終成果 物はボトルネックで決まる 

  13. https://soudai.hatenablog.com/entry/2022/01/04/151923 結論から言えば、決断のコツは失敗できるように することだ。 失敗できる状態なら決断することが できる。 そして素早くアクションして、失敗のフィー ドバックを受け取ることで新しい決断をすることが できる。
 (中略)
 もう少し具体的に踏み込むと決断をするとき、自

    分は次のようにステップを踏む。 
 1. 決断するために必要な条件を整理する 
 2. 決断が難しい場合は、素早く始め、 
 小さく失敗できるように考える 
 3. 失敗が難しい場合は、 
 社内外も含めて多くの知見を集める 
 4. それでも難しい場合は、 
 結論をできるだけ先伸ばす