ふりかえりに入る前にする2つの質問

現場コーチをやっていると、ふりかえり(例えばKPT)で、いきなり「続けたいこと(Keep)」を出し始めるような場を見かけることがあります。このような場合、往々にしてどこかフワッとしたふりかえりになりがちです。

私は、よく現場コーチでふりかえりをする際に、以下の2つの質問をするようにしています。

ふりかえりに入る前にする2つの質問

1:「前回から今回の間でなにがありましたか?」
2:「前回から今回の活動はうまくできましたか?」

この2つの質問を答えも含めて5分程度でサッとやってからふりかえりに入っていきます。
#こういうのも含めて「ふりかえり」と呼ぶ方もいると思います。

1:「前回から今回の間でなにがありましたか?」

前回から今回の間であったことをそれぞれ思い出してもらい、その思い出したもので印象に残っていることを1人1つずつ話してもらいます。例えば「クライアントに動くものを見てもらった」「◯◯機能をリリースした」「残業しなかった」などです。

何があったかを思い出すこでふりかえりのインプットになりますし、それを実際に口にすることで緊張がほぐれたりして後の会話がスムーズになる効果があります。

ふりかえりのインプットとしてを重視するなら、もう少し時間をとり、言葉を出しつつ付箋に書いていく方法もしたりします。

2:「前回から今回の活動はうまくできましたか?」

うまくできたかどうかを(いったんは主観で)「5段階評価するとしたら?」と1〜5までを指で表現してもらいます。
これも何があったかを思い出すことでふりかえりのインプットになりますし、場によってはなかなか出しにくい「自分の意思を表明する」ことをやりやすくなる効果もあります。
#「前回から今回の間でなにがありましたか?」とセットでやる場合もあります。

またperfection gameという方法を使うこともあります。
perfection game

この「どうだった?」という評価は、ふりかえりの最後でも使うことができます。
なんとなくTryは出ているけど何かモヤっとすると感じの時に、「これまで話したことやここに出ているTryで、最初に出した5段階評価のポイントは変化しそう?」と聞きます。

こういうちょっとした質問を投げかけることで「Tryをやろう」という気持ちにもなりますし、「これ以外にもっとやってみれば良いTryはないのか?」と見つめなおすことができます。

さらに、ふりかえりなどの場で定期的に表明するこの5段階評価のポイントを記録しておくと、チームがプロジェクトを進めていく中でどのような変化があったか?というのを時系列で見ることもできます。
#この「これでうまくできそう?」という表明はふりかえり以外に何か計画を立てたりするミーティングでも使うことができます。

このようにいきなりふりかえりをするのではなく、ちょっとした質問を投げかけることで、「正しいものを正しくつくる」現場に近づいていくと考えています。

最後に

このような現場コーチの活動を始めとして、ギルドワークスのやっていることに興味を持った方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください。

このブログでは他にふりかえりのTipsとして以下のようなエントリに書いているので、興味がある方は読んでみてください。
Tipsその1:「根本的な帰属の誤り」
Tipsその2:Problemの深堀りの質問
Tipsその3:安全な場を作るためのグランドルール
Tipsその4:ふりかえりのふりかえりをやってみる
Tipsその5:TryをActionに分解する
Tipsその6:空中戦のミーティングに対してやってみればいいこと

※参考:「これだけ! KPT」「リーン開発の現場 カンバンによる大規模プロジェクトの運営
※アイキャッチの写真:https://www.flickr.com/photos/dpstyles/4835354126/

空中戦のミーティングに対してやってみればいいこと

ミーティングがうまく進まないと「正しいものを正しくつくる」ことはできません。

ミーティングがうまく進まない原因として、「議論が見える化されておらず空中戦になる」「参加者に当事者意識を持っておらず発言が少ない」など色々な事象と原因の組合せがあります。その中の1つに「ファシリテーターが議論に入ってしまうことで、場が進まなくなったり、議論の流れを見失ってしまう」というのがあります。

こういうミーティングの時、当事者以外の人にファシリテーターをやってもらうことでうまくいくことがあります。
#現場コーチがそのままファシリテーターをすることも多いです。

