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にあげます。

2021-12-13

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

はじめに

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

daimyo-blog.hatenablog.com

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

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

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

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

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

www.ryuzee.com

というのが真理。

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

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

www.nri.com

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

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

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

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

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

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

アジャイル開発とメトリクス from Rakuten Group, Inc.

www.slideshare.net

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

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

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

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

www.servantworks.co.jp

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

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

www.ryuzee.com

kawaguti.hateblo.jp

medium.com

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

雑なまとめ

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

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

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

スプリントバックログのDoneまでの時間
⇒スウォームできているか
　INVESTのSとなっているか
ベロシティ
⇒技術的負債の蓄積
　プロセスの改善度合い
　チームの成長
コミット数とコミットサイズ
⇒レビューのしやすさ
　レビューの時間短縮
日次のバグ検出数
⇒ミニWF化の懸念（後半にバグが出まくっている的な意味）
バグ修正日数
⇒スプリントのスラック
　スプリントの品質
　サバイバルモード化
カバレッジ
⇒ユニットテストの品質
　プロダクトの品質

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

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

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

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

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

おわりに

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

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

2021-11-05

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

はじめに

DAY1始まりましたー！

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

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

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

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

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

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

www.agile-studio.jp

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

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

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

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

www.meti.go.jp

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

って書いてあった。

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

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

受託開発のはなしとか

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

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

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

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

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

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

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

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

アジャイル開発と私たちのやり方 from Moriyuki Hirata

www.slideshare.net

jurgenappelo.com

じぶんたちでつくる

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

www.ryuzee.com

アジャイルと契約

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

見えるか/透明性

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

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

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

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

lean-trenches.com

ふりかえり

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

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

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

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

Agile Enterprise - Speaker Deck

その他後半のもの

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

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

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

pub.jmam.co.jp

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

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

最後に

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

2021-11-04

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

はじめに

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

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

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

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

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

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

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

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

エモかったー。

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

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

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

さいごに

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

はじめに

組織の有機体観とは

初期人間関係論とは

ホーソン実験

リカートのリーダーシップ論（=ミシガン研究）

人的資源管理論（＝後期人間関係論、新人間関係論）

アージリスの自己実現人モデル

マクレガーのX理論・Y理論

ハーズバーグの動機づけ・衛生理論（=2要因理論）

さいごに

はじめに

導入

組織の機械観とは

古典的管理論

テイラーの科学的管理法

ファヨールの管理原則論（=管理過程論）

官僚制組織論 （=ビュロクラシー論）

さいごに

参考書籍

はじめに

フレームワークについて

当たり前は変わる

ORSC

4つの毒素

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

はじめに

ざっくり概要

解説

最後に

はじめに

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

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

雑なまとめ

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

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

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

おわりに

はじめに

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

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

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

受託開発のはなしとか

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

じぶんたちでつくる

アジャイルと契約

見えるか/透明性

ふりかえり

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

その他後半のもの

最後に

はじめに

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

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

さいごに

官僚制組織論（=ビュロクラシー論）

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