はんなりと、ゆるやかに

アジャイル、スクラムが好きが日々から学んだことをアウトプット

新 コーチングが人を活かす を 読んだ

「新 コーチングが人を活かす」を読みました。

本書は2000年に出版された「コーチングが人を活かす」の改定版です。著者は出版からの20年間でコーチングが求められる領域が広がったと書かれています。ソフトウェアエンジニアの僕も「コーチング」という言葉を知り、興味を持っていることから広がりを感じますね。

改定の目的は、誤解した使われ方を正すこと、1対1だけではなくチームで活かす方法をまとめること、新しく得たスキルや知識でアップデートすること、とのことです。

本書はコーチングに関するスキルか62個紹介されています。(たとえば、「SKILL01 心のシャッターを上げる」など) 本書を読んで思ったことについてまとめていきます。

相手と同じ目線で、相手を大切にする

コーチングはコーチとクライアントというようにコーチする側、受ける側にわかれます。そのため、意識しないと上下関係が生まれてしまいます。コーチングの目的はクライアントの思うゴールに到達することです。そのゴールに二人三脚で、相手がチームならムカデ競争で協力し、歩幅を合わせて進めて行くことが大切だと学びました。

一兆ドルコーチという書籍も「信頼と愛」がキーワードでした。今、相手はどういう状況なのか?どういった言葉やサポートが前に進む行動に繋がるのか?相手についてとことん考えたいですね。

質問で相手の固定観念を取り除く

本書はコーチする際の具体的なスキルが62個紹介されています。信頼関係を築くスキルもあれば、目標設定のためのスキルもあります。多くのスキルに共通していると感じた点は固定観念を取り除くことです。「制約がなければ、何がしたい?」「妥協していることを5つ上げるとすれば何?」「目標達成の障害になったことはなんだろうか?」など色々なスキルを使って気づきを与えます。その結果、相手が自分でゴールに近づく方法を見つけられるのです。

固定観念は自分では気づきにくいです。なんてったて自分で当たり前と思っているのですから。

巻末の活用ガイドが実用的

本書はコーチングのスキルが紹介されています。巻末には紹介されたスキルはどういった場面で発揮できるか紹介されています。

「相手があまり話してくれない」場合には4つのスキルが紹介されていますし、「相手の目標設定がうまくいかない」場合には5つのスキルが紹介されています。

62個、すべてのスキルを使いこなすことは簡単ではありません。まず、今困っていることから使えるのは取り組みやすいです。

まとめ

  • コーチングに関するスキルが簡潔にまとめられた書籍
  • 活用ガイドは状況から逆引きできる優れもの
  • スキルを活用する前提として、相手を大切にしよう

 

 

This is Lean を読んでリーンの理解が進んだ

アジャイルに触れているとリーンという言葉に出会うことがあります。リーン(Lean)の英語の意味は「贅肉が少ない、引き締まった」というニュアンスの言葉です。また、僕の中のリーンのキーワードは「無駄をなくす、フロー効率」という感じでした。そんな感じでリーンとはなにか?についてふわっとしか分かっていないため本書を手に取りました。

本書はリーンとは何か?について書かれた本です。

本書は構成が良くて分かりやすい。はじめにフロー効率とリソース効率の違いについて学んだあとはフロー効率の特徴 ━フロー効率に影響を与える要素、法則、一次ニーズと二次ニーズ━ と続きます。そして、トヨタとリーンの関係性からリーンとは何かが理解できる構成になっています。

本ブログでは学んだことをまとめていこうと思います。

目次

  • プロローグ 五〇〇倍のスピード
  • 第一章 ソース重視から顧客重視へ
  • 第二章 フロー効率を左右するプロセス
  • 第三章 プロセスにフローをもたらす要素
  • 第四章 効率性のパラドックス
  • 第五章 むかしむかし……トヨタは顧客重視を通じてどのようにナンバーワンになることができたのか
  • 第六章 西の荒野へようこそ……君のことはリーンと呼ぼう
  • 第七章 リーンではないもの
  • 第八章 効率性のマトリックス
  • 第九章 これがリーンだ!
  • 第一〇章 リーンオペレーション戦略の実現
  • 第一一章 あなたはリーン?釣り方を学ぼう!
  • エピローグ 無駄のない装いを!

