Project

General

Profile

ジョイ・インク

ジョイ・インク 役職も部署もない全員主役のマネジメント
リチャード・シェリダン

イントロダクション

あなたがなぜ本書を手に取ったか、僕にはわかっているんだ。あなた自身も望んでいる。望んでも仕方ないと思いながらも、あなたの仕事に喜びをもたらしたいと願っている。
あなたは心の奥底のどこかで、もっといい形でビジネスやチーム、会社、事業部を動かす方法があるとわかっている。これまでもずっとわかっていたはずだ。そうした考えが頭をかすめるのは、眠りに落ちるときや、目が覚めた瞬間かもしれない。だが仕事の一日が始まれば変化なんて考えは押しやられ、つなぎ合わせることのできない夢の破片のように蒸発してしまう。

あなたが人を集めてチームを作り、新しくて魅力的なものを作り出すのであれば、喜びの定義は簡単だ。
ちゃんと日の目を見られて、楽しんで使ってもらえて、意図した人びとに広く普及するものをデザインし、作り上げること。それが喜びである。
喜びを感じられるのは、プロダクトやサービスを世に送り出し、楽しんでもらえたときだ。

僕はとにかく、喜びが存在する場所で、喜びを知る人たちと、喜びの成果を出せる仕事をしたかった。仕事を楽しみながら、めざましい結果を出し、長続きするビジネスをしていきたかったんだ。

本書で紹介していくのは、経営者やマネジメントが職場環境に喜びをもたらすために使える知恵だ。予測可能な成果を生む。シンプルで繰り返し可能なプロセス。従来の人事が必要なくなる、効果的な人事管理。意図した消費者のために、専用に設計したプロダクト。問題を知らせる電話が決してかかってこない品質プラクティス。Joy, Inc.は官僚主義の入り込まない組織構造や、会議なしで意思決定する方法を教えているし、「作られた恐怖」を職場から取り除く効果、曖昧さを取り除いて人にエネルギーを与える方法を学ぶことができる。基本的な人間の原則を守ることについても考えていこう。尊厳、チームワーク、規律、信頼、そして喜びだ。

メンローへの訪問者のなかには、頭のいい良心的な研究者も数多い。彼らは僕たちが作り上げたものを観察し、メンローがうまくいっている理由の理論化に熱心になる。作り上げていく段階では僕らが組織設計やチームワークについて、深い理論的裏打ちをしていなかったと聞くと、たいてい混乱してしまう。メンローにとって喜びの文化を作るのはシンプルだった。毎日仕事に来るのが楽しみでしょうがなくなるような場所を作りたかったんだ。

人間の組織を導く原則は、飛行機を離陸させる原則と似ている。現代の空飛ぶ機械と、古代の人びとが飛ぼうとして失敗し続けた様とを比べてみてほしい。僕のキャリアの始め、マネージャーとして働いていたときはちょうどそんな感じだった。イカロスのように羽根をくっつけた翼を身に着け、全力で羽ばたき、決して空に浮きはしない。僕は全力で努力し、何も成し遂げられず、疲れ果ててしまった。

なぜライト兄弟が勝利しラングレーが敗北したかについては、たくさんの理論がある。僕の答えはシンプルだ。
ラングレーは飛行機を作ろうとしてた。ライト兄弟は空を飛びたかった。
ラングレーが追及していたのは歴史に名を残し、名声を得、儲けることだった。

人間とはより高みを目指すものだ。チームは自分たちを超えるゴールを目指して働きたいと願う。世界に対して、価値があって長く残る仕事をしたい。自分たちのしるしを残したいと思うが、栄光のためではない。喜びをもたらしたり、苦痛を終わらせたりしたいためだ。ライト兄弟と同じように、メンローの人びとは空を飛びたいんだ。この道を進んでいくと、利益、名声、栄光といったものがあとから付いてくるものともわかってきた。

