この国では犬が

本と芝居とソフトウェア

『THE TEAM 5つの法則』は組織内の「常識の違い」を乗り越えるためのツール #THETEAM #エンジニアリング組織論への招待

5/9 にリンクアンドモチベーションで開催された、『THE TEAM』と『エンジニアリング組織論への招待』のコラボイベントに参加してきたので、そのレポートです。

connpass.com

僕はどちらも読んでいて、特に『エンジニアリング組織論への招待』を書いた広木さんの語り口の鋭さはとんでもないなと思っていたので、面白かったけれど個人的にはやや消化不良感もあった『THE TEAM』著者の麻野さんとどういう話をするのか、だいぶ楽しみにしていました。

イベントの流れ

イベントはパネルディスカッション方式で、『THE TEAM』に示された「5 つの法則」のうちの 3 つについて、それぞれ麻野さんが語り、広木さんがコメントを差し込んで膨らます、といった流れで進みました。

モデレーターは、広木さんと同じレクターの松岡さん。

  • Aim(目標設定)の法則
  • Boarding(人員選定)の法則
  • Communication(意思疎通)の法則
  • Decision(意思決定)の法則
  • Engagement(共感創造)の法則

これら 5 つのうち、Aim、Boarding、Decision の 3 つを BAD の順に取り上げて話していくスタイルでした。

パネルディスカッションの様子

イベントに参加されていたおかしんさんという方が、なんとイベント全体の書き起こしを公開されていました。すごい!!

note.mu

ということで、ディスカッションの中身はこちらを見ていただくのが早いし正確です。

以降、この記事では、ディスカッションの中で僕が特にティンと来たところだけピックアップしてご紹介していきます。
一部発言については、こちらの書き起こしから引用させていただきます。

「Boarding の法則」の 4 象限モデルは、「常識」が異なることを前提として対話するために使える

『THE TEAM』の「Boarding の法則」は、縦軸に「環境の変化度合い」、横軸に「人材の連携度合い」を取った 4 象限のモデルで説明されています。

環境の変化度合いに応じて「流動的なチーム」か「固定的なチーム」かを決めたり、人材の連携度合いに応じて「多様性」を重視するか、「均質性」を重視するかを決めたり、といったことです。
この議論自体には納得感があって、わかりやすく整理されていると思います。

でも、僕がこれを読んだとき、「自分たちが 4 象限のうちのどこにいるかって簡単にはわかんなくね?」って思ったのです。
それがわかれば苦労しないと。

DataSpider が置かれている「環境の変化度合い」は?

たとえば、僕が会社で作っていた DataSpider という製品について言うと、環境はまあまあ変化します。

「データ連携」の製品なので、当然さまざまな連携先があって、需要も変動します。そもそもソフトウェア製品なので、ソフトウェア技術の変遷の早さの影響もあります。環境の変化度合いは、大きそうです。
一方で、DataSpider はエンタープライズ向けの製品で、新バージョンを 1~2 年に一度リリースしてはいるものの、ユーザによっては数年に一度しかバージョンアップを行わないこともあります。

これは環境の変化度合いが大きいでしょうか、小さいでしょうか?

また、「環境の環境(ここでは、仮にメタ環境と呼びます)」自体も変化していきます。
(日本における)データ連携の世界は、今はまだオンプレミスに基盤を置く方が主流で、前述のようにユーザによるバージョンアップの頻度も必ずしも高くないですが、世界に目を向けると、iPaaS と呼ばれるクラウドサービスでの提供が主流になりつつあり、クラウドサービスなのでもちろんアップデートも随時行われます。

このように、世界における「メタ環境」と、現在の日本の「メタ環境」とでは、「環境の変化度合い」も異なります。
さて、我々がいるのは日本でしょうか、世界でしょうか。その両方でしょうか。

そういうことを考え始めると、我々がいるのは結局どこなんだ? ということがわからなくなるのでした。
「人材の連携度合い」についても、同じようなことが言えます。

エンジニアはエンジニアカルチャーがすべてに適用できるんじゃないかって錯覚しがち

そういうモヤモヤ感を持ちながら聞いていたら、広木さんがドンズバのツッコミを入れてくれました。

自分たちがどこにいるのかな、とか、自分たちの事業がどこにあるのかな、とかっていうのがぱっとピンと来るって、結構センスだなと思うんですよ。

そうそう!
考えてみると意外とわかんないんですよ!

そしてさらに目からウロコが落ちたのが、その議論の流れで出た

エンジニアの人はエンジニアの中でのカルチャーにおける正義っていうのが、常に全ての組織とか全てのビジネスモデルに適用できるんじゃないか、って錯覚しがちな部分がちょっとあって、全然そうじゃないことはたくさんあるな、って思ってます。

という話です。

前述の DataSpider の話でも、僕は無意識のうちに製品開発の視点だけで話してます。「ソフトウェア技術の変遷の早さ」のくだりとか、その典型ですね。
そういうスタンスから、ついつい「環境の変化度合い」も「人材の連携度合い」も大きいんだ、だからサッカー型のチーム、フィーチャーチームこそが正義だ、みたいな結論を出しがちです。

でも、一歩引いてみれば、同じ組織の中でも、部署や仕事内容によって「環境の変化度合い」も「人材の連携度合い」も変わってくるはずなんです。
開発とマーケティングや営業、バックオフィスでも違うし、同じ製品の営業部門の中でも、「パートナー営業」と「ハイタッチ営業」とで少しずつ違ってくるでしょう。
また、それぞれの部門の中でも、DataSpider の開発の話と同じように、何を「環境」として捉えるか? どの「メタ環境」にいると認識しているのか? といったこともそれぞれ異なってくるはずです。

同じ組織内においても、エンジニアの「常識」は営業の「常識」ではないし、わたしの「常識」は(必ずしも)あなたの「常識」ではないのです。

このディスカッションから、僕は「Boarding の法則」の 4 象限モデルは、「常識」が異なることを前提として対話するために使えるということを学びました。
「正解」は(少なくともすぐに掴める位置には)なくて、「私たちって、どの位置にいるんだっけ?」「なんでその位置ってことになるんだっけ?」「部門による違いってあるんだっけ?」ということを対話するために使うわけですね。

「4 象限モデルのどこに当てはまるか」を簡単に判断できないのは必ずしもこのモデルが不完全だということではなく、むしろそのモデルの中で対話を形成していけばいいんだ、ということがわかったのは大きな発見でした。

「Aim の法則」の 3 種類の目標は、メンバーのレベルに応じて使い分ける

「Aim の法則」は、「意義目標」「成果目標」「行動目標」という 3 種類(段階)の目標で説明されます。
それぞれの目標は、以下のように説明できます。

  • 意義目標: 最も抽象的で、どう行動すればいいかはわかりにくいが工夫の余地が大きく、ブレイクスルーが起きやすい。OKR の O(Objective)にあたる。
  • 成果目標: 意義目標よりも具体的で、行動の工夫の余地もある。成果主義MBO における目標や、OKR の KR(Key Results)にあたる。
  • 行動目標: 最も具体的でわかりやすいが、ブレイクスルーはおきにくい。「きちんと挨拶をする」「忘れ物をしない」みたいな、「小学校の通信簿」に近い。

