Googleの「20％ルール」の歴史に関する専門家の意見

IT分野では、労働生産性は開発者に直接依存します。 したがって、企業は、知的秩序の騎士の仕事の動機付け、報酬、および他の最適化の非常に逆説的な方法を探し、時には見つけます。



しかし、彼ら全員が彼らを見つけるのではなく、最も熱心な先駆者だけを見つけます。 その後、一般の人々は同じGoogleで何が起こるかを熱心に見ています。 誰かが会社で「20％ルール」のようなプログラムを使用したいと考えており、誰かが懐疑的です。 通常、全会一致の意見は存在しません。



このトピックについてコメントするよう専門家に依頼しました。



このルールはどれくらい効果的ですか？ そのようなイノベーションが最も効果を発揮するのはどの企業ですか？ ロシアの大企業はそのような実験の準備ができていますか？ どのロシアのIT企業でこれが既に実装されていますか？



「Googleは数千ものミニプロジェクトを立ち上げましたが、それ自体が収益性を証明するために残されています。 立ち上げられた何百ものプロジェクトのうち、真に価値のあるものはごくわずかであり、2-3は新しいトレンドを設定します。 これは、リソースの2種類の抽出（集約的（深さ）と広範囲（幅））に似ています。 Googleは広範に掘り下げていますが、いや、いや、最高品質のダイヤモンドをいくつか見つけました。 Googleでインターンシップを行ったGeektimesユーザーは2014年に次のように書きました。



20％ルールは、Googleでのイノベーションに対する効果的なアプローチとして引用されていました。 Googleの各従業員には、作業時間の20％、つまり週に1日をサードパーティのプロジェクトに充てる権利がありました。 20％ルールのおかげで、GmailやAdSense、Google Cardboardなどのプロジェクトだけでなく、その多くがオープンソースになった数百の小さなプロジェクトが一度に生まれました。







「Googleには20％のプロジェクトから生まれた小さなチームがたくさんあります。 社内に非常に多くの小規模な新興企業が存在するため、誰もが階層内の論理的な場所を見つけることは困難です。 さらに、一部のチームの本質と目的は時間とともに変化します。 したがって、少し混乱します」とユーザーは付け加えます。



マキシムナルスキー 、 パイラス CEO

Googleの20％のルールは、サードパーティのプロジェクトに関するものではありません。作業の結果は企業のものであるためです。



当社にはもう1つのルールがあります。開発者自身がタスクを100％計画します。 繰り返し開発しています。 私たちは月曜日に会合を開き、各開発者はその週の計画を立てなければなりません。 誰もが会社のグローバルプランを知っています。リリースの時期とその内容。 しかし、マネージャーは開発者に何をすべきかを伝えるべきではありませんが、彼ら自身が来て「私はこれをやる」と言うべきです。 会議では、計画と優先順位を調整および調整します。



なぜこれがあり、なぜGoogleは「20％ルール」を作成したのですか？ その理由は、企業が最高の人材を求めて競争しているからです。 本当に強力な開発者は、業界平均よりも桁違いに優れています。 違いは実際には桁違いです-x10。 1人の開発者が実行できることだけがあり、10人の開発者は実行できません。 そのような才能があり、雇用主は彼らのために戦っています。



Googleは世界中から最高の開発者を集めています。 創造的な人々は、彼らが興味を持たないことを強制することはできません。 彼らはある程度の自由を与えられる必要があります。



ルール自体については、さまざまな意見があります。 Googleでこのルールを使用しているのは従業員の10％のみと考えられています。 Marissa MeyerがYahoo!に来たとき、「Yahooでこのルールを20％にするのはいつですか？」 彼女は答えました。「Googleについてのひどい秘密をお話しします。 このルールは20％ではありません。 このルールは120％です。」



個人的には、20％の時間を費やす価値のあることは1年ではできないと確信しています。 新しい製品を作成するとき、最高の200％を提供し、このアイデアを実践し、朝から晩までそれを実行します。 したがって、これらの20％の時間では、いくつかのアイデアを見つけることができるだけで、リーダーシップを発揮してリソースを割り当てることができます。

ヨヴァン・サヴォヴィッチ、フトゥリコ

私たちの会社では、プロセスの仕組みの一部として、少なくとも最近、意識的にこのことに全力を尽くしています。



