portal shit!

昨年末に mixi2 出てちょっと話題になった。自分もアカウント作って使ってみた。最初はよく考えられてるなぁと感心したけど、なんか使いづらい。

自分として最も使いづらいと感じるのは絵文字の種類の少なさで、数が少なくて気持ちを表現しづらいと思っている。あらためて見てみると mixi2 の絵文字はのほほん系の絵文字しかなく、喜怒哀楽を表現しきれない。 🤔 のような、わずかでもネガティブなニュアンスのある絵文字は使えなくなっている。

リプライ欄のプレースホルダーも「やさしいことばで返信しよう」となっていて、返信内容を穏やかな方向に限定しようという意図が読み取れる。

mixi2 のメッセージとして、のほほんとしたコミュニケーションだけやって欲しいということなのだろう。

Threads が出たときに記事を書こうとしていろいろ調べていたが、改めて引っ張り出してきて見てみると、 Threads / Instagram 勢もこういうコミュニケーションをして欲しいという意図を持っている。 Threads がリリースされたばかりの頃、 Instagram の責任者の Adam Mosseri は Instagram や Threads は政治や重苦しいニュースではなく、頭を空っぽにして楽しめるお気楽コンテンツだけ見られるお花畑のような場所にしたいと言っていた。

Post by @mosseri

View on Threads

Twitter が居心地がよかったのは人が多かった（自分が情報を知りたいと思う相手が多く Twitter を使っていた）というネットワーク効果的な側面もあるが、「こういうコミュニケーションをしろ」という制約が弱かったからだと思う。 Twitter がコミュニケーションの方向性を指示しようという試みは、せいぜい入力欄のプレースホルダーを "What are you doing?" から "What's happening?" に変えたこと（「あなたはいま何してる？」から「あなたのまわりで何が起こってる？」に変更）くらいだ。

ハイパー起業ラジオに MIXI の元社長の朝倉祐介さんが出ていて、いかに SNS として発展させるかばかりを考えていた当時のミクシィを多角化して立て直したかを話していた。

mixi2 の動きは朝倉さんがやったことへの反動のようにも思える。めっちゃ細かいところまでこだわった俺たちが考える最強の SNS を作ろうとしているのだろう。

果たしてコミュニケーションの方向性を限定するやり方はうまくいくのだろうか。

匿名掲示板のような無法地帯がよいとは思わないが、自分は自由にコミュニケーションできる場所の方が好きだ。

新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。

1. システム構成図を描く

どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。

2. 誰が何をやるかを明確に

タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。

3. リリース日を決める

リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース日を動かして調整する。

4. 確認環境・デモ環境を作る

ローカルではなく、本番と似た環境で動作確認できる環境をまず作る。ローカルで動いたけど本番で動かないをなくす。本番サイトを非公開にできるならリリース前からガンガンデプロイしてもいい。CSSが当たってなかったり、APIがモックでもいい。動くものを関係者間で共有し、早い段階でイメージのズレを補正することが超重要。

CI/CD の仕組みまで初期に整えておけるとなおいい。

5. リスクの高いところから開発する

システムの処理の中で重要かつ難易度が高い、もしくは実現できるかわからない（不確実性が高い）部分から開発する。簡単なところから先にやって不確実性（リスク）の解消を先送りにするのは超危険。

6. APIのJSONのフォーマットを先に決める

こうしておくことでバックエンドとフロントエンドがパラレルで開発できるようになる。誰かの作業が進まないと他の人の作業が進まないというような依存関係を作らない。

7. コードはこまめにリポジトリにプッシュ

他の人が作業状況をわかるようにする。小さくプルリクエストを作ってマージしていくとかは今更言わなくても常識ですよね？

8. 朝会か夕会をやる

超ラフにコミュニケーションしてお互いの進捗を共有する。可能ならオフラインで話す。一緒に寿司を食べるのも効果的。

---

