Pythonを去ることについての最後の投稿 から、私のキャリアはさらに変わりました。

今年の初めMozillaはLabsグループを閉鎖しました。これはちょっと 分かりにくい です。私たちは実際には何も閉鎖しませんでした。内部ではアナウンスしましたが外部へは全く不明瞭です。しかしMozilla Labsは明らかに閉鎖です。末期にまだLabsの一員だった人々のほとんどは Mozilla Foundation （Mozilla Corporationを所有する非営利の団体、税務は複雑です）へ異動しました。TogetherJS とHotdish を作るときのパートナーである Aaron は、再編成の混乱で去りました。またその過程で彼をGoogleに取られました。Labsの閉鎖で私も曖昧な状態に置かれましたが、子供ができたので（2014年4月23日生まれのWilla Blue Murphy Bicking）私は大きな変化を求めていませんでした。

Mozilla Labsの閉鎖について

それが起こった時期と同じくらい機を失してから、私はMozilla Labs閉鎖の理由を理解しました。私はLabsが効果的だったとは思っていません。またその内部は効果的ではありませんでした。

Mozilla LabsはMozilla Researchとは異なることに注意してください。Researchは Rust や ASM.js のようなプロジェクトのホームです。Mozilla Researchはまだ元気があります。2つのグループを大まかに区別すると、Labsは製品に焦点を当てていましたが、Researchは特にプログラミング言語に関連するWebの基礎技術について働いています。またResearchはBrendan Eich、今はDavid Hermanに、かなり明瞭なビジョンと連続性があるような方法で率いられています。Labsは異なる興味と異なるビジョンを持つ多数の人々によって率いられていました。ある人は外的な合法性へのまなざしがあり、ある人はMozillaの破壊的な（また不快な）変化を急ぐことに関心を向けて、ある人は外部の貢献を可能にして取り込むことを望んでいました。

この記事を最初に書き始めたとき、リーダーシップの誤りがLabsのつまずきのてっぺんにあったと感じていました。しかしリーダーシップへのこだわりは グレート・マン・セオリー によく似ていると感じます。私たちのリーダーの見識と勇気によってのみ運命づけられたり祝福されたりする点を除いて。私たちのリーダーシップによる変動する優先順位は、重要な優先事項の度合いを破壊してきたかもしれません。また了解事項（すなわちグループにより共同で維持される了解）は、それら自身が十分な骨組みさえ提供しませんでした。

とはいえ、経営は組織をより大きくするグループの導管です。個人は働きかけることができます。しかしそれは困難で、彼らが手に入れた情報はグループ全体に必ずしも浸透しません。実際の潜在力がない支持者の後を追いかけるので、個人の貢献者による擁護もしばしば誤った方向に行きます。確認されたどの問題に対しても、それを修正する想像上の完全なリーダーを描けます。しかしヒーローを想像することと、強い組織のために計画することは全く違います。

Labsからプロジェクトを立ち上げることは特に成功したとは思えませんでした。 Firefox Sync は、Jetpack（現在は Addon-SDK ）の成果として早く世に出ました。 Open Web Apps はLabsを最終的に組み込みました。 Tab Candy、Panorama、Tab Groups はFirefoxに受け入れられましたが、それがその終わりでした。 Persona は独立したグループとチームになりましたが、 あまりうまくいきませんでした 。 Social API はなくなっていませんが、Mozillaで本当のホームを見つけてもいません。Labsで人々が取り組んでいた多くの事柄は今も存在しますが、Labsのおかげではありません。Mozillaにいる他の誰かがそれにコミットしたときのみ、しばしばプロジェクトは離陸しました。他のプロジェクトはLabsでどうやって生み出されるかについてまだ苦しんでいます。

“Labs”グループは分割されすぎていると、所属する企業からしばしば批判されています。私たちは物事をなかなか片付けられなかったので、Mozillaにおいてこれは問題でした。たとえば、プロジェクトの成功がFirefoxの変更に依存するなら、それらを優先することは困難でした。分かれて働くことで、他の人々にとって好まれていないパターンをしばしば使うことにもなりました。Labsの人々はWeb開発者の視点に拠ることが多く、一方Mozillaの多くがユーザエージェントに焦点を当てていて、これは私が初期に評価したよりもはるかに大きな相違です。しかし技術的な問題がたぶん兆候でした。Mozillaの残りとの統合は、探検や実験の一部ではなく、”問題”や末期の試みと見なされました。