メンローで僕たちは楽しみ、たくさん笑い、いつだってエネルギーが感じられるーだがいつも幸せというわけではない。僕たちは信条を共有している。僕たちは集中し、突き動かされる。ときには皮肉を言うことも、カンカンに頭にくることだってある。皮肉や怒りのエネルギーは仕事に向け、人類の苦痛を終わらせるという理想の実現に役立てる。僕たちがねらっている苦痛は、地球上で一番壊れている業界、IT業界が引き起こしているものだ。

僕たちの会社は重要で有意義な仕事に何年も携わった。何年間もずっと幸せであり続けるのは難しい。むしろ、幸せが成功に必須なのであれば、仕事が難しくなったとき、すぐ手を引いていただろう。目に見える、喜びあふれる成果を目指したからこそ、仕事を続けられたし、いまでも続けているのだ。

訓練と準備を重ねてきた戦闘機パイロットが、強風と戦いながら嵐の海に浮かぶ空母に視界の悪いなかF-18戦闘機を無事着艦させたときに感じるのが、喜びだ。エンジンが停止し、車輪が固定され、機体も空母も、甲板のチームも自分自身もみんな安全だと確認するーするとパイロットはすぐに、もう一回やりたくなって、いても立ってもいられなくなる。

人間は自身を超えるものを目指し、お互いにつながろうとするように、生まれついている。だからこそ僕たちはチームに参加し、会社に属し、必死に努力を重ねて困難なゴールを共有し、立ち向かう。

1章 僕が喜びにたどり着くまで

高校から大学のあいだ、僕の心には炎が明るく燃え続けていた。自分にとっても、世界にとっても未来は明るかった。コンピューターがすべてを変えようとしていたし、ソフトウェアはそれを実現する魔法だ。僕は大きなムーブメントのまっただなかに入りかかっていた。人類がこれまで経験した重要な大発見ー火、車輪、電気、写真、大量生産、テレビ、半導体、集積回路に並ぶものだ。目指す将来を考えて、ミシガン大学で情報工学の学位を取った。

始めてテレタイプに触れたときに感じた、圧倒的な喜びと発見への情熱もよみがえってきた。
こうしたことを思い返しながら、僕は大学時代の夢も思い出した。いつか、アナーバー随一のめちゃくちゃイカしたソフトウェアチームを作るという夢だ。
僕は自分が競争しているのだと、やっと気がついた。僕の心の炎は消えかかっている。私生活は、めちゃめちゃな仕事生活の言い訳になりつつある。

本を読みながら、他のビジネス書と同じように、インスピレーションも得たがフラストレーションも感じた。素晴らしい組織について書いてあるのに、どうやったらそんな組織を作れるのかは書いてないのだ。

ベックの手法そのままではないとはいえ、IDEOは熱意のある会社であり、密接な強調によるチームワークと顧客との素晴らしい関係性を持ち、優れたデザイン思考を持っていた。

エクストリーム・プログラミングを始める数週間前、実はクレアは会社を辞める相談をしてきていた。この実験で思いがけない金鉱を掘り当てたのは明らかだった。
「流血、暴力、殺人」と言われる一方で、「これならタダで働いてもいい」と言う人もいる。これは手応えのある反応だ。反応はM字型のカーブを描いている。両端にそれぞれ強い感情が表れているんだ。ベル型の、中央がゆるく盛り上がる形で感情が反応するようでは、大きな変化を導入しても長続きしない。僕はそう経験で学んでいた。中央ではなく、両極端からのエネルギーが必要なんだ。

「これからは、仕事もこのやり方でやっていこう」
以前にもあったように、部屋は死んだように静かになった。
そして全員口を揃えて、恐怖の面持ちで返事をした。「いやです！」

変化を持続させるには、古い報酬系をすぐに新しいものに置き換えなければいけない。新しい報酬系は、古いものと同等以上の価値を持たなければいけない（一番価値のある報酬は金銭と関係ないことに注意）。そうした新しい報酬を準備できないと、すぐに古い形式の古い報酬に戻ってしまう。
僕たちのチームの既存の報酬は何だったんだろう？

