テスト駆動開発(TDD)のゴール「動作するきれいなコード」について考えてみる

「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。

「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。

」 テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用

セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、本当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。

絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと(Validation)は、いずれも動作する様子を現しますが、大きく異なった観点です。仕様書とコードに乖離があったり、クラッシュするようなバグがあったら、Verificationの観点から「動き」ません。ユーザーにとって使えなかったり、資産を毀損するような重大な仕様の穴があったら、Validationの観点から「働き」ません。

そう考えると、動作するきれいなコードは書いた通りに動き、期待通りに働き、同時にきれいでなくてはならない。

TDDは主に開発者やプログラマーの活動です。しかし動作するきれいなコードに関心を持ち、実現したくなる他の種類の人々もいます。顧客、クライアントは働くコードを求めます。テスターやQA担当にとって、動くことが確認済みのコードはありがたいものです。コードを書いた本人以外のプログラマーは、安全に作業できるきれいなコードを好みます。

レッド・グリーン・リファクタリングのサイクルを回しながら、コードが動作する(Verified)かつきれい(Clean)であるようにするのは、プログラマーです。プログラマーがさらに、期待通りに動くか判断できる(Validated)、すなわち今書いているコードの受け取り手の立場にたって判断できる場合もあります。しかしこの判断には、プログラマー以外の人にも関わってもらうべきです。そのことを念頭に置き、図に3種類の人々のラベルを追加しました。開発者、顧客、QA(テスター)です。

こちらの図では、人による価値の置き方の違いが見て取れます。プログラマーはコードが動き、きれいであるよう望みます。QA(テスター)はコードが動くことと働くことの両方を検証、確認します。顧客は働くコードを求めます。きれいなコードは顧客にも間接的に価値をもたらします。顧客としては、コードのきれいさには興味がないかもしれませんが、低コスト・短期間で追加変更できるのは嬉しいはずです。変更が安全かつ容易なのは、きれいなコードの特性です。

下側の2つの円が、プログラマーがTDDサイクルで重視する部分です。同時に上側の円、コードが本当に働くかどうかも重視すべきですが、働くか確認(Validate)できる人の助けを得なくては、動作するきれいなコードにはなりません。それぞれの立場の人々がお互いに助け合い、協力して動作するきれいなコードを追求する。その必要があると思い出すのに、この図が役立つよう願っています。

それぞれの立場の人が、TDDのサイクルを越えて一緒に働くわけです。あるいは、TDDサイクルの中で、一緒にモブプログラミングするのはもっと素晴らしいと思います。

この図はワークショップでも、「動作するきれいなコード」にまつわる活動や作業を見つけるために使えます。3つの円を大きく描いて、それぞれ「期待通り働く」「書いた通り動く」「きれい」とラベルをつけます。思いつく作業やタスク、活動、アイデアなどを付箋に書いて、3つの円の当てはまる場所に貼ります。円には重なっている部分があり、ここに付箋を貼れば2つ、3つの円に関係すると示せます。そうして、足らない部分を見つけたり、違う立場の人どうしが協力する仕方を話し合ったり、自分たちの「動作するきれいなコード」を定義したり、改善のアイデアを出したりと、なんでもやりたいことをしてください。

さて、この図を示したところで、少しばかり懸念があります。3つの円、働く、動く、きれいという3つがすべて重要だと示しているつもりではあるのですが、人の役割を書き込んだことで勘違いが生じてしまうかもしれません。たとえば、「自分は開発者なので「期待通り働く」かどうかは気にしなくてよい」と思われては、本末転倒です。そうした間違いを避けるため、矢印を2本足した次の図を作りました。

正直なところ、この矢印がなにを意味するべきか、まだ自分の中でもまとまっていません。たとえば、こんなふうに言えるとは考えています。

• 開発者は動く・きれいに責任を持つが、働くかどうかも気にしたい。そのためには顧客と会話したり一緒に作業して、顧客を理解し顧客視点を得たい
• QA(テスター)は開発者と積極的に関わるとよい。そうすると、開発者がコードをきれいにする考え方を知り、そこからテスト容易性に結びつけたり、テスト観点を見直したりできる

これ以外にも解釈や洞察があるのではないかと思います。この図の矢印について、思いついたことをコメントなどで教えていただけると嬉しいです。もっと言うとここで紹介した図についての感想やコメントもぜひお願いします。

What it takes for TDD to make Clean Code That Works?

"Great books begin with great openings. 'Test-Driven Development' by Kent Beck (2003) begins with this sentence: Clean code that works, in Ron Jeffries' pithy phrase, is the goal of Test-Driven Development (TDD)." (Quoted from talks by Takuto Wada (和田卓人), or t_wada, the TDD evangelist actively working in Japan.)

When I teach about TDD, I always try to stress that TDD is just a skill and that's Clean Code That Works you really want. To supplement this idea, I came up with an diagram.

