新規開発時の大まかなフロー

現状フローの理解: 解像度上げる

そもそものクライアントが根本的に求めるものは何か
現状どういったオペレーションが組まれているのか

それを踏まえた要求分析: 何をやるのかを決める

担当者のHowを信奉せずに、根本的に求めているものから先回りして機能を考える

ユーザーに最低限FBをもらえるものを考える（実際に使っている人にヒアリングしたり実際に業務を体験して決める）
シーケンス図作成: フローを決める(最近とかだとGPTpluginのshow meとかを使う)
アーキテクチャ設計: アーキテクチャを決める -> optional

設計思想にもよるが、各コンポーネント/レイヤがそれぞれが独立して使えるようにする。（業務によっては通常のコンテキストと違った形でも機能を提供できるようにする。状況によるが。。）

PERT図の作成
1. タスクの依存関係を明確にする
  https://speakerdeck.com/recruitengineers/modernsystemdevelopment-2023?slide=43
2. チケット化する
チケットの見積もり(ポイント)
こちらのブログでは"プロダクトバックログアイテムをSMLの3種類で見積もり、それぞれをストーリーポイントの2,5,8に割り当てる”ことを推奨している。

2〜5辺り

ユースケース図の記述
トップレベルのDFDの記述→エンティティの抽出
データモデリングの実施
API設計
クラス設計
細かいRDBの設計

Tamtam

tamtam流: 見積もりのノウハウ

最小構成と最大構成で見積る

WHAT
最小構成と最大構成で見積もる。これはリリースだけでなく顧客に見せる各チェックポイントでもそれを意識する。
最小構成と最大構成で見積もる。これはリリースだけでなく顧客に見せる各チェックポイントでもそれを意識する。

補足
最小構成…
それがないと価値を証明できない。must要件。価値の証明を考える上では課題に徹底的に向き合い、何が原因で発生しているが、何があれば最低限いいのかをヒアリングし続ける。

最大構成…
ある一定を超えると顧客価値の棄損に対しての解決するコストのパフォーマンスが悪くなるライン。shoud要件?。達人プログラマでいう十分に良いソフトウェア。
課題の影響範囲を調べ、どこまで以上がやらなくても良いのかをヒアリングする。

WHY
技術による解決を確約する上で、最低限何が求められるのか、反対に顧客価値を最大化すると最大どこまで実装すべきか、を事前に理解できる。
→ スケージュール弾いて提示する上での参考になる

スケジュールの提示方法

What
顧客/社内への握りは、解決策: 最小構成の提示、スケージュール感:最大構成+バッファを提示

補足

上の内容と逸れるかもだが、

スケージュール感…
顧客に確約しなくてもいいが、期待に応える上で間に合わせる必要があるデッドライン
顧客に絶対確約しないと信頼を失うデッドライン

がある。これをスケージュール提示する前に裏で持っておき、引く上で参考にする。

Why
期待値コントロールができる

解決策が最小構成であれば、それ以下の価値提供は発生しない。
スケジュール感が最大構成+バッファなら最小構成以上の価値提供は確実に行える。なんならそれ以上の価値提供をできる。

Tamtam

クネビンフレームワーク Cynefin Framework

クネビンフレームワークとソフトウェアエンジニアリング

変化や不確実性にどう対応するのか。

Clear
- 必ずベストプラクティスが存在
  - マニュアルに基づいたルーチンワーク: 仕組み化されている
Complicated
- 不確実性が低く、予測可能性が高い
  - 専門家による分析
Chaotic
- 因果関係が明らかになることはなく、この段階で根本的な解決策を打ち出すことは不可能
- 実効性のある一次対応を可能な限り打つことに集中
  - 場当たり的なプラクティス, カオスエンジニアリング
  - ~~真っ先に思い浮かぶのは、障害対応~~
Complex
- 状況を生じさせている原因と結果の因果関係が、後になって分かる領域
- 因果関係を見出すために、失敗しても影響が小さい実験を繰り返し、そこから成功パターンを見つけ出す
  - 不確実性が高い、予測可能性が低い領域であり、実験を繰り返すことで正解となるパターンを見つけ出す
Disorder
- 当事者が理解していない混乱した状態のことだ。そもそも、理解していないこと自体を本人が認識していない可能性
  - どこにあるのかを議論する

Tamtam

Iron Triangle(鉄の三角形)

【開発法】アジャイルについて理解を深める（1）

スコープとは、機能や機能性など、実際に動くプロダクトをデリバリーするのに必要な作業のこと。
リソースは、予算、そしてデリバリーと実行に関わるチームメンバーのこと。
時間は、リリースやマイルストーンなどのプロダクトをチームが市場にデリバリーする時間のこと。

アジャイルソフトウェア開発宣言では、

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。

という形で、「認めながらも」とある。

すなわち、左記のことがらに価値があることを認めながらも、
私たちは右記のことがらにより価値をおく。

そんな鉄の三角形で、「何を重視するのか？」が

アジャイルな考えとウォーターフォールの違いに出てくる。
アジャイル開発では、「動的で非決定的かつ非線形な特徴を持つ複雑なシステムと製品開発」に向いている。
-> 何を作るかは明確には定義されていない。

モダンな開発では、納期(Delivery),費用(Cost), スコープ(Scope)の中で、スコープのみを可変とさせる。

Tamtam

大規模アジャイルの成功のポイント

大規模アジャイルフレームワークの紹介

いかに不要なものを作らないようにするか
いかにプロダクトを分割して、それぞれを独立、疎結合にするか
いかに情報の流れやコミュニケーションを整流化し、適切な権限を移譲するか

まさにDevOpsの組織のケイパビリティ

Tamtam

プロダクトバックログ(成果物1)

