読者です 読者をやめる 読者になる 読者になる

この国では犬が

本と芝居とソフトウェア

リモートワーク vs 一つのオフィス、あるいは個室

リモートワークが盛り上がっている

昨今、リモートワークが盛り上がっているようです。

何年も前からリモートワーク推進派の 37Signals はその名もずばり『強いチームはオフィスを捨てる』(原題は『REMOTE』)を出しましたし *1、日本でも KAIZEN platformハートレイルズ *2ソニックガーデン等、社員の多くがリモートワークだったり、リモートワークをいとわず受け入れているという会社も増えてきています。
僕が働いているアプレッソにも、一部ですが常時リモートの社員がいますし、僕のように普段は通勤している開発者にも(いまのところ台風が来た場合等の非常時に限りますが)リモートワークが認められています。

リモートワーク vs 一つのオフィス、あるいは個室

いち開発者として、リモートワークは魅力的に思えます。
一方で、ソフトウェア開発において、一つの場所に開発者たちが集まっていることが重要だ、という考え方もあります。
また、リモートとは違いますが、開発者たちには独立した個室を与えるべきだ、という立場もあるようです。

それぞれの立場から主張する書籍を読んでいると、真っ向から対立する主張があったりしてなかなか考えがまとまらないので、ここで文章にまとめてみます。

リモートワーク

リモートワークを支持する立場の筆頭はもちろん、『強いチームはオフィスを捨てる』です。

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

刺激的なフレーズが並びます。

要するに、会社にいたら仕事ができないということだ。本当に仕事がしたい人にとって、昼間の会社ほど最悪な場所はない。(pp.14)

ううむ。

会社の外にいれば、誰にも邪魔されないで思い切り仕事に集中できる。会社の雑音から離れるだけで、生産性は格段にアップするはずだ。 本当に仕事がしたかったら、会社になんか行かなければいい。(pp.15)

一理ある……。

プログラマは、割り込みを嫌います。
なぜ嫌うかといえば、プログラミングをぐっと大きく前に進めるためには、頭の中に多くのものごとを詰め込んで、一息に作業をすることが必要だからです。

割り込まれると、それらのものごとが発散してしまって、詰めるところからやり直しになってしまい、非効率です。(この非効率についての具体的なデータは、またのちほど別の書籍『ピープルウェア』から引用します)

そして、会社に雑音が多いのも、事実。

リモートワーク、その他のメリットとデメリット

また、他にもいくつものリモートワークのメリットが挙げられています。

  • 通勤しなくてよい
  • 働く時間をフレキシブルにできる
  • 都会に住まなくてもよい
  • そもそも住居にも縛られない(別の国に旅行しながら働いてもよい)

もちろん、デメリットについても(控えめに)触れられています。

  • 仲間と顔を合わせる機会がなくなる
  • 仕事とプライベートの切り替えが難しい

そして、それらに対処するための方法も語られています。

個人的な経験としては、僕がいる会社のリモートで働いている社員は「リモートだから」在籍している(できている)という面もありそうです。会社の立場で考えると、そういう人材を雇用できるということもメリットと言えます。

こうして見たところ、リモートワーク、やっぱりすごく魅力的です。

一つのオフィス(例 1 : XP)

対照的に、「一つのオフィスで、一つの空間に集まって仕事をすること」を支持する書籍もあります。

たとえば、XP にはその名もずばり「全員同席」というプラクティスがあります。

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

スピーカーフォンでチームミーティングをしたことがあるなら、面と向かっての会話とどれだけ違うか分かるだろう。生の話し合いと比べて、電話会議は遅くつっかえながら進む。会話そのものや、お互いに話し合っている人たちのあいだには、不快な隔たりがある。(pp.117)

わかります。

旧来の電話会議システムで一度ベトナムの開発者と会議をしたことがありますが、……いやあ。ひどいものでした。
また Skype による通話でも、音声の品質が悪かったり、顔が見えないので全員その場にいるのかどうかもわからなかったり、ネットワークの瞬断でいつの間に通信が切れていたりと、それなりのストレスがあります。

