りもじろうさんによる「住みたいところに住める俺」というウェブログを嫁さんから教えてもらいました。

私も「某大手電機メーカー勤務を経て、海外(ニュージーランド)移住後、ソフトウェアエンジニアをやっている」という似たような(?)境遇ですので、色々と共感できる部分も……。

今回は「仕事は7.5時間で終わらせる」より、私の職場との違いなどを簡単に触れてみようかと思います。

• 基本的には定例会議はない。
• ミーティングは30分単位が基本。

うちの会社は 5〜6 人一組のチームがいくつかある構成になっています。

うちのチームは、チームリーダーの方針により、メンバーの進捗報告を兼ねた Weekly Meeting があります。

この Weekly Meeting が大体 30 分。30 分以内に終わることも、ままあります。

チームリーダーが出張した時など、私が進行役をやる時もあるんですが、5 分程度で終わってしまった時も……。

ちなみに、日本で働いていたとき、昼過ぎから 10 時間以上かけた会議に参加したことがあります。10 時間かけて何も決まらなかったという……。その間自分の仕事は何も進まないし、悪夢のような時間でした……。

• 重要かつ急ぎのプロジェクトの場合、毎朝進捗確認はやるが、15分程度。立っておこなう。
• 2-3人での、ちょっとした相談や、決断は担当者のキューブへ押しかけて行う。

プロジェクト進捗確認は、プロジェクトリーダーの裁量に任されています。

うちの会社では、バグトラッキングシステムを利用して、仕事の割当量や進捗状況などが目に見える形で管理されています。

「重要かつ急ぎの用件」に関しては、確かにリーダーが担当者に直接確認行くことが多い感じがします。会議室などは使いません。その場でさっくり確認という感じ。

2, 3 人でのちょっとした相談は、担当者のワークエリアでやるのは一緒です。

• Wikiなどでドキュメント化して情報共有に努める。

情報の共有化に関しては、wiki などの他に、前述のバグトラッキングシステム、svn などのリビジョン管理ツールなどのツールも利用しています。

また、コードレビューも情報の共有化という面(さらにソフトウェアの品質向上)において欠かせない手法です。

コードレビューは、一種のペアプログラミングになると思うのですが、自身が作成したコードを svn などでコミットするとき、必ず他の人にコードレビューしてもらう必要があります。

コードレビューの際には、自身の書いたコードをどのような意図で作成したのか、またどのように動作するのか(すべきなのか)などを説明する必要があります。

• ただしマイルストーンになるドキュメントだけはしっかりつくる。それがないと次に進めない。
• 責任者ははっきりしている。
• なので関係ない人は巻き込まない。（メールも入れない）

ここら辺は同じ印象です。

自分がメールで確認したいことがある時なども「関係者として誰にメールを送るべきか」という点について、気を使っています。

休出とか、考えたこともなさそう。

休出はあります。もっとも頻繁ではなく、年に数回。

プロジェクトのデッドラインが近づいてくると、上司から「出て来れる人いる？」って聞かれることがありましたし、実際に休出したこともあります。

休出した分は必ず代休取れますし、休出した時には、ほぼもれなく昼食がついてきます。その時には上司が注文を聞きに来ます。初めて休出した時はびっくりしました。

うちの会社の場合、効率の良さを追求しているかどうかはちょっと微妙なところもありますが、日本で働いていた時よりも遥かに、個人を尊重した仕事の仕方ができる印象を持っています。