創発的かつ順番に並べられたプロダクトの改善に必要なものの一覧

コミットメント

プロダクトゴール
将来の状態
長期的な目標

PBI(プロダクトバックログアイテム)の書き方

PBIはユーザーストーリーベースでよく書かれる
実現したい順に一列に並べる
- 順番はリファイメントやプランニングの際に見直す
下位にある時は詳細でないくても良い。
　-　次のスプリントでプランニングができるように詳細かをする必要がある
想定しうる全てのストーリーを書き出す
　-　到底期日に間に合わない分量でも良い(後からでも入れ替える余裕を持つ)

Tamtam

スプリントバックログ(成果物2)

構成

プリントゴール: なぜ
スプリント向けに選択されたPBI: 何をするのか
インクリメントを届けるための実行可能な計画: どのように

開発者による、開発者のための計画書

スプゴを達成するために開発者が行う作業がリアルタイムに反映
デイリースクラムで進捗で検査できる程度の詳細さが必要

スプリントバックログのコミットメント(確約)

スプリントゴール
- スプリントの唯一の目的
- 開発者が確約するもの
  - スプゴ達成のために必要な作業は開発者が柔軟に考えても良い
    -　スプリントゴールがあることで一貫性と集中を生み出し、スクラムを一致団結させる

スプリントバックログの書き方

スプリントで実現するPBIについて完成させる計画を立てる

PBIが主で具体的な方法論をタスク化していく。
PBIが細かい粒度だとPOが優先度を決める負荷が上がりエンジニアが仕分けてPOが雰囲気で確認する感じになる。

タスク分割をすることが多い
スプリント中に変更したり減ったりすることもある
1タスクは1日以内のサイズにすると良さそう

Tamtam

インクリメント(成果物3)

プロダクトゴールに向けた具体的な踏み石
これまでの全てのインク面と+今回のスプリントのインクリメント
利用可能にする
- 犬種推して正しく動作することを保証
スプリントでは複数のインクリメントを作成可能

コミットメント

完了の定義(DoD)
- プロダクトの品質基準を満たすインクメントの状態を示した正式な記述
- PBIが完成の定義を満たした時にインクリメントが誕生する
  - 満たしていない場合
    - リリースできない

完了の定義の例

カバレッジ75%
受け入れテスト
ドキュメント
セキュリティ
性能

Tamtam

スクラムイベント

規定通りに運用しなければ、検査と適応ができない → これ大事
規則性を生む
スクラムで定義されていない会議の必要性を最小限に抑える
同じ時間と場所で開催されることが望ましい

スプリント

アイデアを価値に変える心臓の鼓動
1ヶ月以内の決まった長さ
進捗の見通しを立てる有用なプラクティスが存在する
スプリントゴールが役に立たなくなったときにスプリントは中止される
-　POが中止する権限を持つ

バーンダウンチャートを書く→ 残っている数。タスクが残っている遅れている。

スプリントのルール

スプリントのゴールを危険に晒すような変更はしない
品質を低下させない
プロダクトバックログに必要に応じてリファイメントする

スプリントレビュープランニング

POは参加者に対して最も重要なPBIとプロダクトゴールの関連性について話し合う
アドバイスを得るためにチーム以外の人をプランニングに巻き込むとかも可

プランニングのトピックス

なぜこのスプリントは価値があるのか

スプリントゴールを定義

スプリントで何ができるのか
　- POと話し合いPBIを選択しスプリントに含める
選択した作業をどのように成し遂げるのか
- PBIを一日以内の小さな作業アイテムに分解する

デイリースクラム

やること
　- スプゴに対する進捗の検査　など
開発者のための15分のイベント
POやSMはスプリントバックログのアイテムに積極的に取り組んでいる場合に開発者として参加
デイリースクラム以外でも計画は調整しても良い

スプリントレビュー

スプリントが1ヶ月の場合、タイムボックスは最大4時間
スプリントの成果を検査し、今後の適応を決定する
ステークホルダーに作業の結果を提示し、プロダクトゴールに対する進捗を話し合う
など
環境の変化を確認:

スプリントレトロスペクティブ

スプリントが1ヶ月タイムボックスは最大3時間
目的: 計画すること
個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査
話し合うトピックス
- スプリント中に何が上手くいったのか
- どのような問題が発生したか
- どのように解決されたか解決されなかったのか
  など

イベントのタイムボックス(目安)

スプリント１週間
プランニング 2時間
デイリースクラム 15分
スプリントレビュー 1〜2時間
レトロスペクティブ 1時間

Tamtam

スクラムの原典

スクラムの原典を読み解く(1)

type-Cのチームの6つの共通点

1.不安定な状態を保つ

- 。ソフトウェア開発はプロジェクトの開始時にすべての要求を固定することができないという特性を持つ。だから、アジャイル開発では、要求を固定するよりも、人を中心にしたコミュニケーションと協働でプロジェクトを前に進める。

2.プロジェクトチームは自ら組織化する

- 自己組織化されたチームの状態には、(1)チームが自律しており、(2)常に自分たちの限界を越えようとし、(3)異種知識の交流が起こる、という特性がある。
    - 「スクラムマスター」はメンバーに指示を与えるのではなく、チームが自分たちで決定できる環境を支援するのが役割　→　自立性を尊重
    - チームは１つの部屋に集まることが基本

3.開発フェーズを重複させる

- 専門部隊の垣根を取り払って１つのチームとなる
    - 自己組織化されたチームは独自のリズムを作り出す。開発と製造では、もともとスケジュールの考え方が異なっているのに、それが一体となって全体のゴールを目指すことになる
