アプリケーションの実行環境にポータビリティを与える・・・というのが先のエントリで書いたこと。いうカンファレンス発表でも話した。その典型的なユースケースだと言える。いう特定ベンダのインフラ環境に縛られない、同様のユースケースが実現されていくのは間違いない。新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。アジャイル開発という文脈でいったときに「どうするべ?」ということが幾つかあった。その際たるものが「全員同席」。(・・・そもそも必ずやらなきゃいけないことなんてないとは思うんだけど)、ではないのだけど、リモートワークだとどうしてもその辺りのコミュニケーションが希薄になりがちで、チームビルディングという観点では課題だなと思っていた。以下の様なやりとりが行われたりする。経験がある人はわかると思うが、これ、実際はなかなかにイライラする。誰が悪いわけでもないのでそのイライラをぶつける先もない。これがリモートワークでなければ、その場でいるかどうか確認してその場でちゃちゃっと話合って終われるんだけど、リモートだとなかなかそうもいかない。分がめんどくさいので、チャット上でやりとりして実際には10分話せば終わることを30分も1時間もかけてやりとりしたりする、なんてことになりがちである。作ってる人たちがどうやってリモートワークしてるかという話。面白い働き方をしているらしい。いうツールが、まさに先の問題解決をしてくれた。立ち上げてるチームメンバーが一覧になる。常にストリームをしてるわけじゃなくて、定期的に画像のスナップショットをサーバーに送ってる。そのスナップショットがときどき更新されて、この一覧がでる。この一覧にいるメンバーと口頭で何か話したいことがあると思ったらどうするか。相手の写真をタップするだけ。すると、その瞬間からセッションが始まる。セッションをはじめるよという呼びかけみたいなのは一切なくって、タップしたら音がなって、いきなり相手と会話が始められる状態になる。やりとりとかそういうのも一切必要ない。会話の途中で、その会話にもう一人追加したいとおもったらその人もタップすれば3人での会話になる。隣にいる同僚にちょっとちょっと、と話しかけるような感じに近い。使い始めたときは、常時カメラで写されてるということでプライバシーのこととか、割り込みしやすいというのでリモートワークの利点がとかいろいろ心配していたけどその辺は実際やってみると普段はほとんど気にならない。そのうち放送事故が起こるかも知れないが、まあそれはそうなったらそのときだ。解決してくれるところが非常によい。周りに誰かいる、というような感覚でリモートワークに望めるので適度な緊張感が得られる。怠惰な自分には、それがとてもありがたい。よって結構解消されつつある。駆使してコミュニケーションを厚めにやってみようかなんて話をしている。ちなみにアジャイル開発、というかスクラムでいくと他のプラクティスをどう実践してるかというと、以下の感じである。集まるようにしている。残念ながら大人数でのリモートチャットをサポートしてないのと、議事録用のスクリーンシェアができないため。スプリント計画は、実は厳密にはあまりやってない。やってるのはタイムボックスを決めて、2週間毎に前後のプロジェクト進行をスプリント単位で確認するくらい。系サービスだとこの辺はゆるくやってるくらいが丁度いいと思ってる。やりすぎて疲れてしまうことより、ゆるくても長く続けて常にタイムボックスを意識して進められるくらいが良いかなと思う。日時を決めてしっかりやっている。集まってミーティングをする。そのための良い機会になっている。安定した開発ができるようになってきたと思う。あげて、やらないことはやらない、緩く崩すところは崩すということをしながら今のスタイルに落ち着いている。ところで昨晩から「ピープルウェア」という本を読んでいる。ソフトウェア開発の名著なんだけど、今ままで読んだことがなくて、たまたま知り合いのブログで感想があがってたのをきっかけに読み始めた。これの第一章から早速なかなか面白いことが書いてある。実際のところ、ソフトウェア開発上の問題の多くは、技術的というよりは社会学的なものであるさもありなん。技術の問題というのは、案外正解を導きやすい。コンピュータは、こうしたらこうなるというのにちゃんと答えを出してくれるし、どちらのやり方が良いかというのに結論を出しやすい。人間の問題は、そのやり方が本当に正しいのかどうかが見極めにくい。ものによっては半年とか一年後くらいになってようやく結果がわかることなんていうのも多い。時間が経過しすぎてどのアクションがその結果に繋がったのかという因果関係がはっきりしないことも多い。技術的な問題にばかりフォーカスしがち、というようなことがピープルウェアには書いてあって、そうだよねえと思いながら読んでいる。リモートでどうやるかとか、リモートでも気軽に雑談できるような環境を整えることにリソースを割き続けるとか、そういうことは社会学的な問題だと思っている。使ったデプロイフローなんかは社会学的側面もありつつ基本は技術的な問題である。人の問題が解決されてチームが良い状態になると、今度は技術の問題がボトルネックになる。時間がかかりすぎる、とか。テストを書いて全部自動化することによってそのボトルネックを解消した、なんて典型例があった。逆に技術的な問題ばかりを解決しても、コミュニケーションがボトルネックになって、だれそれの了解が得られないからリリースできないとかそういうことが起こる。人と技術の問題を両面からバランスよく解きほぐしていくのが、昨今のソフトウェア開発におけるチームビルディングのコツなんではないか、と思っている。追記ちなみにリモートワークと書くと時折誤解を招くので、捕捉しておく。リモートワークしましょうということではなくて写真にも映ってる通りオフィスはある。オフィスに行くか行かないかは自分で決めるようになっている。対面でしたほうがよいミーティングがある日はオフィスにいくしそうでないなら自宅、あるいはカフェかどこかでやる。いい大人なんで、その辺は自分たちで判断しましょうね、お互い信頼してれば大丈夫だよね、ってな感じの仕組みになっている。対面でやった方が早いと思うことはたくさんあるけど、本当にそれは対面じゃないとできないのかというところをまずは疑ってみないことには、新しい働き方を追求するということはできない。結果的にそれで会議を減らす、非同期に作業することができれば全体の効率が上がるわけで、そこで思考停止しない・・・ということが大切だと思う。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。