“Labs”の他の批判は、イノベーションがどこでも生じるという点と、ある種の「イノベーション・グループ」を持つことが排他的であり、より大きな企業やコミュニティが示す機会を失うという点です。ときどきLabsは排他的でなくなるよう試みました。コミュニティから案を募ることや、いくつかのより排他的ではない設計過程を導く試みや、内部の休職者をもてあそぶことです。これらによって人々が主に導かれたことを私は残念に思います。それはコミュニティとの創造的な関わりに至りませんでした。

Labsのようなクループの案について、まだ私は完全に悲観的ではありません。たぶん私はそれを”新製品インキュベーション”グループ（”製品”を広い定義で使っています）と呼びたいのでしょう。分割したグループを持つことは課題を明らかにします。しかし確立したグループは彼らの作用域について保守的にならない傾向があり、対処されるべきより中心的な優先事項が常にあります。分割したグループの設立は流用されない投資を生じます。しかし私が書き記すように、これは投資がバランスをとっておく凡庸な方法のように思えるので、既存の製品グループ内でイノベーションを保護することはよりよいかもしれません。私は一部のグループがその保護を達成する場合を見かけます。またそうしない多くのグループを見かけますが、何がその相違を引き起こすかについて私はまだ分かりません。

TogetherJSとHotdish

予想外で不意にもかかわらず、Labsの閉鎖は私たちにとって驚きではありませんでした。プロジェクトとしての TogetherJS が終了するかもしれないというあらゆる予想が確かにありました。閉鎖に対して責任を持つ人を誰も明確にしなかったので、Labsは閉鎖にかかった時間だけ生き抜いてきただけかもしれません。

さらに、私たちはLabsを閉鎖させる動機に反対しませんでした。TogetherJSはMozillaと戦略的な関連がありませんでした。Mozillaの強みの上に築かれた訳でもMozillaを強化した訳でもありません。

「イノベーション・クラウド」の周囲には”失敗はOK”というミームがあります。確かに私たちはそれについてLabsでよく話しました。速く失敗せよ、他の実験を試みよ、繰り返せ。私はこれがでたらめだと思います。失敗はOKではなく、私たちはブラウン運動や選択関数で物事を成す訳ではありません。投資には多くの種類の収益があります。また収益の1種類のみ、成功の1定義のみに焦点を当てれば、ほとんどの実験は失敗に見えるでしょう。イノベーションを促したいなら、”成功”のより排他的でない定義を作る必要があります。成功はあなたが何かを学ぶことを意味するでしょう。成功は解決についての偏った予想の除外を意味するでしょう。成功は領域やアプローチについての学習や理解を意味するでしょう。成功は将来の改善のための適応過程を意味するでしょう。何かが絶望的な失敗のように見えるとき、あなたがいっそう近づき思慮深く見るなら、あなたはそれから学べて、他のアプローチ、他の実験、必要ならメタ実験を思い付けると、私は今なお信じます。あなたはいつでも、しかし思慮深く、方向転換する準備ができているはずです。

イノベーションを起こすためには”全ての”経験から学ぶ必要があります。経験する”間に”活発に学ぶ必要があります。そのプロジェクトについて学ぶ必要がありますが、イノベーションが埋め込まれている環境について学ぶ必要もあります。より大きなMozillaの緊張、懸念、需要、興奮の理解は、学ぶ過程の一部である必要があります。

方向転換できないことは、私たちにプロジェクトの成功を妨げただけではなく、その成功の完全な潜在力の発揮を妨げもしました。たとえば”Apps”は私が始めたときLabsでうまくいっている事業で、また最終的にLabsを含みその後Labsを閉鎖するグループになろうとしていました。しかし私にとってAppsは創造性よりも強情さでできたプロジェクトのように常々感じられていました。Appsは、OSがアプリケーションを必要とする、Firefox OSの文脈の中にしかありません。私が考えているのは、Appsが何らかの意味を持つようになり、ネイティブなアプリケーションのつまらない模倣品にとどまらない何かを目指して繰り返し適用されている状態です。しかし成功を0か1で扱うと、アプローチの再考により改善され得る場合であっても、計画を押し通すことを強いられます。再考が失敗のように感じられるからです。

