システム開発(アジャイル・スクラム)とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

アジャイルスケーリングの手法(SAFe®︎編)

はじめに

こんにちは!
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

アジャイルスケーリングの手法、色々ありますよね。 各手法について意見を聞くことがあるのですが、不勉強なせいで自分の言葉で良し悪しが説明できなかったり、 ざっくりかつ良い感じにまとめた記事があまり見つからなかったので調べたメモです。

今回はSAFeについてです。


SAFeをざっくりと理解する

SAFeとはなにか

SAFeとはScaled Agile Frameworkの略で、いわゆるアジャイルスケーリングの手法の1つになります。 こちらのサイトによれば

世界で最も活用されているビジネスアジリティ実現の基盤となるフレームワークがSAFe®です。SAFe®は、リーン、アジャイル、DevOps の原則、プラクティス、コンピテンシーを組み合わせた実証済みのフレームワークです。役割毎の教育カリキュラムが用意され、グローバルのパートナーネットワークとコミュニティでビジネスアジリティ実現を支援します。

とあります。うーんよくわかりませんね。TDCさんのサイトの方がわかりやすい。

SAFe® (Scaled Agile Framework:スケールド・アジャイルフレームワーク)とは、Dean Leffingwell 氏が中心になって開発したエンタープライズ向けアジャイル開発・ビジネスフレームワークであり、企業規模でのリーン・アジャイル開発を実現するために必要な、役割や責任、行動に関する考え方が体系化されたナレッジベースです。

SAFeは、複数のアジャイル・チームの意見調整、共同作業、デリバリーを同期させることが可能です。拡張性と柔軟性に優れたSAFeは、企業独自のビジネスニーズに合わせることができ、少人数によるソリューションから、構築と導入に数百人、数千人を必要とするエンタープライズシステム構築まで対応できます。

ざっくり言えば、SAFeは色々な書籍やXP、スクラムといったアジャイル開発手法等からナレッジをまとめて体系化したもののようです。

どんな組織が導入しているのか

少し調べたところ、国内だとNTTデータとか上記のTDCなんかが出てきますね。 国外だとCapital OneとかAmerican Expressなんかが導入事例として紹介されています。

www.scaledagile.com

普及率は高いらしい

どこまで信頼のおける指標なのかは存じ上げないですが、State of Agile Reportによると、アジャイルのスケーリング手法としては35%と一番割合が高いようです。

stateofagile.com


もうちょっと具体的に知りたい

Big Picture

こちらのサイトにビッグピクチャという一枚絵があり、全体像が俯瞰できます。(タブをFull SAFeにしてください)この画像からざっくり理解を進めていきます。

原理原則

濃いグレーの下部にさまざまな原理原則が記載されており、例えばリーンアジャイルの10の原則などについて書かれたりしています。

組織チームの役割

左側のグレーの人型オブジェクトの部分が組織チームの役割が記載されています。後ほど紹介する動画では各人の役割が明確に定義されているとのことでした。

それ以外の部分

組織チームのプロセスについて記載されています。スクラムとかカンバンとか見慣れた用語もありますね。

SAFeの進め方

AgileReleaseTrainとは

SAFeではAgileReleaseTrain(以下、ART(アート))という、既存の縦割り組織とは別の仮想組織を構成します。人数は50~125人で、複数のアジャイルチーム、及びそれを支援するチームで構成されます。Trainとあるように電車を模しており、それ以上の人数の場合は電車の数が増えていくようです。

ARTでどうプロセスを進めていくのか

以下の5つのイベントを繰り返します。

  • PI Planning
  • 状況把握と決断
  • システムデモ
  • 次に向けての準備
  • 振り返り

これがART全体の動き、個々のアジャイルチームはスクラムで仕事を進めるようです。

PI Planning

これがSAFeの特徴っぽいのですが、PI Planningという、ART全ての利害関係が集まるイベントがあります。行うこととしては、マネージャ等が最低限の制限とともにミッションを作成、チームが責任を持って直近3ヶ月のプランを作成するなど。関係者が近い位置にいるので色々決めやすい。


