#ふりかえり実践会「スクラムガイドを読み解いてみよう」第5回のまとめ

8/29(土)に開催されたふりかえり実践会スクラムガイドを読み解いてみよう」の議論をサクッとまとめました。 retrospective.connpass.com

筆者は第2回ぶりの参戦です。

スクラムガイドはこちらからJapanese版をDLください。

スクラムマスター

  • スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと/立たないことスクラムチームの外部の人たちに理解してもらう。」とは?
    • 例えば
      • 役に立たない: ステークホルダーからのフィードバック時に叱責はやめよう
        • POが言い出しにくい時とかある
      • 役に立たない: チーム外からチームへの口出しの調整
        • 別チームへの引き抜き(借り出し)へのNG出し、とか
      • 役に立つ: スプリントレビューにステークホルダーが出席
    • スクラムマスターにはチーム中に閉じないことが求められている
    • やったことない人にこれ分かる?
      • 多分読めてない、内容が入ってこない
      • そもそもスクラムガイドが読みづらい
        • 最初の想定として議論を前提としているのかもしれない
        • SECIモデルの第3段階にあたる?
      • どうすればスクラムは分かる?
        • 気合?w
        • スクラムを回すことで学ぶ、経験主義
          • 旅行ガイドブックを読むのと旅行に行くのは違う
            • 「ゲームのルール」という記載を思いだした

スクラムマスターはプロダクトオーナーを支援する

  • これアジャイルコーチじゃない?
    • その側面もある
    • そうだよなあというところ
  • POを支援するという割にはPOのことがあんまりガイドには書いていない
    • どちらかというとチームを向いている?
    • 忙しいPOの存在を考えると、1行目を果たすのすら難しい
      • POを後押し、引っ張る役目としてのSM
  • SMはPOの経験ないと無理では?
    • なくてもいける気がする
      • POはプロダクトバックログの価値の最大化が仕事だが、そこには触れていない
    • スクラムガイドに求めている水準が高いのかも
  • 「価値を最大化するためのプロダクトバックログの調整方法」って具体的には?
    • ROI最大化するためにバックログの並び替えする、とか
      • 並び替えの軸を複数持つとよい
      • 価値を自分たちで定義して、それに向かうことが大事
    • ストーリーの書き方とかは入らない?
      • 顧客に価値が向いていないとき、とか
        • 並び替えても幸せにならないパターン
      • 中身は稚拙でも顧客と調整ができれば十分なのでは?
  • POと開発チームは対等であるべき?
    • チームとPOとSMが対等だといいよね
    • 「サーヴァントリーダー」という語の響きと対等というところがちょっと合わない?
      • 「Management 3.0」の2.0に相当
      • 人に依存しないでシステムをマネジメントする

スクラムマスターは開発チームを支援する

  • SMやること多いw
    • スクラムイベントのファシリテートくらいでしょ、と思っている人もいる
    • SMをやった人が読み直すといいかも
  • スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。」
    • 完全に理解するとSMは不要と言っている気がする
      • SMの理想形
  • 「必要に応じてスクラムイベントをファシリテートする。」はPO支援にもチーム支援にも書いてある
    • 開発チームだけのイベントもあるからでは

スクラムマスターは組織を支援する

  • 段階が上がってきている、SMとアジャイルコーチの差がない
    • チームに紐付いているかどうか?
    • スクラムがない状態を前提としている気がする
  • 「組織へのスクラムの導入方法を計画する」これを出来るレベルの人がスクラムマスターをするってことですか?
    • そうです笑
      • 誰が初っ端できるんだよw
    • しかし、これができない人が最初に導入できるかというとNOでは?
      • 人を巻き込むとか、チームとしてそれをできる能力を有している
    • 導入計画ができるようになっておいた方がいい
      • 他のチームに伝播できない場合、そのチームが危ない
    • 各アイテムにレベリングがほしい
      • 初心者に求めるのはやりすぎ
  • ちなみにこのリストって抜け漏れはない感じですか?
    • 抜けも漏れもありそう
      • ただ日本基準なら完璧w
    • 最低限を書かれている
    • TDD/CIは開発チームを支援するに包含されているとも取れるのでは?
      • ガイド側の抽象度が高いw
    • 「できてない事を自己認識し続ける事が必要」
      • できていないのを探すのは難しいので、自分から探しに行く、学習し続ける方向

#ふりかえり実践会「スクラムガイドを読み解いてみよう」第2回のまとめ

7/19(日)に開催されたふりかえり実践会スクラムガイドを読み解いてみよう」の議論をサクッとまとめました。 retrospective.connpass.com

