弊社内の取り組みや制度について御紹介するシリーズ。先のエントリではエンジニアの集中力維持の為に開発室を分離、つまりハード的な分離について書きました。今回はハードではなくソフト的な分離について。
Cc/Bccにエンジニアのメアドが入ったメールは諸悪の根源
あくまで社内のエンジニアに対してという意味ですが、僕は開発プロジェクトにおいてはこれが真理だと思っています。
メールでエンジニアに割り込みが入るのは基本避けた方が良くて、Toはともかく特にCcやBccは最悪です。とりあえず知っといて的なCc/Bcc活用はよくありますが要点がまとまっていないやりとりを、開発行為を寸断してまで共有する価値は全くありません。ネットワーク帯域とストレージの無駄遣いです。
多くの場合10回行き来したメールも大概3行でまとまるもんですから、そのまとめ役とまとめ先とがあれば十分なんですよね。
| まとめ役 | 社長である僕 |
|---|---|
| まとめ先 | WikiやRedmine等の社内システム |
弊社では基本的にこんな組み合わせでやってます。
すべての情報は僕に入り、社内システムに整理して書き込みます。エンジニアはそれを自分の都合の良いタイミングで確認します(その為にRSSを活用。更新された事が分かる)。重要なのは、エンジニアへの情報の「入り」が push ではなく常に pull であるという点。
エンジニアが意図しないタイミングで1本1本の矢が断続的に外から飛んでくるよりも、束ねられた合計10本の矢をパッと見で確認できる状態になってる方が良いんです。断続的な中断が発生しませんから。
世の中の風習なのか(?)、マネジメント役である僕をToとするメールのCc/Bccにエンジニアのメアドを入れて頂く事もあったりするのですが、「この内容はきちんとまとめて責任持って共有しますので、以後ウチのエンジニアにCc/Bccはやめて頂けますか。開発に集中させたいので」とお願いするようにしています。それぐらい徹底してます。
理由は簡単で、エンジニアのゾーンタイム(開発に集中している時間)を中断したくないからです。これは経験者にしか分かりませんが、ゾーンに入ったエンジニアの5分は凄まじい価値を生み出します。これを失うのは関係者全てにとって不幸せなんですよね。だから「とりあえず知っておいてよ」的なCc/Bccは厳禁です。皆の幸せの為に。
これも、この本の影響が強いですね。トム・デマルコの本、エンジニアを manage する人はすべからく読むと良いんじゃないかなと思います。ソフトウェアは人が作ります。ピープルウェアなんです。
って本の話はさておき、エンジニアにCc/Bccが入っているメールをマネジメント役が許容しているとすれば、それは、まとめたり整理したりする責務を放棄してないかと自問しても良いかもなーって最近思います。Cc/Bcc入れてたら楽ですよ、そりゃ。でも、組織における苦楽はゼロサムゲーム。効率を重視するなら根っこで苦を取るに越した事は無いのです。
まぁそんな考え方なもんですから、僕は毎日対外的に大量のメールを書いて、対内的には社内Wikiを更新して、Redmineにひたすらチケットを発行しています。これが会社というチーム全体の生産性を考えた時に最も合理的という経営判断です。
Cc/Bccに限らず、関係者全員が入っているメーリングリスト開設とかも同様に最悪ですね。仮に作られる事があってもエンジニアは入れて貰わないようにして、僕がまず全部受け取って整理したものをエンジニアが社内サーバから pull 出来るようにしています。
ついでながら電話も push という意味では似たようなものかも知れません。割り込まれますのでね。だから電話の支給は有り得ませんし、内線も有り得ません。エンジニアに電話を繋ぐという事も基本的にNGです。まず僕が受け止めます。
こんな感じでマネジメント役だけが矢面に立つ事により、開発室をソフト的にも分離しています…というお話でした。昨日御紹介した、物理的に部屋を分けるというハード的な分離も併せると、ほっとんどエンジニアにノイズが入らない環境が構築でき、文字通り没頭出来るようになります。
そうすると結果的に、間に1時間休憩を挟んだ7時間ぶっ通し開発が一日の限界って事が分かります。それ以上続けても生産効率は上がらないんですよね。だからウチはエンジニアの残業は基本無しです。年間残業時間合計が5時間もない。メールの数も、電話の数も限りなくゼロに近い。ただひたすらに「開発」なのです。
紛れも無くPureな開発のためだけの「開発室」を作り出すこと、それが開発を生業とする企業経営者の役割じゃないかと僕は考えています。
