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

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

Scrum Fest Niigata 2022@Day1終了後の雑談会のはなし

はじめに

仕事と育児でDay1参加できなかったんですが、おうちで日本酒を飲みながら雑談会からDiscord参加。 つくづく自分の圧倒的知識量のなさに辟易しましたが、オンラインも学びが深かったので酒で流れる前にまとめます。

フレームワークについて

スクラムやっててフレームワークという単語に慣れていたのであんまり深く考えたことはなかったですが、例えば人事の人とかにフレームワークってなに?っていうのを伝えるのが難しいみたいな話をしてました。

「制約を課すことで自由を手に入れる」みたいな話が印象的で、その考え方はなかったなー。 あとはこのあたりの本のはなしとか。

Amazon - 正統とは何か | ギルバート・キース・チェスタトン, 安西 徹雄 |本 | 通販

当たり前は変わる

狩野モデルの当たり前品質のはなしから、当たり前は時代によって変わるみたいな文脈からノーマライズのはなし。

ある事象に対して、一般的な出来事として承認する意味づけを、心理学では「ノーマライズ」(「丸つけ」)といいます(若島,2018)。

note.com

ORSC

最近受けたという話をよく聞くORSCのはなし。 某アジャイルコーチの書籍がORSC要素強いらしく、もうちょっとコーチング学んだら受けてみたいなー。

あとはこのあたりでふりかえりのはなしとか、あんまり見かけないソースとか紹介してもらった。

www.goretro.ai

www.infoq.com

4つの毒素

関係性を阻害する要因は「非難」、「防御」、「侮辱」、「逃避」の4つあるとのこと。 逃避しがち、、

kao-space.com

正しくやるのと効果が出るのは違う

これはこの通り、だけど正しくやるのを追求するのも重要。 スクラムもそうだと思いますが、目的を考えるのと、やり方を変えるなら目的からずれないようなものなのか考える。

毎回Terraformのmoduleの動きを忘れるのでメモしておく(Azure)

はじめに

インフラタスクって初期にどかっときたり、スプリント毎に小出しに出てくるのでしばらく触ってないと毎回リセットされて困っているのでメモっときます。

普通の書き方はドキュメント見ればってことで、普段使っているmoduleについてです。

ざっくり概要

moduleとはリソース単位でテンプレを作って、そこに変数を渡してあげることで汎用的に使い回せることができる便利なやつです。

DevelopとProductionでSKU変えたいとか、環境毎に差分が発生するようなケースで便利です。

むっちゃ簡単に解説するためにリソースグループとストレージアカウントだけ作ってみて、moduleとoutputの動きを確認します。

解説

ソースにコメント載っけながらの方がイメージしやすいのでそうします。

main.tf

module "resouce_group" {
  ## sourceでmoduleというかテンプレート側の場所を指定 
  source = "../modules/resource_group"

  ## 左辺にはテンプレート側のvariableの引数名と同一名称を指定、
  ## 値を渡さなければテンプレ側のdefaultの値が使われるので、
  ## ここで渡すと上書きされるんだな〜という認識でOK
  resource_group_name     = var.resource_group_name
  resource_group_location = var.resource_group_location

}

module "storage_account" {
  source = "../modules/storage_account"

  storage_account_name             = var.storage_account_name
  ## outputの指定方法はmodule + 『module "XX"』のXX(ここならmodule "resouce_group" のresouce_group)+ 『output "YY"』のYY
  resource_group_name              = module.resouce_group.output_resource_group_name
  storage_account_location         = var.storage_account_location
  storage_account_account_tier     = var.storage_account_account_tier
  storage_account_replication_type = var.storage_account_replication_type
}

module(resource group)

resource "azurerm_resource_group" "resource_group" {
  name     = var.resource_group_name
  location = var.resource_group_location
}

variable "resource_group_name" {
  type        = string
  description = "Resouce group name."
  default     = "default_resouce_group"
}

variable "resource_group_location" {
  type        = string
  description = "Resouce group location."
  default     = "Japan East"
}

output "output_resource_group_name" {
  description = "Resouce group name."
  value       = azurerm_resource_group.resource_group.name
}

module(storage account)