当事者以外の人にファシリテーターをやってもらうメリット

1:当事者全員が会話、議論に集中することができる

複雑なテーマや考えることが多いテーマの場合、やはりそれぞれの議論に集中し、深く思考する時間、集中力が必要になってきます。一方、ファシリテートも別の視点で高い集中力が必要になってきます。その両方を十分にうまくやることはなかなか難しいことです。

2:アジェンダを考えるようになる

ファシリテーターを別の人に頼むには、その場の目的やアジェンダなどを伝える必要があります。
いきなり何もなくてポンと任されてもファシリテーターも困ってしまいます。

現場コーチをしていると「アジェンダがないミーティング」が時々あります。そういう時は「どういう目的で、何をどんな流れでやろうと考えています?」と当事者からヒアリングをします。その結果、準備が整っていないことや、そもそもミーティングが不要だったことが分かるということもありました。

ですので、ミーティングの準備としてアジェンダを考えるため、ムダな時間の使い方を防ぐこともあります。

3:新しい視線を得られる

当事者以外のファシリテーターはそのテーマに対して当事者達が持っている思い込みから距離が遠いところにいます。それ故、場や議論を俯瞰することができます。
それによって、当事者では見えていない新しい切り口や論点を見つけることができる場合もあります。
岡目八目的な効果です。

また当事者だと厳しいツッコミや指摘を(事情が分かっている故に)躊躇してしまうことがあります。が、当事者以外であれば、そこは空気を読まずに踏み込んでいくことができます。

4:自分のチームに持ち帰ることができる

これはファシリテーター側のメリットですが、別のチームのふりかえりにファシリテーターとして参加した場合、そこでのKPT(特にProblemに対するTry)を自分達のチームに持ち帰り、よりうまくやるためのヒントになります。

今回は、(この「ふりかえり」のTipsシリーズで扱っている)ふりかえりそのものではなく、ファシリテーターのことについて書いてみました。ふりかえりのTipsは以下のようなエントリに書いているので、興味がある方は読んでみてください。
Tipsその1:「根本的な帰属の誤り」
Tipsその2:Problemの深堀りの質問
Tipsその3:安全な場を作るためのグランドルール
Tipsその4:ふりかえりのふりかえりをやってみる
Tipsその5:TryをActionに分解する

※アイキャッチの写真:https://www.flickr.com/photos/tiarescott/69821764/

現場改善でハマる罠

ギルドワークス 前川です。

ギルドワークスでは、様々な現場に入り込んで現場改善を行っています。もちろん皆さんの現場でも、様々な改善が試行されているのではないかと思います。そんななかでハマりやすい罠について、今日はお話します。

改善をリードする立場とされる立場の間の意識ズレ

あなたが現場改善をリードする立場だった時、あなたの頭のなかには、それが最高にうまく行った場合のバラ色の未来が思い浮かんでいることでしょう。

しかし、改善というのは大抵、即効性のある効果があるものではありません。これまで慣れたプロセスを変えてしまったら、どこかで不慣れによる作業効率の低下や、手順が変わったことによるミスなどがでてくるでしょう。

あなたにとっては、それは改善の効果が出るまでの一過性の痛みに過ぎません。しかし、他のメンバーにとってはどうでしょう?

「いらんことをされて、面倒くさくなった」と思われていませんか?

それを、「分かっていない。利点が見えていない。ずっと使っていたら分かってくれるはず。」と無視するのは簡単です。しかし、そんなふうに強引に進めた改善がたどるのは、早晩打ち捨てられてしまう衰退の道です。

改善をスムーズに進めるために

では、どうすればいいか?

そこに大切なのは、「誠意」です。

丁寧な説明でその「誠意」が事足りる場合もあるでしょうが、もう少し踏み込んだ対策として、即効性のある短期的な改善を組み合わせる、ということがあげられます。

たとえば、バージョン管理システムを新たに取り入れることを考えてみましょう。さきのことを考えると、自分の更新を追うことができ、またいつでも戻ることができる、というのは大きなメリットです。

しかし、最初の導入では、多くの人は「”コミット”とかいうわけのわからない手順が増えてしまった」「新しいツールを導入して怖い」「勝手にマージされて壊れたりしないのか?」などの不安や手間を考えてしまいます。