- 情報をオープンに保つ仕組みも、アジャイル開発に積極的に取り入れられている
    - チームの状況はバーンダウンチャート、バックログ、タスクかんばん、等々によって顧客にまで透明に共有される。
    -

4.マルチ学習

- メンバーはグループ全体として学習し、さらに専門を超えて学習する。
    - アジャイル開発では、顧客の要望を「仕様書」という形ではなく、「ユーザーストーリ」という読みやすい形でカードに書き出す
        - これには、コミュニケーションを発生させる意図がある。詳細に書かれていないからこそ、そのカードを壁からはがして手にとり、それを持って顧客のところに行き、実際に質問をする。「カードは会話のチケット」でもある。詳細に書かれた仕様書という形態ではなく、実際に顧客と対面で会話をすることによって、要望についてのより深い理解を得るのだ。

5.柔らかなマネジメント(subtle management)

- ７つのポイント
    - 正しいメンバー
    - 専門を超えて対話が起こるような、オープンな仕事環境
    - エンジニア自身がフィールドに出て行きって聞くように仕向ける
    - 個人ではなくグループ評価を基本: チームに還元する
    - リズムの違いをマネジメントする
    - 失敗を自然なこととして受け入れる
    - サプライヤにも対しても、自己組織化を促す
        - 課題を提示してどのように解決するかは任せる
    - スクラムマスターの役割
       - 協調型のリーダーシップを取る。特に、2.のオープンな仕事環境づくり、5.リズムのマネジメント、などが仕事となるだろう。
       - 3.のフィールドへ出かける姿勢、6.の失敗に対する考え方は、アジャイルの価値観や原則の中で言及されている。
    -

6.学びを組織で共有する

- 過去の成功を組織に伝える、もしくは、捨て去る。
    - キーパースンを、次のプロジェクトに入れることによって、やり方を浸透させるのである。あるいは、プロジェクトのやり方を組織標準へと昇格させる

Tamtam

スクラムの三本柱

透明性
- 伝達する。オープンにする。やっていることを周りの人が理解する。
- 透明性のないの検査は誤解を招き、無駄になる
検査
- 頻繁かつ熱心に検査する
  → 問題を検知する。4つのイベントでリズムを提供
  
  スプリントプランニング
   デイリースクラム
   リファインメント(任意でこれはやらなくても良くなった)
  スプリントレビュー
   レトロスペクティブ
適応
- できるだけ早く調整
- 自己管理されていない時は適応が難しくなる

Tamtam

スクラムチームの特徴

機能横断型
- ステークホルダーのコラボ、検証、保守、運用実験、プロダクトに関して必要になり得る全ての活動に責任を持つ。
自己管理型
- 何が、何を、何時、どのように行うかはスクラムチームが決定する。

Tamtam

タイムラインのハピネスレーダー

Tamtam

スプリントレトロスペクティブで話すべきこと

スプリントゴールをどの程度達成できたか
チームで改善したいこと
個人で改善したいこと

スプリントレトロスペクティブでスクラムマスターが考えること

スクラムマスターが、レトロスペクティブが意味のあるもの（メンバー全員が改善に向かうように意見を言えてエイルか）をか考える

改善点が出ない時: ハピネスレーダーなどの『思い出す」プラクティスを使う
改善点がありすぎる時: 一番大切そうなテーマを取り上げて議論する

Tamtam

チームの文化をベースに意思決定

エンジニア総動員してスプリントゴールタスクを終わらすようにコミットすることは良いこと?
-> チームの文化や共通認識による。

例えば、
総動員することで長期の生産性や収益性を下げる(スプゴのコミットメントを優先するとリソース効率性が下がる新規プロダクトのリリースが遅れる的な)のであればオーバーコミットメントしすぎかもしれない。
それであればコミットメントの緩みを考えるか、自己管理ができているのであれば、しょうがいない。スプリントでできる量を考える。制度をする。すぎなのであれば、考えている。コミットメントをする。

チームの文化をベースに考える

Tamtam

ケーススタディ_何かしら調査し、新たに冗長性のためにサーバー構築のコストが発生した場合

PO: コストを受け入れるかを意思決定する
スクラムマスター: こすとをもとにぷロダクトバックログアイテム作る
開発者: コストの情報を作る

Tamtam

プロジェクト憲章(PMBOK)

ステークホルダ（利害関係者）に対してプロジェクトの存在を正式に認可してもらうことを目的

・プロジェクトの目的または妥当性
・プロジェクトの目標及び成功基準
・要求事項概要
・プロジェクト記述概要（プロジェクトの方針）
・リスクの概略
・要約マイルストーン、スケジュール
・要約予算（概要見積り）
・プロジェクト承認要件（実施承認の判断基準や担当者）
・プロジェクトマネージャ（責任と権限）
・プロジェクト・スポンサー（プロジェクトの最終責任者）

Tamtam

デイリースクラムを複数会やる是非

教科書的にはデイリースクラムを２回行うのは聞かない。

分けても同じことを話す場合があるため、ムダが増えるようにおもえる。が、上手く回るチームもあると思うので、やっても良いとかもしれない。(それでも、時間は合わせて15分以内にするのが良いのが一般的な意見)

Tamtam

アイデア出しのサポート

Tamtam

プロダクトオーナー

プロダクトオーナの作業は委任するが、最終的な責任はプロダクトオーナーが持つ
プロダクトオーアナーはスプリントレビュー前にプロダクトバックログアイテムの完成を確認する
プロダクトオーナーは開発者と常に話ができる存在である

Tamtam

スクラム開発で推奨されている人数についての見解 (3〜10 人)

人が多いと
- コミュニケーションコストが増える O(N^2)
- 主体的に動かない人が出てくる
- 役割が分かれやすくなる
現在のスクラムガイド(通常は10人以下)
- 人数の指数関数的に難しくなる