フロー効率はサービスを受ける目線で考えること

本書を読む前、

フロー効率は複数のタスクを複数人で同時並行して進めるのではなく、一つ一つのタスクをみんなで早く終わらせるように進める考え方だと思っていました。たとえば、A、B、Cというタスクがあれば、3人が同時並行で進めて3日後にA、B、Cのタスクが終わることがリソース効率、3人で一つずつ進めて、1日目にA、2日目にB、3日目にCのタスクが終わらせることをフロー効率だと思っていました。

そして、本書を読んでそういうことではないと気づきます。

フロー効率とはニーズが発生してから解決するまでの時間で価値を受けている割合だと紹介されています。フロー効率が高いとはその割合が高いことです。病院の受診が例にあげられていました。患者が多くてなかなか自分の番がこない状態はフロー効率が低いです。ただ、お医者さんの立場から見ると常に診察していて稼働率が高いためリソース効率は高いと言えます。

処理する側の目線で考えると自分たちが常に稼働していれば効率的に見えるため、フロー効率の意識が薄れそうです。そこで、サービスを受ける側の目線で考えるとフロー効率が高いか低いか見つけられそうです。

開発だとプロダクトバックログに積まれてからリリースされるまで、処理されている割合を調べるとかですね。

フロー効率を影響する要素

じゃあ、フロー効率を高めようと考えるときに必要な3つの要素が本書で登場します。リトルの法則、ボトルネックの法則、変動です。

リトルの法則を使うと、「タスクの発生から完了までの時間(スループット時間)=プロセス内のタスクの数×タスクを解決するために必要な時間(サイクル時間)」と考えられます。スループットを短くにするにはプロセス内のタスクの数を減らすかタスクを解決するために必要な時間を減らすかどちらかになります。

ボトルネックの法則The Goalでも登場しましたが、プロセス内に複数のサブプロセスがあったとき一番サイクル時間の長いプロセスです。ボトルネック以外のスループットを上げても、ボトルネックで詰まってしまうため、プロセス全体でみると変わらないということになります。

変動はそのままの意味で一定にならないことで、1週間当たりのタスク数や人ごとに違う作業時間などです。本書では変動も3つに分類*1されていますが、その変動をコントロールしないと、フロー効率は良くなりません。

個人的にはボトルネックを特定することが重要で、ボトルネックを特定した後に変動の要素がないか調べるという順に改善するのが良いと思いました。そのために、VSM (Value Stream Mapping) があるんでしょうね。

一次ニーズと二次ニーズに分類すると無駄が見つかりそう

一次ニーズとは実際に必要な作業で、二次ニーズは一次ニーズ以外の作業です。たとえば、ボトルネックがありタスク管理が多くなることなど、本来、必要ないこと価値がない作業です。

日々の開発を一次ニーズと二次ニーズに分類すると不要な作業が見つかったりしそうだと思いました。

リーンとはリソース効率よりもフロー効率を優先する戦略

第七章以降はリーンとは何か?という部分について学べます。その中でリーンを3つの抽象度で説明されている部分がありました。哲学や文化としてのリーン、システムとしてのリーン、メソッドやツールとしてのリーン。どれもリーンではあるんのですが、具体的であればあるほど、他業種への持ち運びができなくなります。リーンはトヨタから生まれた考え方で具体的な方法は製造業以外に当てはめにくいです。逆に抽象度の高い哲学や文化については他の業種でも適応できます。

ではリーンとは何か?というと、「リソース効率よりもフロー効率を優先する戦略」だと定義していました。

この定義を理解するには、第七章以降で説明されているリーンの生い立ちを知ると分かりやすいです。「第一〇章 リーンオペレーション戦略の実現」の一部は公開されていますね。