SAFeを組織内で拡大させるために

Implementation Roadmap

インプリメンテーションロードマップと呼ばれる、組織でSAFeを拡大するためのロードマップ、そしてフェーズ毎に必要なトレーニングがまとめられています。

www.scaledagileframework.com

レーニングについてざっと紹介。

スタートポイントフェーズ

要は導入フェーズですね。Leading SAFeというトレーニングを受講する。 社内の推進リーダー、つまりイノベータ向けの全体像理解トレーニング。

ART開始前フェーズ

全体像を理解している人を増やすためにより多くの人を巻き込みLeading SAFeを受講する。 他にはSAFeプロダクトオーナーやSAFeスクラムマスターといったもの、SAFe for TeamsというART発車前に全員が受講するトレーニングもあるようです。

複数のARTを作るフェーズ

要は拡大期。いくつかの専門的なトレーニングが用意されており、SAFe Advancedスクラムマスターなどがあるようです。

動画で観たい方

こちらのサイトをどうぞ。

www.tdc.co.jp

最後に

何かコメントや誤りがございましたらコメントください。 次はLeSSかなー。

Agile Testing Condensedを読んだ

はじめに

こんにちは!
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

今回は『Agile Testing Condensed Japanese Edition』を読みました。 先日のRSGT2021でも講演もしてましたが、アジャイルテスト界隈で有名なJanet GregoryとLisa Crispinの書籍を日本語訳したものになります。 訳が原文に忠実なので読むのに時間かかるのと、 Condensed≒凝縮とあるように内容が詰まっている分、前提知識がないと少し理解が難しい部分があるかもしれません。


日頃QAについて感じていること

QAチーム

WF的文脈のせいか、QAチームと聞くとゲートキーパー的なイメージが先行する方もいるかもしれません。しかし、アジャイルにおけるQAとはそうではなく、開発者達とOneチームになり、継続的なテストによってプロダクトを成長させていくことが重要だと考えています。開発者(や場合によってはPO)がテストをするスクラムチームだと当たり前じゃんと思う方もいるかもしれないのですが、従来型のイメージが先行したりするせいか、本書でもチーム全体で品質へ責任を持つことについて何度も書かれています。

具体的なQAの開発体制について

理想論を言うと、QAの能力を含めた1チームを編成するべきで、QAチームといった職能的なものは存在させるべきではないと思っています。ただ、現実問題として、俯瞰してプロダクトを見る立場がいることによって開発のサイクルが上手く回ることもあるので、開発期間が半年以上に及ぶような多少大きいプロダクトとかであれば、必要とされてくるのかなあと。

なので、小さいプロダクトであればQAのノウハウを持つT型人材がいるチームを構成すべき、中規模以上であれば開発者とは別にチームを編成しそこでスクラムを回す※1が現状のベストプラクティスなのではないのかなとは個人的に感じているところです。

※1)ブロッコリーさんがどこかでまとめてましたが、開発中のスプリントではQAチームはテスト設計し、その直後のスプリントでテスト実施するやり方等を想定して書いてます


書籍の感想

前提知識的なもの

一部解説されてますが詳細に書かれている訳ではないので、事前に以下の知識があったほうが良さそう。

アジャイルテストの四象

縦軸にビジネス面<->技術面、横軸にチームを支援<->製品を批評を取るものです。 例えばUnitテストは技術かつチームを支援するので左下のQ1に入るなどといった分類ができます。

DoDを決める際に、こういった可視化されたものがあると認識合わせがしやすいかもしれません。

qiita.com

テストは生きたドキュメント

定期的にメンテナンスされ続けるものなので今をうつす仕様となる。

テスト専門家が学ぶべき内容

協調、ファシリテーション、教育、コーチング、コミュニケーションのスキルが必要。 これはテスト専門家だけでなく開発チームやSMなどにも当てはまりますね。

最後に

パワポでみたい方は以下にまとめられています。 speakerdeck.com

書籍の購入はこちら leanpub.com

エラスティックリーダーシップを読んだ

はじめに

こんにちは!
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