Tamtam

アジャイルプラクティスガイドブックチームで成果を出すための開発技術の実践知

Tamtam

やらないことリスト

やること
やらないこと
あとでやること

Tamtam

インセプションデッキ

「ご近所さんを探せ」: 関係者が意外と多い
解決案を描く: 技術的な課題や解決策が実現手段として適切か確認する
- スコープにもなりえる
- リスクも考える
夜も眠れなくなるような問題
- リスクを明確化
- 課題についてチームで話し合う
俺たちのAチーム
- ミッションをやり遂げるためのチーム編成を考える
- スクラムチームであればスクラムの役割を入れる
  - プロダクトの特性に合わせて具体的に何を期待するのか書くと良い
期間を見極める
- 大体の期間を提示する
トレードオフスライダー
初回のリリースに必要なもの
作って終わりにしたい

ゴールを統一するためのインセプションデッキ

「我々が取り組んでいるのは、何かをこなせば成果が出るという簡単な物ではなく、正しい道を探りながら作らなくてはならない。そのために、無駄に見えるかもしれないですが、これらの点を抑えておくことが大事なのです

Tamtam

プラグラティック・ペルソナ

具体的な対象ユーザーを決める
何名か作っても良い
ターゲットと違ってきたら見直す

共感マップ(エンパシーマップ)

いきなりペルソナを作るのも大変なので前準備
順番に考えてみる
- 後から追加しても良い

Tamtam

振り返り方法の取捨選択

ふりかえりの目的がちがうので、チームの問題点をみて、ふりかえりの方法を変える

KPT.. 最後にTRYを出すので、「何か行動する」のが大事な時に使う
+/ΔやFun Done Learn... 現状認識だけでその後の対応はお任せ。そのため、強制力を持たせるのではなく、共通認識を持たせるのに使う

Tamtam

Output(生産高)よりもOutcome(成果)

https://www.mobiusloop.com/

プロダクトの成功には、成果にフォーカスすることが必要

Mobius Loop(メビウスの輪): (結果ではなく)成果に着目したFW

成果を仮説検証をしながら発見し続けていく

アジャイルでは素早い開発に優れていますが、チームの開発パフォーマンスを指標としているのもあり、間違えたものまで素早くリリースできてしまいます。Mobius Outcome Deliveryは、"What/How＝何を/どのように作るか？"だけでなく、"Why/Who＝なぜ/誰のために作るのか？"についてチームで見通せること、発見と提供のバランスをみながら検討できるのがメリットです。

Tamtam

作成物:プロダクトバックログ

一つ一つをプロダクトバックログアイテム(PBI)と呼ぶ
1スプリントで完成可能なサイズ
- 理想は最低でも3つぐらいのプロダクトバックログアイテムをスプリントで選択できるようにする
創発的かつ順番に並べられている
作業を行う開発者は、作業規模の評価に責任を持つ
上位になるほど詳細になる • 最初から全てを詳細化しない
すべてのプロダクトバックログアイテムをストーリー形式にする必要はない
- ログなどのシステム的な物、リファクタリングやバグ
- 最初からすべてのプロダクトバックログアイテムをストーリー形式で書く必要もない
  - 手段は後から考えてもよい

ストーリーの3C

カード (Card)
- ソフトウェアに望むことをインデックスカードに書く
- カードの初期バージョンは会話が始められるぐらいの最低限のものにする
会話 (Conversation)
- チームやステークホルダーが集まって、どのようなソフトウェアを作るか会話する • 言葉や絵を使って会話を促進する
- 会話中にストーリーの内容は変わったり、ストーリーは分割されたりする
- 「会話する約束」
確認 (Confirmation)
- 開発に入る前に、完成の定義やデモシナリオを決める • 合意した記録を残す

ユーザーストーリーは要求ではない

要求・要件=必ず実装しなければならないもの、ではなく交渉可能な意図の表現
- やって欲しいこと、やったらよいと思うこと、妄想
数日~数週間で開発可能な価値ある機能の小さなインクリメントを表す
比較的容易に見積もれるサイズ

ユーザーストーリーはINVESTにする

良いプロダクトバックログの定義とも言える

Independent (独立している)
- 一つのストーリーがそれだけで開発・テスト・潜在的な納品ができる
  - 単独で価値がある
  - 他のストーリーに依存しない(とはいえ依存性があるものは仕方がない。依存性を無くすためだけに依存する部分を切り取ってタスク化はユーザー価値に紐づかないためダメ)
- 順番の入れ替えが簡単にできるようになる
Negotiable (交渉できる)
- 常に変更する柔軟性を持たせる
- 完全に完了するまでは書き換え可能
- 会話の中でコスト(実装やテスト)と価値のトレードオフを調整
Valuable (価値がある)
- プロダクトのユーザー・顧客・ステークホルダーに実際の価値を提供できる(=何かしら使える状態になっている)
  - 一部の機能だけできていても価値提供やFBを得ることができないならだめ(曳光弾的に作ってFBもらえるようにするとか)
Estimable (見積もりができる)
- 1スプリントに納まるサイズにする
  - 1スプリントで複数プロダクトバックログアイテムが選択できる状態が望ましい
  - チームがストーリーを見積もれない場合は、ストーリーが大きすぎるか、不確定性が大きい時
    - 不確実性を減らすために、技術的調査(スパイク)を行う
Small (小さい)
- ユーザーストーリーが小さい
Testable (テストできる)
- テスト可能な内容であること
- ストーリーには完成するために合格すべきテストが書かれている
- 先にテストを書くこともある
  - ATDD(Acceptance Test Driven Development: 受け入れテスト駆動開発)の考え方
  - このシナリオが取ったらOKというのをストーリーに記載しておく
    - ATDDはシナリオをテストコードとして実装する
    - 完成時にはテストがパスしていなければならない

