この本に書かれているのは，「⁠お金や仕事を超えて人々を情熱的にする方法」だ。原題の「People Powered」はこの「方法」によって力づけられた人々のことを指す。
その力づけられた人々こそが，世界のイノベーションがますます加速している秘密でもあり，日本のイノベーションがいまいちパッとしない理由でもある。
そう，本書は今の日本に足りないものが何かを見事に説明している。多くのビジネスが，この本で紹介するような「ピープル・パワード」を活かせずにいるのだ。

世界のビジネスを変えつつある開発のやり方

本書はLinux のようなオープンソース・ソフトウェアがどうやって開発されたか，のストーリーを語ることから始まる。エンジニアじゃない人にはちょっとイメージしづらいだろうが，OSやプログラミング言語，AI など，ほとんどのソフトウェアでは「だれでも開発に参加でき，成果がシェアされる」オープンソースのものが圧倒的に優勢だ。Googleやアリババのようなテックジャイアント企業が，自らソフトウェアを公開し，世界中のエンジニアを味方につけて開発を進めている。

オープンソース開発の利点は次のひと言で表される。

「ある人が1 時間かけてプロジェクトの改善に貢献し，他に10 人が同じことをしたら，その人は1時間の投資で10時間分の改善を他人から得たことになる（第2章⁠）⁠。」

ソフトウェアを公開し共同開発することで，開発パワーは何倍にもなる。Google やマイクロソフトが自社のソフトウェアをオープンソース化しているのはこのためだ。
本書の著者ジョノ・ベーコンは，Ubuntu やKubernetes といったソフトウェアのコミュニティを運営するにあたって，世界中の開発者をボランティアとして巻き込むことに成功し大きな業績をあげている。
開発エンジニアを集めるだけじゃなくて，使ってくれる人，広めてくれる人，デザインや宣伝ビデオを作ってくれる人たちを巻き込んで，プロモーションやマーケティングの部分でもベーコンは大きな仕事をした。今，オープンソースの世界では，「⁠Community Over Code（ソフトウェアそのものよりもそれを生み出すコミュニティが大事⁠）⁠」という考え方が一般的だ。
著者ベーコンの仕事はソフトウェアやエンジニアリングに限らない。彼はXPRIZEという非営利組織で，商用の宇宙旅行の実現を賞金つきプロジェクトとして開催するにあたって，さまざまな民間企業が切磋琢磨する形で進めることに成功した。
技術開発やビジネス開発にも限らない。著者はコミュニティ構築のコンサルタントとして仕事をしていて，本書にはミュージシャン同士の音楽制作や映画／ゲームのプロモーション，メディア企業，顧客満足度向上の事例も多く挙げられている。

企業のやり方とコミュニティをすり合わせることの難しさ

そんないいことづくめで世界をどんどん進化させているピープル・パワードなやりかたが，なんで日本ではパッとしてないかって？ この本ではコンサルタントとして日本や中国を含むさまざまな企業と仕事した著者の経験から，その理由が明確に説明されている。

「歴史的に見て企業は軍隊のような指揮と統制の環境だった。指揮官からトップダウンされる決定に，働き蜂が忠実にしたがう。だが，このモデルは日々通用しなくなりつつある（第5章⁠）⁠。」

昔ながらの企業や組織とコミュニティのやりかたは相性が悪いのだ。本書では著者のさまざまな経験から，山程の失敗事例が紹介されている。

「僕がいっしょに働いたとある会社では，これまで見た中で一番つまらないマーケティングメールを送っていた。行儀がいいだけの言葉が並び，それに意味なしコピーが書かれたコーヒーカップのストックフォトがくっついている，ありきたりで退屈なメール（第4章⁠）⁠。」

「ペルソナは君のチームや組織のなかで，オーディエンスがどういう人達かの意識合わせにつかうものだ。メンバーがコーンフレークにどういう種類の牛乳をかけるかみたいな無意味な細部の予想に使うようなものじゃない。むしろペルソナの要点を外している（第4章⁠）⁠。」

「人でもプラットフォームでもプロセスでも，くっつけたら，いろいろうまくいかない部分は出てくる（第6章⁠）⁠。」

会議のときだけ熱心で，実行になると知らんぷりをする担当者。コミュニティメンバーになってくれた消費者につまらない営業メールを送りたがるマーケター。細部への理解や直接のコミュニケーションをめんどうくさがりながら結果だけ求めようとするボス。いずれもこういう仕事を経験した人が「あるある」と頷きたくなるエピソードだ。さらに本書のいくつかの章は，ビジネスでコミュニティを手がけようとしてサッパリわからなくなった担当者の悲痛な訴えから始まる。そしてさまざまな失敗事例とともに，そうした失敗に陥らないための方法が紹介されている。
具体的な計画・実行のフレームワークを含めた具体的で詳細なガイドラインが，本書の最大のコンテンツだ。

なぜ本書を翻訳したか