↑は作るものが決まってからの話なので、作るものが合ってるか（正しいか）はまた別の話（プロダクトマネジメント）。

仕事でなんか問題があったときにとりあえずミーティングすると大抵うまくいかない。事前に何が問題なのかを見極め、正しくアジェンダを設定しないとただ集まっただけになり、生産的な議論ができない。

一方で問題があったときにとりあえずミーティング招集してうまく行く人もいる。瞬発的に何が問題なのかを察知しアジェンダ設定できるのだろう。あとは断言力ともいうべきか。これが問題なんじゃおりゃ、と言い切って断定することでうまくまとまったような印象を与えられる側面もあると思う。これは人間性に依存する部分が多いので誰しもが使えるテクニックではない。

自分は基本的に自信がないので常におどおどしていてなかなか「おりゃ」と物事を断言できない。なのでノープランでミーティング召集するとグダグダになって参加者から不満が噴出してしまう。

ミーティングを段取るスキル、学校では教えてもらえないけど極めて重要なスキルだと思う。コミュニケーション能力が低い人でもうまくミーティングを段取りできるような、実践的なミーティングテクニックを学んでみたい。

自分はわりと不細工で、不細工であるせいで子どもの頃はバカにされたり思春期の頃は気後れしたりしていた。大人になってくるにつれて自分だけでなく周囲も、外見よりも内面で人を判断するようになってきて不細工であることをそんなには気にしなくなった。しかし最近、やっぱり不細工であることは不利だなと思うようになった。

不細工は第一印象が悪い。初対面の人からはどうしても見た目で判断されてしまう。長い時間をかけて人間関係を作っていく相手だと最終的には不細工であったとしても正しく人間性を評価してもらえるが、最初は低評価からスタートするので起ち上がりがすごく大変だ。外見が良かったらしないですむ苦労をしないといけない。

イケメンとの比較でいうと、イケメンと不細工が同じことを言っていたとして、イケメンの方が賞賛されて不細工は賞賛されない、という問題もある。不細工に対しては精々「ふーん、ま、そんな風にも言えるよね」程度の評価にしかならない。

そういう経験が積み重なって行くと、イケメンは人前でも堂々と話ができるのに不細工はもじもじして堂々と話ができないし、引っ込み思案になってしまう。また周りの人も、「こいつは不細工だしおどおどしてるから人前に出さない方がいい」と考えるようになり、発言の機会を与えられないようになる。そしてどんどん意見を出しづらくなる。意見を出さないからフィードバックを得ることができず、成長の機会を失う。負の連鎖に陥る。不細工だけど人前に立ったり堂々と意見を述べられる人は心が強いかかなり有能な人なのだと思う。

もしみんながアバターで会話するような世の中になれば不細工でも生きやすくなるのかもしれない。その意味でインターネットは顔を見せることなく自由自在に放言できるので不細工にとっては理想郷だと言える。自分がインターネット大好きなのは、不細工でも外見ではなく中身で評価されるからだと思う。

リモートワーク別に寂しくないし楽勝、みたいなコメント多いけど違和感あった。リモート楽勝という人はフリーランスとか受託の会社の人なのではないかと思う。自分のブックマークコメントは以下。

激しく同意。雑談したい、家族から家事を頼まれる、オフィスにいる連中から事業理解が低いと責められる、毎日服を着替える能力や通勤電車に乗る能力が失われる、などなど — http://b.hatena.ne.jp/morygonzalez/20180309#bookmark-359971190

「こいつはわかってない」問題

自分の場合は事業会社に所属した上でのリモートワークだった。事業会社（大抵のスタートアップもこれに含まれるはず）の場合はソフトウェアエンジニアにも事業やプロダクトへの理解が求められるので、リモートだとなかなか厳しい部分がある。事業理解は日々の MTG の他、オフィスで何気なく交わす雑談や昼飯の時なんかに醸成されるものだと思うので、リモートだと MTG での情報伝達密度が下がるし雑談や昼飯に至ってはそもそも不可能なので自分自身の事業理解も深まらない。仮にこちらに事業に対する理解があったとしても、それをオフィスにいる連中に伝えることが難しいので結局「こいつはわかってない」という烙印を押されることになる。リモートワークやってて同僚のエンジニアの皆さんとは友好関係を築けたと思うけど、 PM や上司とはなかなか良い関係になれなかった。