プロダクトバックログの分割方法

アンチパターン
- 技術レイヤーで分ける
- 例:1フロントエンドを作る 2 バックエンドを作る
- 工程で分ける
  - 例:1設計する 2 開発する 3 テストする
    → Valuableでないため
分割方法
- スパイク(技術検証)と機能実装で分割
- ハッピーパスとそれ以外で分割
  https://www.servantworks.co.jp/posts/5-strategies-product-backlog-refinement/
  - 顧客として、自分のアカウントでログインすることができる（ハッピーパス）
  - 顧客として、ログインに失敗した場合、自分のパスワードをリセットすることができる（アンハッピーパス）
- 入力パラメータで分割
  - 抽象的な機能ではなくより入力値ベースで細分化
- 利用者の役割によって分割
- 最適化の度合いで分割
- プラットフォームで分割
- ビジネスルールで分割
- ワークフローのステップで分割
- 操作(CRUDなど)で分割
- ブラウザの種類やバージョンによって分割 • テストシナリオ、テストケースで分割

Tamtam

Readyなバックログ

プロダクトバックログアイテムが用意されている
プロダクトバックログアイテムの価値が明確である
開発を進める上での大きな疑問や決定すべき事柄がない
チーム全員が何を作ればよいか理解できている
受け入れ基準が明確である
他のアイテムとの依存関係が明確である
開発チームによって見積もられている
デモの手順が明らかになっている → POレビュー時にイメージできるようにしたい

Tamtam

PBIの優先順位決め

プロダクトバックログは必ず一意な順番を付けなければならない
プロダクトオーナーは状況に応じて順番を決める必要がある
• 先2~3スプリントぐらいは考えられているとよい

遅延コストの定性的評価

https://scaledagileframework.com/wsjf/

価値が高く、緊急性の高いものが一番優先順位が高い
リリースから得られる価値の総量とリリースまでにかかる時間のトレードオフを考慮する
リリースまでに時間がかかってしまうと稼げたはずのお金を失う
検証の結果、回収のインパクトが大きいものは優先順位を高くする

顧客満足の狩野モデル

製品品質の品質要素について主観的側面と客観的側面の二側面の対応関係を提案

客観的側面 = 物理的な充足
主観的側面 = 満足感

分類は人によって異なるので、アンケート調査を行う

2つの質問をする
- 充足の質問(=あったらどうか)
- 不充足の質問(=なかったらどうか)

Tamtam

555(triple nickels)

ジャストアイデアで思っていたことを言語化していく。

思い出して、ブラッシュアップする。

Tamtam

レトロスペクティブでの振り返り時に、KPTの前にスプリント中でやったことを想起するためにスプリントバックログを見てやったことを振り返る
or 思い出しの手法(ハピネスレーダー)などを先にやる

Tamtam

インペディメントリストに積み残したいものを入れておく
- 例:
  - PBIとスプリントのチケットの粒度が同じためPOの認知負荷が高い印象(つまりPBIが詳細すぎる)
  - PBIの優先順位が低いものを大雑把にする(リーンにやる)
  - スクラムイベントのマスターを定期的に交代しているが、外部との折衝は完全に切り離されていない
    - 外部との折衝の内容を折衝した以外の人がログをとる(?)。カテゴリ分けして対応策をまとめる

Tamtam

ユーザーストーリーマッピング

プロダクトバックログはただのリスト
- 全体像や全体フローが掴みづらい
Jeff Pattonが提唱
- プロダクトのユーザーワークフロー、設計、リリース計画を見えるか化

構成

ペルソナ
大きなアクティビティ
各アクティビティのステップ
各ステップの紹介(ストーリー)

Tamtam

MRF: リリース可能な最低限のフィーチャー (Minimum Releasable Features)
- 顧客に対して価値有する機能群。実際に使うには機能が十分にそろっていない場合もある
MVP: 実用最低限の製品 (Minimum Viable Product)
MMF: 市場性のある(顧客がいて使い始められる・本番運用できる)最小限のフィーチャー (Minimum Marketable Features)

Tamtam

スクラムマスターがーがイベントのファシリをする必要はない。->スクラムがうまく回れば良い。

Tamtam

ベロシティ

以前のスプリントにおいて完成できた見積もりのポイントの合計

予測に使う
- 直近3回分の平均をとって推測する
- 前回のベロシティから推測する

Tamtam

スプリントビューの事前準備

誰を招待するのか決める
スケジュールを調整する
- 重要なステークホルダーの固定の予定に合わせる
- １週間スプリントで最大1時間
スプリントの成果が完成したことを確認する
デモを準備する
- プレゼンのスライドは不要
誰がするのかを決める

Tamtam

ふりかえりを効果的にしていくために

失敗したことだけでなくうまく行ったことも話し合う
- アイスブレイクにもなる
- 感謝を伝える場にもなる
- 色々なやり方を試す
  - 振り返りは形骸化しやすいため、一つの方法ではなく色々なやり方をやる
  - 振り返りのふりかえりをする
- 一度にたくさんのことを解決しようとしない
  - 次スプリントでやるアクションは1,2個くらいにする
やることを増やすよりもやらないことを増やす

Tamtam

ペアプログラミング

新人や新たにチームに加わった人に対して行うのが効果的な印象

モブプログラミング

プログラミング以外でもモブワークとして応用可能

アジャイルにおいて大事なこと

勇気: スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ

Tamtam

優先順位を決める: Qualitative Cost of Delay

プロダクトバックログは必ず一意な順番を付けないといけない
優先度は全て「高」は許されない
プロダクトオーナーは状況に応じて順番を決める必要がある
- 先に2〜3スプリントくらいは決められるように