It was interesting to find out that the 'Works' part can be split into two: It works as intended (Verification) and also it works to fulfill expectations (Validation). In other words, code is not broken (Verified) and valuable (Validated). So, it must be validated, verified, and clean to be called as clean code that works.

TDD is chiefly an activity for developers or programmers. But other people also see values in Clean Code That Works. Clients would receive no value if a part of code does not work. Testers will be relieved if code is already confirmed to work. Programmers who need to read and modify someone else's code will feel safer if the code is clean.

In the Red-Green-Refactoring cycle, programmers make sure the code is clean and verified (Green and Refactored.) Sometimes they also know how to validate, i.e. make sure it's valuable to anyone who receive the software. But sometimes other people are required for validation. So, along with Programmer, I add two kinds of people to the diagram: QA (tester) and Client.

This version of diagram gives us some ideas of who values what: Programmer want the code verified and clean. QA (tester) make the code validated and verified. Client likes validated and clean code. Maybe clients doesn't care (or doesn't know) about clean code, but they sure value ease of change. Safety and easiness in modification is a great virtue of clean code.

Lower half is usually where programmers put focus with TDD cycle. The diagram will help remembering that validation is also crucial to make sure the code really works. And help from other kind of people is essential to validate programmers' work. Everyone helps each other ― everyone works for each other, outside of TDD cycles. Or, perhaps, everyone participates in TDD cycle as a mob!

It may be a good idea to use the diagram in workshops to gather activities to create Clean Code That Works. Draw three big circles, label them Validate / Verify / Clean. Write down ideas, processes, activities or tasks on sticky notes and then put them into appropriate areas. Find out lacking activities, discuss about collaborative overlaps, define your Clean Code That Works, look for ideas for improvements, or do anything you like to do together.

Now I have a worry that the diagram might send a wrong message. It is meant to all three - Validated / Verified / Clean - are important, but someone might read like "I'm a programmer, so validation is none of my business." To mitigate my fear, I made another version of the diagram with two dotted arrows.

I'm not really sure what the arrows mean. Maybe I can say like "Programmers are not only responsible for Verification and Clean but also for Validation. To do that, programmers need to collaborate with clients to understand and share client's vision." I'd like to hear what do you think of the arrows, or rather, any versions of the diagram.

オンラインホワイトボードで自己紹介

「神経の衰弱しない自己紹介」という、オンラインホワイトボードを使ったグループアクティビティを紹介します。初めての人が集まるリモートの場で、アイスブレークを兼ねた自己紹介をするものです。CC-BY 4.0で公開します。(CC-BY 4.0 やっとむ, 合同会社やっとむ屋)

カードに書かれたキーワードを使って、自分の話したいことを語ってもらいます。カードはトランプのように「伏せて」あり、めくって(カード裏をドラッグでどかして)出たキーワードで語るというサプライズ要素もあります。

試してみる用のMiroを公開してます。使い方も書いてあります。お気軽にさわってみてください。

miro.com

気に入ったら、自由に使ってください。同じMiroなら、コピー＆ペーストで自分のMiroに貼り付けられます。それ以外でしたらアイデアやテキストの再利用は自由です。

使い方

1. 参加者1人ずつ付箋に、「今日呼ばれたい名前」と「普段の仕事をひとことで」書き、書けた人から一列に並べる(先頭はファシリテーターや主催者などにする)
2. 付箋の順に、1人ずつ以下の手順で自己紹介をする。
3. まず名前と仕事を言い、次にカードを各枠から1枚ずつ選んで、そのことについて語る。「好き」な「ペット・動植物」とか、「自慢」の「趣味」など
4. すでにめくってあるカードを選んでもよいし、伏せてあるカードをめくってもよい。カードを「めくる」とは、トランプ裏の画像をドラッグして横にずらすこと
5. 1人の話が長くなる場合などは、ファシリテーターが適宜調整します
6. 1人ずつ進めるとき、いま誰の順番かわかりやすいよう、イマココの矢印で指し示すのがお勧めです

一番手にファシリテーターが自己紹介して、そのときカードのめくり方を実演すると伝わりやすいです。各枠の一番上の、伏せてあるカードを使います。

カードの枚数は10名程度想定、内容はIT技術者向けです。参加者の人数や性質に応じて適宜追加変更してください。

アイデアと背景

お互いを知らないところで自己紹介するのは緊張しがちですが、そこで仕事のことでもプライベートのことでも、その人を知れる話ができると後の時間が楽しくなります(たぶん)。いっぽう、ファシリテーションでありがちな「自分の特技」や「今日のグッドニュース」のようなネタに抵抗を感じたり、緊張が強まったりする人もいます。このアクティビティでは、カードを使ったゲーム感覚でネタを選べ、サプライズも可能で、各人それぞれで安心して楽しめるレベルを調整しやすくなります。

人によって、安心な話題を自分で選びたい人もいれば、サプライズで盛り上がりたい人もいます。めくってあるカードから選んでも、自分でめくってもいいのは、そこの調整の役割があります。プレッシャーを感じている参加者のために、自由に選んでもいいし、1枚めくってもナシにしてめくり直してもいいなどと、ファシリテーターが繰り返し説明するとよいでしょう。場の種類によっては、必ず新たにめくるようにしてもいいかもしれません。

