portal shit!

Basecamp で従業員の大量離職騒動が起きていた。原因は社内で社会問題についての議論を禁止するという制度変更への反発。

Basecamp の制度変更の要旨
1. 社内での政治的な発言禁止
2. ジムなどの福利厚生終了（特定の価値観に基づくため）
3. 〇〇委員会禁止（仕事は個々人で）
4. 過去の決定を議論するの禁止
5. 360度評価終了（いい評価しか付かず役に立たないため）
6. 本業を忘れるな（ソフトウェアを作ることが仕事）

— morygonzalez (@morygonzalez) May 1, 2021

この制度変更の背景にはさらにややこしい問題があったようだ。

この記事にこれまでの出来事がまとめてある。 Jason Fried の制度変更表明はこれらの出来事に符合するものみたい。https://t.co/rys1Tx4BKG

— morygonzalez (@morygonzalez) April 30, 2021

この騒動を経て、以前 HEY を使ったときの感想として書いた以下の記事のことを思い出した。

ソフトウェアに必要なのは理念ではなく機能だ。そのことは Jason Fried も書いている。

6. No forgetting what we do here. We make project management, team communication, and email software. We are not a social impact company. Our impact is contained to what we do and how we do it.

ただ、 Jason Fried も DHH も本、 Twitter 、ブログで業務の一環かのように他社のソフトウェアやビジネスモデルに難癖を付けたりと舌鋒鋭い。その一方で従業員に社内で社会問題を議論をさせないのは矛盾しているような気がする。

以前書いた記事では、 Flickr は理念のみで機能が不足しているということを指摘した。 Basecamp の HEY については理念だけでなく、それを裏付ける機能があると支持した。しかし今回の騒動を見るに、理念の部分がだいぶ強すぎたと感じる。理念に引き寄せられて opinionated な人たちが集まったが、理念を表明して良いのは経営者だけで従業員は仕事だけして下さいと言われると反感を買うのは当然だろう。

理念や社会に対する意見があることは結構なことだと思う。しかしそれを声高に表明して回ることはソフトウェア会社の仕事ではないと思う。ソフトウェア会社の仕事はただ一つで、その理念に基づいたソフトウェアを作ることなはずだ。

そもそもソフトウェアで社会を変えられるのだろうか。自分はそうは思わない。世の中がソフトウェアをきっかけにして変わるだけだ。ソフトウェアは人々の内側にあった曖昧模糊とした欲求を具現化して解消しただけに過ぎない。 Uber で車と時間を持て余している人がお金を得られるようになったし、全然タクシーがつかまらなくて困っていた人はふっかけられることなく車で移動できるようになった。これは元々潜在的に存在していた需要と供給を顕在化させて結び付けただけだに過ぎない。どんなに画期的なソフトウェアやサービスも、人々に必要だと思われなければ意味がない。

崇高な理念や信念があったとして、それをいかにソフトウェアに吹き込むかがソフトウェア企業のやるべきことだ。自分は Rails エンジニアとしてソフトウェア業界に橋頭堡を築いたので DHH のことは尊敬しているけど、 Basecamp には人々に求められる良いソフトウェアを作ることにフォーカスして欲しいし、自分もそういう姿勢でソフトウェア開発に携わっていきたい。

※初出は HEY World の https://world.hey.com/hitoshi.nakashima/post-7e01e658 です

Flickr が値上げしたときはとても愚かだと思った。

彼らの言い分は「潰れそうだから支援してくれ、自分たちは高潔なポリシーで運営していてユーザーのプライバシーを他人に売り渡したりしないし、写真好きな人のためのコミュニティを作ろうとしている、我々にとってユーザーは製品ではなくプライオリティなのだ」というものだった。

立派な理屈だが、残念ながら値段が高すぎるし（年間 6000 円近い）、 Pro プランのメリットをほとんど感じることが出来ないし、そもそもユーザーが少なくなってきててガチの写真家しかおらず居心地もあまり良くなかった。友達はみんな Instagram を使っているのになぜ自分だけ一人で Flickr を使い続けないといけないんだ？ 写真のストレージなら Google Photos が無料で使えるのに（ Flickr が値上げを発表した当時はまだ Google Photos は無料だった）。

Basecamp も常々、ユーザーのプライバシーを大事にしているということを声高に叫んでいる。 HEY ではメール配信サービスのトラッカー（ Spy Pixels ）がブロックされるようになっている。 Flickr （と Flickr を買収した SmugMug ）と似たような哲学だが、 Basecamp の方が理念と行動が一致している。 Flickr は「ユーザーはプロダクトではない」と言いながら結局無料ユーザーには広告（リターゲティング広告）を見せている。

