guntamania

20% ルール

[2017-12-08 Fri]

「20%ルールをうちでもできないかなあ」

と隣の先輩が言った。

20%ルールとは、いわずもがな Googleをはじめとする先進企業で取り入れられているルールで、 仕事とは別のプロジェクトを業務時間中に当てられる制度だ。 現在、Googleでの適用は終わったようだが、 イノベーションを促進した制度としてよく挙げられる。

従業員側からすると相当魅力的な制度のように思える。 何も制度がない中で勝手にプロジェクトと関係ない事をすることは、難しい。 一方でソフトウェア開発には、新しいフレームワークの実験や インフラの整備など、プロジェクトに直接関係のない業務も必要で、 それを業務時間中に行えるということはかなり興味をそそられる。

実はうちの会社でも導入を試したことはある。

昔、20%ルールを取り入れたチームがあった。マネジメント側にとっても、 20%ルールを取り入れることは結構容易い。 直属の上司が単にそれを容認すればいいだけの事だ。 しかし、うまくいかなった。 理由は、そのルールを取りいれても 仕事をしてしまう ためだ。

不思議なことに20%ルールがあっても、 そもそもその制度を使う社員がいなかったのだ。 その理由をなんとなくサボっているように見えてしまうためなのかと マネジメント側は考えた。 そこで、時間を固定し、ある曜日のある時間帯は別プロジェクトを行なうこと、 と制度を改善したが、 別の部署からの問い合わせ対応などで潰れてしまっていたり、 優先度の高いタスクを消化してしまい、結局長くは続かなかった。

そもそも我々の順番が逆であったのだ。 この制度の有無にかかわらず、 優秀なエンジニアは勝手に何かを作ってしまうものなのだ。

そういった自発的なエンジニアをかかえる会社は、 社員が勤務時間外に有用なプロジェクトを持った場合の リスクを考える必要がある。 エンジニアがサブプロジェクトに没頭した場合、 転職・独立のリスクが高まるし、知的財産もその会社は主張しにくい。 そうなってしまう前に 勤務時間中にサブプロジェクトに従事させる方が よほどその会社にベネフィットがある。 リスクを逆手にとり、制度化してしまうのが、この20%ルールなのだ。

実態がない中、もなくルールだけ取り入れても仕方がない。

旧態然とした我々には勝手に自分のアプリを書くような 不真面目な社員はおらず、 そのため、20%の枠組みを入れても不真面目にはなれなかったのだ。 仮にこの制度を取り入れたとしても大きくなにかがかわることはないだろう。

そんなことを考えながら、

「そんなのがあったら、いいですね」

と答えたのだった。