最初からめくってあるカードは、誰でも話しやすくかつネガティブな内容や機微な内容になりにくいものです。自己紹介が億劫な人でも選びやすくしてあります。他のカードは、めくったけれど話しにくいという場合もあり得ます。話しにくい、話せることがない、というときは別のカードをめくり直すか、出ている他のカードを選んでもらいましょう。

冒頭で名前を付箋に書いた順に並べると、比較的話すのに抵抗がない、慣れている人が最初に回りやすく、進行がスムーズになりやすいようです。後に回った人はめくったカードの選択肢が増え、話しやすくなります。

カードの内容はIT技術者向けに作ってありますが、多くは一般的に使えると思います。参加者の属性にあわせて、自由に追加変更してみてください。センシティブな内容につながりかねないものを避けるように意識しています(例: 居住地・出身地、学歴や職歴、○年前なにをしていたか、人生の目標、など)。また話題を選びやすくする意図で、複数の項目を1枚に入れて範囲を広げています。

ストーリーポイント見積りって難しくない？

ストーリーポイントの見積りは難しいと思います。ストーリーポイントが難しいと言うよりは、見積りが難しいのですが。たくさんのチームでストーリーポイントを使ってきての感想ですが、コミュニケーションの道具としてはものすごくよくできています。一方、将来を正確に予測するという点では、割とダメな道具ではないかという気がしています。

見積もること、つまり将来を予測するというのは難しいので、ストーリーポイントを道具として使ったところで難しさは変わらないということだとは思います。いくつか思い当たる理由を挙げてみます。

当事者が(当事者ですら)作業を予測できない

チームがストーリーポイントで見積もるメリットのひとつが、一番よくわかっているはずの当事者が、自分たちの作業を見積もるという点です。しかし、既存コードがスパゲッティで変更量が予想できなかったり、スキル不足で作業内容が想像できなかったり、着手してから仕様が変わったり増えたりしてしまう。予想が外れまくったり、そもそも予想できなかったりします。

内部品質が低い

前の項目とも関係しますが、変更や追加をするとき、既存のコードベースがひどいせいで、予想が困難になる場合があります。コピー＆ペーストが横行していて、同じ変更を何十箇所も適用しないといけない。1箇所変えたら他の箇所が壊れ、直すとまた他の部分に問題が起き、先が見えず延々と終わらない。アーキテクチャの一貫性がなく、変更を定型化できない。自動テストがなくて動作確認をものすごく慎重にやらざるをえない。

見積もる対象が大きすぎる

チームで数日かかるような大きい機能/ユーザーストーリー/PBIは、予想からのブレ幅も大きくなりがちです。スプリントで完成するPBIが3つとかだと、1つ外せばベロシティの変動は30%以上になります。(ひとつひとつが数時間で終わるとか、1人/1ペアで1日程度とか、1スプリントで10個以上あるとか、大きさは小さく数を多くすると安定しやすくなります。)

過去の実績を軽視する

ポイントで見積もるというのがとても直感的なのがわざわいして、大きそうだから5、もっと大きいから8か13、という感覚的な数字になってしまいがちです(このクセを直すのは非常に苦労します)。過去に完成した機能やPBIの実績を生かさないと、正確な見積りには近づきません。

ベロシティの業務量

スプリントで完成したポイントを合計して、ベロシティを算出します。このベロシティは簡単なようで、意外と考えたり可視化するのに手間がかかります。スプリント中に休みなどで時間が増減したときの調整、割り込み作業などの注釈、PBIやタスクの性質による分類や分析、過去のトレンドの発見など。ツールで自動計算するとこのへんの直感が失われてしまいます。さらにチームがその結果を踏まえて、以降のスプリントの見積りに生かせるよう、解釈して議論する時間も必要です。このへんの手間を省いてしまうと将来の予測に使うのが難しくなります。

チームの妨害

チームへの割り込みなどがスプリント中に発生すると、作業時間が変動します。そうするとプランニング通りには進まなくなり、調整にさらに時間を取られたりして、完成できる量が変わります。ベロシティの算出は面倒になりますし、将来的にも割り込みが起き続けるのであれば将来の予測自体が難しくなる(変動幅が大きくなって収束しない)ということにもなります。

じゃあなんでストーリーポイントを使うのか

スクラムでストーリーポイントを使って(使わなくても)見積りをする意義は、ひとつはコミュニケーションやPBIの理解のため。これはとても有用です。

もうひとつの将来予測のため、これはなかなか難しく、自分たちの予想と実績をきちんとふりかえりながら「見積もり精度を高める」という具体的な目標を持って、自分たち自身を修正し改善していくという気持ちがいるなあと考えています。改善する道具のひとつとしてストーリーポイントを使うのはまあいいと思いますが、他の道具も必要になります。