抽象のはしごを行き来する能力を鍛える

この 3 段階による目標の説明はわかりやすく、理解できます。

しかし、どの場面でどの目標を使うべきか? というのが難しいところです。
一番ブレイクスルーが起きやすい「意義目標」を目指すべきだ、と言うのは簡単ですが、結果としてうまくいかなければ意味がありません。

麻野さんからも、

与えられた成果目標と行動目標ちゃんとやるっていうこと以外、日本の学校教育ほとんどやってきていないので、もしかしたらOKRによって皆崩壊する可能性ありますよ。

というコメントもありました。

また、広木さんの

意外とMBOも『ちゃんと目標フォーカスしましょう』とか、意義でも意義目標が『世界をハッピーにする』とかだったら意義もへったくれもない

というコメントにもあるように、意義目標の「達成」以前に、意義目標を「定める」というところがまず難しいわけです。

ここでヒントになるなと僕が感じたのが、広木さんが言っていた「抽象のはしごを行き来する能力を鍛える」という話です。

そもそも「成果目標を行動目標に落とし込んだり、逆に成果目標を超えて意義のレベルで目標を設定したり、といったこと自体が容易には得がたいスキルである」という認識を持つ、ということですね。
だとしたら、どのレベルで目標設定するかはメンバーのレベルに応じて使い分ける必要があるし、ブレイクスルーを生むためにより抽象的な目標を設定するようにしていきたければ、意識的に抽象のはしごを行き来する能力を鍛える必要がある、ということになります。

ここでは、「抽象的な目標の方が創造性発揮できるからいいんだ」といっていきなり「OKR を使います。以上」とやるのではなく、「私たちの今の実力でどこまで抽象的にできるんだっけ?」「どうすれば将来より抽象的な目標設定できるようになっていけるかな?」ということに意識的になる必要がある、という気付きが得られました。

「組織の意思決定の遅さ」には 2 種類の原因がある

最後に取り上げられた「Decision の法則」では、意思決定の仕方には「独裁」「多数決」「合議」という 3 つのレベルがあって、「納得感」と「かかる時間」のトレードオフになっている、という風に説明されています。

合議がいいっていう「先入観」にまず気づく

この議論の中でまず面白いなと思ったのは、麻野さんの

そもそも僕たちの政治のシステムがやっぱり、血統によって決められた王様とか皇帝が独裁するところから、皆で決める民主の力に取り戻していくプロセスだったんで、割と『合議がいい』っていう先入観がある

というコメントです。

「納得感」と「かかる時間」のトレードオフということは理解しつつも、ついつい合議がいいって思ってしまいがちなのは、たしかにそういう先入観というかバイアスがかかっている可能性もあるので意識的になりたいなと思いました。

『THE TEAM』の「チーム」は 3~10 人を想定して書かれている

それから「そうだったんだ」と得心がいったのは、麻野さんの

『THE TEAM』そのものは3人〜10人くらいのチームってのを完全に想定して書いた

というコメントでした。

『THE TEAM』を読んでいて、どの「法則」を取ってみても、この「チーム」っていわゆるチーム(数人程度)のことを言ってる? 数百名を超える会社組織も「チーム」として捉えてる? ということがよくわからなくて、モヤモヤしてたんですね。(もしかしたら書いてあって、読み落としていたのかもしれませんが……)

そこがこのコメントですっきりしました。

そして広木さんが言っていたように、1000 人の組織では、全部トップが「独裁」で決めるよりも、むしろ権限委譲して、下の階層で決める方が早い(「かかる時間」が短い)ということも起きうる。

ここがうまくいっていなくて、何でも上層部で決める、しかも「合議」で、みたいなのが最悪のパターンですね。もうとにかくめちゃくちゃ遅い。すると、組織が腐っていく。
ここには実は、2 種類の問題があるわけです。

  1. 権限委譲ができていないので何でも「上の階層」で決めることになり、下の階層から見て、意思決定が遅くなるという問題
  2. 何でも「合議」で決めるので、その「上の階層」内での意思決定そのものも遅くなるという問題

組織の意思決定が遅い、というとき、この 1 と 2 どちらが主な原因なんだっけ? ということを考えることは、課題解決へのヒントの一つになるように思います。

9 割 No でも元気になる

最後にもう一つめちゃくちゃ面白いなと思った話が、麻野さんの次のコメントです。(少し長いですが引用、強調は筆者)

僕が再生ファンドの人に聞いた話でいうと、腐ってる会社どうやったら組織とかチームとか変えれるかっていうと、社内で生きのいい中間管理職を10人集めて、でファンドの横に社長座らせて、(中間管理職たちに)提案させるらしいんですよ。一人一個ずつ。その場のルールは一個だけで、この場で必ず Yes or No 言ってね。全部にこの場で Yes or No と言わないとあなたもう社長には置いておかないと言うらしいんですよ。
で、提案して、『No』、『うーんNo』とか『Yes、いやNo』みたいにいうと、めちゃくちゃ中間管理職元気になるらしいんですよ。9割が No でも。なんでかっていうと、腐ってる会社って、何を提案しても Yes か No かわからないくらいの反応でずーっと放っておかれるって会社が腐っていくらしいんですよね。
そうすると、そうやってやらせれば『あ、この会社なんか言ったら決まるんだ』って。『やらないってことが決まるんだ』みたいな。

面白くないですか。
9 割 No でも元気になるって。

ある程度健全な組織ではさすがにこれほどのことはないと思うんですが、ある程度不健全な組織では、本当にこういうことってあるんだろうなというのも理解できます。
なお、対策としては意思決定者にサイコロを渡すソリューションが提案されていました。冗談として笑。でも、あると思います。そうすれば、少なくとも前述の 2 種類の原因のうち、2 つめの「意思決定そのものも遅くなる」の方は解決するというわけです。そして、サイコロで決めるくらいなら、下の階層で決めてもらう方がいいんじゃないか、ということになるので、1 つめの「権限委譲ができていない」問題も解決に向かいますね :)

まとめ

内容については以上です。

まとめると、今回のパネルディスカッションで僕が個人的に特に面白いと思ったのは以下の 3 点でした。

  • 「Boarding の法則」の 4 象限モデルを含め、『THE TEAM』の内容は、組織内でも「常識」が異なることを前提として、対話するためのツールとして使える
  • 「意義目標」「成果目標」「行動目標」の 3 段階は、どんなときでも「意義目標」を目指せばいいというものでもなく、メンバーのレベルに応じた使い分けや、目標間を行き来できるようになるための意識的なトレーニングが必要
  • 「組織の意思決定の遅さ」の原因は、「権限委譲の不足」と「合議のやりすぎ」の大きく 2 種類に分けることができる

本を読んでなかなか得心のいっていなかったところに一段階深い理解を得られて、参加した甲斐のあったイベントでした。

パネルディスカッションのあとには懇親会があり、他の参加者の方からも面白いお話を聞くことができました。

主催および会場提供のリンクアンドモチベーションさん、広木さんと松岡さんが所属されているレクターさん、ありがとうございました!

「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた

スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみました。

ものすごく長いので(なんせ 38 個あるので)、以下の目次から興味のある質問への回答だけでも見ていただけると嬉しいです。

