リモートワーク
/remoteに機材情報や運営方法の知見などが集められている
しかし、
の考えている前提とけっこう違う部分がある
やる気がある時のエネルギーを効率的にぶつけられる最適な環境だと思う
個人的な体質に合致している
時間を問わず、例え夜中で眠くても突然何かを閃いてしまう事があり、すると一切の眠気がなくなり寝れなくなる
この場合、無理して寝ようとするよりも好きなだけ書いたり作ったりする方が効率が良い
かといって毎日7,8時間は寝ないとつらい
タスクを効率的に処理していくと高速にクソアプリを実装してしまうのような、予防線を置いておくと健康を守れる
やりたい時に料理したり散歩したり実験したり、好きな事ができる必要がある
遠隔地とも、対面した人間と行うコミュニケーションと同等・同質・同系統のコミュニケーションをできるようにしよう
その為に「まるで目の前にいるかのように」やりとりできる仕組みを作ろう
という方向性は、ありきたりで全く面白くない
（やり方に面白さを求める必要があるのか？）
やり方を変えればできる物も変わる場合が多い
問い
情報伝達ではなく解釈
そもそもお前が自信を持っている、「表情・声色・身振りから、言外の情報を伝達しあえている」という思い込みは、はたして正しいのか？
その謎の自信は、1対1ならともかく、5人、10人と人が増えた時も保証される物か？
情報が伝達されているのではなく、実は身勝手に観察して特定のパターンに当てはめて解釈しているだけではないのか？
人生経験が違う人間同士は、共通の解釈を共有できない
開発時に言語化しろ
表情・声色・身振りに頼り、イメージの言語化を怠っているような人間が、プロダクトの設計・実装に明確な意思を込め、ユーザーに意図を伝え説得する事ができるのか？
非効率
音声会話による説明と理解というのは
本来複雑な関係性を持った物事のつらなりを一本の直線に接続し直してから音声化し、それを聞き手がまた元の複雑な関係性に脳内で復元するという工程の事だが
でかいデータをserialize・deserializeしている
どう考えても非効率ではないか？
「◯◯をやっておいて」程度の指示なら、音声会話は手軽である
しかし、システムの複雑な全体設計と細部の実装を交互に行き来する現代のソフトウェア開発においては、手軽さよりもserialize・deserialize時のエラー率の高さの方が問題になる
手戻りを恐れすぎ
調整やミーティングに時間かかりすぎると、集中する時間が作れない
なぜそんなに作業の失敗・手戻りを恐れるのか？
ミス無く1回の作業で完成させる事を狙うよりも、ミーティング減らして時間作れば3回やれるし、2回失敗できて練習になるのでお得
もちろん各自の得意分野で分担しないと最高品質にはならない
しかし、最初から分担するよりも、できないなりに稚拙な部品で作って修正や意見を求める方が相手も楽
部品を後から良い奴に差し替えれるようにイイ設計になったりする
2回多く失敗しているので学習速度も速い
ドッグフーディングしなくなる
インターネット上で使うコラボレーションツール・コミュニケーションツールを作る場合
音声会話が手軽にできてしまう開発環境では、自分が作っているプロダクトを自分で使わなくなってしまう
逆に、音声会話が手軽にできない不都合な状態に自ら身を置く事によって、音声会話に替わる新たな機能を発明できるのではないか？
というような問題意識を、株式会社Helpfeelに入る前から立てていた
従って、自分がScrapboxに対して
日々使い、必要な機能の構成を考え、実装・運用し、ユーザーに説明する
という役割を担う場合に
リモートワークという就業形態を取るのは必然だった