そこで、バージョン管理の利点を語って皆が納得すればよいのですが、それで納得できない人もいます。

そういう人には、先述した短期的な改善を組み合わせて提示するといいでしょう。例えば、コミットフックの機能をうまく使って、エラーを自動検知したり、同時にJenkinsも導入してテストを回してみたり、など、多少導入の手間が増えてしまっても、メリットがすぐ受けられる、即効性のある改善とセットにするのです。

このように、改善を進めていく側だけの目線や都合だけでなく、改善の結果を受け取る人達の気持ちにも寄り添っていく姿勢が、現場改善では重要となる場合が多いです。

自信と傲慢は違います。皆さん、その点気をつけて、現場を良くしていきましょう!

ギルドワークスが、そのお手伝いをできるのならば、お気軽にお問い合わせください。

アイキャッチ: http://fav.me/d4gqh5o

やりたいことができない場合は小さく分解すればいい

こんにちは、ギルドワークスの中村 洋です。

皆さんの現場では「ふりかえり」であがったTryはどれほど実行されているでしょうか?

一見良さそうなTryが出て、チームもそのTryに合意しているが、次のふりかえりで聞いてみると実行されていない」という現象を見聞きします。特に手強いProblemに対するTryや、(壮大な遠い目標を掲げた)新しいチャレンジとしてのTryなどはその傾向は強くなります。
このようなパターンの場合、ふりかえりの会話で「◯◯のTryをやろうと思ったのですが、”いろいろ”あってできませんでした…」という会話が出てきます。

このパターンが続くと「結局Tryを出しても何も変わらない」と雰囲気が沈みがちになりチームのパフォーマンスが落ちたり、Problemが解決されず大きな問題が発生するといった悪影響が出てきます。このようなパターンが発生する原因はなんでしょうか?
続きを読む

実装パターン本やXP本に登場する「価値」とはなんだろう?

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

どちらもKent Beckの著書である、XP本実装パターン本に登場する価値と原則。

その内容については触れられる機会が多いと思いますが、
価値・原則とはそもそも何なのか?という点を考えたいと思います。

特に今回は「価値」に絞って考えてみます。

実装パターン本による「価値」の解説

当初、この記事を書くにあたって、「実装パターン」の価値についてのみ考えるつもりでした。
しかし、「実装パターン」で語られている価値についての説明は、

  • 普遍的で包括的な主題。
  • プログラミング時におけるあらゆる決定を左右する。
  • 価値は(パターンという行動を起こす際の)動機を提供する

ぐらいにしか、解説されておらず、なんとなくわかるのですが、なんとなく曖昧な説明に思えました。

そこで、同じく価値・原則・プラクティス(実装パターン本もパターンのことをプラクティスと言っている箇所があります。)形式で書かれているXP本の方も調べてみました。

XP本における「価値」の解説

XP本にて、価値について説明している箇所を抜き出してみます。

  • (園芸の例えより、剪定のプラクティスを理解するだけでなく、木全体・庭全体を捉える方法を指して)このレベルの知識と理解を価値と呼ぼう。
  • 価値とは、ある状況における好き嫌いの根源にあるものだ。
  • 価値とは、目にするものや考えていることなどを判断するための大きな基準である。
  • 価値は、プラクティスに目的をもたらしてくれる。

実装パターン本よりわかりやすい説明です。さらに、

価値がなければ、プラクティスはすぐに機械的な作業になってしまう

この箇所で理解できました。

実装パターンもXPも多くのプラクティス(パターン)が載っていますが、それらをただ実施するだけでは意味がありません。

例えば、ペアプログラミングを上司を満足させるためだったり、やってみたいからという理由で行っても意味がないということです。

また、コミニュケーションに不満があったり、チームのメンバー間がお互いに無関心といった問題を抱えていたらペアプログラミングというプラクティスが有効かもしれません。(「コミュニケーション」と「リスペクト」はそれぞれXPの価値の一つ)

最後に、実装パターンの価値やXPの価値は「実装パターン」を、または「XP」を方向付けるための価値であって、自分自身や、チーム、会社、またはビジネスのための価値とは必ずしもイコールではないという点に触れておきたいと思います。