resource "azurerm_storage_account" "storage_account" {
  name                     = var.storage_account_name
  resource_group_name      = var.resource_group_name
  location                 = var.storage_account_location
  account_tier             = var.storage_account_account_tier
  account_replication_type = var.storage_account_replication_type
}

variable "storage_account_name" {
  type        = string
  description = "Storage account name. Symbols cannnot be used."
  default     = "defaultstorageaccount"
}

variable "resource_group_name" {
  type        = string
  description = "Resource group name."
  default     = "default_resource_group_name"
}

variable "storage_account_location" {
  type        = string
  description = "Resouce group location."
  default     = "Japan East"
}

variable "storage_account_account_tier" {
  type        = string
  description = "Types of storage accounts, e.g. Standard general-purpose v2."
  default     = "Standard"
}

variable "storage_account_replication_type" {
  type        = string
  description = "Replication type."
  default     = "LRS"
}

最後に

サクっとやったので適当でごめんなさい。きれいにしたらGitHubにあげます。

アジャイル開発におけるメトリックを考える その②

はじめに

開発生産性は高いのか、コストはどうなんだとか、投資判断をするにあたって必要という主張は理解できるんですが、報告するためのメトリックという意味のなさに辟易し、いろんなところで相談していたのが結構前のはなし。

daimyo-blog.hatenablog.com

ちょっと前に受けたScrum@Scaleのトレーニングでは、S@Sの概念的なところもそうですが、どういった指標を取る?というところにかなりフォーカスしていて、やっぱり自分たちの健康度を測ったり、改善するためにもメトリック大事だよねを再認識できました。

というところで、そのあたりちゃんと考えていこうっていうメモです。

共通認識として持っておきたいこと

一言で言ってしまえば、ryuzeeさんのブログの一文で終了してしまうんですが、

スプリントの中ではチームは自己組織的に仕事をしているべきであり、外部から監視目的でメトリクスを取ることはありません(そういう用途で使ってはダメです)。 あくまでもチームが自分達自身がうまく製品を届けるため、そして改善のためにメトリクスを使うことになります。

www.ryuzee.com

というのが真理。

外部からの監視がなぜダメなのか、言語化した法則がいくつかあります。

そして、測定基準のもう一つの弊害「測定基準の改ざん」問題である。この問題を端的に表している法則がある。一つは「キャンベルの法則」と呼ばれ、「定量的な社会指標が社会的意思決定に使われれば使われるほど、汚職の圧力にさらされやすくなり、本来監視するはずの社会プロセスを捻じ曲げ、腐敗させやすくなる」というものである。もう少し直接的なのは「管理のために用いられる測定はすべて、信頼できない」という身も蓋もない「グッドハートの法則」というものもある。ようは「測定基準は改ざんされやすい」のである。

www.nri.com

この記事にもあるケルヴィンの「測れないものは改善できない」は前提にあるとして、キャンベルの法則やグッドハートの法則というものを理解したうえでチームが改善のための指標を追うってことをマネジメントや他のレイヤーに理解してもらわないといけないですよね。

チームとしては、包み隠さない心理的安全性といった土台が必要。

最近はアウトカムで〜という話もよく聞きますし、誤解はなくなりつつあるのかとは思いますが、指標による安心をくれ的な風潮は変えていかないといけないです。

アジャイル開発における指標

あくまでも前述を理解したうえでという話になると思いますが、こんなものもあるよっていうのを調べてみました。

ボリュームあって全体的に学ぶところは多いのですが、「ソースコード変更とテストの継続的な実施」というのが面白いなと思ったのが楽天さんの資料。

www.slideshare.net

コミット数とコミットサイズを複合的に見たり、日次でコミット数や検出バグ数を見たりとか。

スプリントの終わりにまとめてテストしているミニWF化とか、レビュアーがやりやすい環境かとかわかりそう。コミットとかあまりフォーカスして見たことなかった。

他にもコンテキストも記録するというやり方も大事だなあと思った。

コンテキスト(文脈)も記録すること。 コンテキストのないデータは、ノイズ以外の何物でもないことがわかるかもしれない。 例: 動けるチームメンバーの数、スプリント中でのインシデントの激しさ

www.servantworks.co.jp