そして、これが効率の面で正しいかどうかはわかりません。他の会社についてはわかりません。 しかし、私たちは何が重要なのかを自分で決めようとします。

イリヤ・サチコフ 、グループIB

このルールは、会社が存在した最初の日からGoogleに表示されなかったと思います。 そして、会社が安定した状態にあり、成長を必要とし、スタートアップを引き付ける準備ができた日に登場したと思います。



もちろん、最高のスタートアップは、内部従業員を含めて出産することができます。 しかし、たとえば私たちにとっては、現時点では、まだ市場を完全には獲得していない自社製品を改善することがはるかに重要です。 それらのいくつかは非常に初期の段階にあります。 したがって、会社の開発段階では、従業員が既存の製品を改善し、機能を拡張することがより重要です。



Mail.ruやYandexなどの企業では、このような戦略とプロジェクトがおそらく可能です。 ロシアではそのようなことを聞​​いたことはありませんが、そのような文化は正確にYandexに似ています。

Alexey Krainov 、Riot Games Russiaディレクター

Riot Gamesについてのみ言うことができます：私たちは従業員の裁量で、無料のスケジュール-労働時間、休日の数、および休日-で働いています。 モスクワオフィスのグローバルおよびローカル。



これは本当に強力なプロと責任者の間でのみ可能であることを理解する必要があります。 彼らはすでに、このアプローチを自分自身にとっても会社にとっても価値のあるものとして廃棄することができます。

ヴラディスラフ・コチェトコフ、FINAM

金融会社では、従業員は通常、厳しい時間的制約の下で働いています。 そして、彼らが創造性のために時間の20％を注文しても、ほとんどの人は現在の問題を解決するためにこの時間を使うことを好むでしょう。



しかし、私たちには、概念の研究開発、新製品のデザインなどの創造性に携わるエコノミスト、ストラテジスト、アナリストがいます。



このようなルールは、キャメロンとクインが言うように、アドホックな組織構造を持つ企業に理論的に有効です。 つまり、KPIが頻繁に変化する、若くて急成長している企業向けです。 KPIが厳しい場合、従業員は独自のアイデアを実装するのではなく、マネージャーが設定した指標を増やすことを試みます（これらの指標が市場の状況にどれだけ適切かは関係ありません）。



実際には、このルールは、いわゆる「革新的な家賃」を借りる収益性の高い大企業で主に証明されています。 彼らが何らかの方向で最初だったという事実のために利益を上げます。



このような大規模なIT企業は、従業員のアイデアの墓地として、また競合他社の人的資源の供給源として機能することがよくありました。 通常、ゼロックスの歴史は例として引用されており、多くの有用な革新が発明されましたが、そのほんの一部だけが実装されました。



小規模な市場志向の企業がR＆Dを行うことはめったにないため、このルールは実行不可能です。 中小企業は、（GoogleやYandexのように）それほど新しいものを発明するリスクを負うことはありません。 より頻繁にコピーします。 そして、巨人のアイデアのクローンを作成し、適応させるために、従業員に労働時間を提供するためにそれほど多くの必要はありませんが、反対に、その意図された使用を監視するために。 スタートアップに関しては、チームが1つの目標に集中することがさらに重要です。



ロシアでは、同様のプログラム[タイプ20％]がYandexで実施されました。 特に、私の知る限り、プロジェクト「School of Webmasters」が登場しました。

アーサー・サハロフ 、レッドマドロボット

ドライクリーニング、ジム、幼稚園、自動車サービス-従業員が会社のオフィスでできるだけ多くの時間を過ごすために、ITの巨人が集めているインフラストラクチャ。 ところで、エリック・シュミットは「120％ルール」について語っています。開発者は仕事に100％、20％を自分のプロジェクトに費やしています。 実際には、Googleのエンジニアは、日常の家庭の問題に対処する必要がないため、開発にさらに多くの時間を費やしています。



Redmadrobotでは、開発者は商用プロジェクトだけでなく、コーディングだけでなく関与しています。 彼らはR＆D活動に参加し、プロセスの自動化、開発の最適化、会議での講演、Habrに関する記事の執筆などに時間を割いています。 実際にはどこにもないため、20％の明確なルールはありません。 私たちは、従業員が強い制限なしに会社に利益をもたらすように、構造を構築し、仕事を計画しようとします。 当然のことながら、初心者の開発者はプロジェクトでほぼ完全に忙しく、それらを汲み上げていますが、最もクールな開発者は開発と将来を目的とした活動に時間の最大60％を費やしています。 そうでなければ、会社は従業員の開発、彼らによる新しい技術の開発、そして後に新しい製品やソリューションが出現するためのテスト場であり、構築された管理システムのタスクはこの開発を促進することです。