私たちはTogetherJSがMozilla（少なくともMozilla Corporation）にとって成功ではなかったことを知っていました。しかし私たちは物事を学びました。 Hotdish は私たちの方向転換でした。Mozillaにとって戦略的に意味のあった形態において、そのコンセプトを再考する試みです。具体的に言えば、Webページではなくユーザエージェント（すなわちFirefox）との連携の追加です。しかしその方向転換はその時点で望みがなく、出来事は私たちを追い越していきました。あるいは違うかもしれません。あまりに長い遂行によって成功に熱中して機会を見逃してきたので、私はそれらの機会の評価を信用しませんでした。しかしコンセプトとしてのHotdishがそのときのMozillaにとってふさわしくなかったと私は考えています。Mozillaは現在ストレスを受けていて、短期の成功を探しています。Hotdishは長期のコンセプトです。

私は今なお不満があります。TogetherJSとHotdishの両方で開発していたような経験へのアプローチは、私が最終的に理解し始めたように、Labsが最初からずっとすべきことだったように感じています。Aaronから、また Simon と Gregg との協働からTogetherJSで本当に学んだ製品指向の見解に、私たちは批判的に関与していました。私たちはMozillaの強さと特定の機会に（断続的に）関与し始めていました（この点で外見上は関与し始めていませんでした）。私たちはより大きな組織と技術的なレベルでより積極的に関与する必要がまだあります。しかし実際には、小さなチームが新たな領域を効果的に模索できて、控えめの投資で私たちが新たな方向に実際に割り込めることによって、私たちがパターンを開発していたように感じました。

しかし今でも、これらの特定のプロジェクトについて、私には分かりません。彼らの潜在力について私がまだ興奮していても、心理的な距離を設ける必要があるとも感じています。TogetherJSは結果としてちょっと曖昧な状態になっていますが、 Mozilla Foundation は2015年により大規模なTogetherJSの利用を計画していて、願わくは他の開発ステージと利用を急いでいます。また 有益な貢献者 が最近現れていますが、この状態でプロジェクトを引き受けることが長く辛い仕事であると、私は分かっています。

私が学んだこと

Labsでの最後の経験から、私自身についていくつかの事柄を学びました。

1. よいチームであることは素晴らしいです。よい人間だけではよいチームになりません。以前のMozillaで私はよいチームの中にいなかったか、あるいはよいチームの一員ではありませんでした。どちらなのかは確信が持てません。どちらにしても、私の本当の目標は私自身の確かな道筋を見つけることなので、私は他者を責めるのではなく受け入れたいです。

2. 様々なスキルと見方の人々と働くことは素晴らしいです。「もし」彼らが「批判的で建設的に関与する」なら。浮かれた浅い入力は十分な価値がなく、しばしば高価値の入力を隠すので、彼らは「批判的に」関与しなければなりません。否定的な入力は安っぽく無益なので、彼らは「建設的に」関与しなければなりません。見方と動機のでたらめさはよくありません。人々は方々で互いに話して、議論は解決法の発見の代わりに問題の収集になっていきます。本当に賢い人々を一斉に得ることは建設的な模索を必然的に導くわけではありません。

3. 私は私自身の能力だけで成功やインパクトを期待するべきではありません。私はずっと前から一人だけのコーダー・アプローチをとってきました。私は とてもよい一人のコーダー です。私が何か素晴らしいことを考え出して、それから深夜のコーディングの興奮を作り出していく、驚くべき「究極の製品」の概念を、私は心に秘めてきました。それは自らが認める幻想であり、私がこれを行うと本当に信じていませんが、今なお実際の動機であり、私の現実的な野心を阻みます。この見方はうぬぼれているように見えるかもしれませんが、実際には私の自尊心の信じ難い表出です。ちょっとした自尊心を維持するだけの、私自身の考案によるソフトウェアの作成を、私は止めなければならないでしょう。