なお、最初はかなり丁寧に回答していましたが 5 つ目の質問のあたりでこれ終わらないなということに気づいたため、以降はやや簡潔な回答になっています。

スクラムマスターの役割について

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

スクラムはプロセスの集まりではないし、スクラムマスターの仕事はプロセスを守らせることではない。

スクラムは、透明性・検査・適応を軸として、継続的な対話を促すフレームワークであるといえる。
たしかにスクラムマスターがプロセスを守るようチームに働きかけることはあるが、それはあくまで、チームとしての成長を促すフレームワークを活用して、建設的な対話と学習を促進することに主眼がある。プロセスを守ることが目的なのでは決してないし、プロセスを守ればうまくいくわけでもない。

自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

以下のような兆候があれば、アジャイルがうまくいっている可能性が高い。

  • 以前に比べて、「一気にまとめて」ではなく、日々、段階的に不確実性・リスクを下げられるようになってきている。(例: リリースのスコープの確度が週ごとに上がっていく)
  • 以前に比べて、重要な課題が広く認識され、建設的な対話によってそれを解決する努力が行われるようになってきている。(例: 欠陥が多発していたことの原因がレガシーシステムアーキテクチャにあることをチーム全体が認識し、段階的な設計改善やテストによるアプローチを模索している)
  • 以前に比べて、チーム全体が、作業ではなく、成果にフォーカスするようになってきている。(例: 「いつまでに実装が完了するか?」「ちゃんとテストを書いたか?」という会話よりも、「この機能を誰が使うのか?」「一番重要なことに取り組めているか?」という会話の量が増えてきている)

また、自分の働きの効果を測るためには、以下のような兆候を見る。

  • 前述の「アジャイルがうまくいっている」兆候が見られるか。
  • 以前に比べて、自分が指示・指導を行わなくても、自律的に活動して対話を重ね、経験から学んで継続的にプロセスを改善できるようになってきているか。

追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

チームや組織の状態によって重点メトリクスは変わるが、一般的には以下のようなメトリクスに注目する。

  • デリバリープロセス全体の健全性
    • 要求からデリバリーまでのリードタイム
    • 各プロセスのサイクルタイム
  • 局所的な生産性
    • ベロシティ
    • 各種会議・イベントにかかる時間
    • テスト実行にかかる時間
  • (内部・外部)品質
    • テストカバレッジ(使い方に注意)
    • コード品質(静的解析ツール等を用いる)
    • QA でのバグ検出率
  • チームの健全性
    • 残業時間
    • 発言の頻度・内容(定性的でもよい)

チーム全体としては単一の最重要指標(たとえば、顧客満足度)にフォーカスしながら、そこへ向かうためのプロセスの健全性をいくつかのメトリクスで監視できるとよい。

メトリクスの数値そのものに固執せず、何を知りたいからそのメトリクスを計測しているのかをチームが忘れないようにする。
ボトルネックが移り変わった場合、取得するメトリクスは変更する必要があるかもしれない。

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

以下のような理由が考えられる。

  • タスクの粒度が大きく、スプリント計画の正確性が低すぎる。
  • レガシーコードが原因で、計画時に想定していなかったタスク(既存のバグやアーキテクチャの問題による追加作業)が発生している。
  • 計画時に想定しているほどの稼働時間が取れていない。(例: 1 日 8 時間で計算しているが、会議や休憩時間を除くと実際に稼働できているのは 6 時間程度)
  • そもそも、好ましくない対象にコミットメントしている。(例: スプリントゴールや PBI のデリバリーではなく、全タスクの消化をコミットメントしている等)
  • スプリント中に発生する課題をタイムリーに認識できていない。
  • スプリント中に発生する課題にその都度適応できていない。

以下のような話の切り出し方が考えられる。

  • (具体的な事実や数値を示して)このようにコミットメントを守れていないようですが、それは問題ですか?
  • そもそも、チームは何をコミットメントしていますか? 何なら確実にコミットメントできそうですか?
  • そもそも、なぜコミットメントが重要なのでしょうか?

回答に応じて対話を重ね、開発チームが行きたい方向とスクラムチームとして向かうべき方向とを合わせていく。

製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

もちろんよい。
スクラムチーム全体がそれぞれの視点から製品のディスカバリーに貢献することができるし、ディスカバリーに参加していれば、製品への深い理解を持って、創造的かつ効率的に開発することも期待できる。

ただし、開発とディスカバリーとのバランスのとり方がやや難しく、以下のような課題が出てきやすい。

以下のような指針を試しては、結果を観察して改善しながら、自分たちのチームに合ったやり方を探していく必要がある。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

プロダクトオーナーにすべてを任せず、開発チームもプロダクトバックログ周りの作業に関わってよい。チーム全体で補い合って、プロダクトのことに取り組む。スクラムマスター自身がプロダクトオーナーとペア作業することがあってもよいかもしれない。

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

ステークホルダーにはプロジェクトの早期から、頻繁に連絡を取り、ステークホルダーの関与の重要性を説いて理解してもらう。ステークホルダーは忙しいので、ステークホルダー自身にとっても、有効な時間の使い方ができるよう、コミュニケーションのとり方に配慮する。

どのように複数の異なる部門にまたがってアジャイルマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

異なる部門にとってのメリットを前面に出しながら、興味を持った一部の人たちと一緒に小さく始めて、理解を育てていく。IT じゃないステークホルダーについても基本は同様で、ステークホルダー自身の関心事にフォーカスする。

上級管理職にどのようにスクラムを紹介するか

その上級管理職が重視しているビジネス上の課題を理解し、その課題に取り組むためにスクラムがどう役に立つかを説明する。「透明性・検査・適応」「課題を明らかにする」ことがスクラムの本質ではあるが、それだけでは響かない可能性もあるので、一味つけることも考える。たとえば、ユーザ企業の変化に追従する能力を育てる、開発力の持続的な成長に貢献する、等。(ただし、過度の期待やスクラムへの誤解を植え付ける結果にならないように十分配慮し、一度紹介して終わりではなくその後もフォローアップを続ける)

あなたはすでにステークホルダースクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

まずは 3 ヶ月だけ続けさせてくれないか、同僚にお願いする。もちろん、その同僚がどのような課題があると思っているのかもよく聞き、それにチームとして正面から向き合っていきたいことも説明する。ステークホルダースクラムを理解しているとしても、ステークホルダースクラムの適用を命令させるようなことはできるだけ避けたい。

「激しい抵抗」の経験はないが、「本当に Sprint 単位で製品を完成させるようなやり方が成り立つのか?」という懐疑的な態度には出会ったことがある。当時は組織内で初めてのスクラムへの取り組みで、私はスクラムマスターではなく開発者だった。同じチームのメンバーとして課題意識を共有し、日々の活動を通じてさまざまな取り組みを試してはふりかえって改善を重ね、約 3 カ月後には安定した速いペースでインクリメントを届けられるようになった。

プロダクトバックログのグルーミングと見積りについて

プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか?

その流れ自体は悪くないが、チームからのインプットは「見積り」だけであるべきではない。チームによる技術的なシーズ・制約事項や、その他のアイデアもプロダクトバックログに取り込んで、チーム全体として最良のプロダクトバックログを作り上げたい。ステークホルダーの言っていることが「正しくない」ことも少なくない。プロダクトオーナーはステークホルダーの御用聞きにならず、視野を広く持って、チームも積極的にプロダクトバックログづくりに協力していくのが望ましい。

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