そんな改善を積み重ねて、いわゆる「ベロシティが安定する」状態になって初めて、いくつか先のスプリントを予測できるようになります。それって「ストーリーポイントで予測できるようになった」って言っていいんですかね。ここまで来ていれば、別にストーリーポイントじゃなくてもいいような気がします。

代わりに使えるもの

現状が安定していないときでも将来予測に使える道具はあるんでしょうか。知りたいです。結局は『ソフトウェア見積り 人月の暗黙知を解き明かす』に帰着するのかな……？

短期も長期も両方大事

この文章は、Yves Hanoulle編纂 "Tips from the agile trenches" に寄稿したエッセイ(tips!)を元に、概要を日本語にしたものです。書籍はLeanPubで購入できます。

私がスクラムマスターとして一緒に働いたチームの話です。そこのプロダクトオーナーは、ユーザーの獲得と知名度向上に注力していました。その点では非常に上手くいったのですが、1年も経たないうちに企業合併の影響で製品は破棄され、ブランド名だけ残してビジネスが継続されることになりました。私個人の感想としてですが、目の前に注力しすぎて、将来を形作れなかった事例として印象に残っています。

また別の機会に、半分アジャイルコーチ半分開発者というかたちでスクラムチームに参加しました。開発者はみんな経験豊富なエキスパートで、自動テストはキッチリ、アーキテクチャも十分、コードはソリッドでした。メンテナンス性が将来の成長を支えるカギだと、みんなわかっていました。プロダクトオーナーは情熱に裏打ちされたプロダクトビジョンを持って、優れたユーザーストーリーを生み出していました。約1年後、スポンサーはこのプロジェクトの中止を宣言しました。1年たってもユーザーが10人に満たなかったのが理由のひとつです。開発スピードが遅すぎたとも言えるし、直近の課題に対応しきれなかったとも言えます。いずれにせよ、目の前の人々を満足させられなかったのは間違いありません。

アジャイルは長期的な成功を目指す。チームは現在と未来と両方とも価値を提供しなくてはなりません。未来を作るなら、今を生き延びないといけません。足元をいま整えないと、衰退した未来を迎えることになります。

• チームは動作する機能を現スプリントで実装しなくてはならない
• そのうえ、未来のスプリントのためコードをリファクタリングしておかなくてはならない

とか、

• プロダクトオーナーはステークホルダーを今すぐ満足させられるPBIを選ばなくてはならない
• そのうえ、未来のユーザーを満足させられるPBIを選ばなくてはならない

とか、

• このチームでなくては、現行製品を成功させられない
• そのうえ、このチームでなくては、社運を賭けたイノベーションを任せられない

とか、ある意味ムリゲーな話です。

長期的に勝つための2つの基本的考え方

シンプルさは昔からアジャイルの武器の1つでした。いまある問題を解決できる、もっともシンプルな解法を選ぶ。リファクタリング、機能の変更や削除を通じて、常にその状態を維持する。こうすることで、予期せぬ変更に対して最小の手間で対応できる状態を維持することになります。

もうひとつがビジョンです。計画とプロダクトバックログはビジョンを実現するための(終わりなき)道になります。計画があれば長期的になにをすべきかわかり、今やっている作業の位置づけも明確になります。なにより、今すぐやらないといけないことは何か、それは何故か、明確になります。

計画から始める。計画を変更し続ける。

ウォーターフォールでは計画から始めます。アジャイルでは計画から始めます。違いは計画の取り扱い方にあります。アジャイルでは現実に合わせて計画の方を変更し続けるのです。更新されている計画を見れば、次に何をすべきかはすぐにわかります。

プロダクトバックログが計画のすべてとは限りません。他にもUXリサーチ、技術研究、チーム拡大、ピボット判断、ステークホルダーマネジメントなど、たくさんの計画要素があり、プロダクトバックログには載っていないかもしれません。(プロダクトバックログではなく)計画全体をチームメンバー全員に共有しましょう。計画づくりにはメンバーに参加してもらいましょう。

計画は未来を分割したものではない。未来を実現する計画を作ろう。

将来達成したいビジョンには、誰かがなにかのメリットを享受する、そこに自分のプロダクトやサービスが関わっている、という様子が含まれているはずです。本当に達成したいのは誰かのメリットなのですから、それを実現する方策を考えないといけません。そのための機能をリリースするだけでは足りません。戦略的見地から、順序立ったシナリオを考案しましょう。

プロダクトバックログに載せるのは、完成品の部分だけではありません。ほしい機能をひとつずつ作っていくようなものではないのです。人に使ってもらう状態に到達するには、多様な情報も、使ってもらうための努力も必要です。使うのは誰か、なぜ使うのか、どう使うのか、使いやすいのか、他にいいやり方はないのか……そうした情報の獲得、フィードバックの収集、仮説検証はすべてPBIです。知識はアジャイルが生きるのに必須の栄養素です。知識を増やすように計画しましょう。

今を大切に。 目先に振り回されないように。

