はじめに
まず Google1 の 20% ルールとは何かを簡単に説明します。
それは、就業時間の少なくとも 20% を、通常従事しているプロジェクトとは別に、すぐには見返りが期待できなくても、将来大きなチャンスになるかもしれないことに使用するというものです。
もっと細かいところはきっとあると思いますが、簡単にいうとそれだけのシンプルなものです。
サポンテは、このルールをすべての企業（あるいは、ほとんど多くの企業）が採用すべきと考えます。それは Google のように「クリエイティブに、イノベーティブになる」ためというより、もっと現実的な動機によるものです。
IT 屋さんの仕事スタイル
IT 屋さんに限らないかもしれませんが、仕事には「繁忙期」「閑散期」があります。サポンテも、いろいろな会社に行っていろいろな経験があります。
「繁忙期」という柔和な表現をしましたが、中には「炎上プロジェクト」とか「
「閑散期」の方も、ヒマすぎてやばいというレベルのものがあります。システムは保守フェーズに入ってしまえば、安定的に稼働している限り、とくにすることがありません。こちらも経験があります。
スキルアップにつながるのは
繁忙期と閑散期、どちらがスキルアップにつながるでしょうか。普通に考えると、仕事量が多いほうがその分野への習熟が進むと考えられがちです。
しかし、スキルアップにつながるのは圧倒的に閑散期です。
スケジュールに余裕があるからこそ、コードをリファクタリングしたり、新しいツールを導入・試用したりできるのです。
求人広告で、仕事量が多くてスキルが身につけられると謳っているものを見かけることがありますが、嘘です。経営者はそう信じたいのかもしれませんが、仕事が多いことは、何も生み出しません。
デスマーチ中に起こること
デスマーチに入ると、いろいろなことができなくなります。
- コードのリファクタリングができなくなり、コピペコードが多くなります
- 網羅性が低くなり、時限爆弾を抱えたまま出荷されます
- 無駄なテストが多くなり、さらに工数が増えます
- 報連相が粗くなり、工程の手戻りが多くなります
- ドキュメントの作成と査読が後回しにされ、工程の手戻りが多くなります
なにもスキルアップには繋がりませんし、会社の将来に禍根すら残しています。
閑散期に起こること
例えば「案件Aと案件Bの間」など、閑散期が突然発生することがあります。その間の工数は、どちらのプロジェクトに計上するべきでしょうか。終わってしまった案件にも、始まっていない案件にも付けることができません。でもどちらかに無理やり付けるしかありません。結果、案件の工数は実態を反映していないものになります。
20% ルールの導入がなくても、実質的に案件に従事してない状態は発生しているのです。
これは現実的な問題です。メンバーのすべてがクリエイティブでイノベーティブでなくてもいいと経営者が考えていたとしても、この閑散期の社内失業のような状態は是正が必要です。
サポンテは、こうした閑散期に、例えば以下のようなことをしていました。
- リファクタリングのシミュレーション
- よりよい設計の模索
- 保守ドキュメントの執筆
- 個人用コードジェネレータの作成
- Git の導入（CVS 利用時代）
- Sphinx の試用・導入
- カイゼンの提案
- 単体テストツールの導入
- 新規フレームワークの導入
どれも、社内業務や次の繁忙期を見据え、備えることを目的とした活動です。
また、いずれも当時の新しい技術であり、当然のこととしてスキルアップに繋がりました。
こうした会社のための業務であるにも拘わらず、社内失業の状態であり、あまり大きな顔でできるものではありませんでした。ここに 20% ルールがあれば、もっと堂々と、もっと広範に対応できたのにと思います。
20% ルールの利用
経営者としては、スローガンと工数のつけ先を用意するだけです。以下のメリットが得られます。
- 案件の谷間の社内失業（状態）がなくなります
- 案件の工数が正確になります
- ボトムアップの改善提案がたくさん出てきます
- 製品の品質が上がります
- 繁忙期の工数が下がります
- 社員のスキルアップに繋がります
- 組織の硬直化を防ぎます
ぜひご検討をお願いいたします。
-
正確には親会社の Alphabet。↩