上記のページからの引用で、本書にも登場しますが、下記のように書かれています。「木」は比喩ですが、正しい価値観で決断できたかどうか、過去から学べたかどうかを問い続けることが大切だと書かれています。

  • 今日、我々は木をもっと美しくする決断を下しただろうか? それはどんな決断だった?
  • 今日、我々は木をもっと美しくしない決断を下しただろうか? それはどんな決断だった?
  • 木を明日もっときれいにするために、我々はそこから何を学ぶことができる?

フロー効率を高めるために決断が出来たかどうか、それを問い続け、改善し続けることがリーンへの一歩であり、リーンだと言える状態かもしれませんね。

まとめ

構成が良くて分かりやすい、読みやすい書籍でした!

  • リーンはリソース効率よりもフロー効率を優先する戦略
  • フロー効率はサービスを受ける側が価値を受け取っている割合
  • 取り入れやすいツールやシステムに着目するのではなく、目的を理解し、
    抽象度の高いレベルで取り入れる。

抽象度の高さを注意しないといけない点はアジャイルも同じだと感じました。アジャイルを「デイリースクラム」のような取り入れやすいプラクティスの集まりとして捉えるか、アジャイルマニフェストレベルの抽象度の高い価値観として捉えるかで導入方法が変わってきます。リーンに限らず、何かを取り入れる時は抽象度は意識したほうが良さそうだと思いました。

その他

This is Lean に関する他の方のブログを見つけました。

 

 

*1:3つの分類は本書を手に取ってください

ソフトウェア開発のメトリクスについて調べた

アジャイルではメトリクスを取得し、その数値をもとに改善することが重要とされています。測定していない場合、改善しても効果があったかどうか分からず、その改善を続けるのか止めるのか判断できませんよね。じゃあ、メトリクスは何を取得すれば良いのか。どういったメトリクスがあるのか、調べてみました。

メトリクスを使う注意点

1. ゴールに関連するメトリクスをとろう

メトリクスが重要だからといって、なんでもかんでも取得すれば良いわけではありません。測定した数値を見て改善した結果、ゴールに近づくモノを取得したほうが良いです。ゴールは会社、プロジェクトやチームで立てた目標に影響するかどうかを考えるとよいと思っています。

2. 定期的に見直そう

一度決めたメトリクスはそのまま使い続けず、ゴールの変化に伴って更新したほうが良いです。頻度は多くなくても良いですが、定期的に見直すタイミングを持ちましょう。

3. その時の状況もあわせて記録しよう

特定の週の数値が急に悪化している結果に合わせて、「メンバーが一週間休んでいた」などメモがあると数値の扱い方が変わります。

メトリクスの種類

調べることで色々な種類のメトリクスがあることを知りました。調べた内容を「生産性」「品質」「ビジネス」「チーム」に分けてまとめたいと思います。

◆生産性

リードタイム

ひとつのタスクが開始されてから終了するまでの時間。改善するには作業を効率化するだけではなく、タスクの流れを把握し、ボトルネックを見つける必要があります。

サイクルタイム

一つのタスクがプロセスの一部を終えるまでの時間です。たとえば「実装とレビュー」などです。リードタイムはタスクが開始されてから終わるまで、サイクルタイムはその中の一部になります。

ベロシティ

1スプリントで完了可能な数値です。ストーリーポイントを使われることが多いです。ベロシティは計画を立てるときの基準になります。

バーンダウン

スプリント中の進捗を表すグラフです。スプリント期間中に予定していたタスクが完了するかどうか予想を立てることが出来ます。

スループット

一定期間で開発できるタスクの量です。スクラムを採用している場合はベロシティとほぼ同じだと思います。リードタイムが早ければスループットは多くなります。

仕掛の数

仕掛はWIPと呼ばれることもあります。作業を開始したが、何らかの理由で次の工程に進められないタスクの数です。プロセスの中で仕掛りの数が多い部分はボトルネックになっている場所です。例えば、レビュー待ちが多くてテストが開始できていない!などです。

納期厳守率