今回は『エラスティックリーダーシップ: 自己組織化チームの育て方/ロイ・オシェロフ』を読みました。 部下を育てたい気持ちはありつつも押し付けになってしまってはとか、なかなか言ったことを実践してくれないとか、 リーダーやマネージャーでなくとも少し年次が上がってくると多少なりとも悩んだりする瞬間があると思います。

この書籍ではエラスティック、つまりチームに応じて変化する弾力性のあるリーダーシップの在り方について書いています。 抽象化と具体化の例がわかりやすく、こういった本をあまり読んだことない方でも取っ付きやすい内容になっています。


最初にフェーズとモードのはなし

本書ではフェーズとモードという用語が使われています。 フェーズとは簡単に言うとチームの状態のことで、モードとはそれに対する反応のこと。 モードの説明が当初わかりづらかったのですが、闘争本能のようなものだと。例えば敵が迫っているような状態(フェーズ)だと、 闘争本能によって行動したりしますよね。このようにあるフェーズだと認識すると呼び起こされるものという解釈でいます。


チームの3つのフェーズ

チームには、サバイバル、学習、自己組織化の3つのフェーズが存在します。 サバイバルから学習、自己組織化へ、そしてフェーズによってリーダーシップのスタイルを変えて導くのがリーダーの役割。

この書籍では一番スキルが長けているスーパーマン的人をリーダーの前提として置いているので、 「スキルを身に付けるには新しいことに挑まなければならない。自分で解決してしまえば学ぶのは一人だけになってしまう」と警告したりしています。

サバイバルフェーズとは

響きだけ聞くと炎上プロジェクトのように感じますが、 このフェーズではチームの学習時間がない状態のこと。 ゆとり(Slack)を作り、サバイバルから脱することを目指す。

学習フェーズ

ゆとりの時間があり、その時間で学習や検証を行っている。 問題を自力で解決できるように教え、挑戦させることで自己組織化チームへと育てる。

自己組織化フェーズ

リーダーが数日仕事を放棄できる状態であれば、チームは自己組織化しているといえる。

それぞれに合わせたリーダーシップ

サバイバルでは、指揮統制型のリーダーシップを取る。学習フェーズでは、コーチ型だが場合に応じて指揮統制型を使い分ける。 自己組織化では、ファシリテーター型を。


バス係数とバス因子

これは有名な話ですが、バスに轢かれてメンバーが来なくなったときに、 何人いなければチームが破綻するのかという数をバス係数と言います。(つまり高ければ高いほど良い) バス因子とは、バス係数となるメンバー名や役割のこと。


コミットメント言語

やりますという宣言をコミットメント言語と表現。 バグを修正しますとか制御できないものに関しては、1日に何時間バグ修正に取組むとか、 不可能なコミットメントを可能なものに変えること。 デイリースタンドアップやその他約束がなされる場所でこの言語が使われる。


メンバーの成長

学習フェーズ

成長には波がある。グラフで言えば、高原があり、谷(成長前の適応期間的なものだと理解)、峰というのを繰り返し右肩上がりに成長していく。 まっすぐな線で成長するわけではない。

メンバーに対する問い

コーチング的な内容だが、『あなたはそれに関して何をするつもりですか?』と問う。 これは「(私ではなく)何々すべきです」とか自分でやらない回答とかではなく、抜け道のないものを引き出すことができるので良いとのこと。

全く話変わりますが、コーチング学んだ人ってあんななんで?って聞き続けるんだろ、、 コーチングおじさんではなく上手く話を引き出すスキルが必要ですね。

どういったものがチームや個人を成長させるのか

真の成長機会は、恐怖・初期の不快感や不満があることであると言っています。 一瞬ウッと感じるような取り組むのに勇気のいるものが人を成長させるということですね。


リーダーがやるべきこと

バス因子とペアワークや教師になってもらうなど、因子を見つけ、防ぎ、減らすことが担う役割の大部分。 あとはサバイバルから学習フェーズでは50%はチームと話たり作業したり多くの時間を過ごすこと。


クリアリングミーティング

