20パーセント制度がどうこういうのは、一歩下がると企業が新しいものを生み出すためにどうすべきかの議論である。20パーセントは下々や現場の人からも新しいものが生まれるといいですねという話だった。このコインの裏に、新しいことを考えるのが仕事の人は現場に出たほうが良いですねという話がある。勤務先のリサーチ部門のトップ（当時）は、それを主張する Hybrid Approach To Research という記事を書いている。すごい雑にいうと、いわゆる研究者も製品開発に突っ込みましょうみたいな話。しばしば「象牙の塔」などと揶揄されがちな大企業研究所モデルのステレオタイプに対するカウンターとなっている。
論文書きや標準化といったリサーチっぽい仕事と製品開発の近接は自分の勤務先での体験と一貫しているし、機能もしている。伝統的な研究所モデルとの優劣は自分には議論できないが、少なくとも研究者たちが専門分野の知識にもとづいて書いた実製品のコードは差別化の要素になっているし、逆にばりばりコード書いたり標準化にクビつっこんだりしているエース級がその成果を論文にまとめ、世間に注目されたりもしている。
ある日の夕方、リサーチと部門が持っているコードをちょっと直す必要があったのでパッチのレビューを送ると「ごめんごめん今オフィスに帰ってきたところだから明日レビューするね」と返事があり、ふーんとおもっていたら数日後に会社のブログで CVPR に論文を通していたことを知る、みたいな出来事があった。学会帰りだったのか。締め切りのある製品コード書きながら締め切りのある論文も書いてるこのひとたち・・・と驚愕した。
CS のエリートがすごいアイデアを考えバリバリとコードを書いて製品につっこんでくる。その様子をずっと横から眺めていた自分は、これこそ勤務先の競争力の源泉だと信じるに至った。その反動で「誰でもイノベーションできる」みたいなファンタジーに白けてしまう面はないでもない。
一方で、エリートが活躍できるのも究極的には個人の自立性を重んじる文化の現れなのだと考えると、エリートが活躍できるためにそういう空気を作り出すのは大切なことで、それに便乗したボンクラがどうでもいいことに時間を使うのはまあ、空気の対価ということでいいんじゃないかという気もしてくる。エリートだけあからさまに差別しちゃうと空気悪くなるし製品開発で協力とかも心理的に盛り上がれないからね。ある程度は優遇した方がいいと思うし、実際されているだろうが。
世界で戦える CS トップエリートがじゃんじゃん成果を出す。下々のボンクラもたまに少しは面白いことをやる。その間くらいのひとは、間くらいの成果を出す。PM やマネージャは適当にその辻褄をあわせる。プログラマ中心のテック企業にはそういう感じでやっていってほしいもんです。
On 20-Percent を読んだ知り合いから反応があった。自分の考えをもう少し整理し、「20パーセント制度」の語りをめぐる自分の中のわだかまりを三つの論点にまとめてみる。
ひとつ目は、勤務先の中の人の語りは盛り過ぎではないかということ。20パーセント制度の成功例としてよく Gmail が引き合いに出される。Gmail はユーザ数が 1B を超える超大成功製品である。そんな成功を生んだ制度ならたしかに自慢の甲斐もある。しかしこの主張の信憑性は薄い。Paul Buchheit はインタビューの中でこう話している:
[Larry] and Wayne Rosing, who was the VP of Engineering at the time, would sit down with engineers and give them projects. When they sat down with me they said, “we want you to build an email something.” That was all the specification I got! So I went off to build something with email, which became Gmail.
自発的でも 20 パーセントでもなく社長直々のフルタイムプロジェクトじゃん？Gmail に限らず、同じ規模の主要製品の中で 20 パーセント制度から生まれたものは無いのではなかろうか。
20 パーセント制度が何も生んでいないとはいわない。いちいち例はあげないけれど、沢山の面白い、良いプロジェクトの起点になったとは思う。でも Gmail が引き合いに出されるたび嘘くさくて白けてしまう。
20 パーセント制度の成功例をいちいち名指ししたくない理由は、ふたつ目の論点と関係がある。これは前に書いたことの繰り返しだが、20パーセント制度はボトムアップで勝手になんかやる文化の現れに過ぎないと自分は信じていて、制度ではなくその文化を大切にしてほしい。
二割とかケチくさいことをいわず、プログラマは自分でやると決めたプロジェクトにフルタイムで取り組むことができる・・・こともある。実力、実績やカルマ、チームの勢い、上司の性格、プロジェクト自体の説得力と野心度、主要製品との相性・・・こうした変数によって、獲得できる自立性には大きなばらつきがある。でも当事者たるプログラマが「こういうのがあるといいと思うのでやります」と言い出し、上司などが「そんじゃよろしく」とプロジェクトが始まる(あるいは上司に黙ってこっそり始まる)のはそこそこ普通の現象。Gmail の逸話にしたって、上司がいってきたのは「メール関係でなんかやってよ」だけだから勝手にやったと Buchheit はいう。このマネジメントの雑さ、当事者の自由度は勤務先に対する自分の文化的イメージと合致するし、大企業になった今も面影を残していると思う。
別の例: Chrome の話。Chrome をはじめたのは Ben Goodger や Darin Fisher といった Mozilla 出身者だが、彼らは別に Chrome をつくるためではなく Firefox に検索っぽい機能を入れるために雇われた。けれどしばらく働くうちに結局ブラウザが作りたくなり、上司に「ブラウザやります」といったら「やろうやろう」と盛り上がりプロジェクトが始まったと言い伝えられている・・・というか件の上司が他の部門に異動する際の小さな集まりで当人から聞いたのでここで言い伝えさせていただきます。つまり Chrome は少なくとも当初は戦略的製品とかではなく、当事者が自発的に始めたフルタイムのプロジェクトである。大小様々な規模のプロジェクトが似たような感じではじまり、様々な成功（や失敗）を収めたことは想像に難くないし、実際いくつも目にしている。
各人が実力や実績に相応しい自立性を持てる。そして「実力や実績」には必ずしも組織上の権力が伴う必要はない。そうした自立性を当然のものとみなす空気がある。制度としてすべての社員に最低限の自立性を与える20パーセントより、自分は雑さの空気を信じている。
空気は繊細なものだから、環境の変化に晒され失われることもあるだろう。だからこそ単純な制度に卑小化されたくない。「制度としての自由」と「上司にいわれたことをやる」の間にある豊穣をわかりやすいストーリーで握りつぶさないでほしい。
みっつ目は完全に個人的な話。自分は、少なくともある時期まではかなり高い autonomy budget を与えられていたと思う。勢いのあるチーム、放任主義のマネージャ、外的要因のせいで進みの遅いプロジェクト。妻子なし。本業の外で自分のやりたいことに好きなだけ時間を使える条件が揃っていたし、実際それなりに時間を使っていた。にも関わらず、大した成果は何もなかった。やがてこの autonomy budget をダラダラと浪費する働き方に適応し、非生産的な日々を過ごすようになった。この話は前にも少し書いた。
自由を与えられながら何もできなかった現実は自分に都合が悪いので、無意識に色々言い訳したくなる。その一環で20パーセント制度にもケチをつけたくなる。別に自由な文化からイノベーションとか出てないでしょ成功した製品みんな買収でしょ、とかシニカルな態度を取りたくなる。
ボトムアップで自律的な文化に負の側面があるのは事実だと思うけれど、自分がそれを生かせなかったからといって必要以上に否定的になるのは我ながらよくない。
でもインターネットで20パーセント制度の話題をみかけると「なにもできなかった自分」という現実が視界に入り、シニカルさが顔をだしてしまう。愛社精神とシニシズムが関心を求めそれぞれ声を上げる。自意識の病。
この「20パーセント病」が発症したらほんとうは話題から距離を置くのがよいのだろう。それに自分のようなボンクラより、成功譚の当事者から話を聞きたいよねえ。
職場から持ち帰った仕事での不機嫌が感染して子も不機嫌になる、という vicious cycle が発生した。よろしくない。
帰り道に考え事をするのは生産的ではあるが、仕事で BS が発生した直後だと考え事を通じて腹立ちが長引いてしまう。仕事が BS だった日はむしろ家への帰路で podcast なり audiobook なりを聴いて仕事を detach した方がよいのではないか。仕事以外の考え事するでもいいけれど、題材があるとも限らないし。
一方で仕事から一歩距離を置いて何かを考える、というと大仰だけれども目先のバグから一歩下がって翌日やるべきことを考える、とかは意味があるし、記憶が失われる前、その日のうちにやった方がよい。というわけで仕事というかデスクを終業 30 分前に離れ、よそのオフィスにラップトップを持ち込んでコードから離れて wrap up をしてみる。（コードはデスクトップで書いています。）
終業間際までコードを睨んでいるよりは良い気がする。欠点としては移動のオーバーヘッドがあるのと、このまま家に帰るのでラップトップをもって通勤しなければいけない点。あとなんだかんだで実作業時間が減ってしまうのは若干いまいち。ラップトップは諦め、歩きながらの考え事とおなじく紙のノートを受け入れれば良いのかな。まあ 30 分前 wrap-up 自体は実験的にしばらく続けてみよう。アラームを設定。
ところで先週ことさら BS に腹がたったのは、一つには風邪のせいで二週間くらい課外活動ができていなかったせいもある気がする。気分転換がなかった。Podcast の準備に paper reading とかをしていると、仕事以外のテックな関心事がアクティブになるので仕事が多少ムカついても気を散らせて良い。気が散るのは一般には良くないことだが、BS が目の前にあるときは有効な気がする。仕事の性質上ある程度の BS は避けられないので、課外活動をもっておくのは精神衛生の予防に良さそう。「仕事の他の趣味があるといい」みたいなのってどうでもいいとおもってたけど、働いて稼ぎ続ける必要性を考えるとあながち無視もできない。やれやれ。
NN のモデルがアプリのあちこちに色々ありすぎてメモリや CPU を使いまくって厳しい。モデルの実行は自分の与り知らないネイティブコードの奥深くで起こっているのではたして全体でいくつのモデルがあるのかすらわからないが、なかなか現代的な事象を目の当たりにしているとは思う。
アプリの性格上、こうしたモデルの大半は何らの方法で画像を入力として受け取るモデルのはずである。理想的には、アプリに内在するいくつものタスクは入力を共有する multi-head なモデルとして表現され hidden layer などの計算資源を共有すべきだが、たぶんそうなっていない。
これは入力の解像度やモデルの実行頻度の違いなどに起因している面もあるけれど、より本質的には Andrej Karpathy の Software 2.0 や Keras 作者の The future of deep learning が envision しているような未来のプログラミングとしての model composition という世界がまだここには来ていない、という話のような気がする。
モデルを開発しているチームが会社の中の別のところにいるせいでおこる ML 版 Conway's Law という見方もできる一方、伝統的なソフトウェアではチームをまたいでコードが分断されても機能自体は API を通じて共有され同じ計算を何度もやりなおしたりは（そんなには）していない。ML モデルにしても、たとえば segmentation なんかは複数チームの機能をまたいでモデルおよび結果を共有している。つまりモデルの入力という切り口でなく Java なり C++ なりの API というところまで遡れば共有されている。
複数機能やチームをまたいでモデルのアーキテクチャを部分的に共有する、なんて言うは易しだけれどもトレーニングどうするなどを含め自明でないことが多すぎ、自分にはあるべき姿がまったく想像できない。一方でそうしたモデルの統合なしにデバイスの計算資源が要求にあわせスケールすることがあり得ないのもまた明らかなので、この問題は数年以内にどこかの頭のいい人がなんとかするのだろう。それを見届けたい気はする。単にスケールせず AI 機能は頭打ちになりました、おしまい、という可能性もまあまああるが・・・。
あるとき AI っぽい新機能を開発している同僚と話していたら、その機能は実は別のあまり関係なさそうな既存機能のモデルで実現でき、したがって性能上のインパクトほとんどないんだよ、と聞かされてびっくりした。モデル再利用できちゃってる？自分の問題認識が遅れているだけで、結局問題は Conway さんという話なのかなあ。
Martin Fowler が micro models とかいいだすのはいつだろうか。Micro frontends 以上にどうでもいい話になりそうだが・・・。
Getting Things Done であるためには手段を選ぶべきでない、プログラマはなんでもテクノロジで解決しようとするが交渉などで解決した方が良い問題もある、みたいな主張を昔たまに耳にした。今でもそういうことを言う人はいるかもしれない。
これは言い換えると、問題を解決するためのコストを最小化しろという主張だと理解している。ここで主張自体に異論を唱える気はないが、当事者のコストを理解してないなとも思う。
たとえば何らかのインテグレーションを片付けたいとする。インテグレート先に望ましい API が足りていない。コードによる解決策は、たとえば足りない機能を自分で実装する、かもしれない。この作業には 10 コード$かかるとする。 交渉による解決は、たとえばインテグレート先のチームにお願いして API にフラグを足してもらう、かもしれない。この作業には 2 交渉$かかるとする。
「コード$」および「交渉$」は仮想のコスト通貨である。ここでいうコストは所要時間かもしれないし emotional burden かもしれない。交渉の方が速いと考える人は 10コード$ > 2交渉$ と考えているが、これは交渉が得意な人の為替感である。そのひとにとっては、たとえば 1コード$ == 1交渉$ である。一方あるプログラマ、仮に森田と呼んでおく、にとっては 10コード$ = 1交渉$ である。別の言い方をすれば 1 森田$ = 1 コード$ = 0.1 交渉$ である、かもしれない。
コスト通貨の為替レートは個人差が大きい。個人は自分の為替レートに基づいて判断を下す。相手に自分の為替レートを押し付けることはできない。
チームワーク
反論はいくつかありうる。たとえばチームワークという点でコードは高く付くかもしれない。後の保守コストを考えると 1 チーム$ = 2 コード$ = 0.5 交渉$ くらいかもしれない。すると先のインテグレーションはコードを書けば 5 チーム$, 交渉なら 4 チーム$ で片付く。交渉したほうが安い。
頼まれる側からするとチームのために自分の苦手なことをやれという依頼には Principal–agent problem がある。真面目な会社員たるものべつにチートとかはしないけれど、やる気は起きない。もう一つの問題は、チーム総体の能力を判断するのは難しいことなので、そのunreliable judgement に基づいてなされる話には説得力がない。
もっと有り体に言うと、交渉仕事はそういうのが得意な人に頼んでくれやと思う。人手が足りないのはわかるのである程度は協力するけどさ。
スキルポートフォリオ
人手の足りなさに連なる別の主張として、交渉も得意になった方が仕事の幅が広がるし問題解決能力も高まるよ、という反論もある。この主張の正しさはケースバイケースだし、バランスでもある。
交渉、に限らず自分の得意なこと以外が極端に苦手というのは、要するに問題解決の手札が少ないということで、そこには不利がある。仕事にかぎらずなんらかの達成が求められている世界では、原則として達成を重ねるほど評価され、立場がよくなる。結果としてやりたいことがやりやすくなる。なので手札を増やして達成のスループットを増やすのには意味がある。
要するにスキル・アップしてキャリア・アップしましょうね、という話。
一方で、目の前の問題解決に求められているスキルと自分のキャリアに必要だと自分が感じているスキルが一致しないこともよくある。交渉上手になれっていうけど別にそういう組織横断的な仕事をやりたいわけじゃないんで・・・みたいな。目の前の問題解決に最適化した結果マネージャになる事例はよく観測される。それを望んでいるケースもあるので必ずしも悪い話ではないが、それを特段望んでいない身に交渉がんばる気などはない。
そうはいっても、自分のやりたいことと世間の需要が乖離すると金を稼ぐのは難しくなる。そして目の前の問題は、世間の需要を何らかの形で近似している。目の前の仕事の求めを自分の思惑と違うからを退ける不安は強い。
けれどけれど、真の意味で世の中の需要を突き詰めるならプログラマとかやってないで Wall Street の trader なり外資系 consultant なりになった方がよいのでは？プログラマたるもの Knuth 目指して山に籠もって Deep Work でしょう？
これは極論だけれど、スキルポートフォリオを根拠に交渉 $ の強化を求める上司の望みもまたノイズ溢れる市場からのシグナルに過ぎない。そんな視座は失わないほうが良いと思う。目先の仕事が超稼げるので上司の願いを叶えるのは重要、というケースもありうるが・・・（ドラマの中の Wall Street や Hollywood にみられるステレオタイプ。)
などこれといってはっきりした指針があるわけでもないので、問題解決の手段は人の話は聞きつつも最後は自分の胸に聞いて決めましょうという話。
政治的ということばは曖昧すぎるので嫌いだが、外交的なコードってあるよな。WebKit の仕事をしていたころは毎日そんなのばかりだった。また最近書く羽目になってうんざり。
外交的なコードとは他人の主張にあわせて書くコードのことである。他人のコードにあわせる、では無い点に注意。他人の書いたダサい API に自分にコードを合わせるのは、ここでは外交的に数えない。それを言い出すと一人で閉じないすべてのコードが外交的になってしまう。コードレベルの enforcement ではなく、ミーティングとかで書くことが決まってしまった望ましくないコードを指すことにしておく。
外交的なコードにはいくつかの段階がある。
一番ダメージが少ない外交的コーディングは他人のために自分がコードを書いてあげる、仕事をひきとるケース。仕事は増えるが後腐れはない。
一番ダメージがでかいのは他人の意見によってソフトウェアのデザインが歪められるケース。なおここでいう他人は該当ソフトウェアを書いているチームの外の人という意味で、チームメイトは含まない。チームメイトとデザインの方針が合わず好みのコードを書けないこともあるが、外交よりチームワークの範疇。
他人の「都合」によってコードがダサくなるのは外交的な問題か？他人の都合、たとえばレガシーコードとのつなぎ込み、は解くべき問題の一部だと思うので、外交には数えたくない。外交的コードとは、よりよい解決策があると自分は考えているのに、相手の顔をたてるなどソフトウェアの外の事情で自分のアイデアをひっこめて他人の主張を受け入れるもの。
この間くらいにあるのが、相手の意見によって優先度が変わるケース。それ次のリリースでいいじゃんという作業を、いや早くやるべきなぜなら俺がそう思うから、みたいに押し付けられる。締め切りまで時間がないので corner cutting がおこり、デザインが歪む。
外交的コーディングの必要性は外交それ自体とおなじくはっきりしない: 外交というものの必要性は認めるが、個々の外交的アクションを評価するのは難しい。
外交的コーディングには仕事が増える以外に固有の問題がある。
まずソフトウェアデザインの autonomy が奪われる。Autonomy は人々の労働意欲の核の一つである（って Daniel Pink が言ってた・・・と書くと急に説得力なくなる。）要するに仕事のやり方を指図されるのはムカつく。デザイン全体の integrity も損なわれる。
つぎ。外交的コーディングは rationale を記録するのが難しい。「あのめんどくさい人のいうことに従ったのだよ」なんて design doc や commit log に書けないじゃん。結果として説得力のないデザインだけが残り、後世の人々は puzzled する。そして書いた人を blame する。俺のせいじゃねえーーと言い返したいが証拠がない。
外交的介入をうけたのがデザインそのものではなく優先度だと事態は殊更不透明になる。たしかにそのデザインを考えたのは我々だが締め切りが無茶だったのだよ・・・みたいな主張は、外交的に作られた一時的で人工的な締め切りの存在を明らかにしてしまうので大っぴらに語りにくく、風化しがち。俺のせいじゃねえーーー！
同様の理由により、外交的コーディングは議論するのも難しい。外交的妥協をしたマネージャはしばしば下々のプログラマから意思決定に噛みつかれる。「偉い人を宥めるためなのだよ」と開き直れるかはマネージャの性格次第でもあるが、外交の性質上単純な honesty が望ましいとも限らない。無理に取り繕って株を下げがち。外交に負けて株が下がるのは仕方ないとして、「外交に弱い」ではなく「話がわからん」とラベルをつけられてしまうマネージャは気の毒。
外交的譲歩は良くないことに思えてくるが、ならばとタカ派になるとそれはそれでどこかの大統領みたいになってしまう。よりよい提案は: きわどい外交的立場にならないよう普段から気をつけましょう。より長期的には外交的露出の少ない立場につきましょう。