こちらには切り札がある。JAVAだ。ジェームズと僕はこう宣言した。新しいおもちゃで遊びたければ、たとえばJAVAの新しいアーキテクチャを考えたり、プロダクトをJAVAで書いたりしたければ、新しい手法で、新しい作業スペースでやりように、と。

世界が知らないことを僕たちは知っている。会社の目的は僕たちの喜びを世界にもたらすことだ。喜びは、僕たちが設計し開発するソフトウェアを通じて伝える。さらに喜びに満ちた手法やシステムを人に教えることにしよう。自分たちのやり方を秘密にするつもりは一切なかった。この業界において根本的に重要なものを見つけたんだ。自分たちだけに取っておくことはない。

2章 スペースとノイズ

僕たちのソフトウェアファクトリーは、人気があって、騒がしくて、その上楽しいレストランのように見えるかもしれない。
喜びの組織は、あらゆる方向からそう見えるべきだ。ビジネスに喜びのコンセプトを入れた会社を作ったと人に言うだけではしょうがない。スペースに初めて足を踏み入れた瞬間から、喜びが目に飛び込んできて、耳にあふれるようにしなければいけない。

誰も許可を求めなかったし、誰も自分が描いたと名乗り出ることもなかった。年１回のパーティに向けた、素晴らしく賢くて奇抜な準備だったと思う。
チームにとっては、柱と壁は全部白いキャンバスに見えるようだ。特別に、もしくは奇抜に装飾したくなる。チームにとってここは自分たちの場所であり、オーナーシップを持って自分たちの望むような場所に変えていくというコミットメントでもある。

そうした振る舞いはみんなの気に障るし、僕の気にも障る。メンローではそんなことは起こらない。聞こえる会話は、問題解決だったり、設計課題についてだったりだ。敬意をもった有用なノイズの流れを扱うのはたやすい。僕たちのオフィスで聞くノイズは、仕事のノイズなのだ。

3章 自由に学ぶ

使ってる言語は？JAVA、C#、Ruby、Microsoft .NET？「どんな言語でも使います。解こうとしている問題に最適なものを選びますね」。プログラマーたちはたじろいで、それじゃあどのテクノロジーを信奉するのかと重ねて聞いた。自分たちの顧客に一番適したテクノロジーです。ケアリーはそう答えた。

メンローでは誰も、特定のテクノロジーの知識で自分を規定したりしない。ソフトウェア開発者はさまざまなプログラミング言語を経験しているし、テクノロジーも最適なものを、目の前の問題に合わせて選択できる。特定のテクノロジーに偏向したり、不必要にこだわったりもしない。この業界では特異とも言える。
そのおかげで僕たちは、iPhoneとApp Storeがもたらした言語の変化にもすぐに対応できた。チームは出かけていってObjective-Cの本を買ってきた。数日後にはもう、顧客の要望を受けて、ペアでiPhoneアプリを書き始めていた。初めてのプロジェクトだったし言語にも不慣れで、そんなに速くも上手でもなかった。しかし協調的な、走りながら学ぶスタイルこそが、僕らの競争力の源だ。ペア作業を通じて、チームには学ぶ権利が認められているんだ。

僕がペア作業に初めて取り組んだのはインターフェイス社のJAVA工場だったが、マネージャー的な心の声と戦い続けなければいけなかった。要因配置の戦略として効率が悪すぎないか？一人ずつ作業するほうが生産性がよいのでは？一つの作業に二人分の給料を払うのか？ところが僕が実際に学んだのは、ペア作業はいままで見たなかでも最高のマネジメントツールだということだ。ペア作業により、従来あったたくさんの問題を解消できるようになる。ペア作業は学習システムを育む。また人間関係の構築、知識の塔の除去、新メンバーの立ち上げにも寄与し、生産性の問題を洗い出す役にも立つ。

非公式な調査結果だが、プログラマーの多くは一日４時間しか働いておらず、残りの時間はミーティングやワークフローの割り込み、またコンピューターのもたらす邪魔に取られている。ウェブの登場で状況は悪化し、スマートフォンでさらにひどくなっている。僕たちのスピードと集中力は、初めての人にはショッキングですらある。チームが働いているときは、邪魔は一切入らないーーー本当に働いているんだ。新人も２〜３週間するとこうした集中に慣れてくる。ある程度自分を調整していかないと、高い生産性を一日中発揮するような会社で働けるようにはならないんだ。