僕は中国の深圳でオープンハードウェア周りの事業開発を仕事にしている。エンジニアや研究者に向けて新しいオープンハードウェアを，コミュニティを作りながら販売する仕事だ。IoT に興味がある人は，スイッチサイエンスという僕の会社や，Raspberry Pi，M5Stack といった代表的な取り扱い製品を聞いたことがあるだろう。コミュニティを利用してビジネスをしているだけでなく，深圳でニコ技深圳コミュニティを藤岡淳一氏と共同主催することで，仕事以外の部分でもテクノロジーについての知見をボランタリーに交換している。
この本を知ったきっかけは，自分もメンバーの1 人である中国最大のオープンソース組織，「⁠中国オープンソースアライアンス（開源社⁠）⁠」の年度会議でゲスト基調講演を務めたジョノ・ベーコンの講演を聞いたことだ。本書の英語版を読んで内容を知れば知るほど，僕の本業のビジネスも，ビジネス以外のこともうまくいくようになった。
そして，中国でさえ大きなイベントの基調講演に呼ばれるような人の本が，日本語版がないことを知った。中国企業はその後，オープンなコミュニティづくりに手間も金も大きくかけるようになっている。日本語版が出ることで，日本でもこうした内容が広まるとうれしい。その思いは，僕の前の翻訳書「ハードウェアハッカー新しいモノを作る破壊と創造の冒険」のときと同じで，本書の翻訳をした最大の理由だ。

カルト的・搾取的なコミュニティと本書の違い

この本で書いてあることはどんな目的でも応用できる。ここで注意すべきは，すべてのコミュニティがいいコミュニティとは限らないということだ。
2001年9月11日に，旅客機をハイジャックしてニューヨークの世界貿易センタービルに突っ込ませたのは，まぎれもなくコミュニティの力だ。「⁠ピープル・パワード」な人は，自爆テロだって起こしてしまう。
コミュニティ利用が日本ではパッとしないと書いたけど，マルチ商法まがいの副業サロンに課金して積極的にタダ働きや宣伝を引き受ける人，会社や学校をやめてしまう人は日本にもたくさん見られる。彼らも「ピープル・パワード」だ。なぜ，こんなことが起きてしまうのだろう。それは，本書でもコミュニティづくりの原則の一つとしてあげられる，「⁠親近性」が，悪い方向に利用されているからだ。監訳の山形浩生さんは，この「親近性 Relatedness」という単語に強い嫌悪感を示していた。

僕がこの本を翻訳しようとしたもう一つの理由は，「⁠だからこそ」だ。コミュニティの力を，そういうものたちだけに使わせるのはもったいないし，そういうものがコミュニティとされるのは腹が立つ。もっと日本のGDPを上げそうな組織や人々が，積極的に人々を「ピープル・パワード」させていくべきだ。
人間心理を理解した，褒めることや叱ることを含めたコミュニケーションを何度も繰り返されることで人々は「ピープル・パワード」になる。人は非合理そうに見える目的でも，毎日親密なコミュニケーションと，良し悪しのフィードバックを受けると信じ込んでしまうものだ。僕が親近性のある人，たとえば部活のマネージャーや自分の親から受けた影響はたくさんあるし，そのなかにはいいものも悪いものもある。人間に影響力を与えるうえで，親近性は大事だ。この本で紹介されるコミュニティ構築のメソッドは，論理的でかつ動物的でもある人間への深い理解のうえで，いいものにも悪いものにも作用できる（できてしまう）ように書かれている。仕事でもホビーでも，密接な集団のなかでセクハラやパワハラが起こるのはよくあることだ。
そのうえでジョノ・ベーコンはそうしたカルト的・搾取的なコミュニティ利用とはまったく別方向をむいている。僕たちが自分の受けている影響をあるていど客観的に見られるのは，複数のコミュニティに同時に参加しているからだ。カルト的な集団は必ず，「⁠自分たち以外との関係を遮断させよう」とする。勧誘をさせてマトモな人と付き合わなくさせるとか，自分たちの副業を勧めるとともに会社をやめるよう促すとか，素人の思いつきを勧めつつ大学などのマトモな勉強をやめさせようとするなどの手段で。本書では，人間は多くのコミュニティに同時に接続できるし，そのほうがいいことがきちんと説明されている。
さらに本書では，コミュニティ内の意思決定におけるオープンさと，開かれた議論の重要性，そしてそのうえで最終的には何かを決定して前に進まないとならないことが，きちんと説明されているのは見事だ。主要メンバーとプライベートな付き合いをすること，そうしたコミュニティメンバーとの付き合い方や評価が透明でオープンであることの両方の重要性を極めて具体的に，たとえば「コミュニティに多大な貢献をしてくれた重要メンバーを会議に招待するとき，向こうは自分の仕事を止めて君のために来てくれるのだから交通費やホテルは出すべきだが，あまり豪華にするべきではない」などと書いてある本はめったにない。親密さの重要性と危険性を，著者はどちらもすごくクリアに言葉にしている。
それこそが，カルトや搾取に陥らず，かつ会議ばかりで前に進まない小田原評定やエコヒイキに陥らないコミュニティの活かし方だろう。