Scrum には、製品について話し、考えるための Sprint Review という時間があるので、そのタイミングで、前回の Sprint Review 以降にわかった短期から中長期までの製品に関わる新しい情報は、何でも話してもらう。プロダクトオーナー自身が何を話すべきかうまく判断できないようなら、チームが何を求めるかを重視する。それでもうまくいかなければ、まずはプロダクトバックログの内容(全体像・優先順位)に直接関わることから話し始めてもらい、慣れてきたら少しずつ会社の全体戦略やマーケットの状況へと視野を広げていく。

誰がユーザーストーリーを書くとよいか?

プロダクトオーナーが第一候補になるが、誰が書いてもよい。また、ユーザストーリーは書くものではなく語るものである。ユーザーストーリーを「ちゃんと書いて」、「要求仕様」と見なすようなことがないように気をつけたい。誰が書いたにせよ、ユーザーストーリーは語られる。ユーザーストーリーについてチーム全体が会話をし、会話から現れてくる価値を届けるための機能を、開発チームが実装する。

よいユーザーストーリーとはどんなものか?どんな構造か?

一般論として、誰が・(どのような場面で・)何のために・何をしたいのかが書かれていてほしい。
また、ユーザーストーリーは階層化したほうがよい。あるストーリー、を実現するためのストーリー群、を実現するためのストーリー群というふうに階層化する。上位階層のものほど、「何のために」にフォーカスし、下位階層のものほど「何を」にフォーカスする。
一方で、「どうやって」は限定しないようにする。「何を」と「どうやって」の間に境界を引き、「どうやって」のエリアで創造性を発揮できるようにすることが、開発チームが活き活きと働くための重要な条件と言える。
また、ストーリーではなく PBI としては、明確な受け入れ条件が指定されているとよい。それが透明性の担保に寄与する。また、受け入れ条件はできるだけ交渉可能になっていると望ましい。そういったよいユーザーストーリーの条件をまとめた INVEST という用語もあり、有用。

「Readyの定義」には何が含まれているべきか?

INVEST のうち、E、S、T が整っていること。すなわち、「見積り」「適切なサイズ」「完成したことを確認する方法(受け入れ条件)」がすべて満たされていてほしい。
もちろん、Ready 以前に V、つまり価値も定義されていることは前提である。(なお I、N は必須ではないと考えます)

