職場での「20％時間」の導入[終了]

20％の時間は、それはそれの従業員は、彼らが面白いことをプロジェクトに取り組んで自分の時間の20％を費やすことができ、雇用主の文化だ-それは新しいアプリを発明、または既存のプロセスを向上することができる、などの一部の人々がありスカンクのようにこれを知っています動作しますが、その用語はあなたにとって何も意味しないかもしれません（またはまったく異なるもの）。

会社で20％/スカンクの仕事から生まれた素晴らしい製品の多くの文書化された事例があります。勝ち負けの状況のようです。会社は素晴らしい新製品やアプリケーションを獲得する可能性があり、開発者は自分の創造力を曲げて革新する機会があります。

私は以前の雇用主で働いていた20％/ Skunkを何らかの形で紹介しようと何度も試みましたが、成功しませんでした。

どうすれば経営陣にそれを正当化できますか？この種のワークアレンジメントにアプローチする「正しい」方法は何ですか？

20％の時間の主な理由は、容量の使用率を100％ではなく80％に維持することです。

ソフトウェア開発組織は、機能要求を開発された機能に変換するシステムと考えることができます。キューイング理論を使用して、その動作をモデル化できます。

理論

システムが要求を処理できるよりも早く要求が到着した場合、要求はキューに入れられます。到着が遅くなると、キューサイズは減少します。到着プロセスとサービスプロセスはランダムであるため、キューサイズは時間とともにランダムに変化します。

数学的に傾倒している人は、この「ランダム性」について尋ねることができます。何らかの確率分布がなければならないので、キューサイズは平均で何になりますか？数学（キューイング理論）には答えがあります。到着プロセスとサービスプロセスの両方がマルコフである場合、N = rho ^ 2 /（1-rho）です。

（ここで、rhoはサービスと到着率の比に等しい使用率です。プロセスが非マルコフの場合、計算はより複雑になりますが、結論は変わりません。）

この関数をプロットすると、平均キュー長は低いままですが、使用率は最大0.8であり、その後急激に上昇して無限になります。これは、コンピューターのCPUについて考えることで直感的に理解できます。使用率が100％に近づくと、コンピューターが応答しなくなります。

練習

ソフトウェア開発の経済性により、ソフトウェア会社は、キューが高キュー状態にあるときに大きなコストが発生します。これには、見逃された市場機会、時代遅れの製品、プロジェクトの遅れ、需要を見越して機能を構築することによる無駄が含まれます。

したがって、20％の時間は、経済的な結果を最適化する問題に対する科学的な答えです。高キュー状態を引き起こす使用率を回避することで、高キュー状態を回避します。基本的に、システムの応答性を保つのはスラックです。

いくつかの実際的な結論がすぐに続きます。

• 20％の時間を考慮して原価計算を行っている場合（開発者の時間はXになりますが、/および会社はそれを購入できる/できない）、それは間違っています。
• 毎週金曜日に20％を割り当てている場合、それは間違っています
• 20％の時間のプロジェクト提案提出/レビュー/承認システムをセットアップしている場合、それは間違っています。
• タイムシートに記入している場合、間違っている
• イノベーションを20％の時間の動機として使用している場合、それは間違っています。新製品は20％のプロジェクトから生まれましたが、それはポイントではありませんでした。あなたの会社がコア時間中に革新できない場合、それは問題です！
• 20％の時間は創造性ではありません。20％の時間であなたの創造性を解き放つと言ってはいけません。なぜあなたがコア時間中に既に十分に創造的でないのかを尋ねてください。

コメントの質問に対する回答

ダン、あなたはその権利を得て、多くの人が犯した間違いを正確に説明しました。使用率は出力変数であるため、選択できません。これは、2つのプロセスの特性の比率であるため、プロセスがそのままの状態であるため、そのとおりです。組織は両方のプロセスに影響を及ぼします。能力と需要のマッチングは、無駄のないソフトウェア開発知識体系が取り組む困難な問題の1つです。使用率は、組織内でこの問題がどれだけうまく解決されたかを示す指標の1つです。無駄のないイニシアチブが進むにつれてスラックが発生し、バリューストリームから無駄を取り除きます。ただし、20％の時間を義務付けると、使用可能な容量が少なくなり、同じ使用率トラップに陥ります。

キム、それはまだ部分的に文化的なものです。私が考えることができる最も近い文化的参照は、組織変化のいわゆるマーシャルモデルの相乗レベルです。これは、リーン変換の成功の終わりに現れるか、最初からリーンに構築された組織に存在します。（ボブマーシャルのホワイトペーパー（PDF）へのリンクです。）

参考文献

