非同期のコミュニケーションを工夫する
Web系などのスタートアップなどテックカンパニーではエンジニアの需要が高い。知っているところでは、渋谷界隈や六本木界隈だといくらでもエンジニアを欲しいという。旧来のSIerでもインフラエンジニアは常時案件を持っていて、断っていると聞いてから数年経つがまだ続いているそうだ。
それで、エンジニアが集まらない、複数の案件を手がけるためにリモート環境を生産性向上や働き方云々で導入してエンジニアのリモートワークを結果的に進めることになる。
エンジニアはITリテラシが高い（ことになっている）ので、O365やGsuiteやサードベンダのツールを用意して使うことになる。プロジェクトでは、プロジェクト管理はもちろんシステム開発で必要なツールをWeb上で提供されているものを使う。
例えば金融などの案件では、プロジェクトルームにエンジニアを集めて同じ場所でプロジェクトを運営することで、情報セキュリティはもちろん、プロジェクトの失敗原因にあげられるコミュニケーション対策にもしている（失敗した経験からの学習能力を持っているならば）。
こうした環境でのコミュニケーションは、基本的に同期である。必要なときに必要なエンジニアが求める人にコンタクトして情報を引き出す。と書くと、実態は違うとたくさんのツッコミが入りそうだし、ツッコミたい気持ちもわかる。例え、隣に座っているエンジニアにさえメールで会話しようするエンジニアが少なくない。
ただ、同じ場所に集まるのは、情報の即時性、共有を効率的に、確実に行いたいからだ。
アジャイル宣言でも言っている。
プロセスやツールよりも個人と対話を、
それを補足するアジャイル宣言の背後にある原則でも詳しく伝えようとしている。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
リモートワークは、これと反することをしているのだろうか。
トリンプでは、『頑張るタイム』午前中は仕事の集中タイムにしている（割り込みをしない）運用をしている。
1日２時間ではあるが、同期できない時間帯が存在する。まあ、2時間待てばいいだけの話なのだが。
自分の仕事だけに集中するための貴重な時間です。
従来のプロジェクトでは、情報伝達を人づてやここに書いてあるから読んでおいてという伝搬形態にすると取り違えたり、読まなかったりして、そこからリスクを産み、トラブルに繋がっていたのではないか。また、プロジェクトの情報はリーダなどのロールに集中する構造になるし、そうした役割の人は時間がないから何度も説明する時間ももったいないという（効率性の）理由で集めて一度に説明できるプロジェクトルームをオンプレにしたのではないか（後年、情報セキュリティの観点も後付されるので管理の利便性も追加されたが）。
こうしたコミュニケーションの即時性を求める根本は、仕事の渡し方に原因があるからだと思いは広がる。仕事を渡す、受け取るときに曖昧さが大きから追加で情報を必要とするし、説明したくなる。これが小さくなれば、チャットレベルの文字の会話で済むので、オンプレで場を持つ必要はかなり減る。
そうであるとすると、プロジェクトでのコミュニケーションを期待どおりにするには、タスクの切り出しサイズを如何に小さくするかが鍵となる。それを補助する道具を揃えられれば、リモートワークはうまくいくかもしれない。実際に上手く行っているのはそういうところで運用をやっているからではないか。