家庭内で仕事が軽んじられる

家族がいる人の場合は家族が「こいつ家にいてあんまり忙しくなさそうだから家事を頼もう」ということになりがち。自分の場合は子どもの幼稚園の送り迎え（バス乗り場まで）、幼稚園から帰ってきたあとの子守、洗濯物干し・取り込み、などを頼まれることが多かった。配偶者も仕事をしていて家事を分担する、ということなら当然やるけど、我が家の場合は嫁さんが習い事やヨガで忙しいので家事をやらなければならない、という感じで、自分の仕事は嫁さんの習い事よりも優先度が低いものなのだろうかと悶々とした。

社会適応能力の低下

毎日身支度をする能力、出かけていく能力も確実にむしばまれていく。転職してリモートワークからオフィスワークに切り替えて、朝の混んでる時間の電車に乗る通勤生活を再開してからの数ヶ月間は肉体的にも精神的にも非常につらかった。また家で仕事してると出歩かないので当然に運動不足になる。自分で意識してジョギングしたり体を動かしたりしないと確実に健康を損なう。

自分がリモートワークに対して否定的な見解を持っているのは以上のような背景があるのであった。

良い面もある

もちろんリモートワークには良い面もある。

ワークライフバランス

子育てのための一時期や家族の看病が必要な時期には非常にありがたい制度だと思う。ワークライフバランスは非常に良好になる。

集中維持

コード書きに集中したいときにもリモートワークは便利だった。リリース前など、移動の時間も惜しんでコードを書きたいときには朝 10:00 から夜の 24:00 頃まで風呂とトイレと飯の時間以外はずっと仕事してたこともあった。それでも 10 時間は時間が空くので十分睡眠をとることはできる。これも前にブログで書いたような気がするが、いつでもオフィスに仕事しに行ける環境で、自分の裁量で週に数日リモートで仕事をするのが一番満足度の高い働き方になると思う。

地方都市に暮らしながらデラウェア法人で働ける

あとそもそも福岡では前職のような数十億円規模の資金を調達してがつんと成長しようとしているスタートアップの仕事にありつくことなんかは不可能なので、田舎に住んでいても都会のイケてる手法で仕事できてたのはリモートワークならではだったと言える（これも元記事に書いてある）。いまの職場でやってることは前職で身につけた¹もの（スタートアップで働くエンジニアのディシプリン的なもの、あるいは技術顧問おじさんの素養）を土台にしているので、これは非常にありがたかった。

まとめ

ひとくちにリモートワークといってもいろいろな形態、状況があるので、↑の記事のブコメのように「リモートとか楽勝じゃね？」というコメントを読んでうかつにリモートワークを始めようとしている人がいたとしたらちょっと踏みとどまってもらいたいし、自分に向いているか、勤務先のビジネス領域・ビジネスモデルなども加味した上で決めてもらいたいと思う。

あとリモートワークだとコードレビューが甘くなりがちではないか、という問題もあるけどそれはまた別の話かもしれない。

リモートワークしてた頃、コードレビューの指摘・修正往復を沢山したくなくて（修正してもらった後にさらに注文つけるのきつい）、本当は修正して欲しいけどLGTMすることあったけど、オフィスで仕事してると追加の指摘をしたあとに口頭で補足説明できるので割と納得できるまでレビューできる気がする。

— morygonzalez (@morygonzalez) March 8, 2018

References

• リモートワークのストレス | POSTD 翻訳記事
• The Stress of Remote Working – Hacker Noon 元記事
• Kaizen Platform という会社について - portal shit!
• リモートワーク - portal shit!