スクラムガイドはこちらからJapanese版をDLください。

スクラムの理論

  • 経験主義大事
  • 経験主義の対比は?
    • 予測主義
    • 計画主義(ウォーターフォールとの対比として)
      • 「いわゆる一般的なプロジェクトマネジメントは計画が予定通り進むと信仰している」
        • 信仰はキリスト教由来?笑
          • 「人月の神話」みたいな神話めいたものから来てるのかも
  • 「反復的かつ漸進的な手法」という表現について
    • 経験主義だから、予測可能性を最適化する
      • 予測できないもの、見えないものを見えるようにしていく
    • 初期のアジャイル帰納と演繹の対比で語っていた気もする
      • 結果から見るか(帰納)積み重ねで見るか(演繹)の違い
  • 「リスクの管理を行う」という表現について
    • アジャイルは「来たとこ勝負でやる」と勘違いされがち
      • 「予測可能性を最適化し、リスクを管理する」とちゃんと書いてある
      • OODAもそう
        • PDCAのように回るわけじゃない
    • ジェフ・サザーランドが元軍人なのに由来しているのかも

透明性

  • 透明性のこういうところ大事だよねってある?
    • 人間関係の透明性、働く人の透明性
      • よくわかんない人とは働きづらい
      • 腹の底がわかんない人はキツい
    • 英語ではTransparency
      • 心の内をオープンにするという意味もある?
        • Opennessに入るかも
    • 透明性とは「情報が一箇所に集まっていて、誰でも取りにいける状態」
      • 透明性、検査、適応は全部状態
        • それを担保するためにスクラムは設計されている
      • 情報が一カ所に集約され.次の行動が自然と誘発されること。
        • ツールに依存しない方法を模索しながら透明性を高めていく
  • 結果責任を持つ者」とあるが、誰のこと?
    • お金を出す人、プロダクトのドンのことでは?
      • ROIに対してスクラムチームを雇っている、決済者と言う
      • 全てが見える状態にしておかないと投資してくれなくなる
    • 大きなところと小さなところがあるのでは?
      • プロダクトのドンというのは大きなところ
      • 例えばチーム内では開発者はPOに対して見える化する必要があるように、小さなところでも言うのかも
  • 「透明性って大事だよね」って皆言うけど、「透明性があるってどういうことか?」が結構ブレがち
    • 透明性が大事だって言う人ほどドキュメントを書かないとかあるある
    • 透明性とはこれです、ってのは言いづらい
      • アンチパターンは言いやすいけど…
      • 真の透明性は、見えない状態?
        • 意識して見ている状態にあるという時点で透明ではない
        • 「〇〇さんの情報にアクセスする」という時点で違う、「チームの」が主語になる状態こそが透明性のある理想状態
          • 例えば、新しい人が入ってきたときに「ここ読めばわかる」というのは透明性があると言えるのか?
            • どうやってジョインさせるかというプロセス自体もなんとかできるはず
          • 「健康だ健康だ」という人は健康ではない
        • 見える化は人を殺せる」
          • 過剰な透明性の意識は精神攻撃化しうる
          • 心理的安全性が大事だと言って⇢強制自己開示運動がはじまる、みたいな事例も見聞きする
        • 「チームの」透明性というところが大事
          • 普遍的な透明性を追い求めると神の領域に至る笑
  • スクラムでの「標準化」ってなに?
    • 皆がこうだよね、っていう共通認識取れているということ?
    • a common standard
      • 常識になっている、共有されている?
        • ワーキングアグリーメント、Doneの定義とかに近い?
        • ステークホルダーに対しての説明
          • 自分たちのチームを取り巻く境界の外にどうアプローチをするか
          • 説明するというのは標準化のひとつ
            • 自分たちの活動でこういうことをやっています、というのを対外的にアピールする
            • アジャイルとりあえずやってみよう⇢まわりが冷めてて結局ポシャるってよくある話
              • そのときの肝は透明性
                • 興味を持ってくれる人を巻き込んでいく

