こうしたGoogleのサービスの開発にあたっては、305人の少人数でグループを作って取り組んでいるという。また、開発者には「勤務時間の20％は、自分が興味のあるアイディアに取り組んでよい」という「20％ルール」が与えられ、このルールによってGmailやorkut、Google Newsなどが生まれたという。20％ルールはすべての開発者に対して適用され、新たなサービスの開発や検索効率の改善などの大きな原動力になっているという。
爆発的に増える情報を整理し、どこからでも検索可能に0Google・マグラス氏

IT界隈では結構有名なこのルール。
大企業じゃ採用しづらいんだろうなぁ。

いまだにソフトウェア開発に携わる大部分の企業では人月の神話が成り立ってる。
人月の神話とはFrederick PhillipsとJr. Brooksの共著人月の神話で有名になった言葉で、

コストは実際に人数と月数の積に比例する。が、進捗はそうではない。したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。 人月とは、人と月とが互いに交換できるという意味だからである。

というソフトウェア開発の評価基準として人月を使用することの危険性を継承する言葉でもある。
この本自体未だに読み伝えられている古典書で、原書の発行は何と1975年だ。
20年もの間この本が名著として読み続けられている事自体が、「人月」に対する信奉の根強さを物語っていると言える。
ブルックスも言う様にコストは人数と月数の比なので、企業としてのコストパフォーマンスを最大化させようとした場合 各人の勤務時間をフルに使い切るような仕事をマウントすることが最適解となるように思える。
この考え方はある意味正解だが、この解が最適解となるためには以下の条件が必須となる。

・生産に必要となるテクノロジが十分枯れて(成熟して)いて生産者が十分に成熟している。
・満足できる程度の生産効率を既に得ている。
・生産効率において競合他社と著しい差が無い。

つまり、工場での大量生産のような完成されたプロセスで管理された流れによって製品を生み出すような職場において最適解となるような計算式なのだ。
では転じてソフトウェア開発での状況を見てみると、技術が日進月歩で進化し昨日までの最適解が今日の最適解では無いというような業界であり、人月の神話が成立する第一条件すら満たすことが出来ない。
また、その進歩によって効率は劇的に進化するため、最低限世間の進歩と同程度に改善を続けなければすぐに競争力を失ってしまう。
つまり人月を万能の指標として使用するには極めて不向きな業界なのだ。
しかし、現実問題として人月を最適化の指標として使いながらも技術の進歩から遅れ続けている企業ばかりかと言えばそうではない。
では、どのように追随しているのかといえば極めて少数の個人による勤務時間外の活動に支えられているように見える。(*1)
こういった状況は次のような例において非常にナイーブな面を持つ

・勤務時間外なのでその活動範囲は個人的嗜好に強く影響を受けるためバランスの悪い技術革新になりがち。
・企業全体の将来に渡るパフォーマンスを特定少数個人に強く依存するためリスクヘッジの観点からすれば非常に脆弱
・企業として個人の評価がしづらく、適切な待遇がなされづらい為に技術(力)流出が起こりやすく、更にその損失は失われてしばらくしなければ認識されない。(*2)

また、そういった職場に在籍する技術者は以下の例において極めてリスキーだと思う。

・普遍的な水準に対する評価基準を自分で持てないため偏った知識になりがちで、転職に対して重大なリスクを抱える。
・どの技術が普遍的な技術か、職場特化の技術かの判断がつかず外部とのコミュニケーションにおいて障害をもたらしやすい。(*3)
・そもそも技術の進歩を実感できていない化石のようなエンジニアになりがち。(*4)

これらの問題を包括的に、かつ少ないリスクで実現し得るアイディアこそが冒頭に挙げたGoogleルールだと思う。
つまり勤務時間の２割(に限らず一定の割合)を本来の業務以外の事に自由に割り振らせることで、本来業務自身の効率化や新しい製品のブレイクスルー、新たな技術的進歩の導入などを狙い将来的なリスクを軽減させる方法だ。
乱暴な言い方をすれば、２割の時間で効率の改善をして残りの8割で10割の仕事ができればOKだろうと。
かくいう俺はもう5年ぐらい前からこの考え方で仕事をしてる。
今までこのやり方で文句を言われた事も無い(*5)し、却って効率が悪化している事も無い。
ただ、一向にこう言った方法論が採用される兆しは無い。
そう考えるとサクっと採用したGoogleという会社の凄さが改めて実感できる。