こうした伝統的な考え方を取り除けないようなら、顧客にとって我が社は合わないかもしれない。経験と熟練に頼ってはイノベーションを起こせない、僕たちはそう信じている。顧客のプロジェクトのため新しいプログラミング言語やツールを学ぶ。まさにそのための組織になっている。学ぶ機会があれば、僕たちは躊躇しない。本を買ってきて、ページを開き、働きながら学んでいくんだ。

知識の塔は周囲から大事にされているが、その人自身はそうした状況に満足しているだろうか？そんなことはない。デイブは安定した立場というメリットを初めのうちは感じるものの、やがて牢屋に閉じ込められて逃げ出せないような気分になってくる。知識の塔は組織全体のボトルネックとなってしまうんだ。デイブは休暇の予定を組めない。現在のプロジェクトだけでなく、すべての顧客からの緊急事態に対して、彼は欠かせない人物となっているためだ。

もしある日、デイブが新しいことに挑戦したくなり、未知の面白い分野を学ぼうと考えたら、どうなるだろうか。面白そうな仕事がすべて、自分より知識も経験も浅い人にアサインされていくのに、彼は気づくことになる。デイブには際立った得意分野があるのに、それ以外の仕事まで彼に任せる理由は会社側にはない。居心地のいい知識の塔が、突然ワナのように思えてくる。錆びついた鎖でデスクに縛りつけられているように思えてくる。会社を辞めて知識の塔から逃げ出すのも難しい。この業界の雇用慣行のためだ。デイブの履歴書には、一つの分野の深い知識しか記されていない。雇ってくれるのはその知識を求める会社だ。

メンローでは知識の塔を許していないものの、知識不足が許されるというわけでもない。いつも教わる一方で、そこから何も学ばず、毎週新しいパートナーにリードしてもらい続けるなんてことが許されるだろうか？そんなわけはない。

メンローニアンは教えるのと同時に、人前でのプレゼンテーションや説得力ある資料作成についても学んでいる。チームにはよいプレゼンター、よい教師になってほしいし、カンファレンスで発表もしてほしい。ラーニングランチというスタイルは、聴衆の前でプレゼンテーションする自信がつくよう、安全な環境で同僚を相手に練習するためでもある。

アクティブに学ぶ組織であるおかげで、チームは強くなり、メンローにとっても顧客にとってもより価値のあるチームとなる。お互いに、そして会社の外までメッセージを共有する能力を、それを維持しつつ強化するのが僕たちの文化の芯だ。文化を徹底するため、人間のグループであれば必ずそうするように、僕たちにも儀式と成果物がある。

4章 会話、儀式、道具

会議の参加者が真剣になるのは、自分よりも遅れている人がいるか探って、自分がクリティカルパスになっていないか見分けるところだけだ。

ペア作業をする環境では会話が必須なので、僕たちのスペースはノイズで埋め尽くされている。ノイズはエネルギーを高め、部屋の中でペアの間の新しい会話を促す。逆に、静かな環境では、人に接触するのはマナー違反と考える。ありがちなキュービクルの環境は、ステレオタイプ的な内向性の持つぎこちなさを強化してしまう。内向性のメリットは生かせていないのに。

あるときのハドルで、販売している食事のコストが高すぎるという問題が議題となった。皿洗い担当者が、フレンチフライが毎日大量に廃棄されていることを指摘したのだ。ビジネスの無駄のメトリクスを観察するのに、彼はこの上ないポジションにいた。結局のところ、皿洗い以上に無駄を目にする役目はいないのだ。
その会話を始めてから、ジンガーマン・ロードハウスのチームは、美しく、しかも彼らのおもてなしの心にも合致した解決策を考えついた。一皿あたりのフレンチフライの量を半分にするのだ。食事のコストも下げられる。そして、おかわり自由にすることで、顧客価値も下げないようにした。顧客はこのやり方を気に入った。フレンチフライのおかわりを頼む顧客は実際にはほとんどいなかったようだが。こうして無駄はなくなった。