人々の距離が遠くなると、コミュニケーションの有効性も低下する。誤解が生まれ、遅延が紛れ込む。答えを待つ煩わしさを避けるために、推測し始める。すると間違いが起こる。(pp.118)

はい。

全員同席は答えを待つことによるムダをなくし、生産性を劇的に向上させることができる。同じ場所に席を並べたチームを使った 6 例の実地調査によると、全員同席すると生産性は 2 倍になり、製品化までの時間は社内基準のほぼ 1/3 にまで削減できたことがわかった [Teasley et al.] *3。(pp.119)

ほう……!?
しかし、この「生産性」として何をどう計測したのかが問題ではありますね。

すぐに助けが得られるような環境であっても、誰も質問しないようであれば何の役にも立たない。多くの組織では割り込みをやめさせるのだが、私のいる XP チームではむしろ割り込みを促している。(pp.120)

おお……。
ある意味、『強いチームはオフィスを捨てる』以上に刺激的な論調です。

ところが、XP における「全員同席」には、別のプラクティス「ペアプログラミング」を組み合わせる、という前提があります。

もしプログラマペアプログラミングをしていないなら、全員同席するのには注意しよう。1 人でプログラミングをするには静かな仕事場が必要になる。これに対して、ペアプログラミングをしていれば、プログラマは雑音を無視することができる。(pp.125)

なるほど、よくできていますね。

ペアプログラミングの是非についてここでは議論したくないので、もう少し広く解釈しておくと、「全員同席して高品質な情報共有を活発に行うことのメリットは大きいけれど、割り込みによる効率低下に対処するための方策が必要」ということになりそうです。

コミュニケーションの希少性?

ところで。

前出の『強いチームはオフィスを捨てる』には、こんな一節もありました。

たしかに直接会って話をしたり、ミーティングをしたりするのは大切だ。複雑でデリケートな問題について話し合うときには、相手の雰囲気を感じとれた方がうまくいく。 しかし一方で、いつも顔をあわせていると、「会う」ことの価値が下がってしまうのも事実だ。せっかく質の高いコミュニケーションができるチャンスなのに、みんな慣れすぎて惰性になってしまう。いくらでも無駄づかいできるものだから、メールなら 5 分ですむ内容を、くどくどと 45 分も話していたりする。(pp.222)

ううむ。
個人的には、「メールなら 5 分ですむ内容を、くどくどと 45 分も話していたりする」のは「同席していることの問題」ではまったくなくて、そもそも……という気がしますが、まあ、そういうとらえ方もできるかな、とは思います。