クリアリングミーティングというワークというか手法について紹介がありました。 ① 今週もっと上手くいったらよかったこと(上手くいかなかったこと)、 ② あなたはそれに関して何をするつもりか、 ③ 今週起こったよかったこと・メンバーがしたよかったことについてそれぞれメンバーに聞いていく。 具体的な場面での例がありましたが、①を各メンバーに聞いて、その後②〜③の順に聞いていく。長くなるからと割愛したりせずに傾聴。


キーワードや心理学っぽい用語


さいごに

気になった方は是非書籍をどうぞ。

今さらジェフサザーランドのスクラムを読んだ

はじめに

こんにちは!
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

よく本屋さんで見かけるグレーの表紙の『スクラム:仕事が4倍速くなる“世界標準”のチーム戦術/ジェフ・サザーランド』を読みました。 スクラム始めて2年くらいになりますが、背景理解的な意味で復習した方がいいかなってことで再読メモ。


へえって話

  • ヘンリーガントがガントチャート考案したのは1910年代らしい(100年以上経っとるものを未だに使っている現代社会)
  • スクラムの透明性については、コロラド州議会で導入を進めていたサンシャイン法(会議公開法)から影響
  • プロダクトオーナーの発想は、トヨタのチーフエンジニア(例えばカローラとかの生産ライン全体の責任者)から。 人事とかの権限はないが、ビジョンやどう造るのか責任を持つ。


ハイパープロダクティブ

ハイパープロダクティブ、直訳すると『超生産性』。 サブタイにもなっているが、この書籍ではスクラムを導入することによるスピードについての記述が多い。 主体性を持ったチームが障害を取除きつつ開発をすることによって仕事が4倍早くなる。

個人的にはスクラムは現状を見える化するのに特化したフレームワークアジャイルになる目的は変化への適応が 一番しっくりきており、スピードは副次的なものかなあってところだったので、強調ポイントにギャップはあったり。


トヨタ生産方式とか日本の製造業とスクラム

お馴染みかと思いますが、スクラムは日本の製造業から大きな影響を受けています。

ただ、その影響を与えた日本企業はW・エドワーズ・デミングというアメリカの統計学者から 学んだという話は皮肉ですね。問題の解決には後からではなく、問題を発見したその場で当たるのが ベストという考え方が根底にあるなどと紹介されていますが、トヨタ生産方式について断片的な知識しかないので、 そろそろ大野耐一氏の書籍を読みたいところ。


幸福

仕事では幸福こそ大切、幸せであればいい選択ができる。 想像力を発揮、仕事を辞めず大きな成果にも手が届く。 人は成功したから幸せになるのではなく、幸せだからこそ成功すると。

鶏と卵みたいな話は置いておいても、 このあたりの正のループが循環させたい!って思いで仕事したい。

チームのメンバーを幸せにする要素は主体性、スキルアップ、目的意識。 スクラムちゃんとやっていると勝手にこの要素ついてくるの本当すごいなって改めて思った。

ちなみに幸福のバブルという、成功したチームが改善しなくていいのでは?となり、 現状に満足する赤信号なので注意。 スクラムマスターを『賢い道化』と表現してましたが、誰もそこに触れなければ、 気付きを与えて導く役が重要であると言っています。


レトロスペクティブ

シンプルに進め方で変えられるところはないか、仕事を進めるうえでどこが一番の難関か、 という2点を聞くのが良い。なんか最近色々なふりかえりのフレームワークをやっていましたが、 ベースはここなんだなあと。


キーワードだったり出てきた心理学っぽい用語


さいごに

気になった方は是非書籍をどうぞ。

今さらエクストリームプログラミング(第2版)を読んだ

はじめに

こんにちは!
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

弊社では、スクラムにXPのプラクティスを導入して開発を行っています。XPについては、断片的に知識はあったものの、体系的に理解できてなかったということもあり、改めて勉強してみました。