スクラムチームの成熟度は弊チームでもたまにやるのですが、結構抽象度が高く体力使うので、スプリント毎とかに測るなら、スクラムチェックリストやSpotifyAgile Metricsとか良さそう。

スクラムチェックリストは日本語訳がありましたが、言語の壁をつないでくれる方は本当感謝しかないですね。

www.ryuzee.com

kawaguti.hateblo.jp

medium.com

英語で検索するとscrum orgのサイトとかで色々とディスカッションされてますね、色々掘っていきたい。

雑なまとめ

記事を読みながら(あと携わっている開発を思い出しながら)メトリックと何が測れるのかをざっと考えてみました。

前述の通り、大事なのはこれだけを追うというよりは、複合的に見たり、そのときのコンテキストを把握したうえで活用すること。既に使ってるものもありますが、チームに合ったものを色々試していきたい所存。

開発者にフォーカスしたもの

  • スプリントバックログのDoneまでの時間
    ⇒スウォームできているか
     INVESTのSとなっているか

  • ベロシティ
    ⇒技術的負債の蓄積
     プロセスの改善度合い
     チームの成長

  • コミット数とコミットサイズ
    ⇒レビューのしやすさ
     レビューの時間短縮

  • 日次のバグ検出数
    ⇒ミニWF化の懸念(後半にバグが出まくっている的な意味)

  • バグ修正日数
    ⇒スプリントのスラック
     スプリントの品質
     サバイバルモード化

  • カバレッジ
    ユニットテストの品質
     プロダクトの品質

プロダクトにフォーカスしたもの

アウトカムや事業的な意味で考えるとたくさんありますが、自分が書くとお粗末になってしまいそうなので1つだけ。

  • サイクルタイムと問い合わせ発生率(バグ的な意味)
    ⇒リリースのオーバーヘッド
     プロダクトの品質
     顧客へ届けた価値
     自動化

チームにフォーカスしたもの

  • スクラムチェックリストや定点観測的な質問
    ⇒Happyさ
     チームの練度
     そもそもスクラムなのか?的な問い

おわりに

まとめ疲れてしまったんですが、サービスのダウンタイムとかコールセンターの入電率とか結構思いつくものたくさんあるなあ、、

誰かとディスカッションしたい。

スクフェス札幌 基調講演:「アジャイルの旅支度 ー ここではじめる、自分ではじめる」に参加しました

はじめに

DAY1始まりましたー!

平鍋さんの基調講演からです!わいわい!

基調講演:アジャイルの旅支度 ー ここではじめる、自分ではじめる

アジャイル開発定着している?

このイベントですらアンケートの1割ちょっとがまだまだだった。(謙遜?)

結構実ビジネスでもやってるという声が多かったですが、組織全体というのはそこまで多くなかった。

リモートでアジャイル開発やることがごく当たり前になりつつある状況なので、ノウハウ集も出してたりするみたいです、必見。

www.agile-studio.jp

ミッション・リスク分割型ビジネスと従来型の開発

よくある話ですが、従来のやり方はビジネスとITで分断されてしまう問題点がある。

今の会社も入って1年くらいは受託のWF開発のPjMやってましたが、UATで問題出るけど取り込めないモヤモヤばかりで仕事してたなあとか。 漏れたやつは来年度予算になるので対応1年後ですとか。

不確実性推移が上がっているらしい。これかな?

www.meti.go.jp

日本、米国、英国、中国など20カ国の指数を購買力平価レートでドル換算したGDPウェイトにより加重平均して算出

って書いてあった。

WFでやると壮大な伝言ゲームになる。今スクラムやっていて1人挟むのでも辛いなあと思う。

ガチガチに工程切られているけどまずはカンバン的にやってみる話とかあった。

受託開発のはなしとか

爆弾処理のメタファーしていた。UATで突如爆発しますよね、小さい爆弾ならそんなにダメージないかもだし。

受託だけでないかもですが、POを育成するのが大事みたいな話をしていた。

比較的大きな組織でアジャイル開発やっているとここが凄く課題になるので頷いていました。 これはシステム側の仕事でしょ?とか開発のことよくわかりませんみたいな、一線引かれるのがつらい。

上記に関しては、スクラムマスターが全力で仕事しろってコメントあったりしましたがその通り、、

新しい文化を取り入れるということ