難しい会話を一緒に続けながら、人を議論の対象にするのではなく、問題そのものに向けたいと考えている。
テーブルの同じ側に座り、共通のゴールに向かっていると感じられる会話は、僕たちの関係構築プロセスに不可欠だ。

そうか！顧客は、プロダクト開発以外の努力について自由裁量権を与えたくなかったのだ。僕たちは、顧客が価値を理解できるように、僕たちのしごとを説明する必要があったのだ。顧客が優先事項に照らして把握できるよう、会話を組み立てるべきだったのだ。

ビジネスの両側の間で、定期的かつ健全な会話が行われ、お互いをパートナーと感じられるようになれば、価値の競合から起こる無用な戦争を避けることができる。

見積もりはたいていマネジメントのしごとだ。チームがプロジェクトを把握したら、割り当て作業の締め切り、あるいは使える予算枠、もしくは次の四半期の売上高をマネジメントが指示し、命令する。リップサービスとしてチームに見積もりを尋ねたりするかもしれないが、チームの見積もりはたいてい相手にされない。
メンローでは、チームの見積もりを実際に作業するチームが出す。

見積もりは僕たちにとって最も重要な会話のひとつだ。その週に実行しなければいけないかもしれないすべてのタスクについて話し合うからだ。

QAを見積もりの儀式に巻き込んでおくと、ストーリーカードのタスク実施に変更が難しいコードがあるという話も聞ける。QAチームは質問をして、その週のテスト戦略について開発者に知らせることもできる。ストーリーカードの理解に混乱があると感じたら、QAは簡単な質問をすればよい。たとえば、「そのカードが完了したかどうか、QAはどこを見たらわかりますか？」などだ。もし、答えを聞いてもまだ混乱しているようなら、仕事を始める前にカードは書き直される。

どんな組織でも、不完全な情報にもとづいて未来を予測しなければならない。グループで口に出しながら考えることで、僕たちの見積もりプロセスは安全を作り出し、未知に対する恐怖を和らげることができる。またこのプラクティスにより、新しいプロジェクトの規模を見積もる能力を得た。僕たちは毎週見積もりをやっているので、新しいドメインに飛び込むのにひるんだりしない。

メンローでは、競合するかもしれない二つの絵を毎週の儀式で顧客と見せ合う。その儀式をショウ＆テルと呼んでいる。ショウ＆テルでは、その週にプロジェクトに携わったチームが聞き役となる。説明役は顧客だ。チームが達成した仕事の成果を顧客に説明してもらい、それをチームが聞くんだ。

ジェニファーの喜びようはタスクの複雑さや、完了までに必要だった努力と釣り合っていないように見えた。彼女は説明してくれた。シンプルなタスクを明確に完成できたのは、すごい進捗なのだと。「こんな仕事を長いことやってきたの」ジェニファーは言った。「プロジェクトが始まって、たった二週間しかたっていないのに、みなさんはハードウェアチームとソフトウェアチームが一緒に働けることをデモしてくれた。すごいことよ。ほとんどの会社は、デバイス開発に入ってから何ヶ月も、ときには何年もたたないと、チーム間で協力できたという結果を見せることができないの」

「ああ、私たちの説明をこう理解しちゃったのね」と言うこともある。「そう、まさに伝えたとおりだ。でも、実際に見てみたら、必要なのはこれじゃなかった」と言うこともある。どちらの場合も、僕らは成果に問題があるとは考えない。どちらも、すばやくたくさん間違えるという、僕たちの創業の哲学と沿っているからだ。すばやく失敗して、早く発見できれば、成果が小さいうちに修正できる。変更のための時間も予算もあるうちに。