一つのオフィス(例 2 : Google

Google は現時点で「先進的企業」だと言ってよいと思いますが、Google も「一つのオフィス」を強く支持しています。
これは、ちょっと意外に感じます。

How Google Works (ハウ・グーグル・ワークス)  ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

「社員を窮屈な場所に押し込めよ」(!)というこれまたセンセーショナルなタイトルの項で、以下のように語られています。

お互いが手を伸ばせば相手の肩に触れられるような環境では、コミュニケーションやアイデアの交流を妨げるものは何もない。独立したキュービクルとオフィスが並ぶ従来型のオフィスレイアウトは、静寂がデフォルト状態だ。グループ間の交流はあらかじめ計画されたもの(会議室でのミーティング)か、偶然の出会い(廊下、給湯室、駐車場での会話)に限られる。だが、これを逆転させるべきだ。デフォルト状態として、活発な交流が起きている。騒々しく山ほどの人のいるオフィスでは、熱気あふれるエネルギーが渦巻いている。(pp.59)

実はこれには、個人的に思い当たるところがあります。

今座っている席と背中合わせに社長(元 CTO、創業者)の席があるので、その周辺でのコミュニケーションが僕のあたりまで漂ってきます。
僕がそれに加わること自体はほとんどないのですが、何というか、「エネルギー(と情報)が渦巻いている」のは確かです。

また、「アイデアの交流」の例としては、この間製品デザインの根幹に近いところで迷ったとき、相談に乗ってくれていた先輩エンジニアがちょうどそこにいた元 CTO に声をかけて、「なるほど!」と言えるような意見をもらって、方針がガラッと変わったこともありました。(もちろん、いいことです)

作るものがある程度決まっている場合は、いざ作るにあたっては(時間あたりのアウトプットの量という意味での)「生産性」を高めれば、おそらく十分と言えます。
一方、どういうものを作るのか、そもそも何を作るのか、あるいは作らないのか、といったところから考える必要があるとき、様々な技術、経験、考え方を持った人たちとの活発な交流から生まれるものは、決して小さくないはずです。

「一つのオフィス」に必要なもの

とはいえ。

集団からの刺激を存分に受けた従業員が、静かな場所に移動する自由も与えるべきだ。だからグーグルのオフィスには、たくさんの "隠れ家" が用意されている。人目につかないカフェの隅、ミニキッチン、小さな会議室、屋外のテラスや昼寝用ポッドまである。(pp.59)

はい。

これにも、やはり同意見です。
人の多い狭いオフィスで(にもかかわらず、のびのびと、また、集中すべきときに集中して)やっていけるのは、こういった "隠れ家" があればこそ、だろうなと。*4

もちろん、それこそ「生産性」という観点からは、どうしても「カフェ」「キッチン」「会議室」「テラス」「昼寝用ポッド」のすべてが必須、というわけではないでしょうけど。ここには、Google が優秀な社員を惹きつけておくための福利厚生としての側面も多少あるとは思います。

どうしても物理的な余剰空間が用意できなければ、「割り込み禁止の時間帯」のようなルールを決めて運用するというのも手かもしれません。
同じ Google の話である『Team Geek』には、こんなエピソードが紹介されていました。

ぼくたちがこれまでに見てきたチームの多くは、今は忙しいので邪魔しないでほしいという合図を作っていた。合言葉を使うチームと一緒に仕事をしたこともある。(中略)
ノイズキャンセリングヘッドフォンをエンジニアに配布して、ノイズに対処しようとするチームもある。ヘッドフォンを装着すると「邪魔をするな」という意思表示になるからだ。あるいは、緊急時以外は話しかけられないようにする合図として、トークンやぬいぐるみをモニタの上に置くチームもある。(pp.10)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

僕は、現状、個人的に作業ログ *5 やポモドーロ・テクニック *6 を使って、割り込みによる中断に対処しています。
これらは、それなりにうまくいっていると思いますが、Google のようにチームでやれることも何かあるのかもしれません。

実録・Google のオフィス

Google のオフィスの様子を紹介しておきます。

マウンテンビューにある本社、Googleplex。
3 番めの写真を見ると、たしかに、デスクは思いのほか狭いです。(ただ、それ以外の写真を見ると……)

また、テルアビブ(イスラエル)のオフィス(L 字型デスク)がアプレッソにちょっと似ていて面白かったので、紹介します。 10 番めと、11 番めの写真です。

一方、僕のデスク。

f:id:enk_enk:20140922002333p:plain

この写真だと全体像がわかりませんが……、似たような配置です。まあ、L 字型デスクを置くとこうなるよな、という配置ではあります。
それから、L 字型デスク「以外」はないので、悪しからず。笑

個室(例 1 : ピープルウェア)

さて、最後は「一つのオフィス」を認めながらも、「開発者には個室が必要である」とする立場です。

まずは、第II部がまるまる「オフィス環境と生産性」と銘打たれている、『ピープルウェア』。

ピープルウエア 第3版

ピープルウエア 第3版

部の冒頭の章で、「個室」というアイデアが出てきます。

生産性を阻害する個々の要因に対し、スタッフを守るために簡単で機械的に進められる解決策を探さなければならない。比較的余裕ががあれば、オフィスのレイアウトを間仕切りなしといういわゆる「開放型オフィス」から、個室形式のオフィス(1 ~ 3 人用程度)に変えることも考えてよい。(pp.41)

「職場環境」と「生産性」との関係を調べるために「プログラミングコンテスト」を開催した、その結果もあります。

コンテストで優れた成績(各成績を総合したもの)を収めたプログラマーの作業環境と、そうでない人のオフィスを比較すると、作業環境と生産性の相関関係は極めて顕著である。この調査では、優秀グループとして上位 4 分の 1 を、また最悪グループとして下位 4 分の 1 を抽出した。上位グループの生産性は下位グループの 2.6 倍優れていた。各グループのオフィス環境条件を表 8.1 に示す。

表 8.1 上位、下位グループのオフィス環境

環境要因 上位 1/4 のグループ 下位 1/4 のグループ
1. 一人あたりのスペース 78 平方フィート(7.0㎡) 46 平方フィート(4.5㎡)
2. 十分に静かか? 「はい」57% 「はい」29%
3. プライバシーは十分か? 「はい」62% 「はい」19%
4. 電話の呼出音を消せるか? 「はい」52% 「はい」10%
5. 電話を他へ転送できるか? 「はい」76% 「はい」19%
6. 無意味な中断は多いか? 「はい」38% 「はい」76%

(pp.55)

たしかに、顕著な差があります。
ただ、この調査が「課題として与えられた仕様を各社に持ち帰って実装する」という内容のもので、現実のプロジェクトの成果を直接計測しているわけではない、ということには注意が必要です。

個室がよい、とはいっても

また、個室を理想とはしながらも、開発者間の交流にも価値を見出していることがわかります。

部屋を仕切るという話になると、遅かれ早かれ「1 人で作業をすると生産性が低下する」という議論になる。しかし、部屋を仕切るといっても、一人部屋である必要はない。特に担当作業別に部屋割りしてあれば、2 ~ 4 人部屋というのも理にかなったものだ。(pp.90)

なるほど。

日頃密接に連絡を取るべき人々を物理的に引き離すことは、どの道全く意味がない。隣にいる作業者は、騒音と中断の発生源になる。作業者が同じチームにいるときは、同時に静かに仕事をすることが多いから、フロー状態を中断させられることも少ない。チームのメンバーを一緒にしておけば、チーム形成にとって必要な日常の何気ない会話を交わす機会も生まれる。(pp.166)

さすが古典ピープルウェア、議論に抜かりがないです。

個室(例 2 : More Joel On Software)

「個室」のメリットを強く主張するのは、『More Joel On Software』の「バイオニックオフィス」という章です。

More Joel on Software

More Joel on Software

適切なオフィス空間、特に個室がプログラマの生産性を上げることについては、多くの証拠がある。(pp.219)

たとえば、前述のピープルウェアの主張などがそう言えるのでしょう。

また、採用、人材確保のために個室が有効だ、という立場でもあります。

窓のついている目を奪われるくらい素敵な個室のオフィスは、単にできがいいというソフトウェア開発者より 10 倍も生産的なスーパースターの採用を容易にしてくれる。(pp.220)

これはデータを待つまでもなく、いち開発者として、そりゃそうだろうなと思います。

共用スペースの必要性もしっかりおさえています。

オフィスは、そこで時を過ごすのが快適なたまり場のような場所であるべきだ。仕事の後に友達と食事に行くのであれば、オフィスで待ち合わせしたいはずだ。(pp.220)

窓だらけの Fog Creek Software

最後に、著者の Joel のこういった考えをもとに設計された、 Fog Creek Software のオフィスの様子をリンクしておきます。
Google ストリートビューで、オフィス内の様子(!)を見ることができます。

広い共用スペースがあって、向かって左側には個室が見えますね。そして、とにかく窓が多くて、明るい!
うーむ、めちゃめちゃ良い……。

なお、「従業員に個室を与える」ことを実践している大企業としては、Microsoft が有名です。

そういえば、Joel は Microsoft 出身者でした。

まとめ

リモートワーク、一つのオフィス、それから個室について、様々な立場からの主張を検討してきました。

考えてみて、おおむねこういうことが言えるのではないか、と思っています。

  • リモートワークは、実現可能である。また、多くのメリットもある。
  • 一方で、リモートワークでは得られない、対面での広帯域・高品質なコミュニケーションも(今のところまだ)たしかに存在する。

  • 開発者を一つの空間に集めることで、コミュニケーションを活発化させ、自然な情報共有を促進したり、アイデアの発生を促すことができる。

  • 一方で、開発者が開発作業を進められるように、ペアプログラミングを採用したり、静かな場所も用意しておいたりといった工夫も必要。

  • 個室は、開発者の生産性を高めるために有効。ただし、開発者同士の自然なコミュニケーションを促すような空間もあった方がやはり望ましい。

  • また、個室は、優秀な開発者を惹きつけるためにも有効。

こうしてまとめてみるまでは「本当のことを言っているのはいったい誰なんだ!」とばかり混乱していましたが、それぞれにメリット・デメリットがあり、その組織の目標が何かによってもどこに寄せるべきかは異なってくる、という(ある意味当たり前の……)ことがわかってきました。

リモートワークのこれから

『How Google Works』でまさに著者自身が言っているように、そう遠くない将来、リモートワークでも(目的によっては)同じ場所にいるのと同じくらい広帯域・高品質なコミュニケーションが取れる日が来るでしょう。

ビノッド・コースラは、一九八〇年にはマイクロプロセッサがコンピュータだけでなく、自動車や電動歯ブラシなど、ありとあらゆるモノに使われるようになることなど想像もできなかった、と指摘する。
(中略)
マイクロプロセッサ、携帯電話、インターネットはそれこそどこにでもあるが、それぞれの草創期にこうした事態を予測した者はいなかった。それにもかかわらず、私たちはいまだに同じ失敗を繰り返している。グーグルが自動運転車のプロジェクトを発表したときの一般的な反応は、「あり得ない」というものだった。車が自分で走るなんて、あり得ないでしょ? だが私たちは当然、あり得ると思っている。(pp.344)

リモートと同席とのコミュニケーションコストが同じになる未来も、当然、あり得る。
ただ、今はその一歩か二歩ばかり手前なのかな、と思います。

KAIZEN platform の技術顧問を務める @naoya_ito さんが、リモートワークについて色々実践して、書かれています。

僕は将来「東京近郊」に住んで片道何十分もかけて通勤する、みたいなのがものっそいものっそい嫌なので、早くリモートワークの時代、リモートワークで、『How Google Works』で主張されているような「コミュニケーションとアイデアの交流」が実現される時代が来てほしい、と願っています。鎌倉からリモート勤務したいです。

*1:と書いたあとに調べてわかったのですが、「BaseCamp」に社名変更していました : 米37signalsがBasecampに社名を変更、事業集中で他サービスは売却も検討 -INTERNET Watch Watch

*2:……と書いたあとに調べてわかったのですが、ハートレイルズはなんと 2006年(!)の創業当時からリモートワークにこだわっているとのことです : ハートレイルズ流、リモートワークのススメ - HeartRails Tech Blog

*3:Teasley, Stephanie Lisa Covi, M.S. Krishnan, Judith Olson. 2002. "Rapid Software Development Through Team Collocation." IEEE Trans. Softw. Eng. 28(7):671-83. http://dx.doi.org/10.1109/TSE.2002.1019481

*4:誤解のないように言っておくと、今のオフィスが狭くて、全然のびのびとやれない、ということではないです。相対的には、「のびのびとやれる側」には違いないと思います。ただ、もっとよくできるはず、ということです

*5:作業ログのすすめ - この国では犬が

*6:ポモドーロと Trello によるタスク管理(2 of 3 : ポモドーロ編) - この国では犬が

広告を非表示にする