4. 私は他の人々の意図、興味、無関心についての仮定をやめるべきです。それは完全に不必要です。私がすべきことの全ては質問です。

5. 成功（または有効性や衝撃）は文脈で起こります。独立した事物ではありません。それはチーム、企業、コミュニティ、あるいはより大きな世界の中で起こります。しかし私は、ほとんどの隣接する文脈の全てを飛ばして、やはり効果的でない時代精神にだけ注意を払うような、一匹狼であることをただ避けるべきではありません。これはLabsにおいて常在する問題でした。それがシリコンバレーの性質なのではないかともときどき思います。

ではどうすれば…？

それで今私は技術管理者という新たな地位にいます。 Cloud Services グループで働いていて、私のチームはFirefox OSのための提供サービスに焦点を当てています。始めてから私はコードに触れていません。経営の専門用語では、私は”ピープルマネージャ”です。

これは私が期待していた異動ではありません。多くの開発者（特にオープンソースの開発者）のように、私は権限に基づく正式な台詞を常に控えてきました。私は技術指導の地位にいる自分の姿を想像してきたかもしれません。私が現在持つ権限はMozillaによって与えられて、必ずしも自分で獲得したわけではありません。これはチーム内での昇進ではなく水平な異動でした。また私が演じる役割は実装者ではなく進行役です。しかしここに私はいます。

私は”物事を行う”方法の探索に多くの時間を費やしてきました。今は”物事を片付ける”方法の探索に時間を費やすことへ目を向けています。これはオープンソースの属性を持ち続けるときに渡る容易な橋ではありません。私たちは驚くべきツールの集合を作成してきましたが、製品はほとんどありません。（Firefoxでさえある意味Netscapeによって実際に作成されました。）　そのため伝統的な手法、商業的な世界の過程や見方に私自身がいっそう目を向けていると気づきます。

マネージャであることを私は学ぼうともしています。マネージャとしての技術と私が軽視していない役割を含めてです。日々の仕事のペースは今や全く違います。自由時間の大きなかたまりは私にとって必ずしも生産的ではありません。代わりに私はアポイントメントとTODOリストを通して勢いに気づきます。マネージャにとって”フロー”が意味することすら確かではありません。以前自分とは無縁にあるものとして常々見てきた規律を私は実践しています。以前は事務・コミュニケーション・応答を、私の”本当の仕事”から遠ざける邪魔なものと考えていました。その考え方は私の傲慢さでしたが、私と共にありました。

私がこの中にいてどれくらいの長さなのか、私には分かりません。私はもっとたくさん学ぶことがあり、まだまだ重要なレッスンが尽きることはないでしょう。また私は物事を継続する義務があります。私が進めた物事は解決するために時間を要して、私がどれくらいうまくこなしているかを知ることすら時間を要します。また私はこの仕事が嫌いではありません。私の職業人生（浮き沈みがありましたが）において長い間すごしてきたよりも、私は驚くほどくつろいでいます。また”責任がある”訳ではないと私が愚かにも考える間に、実際は今や多くの物事に責任がある人生です。責任のうちで最も重要なのは仕事の一部ではなく、私が若かったときに選んだ方法のように気楽でいられるはずがありません。

私は私の技術的な経験が衰えることを心配しています。常に直接的な経験を経るのではなく、理論的に物事を理解することに、私は実際に自信があります。私はチームへ貢献するための”スキル”を正確に必要としません。私が本当に必要としていることは”直感”だと考えています。プロジェクトについての物事を察することが私の役割なので、私は質問を尋ねて、改善を提案して、リスクを見つけて、代替案を提案できます。しかし私がこれを書き記すと同時に私の心配は和らぎます。もし私が組織やチームに関する私の全ての洞察を滝から落とせば、私の知識は衰えるでしょう。しかし私が聞き入れる限り、各々の提案は学ぶ機会でもあります。

なぜ私が始めてからコーディングしてこなかったかは現時点で明らかかもしれないしそうでもないかもしれません。プログラミングは快適で、私において何かを満足させます。またそのことは今の私自身が成長するために必要なことではありません。私が選んでいる行動は私にとって快適ではなく、私が信用しない快適さを差し控える必要を感じています。