機能面でも HEY はよく出来ていて、お金を払うのに十分な価値があると感じる。一方で Flickr には機能面での価値提示がない。これがあるから Flickr を使いたい、と思えるものがないのだ。

理念に共感して金を払えと言ってもユーザーにはなかなか理解してもらえない。少なくとも自分は理念に金を払えるほど裕福じゃない。高潔な理念を打ち出すならそれに見合う価値提示が製品に求められると思う。

その理念は機能に裏打ちされたものだろうか？

Basecamp が始めたメールサービスの HEY に登録した。去年のリリース時にお試ししていたのだけど、踏ん切りが付かなくてお金を払わなかった。ただ、ソフトウェアにお金を払うことに対していろいろ思うところがあって、良いと思うものにはお金を払おうと思って HEY に登録してみることにした。

脱受信トレイ（ Inbox ）のお気楽なメール管理

意識高く金を払って気分が良いというだけでなく、 HEY 自体がよくできてて、これまでと違ったメール体験を提供してくれる。 HEY 以前にメインで使っていた Spark も悪くはないのだが、やはり古典的なメールソフトの概念と、 Google が発明した Gmail の「受信トレイ（ Inbox ）」と「アーカイブ」の概念を引きずっている。とにかく全部のメールに目を通してアーカイブしていく作業に疲れてしまった。

HEY は最初のオンボーディングチュートリアルで使い方を学びつつ最低限の振り分け設定を行え、 15 通くらいメールの仕分けをするとその後大体いい感じにメールが振り分けられるようになる。 Imbox 、 The Feed 、 Paper Trail という三つの箱があって、重要なメールやまだ仕分けルール付けがされていないものは Imbox に、メールマガジンなどマーケティング的なメールは The Feed に、購入時のレシート的なメールは Paper Trail に、という風にメールを仕分けて使うことが想定されている。仕分け処理をやるとメールアドレスに紐付いて設定が保存され、以後そのメールアドレスからのメールは設定した仕分け先に入るようになる。一々受信トレイに来たものをアーカイブする必要はないし、受信トレイをすっ飛ばしていきなりアーカイブに放り込んでお得情報メールを見逃すということもない。 The Feed を余裕があるときに見ればよい。メールマガジンはチラシのようなものなのだということに HEY を使って初めて気がついた。

Gmail にも「メイン」、「ソーシャル」、「プロモーション」、「新着」、「フォーラム」というカテゴリー分けのような機能は存在するが、「これはここじゃないんだけどなぁ」と思うことがよくあるし、分類先を変えたいと思ったらフィルタールールを作って移動させないといけない。一々こんな仕分け作業をやってられない。一回メールの仕分けをしたら以後は自動的に同じルールを適用して欲しい。 HEY はそれをやってくれる。

Contacts という概念

HEY には独立した Contacts がある。 iPhone の Messages などメッセージアプリだと「誰とやりとりしたか」から履歴を辿れる。「友だちのノブヒデ君とやりとりしたメールを見返したい」と思うことはあると思う。メッセージアプリで普通にできることを、メールの場合はメールアドレスなどで検索するしかなかった。 HEY の場合は Contacts にアクセスして相手の名前を選ぶだけでよい。「誰とやりとりしたか」から目的のメールを探せるのが HEY のユニークなところだ。

Contacts は自分でいい感じに整理することもできる。例えば以下のキャプチャでは、 Apple の二つのメールアドレスがある。

Apple 社としてはメールを送る部門ごとにメールアドレスを使い分けているのだろうけど、こっちからしたらどっちも Apple なので統合してしまいたい。片方を開いて、サブのメールアドレスとしてもう一方のメールアドレスを登録する。

保存すると、「このメールアドレスはすでに Contacts に存在するけど統合する？」と聞かれる。

ここで "Yes, merge them" を押すと統合され、 Contacts 一覧からメールを辿るときにも統合して表示される。めっちゃ便利。

その他の便利な機能

そのほかにも、同じような要件で別々に届いたメールをスレッドとしてひとまとまりにしたり、メールを開封したかどうかを調べる解析用の gif 画像を読み込まないようにしたりなど、これまでのメールソフトにはない機能がある。まだまだ使いこなし切れてない。

HEY はガワか？