検査

  • 「スキルの高い検査担当者」って何?
    • スクラムマスター?
    • QAとはまた違う文脈のはず
      • テスト的な検査は一部分にすぎない気がする
    • 検査の対象が違うのかも
      • プロセスはスクラムマスター
      • プロダクトはQA
      • この文脈ではどっちも?
        • 作成物はQAっぽい、スプリントゴールはPOなどな気がする
    • 「検査する人のスキルが高かったら検査は効果的」と言いたいのでは?
      • 検査するスキルというのが存在する、と言いたいのかも?
  • 「頻繁にやりすぎて作業の妨げになってはいけない」も大事
    • 検査はtestではない、inspect
    • ふりかえり、スプリントレビュー、リファインメントといったイベント以外の部分は作業に集中
  • スクラムフレームワークなのでユーザという表現を使っている
    • 3つのロールだけじゃなくて周りも含めてユーザ
    • スクラムは使うツールだという意識も大事
  • 「検査担当者には」チームメンバーの誰もがなり得て、誰でも同じ検査ができることが理想か?
    • 理想ではあるが、はるか遠い理想
    • 皆が同一の視点をもって検査するのは危ない
      • 別々のやり方でよい
      • チームとして最適な形になればよいのでは
      • 一方でスキルセットとして全員が同じことを実現できること自体はOKな気がする
    • 皆が同じ検査ができる状態をあえては目指さないかも?
      • 通過点としてはなろうとした方がいいが、ゴールにはなっていけない気がする
      • あくまでチームが同じ検査ができることが大事な気がする
        • チームとして同じレベルを担保できれば、AさんとBさんの持っている検査のスキルセットが違ってもよい
  • デイリースクラムは検査イベント
    • スプリント自体も検査と適応イベントと認識していた
  • スクラムの中でロールが分かれているが分かれていることの意味合い
    • 「境界はちゃんと考えておけ」
    • 越境の精神は大事だけどスクラムの中では過剰にやりすぎない
      • 人数の問題で、プロダクトじゃなくてチームの方向を向きやすくなる
      • POのようにビジネス的視点は必要、DBスペシャリストのような技術特化型スペシャリストとかはいらない
    • 個人のスキルセットとして開発・PO・SMどの振る舞いもできるというのはOKだが、チームの中で一人が全部を兼ねるのは違う
      • 役割を分けないと議論できないこともある
        • 対立構造がいいものを生むこともある
        • ビジネスと開発のバランス
        • SCRUM MASTER THE BOOK」を読んでください笑

適応

  • 「許容値を超えた時点」では遅くない?
    • そもそも許容値を持つ?
      • 持つ気がする
      • スクラムの中で実験をするが、どこまで遊ぶかを決めておく
        • 許容できる失敗ってどこまでかっていうのは置いておくべき
        • リリースまでのスパンまでのどこまでに気づけるかを許容値とする
  • 手既往していないもの、の逆を取っている?
    • 適応されていない状態というのは?
      • 立ち止まらない、デイリースクラムをしていない
        • 例: スプリントレビューギリギリでスプリントゴール達成できないと気付く
        • 例: ウォーターフォールでテスト段階で仕様決まってませんでした
      • スプリントレビューで叩いていない
        • 結果 : 言ってたことと違うことが起きる、緊急MTGが増えていく、リリースしたあとに気付く、施策が外れまくる
    • 忙しい、うちは特殊、わからんの3つは三大パワーワード
      • わからんは勉強すればいいけど、前半2つは厳しい
      • スクラムにプラクティスとかない笑
        • 「うちは特殊」という人ほど一般を知らない
          • 何と比べてるの? 笑

お知らせ

次回は8/1(土)。無言キャンセルが多いため次回より参加費100円徴収するそうです。
行けないときはちゃんとキャンセルしましょうね!

#ふりかえり実践会「スクラムガイドを読み解いてみよう」第1回のまとめ

7/4(土)に開催されたふりかえり実践会スクラムガイドを読み解いてみよう」の議論をサクッとまとめました。 retrospective.connpass.com

スクラムガイドはこちらからJapanese版をDLください。

表紙

スクラムガイドの目的

  • artifactsの訳が成果物じゃなくて作成物
    • 「価値を届けるもの」にフォーカスしているという違いがある?
  • 複雑なプロダクトって書いてあるのがクネビンフレームワークに通ずる
    • カオス・簡単な問題より、複雑な問題に強い

