ノマドワーカーになりたいので、できるかどうか考えてみた

このエントリーをはてなブックマークに追加
先日、『国境なきプログラマ』を目指す~ノマドワークの究極のかたち というブログを読み、コレが私の理想の働き方だ!と憧れている megumi です。

そこで、これは弊社で可能なのか?と考えてみることにしました。

制度が存在しないので、現実としてはできません。
それは置いといて、技術的に可能なのか、もし制度があったら可能なのか、というところだけを考えてみます。

海外から仕事をした経験については、以前ソンさんが韓国から仕事をした経験を書いてくれています。(海外からのリモート作業) 韓国は時差が少ないので、チャット等でリアルタイムに連絡を取りながら進めることが可能です。

前職ではアメリカやヨーロッパと一緒に仕事をしていましたが、さすがに時差が大きいので、チャット等の使用頻度は高くありませんでした。
その頃の経験と、現在の仕事スタイルから、必要なことを考えてみます。

開発エンジニアが1日にやることは、だいたい毎日こんな感じです。(時系列)
  1. ReviewBoard を使ったコードレビューをする
  2. 自分が出したレビューが ReviewBoard で Ship it になっていたら、CVSにコミットする
    • Bugzilla にコミット内容を記載し、ステータスを変更する
  3. Google docs の業務報告シートに昨日の仕事内容を記録する
  4. Backlog で今日のタスクを確認する
  5. スクラムチームのデイリーミーティング
  6. Bugzilla を確認し、要対応なものに着手する
    1. バグが再現しないときや仕様が曖昧な時はQAに相談する
    2. 修正と動作確認をし、Build テストを流す
    3. ReviewBoard に投稿する
  7. 今月の開発テーマに着手する
    1. 現状の機能がどう作られているか確認し、開発方針を立てる
    2. 仕様が曖昧な時はQAに相談する
    3. 口頭かメールかReviewBoardで設計レビューを出す
    4. 修正と動作確認をし、Build テストを流す
    5. ReviewBoard に投稿する
    6. Google docs のリリースノートに変更内容を書く
  8. ReviewBoard を使ったコードレビューをする
  9. 作業の進捗をBacklogに記録する
  10. (帰宅)
※ ReviewBoard についてはこちら ⇒ コードレビュー
※ Bugzilla についてはこちら ⇒ Bugzilla-jp - もじら組 (本家)
※ Backlog についてはこちら ⇒ Backlog ユーザーの集い in Fukuoka に行ってきました!
※ スクラムについてはこちら ⇒ スクラム道バーストにいってきました, マンネリ化したスクラムをアナログ回帰でテコ入れするの巻

この他に時々ミーティングが入ったりすることがあります。また、月末にスプリントレビュー(ビジネスオーナ-向けのレビュー)、月初に計画ミーティングなどがあります。

これらは、対面で行うもの、方法は問わないもの、ツールを使用するものに大別できます。

対面
  • スクラムチームのデイリーミーティング
  • その他ミーティング
方法は問わない
  • バグが再現しないときや仕様が曖昧な時はQAに相談する
  • 現状の機能がどう作られているか確認し、開発方針を立てる
ツール
  • ReviewBoard でレビューする/される
  • CVSにコミットする
  • Bugzilla でバグの管理をする
  • Google docs で業務報告シートを書く
  • Google docs でリリースノートを書く
  • Backlog でタスクの管理をする
  • Build テスト

対面で行っているものについては、Skypeやメッセンジャーなど、リアルタイムで連絡を取ることができる方法が必要です。
このときに最重要なことは、ログインしておくこと でしょうか。そのためには、ミーティングの開始時刻を確定しておくこと時間を守ること も大事なことです。
ミーティングの時間と移動時間が重ならないようにする必要があるからです。また、時差が大きいときは、いつ始まるかもわからないミーティングのために待っていられないものです。
全員揃ったら開始、前のミーティングが終わり次第開始といった曖昧なミーティングが時々あるので、そこは改善すべきポイントだと思います。

次に、方法が決まっていないものについて。
これは対面の場合と同様に行うか、もしくはメールを使うことが多いのではないかと思います。
メールのように非同期でコミュニケーションを取る場合には、お互いがメールをチェックする習慣があることわかりやすく説明する言語能力 が必要かと思います。
メールを見てなかった・・・では仕事が進みませんし、読んだけど意味不明だったというのも仕事は進みません。文章が長すぎて読むのがイヤになった、というのも困ります。

そして最後に、ツールを利用するものについて。
上に列挙したものを見るとツールを使うものが大半です。そのため、いつでもどこでも仕事ができそうじゃないか!と思うかもしれません。確かに、ちゃんと有効活用できていれば、かなりの部分をツールに頼ることができそうだという実感はあります。
主にコミュニケーション手段ともなる ReviewBoard、Bugzilla, Backlog (レビュー、バグ管理、タスク管理) をうまく活用できているかどうかは重要です。これらは何をどこまで作業しているかを見えるようにするという重要な役割があります。
きっと見えない相手と仕事をすれば、相手がサボっているのではないか?と不安になることもあるのではないでしょうか。それを解消する役目がこれらのツールを活用することかなと思います。

いずれの手段を用いるにしても、それがインターネット経由で共有できる情報なのかどうか、というのが大事だと思うのです。

こうして書いてみて、ツールなど手段は存在するけど、使い方はまだまだ足りないな、という感触を受けました。
時差がないほうが仕事しやすいというのは、ツール等を用いた非同期コミュニケーションに慣れていないからだと思います。うまく時差を活用すれば、開発とQAをうまく組み合わせて2倍速くらいにできる気がするのです。

自分が海外で働くわけではなくても、海外の人と仕事をすることになるかもしれません。
そんな遠隔地でなくても、もし日本で開発拠点が2つになった時点で、姿が見えない相手と仕事をすることになるわけです。他人事だと思わずに、一度思いを廻らせてみると、見えてなかったことに気付くかもしれません。

次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...