書評 ふりかえり読本 実践編 ~型からはじめるふりかえりの守破離~ #技術書典 7
技術書典 7 で発売される、ふりかえり読本の最新刊「実践編」を森一樹さん(@viva_tweet_x)から早めに頂きました。
ありがとうございます!
今回も素敵な仕上がりになっているので、私の感想も交えて紹介させていただきます。
内容紹介
ふりかえり導入の4つのパターン
ふりかえりを始めることに前向きか・後ろ向きか、ふりかえるために十分な時間を取れるか・取れないかで4つの導入パターンが紹介されています。
そもそも、ふりかえり始めたくてもどう始めていいのか分からない。という状況もあると思うので、このパターンの提示はたいへん助かるのではないでしょうか?
この本を購入できるようになるまで少し時間があるので、事前にチームメンバーがふりかえりについてどう思っているのかをヒアリングしておくと本書を読み進めながらイメージトレーニング出来るので良いかもしれません。
ふりかえりの守破離
守破離の概念の説明と「守」を実践する上で大切なことが示されています。
注意が必要なのは、Webサイト上に載っている情報はほとんどが「情報の発信者の現場のコンテキスト(環境や背景など)に合わせて(発信者も意図しないままに)カスタマイズされた情報だということです
私も、このコンテキストの違いは「守」を実践する上で非常に重要だと思います。
書いてあるとおりにやっているのに、うまくいかない場合はこのコンテキストの違いを認識せずに実践していないか確認するのは大切です。
そんなときは、ふりかえりのふりかえりをやってみるのも良いのではないでしょうか?
森さんがふりかえりのふりかえりについても記事を書かれているので、是非参考にしてみてください。
(ここまではお試し版で読むことが出来ますよ!)
実践しやすいふりかえりの型
本書では8つのふりかえりの型が紹介されますが、いずれも使いやすい型になっています。
これは、ふりかえりの型としていろいろなコンテキストで使えるようにするために、アクティビティ単位ではあえて破をすることも示してくれているからだと思いました。
たとえば、「短期間をふりかえる」でKPTの進め方のコツが紹介されていますが、前述の通りKPTの破の仕方が示されます。
最後のポイントは、「Keep、Problemの意見が多く、意見が割れている場合は、Tryを出す前に絞り込む」ことです。
続けてこの破をどのような状況で実施するべきか、目的は何であるのかも続けて示されます。
Keep、Problemの意見が多く、発散している状態でTryをしようとすると、どうしても個人の思いが強い、部分最適になりがちなTryが挙げられがちです。チームにとって特に大切で、伸ばすべきKeepは何か、解消すべきProblemは何か、というテーマを一度ドット投票によって絞り込んでから、絞られたテーマに対するTryを検討するとより効果的です。
ここで示される状況は、チームとしては良い状況だとは思うものの、意味のあるアクションに繋げるためにはファシリテーションが難しい印象があります。 この破を知っていることで、ふりかえりをより効果的に進めることができるようになるのではないでしょうか。
また、この破のポイントや狙いはKPTだけに限ったことではないので、全体としての型を守りつつどこで破をするとよいのか、その考え方を示してくれているように感じます。
まとめ
前書である「学び編」では、ふりかえりで使えるいろいろなアクティビティに関して、目的や狙い、具体的な方法が森さんらしい表現で書かれているものでした。 本書「実践編」は、森さんらしさはそのままに、ふりかえりの目的に応じて、どのようにアクティビティを繋ぎ合わせ、どのようにふりかえりの流れを作るのかを型として紹介してある本になります。
オススメの本は読む人によって変わってくるのですが、「ふりかえりを始めたい」「ふりかえりで悩んでいる」という人にはまず「実践編」をオススメさせていただきます!
どこで買えるの?
9/22に開催される技術書典 7 で冊子版、DL版ともに購入可能です。
技術書典に行けない方はBOOTHでも購入出来るようになっています。 hurikaeri.booth.pm
書評 ふりかえり読本 学び編 〜経験を力に変えるふりかえり〜 #技術書展6
4/14(日)に開催される技術書展6。
そこで発刊される「ふりかえり読本 学び編」をびばさん(@viva_tweet_x)のご厚意で頂きました。
早速読んでみて、これはいろいろな人にオススメしたいと思ったので、そのポイントなどをまとめてみます。
どのような人にオススメか
万人にオススメと言っても過言ではありません。
技術職であってもなくても、日々何かしらに真摯に取り組んでいる方は本書から次の成長につながる継続的なきっかけを手にする方法を学べます。
また、あなただけではなく、あなたの所属するチームや組織、コミュニティに参加している方の成長につながるきっかけをどのように生み出すかを学べます。
本書のオススメポイント
ふりかえりが生み出す学習
ふりかえりがどのような認知を人に引き起こすのかを経験学習サイクルを踏まえて分かりやすく解説されています。
この経験学習サイクルに則ってKPTを行うだけでも、これまでとはちょっと違うファシリテーションができるのではないでしょうか。
ふりかえりの質を更に上げる問いかけ
ひとりでふりかえりをしているとき、チームのふりかえりをファシリテーションしているときどのような問いかけをしていますか?
経験学習サイクル毎にどのような問いかけをすると良いのか、概念とともに具体的な例も記してくれています。
これで、あなたのふりかえりのファシリテーション力はさらに上がるはずです。
ふりかえり実践ワークショップに参加しているような感覚に
びばさんは、ふりかえり実践ワークショップを定期的に開催していらっしゃいます。
自分もこれまで2回参加し、びばさんのファシリテーションのもとふりかえりを体験しています。
本書を読み進めてる最中にすごく感じたのが、このワークショップの雰囲気が文章に現れていることです。
びばさんらしい優しく丁寧な語り口と的確な指摘。ワークショップの追体験をしている感覚になることが多々ありました。
うちの会社にびばさん来てくれないかな?と思っている人は本書で仮想びばさんを手に入れましょう。
本書から得た学び、気付き、何を実践するか
ひとりのふりかえり ≠ ひとりでふりかえり
ひとりのふりかえりは一人でするという固定概念があったことに気づけました。
別にひとりでやる必要はなかった。複数人でひとりのふりかえりをやることで、コーチングやメンタリングという観点でひとりで行うより質の高いふりかえりをできる。
この気付きは大きいです。 またフラクタル的に捉えることもできそうなイメージを持ちました。 たとえば、チームのふりかえりを別のチームを交えてやるとか面白そうじゃないですか?もうちょっと練ってみて実行してみたいです。
実験したい気持ちを強く持った
経験学習サイクルを軸とした問いかけの例、ふりかえりの場毎のプラクティスの具体的な解説がまとめられているおかげで、色々実験してみたいという熱量が高まりました。
というわけで、直近ふたつ実践してみようと思っています。
まずは、チームのふりかえりでFLAPを一度やってみること。
そして、有志を募ってで四半期のひとりのふりかえりをやってみること。
興味湧いてきたそんなあなたに
冒頭でも書いたとおり、次の日曜(4/14)に開催される技術書展で購入できます。
詳しくは以下のページを御覧ください。
さらに、以下のページから、前半75ページ試し読みできます!
続きを読む#技術書典 6
— びば(森のフレンズ)/技術書典6 お34 ふりかえり読本 学び編 (@viva_tweet_x) 2019年4月8日
75ページ無料公開にしました。ふりかえり読本のコアな部分は大体お読みいただけます。
エンジニアの成長に繋がる「ふりかえり」を広く知ってもらえて、それで誰かの次の一歩につながったら、とても嬉しいです。https://t.co/Ujqb3GzkVD
16 personalitiesで内面の変化を定量化して、自分が変われることを知れるぞ!
ゆのんさんのつぶやきとブログを見て「これは!」とワクワクしたので早速やってみた。
きっかけとなったつぶやき
書いた / “定期的に16 Personalitiesを調べて、自身の確証バイアスを見直す - Unknown Error” https://t.co/7WFMqg135j
— ゆのん@EM.FM (@yunon_phys) January 14, 2019
私の反応
あー16 personalitiesを無意識に変わらないものと思い込んでいてこういう使い方は考えたこともなかった。取り入れよう。 https://t.co/5X1NYuQwYB
— ちゃまぐ (@tyamaguc07) January 14, 2019
つぶやいている通り、自分は無意識に16 personalitiesは変わらないと思っていた。
これが変わるとなると色々受取り方が変わってくる。
ゆのんさんの仰る通り、自身の内面の変化を定量化できる。
これは今年の行動指針「トラッキングする」にも繋がる。
そして何より、比較できる情報の価値は大きい。
やってみた
残念ながら昨年のデータは一部しか残っていなかったが、一部を比較できるだけ嬉しい。
見ての通り大きな変化はないが、多少の変化は起きている。
この変化がどのようなモノとして起きたのか考えてみたい。
意識の変化
昨年は社外の勉強会でトークをさせてもらう機会が4回あった。
3/7に16personalitiesをする前に2回、後に2回。
それ以外にも社外の方と話をさせて頂く機会が増えた年でもあった。
おそらくだが、社外の方とコミュニケーションすることの不安が減ったことが数値の変化につながっているのだと思う。
エネルギーの変化
この1年で直感的に判断しとりあえずやってみるという動きが増えた気もするが、それ以上に自分のことを知ったからだと思われる。
以前の自分は現実型で「ありたかった」現実型だと「思っていた」。
これが最近では、自分は結構直感型で思いつきで行動することが多いということに自覚的になってきた。
変化の定量化
最初にも書いたが、このような形で自分の変化を定量的に見れるとは思ってもみなかった。
やってみて思ったが、1年のふりかえりにも有効に使えそうだ。
そして何より、「自分が変化出来ること」を知れる1つの手段である。
自分は内向的な人間で変わらない。と思っていたとしても、このような取り組みを経て少しでも変われることを実感できれば、次の行動につなげる事ができるのではないかと思った。
#RSGT2019 のふりかえりと感想
(書きかけ)
ふりかえり with KPT
Keep
- 自分が今の会社の中でやっていきたいことが明確になった
- 測定することの大切さを改めて知った。
- 一緒に参加してもらったメンバー全員が楽しかったと言ってくれたこと
- 「チーム全員参加させたい!」と言ってもらえた
- チケット代の予算獲得してよかった!
- 新しい施策を思いついた
- チームとしてやめたことを残す
- 昔辞めたあの施策、今あらためてやるといいんじゃないか。みたいなきっかけを生みそうな予感から
- チームに高い目標(理想?)を作ってもらう
- How do we interact?
- How do we code?
- How do we do business?
- How do we innovate?
- チームとしてやめたことを残す
- ふりかえりをしていること
- OST楽しかった
- 軽井沢に住みたくなった
- ヤッホーブルーイングのファンになった
Problem
- 参加者とあまりコミュニケーションできなかった
- OSTに話したいことを持ち込めなかった
- OST始まってから思いついた
- 事前に会社のメンバーとRSGTの行動目標決めておけばよかった
- 知らない人と話すために名刺5枚ゲットする。みたいな。
Try
- Day毎にふりかえり
- 懇親会に参加する
- 休憩中に毎回誰かに声をかける
感想
Day1, 10:10 delivering what matters
Day1, 13:00 Coaching resilient Scrum teams
Day1, 14:00 行動分析学に基づくScrumの導入
Day1, 15:15 心理的安全性ゲーム
Day1, 16:15 超Scrum入門〜未完成フラクタルと15minSprint〜
Day2, 10:10 Learning to Experiment
Day2, 13:00 Effective Retrospective / とにかく楽しいふりかえり
Day2, 14:00 プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making
Day2, 14:25 プロダクトオーナーとして『開発プロセス』を思考せよ〜EBM(Evidence-Based Management)を軸とした『プロセスの見える化』と『ムダからの解放』を実践したインパクトについて〜
Day2, 15:15 そのときサーバントリーダーはどう振る舞うか
Day2, 16:15 学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー
Day3, 10:10 Open Space Technology
楽しい
成功体験
unlearnとは
Day3, 13:00 よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~
■ プログラミング言語Rust 「4.4. コメント」「4.5 if」写経時のつぶやき
4.4. コメント
■ 行コメント
— ちゃまぐ (@tyamaguc07) 2018年12月23日
「//」は以降行末までの文字がコメントとなる。
■ ドキュメンテーションコメント①
「///」はその中でmarkdown記法をサポートする。
■ ドキュメンテーションコメント②
「//!」コメントの対象がクレート、モジュール、関数。
一般的にはクレートルートやモジュールルートで使用される
4.5 if
■ if
— ちゃまぐ (@tyamaguc07) 2018年12月23日
動的型付け言語のif文に近い
添付のような使い方もできる
これが動くのは、ifが式であるから。
式が返す値は、選択された分岐が最後に評価した値
elseのないifでは、最後に評価した値は常に()となる pic.twitter.com/oDAfctCBj4
プログラミング言語Rust 「4.3. プリミティブ型」写経時のつぶやき
2018/12/13
変数束縛fを使って関数を実行できる
— ちゃまぐ (@tyamaguc07) 2018年12月13日
型推論は`type inference`というのか。
■ プリミティブ型
プリミティブ型は言語に組み込まれた型
■ ブーリアン型
boolと名付けられている型
trueとfalseの2つの値を持つ
■ char型
一つのユニコードのスカラ値を表す型
Rustのchar型は1byteでなく4byte
■ 数値型
— ちゃまぐ (@tyamaguc07) 2018年12月13日
Rustにはたくさんの種類の数値型がある
カテゴリとサイズという2つの部分から成る
カテゴリの種類「符号ありと符号なし」「固定長と可変長」「浮動小数点と整数」
数値リテラルが型を推論させるものを何も持たなければデフォルトの型になる
let x = 42; // xはi32
let y = 1.0; // yはf64
2018/12/14
■ 符号なしと符号あり
— ちゃまぐ (@tyamaguc07) 2018年12月14日
符号なし(unsigned)型はカテゴリ部に u を使う
符号あり(signed)型はカテゴリ部に i を使う
i はinteger(整数)の i
u8は符号なし8bitの数値
i8は符号あり8bitの数値
■ 固定長型
— ちゃまぐ (@tyamaguc07) 2018年12月14日
固定長型はそれぞれの表現の中に特定のビット数を持つ
指定することの出来るビット長は8, 16, 32, 64
u32は符号なし32bit整数
i64は符号あり64bit整数
■ 可変長型
— ちゃまぐ (@tyamaguc07) 2018年12月14日
実行環境のポインタサイズに依存する型
符号ありはisize
符号なしはusize
■ 浮動小数点型
Rustは2つの浮動小数点型を持つ(f32とf64)
■ 配列
— ちゃまぐ (@tyamaguc07) 2018年12月14日
固定長の同じ型の要素のリスト(リスト?目録と訳するほうが正しそうだが、直感的ではないなぁ。日本語難しい)
配列はデフォルトでイミュータブル
配列は[T; N]という型を持つ
T記法はジェネリクスのセクションで解説
Nは配列の長さのためのコンパイル定数
let a = [0; 20];
— ちゃまぐ (@tyamaguc07) 2018年12月14日
上記のコードは配列の各要素を同じ値で初期化するための省略表現
変数束縛aの各要素は0で初期化される
配列aの要素の個数はa.len()で取得できる
配列の特定の要素には添字記法でアクセスできる
— ちゃまぐ (@tyamaguc07) 2018年12月14日
添字はほとんどのプログラミング言語と同じように0から始まる
配列に含まれない添字を使おうとするとエラーになる
配列アクセスは実行時に境界チェックを受ける
2018/12/15
■ スライス
— ちゃまぐ (@tyamaguc07) 2018年12月15日
他のデータ構造への参照(またはビュー)
コピーすることなく、配列の要素への安全で効率的なアクセスを許すために便利
スライスは既存の変数束縛から作られる
スライスは定義された長さを持つ
スライスはイミュータブルにもミュータブルにも出来る
(ミュータブルにできる??)
・スライシング構文
— ちゃまぐ (@tyamaguc07) 2018年12月15日
スライスを作るためには、&との組み合わせを使う
&はスライスが参照と同じであることを示す
はスライスの長さを定義する
スライスは型 &[T] を持つ
■ str
— ちゃまぐ (@tyamaguc07) 2018年12月15日
str型は最もプリミティブな文字列型
型と言っているが実際は文字列スライスと表現したほうがしっくり来る
"hogehoge"としただけで、スライスが作られる(Perl脳だと違和感しかない)
str型は必ず元となるデータがある
— ちゃまぐ (@tyamaguc07) 2018年12月15日
Stringから作成したり、文字列リテラルで作成する場合はプログラム中にそのままバイト列として埋め込まれるhttps://t.co/njijMTdI4k
2018/12/16
■ タプル
— ちゃまぐ (@tyamaguc07) 2018年12月16日
タプルは固定長の順序有りリスト
【語源】quintuple(5要素の組)、sextuple(6要素の組)などの後半部分から
let x = (1, "hello"); // 型推論あり
let y: (i32, &str) = (1, "hello"); // 型推論なし
tupleは異なる型の値を含むことが出来る
tupleには他のtupleを割り当てる事ができる。(条件付き)
— ちゃまぐ (@tyamaguc07) 2018年12月16日
条件① 持っている型が同じ
条件② アリティが同じ
let mut x = (1, 2);
let y = (2, 3);
println!("{:?}", x); // => (1, 2)
x = y;
println!("{:?}", x); // => (2, 3)
■ letの追加解説
— ちゃまぐ (@tyamaguc07) 2018年12月16日
letの左辺にはパターンを書くことが出来る
letの左辺のパターンと右辺が一致した場合、複数の束縛を一度に割り当てる事ができる
let (x, y, z) = (1, 2, 3);
コンマをつけることで、要素1のtupleと丸括弧の中の値を混同しないように明示できる
— ちゃまぐ (@tyamaguc07) 2018年12月16日
let x = (0,);
let y = (0);
println!("{:?}", x); //=> (0,)
println!("{:?}", y); //=> 0 pic.twitter.com/XIkTYazA8m
■ tupleのインデックス
— ちゃまぐ (@tyamaguc07) 2018年12月16日
tupleのフィールドにはインデックス構文でアクセスできる
配列のインデックスと同じように添字は0から始まる
配列のインデックスと異なり、[] ではなく . を使う pic.twitter.com/1R25LY4i9t
2018/12/23
■ 関数
— ちゃまぐ (@tyamaguc07) 2018年12月23日
関数も型を持つ
fn foo(i32) -> i32 {
x
}
let fp: fn(i32) -> i32 = foo;
この場合のfpは関数ポインタ
プログラミング言語Rust 「4.2. 関数」写経時のつぶやき
2018/12/11
fnは関数ということを示す
— ちゃまぐ (@tyamaguc07) 2018年12月11日
関数の引数はletと似た動きをする
引数の名前にコロンをつけて型を宣言する
letと異なり、関数の宣言に型は必須
Rustはあえて関数で型を明示するように設計されている
— ちゃまぐ (@tyamaguc07) 2018年12月11日
→ 型推論するようにすることも可能
→ Haskellは関数も型推論が動く
→ そのようなHaskellでもドキュメント目的で型を明示することは良い習慣だと言われている
関数戻り値の型は以下のように指定する
— ちゃまぐ (@tyamaguc07) 2018年12月11日
fn add_one(x: i32) -> i32 {
関数の最後の行が何を返すのか決定する
最後の行の末尾にセミコロンがあるとエラーになる
このエラーが示すことは2つある
①Rustが式ベースの言語であること
②セミコロンが他の「波括弧とセミコロン」ベースの言語と違うこと
Rustは主として式ベースの言語
— ちゃまぐ (@tyamaguc07) 2018年12月11日
文の書き方は2種類しかない
式と文の違い
・式は値を返すが、文は値を返さない
→ 関数の最後の行の末尾にセミコロンがあると文となり、値を返さないためエラーになる
・宣言文
— ちゃまぐ (@tyamaguc07) 2018年12月11日
変数束縛に使用するletを使うと宣言文となる
したがって、rubyなら動く以下のコードはRustではエラーになる
Ruby: x = y = 5
Rust: let x = (let y = 5) // expected expression, found statement `let’
エラーが伝える内容は、式を期待していたが、'let'文が見つかった
既に束縛されている変数への割当は式
— ちゃまぐ (@tyamaguc07) 2018年12月11日
let mut x = 5;
let y = x = 10; // x = 10は式
割当が割り当てられる値を評価する他の言語とは異なり、Rustでは割当の式が返す値はタプル
なぜなら、割り当てられる値には単一の所有者しかいないため、割り当てられる値を返せない。他の値を返すことも予想外。
したがって、以下の処理を実行するとyの値はタプルになる。
— ちゃまぐ (@tyamaguc07) 2018年12月11日
let mut x = 5;
let y = x = 10;
2018/12/12
・式文
— ちゃまぐ (@tyamaguc07) 2018年12月12日
式を文に変換する
Rustの文法は文のあとに文が続くことを期待する
式の末尾にセミコロンを入れることで文に変換する
したがって、Rustのコード「ほとんど」の行でセミコンが見られる
「ほとんど」の例外は、関数から値が返る場合
この場合、値を返したいのでセミコロンをつけない
returnキーワードを使うことでセミコロンが末尾にあっても、値を返せる
— ちゃまぐ (@tyamaguc07) 2018年12月12日
しかし、関数の最後でreturnキーワードを使って値を返すことは良くないスタイルと言われている
・発散する関数
— ちゃまぐ (@tyamaguc07) 2018年12月12日
「発散する関数」=値を返さない関数
発散する関数のための特別な構文がいくつかある
fn diverages() -> ! {
panic!("This function never returns!");
}
この関数はクラッシュするので決して値を返さない
そのためこの関数は返り値の方として!型を持つ
!はdivergesとよぶ
■ 関数ポインタ
— ちゃまぐ (@tyamaguc07) 2018年12月13日
関数を示す変数束縛を作る事ができる
let f: fn(i32) -> i32;
上記コードで定義されたfはi32を引数として、i32を返す関数を示す変数束縛。
よって以下のような事ができる
fn one_plus(i: i32) -> i32 {
i + 1
}
let f: fn(i32) -> i32 = one_plus;
変数束縛fを使って関数を実行できる
— ちゃまぐ (@tyamaguc07) 2018年12月13日
型推論は`type inference`というのか。
■ プリミティブ型
プリミティブ型は言語に組み込まれた型
■ ブーリアン型
boolと名付けられている型
trueとfalseの2つの値を持つ
■ char型
一つのユニコードのスカラ値を表す型
Rustのchar型は1byteでなく4byte