優先順位を決める: 顧客満足の狩野モデル

社内OPSでもアンケートやるの良さそう

当たり前品質要素：点数が高いものから順次開発していく
一元的品質要素：点数が高いものから順に「1スプリントに1要素」等を目安に取り込んでいくと良い
魅力的品質要素：点数が高いものから順に「3スプリントに1要素」等を目安に取り込んでいくと良い
無関心品質要素：作る必要はない
逆品質要素：作ってはいけない

Tamtam

POの他の仕事

ストーリーマッピング等で作成したリリース順をスケジュールにする
マイルストーン（中間地点）とも呼ぶ
１週間のスプリントであれば、一ヵ月ごとに作っておくのが良い（４スプリント分）

Tamtam

引用: 完成の定義と受け入れ条件の違い

この2つの用語は混同しがちであるため、あらためて解説する。

受け入れ条件と完成の定義
（出典：永和システムマネジメント「アジャイル開発の基礎知識研修」テキスト）

完成の定義はPBIをまたがって共通的に決めるものである。すべてのPBIが満たす必要がある品質基準や非機能要件などは完成の定義に入る。

例）2秒以内にレスポンスが返ってくること、ユニットテストが書かれていること、mainブランチにマージされていること、など

一方、受け入れ条件はPBI毎に個別に決めるものである。

例）ユーザー管理画面であれば、ユーザー名が更新できること、ユーザー名は英数字5文字以上、他のユーザーと重複しないこと、など

PBIは完成の定義と受け入れ条件の両方を満たしてはじめて完了となる。

Tamtam

スクラムチーム内で複数ラインを持つ場合

スクラムでは「チーム内にはサブチームや階層は存在しない」という特徴がある。

この時、チーム内で機能やプロダクトを複数持ち2ライン等でやるのはアンチパターン。
(明確なプロダクトゴールを設定できないので)

規模や忙しさが小さくて複数抱えなければならないことがある場合は、

バックログはチームで一つに統一
POは一人にしたほうがプロジェクト間の優先順位が決まりやすい
プロダクトでラインを分けない方が柔軟性は上がる
スクラムイベントも全て同時に行う
→上記のことが難しければスクラム以外の手法を試す

Tamtam

POと開発優先度 / 開発進捗(リリース時期) をうまく握るには

前提: スクラムマスターの役割(色々省くが)

チームの開発生産性を上げる
- チームが目標を達成する上で妨げとなる可能性のある障害や気の散る要素を巧みに取り除くことでスクラムチームがより効果的に作業できるようにする

開発優先度観点で生産性を上げるには

生産性をoutput量としてではなく最終的にユーザー価値になったもの(outcome)として考えると、
- 開発者としてのタスクの優先度: 普変度が高いものから実装する
  - 例: コアなシステム
- POとしてのタスク: 変更性が高いものからFBをもらえるようにする
  - 例: mock作るとか、トンチ絵作るとか。きつそうであれば簡単にプロトタイプ作ってもらう

開発進捗(リリース時期) を握るには

初回リリースで必要な機能(変更性高いもの/低いもの全部)をmock等を見比べつつ概要レベルで洗い出す
大枠でタイムラインを出す
- 時間 / リソースを調整する

Tamtam

memo:

事前にPOがストーリーチケットを切る / 並び替える
差分があればPOがアップデートの共有を行う(仕様の変更, 優先度の変更など)
優先度が高いものから順に見積もる
- ストーリの要件のすり合わせ
  - 足りていない部分はどこで何をやるのかを決め切る/削る
- 必要に応じてストーリーの分解
  - 要件すり合わせ…
- ストーリーの実装方針の確認
- プランニングポーカーをする

Tamtam

大きなユーザーストーリーを作成
- 初めに、サービス全体の主要な機能をカバーする大まかなユーザーストーリーを作成します。この段階では、各ストーリーがユーザーの主要なニーズを満たすことを目指します。
大まかなストーリーをレビュー
- 作成した大まかなユーザーストーリーをチームでレビューし、それぞれがどのような価値を提供するか、実装の優先順位を考慮します。
ストーリーを細かく分割
- 各大まかなユーザーストーリーを、実際の開発タスクとして実行可能な小さなストーリーに分割します。以下の点に注意して分割します：
  - 独立性: 各ストーリーが独立して完了できるようにする。
  - 具体性: 具体的なアクションや結果を明示する。
  - 価値の提供: ユーザーに対する明確な価値を示す。

Tamtam

スプリントプランニングのステップ

ベロシティの確認

スプリントゴールの設定:

目的: 次のスプリントで達成するべき具体的な目標を設定します。
プロダクトオーナー: プロダクトオーナーはスプリントの目標を提案し、チームと協議します。
バックログアイテムの選定:

優先順位の高いアイテムの確認

チームはプロダクトバックログから、スプリントゴールに最も関連するアイテムを選びます。
フィージビリティの確認: チームは各アイテムの見積もりを確認し、スプリントの容量に合わせて適切な量を選定します。
タスク分割:

ユーザーストーリーの分解:

選ばれたバックログアイテムを小さなタスクに分解します。

タスクの見積もり:

各タスクの所要時間や難易度を見積もります。

タスクのアサイン

タスクの割り当て

チームメンバーに各タスクを割り当てます。ただし、全員が全てのタスクに関与できるように柔軟性を持たせることが重要です。
リスクと依存関係の確認:

Tamtam

ポインティングポーカーで経験/慣れを考慮してポイントを増減してはいけない

チームの成長に応じて、ポイントの基準がずれてしまう
- ベロシティが上がっていかない構造になるため

Tamtam