ルスラン・ファズリエフ 、エクウィド

ビジネスには100％が必要です。



Googleは事実上20％のイニシアチブを閉鎖しました。 絶対的な焦点のみが勝利を可能にします。 自己紹介をすると、どれほど効果的でしょうか？ そして紹介しました。 PHPの電子商取引プラットフォームであるX-Cartには、従業員がプロジェクトをインキュベートする機会がありました。 誰もできませんでした。 X-Cartが実際に成功させたプロジェクト-TittygramのEcwidは、複数の従業員によって作成され、会社はそれらにリソースを提供しました。 一匹狼は偵察を行うことができますが、勝利は会社がプロジェクトを真剣に考え始めたときにのみ起こります。



小さな会社では、20％のルールは災害であり、スタートアップは生産性の20％を失う余裕はありません。 そして、もし人々がメイン製品以外のいくつかの製品をカットしたいなら、これは考える機会です：メイン製品はとても興味深いです、それは「すべてを振る」時です。



大企業では、個々のイニシアチブを真剣にサポートし始めたときにのみ、20％の有用な枯渇が発生します。 すべてをサポートします-それは洗い流されます。 その結果、「20％システム」は事実上の仕事をすることはできません。従業員は排出量のプロジェクトを見ています。



本当に効果的なのは、時々テーマにしたハッカソンであり、それらをアレンジします。

2004年、ラリーペイジとセルゲイブリンは 、会社が「20％ルール」を使用していると最初に述べました。



2013年、メディアは 、従業員が「20％ルール」の下で自分のプロジェクトを開く権利を奪われたと書きました。 ラリーペイジコーポレーションのメインチェアの登場により、政治は劇的に変化しました。 新しいコースは、プロジェクトの多様化ではなく、少数のエリアでの開発の有効性を最大化するために行われました。



「20％ルール」の廃止は、2012年に開発者がマネージャーからサードパーティプロジェクトの特別な許可を取得する必要があるという事実から始まりました。 Google+の開発ディレクターであるJames Wittakerが2012年にこの理由について書いたものが、彼の出発の理由を説明しています。

「エリックシュミットの下では、広告は常にバックグラウンドにありました。 Googleはイノベーションの工場として運営され、創業者の報酬、ボーナス、そして20％の時間を通じて従業員に起業家精神を奨励しました。 広告収入は、思考、発明、創造のためのマージンを提供してくれました。 App Engine、Google Labs、OpenSourceなどのフォーラムは、当社の発明の足がかりとなっています。 広告でいっぱいのATMですべてが支払われるという事実には至りませんでした。



おそらく、特定の広告を開発しているエンジニアに来ましたが、他の誰もがGoogleは主にテクノロジー企業であると確信していました。 優秀な人材を雇用し、彼らの革新能力に大きな賭けをした企業。



GmailやChromeなどの戦略的に重要な製品が、この革新的なマシンから生まれました。これは、会社の最下位レベルでのイニシアチブの結果である製品です。 もちろん、そのような止められない先駆的な精神は、時には失敗につながります。 Googleにはそのようなものがありましたが、会社はすぐに立ち下がり、立ち上がって結論を出す方法を常に知っていました。



そのような状況では、成功のために特別な「内部サークル」に参加してはなりません。 キャリアを積むことができるクールなプロジェクトを手に入れるのは幸運ではないはずです。 アイデアやコラボレーションの能力がある人なら誰でも貢献できます。 この間、Googleを退職する機会が何度かありましたが、より良い職場を想像することはできませんでした。 しかし、彼らが言うように、それはその時であり、今-それは今です。」

その後、Googleはスタッフの生産性を分析する強力な分析部門を設立しました。 最大の効率で作業するには、従業員は自分の時間の100％をメインプロジェクトに費やす必要があります。 したがって、「20％ルール」に従ってプロジェクトの開始を申請したい人はますます少なくなりました。



正式には、この規則は引き続き会社に存在しますが、実際にはその適用は承認されていません。