これまで Gmail のメールアドレスをいろんな場所で登録してきたのでいまも大半のメールは Gmail に届いている。各所を変更して回るのは大変だし、死ぬまで毎年 $99 を払える自信がないので Gmail から @hey.com のメールアドレスに転送するようにしている。なのでいまの自分の HEY の使い方はガワというかメールクライアントみたいな感じだ。メール本体は Gmail にあってそれを HEY のインターフェース越しに読んでいる。これならガワとして、つまりメールクライアントとしてサービスを提供してもらった方がユーザーは自分のメールアドレスを持ち込みで使えてスイッチングコストが発生せずうれしい気がするのだけど、 Basecamp はそうしないみたいだ。 HEY のマニフェエストの先頭に、メールクライアントではなくプラットフォームであることが宣言されている。

A platform, not a client

To make significant, meaningful upgrades to email, you need to build your own platform. That’s why HEY isn’t an app that sits on top of Gmail, Outlook, iCloud, Yahoo, etc. HEY is a full email service provider. You don’t use HEY to check your Gmail account, you use HEY to check your HEY account. It’s its own platform, and it’s all you’ll need.

真に意味のある変革を E メールにもたらすためには、独自のプラットフォームを構築する必要があるということだ。スレッドの統合や検索の性能向上（サーバーサイドとクライアントサイドが連携した一気通貫の検索システム）など、確かにただのガワでは実現できない部分があるのだろう。

そのほかにも The HEY Way のページには過去のメールを HEY に移行できない理由など、「割り切り」コンセプトの理由が書かれている。まるで "Getting Real" や "Rework" からの抜粋かのようだ。

HEY の残念な点

概ねにおいてよくできているのだけど、一部で使い勝手が良くない点がある。

Rebuild のエピソード 272 でヒロシマさんも言っていたけど、アプリがネイティブ実装ではなく HTML で作られているせいで、特に Mac のクライアントが Mac らしくない。一覧から詳細に遷移し、もう一度一覧に戻るときにもっさりする。 HTML を再レンダリングしているからだと思われる。個々の画面の表示は別に遅くないのだけど、総合的な体験としては良くなくて、ヒロシマさんが「速いけど遅い」と言っているのは言い得て妙だ。この辺は DHH の思想 が反映されているのだろう。

iOS 版アプリにタブがなくて移動しづらいというのもそう。 Mac であればショートカットキーで Imbox 、 The Feed 、 Paper Trail を行き来できるけど、タッチ UI ではショートカットキーが使えないので一々 HEY メニューを経由する必要がある。

総じて

不満な点がないわけではないが、 HEY がこれまでのメール体験を刷新するものであることは間違いない。インターネットを始めたばかりの頃、メールは届くととてもうれしかった。 『 You've Got Mail 』というトム・ハンクスとメグ・ライアンの映画もあったくらいだ。それがいまではメールは面倒なもの、しょうもないもの、スパムや広告だらけのものという印象を持たれるようになってしまった。その認識をひっくり返そうという試みは面白い。死ぬまで使い続けるかはわからないけど、とりあえず一年分の料金は払ったので活用してみようと思う。

プログラマーの種類、いろいろあると思う。

1. ハッカー
   プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。
2. OSS プログラマー
   1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。
3. プロダクト指向プログラマー
   開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。
4. サラリーマンプログラマー
   プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。

1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。

職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネージャーや営業が偉かった。プログラマーの人たちは仕事のために仕方なくプログラミングしてた。

それが嫌で余暇でもコード書くような人たちがいる職場に移ったけど、そこではハッカーや OSS プログラマーがよいプログラマーの代表とされていた（と思う）。自分もそういうのを目指し OSS カンファレンスに登壇したり技術的に中身のあるブログ記事を書いたりしたいと思ったけど、なかなかよいコードは書けないし、結婚して所帯を持つと町内会の草むしりや廃品回収、町内の運動会のテント設営、審判にかり出され、またあるときは子どもの幼稚園に夫婦そろって呼び出されて「お前らは夫婦そろって人間の屑以下だ、心を入れ替えるか幼稚園を辞めるかどっちか選べ」と説教されるなど多忙を極め、勉強会で話したりブログ記事を書いたりということが難しくなった。

一時期は自分は凡人プログラマーなんだろうなぁ、かつて忌み嫌っていたサラリーマンプログラマーと同じなのかなぁ、と将来を悲観していた。この頃は技術的な伸びしろがなくなって学ぶことに対する意欲が失せてしまっていた。