ベロシティを上げる vs. 安定させる
大前提
ソフトウェア開発チームには常にベロシティを下げる力（変化）が働いています。例えば、以下のような変化があります：

市場の要求
ミドルウェアやライブラリの変更
システムの使用言語や設計の変更
トラフィックやリソース使用の変動
メンバーの変更
これらの変化に適応することがアジャイルの重要な価値観です。

ベロシティを安定させる
ベロシティを安定させることは簡単ではありませんが、高いレベルの計画、ふりかえり、障害物の排除が必要です。安定したベロシティは、以下のようなメリットがあります：

スプリントごとに予測したことが確実に終わる
大きな計画の精度が上がる
POやステークホルダにとって嬉しい
チームが変化に押し潰されず、達成感や自己効力感を得られる
安定したベロシティは多くの現場で十分に高い目標であり、最初に目指すべきものです。

ベロシティを上げる
価値のデリバリーは速いに越したことはありません。ベロシティを上げる際の重要なポイントは以下の通りです：

ベロシティをハックしない（見積りをいじったり、完了条件を緩めたりしない）
持続可能であること（無理な残業やその場しのぎの実装を避ける）
ベロシティを安定させることが前提となり、その上で自然と望ましい行動が導かれます。ベロシティを上げるのは、安定したチームが次に目指す目標です。

結論
ベロシティを上げる vs. 安定させるは二項対立ではなく、ベロシティを安定させた上で上げることが目標です。短期的な目標としてベロシティを安定させ、長期的な目標として上げることが適切です。

ベロシティを生産性観点で見るなら、4keysとか別の指標で追うべきでは？
ChatGPT
確かに、ベロシティだけを生産性の指標とするのは限定的であり、より包括的な視点を持つことが重要です。4 Keys (Four Key Metrics) やその他の指標を使用することで、チームのパフォーマンスや生産性を多角的に評価できます。以下に、4 Keysとその役割を紹介します。

Tamtam

スクラムマスターの１番の役割は自己組織化されたチームつくり、ハイパフォーマンスにすること
→ デリバリー責任を持つことでは無い。あくまでもチームとして思考させること

Tamtam

ポインティングポーカーの考え方

ポイントをふる際の考え

-正確にかつ客観的に見積もるようにする
- 正確に見積もるには
- 技術的難易度

作業量
- ステークホルダーの多さ等多面的に評価
客観的に見積もるには
- 慣れ/経験によって難しさを判断しない => 人に依存してしまい、絶対的でなくなる

ポイントを振った後の考え

どうしたらポイントを効率的に消化できるかを議論する
- アサイン
- 進め方　等

Tamtam

議論で納得させるには -> 本の引用等で権威で殴る

今だとスクラム本をGPTに食わせるが良い？ただそれだと自分の血肉にならないのが問題

Tamtam

直近大事にしているスクラムマスターとしての意識

1歩先に立って考える
- 来週のスプリントプランニングのことを先週時点で想起する
  - プランニングがグダリそうならリファイメントを実施する
    例: 月にプランニングがあるなら水時点で考える
    - 予想されるゴールの確認
      - ゴールに紐づくPBIの要件の確認
      - 要件がファジーなら埋める
      - 要件の前提で調査が必要ならその調査タスクを切る
会議中はファシリに徹する
- 会議の明確な目的, 期待する成果物を先に定義
  - それに基づいて進行を組み立てる
- 自分を会議の中心にしない、基本的にチームに意見を求める
- 課題と解決の話に意識を向ける -> 課題の議論を優先して認識を揃える

Tamtam

以下を意識して組み立てる。

スプリント計画（Sprint Planning）
目的：

スプリントで取り組む作業を決定する。

チーム全体でスプリントの目標（Sprint Goal）を設定する。
期待する成果物：

スプリントバックログ：スプリントで完了するためのタスク一覧。
スプリント目標：スプリント期間中に達成するべき目標。

-> 目標が先立って計画が作られる

デイリースクラム（Daily Scrum）

目的：

チームメンバーが進捗を共有し、問題を早期に発見して対策を立てる。
次の24時間の計画を立てる。
期待する成果物：

チームメンバーの進捗状況の共有。
問題や障害の共有とその対策。

→ 計画に対して各人の進捗共有

次の24時間の行動計画。

スプリントレビュー（Sprint Review）

目的：

スプリントで達成した成果をステークホルダーと共有する。
フィードバックを受けて製品バックログを更新する。
期待する成果物：

実際の作業成果物のデモ。
ステークホルダーからのフィードバック。
製品バックログの調整と更新。

-> ゴールが達成したかの評価

スプリントレトロスペクティブ（Sprint Retrospective）

目的：

チームのプロセスと作業方法を振り返り、改善点を見つける。
次のスプリントに向けて、プロセスの改善策を決定する。
期待する成果物：

改善点のリスト。
次のスプリントで実施する改善策。
チームのプロセスやツールの改善案。
これらのスクラムイベントを通じて、チームは継続的に改善し、より効率的に目標を達成することが期待されます。

-> プロセスの継続的な改善

Tamtam

リファインメントで分割時の対応

関連チケットにリンクを記載
- 元のチケットのものをリプレイス
  - 明示的に分割したように見せる
- ポイント見積もり前に確認

Tamtam

スクラムマスターとしてのタスクの振り分け意識

落ちているボールをとにかく渡す
- 自分をロードバランサーと思って渡す
  - @ メンションで自分を棚に上げて渡すようにする
課題気づいたら都度話せるようにする
- 人でなくモノに目を向ける、アサーティブになりすぎると主張だけなく目の向け方として人にならないときがある。ので、人にも目を向けてちゃんと言えるようにする

Tamtam

https://kanbanflow.com/

Tamtam