読んだ書籍は、『エクストリームプログラミング(第2版)/ケント・ベック(Kent Beck)、シンシア・アンドレス(Cynthia Andres)』です。日本語訳は角征典さんですね。今回第2版を読んだのですが、第1版とかなり違うようですので、改めて読んだりするもの良いかもしれません。なお、本記事はただの読書メモです。


XPとはなんなのか

建築家のC・アレグザンダーによる、パタンランゲージという知識記述の方法があります。それに触発されて、ソフトウェア開発における「パターン」をまとめ、著者のケントベックらはエクストリームプログラミングとして提唱しました。本書でもフォースなど、パタンランゲージの表現が出てきたりします。

XPには価値と原則、プラクティスという3つのキーワードが出てきます。


XPの5つの価値

XPでは5つの価値について述べています。

  • コミュニケーション
  • シンプリティ
  • フィードバック
  • 勇気
  • リスペクト

上記価値はそれぞれ独立したものというよりは相互的に作用します。比較的言葉の通りな感じですので、詳細知りたい方は、書籍をどうぞ。


XPの原則

  • 人間性
  • 経済性
  • 相互利益
  • 自己類似性
  • 改善
  • 多様性
  • ふりかえり
  • 流れ
  • 機械
  • 冗長性
  • 失敗
  • 品質
  • ベイビーステップ
  • 責任の引き受け

価値とプラクティスのギャップを埋めるものが原則です。

価値は抽象的すぎるため、プラクティスを実施する指針にするためのものと理解しています。 「否定的な感情に耳を傾ければ、新たな知見の源泉になる」というのは最近イライラしがちだったので自戒。


ラクティス

ラクティスには主要プラクティスと導出プラクティスの2種類があります。

主要プラクティスは無関係に役立ち、安全に始められる。導出プラクティスは主要を習得してから導入すること。つまり、基本的な主要を守ってから導出を始めようねと言っています。

主要プラクティスは以下の通り。

  • 全員同席
  • チーム全体
  • ストーリー
  • 週次サイクル
  • 四半期サイクル
  • テストファーストプログラミング

少し触れると、テストファーストプログラミングはロジック本体を修正する前に失敗するテストを書きましょうとか、週次サイクルは週次で仕事を計画しようとかそんな感じです。 スクラムでは具体的な開発方法については言及していないので、前者は導入できたりするかもですが、後者は少し被ってくる部分だったりしますかね。

導出プラクティスは以下の通り。

  • 本物の顧客参加
  • インクリメンタルなデプロイ
  • チームの継続
  • チームの縮小
  • 根本原因分析
  • コードの共有
  • コードとテスト
  • 単一のコードベース
  • デイリーデプロイ
  • 交渉によるスコープ契約
  • 利用都度課金

こちらも少し触れると、デプロイまでの期間をなるべく早く、デイリーでデプロイしようとかの考え方を言っています。主要を先に導入せよと言っているのは、テストファーストプログラミングなど、品質を高める活動をしないうちにデイリーデプロイすると失敗するから、そう言った理由になります。

また、ラクティスは組み合わせることで効果を増幅させます。


3つのキーワード

価値は抽象的なので原則という指針を持ってプラクティスに向かう。(実施する)

さいごに

気になった方は是非書籍をどうぞ。

自己紹介

初めまして、ブログ始めました

おはようございます、こんにちは、こんばんは。 daimyoと申します。

普段は某金融機関でシステム開発をやっており、 スクラムマスターや開発チーム(エンジニア)として働いております。

ブログ始めた経緯

まあなんてことないのですが、 日頃本を読んだり、勉強していることが多いのですが、 せっかくインプットをしているのにアウトプットしないともったいないと始めた次第です。

あとは、前職でもシステム開発の仕事をしていたのですが、 その頃と比べると今イキイキ開発しているなあと感じています。

それはアジャイル開発故の楽しさだったりがやっぱりあるので、 その辺を広く伝えたりできたらいいなあと。 開発の現場ってピンからキリまで色々あるのでキャリアで迷っている人もいると思います。 そういう人の助けにもなったらいいですね。

さいごに

ということでこれからよろしくお願いします! 気になった方がいればブックマークや下にあるスターとか押してくださると励みになります。