新版コーチングの基本を読んだ
はじめに
こんにちは！daimyo404です。
子どもが生まれて勉強会やブログなどから暫く離れておりましたが、 タイミング見てそろそろ復活していきたいと思う次第です。（遠ざかっているとモチベーションの維持ができなくて本当つらい）
今回はコーチングの基本/コーチ・エィを読みましたので自分用のメモにまとめます。
コーチング概論
そもそもコーチングってなんぞや
コーチング学んだっぽい人から、「なんで？なんで？」と詰問されて「いやなんなんだよ、、こっちは答えを求めているんだけど、、」という経験があり、正しく理解しないとなとずっと思っていたというのがファーストインプレッション。
書籍によるとコーチングの定義とは
対話を重ねることを通して、クライアントが目標達成に必要なスキルや知識、考え方を重ね、行動することを支援するプロセスである。
コンサルタントのようにコーチが分析して答えを提示するのではなく、クライアント（コーチを受ける人）自身が目標を明確にして達成していくのを助けるというわけですね。
無意識のなかにあるもの
パーセンテージは若干文献によってばらつきありましたが、自らが意識できていること（顕在意識）は、3~10%程度でそれ意外は前意識や無意識であると言われています。
人の意識と無意識について ｜ ビジネス・夫婦間コミュニケーションの問題を解決するコーチング
日常でも言われてハッとしたこととかあると思いますが、ちょっと考えれば分かっていたけどということも多々ありますので、そこをコーチとの対話のなかで掘り起こしていくプロセスというわけですね。
選択的知覚
有名どこだと、カクテルパーティー効果のアレです。
心理学用語「選択的知覚」とは？意味と具体例をわかりやすく解説 – スッキリ
強く関心を持った情報を、大量の情報からふるい分けて認識する能力が人間には備わっています。様々な情報から対話を通してフォーカスさせることも重要になってきます。
コーチングが機能する条件
冒頭に書いた内容に近いですが、無闇矢鱈に相手の内省を促す質問を投げればいいかというとそうではありません。一例として、相手の精神状態、成長段階、課題領域という3つの判断基準に注目するというものがあります。
精神状態
内省する暇もないような状態でコーチングを受けてもあまり意味がないので、対話に参加できるエネルギーレベルや精神的な安定が必要になります。
成長段階
コーチングの際、いつでも同じアプローチを取ればいいかというとそうではなく、相手の能力レベルと意欲を読み取りながら変えていくのがいいとされているようです。
#111 能力・意欲マトリックス : LIFENAVI COACHING
意欲は高いが能力が低いケース
なんとなく想像でイメージつくと思いますが、ここはコーチングは機能し辛いです。能力が低いためにアウトプットの質などに自身が持てない状態が続いては、段々と意欲まで削がれてしまいます。なので、ティーチングでリードしていく方が効果的なケースが多い。
能力は向上しているが意欲が低下している場合
成長段階の多くの人は、自分自身が気づけていなかったり、走り続けているなかで意欲が低下していくケースが少なくないです。このような状況に直面している人がコーチングが効果的で、コミュニケーションのやり方を「認める」、「理解する」、「考えさせる」にシフトさせていきます。
また、過度な介入は本人の自尊心を傷つけるリスクがありますので、「観て」必要に応じて支援する動きが必要になってきます。
コーチングの流れ
専門のコーチになりたいわけではないので割愛しますが、実際の流れは以下を参考。
コーチに必要な視点や価値観
PBP
コーチに必要と言われる視点にPBPというものがあります。まとめるの疲れてきたので下記参考。
コーチングの三原則
クライアントの関わり方における、双方向、継続性、個別対応という3つのマインドがあります。 このあたりは文字通りという感じで、きちんとクライアントに合わせたりしましょうとかそういう感じです。
コーチングの定義と三原則 | コーチングとは | コーチ・エィ アカデミア
テクニックっぽいこと
知っていることも結構ありましたが、テクニックや知識的な部分をまとめていきます。
コーチングの代表的なスキル
下記の7つがあります。
- 傾聴
- ページング
- 質問
- アクノレッジメント
- フィードバック
- 提案
- 願望
傾聴で気をつけないとと思ったポイントは、相手のノンバーバルな情報を受取ること、聞いているというサイン（表情やうなずき）、沈黙を共有することかなあと。
質問に関してはチャンクダウンやスライドアウトを上手く使うこと、アクノレッジメントはいくつか承認にも種類があると紹介されていました。
提案のポイントも色々紹介されていましたが、「提案してもいいですか？」と許可を得ることでお節介や命令とは異なるものにとありました。以前お世話になったアジャイルコーチがよくやっていたなあと思い出したり。
自己開示の返報性
これは有名なので割愛。
自己開示の返報性とは？意味とビジネス・恋愛で使えるテクニックを紹介 | トレンディパレット
ほめるための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専任者のはなしとか。
モブプロの発表お疲れ様でした！
RSGT動画同時視聴したりアジャイルの相談したりOSTに参加しました（2021/06/17）
はじめに
RSGT動画同時視聴したりアジャイルの相談したりOSTに参加しました。 ほぼ1テーマで、あとはアリの動画見たり、SFOのはなしとかおすすめの動画の話とかしてました。 （12時以降の話は濃いので現在進行系で飲み込んでいる）
自分が思ったこととかも雑多に書いているので正確性はご容赦ください。
思考力やその他若手に足りてないスキルを向上させるためには
元々のテーマはこんな感じだったのですが、発展して色々話していました。 主に印象に残ったこととかをメモ。
ふりかえりのはなし
色々なツールや手法がありますが、それだけでフォースを働かせるほどのものは少ないみたいな話をしていました。 ふりかえりの目的意識みたいなものは大事、だけどガチガチにやると固くなっちゃうとか。
関係性が出来上がってない状態でやろう！が先行しちゃうとありますよね。 場作りから日頃の関係性構築が大事なんだろうなと。
最近色々なふりかえり手法をやっていて、同じようなものもあるけどものによってやりやすさが違う。 人によって言葉の刺さりが違うっていうのはとても腹落ちしました。
あとはふりかえりを楽しくやるためのゆとり大事だなーとか。 だまって書く時間も良いかもだけど喋りながらこんなことあったねーってやり方もいいかもとか。
ふりかえりとかのファシリテーションで形容詞で問うといいっていう学び。 早速明日からやってみよう。
他の人に対する期待
他の人にこうあってほしいみたいなのが最近多く、自分は頑固なんだなーと反省することがある。
頭ごなしに言われてもなんだよってなるので、偉大なチームとか良い教材を見せるってのはとても良い。 期待を下げれば伸びしろしかないっていう名言もあった。
雑談のはなし
雑談苦手〜って人が多かった。 弊チームはデイリーで自分の今の気分とか、プライベートな話とか一言話したりしてるんですが、 上手く話さなきゃ感がないのがよかったのかも。
このあたりはチームで言語化したい。
雑談って楽しそうに話すとみんな興味持ってくれるなと思うし、それを見るのが楽しいって話もあった。 好きなものをとことん拘るってこういう面でもいいなー。
その他
基本に立ち返ってエッセンシャルスクラムを読む（その１）
はじめに
チームが成熟するにつれて、改めてバックログの良い管理方法を模索したり、技術的負債の立ち向かい方を議論している。
基本的なところから立ち返ってみようということで、エッセンシャルスクラムを引っ張り出して読み始めたのでメモです。
最終責任時点（LRM）
この原則はポッペンディークの研究かららしい。
判断しないコスト＞判断するコストになったらときに意思決定する。十分な情報が得られるまでは意思決定しない。どちらのコストも指数関数的に見えるのでタイミングは逃さないようにという意味なのかな。
仕掛中の作業（WIP）
あんまり意識してなかったけど、計画駆動型開発はall-before-any型アプローチ。 いっぺんにやると効率が良い思想。
あとは改めて遅延コストのはなしとか。
WIPに上限を設けるのを結構前にチームでやり出したけど普通に書いてあった。（ちょっと別の文脈からでしたが）
タイムボックス化
タイムボックス化の恩恵は不必要な完璧主義を避けられること。パーキンソンの法則的なはなし。
できる限り非機能要件はDoDに含める
はい、、という感じ。
よくできたプロダクトバックログ
INVEST以外にもDEEPという概念あり。
技術的負債
大きく3つに分類でき、不可避、ナイーブ、戦略的なものとある。
技術的負債はビジネスと技術的な視点のバランスを取る必要があり、POがいることで合理的に判断できる。PO難易度高い要素の1つ。
ベロシティを使えば負債の金銭的コストわかるとあるが、これはやりたくない。 負債の返済はボーイスカウトルールとバックログの管理とでバランスよくやりたいなあと。
さいごに
本の画像出したかっただけなので、アフィリンクは踏まなくて大丈夫です。
Management3.0のパーソナルマップをやった
はじめに
Management3.0のプラクティスの1つである、パーソナルマップをチームでやってみたので、覚えているうちに気付いたことをメモ。
パーソナルマップとは
自己紹介×マインドマップ×アクティブリスニングをかけ合わせた手法で、簡単に言うといい感じに自己紹介をやるプラクティスです。
気になった方はManagement3.0のトレーニングで詳しく学べるので是非どうぞ。
コンテキスト
- チームメンバープラスアルファの10人で実施
- 新しくメンバーが1名入ってきたタイミングだったのでやってみた
- 1時間枠、1人約4分質問タイム
気付いたこととか
メンバーから出た声や自分で感じたことなど。
関係性が出来上がっている場合、普通に話したいこと話しても良いかも
自分語りすると快楽中枢が刺激されるみたいな話がありますが、人は自分のことを話したいもの。
パーソナルマップやって改めて飲み会的な雑談の場が減ったなあって思ったこともあり、無理に質問形式にしなくても最近あったこととかみんなで話す場にしても良いかも。
無理にやり方に拘るよりはわちゃわちゃやるのが楽しい。
知らない人同士でやる場合
マップになっているので1個の質問だけ掘り下げるよりも広範に聞いたほうが良いのでは精神になったので、具体的に書いたほうが盛り上がる話が振れそう。
人多いと質問し辛いかも、多くても4〜5人くらいがいい？
そのほか
面白いこととかインパクトあるワードセンスが求められる。
あとワイガヤでやってたこともあり、瞬発的な面白さみたいなものが求められたので日頃からトーク力を磨く意志が芽生える。
さいごに
オンライン飲み会に持ち込みたい〜
ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践を読んだ（その２）
はじめに
引き続き、ソフトウェアテストの教科書という書籍を読んだので、気になったところメモです。
組み合わせテスト
因子と水準
例えば以下の要素があったとして、列見出しのテスト対象の機能名や設定項目を因子、因子が持つ選択肢や設定値などが水準となります。
| ブラウザの種類 | 画面サイズ | OS |
|---|---|---|
| chrome | FullHD | Windows |
| safari | - | Mac |
2因子間網羅
なぜ2因子間網羅で十分なのか、出典をきちんと把握してなかったのでメモメモ。
D.Richard Kuhn氏の研究かららしい。
https://www.researchgate.net/publication/3188430_Software_Fault_Interactions_and_Implications_for_Software_Testingwww.researchgate.net
組み合わせテストを全部やるとケース数が膨大になるので、バグの発見数と組み合わせの数のバランスを考えて2因子間を網羅できれば良いのではという考え方ですね。
ペアワイズ法（オールペア法）
上記の2因子間網羅を達成できる、2因子間の水準の組み合わせを全て作る方法のこと。 作成ツールとしてはPICTやPictMasterが有名。
直交法
あんまり書籍では一言で表す定義がなかったのですが、日科技研さんのサイトによると以下の通り。
直交表とは，任意の2因子（列）について，その水準のすべての組合せが同数回ずつ現れるという性質をもつ実験のための割り付け表です
こちらも調べるとテンプレートが出てくるのでそれを活用するのが早い。
踏み込むと数学的な話になっちゃいそうですが、直交法の方が組み合わせ数が多く、3因子間以上の網羅率が高いとのことで、多因子で検出されるバグはこちらの方が発見できる可能性がある。
回帰テストにおすすめな組み合わせテスト
状況に応じてどのテスト技法を使えばいいのかチャートが用意されていました。 組み合わせテストは回帰テストに良いってところは納得なので実践してみたい。
テストドキュメントの項目
MECEに項目を考えるために、IEEEがテストドキュメント項目ってものを出しているらしい。
さいごに
テスト工程で作成するドキュメントのサンプルが載ってたり、ゼロイチで何か始めるにも良さげな書籍だと思いました。まだ手に取ってない方は是非。
ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践を読んだ（その１）
はじめに
かなり前からアジャイル開発におけるQAに課題感があり、色々勉強しているところなんですが、あまり体系立って勉強したことがなかったので、ソフトウェアテストの教科書という書籍を読んでみました。
読んでて気になったところをメモがてらまとめていきます。
狩野モデル
かの有名なやつ。
改めて品質の作り込みが効果あるのかきちんと見極めたい。
productmanager55.hatenablog.com
W字モデル
V字モデルの発展型のようなW字モデルというものが存在するらしい。
思想的には類似開発経験のあるQAが上流から参画してドキュメント等の確認により手戻りをなくす、工程が終わったらV字の相対する工程の計画をする（要求定義だったらシステムテスト計画とか）という進め方をするらしい。
利用しているプロジェクトは今の所聞いたことはないし、上流工程で検出されるバグが下流工程で見つかるようなケースとかまあまああると思うので、そういったときの手戻りがありそう。
カバレッジ基準
カバレッジってC0〜C2とかよく言うけど、正式な名称を知らなかった。
あとよく混乱するのでまとめておく。
| 名称 | 略称 | 一言で説明 |
|---|---|---|
| ステートメントカバレッジ | C0 | コードで書かれている命令文を実行 |
| デジジョンカバレッジ（ブランチカバレッジ） | C1 | 各IF文のTRUE・FALSEの両パターンを実行（要は判定条件を満たす） |
| コンディションカバレッジ | C2 | IF文の全ての条件文のTRUE・FALSEを実行 |
| マルチプルコンディションカバレッジ | MCC | C2の組み合わせ全パターンを実行 |
※ IF文の条件部分＝条件文、TRUE・FALSEの場合に実行されるブロック文＝命令文 としてます
テストフェーズ
以下の順で実施。
最近はそんなことないですが、あんまりテスト設計ってワードに今まで馴染みがなかった。
- テスト計画
- テスト設計
- テストケース作成
- テスト実施
- テスト報告
機能観点一覧表
前職のガチガチWFでは作ってたかもしれないドキュメント。 作成にあたりインプットになりそうなもの。
- ISO/IEC 9126の品質特性
- Ostrandの4つのビュー
- Myersの14のシステムテスト・カテゴリ
状態遷移テスト
状態遷移図を用いたテストの総称らしい。
このあたりを読んでいて、 非同期でプログラム組むことが多いのでなんかうまいこと使える手法ないんかなって思った。
状態遷移表を少し改造？して、表の行見出しに状態、列見出しにイベントや動作、交差するところに結果みたいな感じとかどうかな。ファイルダウンロード中に画面切り替えたらAPI打鍵キャンセルするかみたいな。
さいごに
後半読んだらその２を書きます。