今を生き延びなければならない。そのため現在に集中しましょう。致命的になりうるリスクを見つけ、情報を集めて評価しましょう。プロダクト自体から収集できるデータは貴重なので、そのための機能や仕組みは早期に構築しましょう。チームメンバーやステークホルダーも重要な情報源です。

ちょっとしたコツを紹介します。みんなに「明日の天気」を聞いてみるやり方です。晴天快調問題ないと答える人がいるかもしれないし、しばらく向かい風で進捗厳しいですと答えるかもしれないし、中には進路に真っ黒な嵐雲が見えている人がいるかもしれません。アイスブレークでも使える小技です。

私の経験した失敗として、スポンサーが親切で優しいあまり、ビジネスで厳しい判断をする人だと見通せなかったことがあります。ステークホルダーの人々について、どんな危険をもたらしうるか、その人自身の責任や、モチベーション、判断基準などを理解するように努めましょう。

目の前というのは把握しやすく、今やるべきことを見つけやすいので、気持ちを奪われがちです。未来が把握しにくく、やるべきことを見つけにくいからと言って、未来が重要ではないわけではありません。むしろ未来の観点で考えましょう。今やるべきそのタスク、未来へのインパクトはどのくらいか？ 後回しにしたらどうなるでしょうか？ また別の、効果が出るのはずっと先になるけれど未来のインパクトは大きいタスクと比べて、本当に今やるべきはどちらでしょうか。

目先のことでいっぱいいっぱいになっていたら、敢えて時間をとってみんなで一息入れ、目先ではない少し先のことを話してみましょう。

未来への一本道

2種類の麺を鍋でゆでる必要があるとします。短い方の麺は3分でゆで上がり、長い方の麺は10分かかります。どちらを先にゆでますか？ おそらく、長い方を早くゆで始め、7分後に短いほうをゆで始めるはずです。それが計画づくりというものです。ここで、さらにもう1種類の麺をゆでると思ってください。この麺、ゆで時間がわかりません。さて、長い方とわからない方、どちらを先にゆで始めますか？ それはなぜですか？

短期と長期のバランスを取ればいいという話ではありません。いつなにをすべきかという決断の話であり、イコールいつまでに何をデリバーしたいのかという、ビジョン実現の1ステップの話です。価値創造もソフトウェア開発も難しいものです。チームとして、難しい状況に直面し続け、決断し続けていくと、その足跡は過去から現在への一本道になります。実のところ道は未来まで延びているのですが、見ることはできません。次の一歩も、今を大事にしながら、望ましい未来を作る、最善の決断となります。

短期、長期というのは相対的です。次スプリントより来月のほうが長期で、来年はもっと長期です。ことによると何年、何十年にわたり、決断は影響を及ぼすかもしれません。あなたの決断が、長く長く尾を引きながらたくさんの人々に影響していくことを頭に刻みながら、未来を作ってください。

モダンアジャイルについて

2021年7月1日に「モダンアジャイル 再考 2021」というイベントが分散アジャイルチームについて考える会の主催でありました。

distributed-agile-team.connpass.com

このイベントのきっかけは、私のFacebookでのつぶやき？でした。

これへのコメントできょんさん、鬼木さん、川口さんらに反応していただけ、さっそくオンラインイベントとして開催されたのでした。

以下では、イベントでいろいろな方から出た話、意見、考え方を踏まえながら、私自身の解釈や思っていることを書いてみます。最初に議論したいと思っていた内容もあれば、イベントでのやりとりから感じたこともあるし、後から思い出しつつ考えが変わってきた部分もあります。内容や文章について責任は私にあります。

モダンアジャイルとは

モダンアジャイル(Modern Agile)はJoshua Kerievskyが2016年頃に発表しました。Agile 2016の基調講演や、Agile Japan 2017の基調講演では来日したJoshuaがモダンアジャイルを紹介しました。Joshua自身はXP(エクストリームプログラミング)の初期からの実践者で、「Kent Beckから教わった」(川口さん談)そうです。1996年にIndustrial Logic社を創立していて、同社が作ったXPカードゲームは今でも持っています。

さて、モダンアジャイルは以下の図にある4つのGuiding Principlesで説明されています。日本語で理解するには「導いてくれる原則」とでも訳すといいでしょうか。4つの項目は、今給黎さん、角さん、伊藤さん、平鍋さんらが日本語にしてくれたそうです。

私は自分の研修など(「アジャイル入門」的なやつ)で、4つの項目をざっくり以下のように紹介しています。

• 工場などで物理的安全を確保するのは、作業者がパフォーマンスを発揮できるようにするため。おっかなびっくりではいい仕事はできない。
• 心理的安全は、対人関係の中にあるリスクについて、安全を確保する＝言いたいこと、言うべきことを誰でも誰にでも言えるという観点の安全性の話。
• 安全ニアリング(=Anzeneering。Joshuaの造語)は心理的安全を含む(たぶん)が、それ以外にも、急にデータが消えるとか、ちょっとしたミスが重大な損害につながるとか、ユーザーが食い物にされるとか、そういう危険がなく安全であることまで含む。