アジャイルマニフェストに左も大事だけど〜と書いてありますが、曲解されてしまうこともある気がする。 左は重要だけど右はいま重要!って凄い伝えやすいと思った。

良い意味でも悪い意味でもウイルスという表現を使っていましたが、自分に照らすと出島だとウイルス広がりづらいと思った。 けどこういう状況でもプレゼンス上げていかなきゃいけなんだろうなと思った。大きめの企業だと協力してかないと仕事できないし。

元の地下鉄の絵とデロイトさんの激しいやつ。(ひいい)

www.slideshare.net

jurgenappelo.com

じぶんたちでつくる

フレームワークは器、中身のサラダ(プラクティス)は自分たちで味見してつくる。 下記のサイト貼ってもらいましたが、リンク飛べなそう、、あとで探してみる。

www.ryuzee.com

アジャイルと契約

どこで契約の線引くかという話。 これは別途色々思うことがあるのでまたまとめたい。

見えるか/透明性

野球のスコアボードの例。あ、これだという感じだった。

「最新の正の情報」を「1箇所」に、「次の行動を誘発する」とか、透明性って大事で見えないと改善できないしとかの説明に終始していた気がするので、これなら分かりやすく伝えられそう、野球やったことないけど。

TPSのコンサルにカンバンを見せると出口から見て、どのくらい出荷できるのか、 右側にない在庫は徹底的に履けさせるという話、面白かった。このくらいの意識しないとと思った。

スクラムバンって知らなかったのでメモ。

lean-trenches.com

ふりかえり

チームストライプ?という巻物を用意するやついいかも。 新しく入った人のキャッチアップ課題なんですよねー。

アジャイルスタジオの見学会行きたい。

エンタープライズアジャイルアジャイルエンタープライズ

ベンチャー的ないつの間にか型が出来て言語化するようなアジャイルエンタープライズと既存組織の型にはめ込む方向のエンタープライズアジャイル

Agile Enterprise - Speaker Deck

その他後半のもの

北國銀行の資料見つけた。

https://www.agile-studio.jp/post/financial-dx-and-hokkokubank

チームトポロジーは本出るみたいだから読まないと。

pub.jmam.co.jp

あとは自律しつつ全体性を維持するのをプロセスでは制御できないと思っているとコメントありましたが、そのとおりと思いつつプロセス作りたがりがちだなーと。

マルチ学習。学びは多層に、多能力に。

最後に

引き続きよろしくおねがいしますー!

スクフェス札幌 DAY0 に参加しました

はじめに

この1ヶ月くらい仕事が鬼のように忙しかったですが、なんとか調整付けて参加!

今回こそはゆっくり参加するぞ〜という心持ちで楽しみたいと思います。 というところでDAY0の感想戦スタート。

セッション1:コーチズクリニック活用のススメ

凄い人たちに相談できるよ!活用してみてね!という話でした。キーワードはもんにょりと笹団子。

コーチズクリニックに関しては、RogerBrownさんがScrumAllianceのサイトで情報公開しているみたいです。

https://www.agilecoachjournal.com/wp-content/uploads/2013/06/CoachesClinic1.6.pdf?189db0&189db0

コーチ受講者の経験談を聞いてたんですが、どうしても自分の悩みなんて、、と思ってしまいますが言語化して相談したいなあと。 あと自分は不安でしょうがないんだなと思った。そして背中を押してほしいのかもなと聞きながら内省。

セッション2:ふらっと立ち寄れる廊下のある風景 -- フラットでオープンネスがもたらす魅力

エモかったー。

satoryuさん喋っているところ今まで見たことなく、 チャットのダジャレ名人的なイメージが先行してたんですが、勉強会って本当にいいなあと再確認でき、明日からも楽しめそうと思える内容でした。

ちょっとしたきっかけで参加した勉強会で、救われたことが多々あったので最近めっきり行けてなかったですが大事にしたいと思いました。

あなたが楽しいと思えることは、他のひともきっと楽しい。良い言葉だー。

さいごに

簡単な感想になってしまいましたが、3日間よろしくおねがいしますー! そして育児してくれている妻に感謝。

新版コーチングの基本を読んだ

はじめに

こんにちは!daimyo404です。