これらはXPの原動力となる価値である。組織、チーム、あなた自身が、その他の価値を選択しても構わない。・・・チームがそれらの価値を共有すれば、XPの価値がプラクティスを作り出すのとは違ったやり方で、自分たちのプラクティスを作り出すことができるだろう。

とXP本の価値の章の最後にありました。

逆に言えば、XPや実装パターンの価値とチームの持つ価値が一致していれば、XP本や実装パターンの各プラクティスはチームに大きな力をもたらしてくれるということではないかと思います。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

定冠詞”the”の重要性を、アジャイルマニフェストから学ぶ。

ギルドワークス 前川です。

自信を持って言えるほどではありませんが、英語はちょっとは読み書きできます。そもそも英語の強さは、二種類あると思います。

一つは、語彙力。じつはこれ、僕はあんまりありません。なので結構英辞郎やロングマンの英英辞典を引っ張ってくることは多いです。

もう一つが、文法力。というか、英語のルールを知っておくこと、ですね。こっちのほうが僕は少し得意です。

文法と聞くと、あんまりいい顔する人はいないでしょうが、本来英文法ってのは英語の考え方を知るためのツールなんです。なので、幾つか知っておくだけで格段に英語の見方が変わりますよ。

そんなわけで、恐らく最も簡単な英単語の一つ、にして、多くの人が重要性を意識せず使っている”the”についてお話します。

定冠詞 “the”

“the”は文法上の分類で「定冠詞」と呼ばれます。「定冠詞」があれば「不定冠詞」はあるのか?というと、あります。”a”です。どちらも英語を勉強してごくごく初期にでてくるものですね。

この2つの違いは何でしょうか?実はもう名前の時点で答えが出てるんですが、定まったもの=文脈上一意に特定できる/するものを定冠詞で表します。バカみたいな例で恐縮ですが。

This is a pen.

は単独で意味が通りますが、

This is the pen.

は文単独では意味不明です。“the pen”ってどれなの!?となります。なので、例えば。

I found a pen yesterday. This is the pen.

みたいに文脈を付けないと意味がわかりません。

このように、”the”にはそれが指すものが一意に特定できている、という暗黙的な意味があるのです。逆に”the”を付けなかったり、”a”を使う場合には、これはふわっとした一般論を指しているという意味合いがつきます。

アジャイルマニフェストと原則における”the”の扱い

では、具体例としてアジャイルマニフェストアジャイル原則の原文を見てみましょう。

まずは、あまりにも有名なマニフェストの4つのセンテンスを引用します。

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

いかがでしょうか?そうです。Theは欠片もでてきません。マニフェスト中でTheがでてくるのは

That is, while there is value in the items on the right, we value the items on the left more.

このように、上に書かれている4センテンスで既に挙げられているものの、左のほうなのか右のほうなのか、を指定している部分だけなのです。

では、アジャイルの12の原則ではどうでしょうか?一つ目からいきなり、こうです。

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

the customer“なんです。特定できて、目の前にいる、そのお客さんなんです。

公式日本語訳は、こうなっています。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

もちろん意味は正しいし、日本語としても綺麗です。でも、この訳だと原文は”a customer”や”customers”でもいいんです。

「顧客満足を再優先する」だけでは、あまりにも元の英文が持つ鋭い意味合いから乖離してしまっている。

だって現場には目の前に製品を届けるお客さんがいるはずなんですから。「現場のお客様を」とか「目の前のお客様を」とかの方が良い表現に思えます(語調は汚くなりますが)。

他の原則はどうでしょうか?例えば、三番目のセンテンス。

Business people and developers must work together daily throughout the project.

“the customer”だけでなく、”the project“です。プロジェクトも、メンバーがちゃんと全員”the project”と言える状態に、メンバー全員が自分ごととして認識して「そのプロジェクト」で通じる状態になっている、という前提なんです。

このように、アジャイルマニフェストとアジャイル原則は、定冠詞という観点から見ると大きく印象が異なるものです。言ってしまえば、アジャイルマニフェストは一般論としてのふわっとした言葉です。