なお、そもそも「見積り」そのものは必須ではなく、デリバリーペースの予測に役立つ何らかの手段があって、アイテムがその要件を満たす状態になっていればよい。(#NoEstimates の人たちが言うように、見積りそのものに価値はない)

ユーザーストーリーを時間で見積もらないのはなぜか?

デリバリーにかかる時間は人によって異なり、チームとしての見積りにするのが難しい。サイズ(作業量)の見積りであれば、認識を合わせやすい。
また、デリバリーにかかる時間はチームの状態によっても変わりやすい。チームが新たに学んだことや、開発を担当するメンバーによって、一度見積もった時間は変化する可能性が高い。
サイズで見積もっておけば、それらの変動要因を吸収しやすい。

加えて、時間の議論は「俺なら 1 時間」「私なら 30 分」といった不毛な会話になりやすい。相対サイズの議論なら、どのような作業が見込まれるかにフォーカスして、ユーザーストーリーに潜む穴を素早く見つけることができる。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

もちろん、並行して 200 個のチケットに同時に取り組むことはできない。(できたとしても、する意味がない)

多くのアイテムがある場合(つまり、ほとんどの場合)、ユーザーストーリーマッピングのような手法を用いてバックログを階層化して、構造が見えるようにする。
また、プロダクトオーナーは取り組みの優先順位を明確に定めて、時間軸上で近くにあるアイテムほど、チームで精緻に議論するようにする。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

前提として、プランニングまでに優先順位付けされた Ready な PBI が揃うように取り計らう。
チームには、解決手段だけではなく PBI がもたらす価値にフォーカスするよう促し、複雑な実現手段に固執しすぎているようであれば、プロダクトオーナーとの対話を試してみるよう働きかける。
プロダクトオーナーには、スプリントプランニングに同席することの価値を理解してもらい、少なくとも常に連絡可能な状態を保ってもらうよう働きかける。
また、全体を観察し、状況を書き出すなどして見えるようにする。流れの悪いところがはっきりしたら、チーム自身が気づいて解決できることが理想だが、必要に応じて介入してもよい。チームの自律を奪わないよう気をつけながら、情報がチーム内・プロダクトオーナーとの間でスムーズに流れるように取り計う。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

実装前は、製品ビジョンのどの部分にどの程度寄与する見込みなのかや、期待される収入増加やコスト削減などを、複合的にメトリクスとして用いる。狩野モデルなども有効。価値だけでなく、ROI も重要。プロトタイプを用いてユーザビリティテストを行い、ストーリーの価値を実装前に検証することもできる。

ステークホルダーがそう言ったから」とか、「(たかだか一人の)ユーザがそう言っているから」といった表面的な理由は受け入れがたい。ストーリーは実装する前によく磨かないと、すぐに機能過多の鈍重な製品になってしまう。

なお理想の世界では、ユーザーストーリーは直ちにデリバリーされ、アプリケーションやプラットフォームから直接取得できるメトリクス(滞在時間、コンバージョンレート、アクションの成功率、そのストーリーに紐づく機能の販売数等)に基づいて価値を確認できる。ただし実際は、複数のストーリーが同時にデリバリーされたり、直ちに取得できるメトリクスがなかったりする。その場合、大域的であったり定性的であったりするメトリクス(顧客満足度ユーザビリティテストの結果など)を頼りにすることになる。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

前提として、PO が価値に基づいて優先順位をつけているはずだが、何らかの理由で調整が必要になった場合の話として理解します。
基本スタンスは問いかけ。PO にも、チームにも、「どうしたいですか? それはなぜ?」と問いかける。見解が一致すれば、めでたし。多くの場合、価値・PO がやりたいこととコスト・チームができることとのトレードオフになりやすい。その場合、対立構造にならないよう、事態をお互いの目で見るように促す。ちょっとした思い込み(「このように実装する必要がある」とか)を取り除くだけで、PO とチームの双方が納得できる最善の道が開けることもある。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

目安としては、2 割程度。ただし、そもそもそれらのタスクをどの程度明示的に扱うかはチームによる。リファクタリングや新しい技術の調査は、通常の PBI への取り組みの範疇でできていれば、それでもいい。できていない場合に、最大 2 割程度まで、別途時間を確保したり、PBI として定義して、リファクタリングやバグ修正、技術調査等に取り組むようにする。それらの取り組みが 2 割よりも多くなると、ステークホルダーの期待に十分応えられなくなってくる可能性が高い。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

チームに自己裁量権を認めることで最大の成果を届けられることを説明し、理解してもらう。また、個人にストーリーやタスクを割り当てようとする理由を聞き出して理解し、その理由となる課題を解決するようなアプローチを一緒に考える。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

チーム全体にリードタイム・サイクルタイムの概念を説明し、理解してもらう。また、タスクのつまみ食いは表面的な事象で、別の課題が隠れている可能性もある。たとえば、T 型のスキルセットになっておらず、実施できるタスクが限られているなど。そういった場合、ペア作業の導入が有効かもしれない。いずれにせよ、個別事象(タスクのつまみ食い)にこだわりすぎず、マインドセット、チームとしての目標、スキルやプラクティスといった様々な面からアプローチする。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

スプリントの透明性の確保のために、そのようなアイテムはスプリントバックログに入れないのが望ましい。そのため、プロダクトオーナーにはそのアイテムを今スプリントに入れる必然性があるのかどうか、確認する。また、入れる場合のリスクも説明して理解してもらう。それでも入れるという判断をする場合、これは特殊なオペレーションなので、チーム全体としてそうすることの影響を理解し、試してみることへコミットした状態にする(注意: そうすることへの「完全な同意」や、そのアイテムを確実に届けることへのコミットではない)。そうしておけば、その結果への検査と適応がレトロスペクティブのときにやりやすくなる。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

いくつかの戦略が考えられる。

  • なぜ時間の無駄だと思うのかよく聞いて、対話する
  • スプリントプランニングがチームにとってどのように役立つと見込まれるのか、よく説明する
  • チーム全体でそもそもプランニングをやるべきか、どうやるべきか話す場を設ける
  • ひとまず協力してくれないか、お願いする
  • プランニングをやる・やらない(最小限にする)の両方を試してみることを提案する

おおむね上から順に試してみる。 チームの状態や相手の反応によって、対応を切り替えていく。

スタンドアップやデイリースクラムについて

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

(「スタンドアップ」というのが日次の定期ミーティング、Daily Scrum のことだと想定して回答)
まずはやってみて、しばらくは続けてみることを薦める。
どんなチームにとってもリズムを作ることは重要で、スタンドアップによって日次のリズムを作ることができる。また、頻繁な検査・適応の機会があることで、さまざまな課題を見つけ、対処していける。

人数が多い場合、「3 つの質問」のようなフォーマットにはこだわらず、短時間で最大限の効果が得られるようなやり方を見つけ出していく必要はある。スタンドアップが難しいほどチームの人数が多い場合、そもそもチームの分割を行ったほうがよいかもしれない。

もちろん、達人揃いのチームで、既にスタンドアップよりもよい検査・適応の方法を編み出している場合は、無理強いはしない。(もっともその場合、そのチームは Scrum フレームワークにもこだわっておらず、ScrumMaster の役割も典型的なものとはだいぶ異なっていると想像される)

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

特にスタンドアップを待つことを期待はしない。スタンドアップはコミュニケーションを限定するものではなく、促進するものであり、スタンドアップがあることを理由に日常のコミュニケーション(を通じた透明性・検査・適応の実践)が妨げられてはいけない。(スタンドアップに使われるのではなく、スタンドアップを使う)
いま助けが必要なら、いま求めるべき。

もちろん、緊急性のない事項に関しては、即時ではなくスタンドアップや他の機会に共有してもかまわない。
そのあたりはチームのバランス感覚になるが、一般的に(必要以上に)スタンドアップを待ちがちになりやすいと思うので、そうなってしまっていないか、ScrumMaster が気を配っておくとよい。

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

その人は、なぜ報告セッションにしたいのだろう? もしかしたら、それがミーティングのやり方だと思いこんでしまっているだけかもしれない。だとしたら、スタンドアップの目的を繰り返し説き、場合によってはリードを代わってもらって実践してみせる。チームメンバーにとってほしいアクションを伝えるような話し方を意識してもらったり、逆にあえて雑談をしてもいい。いわゆる進捗会議とは違うということが伝わるようにする。
それでも納得しなかったり、何か別の理由がある場合、その理由にチーム全体として向き合う。なんのためにスタンドアップをやるのかを考え、チームとしての答えを出す。

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

スタンドアップは短時間なので、それほど無駄だとは思われにくいはず。にもかかわらず無駄だと思われるなら、スタンドアップ自体に問題がある可能性が高い。スタンドアップが機能不全に陥っていないか。まずはそちらの可能性からアプローチする。と同時に、その人がスタンドアップを無駄だと思う理由にも注目して、対話する。その人個人にとってスタンドアップがどのように役立つ(役立ちうる)か、チームにとってはどうか、それぞれにフォーカスしながら話してみる。
なお、朝にスタンドアップをしている場合、遅刻については単純に朝が苦手な人の可能性もあるので、場合によっては時間の変更も検討する。「時間どおりに来るのが当然」と決めつけず、現実を見てチームにとって最善のやり方を模索する。

スクラムチームのスタンドアップステークホルダーは誰も参加していない。この状況をどのように変えるか?

そもそも、変える必要があるとは限らない。ステークホルダーとのコミュニケーションは難しい問題だが、ステークホルダーの多忙度合いによっては、週次の Sprint Review で精一杯ということもありうる。無理をして毎日スタンドアップに参加してもらうことがよいとは限らない。

ステークホルダースタンドアップに参加してもらう合理性があり、かつ現実的に参加できそうということであれば、シンプルにその理由(合理性)を伝え、参加をお願いしてみる。おそらく何らかの理由で難しいということになるので、スタンドアップの時間帯を変える、日次ではなく隔日、等の選択肢も含めてチームとステークホルダーの折り合う場所を探る。

もっとも、そこまでするなら、スタンドアップにこだわらず、ステークホルダー専用の時間を設けるほうがよい可能性もある。原則としてスタンドアップはチームのためのミーティングなので。

分散チーム間のスタンドアップをどのように進めるか?

タイムゾーンが同じであれば、音声ないしビデオでつなげば事足りる。音声や映像でつながった状態を保つことはチームの相互理解にも寄与するので、できればそうしたい。

タイムゾーンが異なる場合、どれくらい異なるかにもよるが、チャットの使用を検討したほうがよい可能性がある。おそらく、チーム専用の Slack チャンネルで各自定形の質問(「3 つの質問」のような)に答えてもらうようなかたちになる。https://geekbot.com/ のようなソリューションも役に立つかもしれない。

チーム自体が 2 拠点に分かれている(例: 東京に 5 人、大阪に 4 人)ような場合、拠点ごとにスタンドアップを行い、要点を Scrum of Scrums のようなかたちで共有し合う、という手もある。各拠点では通常のスタンドアップの感覚でやれる一方、離れた拠点のチーム全員の詳細はわからなくなるなど一長一短あるので、そのやり方が効果的かどうかには特に気を配っておく必要がある。

スクラムチーム用の物理カンバンボードをいま書いてください

たとえば、以下のような構成が考えられる。

案 1
Todo Doing Done
... ... ...
案 2
PBI Tasks Doing Done
... ... ... ...
案 3
Idea Ready Developing Developed Testing Tested Delivered
... ... ... ... ... ... ...

気をつけるポイントは以下。

  • 個人ごとのレーンは設けず、アイテムごとにレーンを設ける
  • Doing の列は狭く(WIP が増えすぎないようにする)
  • 必要があれば、明示的に WIP 制限を設ける
  • ただし、個人的には最初はシンプルなものから始めるほうが好みです。

ふりかえりについて

だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

第一には、チームのためのものと考える。特に成熟していないチームには、心理的安全を保ちながらふりかえりを行える場が必要なので、はじめはチームの関心にフォーカスした方がよい結果を導きやすいと思う。

とはいえ、プロダクトオーナーが参加していけない、ということではない。プロダクトオーナーは参加しても黙っていてもらう、という手もあるし、悪影響が顕在化するまではチーム全体のすることに任せるという手もある。
逆に、プロダクトオーナーが明らかにふりかえりの場でのチームの心理的安全に悪影響を及ぼしているようであれば、プロダクトオーナーに丁寧に説明し、ひとまず不在にしてもらう、というケースも考えられる。

全体の流れとしては、顧客をはじめとするステークホルダーやエンドユーザのことまでを考えたふりかえりになるのが理想なので、時間がたつにつれてプロダクトオーナーまでを含めたふりかえりにしていけると望ましい、と考える。

チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

チームの健全性には日々気を配るが、ふりかえりはよいタイミングなので、確認しておきたい。指標としては、遅刻、欠勤、残業時間、ふりかえりの場での発現頻度・長さ・内容、ふりかえりに臨む態度、メンバー同士の関係性、ふりかえりの話題におけるよいこと・悪いことや、技術的なこと・それ以外のことの割合等に注目する。スナップショットではなく、中長期的な推移にも気を配る。
テクニックとしては、チェックインで今の気分を言ってもらったり、ふりかえりのフォーマット自体を気分にフォーカスしたものにする、普段から記録をつけてもらい(例: ニコニコカレンダー)それをふりかえりの場にも持ち出す、等が考えられる。

過去に使ったふりかえりのフォーマットはどんなものか?

基本的に、「場を設定する、データを収集する、アイデアを出す、何をすべきかを決定する、レトロスペクティブを終了する」の 5 フェーズでデザインする。

主要なプラクティスとしては、週次のふりかえりでは KPT、よかったこと/モヤモヤすること/嫌なこと、スターフィッシュKPT 進化版)等。