子どもが生まれて勉強会やブログなどから暫く離れておりましたが、 タイミング見てそろそろ復活していきたいと思う次第です。(遠ざかっているとモチベーションの維持ができなくて本当つらい)

今回はコーチングの基本/コーチ・エィを読みましたので自分用のメモにまとめます。

コーチング概論

そもそもコーチングってなんぞや

コーチング学んだっぽい人から、「なんで?なんで?」と詰問されて「いやなんなんだよ、、こっちは答えを求めているんだけど、、」という経験があり、正しく理解しないとなとずっと思っていたというのがファーストインプレッション。

書籍によるとコーチングの定義とは

対話を重ねることを通して、クライアントが目標達成に必要なスキルや知識、考え方を重ね、行動することを支援するプロセスである。

コンサルタントのようにコーチが分析して答えを提示するのではなく、クライアント(コーチを受ける人)自身が目標を明確にして達成していくのを助けるというわけですね。

無意識のなかにあるもの

パーセンテージは若干文献によってばらつきありましたが、自らが意識できていること(顕在意識)は、3~10%程度でそれ意外は前意識や無意識であると言われています。

人の意識と無意識について | ビジネス・夫婦間コミュニケーションの問題を解決するコーチング

日常でも言われてハッとしたこととかあると思いますが、ちょっと考えれば分かっていたけどということも多々ありますので、そこをコーチとの対話のなかで掘り起こしていくプロセスというわけですね。

選択的知覚

有名どこだと、カクテルパーティー効果のアレです。

心理学用語「選択的知覚」とは?意味と具体例をわかりやすく解説 – スッキリ

強く関心を持った情報を、大量の情報からふるい分けて認識する能力が人間には備わっています。様々な情報から対話を通してフォーカスさせることも重要になってきます。

コーチングが機能する条件

冒頭に書いた内容に近いですが、無闇矢鱈に相手の内省を促す質問を投げればいいかというとそうではありません。一例として、相手の精神状態、成長段階、課題領域という3つの判断基準に注目するというものがあります。

精神状態

内省する暇もないような状態でコーチングを受けてもあまり意味がないので、対話に参加できるエネルギーレベルや精神的な安定が必要になります。

成長段階

コーチングの際、いつでも同じアプローチを取ればいいかというとそうではなく、相手の能力レベルと意欲を読み取りながら変えていくのがいいとされているようです。

#111 能力・意欲マトリックス : LIFENAVI COACHING

意欲は高いが能力が低いケース

なんとなく想像でイメージつくと思いますが、ここはコーチングは機能し辛いです。能力が低いためにアウトプットの質などに自身が持てない状態が続いては、段々と意欲まで削がれてしまいます。なので、ティーチングでリードしていく方が効果的なケースが多い。

能力は向上しているが意欲が低下している場合

成長段階の多くの人は、自分自身が気づけていなかったり、走り続けているなかで意欲が低下していくケースが少なくないです。このような状況に直面している人がコーチングが効果的で、コミュニケーションのやり方を「認める」、「理解する」、「考えさせる」にシフトさせていきます。

また、過度な介入は本人の自尊心を傷つけるリスクがありますので、「観て」必要に応じて支援する動きが必要になってきます。

コーチングの流れ

専門のコーチになりたいわけではないので割愛しますが、実際の流れは以下を参考。

3分で理解する『コーチング・フロー』を構成する5つの要素

コーチに必要な視点や価値観

PBP

コーチに必要と言われる視点にPBPというものがあります。まとめるの疲れてきたので下記参考。

syr33.com

コーチングの三原則

クライアントの関わり方における、双方向、継続性、個別対応という3つのマインドがあります。 このあたりは文字通りという感じで、きちんとクライアントに合わせたりしましょうとかそういう感じです。

コーチングの定義と三原則 | コーチングとは | コーチ・エィ アカデミア

テクニックっぽいこと

知っていることも結構ありましたが、テクニックや知識的な部分をまとめていきます。

コーチングの代表的なスキル

下記の7つがあります。

  • 傾聴
  • ページング
  • 質問
  • アクノレッジメント
  • フィードバック
  • 提案
  • 願望

傾聴で気をつけないとと思ったポイントは、相手のノンバーバルな情報を受取ること、聞いているというサイン(表情やうなずき)、沈黙を共有することかなあと。