• 現状維持を目指すのではなく、新しい発見とそこから起きる変化をはやくたくさん起こそうというアプローチ。
• 実験には失敗がつきものなので、失敗していなかったらちゃんと実験できていないことになる。失敗しても問題ないような安全性が前提となる。安全性なくては実験はできず、実験なくして学習はできない。
• いわゆるプロセスの改善だけでなく、プロダクトの改善も含む(これは「継続的に価値を届ける」との合わせ技になる)。

• なんの仕事をしているのであれ、アウトカム、提供価値、結果が大事。誰のための仕事かを理解した上で、その誰かまで価値を継続的に届ける。
• 自分の仕事をやり遂げるところから、誰かの価値になる成果に意識をうつし、そのために自分の仕事に集中する。意識をうつすのにも、自分の仕事に集中するのにも、安全は欠かせない。
• 価値が届いたかどうか確認するところまでが「価値を届ける」こと。届けたつもりだけど、本当に使ってもらえているのか、想定した価値が出せているのか、喜ばれているのか。知りたいと思い、実際に知るべく、フィードバックを獲得する。

• 最高の結果は、人々を最高に輝かせるところから得られる(awesomeは「メチャクチャすごい」とか、ものすごさや凄まじさを感じる意味合いという気がしてます)。受け手を輝かせることも、作り手が輝くことも同じく大切。価値の提供はそのために必須。
• その輝くべき人々を考えるとき、誰のための仕事なのか、そしてその仕事をしているのは誰かを見渡したとき、見つかるすべての「誰」が対象となる。ユーザーだけでもダメだし、開発者だけでもダメ。
• 輝く人々は新たな価値を生み出していくし、より良いあり方を求めて学習もする。逆に、価値を提供せずに輝かせることもできないし、学習せずに輝くこともできない。

以上4つのGuiding Principlesは、人々が集まって有意義な活動をしている場面であればどこでも適用できます。2001年のアジャイルソフトウェア開発宣言は、ソフトウェア開発に限定した内容になっていました。現在ではアジャイルという言葉や考え方はもっと幅広く、プロダクト開発全体、サービス提供、組織づくりなど、様々な業種、場面で使われるようになっており、それらを包摂した上でアジャイルという言葉に新たな意味づけをしたのがモダンアジャイルとも言えます。

(そしてうがった見方をするならば、アジャイルを冠するコンサルタントやコーチが支援できる業種が増え、マーケットが広がり、仕事の幅を多様にする再定義とも考えられます。)

Guiding Principlesの使い方

モダンアジャイルを学び、4つのGuiding Principlesを活用するためにはなにをしたらいいのでしょうか。ここでは主に、Joshuaの記事にあることと、鬼木さんにうかがった話とを書いていきます。私自身はいままで、モダンアジャイルを紹介しているだけで、直接的に使ったことはありません。

モダンアジャイルは"principle driven and framework free"であると定義されています。やるべきこと(フレームワーク、プラクティス)が決まっておらず、4つのGuiding Principlesによって導かれ、自分たちのPrinciplesを軸にして推進されるものです。そこでまず活用に向けて、それぞれのGuiding Principlesを理解した上で、自分たちにとってのPrinciplesを定義していきます。以下のような疑問について考えながら、自分たちの状況、ビジネス、とりまく環境などを考慮に入れつつ、独自のPrinciplesを作ります。

• 誰を「最高に輝かせる」のだろうか？
• その人が「最高に輝いて」いるとはどういうことか？
• どうしたらそんなふうに輝くのか？
• 届ける価値とは何か？
• 継続的に届けるとはどういうことなのか？
• いま実験したいことは何か？ していない理由は？
• どんな危険が身の回りにあるか？

ここで言うPrinciplesは、日本語で言えば「行動原理」が近そうです。行動、やることそのもの(Practice)ではなく、行動する理由だったり行動が結果を生み出すメカニズムを説明するものになります。

こうした自分たちのPrinciplesを定義し、共有し、みんなが理解したら、モダンアジャイルのスタートラインを踏み出したことになります。ここからはPrinciplesを実体ある実際の行動に移していくことになります。

行動の中でもGuiding Principlesを使えます。ここは私の想像になりますが、ひとつのアクションを取り上げて4つの項目に照らして評価したり、日々の行動全体を見直したり、組織全体の方向性をそろえ直して局所最適を防いだりする際にも役立ちそうです。ふりかえりで使うのも良さそうです。

モダンアジャイルはいわゆるプラクティス、具体的なやり方やルールを提示していません。すべて自分たちで考えつつ、自分たちで作りつつ、自分たちでより良くしていく、「補助輪なし」という方法を提言しています。ルールやプラクティスが与えられると、ついつい「それをやること」に気が向かってしまい、そもそもの目標から逸れてしまいがちです。モダンアジャイルは、常に目標に向きながら自分たちの頭で考えるよう促しているように思います。