朝会でPBLに追加してもらいたいものがないかスクラムマスターとして問いかける
- 問いとして、朝会で困っていること等の話がないか(課題感等)を引き出す
あくまでPBLを管理するのはPdMだが開発の現場からストーリー解決のため必要な別ストーリーがでてくるケースもある

スクラムマスターとしての発言のときは、「スクラムマスターとして発言しますが、」と立場を明らかにする

Tamtam

POがフル稼働できる時間に強い意志を持ってずらす

Tamtam

リソース効率性を上げる... 一人にチケットをやらせる。アウトプットが見えているものに良さそう。
フロー効率性を上げる... 細かくチケットを切って価値にフォーカス

Tamtam

改めてPdMとは

強いPdM...PL責任を負い、事業のイベントに連動してプロダクトを作っていく。
弱いPdM...プロジェクト進行にフォーカス。QCDのQDをメインにやる。加えてどのように売っていくかといった構想力が弱い

強いPdMは文字通りプロダクトで事業を創造することにフォーカスする。
プロジェクトの進行や仕様といったHOWも、どの機能がどれだけの事業インパクトに繋がる、そしてその機能を作るためにどれくらいのコスト(単価 x 時間)を払うのかの管理し、その上で優先度を決めてく。くらいのことをやりたい。

改めてSMは

プロジェクトの進行や仕様以降の相対的に川下になる業務は別の人に任したい。

極端な話、

強いbizと強いtechでタッグを組めばコミュニケーションパスが減る

ので、強いチームであればプロジェクトの進行や仕様をする中間の人間はなくても成立する(メンバー側がPdMがプロダクトに集中できるように積極的に支援し、回るようにする)

PdMはより開発においてビジネス的なチューニングをしお金を生み出すようにし、メンバーはより支援する形で構想の実現をする

Tamtam

スクラムの弱いところ
- 冷静な目線でどのようにお金に変えるのかといったOUTCOMEに対する議論を仕組みとして設けない(PdMの力量になる)
  - お客様の欲しいものはわかるが...

Tamtam

最終的なストーリーは何か

必要な観点は何か
不必要な観点は何か

Tamtam

スクラムのバーンダウンチャートといいますか、スケジュール見積もりの手法(ポインティングポーカー含む)に最近違和感を持っています。

違和感の言語化として、以下ようなことを経験したので列挙します。

基本的に計画的に終わることはない
見積もりに時間かけるよりも、エンジニアに仕様だけ渡し実際に設計/実装する
- 方が、机上の空論にならず解像度が高い状態で問題に対して議論できる
- でもボトムアップで進捗がおえる(100分率であと何%くらいで終わるか聞くだけで良い)
単に見積もりをしてその時に計画的に進んでいることを安心しているだけなのでは
リスクが高い順にタスクに取り組むことをブラさなければ見積もりせずともプロジェクトはうまく回る認識。

リスク大: 基本的に調査しないとわからないので実際に見積もりよりも検証に注力した方が良い印象
リスク中: 見積もりをしても、検証/実装しても同程度良い印象(であれば見積もりをしないでも良いのでは?)
リスク小: 見積もりを頑張らずとも実際に実装してもらう方が時間が有効的に使える(リスク大から取り組んでいる前提であれば経験によりどのくらいで終わるかが直観でわかる)

とはいえ、ビジネス的なデッドライン(事業会社ではIR資料に載せたい/競合のサービスに対抗したいのでいついつまでに必要)があるので、ビジネス判断をできるための材料としての見積もりが一定必要なのではとも思っています。

こう言った場合、一旦以下のように落ち着いたのですが、どう思われますか。

なるべく(ビジネス判断のための)見積もりを遅らせる
デッドラインのポイントを分割し、1ヶ月程度のプロジェクトに分ける。また、時間をベースにスコープを決定する（スコープから時間を見積もるのではなく、時間からどこまで終わるかを感覚的に判断）。

Tamtam

出来る限りソフトウエアプロジェクトのサイズは小さくし、リスクの暴露が確認できるプロジェクトサイズへと小さく分割すべきである。

Tamtam

リーンポートフォリオマネジメント（LPM）は、企業全体のポートフォリオを効果的に管理し、戦略の実行を支援するためのフレームワークです。LPMの主な特徴は、戦略と実行の整合を取るためのアプローチ、分散型の意思決定、リーンガバナンスを基盤に持つことです。また、LPMはSAFe（Scaled Agile Framework）の一部であり、エンタープライズ全体でのビジネスアジリティ向上を目指しています。
まず、LPMは戦略、予算編成、実行の足並みを揃えることを目標とし、各ポートフォリオの戦略とその実現のためのインベストメントファンディングを効果的に管理します。このアプローチにより、ポートフォリオ内の優先事項が明確になり、企業全体での目標達成に向けた整合性が高まります。
次に、LPMは軽量なガバナンスと分散型の意思決定を採用していることが特徴です。これにより、現場レベルでの迅速な判断が可能になり、ビジネス変化に対する適応力が向上します。分散型の意思決定は、重要な戦略的決定は中央で管理しつつ、その他の意思決定は現場に委譲することで、効率的なリソース管理と問題解決を促進します。
LPMの効果として、従来のプロジェクトベースのアカウンティングに代わり、バリューを中心とした編成が実現できることが挙げられます。これにより、サイロ化した部門間の摩擦を減らし、迅速な学習と市場投入を可能にし、ビジネスの成果を最大化します。また、ポートフォリオ全体でのフローを最適化することで、計画と実行のスピードが向上し、顧客に対して継続的に価値を提供することができます。
LPMは、リーンとシステム思考を活用することで、戦略と実行の連携を強化し、ビジネス全体の持続的な成長を支援します。