人間のコミュニケーションは、間違った理解、間違った伝達、暗黙の前提に満ちている。関係性の問題のほとんどには、これらの危機がある。一方から見れば明白なことも、逆から見ると理解することさえ難しい。僕たちにとって誤解の壁を壊す唯一の方法は、関係者を一緒に集め、開発している技術を一緒に触って見たりする、構造化された儀式に放り込むことなのだ。

メンローでは、毎週の計画ゲームで顧客と一緒にプロジェクトの舵取りをしている。計画おりがみというテクニックを使い、プロジェクトマネージャーは顧客をガイドする。計画シートの上に、おりがみで作ったストーリーカードを乗せていくのだ。計画シートもストーリーカードも、物理的な大きさにより予算と時間を示す。ストーリーカードは開発する機能を示す。必要な時間は見積もりの儀式ですでに見積もってある。計画シートの大きさは、その週に使える時間を示している。

このシンプルな活動は、最も重要な会話と判断を促す。顧客はプロジェクトがコースから外れないよう制御できる。プロジェクトの舵取りがただ一人であることは少ない。研究開発部門には自分の最重要事項があるし、経営層にも他の最重要事項がある。マーケティングにも、営業にも、顧客サポートにも。それらの最重要事項は競合するが、それでもお互いに解決して、優先順位を決めなければいけない。いちばん重要な事項が、グループのディスカッションで話し合われるように。

計画ゲームは毎週の議論だが、いつも簡単にいくわけではない。でも、シンプルな計画作りの儀式が、会話を強制するのだ。情報が完全に揃うまで待つという贅沢は、プロジェクトチームには許されていない。それでも、判断を下さなければいけない。そのような判断は、協調的な会話と儀式のなかで下すほうがいい。疲れ果てたプロジェクトマネージャーが、深夜のオフィスで孤独にだらだらと判断を下すより、ずっといい。

メンローにおける見える化ボードの長老とも言うべき作業承認ボードが素晴らしいのは、曖昧なところが一切ない点だ。それぞれのペアは、自分たちが今週どのプロジェクトにアサインされ、これから五日間何をやるかの計画を明確に理解できる。完璧な専制という言葉が出てくるとは、面白い話だ。でも、ここで僕たちの自由という文化が動き始めるのだ。ペアは、自分たちが好きな仕事を追求する。「進み具合はどう？何やっているの？」などと聞いてきて仕事の邪魔をする奴はいない。僕たちにそんな奴は必要ない。

自分たちに割り当てられたカードを全部終えてしまったら、他のペアの列にあるカードにサインアップして、他のペアを助ける。もしすべてのペアが割り当てを終えてしまったら、顧客が計画作りのときに選んでおいた先行着手してよいストーリーカードが、計画シートの下に積み重ねてピンで留めてあるので、その上位から作業をする。こうすれば、その週のあいだずっと、スポンサーの優先順位にもとづいて、全員がタスクを実行できる。

オレンジのシールは、カードのチェックが必要という品質保証担当へのシグナルになる。品質ペアがやってきて、カードの作業を行ったプログラミングペアと話す。四人で、完了した仕事をレビューする。小さなショウ＆テルのようなものだ。

ボードには、ボード全体を横切るように一本の糸が貼られている。毎朝、糸の位置を動かす。日に日に糸の位置は下がっていく。うまく行っているときには、糸の上側にはオレンジと緑色のドットしかなく、黄色はない。糸の上側に黄色があったら、その週の予定どおりに進捗させるには、助けが必要なペアがいるということだ。自分のペアの列で、糸より下側にオレンジや緑色のドットがあるペアが、助けに行くことが多い。

紙に印刷して、バインダーに綴じて棚に置いておいても、設計のアイデアの議論のために棚から引っ張り出そうと考えるのは、よほどの変人だけだ。自分で確かめてみよう。自分の部門の三穴リングバインダーの上に、どれだけの埃がたまっている？ドキュメント管理システムにログインして、ドキュメントが最後に利用された日付を確かめてみよう。僕たちは、そんなシステムを皮肉を込めて霊廟と呼んでいる。ドキュメントを入れてしまったら、二度と出てこないからだ。

5章 インタビュー、採用、立ち上げ