(そしてまたうがった見方をしてみると、決まったやり方がないぶんアジャイルコーチの支援の重要性が増すのかな……という気もします。まあ、ルールが多いほうがコーチが必要になる気もするので、どっちもどっちかもしれません。)

この4つは何なのか

さてこのへんから、私自身がモダンアジャイルを独自解釈したうえで疑問に感じている点に触れていきます。モダンアジャイルのGuiding Principlesとは何なのか、という話です。

"(Guiding) Principles"という名前は、アジャイルソフトウェア開発宣言のprinciples=「背後にある12の原則」を想起させます。12の原則のほうは、たとえば「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」という行動原理が書いてあります(ここでも、principlesは「原理」のほうが近いかなと個人的に思っています)。この一文は「顧客満足」を「価値のあるソフトウェアを早く継続的に提供する」ことで実現するという、目標と達成方法を含んだものです。

(なお和訳だとその構造はちょっとわかりにくいかもしれません。原文は"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."です。)

アジャイルソフトウェア開発宣言では4つの価値(Values)と12の原則(Principles)を述べています。XP(エクストリームプログラミング)では、価値・原則・プラクティス(Values / Principles / Practices)という構成で全体を記述しています。価値とは目指すもの、究極のゴール、目標です。プラクティスは価値に到達するための手段です。ただし、やみくもにプラクティスをやるだけでいい、やれば自動的に価値に近づくというわけではありません。そこをつなぐのが原則です。プラクティスがなぜ役に立つのか、どうしたら価値の到達に近づくのか、そこを説明し、機序(メカニズム)を明らかにし、プラクティスの効果的なあり方を示すのが原則です。

あらためて4つのGuiding Principlesを見てみると、「○○する」としか書いていない。あるいは「○○を実現する」と言っているだけです。きょんさんが「動詞だから(価値ではなく)原則では」とコメントしていましたが、「○○」の名詞を取り上げればそこが価値のようにも思えます。

モダンアジャイルの使い方として、Guiding Principlesを使って自分たちのPrinciplesを見つけるという話がありました。そう考えると、「自分たちのPrinciples(とValueとPractice)」を見つけるときに使うGuiding Principles＝「導いてくれる原則」なのであって、それ以上でも以下でもなさそうだ、そういう理解に落ち着いてきました。結局これ自体が補助輪だったのかと言える気もします。

Joshua自身、Agile 2017のキーノート中で"These four, I call them principles, you can call them values. You can call them thingies. They are the four things that I focus on."と言っていたりする(リンク先にtranscriptがあります)ので、Value / Principles / Practices という構造をモダンアジャイルでは採用していないか、単にこだわっていなさそうです。

さて、さらにめんどくさい話に少しだけいってみると、XPはパターンランゲージである(少なくとも志向している)。スクラムもパターンランゲージである(と考えている人々がいる)。パターンランゲージがとらえるのは全体性であって、(うまく説明できないから拙劣なメタファを使うと)一本の美しい木があって、木が育つ土地があって、土地を取り巻く山々と水源と動植物相があって、気候は……とひと続きの壮大な連なりとして考える。それに比べると、モダンアジャイルの4つに分ける整理の仕方は安直で、即物的で、あたかも木を掘り起こして根と幹と枝と葉に切断して語っているような印象ですらある。

たぶんこれがモダンアジャイルのいいところで、わかりやすい。間口が広く、入りやすいし、やってみようかという気になる。アジャイルの濃い人たちの話ってめんどくさ……いい話なんだけど、今それを聞かされてもわからないし困るんですがという人たちはたくさんいて、そんなときはモダンアジャイルに導かれて自分たち自身のことを捉え直すところから始めるアプローチがうまくいく、かもしれない。

まあだからこそ、濃い人から見ると疑問もあって、こんなふうに絡んでしまってごめんなさいという話にもなるのかなと思います。

モダンアジャイルは何を価値とするのか

Ron Jeffries著 "The Nature of Software Development"では、価値(Value)をピラミッドの最上位に置いたうえで「価値とはほしいものだ」あるいは「価値とはあなたがほしいものだ」と定義しています。

モダンアジャイルの価値は何なのでしょうか。2001年のアジャイルソフトウェア開発宣言では、4つの価値を明言していました。モダンアジャイルを導入するあなたは何がほしいのでしょうか？ 何がほしいとき、モダンアジャイルを考えればいいのでしょうか？

私自身は「最高に輝く人々」がモダンアジャイルの価値なのではないかと考えています。2001年のほうの「個人と対話」と直接対応するためです。もっともモダンアジャイルでは「人々」の中で受け手と作り手を等しく扱っているためか、上でも紹介したJoshuaの記事では"Make People Awesome"を”Customer collaboration over contract negotiation"と紐付けています。

7月1日のイベント(本質的には雑談会)でも、最高に輝く人々に特別な価値を置いていると考えてもいいんじゃないかと、そういう雰囲気になりました。論が尽くされたわけではないとも思いますが。