「伽藍とバザール」から本書へ

本書はエンジニア向けに書かれた本ではなく，コミュニティをもっと上手に活用しようと考えるすべての人に向けて書かれた本だ。一方で著者のジョノ・ベーコンや解説の関治之さん，監訳の山形さんも僕もエンジニアの経験がある。関さんの解説には，彼が代表理事を務めるCode for Japan が，オープンソースの開発手法がどう役に立つのかについての名論文「伽藍とバザール」から始まったことが書かれている。テクニカルな細かい側面は置いといて，オープンソース・ソフトウェアの開発のやりかたそのものが，ソフトウェア開発を超えてさまざまな活動やビジネスに波及して，世界を変えているのはまちがいない。
1999 年に書かれた「伽藍とバザール」を無償で翻訳してネット公開して日本で紹介してくれた（しかも，続編ほか三部作ぜんぶ）のが，本書の監訳の山形浩生さんが中心になったフリー翻訳プロジェクト「プロジェクト杉田玄白」だ。僕がオープンソースに関心を持って，今まで活動しているのも「伽藍とバザール」がきっかけになっている。その意味で伽藍とバザールの原書英語版からプロジェクト杉田玄白，Code for Japan，そして本書の日本語版に至る20年以上の流れそのものが，「⁠ピープル・パワード」であると言えるだろう。 もしも読者がエンジニアで，まだ「伽藍とバザール」ほか三部作を読んでいないなら，ぜひ合わせて読んでもらいたい。リーダーシップやプロジェクトの進め方などについて，本書と共通する点は多い。
「⁠伽藍とバザール」の中で太字で強調されているこれらの言葉は，本書と同じ目線で書かれたものだ。

• ユーザを共同開発者として扱うのは，コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
• ベータテスタをすごく大事な資源であるかのように扱えば，向こうも実際に大事な資源となることで報いてくれる。
• いいアイデアを思いつく次善の策は，ユーザーからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
• 開発コーディネーターが，最低でもインターネットくらい使えるメディアを持っていて，圧力なしに先導するやりかたを知っている場合には，頭数は一つよりは多いほうが絶対にいい。
• ぼくたちは，もっといいソフトがつくれることを示しただけじゃない。よろこびが資産であることを証明してもいるんだ。

伽藍とバザールもエンジニアだけを対象に書かれた文書ではないが，この引用文にもあるとおり，例はすべてソフトウェア開発のものだ。本書は，「⁠伽藍とバザール」のチカラをエンジニア以外にも開放するための本とも言えるだろう。

日本のために：Code for Japanのようなコミュニティを増やそう。人々を力づけよう。

最終章で解説を書いてくれた関治之さんが代表理事を務めるCode for Japan は，東京都の新型コロナウイルス対策ほか，いくつもの社会問題をオープンな協力関係で解決する枠組みを作ることに成功した企業でありコミュニティだ。本書の内容を日本で根付かせるために，関さんに解説を依頼した。Code for Japanの事例を含め，日本でも「ピープル・パワード」が多くの成果を挙げていることがわかる，すばらしい解説になった。まず解説から読み始めるのもいいと思う。
多くの会社や組織（大学や役所が）に本書「ピープル・パワード」の知見を使って，オープンなコミュニティづくりを推進してほしい。
Code for Japanのような活動が増えることを心から願っている。
最後にまた「伽藍とバザール」から結びの言葉を引用する。これはあらゆる仕事に共通する言葉だ。 Happy Hacking!

「むしろぼくは，ソフトウェア（そしてあらゆる創造的またはプロフェッショナルな仕事）についての，もっと広い教訓をここで提示してみたい。人間は仕事をするとき，それが最適な挑戦ゾーンになっていると，いちばんうれしい。かんたんすぎて退屈でもいけないし，達成不可能なほどむずかしくてもダメだ。シヤワセなプログラマは，使いこなされていないこともなく，どうしようもない目標や，ストレスだらけのプロセスの摩擦でげんなりしていない。楽しみが能率をあげる。
自分の仕事のプロセスにびくびくゲロゲロ状態で関わり合う（それがつきはなした皮肉なやりかただったとしても）というのは，それ自体が，そのプロセスの失敗を告げるものととらえるべきだ。楽しさ，ユーモア，遊び心は，まさに財産だ。ぼくがさっき，「⁠シヤワセな集団」という表現を使ったのは，別に「シ」の頭韻のためだけじゃないし，Linux のマスコットがぬくぬくした幼形成熟（ネオテニー）っぽいペンギンなのもただの冗談じゃあない。
オープンソースの成功のいちばんだいじな影響の一つというのは，いちばん頭のいい仕事のしかたは遊ぶことだということを教えてくれることかもしれない」

翻訳について自分の英語力に不安があり，「⁠ハードウェアハッカー」と同じく，山形浩生さんに監訳をお願いした。翻訳に関するサポートページはこちら。