スクラムの定義

  • プロジェクトではなくプロダクトという表現を使っている
    • プロジェクトははじまりとおわりがある(有期性)
    • プロダクトには期限がない
      • 市場でプロダクトを少しずつ育てていく、期限が見えないからプロダクトと言っている?
      • プロダクトにも終わりあるよね?プロダクトライフサイクルとか…。
        • 作ってるときはあまり意識しない
    • プロジェクトマネジメントとプロダクトマネジメントは違ってくる
    • プロジェクトは動き、プロダクトはもの
  • 可能な限り価値の高い創造的な」、という表現について
    • スクラムだから絶対的に成功するわけではない
      • チームのポテンシャルの最大値を超えることはない
      • スキルのない開発者が集まっても仕方ない
    • 「可能な限り」という表現には万人に届く普遍的な価値はないという意味でもある?
      • ターゲット以外には響かない、価値とならないことも
  • 「理解が容易、習得は困難」という表現について
    • 実際やったら難しい、今でも理解できた実感はない
    • 容易な理解とされているが、理解ってどういう意味なんだろう?
      • スクラムマスターという仕事は経験則を売っている
        • コアのところまでは容易に理解できないのでは?
      • 英語では"simple to understand"
        • 意味を知っていれば理解している、と言える
        • 容易というよりはシンプル、というところなのかもしれない
  • 18ページという少なさで、"わかった気にさせる"のはすごい
  • スクラムは1990年代初頭から」なんだね…
    • スピーカーさんたちはスクラム世代とも言えるw
  • 「決定的な方法論ではない」ことを自認しているのがよい
    • このガイド自体も更新されている
    • 悪い意味で「仕事として」スクラムをしている人も増えているが、"スクラムの決定版!"とか言うのはダメw
  • さまざまなプロセスや技法を取り入れることのできるフレームワーク」という表現について
  • スクラムは、(中略)プロダクト・チーム・作業環境の継続的な改善を可能にする。」という表現について
    • プロダクト・チーム・作業環境は優先順位順?
      • 順位感はあんまりない、三位一体感の方がある

スクラムの用途

Page 3

  • この項は2017年版から入って、昔はなかった
    • プロダクト開発以外で認知され始めたから?
      • 2014年くらいからスクラム人事とか言われだした気がする
    • あくまでプロダクト開発論だよって言いたかった?
      • 逆に「保守・刷新」や「新規開発」・「インフラ」にも使えるよっていいたかった?
      • eduScrumとかからの流れ?
      • サービス開発ってプロダクト開発に含まれる?
        • SaaSのことなら入る

Page 4

  • 自動運転、学校教育とかちゃんと書いてあったw
  • 「開発する」はITエンジニアが単純に想像する開発だけではない、と言っているのが良い
  • スクラムが何に向いていないものが欲しくなる
    • 階層的な組織、ティール組織で言うレッド・オレンジには向いていないかも
    • 本質は「少人数制のチーム」というところにある
      • 小さなチームをまとめてでっかくしていく、LeSSScrum@Scaleとかでもそう
        • 100人で1チームとかはやっていない
        • コミュニケーションパスの問題
  • 先程までのプロダクトへのこだわりはどこへいった?w
    • 経緯としてプロダクト開発があったが、広がったと見るべき?
    • そもそもプロダクトってなんだ?
      • 自動車だってプロダクト、料理や消費財、教育だってプロダクト
      • 生産的で創作的なもの
  • たとえば建築でもスクラムやってそう?計画の権化に感じるが…
    • 街づくり、都市設計とかは数年ものだしプロダクト感ある
    • 家でもそのまわりの木が変わったり、建築資材が変わったりする
      • それは施主に言えw
    • ソフトウェア開発でも意図せずバグ仕込んだりもする
  • ハードウェアだとスクラムが向いていない気もする
    • 向いているハードもあるのでは?
      • 3Dプリンタでプロトタイピングとかは最近できるようになってきた
        • 昔よりは楽だが、組み込みではシミュレーションで想定してなかったことも起こる
          • だからこそスクラムでもできるよなとも思うが
    • ロットが決まっちゃってるときがあるから
    • 作るものの複雑さで変わるのでは?
      • 例えばマスクの大量生産はスクラム開発しない、新しいマスクを作るならスクラムを使うかも
        • 製品が複雑か簡単か
        • やはりいつ量産するかのタイミングで決まるのじゃないか
          • Doneの定義で語られるかも

やぼ、(また)ブログやるってよ。

こんにちは、三日坊主を超越して3秒和尚と化したやぼ(@yaboxi_)です。
以前にもブログを作成したのですが、今年の2月に1つだけ投稿をしたあと180日間放置しました。
そのブログに続けて書いてもよかったのですが、
心機一転、前のブログをスクラップして新たにブログを作りました。

今年4月にSET(Software Engineer in Test)的職種に社内転職をし、
それ以降少しずつではありますが外部のITイベントにも参加しています。
このブログではそれらのイベントで得られた知識を発展昇華していったり、
また思考の備忘録的なものも記載していければと思っています。

それでは、対戦よろしくお願いします。