対して定冠詞が非常に多く登場し、対象が明確化されるアジャイル原則は、より開発現場に近いところで利用する実践的な言葉、といえます。

このような視点で、一度アジャイルの原典であるこの2つの文章、英語で味わってみるのはいかがでしょうか。

ユーザーストーリーの”INVEST”とどう付き合うか

ギルドワークス 前川です。

ギルドワークスで開発を行うときは、ユーザーストーリーを使ってタスクを管理することが多いです。その際に気をつけていることをまとめてみたいと思います。

ユーザーストーリーの”INVEST”

ユーザーストーリーをつくるときに意識するのは、おなじみ”INVEST”と呼ばれる、優れたユーザーストーリーが満たすべき特性です。

ちょっと復習してみましょうか。

Independent 独立している。先行するストーリーが完了してないと始められない、など他の影響を受けない。
Negotiable 交渉可能である。ストーリーが具体的なタスクに落ちすぎておらず、プロダクトオーナーと実現方法について交渉することができる。
Valuable 価値がある。ストーリー単独で顧客にとっての価値があること。
Estimable 見積もり可能である。ストーリーを実現するのにかかる時間が(他ストーリーとの相対時間として)見積もれるだけ、十分な情報があること。
Sized Right (Small) 適切な大きさである(小さい)。チームが開発を回していくにあたって、ストーリーを実現するのに要する時間が長すぎない程度に、適切なサイズに分割されていること。
Testable テスト可能である。そのストーリーが完了したかどうかをテストできること。受け入れ条件が明確になっていること。

このINVESTをしっかり意識したストーリーを作れば、うまくユーザーストーリーで開発を回すことができます!・・・って果たしてそうなんでしょうか?実は、”INVEST”全てを同時に満たすことは、かなり難しい、もっというとすべてを同時に満たすことにあまり意味が無いものなのです。

“INV”と”ES”の違い

例えば、「交渉可能」にしたストーリーって、やり方についてまだまだ交渉の余地を残しているということです。それって、「見積もり可能」 なほど固まっていない、とも言えます。

あるいは、ストーリー単独で「価値を出し」たり、他のストーリーに依存しない「独立した」ストーリーをつくろうと思うと、どうしても「適切な大きさ」から離れていってしまう、なんてことも有ります。

そう、前半3つの”INV”と続く”ES”は、実はコンフリクトするのです。なぜなら“INV”と”ES”は異なる要請から導かれているものだからです。

“INV”は、乱暴に言ってしまえば上流工程寄りのストーリーの捉え方です。システムに必要な機能を洗い出す際に抜け漏れをなくすため、実装時に柔軟な対応を確保しておくため、など要件定義やプロジェクトマネジメント的な観点からストーリーに求める要件なのです。

一方、”ES”は下流工程、つまりいざ手を動かして実装していく時に重要になってくる事柄です。開発チーム内で不幸なコミュニケーション事故がおこらないためにも、「見積もり可能」で「適切な大きさ」になっていなければいけません。

スクラム的なイテレーティブなプロセスを取るならば、まずは”INV”を重視したストーリーを作っておき、いざ実装が近づいてきたストーリーについて、”ES”の観点から見直し、必要に応じて書き換えたりバラしていく、という流れが必要になります。

圧倒的に大切な”T”

しかし、この中で”T”だけは別格です。”Testable”すなわち“受け入れ条件”だけは、ストーリーが生まれた時から死ぬまで明確にしておかないといけません。”受け入れい条件”がブレないからこそ、”INV”から”ES”に振ったとしても、そのストーリーが実現する物事についてブレなく矛盾なく保つことができます。たとえストーリーが分割されて小さくされたり、実現方法が決まって見積もり可能になったとしても、そのストーリーが達成された結果として実現されることは変わりません。

ユーザーストーリーのライフサイクル

このように、”T”をストーリーのかすがいにしつつ、上流寄りの”INV”なストーリーから下流寄りの”ES”なストーリーに変えていく、そんなライフサイクルを意識すれば、よりスムーズにユーザーストーリーを使って開発を行うことができるでしょう。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください。

アイキャッチ画像