プロジェクト等中長期のふりかえりでは、タイムラインを使うことが多い。

それぞれのアクティビティについて、大きく分けて各自黙って付箋やホワイトボードに書いてもらう時間をとるスタイルと、声に出してもらってファシリテータが書き留めていくスタイルがある。前者の方が効果的な場合が多いが、そういったワークを好まない人がいそうな場合や、試してみる目的で、あえて後者にしてみることもある。

データの収集においては、できるだけ客観的な事実をすばやく思い出せるよう工夫する。過去には、チームボードのスナップショットをプリントアウトして張り出したり、チームの日記を張り出したり、日付で区切られたチームボード(チームの Sprint における活動の記録がそのまま貼り出されている)自体の前でふりかえりを行ったりしたことがある。

どうやってマンネリを防いでいるか?

ゴールを共有した一体感のあるチームだと、たしかにマンネリになってくることがある。そういうときは、あえてゴールに直接はあまり関係ないことを試してみる、イベントの進め方もちょっと変えてみる(ファシリテーターを変える、プロセスを変える、等々)、イベントに普段は呼ばないゲストを招いてみる、といったことをやる。

そういう「ちょっと試してみる」ことをやりやすいように、スプリント期間はできるだけ短いほうがよい。

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

なぜ行動できていないのかにもよるので、観察から自分なりに原因を見極めると同時に、チームになぜできていないのか、できていないことに対してどう考え、どうしたいか考えてもらう。場合によっては、実際に行動できるよう自ら手助けするのもよいかもしれない。たとえば、進捗の確認(「やってないようですが、やらなくて大丈夫ですか?」といったキュー出しのようなこと)を行ったり、アクションアイテムをプロダクトバックログに含めるよう PO とも協働したり、といったことが考えられる。

どうやってアクションアイテムのフォローアップを薦めるか?

アクションアイテムが SMART になっていれば、その指標にもとづいて適宜確認するとよい。タイミングとしては、Daily Scrum や Retrospective などがちょうどよい。遅くとも Retrospective では必ず前回のアクションアイテムのふりかえりを行うようにする。
達成できていた場合、さらによくするための追加のアクションがあるかを考え、あれば行うし、なければいったんチームとしてのフォローアップは終わりにする。(とはいえ、重要なアクションであったり、継続性に不安がある場合、スクラムマスターで独自に追跡するのもよいかもしれない)
達成できていなかった場合、アクションの有効性(今でも妥当なアクションか)や達成できなかった原因をチームで調べ、継続・変更・廃止などの、次のアクションにつなげていく。

11冊を並行で読む

年末年始休みだからいっちょ気合い入れて本でも読むかと思って読んでいる。

だいたいこういうときには多数の本を一気に読み始めてしまう。
今は知りたいことが多いから、一緒に読んでいる本も多い。

ビジネス/マーケティング

ブルー・オーシャン戦略

こないだ読んですごくよかった『突破するデザイン』で引用されていたから読んでみる。
戦略策定には実行手順を組み込める」という主張が特によい。

ブルー・オーシャン戦略では、策定と実行の連動性を重視している。大多数の企業ではこの両者を切り離しているかもしれないが、我々の研究によると、策定と実行が分断されてしまうと実行に時間がかかって効果も怪しくなり、機械的に手順を追うのがせいぜいである。

そうなのだ。
経営戦略、だいたいまともに実行されずに終わる。いかに戦略がよくても、まともに実行されなきゃなんの意味もないのだ。

キャズム

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

キャズム関連の主要な用語やその主張するところは聞きかじって知っているものの、この本を読んだことなかったのでこの機会に読む。
エスケープ・ベロシティ』もそうだったけど、ジェフリー・ムーアの本は読みやすさと面白さが両立していてすごい。サクサク読めてしまう。

イノベーションへの解

イノベーションへの解 利益ある成長に向けて (Harvard business school press)

イノベーションへの解 利益ある成長に向けて (Harvard business school press)

イノベーションのジレンマ』がめちゃくちゃ面白かったから、その続編ということで読む。
ジェフリー・ムーアの本とは対象的に、読むのに時間がかかる。それは論理の緻密さの裏返しでもあるので、がんばって読む。

INSPIRED

INSPIRED: How to Create Tech Products Customers Love (English Edition)

INSPIRED: How to Create Tech Products Customers Love (English Edition)

初版は日本語で読んで、すごくよかった。
去年出た第 2 版も翻訳が進んでいるらしいのだけど、早く読みたいし旧版を一度読んだ本で英語の勉強にもちょうどいいかなと思って読む。

デザイン

Design Systems

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド

最近関わってる製品でデザインシステム構築したほうがいいんじゃないか説があって試行錯誤してるので、ちょうどいい本出てるやんけと思って買った。
まだ序盤だけど、かなりいい。最新の事例がビシバシ出てくるのもいいし、デザインシステムとはなにかの話をアレグザンダーのパタン・ランゲージの話から始めてしっかり積み上げてくれるところもいい。買ってよかった。

UIデザイナーのためのSketch入門&実践ガイド

UIデザイナーのためのSketch入門&実践ガイド 改訂第2版

UIデザイナーのためのSketch入門&実践ガイド 改訂第2版