納期や約束を守れたかどうかです。この指標だけでは改善ポイントを見つけることは難しそうですが、悪い状態になっていることに気づきやすい指標だと思います。

◆品質

平均故障間隔(MTBF)

稼働してから停止するまでの時間です。

平均修復時間(MTTR)

停止してから復旧するまでの時間です。

見つかった不具合の数

スプリント期間中に見つかった不具合の数です。不具合の数だけでなく、開発したタスクの難易度など組み合わせて見ることが重要です。

バグ修正を解決するまでの時間

MTTRと似ていますが、不具合が見つかってから修正するまでの時間です。未解決のバグ多い場合は開発が厳しい状態だと判断できます。

パフォーマンステスト

ボタンをクリックしてからの応答時間など、システムの性能の測ります。基準を設けて異常値かどうか監視する必要があります。定期的に確認していると、異常値の原因を見つけやすいですね。

◆ビジネス

価値要求と失敗要求の数

価値要求は新機能の開発や既存機能の改善です。失敗要求は不具合修正や仕様不具合の修正などです。失敗要求が多い場合は品質に問題があると考えられます。

破棄項目

開発途中に開発中止になった機能の数です。多い場合はパフォーマンスにもモチベーションにも影響するため改善が必要です。

NPS(ネットプロモータースコア)

「プロダクトを友人に薦めるか?」0~10で評価した結果です。

ユーザインタビューやアンケート

ユーザインタビューやアンケートで定量的、定性的な結果です。

◆チーム

アジャイルの車輪など

アジャイルの車輪はSCRUMMASTER THE BOOKに登場したツールで、以下の12の項目に対して期待値と現状を評価します。

  • 市場に出すまでの時間
  • チームの健康
  • チームのコラボレーション
  • チーム外とのコミュニケーション
  • 継続的改善
  • 効率性
  • 品質
  • 変化への反応
  • 顧客からフィードバックを得る
  • デリバリーの予測可能性
  • 顧客満足
  • 生産性

今回、まとめたメトリクスともかぶる項目もありますね。他にも心理的安全性を測る質問など、「チームのありたい姿になれているか?」という質問を定期的にチームメンバーで評価します。

まとめ

調べてみるとリードタイムやベロシティなど、多くのチームで使われているメトリクスがありました。定期的に取得する数値もありつつ、状況に合わせて取得する数値を選ぶという方法が良いのかなと思いました。

だいくしーのスクラムBar #0 に参加した

だいくしーのスクラムBar #0 に参加しました。

chatwork.connpass.com

『Chatwork で取り組んでいる Scrum@Scale の現在』と『本日のお悩み相談』という2本立てでした。

Chatwork で取り組んでいる Scrum@Scale の現在

Scrum@Sacaleとは
  • Scrum@Scaleガイドがある

scruminc.jp

Chatwork さんのScrum@Sacale の実装(特徴)
  • SoSのデイリースクラムに参加する人は課題を持った人や挙手性
  • 週1のEATミーティング
  • 各チームでスクラムイベントがある
質疑応答

デイリースクラムで情報が高速に共有されるので今のところ劣化は感じない。ボトムアップの情報はEATまで上がったあと、解決策の情報はトップダウンから全体に周知するようにしている。

  • POのスケールは難しくないか

かなり難しい。育成は課題だが、キャリアとしては面白いのでやりたいという声はある。

お悩み相談

お悩み:スクラムをスケールさせて、各チームの情報を高速に繋ぎたい

  • 単一のプロダクトを大人数で作る場合はLeSSが有効
  • チーム間の情報共有を改善するならScrum@Scale のプラクティスを採用すると良さそう
  • 専任スクラムマスターの価値を理解してもらうのは難しいが、自己組織化したチームができるとピープルマネージメントの負担が減る
  • Scurm@Scaleは12のコンポーネントがあるので、優先順位つけて1つずつ実装するのが良い
  • 12のコンポーネントを自己採点して、変革バックログを作って進めている

まとめ