ただ、仕事で失敗プロジェクトを担当してつらい目に遭うことが多く、チームで仕事することだとか、失敗からどう学ぶかとか、その手のことに関してはそこそこ知見が貯まっていった。どうすればチーム開発はうまくいくのか、どういう風に情報を共有すればいいのかなどなど。業務改善のためにちょっとしたスクリプト書いたり、ぶっ壊れて動かなくなってる hubot スクリプトを直したり、 CI のセットアップを頑張ったりと、エンジニアチーム全体の生産性を上げるような落ち穂拾い業務みたいなタスクも好きだった。

いまは自分はチーム開発プログラマーなんだろうなぁと思う。ハッカー気質は皆無じゃないけどそこそこ、 OSS へのコントリビュートも気が向いたときに、プロダクトのことを気にする気持ちもある。どれも中途半端で単独では生産性高くないけどチームで仕事をするときに効能を発揮するタイプ。こんな風に自分が適している役割が分かると仕事がやりやすくなるし、目指すべき方向性のようなものが明確になって将来のことを考える上でも役に立つ。

ベンチャー企業で働く場合は自分のマインドやスキルセットが会社のステージにフィットすることも大事だと思う。もともとはベンチャー企業でも成功して上場しているような会社だとデプロイ時にハンコリレーなどがあってやるべきことをやるべきときにババッとやるのが難しい。そういうのは自分には向いてない。一方で起業したばかりの小さなスタートアップも、自分のような最初から綺麗なコードを書こうとするプログラマーはきっとフィットしない。起業したばかりのスタートアップでは自分たちの事業が社会から求められるかどうか不透明なので、そんな状態でテストがどうだとか CI がどうだとかチーム体制がどうだとかを言うようなプログラマーは必要ない。汚くてもクソコードでもテストコードなんて存在しなくてもいいからとにかく金を生み出すコードを素早く書ける人が向いている。

その意味でいまいる会社は創業当初の価値仮説の検証は済んでいて、これからいかに事業を伸ばしていくかというステージに入っているので、ちゃんとテストを書いたり、 CI を導入して継続的インテグレーションに努めたり、デプロイをいい感じにしたり、情報共有ツールを導入したり、開発チームの組織体制を云々したりといった部分で価値を発揮しやすい。

一握りの本当に優秀なソフトウェアエンジニアってのは受託会社だろうが事業会社だろうがベンチャーだろうが大企業だろうがどこにいたって価値を発揮できるのかもしれない。しかし自分のようなすべてにおいて中途半端なプログラマーは、自分に何ができるのかを理解し自分を必要とする規模とステージの会社を見つけてそこの門を叩くのがよいと思う。もちろん、事業に共感できるとか、チームメンバーとの相性も大事だけど、事業に共感できてもチームのメンバーがいい人ばかりでも、会社の規模やステージが自分を必要としなければ価値を発揮することは難しい。

関連してそうな記事

Ruby on Railsの生みの親、デイヴィッド・ハイネマイヤー・ハンソンの勤務先37シグナルズの本。CEOのジェイソン・フリードとデイヴィッドの共著です。とても共感しながら読むことが出来ました。個人的に響いた部分を箇条書き。

計画をやめる

• 計画を予想に言い換える。誰にも未来のことを計画するなんて不可能。
• 計画はあらかじめ立てるのではなく、やりながら立てる。やっていないと情報が集まってこない。

最適な規模

• 無意味に拡張しない。規模の拡大はコストも増やす。
• 働きすぎるのは馬鹿。ヒーローになるな。

自分たちが必要なものをつくる

• 37シグナルズの Highrise は自分たちが必要性に駆られて作った。

まずつくる

• アイディアは実行しなかったらアイディアのまま。
• 金がないとか時間がないとか言い訳にならない。ベストな状態で始められることなんてない。本当に実現したいことだったら金や時間は自分で工面をつけるもの。

金を借りない

• ウェブサービスとかは特に金が必要ない。
• 他人の金が入ると感覚がおかしくなるし、長期的な視野を持てない。

なんでもまず自分たちでやる

• 会社の規模はコンパクトに維持し続けるべき。
• まずなんでも自分たちでやってみる。できなかったら人を雇う。

スタートアップという意識を捨てる

• スタートアップには甘えがある。
• 他人の金で好きなことをやるなんて幻想。
• 最初から利益の出せる企業を目指すべき。
• exitのことを考えるとユーザー本意のサービスが作れなくなる。

制約を利用する