Sketch は使ってないんだけど*1、巷のプロトタイピングツールはだいたい Sketch みたいなものと聞いたので買ってみた。
おおむね期待通り、Figma 触ってみてイマイチよくわからなかった用語とか概念が解説されていてよい。後半にはモダンな周辺ツールの紹介とか UI トレースのすすめみたいな章もあるっぽいので楽しみ。

プロとして恥ずかしくない 新・配色の大原則

プロとして恥ずかしくない 新・配色の大原則

プロとして恥ずかしくない 新・配色の大原則

最近会社でやってるデザイン教室(?)の課題図書。
読み進めていくと世の中のモノとか Web とかアプリとかの配色について言葉で説明できるようになっていくので、たいへん面白い。

IA Thinking

IAシンキング Web制作者・担当者のためのIA思考術

IAシンキング Web制作者・担当者のためのIA思考術

こちらも同様に課題図書。
仕事始めまでに読み終わって課題もやっといてねとのことだったので、安全策として実家への帰りの新幹線でさくっと読んでしまう予定。

About Face

About Face: The Essentials of Interaction Design

About Face: The Essentials of Interaction Design

ゴール指向設計およびペルソナ・シナリオ法の父である Alan Cooper 御大の本。
旧版である About Face 3 は日本語版が出てるんだけど絶版で古本が高い。うっかり新版の翻訳出ないかなってずっと待ってたけど出る気配ないし、観念して英語で読む。

息抜き

イノベーション・オブ・ライフ

イノベーション・オブ・ライフ ハーバード・ビジネススクールを巣立つ君たちへ

イノベーション・オブ・ライフ ハーバード・ビジネススクールを巣立つ君たちへ

クレイトン・クリステンセン先生の本があまりにも面白かったので(そういえば去年読んだ『ジョブ理論』も面白かった)、最近敬遠してた人生指南(?)系の本だけど読んでみることにした。
まえがき(序講)に「今回も容赦はしねえ、理論で攻めるぜ」(意訳)みたいなこと書いてあるからワクワクしたものの、期待したようなキレッキレの論証とかはなくて、先生も人間なんだな~というあたたかい気持ちになりながら読んでいる。

Effective Java 第3版

Effective Java 第3版

Effective Java 第3版

ほか色々

このへんがメインで、合間に詩とか小説とか他気になった本とかをはさみながら読んでいくことになる。
予定。

まとめ

といった具合に、やたらめったら読む。

関連するジャンルの本を並行で読むと、似たようなことを言っているところ、少し切り込み方が違うところ、(極端な場合は)同じ事例を扱っているのに逆の主張をしているところとかが見つかって、自分の中での対話が捗る。

久々の感覚で、ちょっとたのしい。

*1:業務用の Mac がないから使えない、とりあえず Windows でも使える Figma を使ってみてる

読み比べたらぜんぜん違うのだろう

もともと 2018 年をふりかえっておこうかと思って書き始めた。

ところが、何か意味のあることを書こうとするとどうしても愚痴や恨み言めいたものになってしまう。
でもそれは本意ではないというか、筋ではないというか、少なくとも公共の場で語りたいようなことではないので、結果としてほとんど何も書くことがない。

こういうときに、人は詩を書いたりするんだろうか。

最近は、小さくて美しいものを見て心をなごませている。

Irene さんという、アメリカ在住で飼っている 3 匹の犬の写真を毎日 Twitter に上げている人がいて、その犬たちの幸せそうな様子を見ては、幸せな気持ちになっている。
犬はありがたいし、Irene さんもありがたい。

古賀及子さんという、Web ライターの人がいて、日常のことをはてなブログで書いている。お子さんのことが多いけれど、それだけでもない。
淡々と日常を綴っているだけで、煌めくような美文というわけでもない。そもそも僕にとって赤の他人の日常である。

でもなぜか、泣きそうになる。
今気づいたのだけれど、この淡々とした文体は、僕が大好きな『帰ってから、お腹がすいてもいいようにと思ったのだ。』の高山なおみさんに少し似ているような気がする。

たぶん、読み比べたらぜんぜん違うのだろう。

11 月には 4 回目の舞台に出た。
今年は、職場の人たちも何人か見に来てくれた。

荒れ放題になっていた部屋の掃除をしたら、少しすっきりした。

「全員常時ペアプログラミング」は「チーム開発初心者」向けなのではないか

週 40 時間ペアプロ

ここ 3 ヶ月ほど、所属しているチームの開発者全員が常時ペアプログラミングしている。

今やっている開発は、ほぼ、「ケント・ベックの本に書かれている XP」そのまんまのスタイル。*1

プロダクトマネージャが書いたユーザーストーリーを、プロダクトバックログの上から順に、4 人の開発者が週 40 時間労働で、毎日朝から夕方まで常時ペアプログラミング、TDD で開発している。*2

このように日常動作がペアプロなので、自然、ペアプロについてメタ的に考えることがある。
そんな折、ふと「この常時ペアプロするスタイルって初心者向けなのでは?」という考えに至った。

守破離の守

守破離」という言葉がある。

以下に Wikipedia の記述を引用する。

まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
守破離 - Wikipedia

この「守破離」でいうと、チーム開発において「常時ペアプロする」というのは「守」なのではないか。

言い換えると、チームで生産性の高いソフトウェア開発をしようと思ったときに、「まずは常時ペアプロする」のがいいのではないか? ということ。
「できるところから」とか「必要なときに」ではなく、いきなり「常時」やる。

逆に言うと、「常時ペアプロする」のはあくまで「初心者の動作」であって、チーム開発が上達するにつれて、やがて「常時ペアプロ」ではない形態に転換していくのではないか? ということ。
チーム開発に熟達すると、必要なときにペアプロし、そうでないときにはそれ以外のスタイルを取れるようになるのではないか。

XP におけるペアプロ

ところで、ペアプロというプラクティスは、「ケント・ベックの本に書かれている XP」の肝だと思う。
ここのところ、「週 40 時間ペアプロ」する日々のなか、ペアプロを日常動作の中心に据えることで、XP の価値・原則・プラクティスが、美しく統合されることを実感している。

XP の価値である「コミュニケーション」も、「フィードバック」も、「勇気」も、「リスペクト」も、ペアプログラミングというプラクティスからなめらかに導かれるし、ソロであればついつい設計や実装に不要な複雑さを持ち込みがちなところ、ペアで作業していれば「シンプリシティ」も保たれる。

「経済性」という原則については結論を(直感的には)即断できないとしても、「人間性」「多様性」「流れ」「機会」「冗長性」「品質」「責任の引き受け」といった大半の原則が、ペアプログラミングからほとんど直接の効果を得られる。

多くのプラクティスについても、同様のことがいえる。

「常時ペアプログラミング」することで、XP の価値・原則・プラクティスに則ったチーム開発が格段にやりやすくなる。

ペアプロのペイン

ここまで、ペアプロをほとんどべた褒めしてきた。僕はペアプロが好きだ。
でも実は、ペアプロには苦手なところもある。

コードを書くのが速すぎて、ペアの相手がついてきてくれないのである。

これは、僕のプログラミング能力が(チーム内で相対的に)高すぎるのか……そんなことって……、とか考えていたら、実はそうではないようだ、ということに気づいた。