私は明らかに疲労を感じています。私が心配するべきことを私が知らないという心配について、今はより多くの時間を費やしています。Mozillaは巨大ではありませんが、小さくもなく、またその組織において柔軟さと緊張のある場所、どの部分が整理し終えているか、どの部分を以前より変えたいかを、理解しようと私は奮闘しています。私は未開発地域の組織的な開発（すなわちスタートアップ）への魅力を理解しています。

原則の成長する集合

これまでの私の時間において、私があろうとするマネージャの種類が何なのかについて考えてきました。たぶんたまにはこれらの原則に従って行動しますが、これらを向上心があると考えることは心地よくもあります。

1. 私の第一の関心事は、チームのメンバーが最も影響力の強い仕事を行うことの手助けです。これは彼らの”最良の仕事”と同じではありません。時間とともに私はこれらが大いに異なることを見ています。またオープンソースの世界がほとんど”影響力の強い”を超える”最良”の上に築かれていると私は考えるので、この優先順位付けは重要でいくらか正反対です。

2. 私はそこが”空間”であることを常に望みます。発見するための空間、学ぶための空間、失敗を犯すための空間、それらの失敗から学ぶための空間（”学ぶための空間”はいつも忘れられます）。同様に会話の空間、会議の空間。私は会話や会議で長い中断を楽しみます。それらがよい兆候になり得ると私は考えます。

3. 熱心に考えることは困難です。特に必要に応じてそうすることは。私にとっても困難です。直感や会話ははるかに楽です。しかしある時点において、私たちが熱心に考えることは必須です。これらの決定的な時間で起こることを確かめる方法を、私はまだ理解していません。

4. 私のチームのメンバーを評価するよう私は求められているのかもしれませんが、それは私の仕事ではありません。教育についての記事ではありますが、私は『 教育における優雅さの授業 』により、私自身が極めて影響を与えられている点に気づきました。私のチームに優雅さを提案する機会を持つとき、私が優雅さを忘れる場合があることを懸念します。また私自身のストレスの渦中でその機会を失います。しかしそのため私自身にこうして思い出させなければなりません。

5. 正しいことを行うときは常に楽しい時間です。しかし過去や想像上の現在ではなく、すぐに正しいことを行うべきです。 埋没費用の誤り は 2つの面 があります。

6. 私はより大きな組織の混乱やストレスから私のチームをかばいません。人々にマネージャによるお気に入りの経験が何だったか尋ねたとき、その組織のより大きなストレスから彼らをかばうマネージャ、彼らに単一で明瞭な展望を与えるマネージャを好むと私はしばしば聞いてきました。そのような経営方式はより快適な環境と、より安全に”感じる”環境を作ります。しかしすでに述べたように、私は”影響”を優先して、影響は組織の文脈に存在します。私のチームが組織の文脈へ創造的に応えて対処できることを私は望みます。私自身のストレスを伝えたくありませんが、根拠のない自信によって私のチームを隔離することは、たとえその時点で親切に見えても、彼らにとって正しくありません。

7. 小さな決断は重要です。また各個人が、彼らの仕事中ずっと、たくさんの小さくて重要な決断を下しています。これが私が隔離したくない理由です。それらの決断が、よくできていて、重要な影響を持つと私は信じます。また私のチームの代わりに、それらの決断がいつ生じるかを私は予測できません。

8. 私のチームが”なぜ”を理解することを私は常に望みます。なぜ私たちはこれを行っているのか？　人々は理由を理解することなく命令を実行できます。私は単に仕事を割り当てることができるだけです。彼らはバグを終わらせることができます（そのときバグ管理システムは仕事を割り当てます）。しかしもしあなたが動機を理解しなければ機会の損失があります。

私がまだ学んでいないリストと比べて、多くの欠落があります。またおそらく私の役割に関して正しくない見方を示す項目がいくつかあります。しかし経験の次なる集合から、暫定的な理論を私は作り続けるでしょう。

私がこれまでに学んだことについてさらに書くための意思を集められたらと思っています。