仕事において笑顔になることや、笑ってしまうことはチームの団結、生産性、組織のパフォーマンスを証明してくれる。楽しさは強制できるものではないが、促進できるものであると Holly Cummins 氏は FlowCon France 2019 で語った。仕事場における楽しさの重要性の講演である。
Cummins氏は、楽しさを得るためのスリーステップを紹介した。Step 0は暗黙の条件で、楽しさを妨げることを止めるというものである。Step 1は楽しくないことを取り除くというもので、ダブルウィンになることが多い。Cummins氏はこう説明している:
普通、人というのはタスクを嫌います。なぜならそれに価値を加えないとわかっているからです。それゆえ、無駄、忙しい仕事、繰り返しのタスクを除外することは効率を上げ、そして仕事場をより楽しくするのです。
Step 2は楽しむこと。正しい種類の楽しさは、楽しんでいる人に大いに依存する。Cummins氏は万人が楽しめるというようなレシピはないだろうと言及した:
個人的には、楽しめるエクササイズ（ピンポンのような）を支持しています。エクササイズ・ブレークによって脳の機能が良くなるからです。しかしながら、クスクス笑ったり、ゲームをしたり、何か面白いものを見るのは全て良いことです。
Cummins氏はプログラミングと楽しさが互いにどう関係しているかを説明した:
プログラミングは楽しいです！ええと、限定しなければなりませんね。ついてない日、何もうまくいかない日とか、つまらない仕事が山積みなときは、プログラミングは恐らくそんなに楽しくないでしょう。しかしベストのときには、プログラミングは本当に楽しいものです - パズルがあって、そしてそのパズルを解いたときには、動くコードに対する報酬があるのです。そしてものづくりができるのです！プログラミングはクリエイティブな側面があり、また論理的な側面もあり、つまり複数の観点で満足感を得られるのです。
アジャイルは無駄を排除してフィードバックサイクルを短くするものだ、とCummins氏は述べた。彼女は、誰もが無駄だとわかっている仕事は、仕事場から楽しさを奪い、それゆえ頭上にある重いペーパーワークを除外することは人と生産性の双方の勝利なのだと言う。Cummins氏はまた、苦労を取り除くことが主要目的であるSREについても言及した:
苦労というのは繰り返しの、手動の、スタッフの時間を奪う面白くないタスクです。それは伝統的なオペレーションをすることよりも、SREチームウェイに沿うことがより楽しいものだとしてくれます。
フィードバックもまた重要だとCummins氏は述べた。よりタイトなフィードバックサイクルは正しいことをデリバリするより良いチャンスを与え、仕事の満足度も高めてくれる。”仕事をして、それを役に立たないものにしていくのが好きな人なんていません - わたしたちは、自分たちがうまくやっているかを知りたくて、自分たちの努力からのポジティブな影響を見たいのです。”とCummins氏は述べた。”最終的にわたしたちは、自分たちが作ったものを人々が使っているところを見たいのです。”
楽しさは人々が何をしているかではなく、どう感じているかについてである。Cummins氏は、マネージャは面白くしようと頑張るべきではないが、楽しさが花開ける文化を作ることはできると言及した。初めのステップは、チームが楽しさには耐用性があると知っているようにすること。そうすれば人々は笑ったり遊ぶことを恐れない。マネージャは自分たちが楽しむことで例を示すことができる。
InfoQは、世界的な開発リーダー、IBM GarageのHolly Cummins氏に、FlowCon France 2019 での講演後にインタビューを行った。
InfoQ: 仕事場での楽しさをどう定義しますか？
Holly Cummins氏: 例を以て楽しさを定義するのが一番便利だと思います。楽しさは心地良いもので、笑顔にさせてくれたり、笑ってしまう（楽しさのギークからは”ポジティブ・アフェクト”と呼ばれる）ものです。探検、遊び、パズル、ゲーム、ジョークが楽しいことに入ります。幼い子供にとっては、探検はガラガラで遊ぶことでしょう。開発者にとっては、Hello Worldをコンピューターに言わせることでしょう。Goで、コンテナで、Kubernetesで。子供のパズルはルービックキューブとなる一方、大人のパズルはGoのプログラムがなぜ大きなスタック・トレースを吐き出しているのかを解明することになるでしょう！
InfoQ: なぜ楽しさはそれほど重要なのでしょうか？
Cummins氏: 楽しさが緊張を和らげ、チームの団結を高め、病欠を低減するという証拠がたくさんあります。さらに驚くことには、楽しさは生産性と組織のパフォーマンスを高めるのです。楽しさが実にささいであっても、これは本当のことなのです。試験前にコメディの動画を見せられた人々は、何もしなかった人々より12%高いスコアを取ったのです。
InfoQ: 楽しさはどうやって測れますか？
Cummins氏: 楽しさを破壊するには測定するのが一番です。楽しさを定量化できないという意味ではありません - 楽しさを研究するのが仕事の人々は常にしていますので。わたしが好きな楽しさの理論的な測定は、”funtinuum”があります。しかしながら、楽しさをメトリクスによって制度化して、運用可能にしようとするなら… 楽しい環境にはならないでしょう。あるオフィスパーティーの悲しい話を聞いたことがあります。そこではマネージャが、全てのスタッフが命によって楽しんでいることを確かめるために出席を取ったというのです。明らかに逆効果です。
InfoQ: 人々に楽しんでもらうためには何をするべきでしょうか？
Cummins氏: 楽しさを得るためには、ふたつのステップがあると思っています; 初めのステップは、楽しくないことを取り除くこと。そしてそれができたら、楽しさが加わってきます。しかしながら、人々がわたしに楽しさに関する話を聞かせてくれるようになってから、実際にはそこに暗黙の条件があると気付きました。楽しさを妨げるものを止めるというものです。明確になっておくべきことなのに、明確になっていないのです。こんな悲しい話を聞きました。人事部がケーキを配るというEメールを送ることを禁止したというものや、マネジメントが分散チームに、終業後のチームビルディングエクササイズとしてDoomはできないと伝えたというものです。（率直に言って不可解な）要求は、もし彼らが5:30以降もオフィスにいるなら、仕事をしなければならないというものです。さらに誰かは、プロジェクトマネージャが彼らが楽しそうにしているのを見てこう言ったと教えてくれました。”君はなぜ笑顔なんだ？仕事場は楽しくなる場所じゃないんだ！”
InfoQ: ゲーミフィケーションと遊びはどう役立ちますか？
Cummins氏: ゲームと遊びは両方とも、学ぶ方法としてうってつけです。両方の単語を区別なく使うときもありますが、ゲームにはゴールとルールがある一方、遊びは非構造で、それ自体で完了します。ゲーミフィケーションは、ゴールとルールが組織の広いゴールにそろうため、マネジメントに対して明確なアピールとなります。10年に渡る技術的負債をマネジメントしていたあるチームは、何千もの新しい自動テストを作り、何百ものSonarQubeの問題をコンペティションを開催することで解決していました。興味深いのは、賞は大きくなかったということです - ただの無料ランチだったんですから！別の例にStackOverflowがあります。サポートフォーラムモデルのゲーミファイイングが質問と回答の両方を劇的に改善したのです。StackOverflowは形ある賞は全くなく、それでも人々は勝ちたがったのです。良い回答にポイントで報酬を与えることは実に効果的で、StackOverflowの前任者は多かれ少なかれ消えたのです。もっと微妙ですが、ベロシティの追跡もまたゲーミフィケーションの一種です - チームは数字が上がるのを見たいため、スプリントが終わる前に励み、もう1つポイントを獲得するのです。
遊びの利点はさらに定量化しにくいですが、同じく重要です。仕事場での遊びは、内部ツールの設計や、プロダクトの隠れ機能に自身の奇抜さを示します。これらの奇抜さはユーザと、それらを作った開発者の両方を喜ばせるのです。遊びはまた、何か新しいものを学ぶときにするものです。遊びはよく、イノベーションの前兆になります; 自分たちが知っている方法と、知らない方法の狭間を探検するとき、新しいアイデアを見つけるのです。IoTガジェットと虹色に染まったラボコートで有名なIBMフェローであるJohn Cohnの引用に、わたしが好きなものがあります。”クリエイティブになるために、遊ぶ時間を取らなきゃ。”