もしそうでなかったら、「人々を最高に輝かせる」のはあくまで手段であり目標(価値)は別なのだったらと考えると、気持ち悪さが出てきます。人々が輝くとビジネスにいいとか儲かるとかいった理由づけは、幸福な人は生産性が12％高いから従業員を幸福にすれば会社が儲かるみたいな考え方と同じく、人間性を見失いかねない危険なものだと思います。

最高に輝く人々について

ここからは完全に私の妄想というか連想として出てきた話になります。人々を最高に輝かせたとき、最高に輝いている人々とはどんなものなのだろうか。そこで思い出した、というか根拠なく連想したのが『民芸とは何か』(柳宗悦)で述べられている民衆です。(ちなみに著作権切れのためKindle版が無料で読めます。)

「あの無学と云われ凡庸と云われる民衆も、無限に美しい作を生み得るのであると。…民衆ならでは、あの民藝品の美を産むことはできないのだと。…民衆の作に誤謬はあり得ない。自然に従順だからであると。私は最後にこう云いたいのです。民衆は天才より、なお驚くべき作を造り得るのだと。」

この本は民芸について、民芸運動の中心人物である柳宗悦が書いたものです。民芸運動は20世紀前半に始まっており、「日常的な暮らしの中で使われてきた手仕事の日用品の中に「用の美」を見出し、活用する」運動です(Wikipediaより)。同書の中で柳は、「民藝とは民衆が日々用いる工藝品」と定義して、機械で工業的に作ったものや、人が意図的に美しく作ろうとしたものより、民衆が無心で「用途のために」作った民芸のほうが美しいと断じています。こうした工芸品は雑器とも呼ばれる、安価で多産に作られてきたものです。

この論の是非はここでは置いておきます。いったん前提を受け入れ、無学で凡庸な民衆が、自然に従順に、手作業で安価なものを多産する仕事の中で、無心に生み出した品が著しく美しくなり得ると考えたとき、この人は「最高に輝いている」と言えるのではないだろうか？ それが私の疑問です。

この製作者であるところの民衆は、無心なのですから、もっといいものを作ろうとか、高く売れるよう作ろうとか、実験しようとか改善しようとか、考えていないはずです。ユーザーを喜ばせようという意識もないでしょう。自分の仕事に大してモチベーションがあるわけでもなく、一連の作業の繰り返しに無心で集中しているフロー状態のような状況はあるかもしれませんし、作ったものは確かに誰かの役に直接たつものですが、仕事への充実感はあまりなさそうです。決して収入が高いわけではなく、社会的地位もなく、文字通り無名の民衆のひとりでしょう。

こうした人々こそが美しい、価値のある品を作り出せる。ただし、そうした美は見過ごされたり、軽視されたりしがちである。そのように目立たないが優れた仕事をしている人々は、輝いていると言うべきだと思います。際立っておらず、壮大なビジョンがあるわけではなく、さして情熱的でもない、最高に輝く人々です。受け手と作り手を取り巻くエコシステムがこんなふうに自然に従順に成立するとしたら、そうした人々についてモダンアジャイルはどう考えるのか、あるいは「個人と対話を価値とする」広義のアジャイルからどう見えるのか、そして私はいったいいどうしたいのか。迷走する連想からたどりついた、これが私の疑問です。

スクラムマスターの資格って必要？本当に答えます

スクラムマスターに資格(職務に就くための必須の条件)はありませんが、認定(スクラムマスターとして有能である、十分である)はいくつかあります。

ですので、タイトルに直接答えれば「資格は必要ありません(そんなものはありません)」となります。

いっぽうで、スクラムマスターの認定はいくつかの組織から提供されています。こちらは勉強する目標としても、就任する上での判断材料のひとつとしても、有用ではないかと思います。

Certified Scrum Master® / CSM® / 認定スクラムマスター

非営利組織Scrum Allianceが提供しています。認定トレーナーの研修を受けた上で受験します。日本ではOdd-e Japan、アギレルゴコンサルティング、アトラクタなどが提供しています。

Licensed Scrum Master / LSM

Scrum, Inc.が提供、日本ではScrum, Inc. Japanが提供しています。研修を受けた上で受験します。

なお、Scrum, Inc.(米国)では現在 Licensed Scrum Master という名称を使わず、 Scrum Master by Scrum Inc.™となっているようです。Scrum, Inc. JapanでもLSMという表記が目立たなくなっており、名称の変更がされるのかもしれません。(2021年5月現在)

Professional Scrum Master™ / PSM

Scrum.orgが提供しています。試験だけ合格すれば認定を取得できます。対応する研修もあり、日本ではITプレナーズなどが提供しています。

スクラムマスター以外

それぞれ、より上位の認定や、スクラムマスター以外のプロダクトオーナーや開発者の認定も提供しています。より広く・深く学ぶうえで有用だと思います。

参考にした資料:

• スクラムマスターの役に立つ認定資格・研修一覧｜オッドイー

なお本記事はCC-BY 4.0で提供します。ご自分のブログ、メディア、サイトなででそのまま掲載いただいて構いません。