質問に関してはチャンクダウンやスライドアウトを上手く使うこと、アクノレッジメントはいくつか承認にも種類があると紹介されていました。

コーチングスキル「承認」すべき3つの要素 | LBJ

提案のポイントも色々紹介されていましたが、「提案してもいいですか?」と許可を得ることでお節介や命令とは異なるものにとありました。以前お世話になったアジャイルコーチがよくやっていたなあと思い出したり。

自己開示の返報性

これは有名なので割愛。

自己開示の返報性とは?意味とビジネス・恋愛で使えるテクニックを紹介 | トレンディパレット

ほめるための3種のメッセージ

「よく頑張ったね!」と「勉強になりました!」で褒め方にどう違いがあるかわかりますでしょうか?答えはメッセージの主体が「誰になるか」という点で、この例だと、「あたな」が主体なのか「わたし」が主体なのかの違いということになります。

どうやらIやWeの方が心に残るみたいですが、ストレートなYouメッセージを好む人もいるので見極めようということみたいです。

褒めるコツ|相手の承認欲求を満たす3種類の承認レベルとメッセージ - Web活用術。

脳科学とやる気

ちょっと逸れますが、これはブログ書くなかで見つけた面白い記事。 書籍では茂木先生の話とかに触れてました。

脳科学から見た やる気とグロースマインドセット|Adecco Group

さいごに

日々勉強。

スクラム実験室のプレゼン & ワークショップ まつりに参加しました

はじめに

スクラム実験室のプレゼン & ワークショップ まつりに参加しました。 2回目くらいの参加だと思いますが、清水さんの声は本当優しくて癒やされますね。

GROOVE Xにおける大規模スクラム(LeSS) リリースサイクルを短くするとりくみ

コンポーネントベースでチーム作ってるらしい、でも対立構造はない。

課題として、リリースが延びたりテストスプリントがある、リリース後の不具合とか。 けど、自動化はやり尽くした感。

基盤系の自動化をスプリント内に持ち込んだ。 ソフトウェアのように立てたインスタンス壊してなどが難しいので、 状態を元に戻したりハードウェア特有の難しさはある。

ワーキングアグリーメント作ったり、Doneの定義整備したり。 そういえば前作ったワーキングアグリーメントどこいったっけ、、って思い出した。

WikiにはSPIRITを置いてた。 ダッシュボードとか目につくところにミッションを書いておくのはいいかも。

エグい量のスクリプトが映ったけど、テストの大変さがわかる。 あとはリブート走ったあとの通信とかハードウェアのテストの大変さみたいなのが。

Six trumps for Scrum -スクラムのセレモニーを最大限楽しくする原則(オンラインでも利用可能!)

最初に退屈な打合せとかの特徴を挙げた。

シャロン・ボウマンのSix Trumpsという手法がある。

  • 座り続けるよりも、話そう
  • 聞き続けるよりも、話そう
  • 文字よりも、絵を描こう、使おう!
  • 読み続けるよりも、書こう
  • 長い時間をかけるより、短い時間(10~20分)を意識しよう
  • 同じことを続けるより、変化を与えよう

https://www.amazon.co.jp/Using-Brain-Science-Training-Stick/dp/096568511X

モブプロを導入して2年が経ちました

6人以上いると内職する人いるとかリアルな話があった。 ペアプロはペアとの対立があるかもしれないがモブプロだと問題の対立になるとか、 ペアが抜けても続けられるメリットとか。

  • 初心者の人が多いと代わる代わる何度も同じ質問がくるのを避ける
  • 知識の平滑化
  • 新しい質問の視点による自分たちへの学び
  • フロー効率
  • 現在は必要な場合だけ取り入れるスタイル
  • モブプロベストプラクティスがとても良い
  • ファシリテーションをモブする

ファシリテーションのモブはいいですね。 チームで進行上手くなりたいって人もいるしやってみようかな。

はじめての懇親会

懇親会も参加できました。

最近少人数でガッツリ話す機会もなかったので、 チーム外の開発の話聞けて楽しかったです。

あとまわりにあまりいないSM専任者のはなしとか。

モブプロの発表お疲れ様でした!