上記のロジックは、ソフトウェアエンジニアリングの文献で十分にサポートされています。メアリーとトムポッペンディークは、2006年の本「リーンソフトウェア開発の実装」でそれをほのめかしました。ドナルド・ライナートセンは、2009年の本「製品開発フローの原理」（第3章）で、式とグラフを使用して、この主題を徹底的に扱っています。

この回答を書いてから14か月後に、はるかに優れた回答を思いつきました。

そのような作品が公式に認められた場所で働いたことはありません。しかし、この実践についての会話と学習の試みから、私はこれを見つけました-まあ、ほとんどの場合、「20％時間」はそうではありません：

• それは確かに文化であり、政策ではありません
• それは上級管理職によって決定することはできません
• 開発者の委員会によって設立することはできません
• これは32時間ではなく、8時間ではありません

「Skunkworks」は20％の時間とは異なります。20％の時間はあなたが言ったとおりです-開発者が自分で何に取り組むかを選択する時間です。Skunkworksはまったく異なります。スカンクワークスプロジェクトは、チーム（多くの場合、指導者の分裂チーム）が担当する高価値で高コストのプロジェクトであり、経営陣に報告されず、チームは管理の指示なしにプロジェクトを進める方法を独自に決定します。これらのプロジェクトは、多くの場合、何かを成し遂げるための戦術的またはビジネス上のニーズによって動機付けられますが、予算に余裕はありません。何かがいる場合に行わ取得する必要があり、それが行われます-予算はのろわれました。

開発チームを管理し、20％の時間を費やしました。とにかくしようとしました。上司の承認を得たので、それは問題ではありませんでした。問題は、チームが小さすぎて専門性が低すぎることでした。すぐに介入する必要がある問題が発生するたびに、20％の時間がぶつかった。これは非常に頻繁に起こりました。

また、私の開発者の中には、私の方向性の欠如が動揺することを発見したこともわかりました。「プログラミングに関連する限り、あなたがやりたいことは何でもできる」と言ったとしても、彼らは「何でも」の部分を受け入れるのに苦労しました。一部のプロジェクトは他のプロジェクトよりも優れていると考えていたため、必然的にメイン製品の低レベルの実装要求に取り組みました。私は彼らに分岐して成長してほしかったが、代わりに彼らは彼らの主要な専門知識に深く掘り下げた。

私はもう一度やりますが、メイン製品での作業を明示的に禁止し、開始するために選択するいくつかのアイデアからそれらを始めるかもしれません。

私は20％のポリシーを実装した新興企業で働いています。これは私の最初の雇用主であり、彼が就職の面接でそれを持ち出したとき、他のほとんどの雇用主が1時間も「無駄」にしようとしていないので、私は本当に驚きました。

私はスタートアップが設立されたときに参加しましたが、ほぼ1年間、私が唯一の開発者でした。私は20％を基本的にいくつかのことに費やしました。

• ランダムなオープンソースプロジェクトのバグの報告/修正 -これは、Githubで興味深いプロジェクトをフォークし、ドキュメントのいくつかのタイプミスを修正するのと同じくらい小さなものです。
• オープンソースの「もの」を書く -プログラミングの課題のようなもの、ただの楽しみのために。
• 会議やスプリントに行く –数ガ匹ごとにスプリントに行き、そこでプロジェクトの一部（メインアプリで使用されるものもあれば、そうでないものもあります）で作業し、経験を積むことができます。私たちのアプリや、開発者を会議に招待する他社が開発したアプリで使用されるライブラリがいくつかあるため、当社にとって直接的な利点と見なすことができます。
• 新しいテクノロジーの学習 -これは、社内でGoを使用していなくてもGoを学習した方法です。これは私の雇用主によって特に奨励されています。最近、私はスタンフォードの無料オンラインクラスのいくつかをフォローしています。

時間は正確に測定されていません。32+ 8時間ではありません。20％をカットするのに十分な時間がなかった場合、緊急の対応が必要な場合があります。

私はリモートで作業しており、37signalのCampfireチャットを使用して通信し、互いの存在を大まかに追跡します。これらの時間は「作業」時間として追跡され、チャットにログオンし、私が今プロジェクトに取り組んでいないことは明らかです。

私の小さな経験から、私たちのプロジェクトの多くは実際にこのやり方で始まりました。新しいプロジェクトに取り組むための自由な時間と帯域幅があったので、一緒になって、自分の部署で考えられるクール/先進的なアイデアを思いつきました。空き時間にプロトタイプを開発し、それがかなり洗練され、上位レベルに提示されると、通常は利点が見られます。

上位レベルは、見れば自分が望むものを知っているが、それを見るまでは必要/欲しくないことを知らないようです。プロトタイピングにより、私たちは独自のプロジェクトを作成し、提案し、承認されると、完了までの時間をさらに割くことができました。