大規模スクラムで名前があがるLeSSは本を読んだことがありました。Scrum@Scaleはガイドがあるんですね。短くまとめられていて、概要を知るにはちょうど良い資料を知れました。今回、1番印象に残った部分はScrum@Scaleの12のコンポーネントを自己採点して、変革バックログを作ることです。理想との差分を確認し課題を見つけること。課題に優先順位をつけて解決すること。言葉にすると当たり前のことですが、僕はまだまだ出来ていないと感じました。

雰囲気はゆるい感じ、でも内容は学びがある。そんな良いイベントでした。ぜひとも次も開催していただきたいなっと思いました。

運営の皆さま、参加の皆さま、ありがとうございました。

The Goal(コミック版) を読んだ

The Goalのコミック版が2021/11末まで無料で公開されていたので、読んでみました。内容は公開されているので、ぜひ読んでみてください。本記事では読んだ感想をまとめておきます。

promo.diamond.jp

生産性とはゴールに近づけること

本書では生産性とはゴールに向かって近づけることと定義しています。部分的に効率を上げてもゴールに近づく速度が変わらない場合は生産性はあがっていないということになります。

ボトルネックを見つけて改善

じゃあ、どうやって生産性を高めるのか。それが、本書が伝えたいことだと思います。その方法はTOC(制約理論)です。工程のボトルネックを見つけて、そこを改善することで生産性を高めます。

ドラム・バッファー・ロープ

ボトルネックを改善するヒントになるのが、DBR(ドラム・バッファー・ロープ)です。ボトルネックの速度に合わせて仕掛り品の作成を減らし無駄な在庫を減らします。さらに、ボトルネックの速度を改善することで生産性を高めます。

カンバン仕事術 に似ている

「カンバン仕事術」と似ていると感じました。カンバン仕事術はWIP(仕掛り)を制限して、ボトルネックに対して見える化したり改善をすすめていました。

iucstscui.hatenablog.com

まとめ

  • The Goalのコミック版は手軽にTOC、DBRが知れる
  • コミック版はストーリー仕立てで、分かりやすい
  • ボトルネックを見つけることからスタート

git diff で コミット間に変更されたファイルの一覧を取得する

git diff で コミット間に変更されたファイルの一覧を取得する方法を確認したのでまとめておきます。

方法

--name-only オプションをつけることで変更があったファイル名だけ出力できます。コミット間はコミットのハッシュ値を「..」で繋げることで指定できます。

$ git diff --name-only <commit>..​<commit>
test/test4.txt
test2.txt
test3.txt

ディレクトリ階層も維持したまま出力されます。


似たオプションで --name-status があります。こちらは、名前と変更のステータスが表示されます。

$ git diff --name-only <commit>..​<commit>
A       test/test4.txt
A       test2.txt
A       test3.txt

A は追加されたという意味です。

まとめ

  • git diff --name-only <commit>..<commit>でコミット間に変更されたファイルの一覧が取得できる

Visual Studio Code の Split in Group でエディターを分割

Visual Studio Code の version 1.61でSplit in Group という機能が追加されたので確認してみました。

code.visualstudio.com

使い方

タブを右クリックし、Split in Group をクリックします。
f:id:iucstscui:20211013225052p:plain

そのタブ内で分割できました。
f:id:iucstscui:20211013225125p:plain

同じグループ内の別タブに移動すると分割されていません。対象のタブのみ有効です。
f:id:iucstscui:20211013225151p:plain

戻すときはタブを右クリックし、Join in Group をクリックします。
f:id:iucstscui:20211013225240p:plain

今までとの違い

今まではグループを分けることで分割が出来ていました。その場合は各グループでタブ管理が求められます。Split in Groupはグループ内で分割できるため手軽に感じました。また、タブによって分割するしないが選べるため、①タブは分割して見比べたいけど、②タブは画面をいっぱい広く見たいという場合にも便利そうです。

グループで分割した図
f:id:iucstscui:20211013225319p:plain

まとめ

  • Split in Group は グループの分割とも似ている
  • グループ内で分割できるため、画面は広く使える