僕は、コードを書くときに「トップスピードで試行錯誤しまくることで最短時間で正解にたどり着く」ようなスタイルを取るのが好きだ。マシンにできることは、マシンにやらせたい。*3

でも、ペアプロのときにこれをやると、実質「ペアの相手はマシン」という状態にになってしまう。僕とマシンのペア。
すると、人間のペアが置いてきぼりになる。

それではまずいので、常に思考を発話し、相手の理解を確かめながら進める。ところが、相手の理解を待っていたら、トップスピードではなくなってしまう。*4
理解を待たないわけにはいかないので、結果として、ソロでやったときよりも、その場の開発スピードは落ちることになる。

もちろん、ペアの相手が僕の知らないことを知っていて、ペアの力で速く進めることもある。これは、ペアプログラミングの重要な利点でもある。
だとしても、その場の開発スピード(の平均値)はソロのときよりも落ちる、というのが偽らざる実感で、そこがペアプロのちょっとだけ苦手なところ。*5

ペアプロの生産性

では、僕がいるチームでは、ペアプロしないほうがいいのか?
「しない」とは言わないまでも、「ペアプロしたり、しなかったり」するほうがいいのか?

そう考えてみても、やっぱり、今は「常時ペアプロする」方がいいと思う。

それは、ペアプロがもたらす価値が、「今コードを書く速さの低下」を補って余りあるから。
定量的に説明するのはちょっと難しいけど、「XP におけるペアプロ」のところで並べ立てた、XP の価値や原則、言い換えると「チーム開発の生産性を高めるための道」をペアプロが導く、ということが、説明になっていると思う。

プログラミングはコミュニケーション

関連する話題をもう一つ。

プログラミングは、コミュニケーションだと思う。

もちろんプログラミングの第一義は機能の実装、価値を届けるために動作するコードを生産することなんだけど、その生産性を高めるためには、「プログラミングはコミュニケーションだ」ということを理解している必要がある。

読みやすいコードも、整然としたアーキテクチャも、チームのメンバーや、将来の自分、そして将来そのコードを読み、使い、変更する人とのコミュニケーションのためにある。
テスト駆動開発によって設計を導くのも、チームメンバーとのコミュニケーションのためであり、理解しやすく変更しやすい設計による将来のコミュニケーションを導くためだ。

なぜコミュニケーションが重要かというと、コミュニケーションのなめらかさが、製品の品質や、生産性に跳ね返ってくるから。

そして、XP は「コミュニケーションとしてのプログラミング」の「先生」であって、ペアプログラミングこそがそれを導くものだと思う。
ペアプログラミングがそれを導くなら、常時やればいい。

プログラミングがコミュニケーションであることが、「今コードを書く速さが落ちるとしても、ペアプログラミングをした方がいい」ことの説明になる。

ペアプロの「破」「離」

ということで、「常時ペアプロ」がチーム開発の「守」にあたる、という話に戻ってくる。

やや乱暴な言い方をすると、常時ペアプロすれば、チームとしての生産性が上がる、とも言える。
「すれば」→「上がる」というのは、まさに「守」だ。いつペアプロすべきか、とか、何をどう工夫すれば、とか、考えなくていいのだ。*6

では「破」「離」はなにか。
それが「いつペアプロすべきか」考えること、そして選ぶこと、なのだと思う。

まだその域に至っていないので、何が「破」で何が「離」にあたるのかはわからないけど、いずれにせよ、ペアプロするとき、しないとき」を使い分けるのは「上級スキル」だ、という感覚が今はある。
下手に「一人でやったほうが速いから」ということでソロ作業を取り入れると、「速さ」以外の、コミュニケーションにかかわる価値を損なって、結果としてチームとしての生産性(要するに、中長期的な「速さ」!)が低下しかねない。

だから、初心者のうちは、常にペアプロした方がいい。
そうすれば、ペアプロのメリットもデメリットも余さず体感できるし、経験が少ないうちは、下手な工夫でやったりやらなかったりするよりも、チームとしての生産性の平均値は高くなるはず。

とはいえ、いつまでもずっとペアプロを盲信するのではなく、いつか「破」に移行して、また「離」にいけるといいな、と思う。

それはモブプログラミングのような形かもしれないし、もしかしたら、全員がソロに戻るという可能性もある。
結局、常時ペアがいいということになるかもしれないし、それらの間になるかもしれない。

結論

僕は、今いるチームで「全員常時ペアプログラミング」することで、チームの生産性向上を感じている。
チーム開発の初心者や、集まったばかりのチームは、「少しずつ導入」するよりも、むしろ「全員常時ペアプログラミング」を試してみるといいのではないか。

ペアプログラミングは、「コードを書くスピード」が落ちることもあるけど、「コミュニケーションとしてのプログラミング」を強力に推進する。
それはチームとしての生産性の向上を導き、中長期的な生産性にもつながる。だから、やる価値がある。

はじめは「常時ペアプログラミング」して、慣れてきたら、「ペアプログラミングしないとき」について考え始めるといいのではないか、と思う。

補遺

ペアプログラミングには、「誰もが好むわけじゃない」という課題がある。

ペアプログラミングの研究者が書いた本にも書かれていることだし、僕の周りにもペアプログラミングが苦手な人はいる。(もちろん、それは責められるべきことではない)

僕の場合、今のチームには、少なくともペアプログラミングが「すごく苦手」「大嫌い」という人はいなそう。(直接面と向かって「大嫌いですか?」と聞いたことはないけど……)
だから、成り立っている。

もし、チームの中にそういう人がいそうだったら、導入は慎重に。
強制すると、みんな幸せになりません。

*1:ブログ購読者の方向け: 今は、以前スクラムをやっていたチームとは別のチームにいます。以前のチームは、形を変えながらもスクラムによる開発を続けています。ちなみに、モブプログラミングを実践しているみたいです

*2:なお見出しにはわかりやすいように「週 40 時間ペアプロ」と書いたけど、定時が週 37.5 時間なのと、プログラミング以外の時間もあるので、実質は 30 時間くらいだと思う

*3:コンパイル言語でテストも書いてれば、考える時間ってあんまり必要なくて、書かれたストーリーを見て、上からいくか下からいくかだけ仮決めして、あとはIDEとテストの導きに従ってひたすらキーボードを叩いてたら、コードはできあがる。立ち止まって考えるのは、最初と、打鍵しながらと、機能が一通り動いて少し大きめにリファクタリングしようと思ったときだけで十分。

*4:これは能力差の問題というより、非対称性の問題。マシンは人間より桁違いに速いので、正しい入力も間違った入力も、瞬時にフィードバックしてくれる。でも、人間はそうはいかない。相手が僕の 2 倍くらい速い人じゃないと、トップスピードは出せないと思う

*5:これに気づいて(つまり、「僕の開発スタイル」が原因で、「ペアとしての生産性」が最大化できていないようだ、ということに気づいて)、自分の開発スタイルを「ペア用」にチューニングすることを考え始めたのだけど、この記事の本旨とはずれるので、ここでは議論しません

*6:「考えなくていい」というのはもちろん言いすぎで、考えるのはいいことだし、考えたほうがいい。でも、考えながらも、基本動作としては「常にペアプロする」。