• 優れた作家は制約のもとで創作していた。シェイクスピア、ヘミングウェイ、カーヴァー。
• 一度にサービスに携わる人間は一人か二人に限定し、機能は絞る。
• 芯から作り、本質的でない細かい部分は後回しにする。

副産物

• 企業は自分たちが気づかないうちに副産物を生産している。木工所はおがくずを売った。37signalsはGetting Realという本を副産物として売った。

すぐリリース

• 不完全な状態でも最低限な条件をクリアしたらすぐにリリース。

会議をやるやつは馬鹿

• 会議は時間の無駄。やっても7分。
• 会議には準備が必要だが、十分に準備することは不可能。
• 1時間の会議に10人が参加したら、10時間の生産性が犠牲になる。会議にそんな価値はない。
• 会議は新たな会議を生み出すだけなので不毛。

一人で作業する時間をつくる

• 電話とかメールとかシャットアウトする時間を作らないと生産性は上がらない。
• せめて一日の前半か後半のどちらかは一人作業モードに設定すべき。
• 連絡手段は電話やチャットなど即時対応式のもではなくなるべくメールにする。

そこそこの解決策

• 完璧な解決を求めようとしない。そこそこの手段で済む問題にはそこそこの解決策を。問題があれば後から良くすればいい。

タスクは分割する

• 長大なタスクリストは気が滅入るだけ。
• 100のタスクを10ずつに分解すれば心理的に楽になる。

はまったら人に見てもらう

• 意固地になって無駄に時間を費やすとコストに見合わなくなる。
• はまったら他の人に冷静な視点でレビューしてもらう。

寝る

• 睡眠不足は創造性を損なうし、士気が低下する。間違いも犯しやすくなり、他人に不寛容になる。いいことは一つもない。

真似ない

• コピペコードは理解が伴わないから、いつまで経ってもオリジナル作者にかなわない。

社員が一緒の国に住んでる必要はない（デイヴィッドは入社当初はまだデンマークにいたらしいです）とか他にも面白いところもあるんだけど、英語がしゃべれないとこの辺は僕らには当てはまらないですよね。あと会議を極力しないってのは理想だと思うけど、受託開発というかホームページ制作みたいなお客さんがいる仕事してたら打ち合わせはしないといけないわけで、なかなか難しいでしょう。

でも電話や会議などは確かに生産性を損ねていると思う。電話なんていきなり日常業務に割り込んでくるわけだから。電話は予約制にして欲しい。何日の何時に電話したいのでお願いしますみたいな感じでメールしろや。

雑談の排除とかも大事ですよね。僕はなるべく仕事中は雑談しないようにしてる。だからといって生産性が高いかと問われれば疑問なんだけど。でも雑談とか会議とか打ち合わせとかやって仕事した気になってる人は多いと思う。例えばこの本では人の雇い方のパートで、仕切り屋を雇うなみたいなことが書いてある。仕切り屋は会議好きで、自分の仕事を作り出すために会議を開きたがる。まったく何の価値も生み出さないのに、会議に参加することで会社に貢献しているふりをするわけですね。こういうのは本当に最悪。

37シグナルズの発想は、ピュアに作り手だけで会社を動かそうという風に読めました。広告とか営業とか意味ないというか、頼りにしないという考え方。本当に良いものを作って自分たちのファンになってもらえたらサービスを使ってもらえるようになる。特にウェブサービスとかはそうですよね。広告とかPRとかは金ばかりかかって効果がないということに気づかないと。有名な雑誌や新聞に取材してもらうことも否定していますが、折角ユーザーと直接結びつけるのがウェビサービスを提供する企業のメリットなんだから、そこにいちいち旧メディアや広告屋を介在させる必要はないですよね。またセールスマンを省きサポートも極力エンジニアが行うことで顧客の要望が直に作り手のところに伝わる（とはいえ本書では逆に顧客の要望には応えすぎるなとも書かれてはいます。その辺は買って読んでみてください）。

シンプルに、極力自分たちで会社を動かそうとすることで、大企業が抱えるいろんな問題が回避できるというのがこの本のエッセンスでしょう。Railsはお触り程度のことしかやってないですが、CakePHP（RailsのPHP移植版）越しにそのすさまじさというかすごさは実感しています。こういうすごいフレームワークがあるいまは、本書で掲げられていることは単なる理想や夢物語ではなく十分実行可能なものであると感じます。自分たちだけでなにかをやることが十分に可能。

とにかくなにかつくってみよう、と思わせられる本でした。Ruby on Railsの勉強を本格的に始めてみたいと思います。