製品開発においていちばん影響力をもっているのは誰か。もちろん組織構造で上の方にいる人が偉いわけだが、それはさておき様々な SWE, SWET, PM や UX など色々ある職能のうち誰が強いのか。

ブラウザをやっていたころは、プログラマが強い印象だった。自分が  Web の API を増やす部門だったせいもあるとはおもう。プログラマ（のうち意見のあるアジテーターみたいな人）が色々とやりたいことを決める。PM は主にロジスティクスとか辻褄あわせとかをやる。仕事の性質上 UX はいない。Web API に限らず、ブラウザという製品の舵取りをするのは founding member のエースプログラマだった。今はどうだか知らないが・・・。

UI にしても、デスクトップだとメニューに要素を一個足すくらいなら UX に相談とかは一切なく新入りプログラマが思いつきで足すようなことを平気でやっていた。というか自分は  パッチ修行として Mac Chrome に「辞書を引く」というコンテクストメニューの項目を足した。十年前は牧歌的な時代だったという話でもあるが、それだけでもあるまい。

UX

スマホアプリのチームに異動してびっくりしたのは UX の力の強さだった。プログラマが雑に UI を決めたりはせず、基本的には UX (デザイナ) のつくったモックを実装する。プッシュバックしたりはあるが、ほとんどのプログラマは自分でモックを起こすことがない。新入りが勝手にメニューを足していたデスクトップとはだいぶ違う。画面が狭いので雑さが許されない。

UI をデザインするというのは、結局機能をデザインするのと同じ。なので UX が製品の舵をとっている・・・というのは大げさすぎるが、プログラマには「降ってきた仕様」を実装する下っ端ぽさがあった。（自分が性能改善ばかりやっていたのは、それがなんとなく面白くなかったせいもある。）面白いのは UX の人々が自分の権力を自覚していないように見えたこと。そして UX とプログラマの関係が妙にウォーターフォールぽかったこと。プログラマ主導、実験指向で漸近的な開発を誇っていた企業のはずなのに、モバイルになった途端こんな前時代的になってしまうとはとショックを受けた。

まあプログラマは別に地位が低いわけではないし意見もある人々だったのでただおとなしく仕様を実装したりはせず色々ネゴしたり自分のやりたい機能をゴリっと入れたりもしていたがそれは個人の努力であって、プロセスはそうしたプログラマの自律性を後押しはしていなかった。

ただしばらくモバイルの仕事をして振り返るに、これはやや極端な例だった。つまり、必ずしも UX パーソンが仕様を主導するわけではなく、それができるのは優秀かつ意見のある人だということ。たとえばチームの新機能ブレストみたいのをリードするのは誰か。UX の人が主導するチームもあるし、プログラマが主導するチームもあるし、PM がやるときもある。

自分が体験した UX 主導プロジェクトは、プログラマが相対的にボンクラだったのに対し UX のひとはすごい優秀だった。実際そのひとはトントンと出世し、どこかに行ってしまった。その人の下で働いていた UX の人がいまの自分のチームにいて、やはりというか割と優秀である。

PM

Mini CEO などともてはやされがちな PM. 存在感はまちまち。ブラウザ時代いっしょに仕事をした PM は雑用っぽいかんじだった。無能というわけではなく、ただ方向性とかは主張しない人々だった。当時はまわりに TPM も PGM もいなかったけれど、事実上そうした仕事をしていた気がする。おかげで人々から感謝はされていた。

電子書籍時代の PM は、下っ端の若者はさておきシニアな人は大きな方向性やビジョンみたいのは決めていた気がする。たとえば「Audiobook やるぞ」みたいな。そういう人がミーティングでバーンとプレゼンし、具体的な機能は、その方針をうけてプログラマなり UX なりが考える。PM がエラそうにしてる！と最初はちょっとびっくりした。

電子書籍ではコンテンツホルダ（出版社）との窓口をするパートナーシップの人も存在感を持っていた。契約上の色々なめんどくさいことはこうした人たちが PM と組んで deal してくる。プログラマは出る幕なしで、決まったことを実装しないといけない。これはパートナーシップ部門の人が偉いというよりはコンテンツホルダが偉い、すなわち Content is king という話な気もする。むかし Ben Evans が Content isn't king と書いていたが、これは市場を独占した人たちに限った話。

PM は色々なことをトップダウンに決めているように見えたが、実際は関連部門の意向をとりまとめていた面もあったのだろうと思う。今やっているカメラの PM は比較的仕事ぶりの transparency が高くどうやって物事を決めているか開示している。それによれば、リサーチ部門からハードウェア部門から OS 部門まで各方面に話を聞いた上で判断を下している、ように見える。バーンとトップダウンにプレゼンしているように見えた電子書籍時代の PM も、たぶん事前に各職能の leads と相談し、おおよその合意を形成していたのだろう。自分が気にしてなかっただけで。

トップダウンより合意形成を重視するのは、一つには PM は別に関連部門の上にいるわけではないからだろうね。それでも自分がいまいるチームの PM はそれなりに筋の通った価値基準を持ち必要に応じて外からの提案を押し返したりもしているので、個人的には評価している。エラくなりそう。

SWE

プログラマはソースコードという最終成果物に直接アクセスできる強みがあるので実質的には一番権力がある・・・と思っていた時期もあったが、実際にはケースバイケース。

たとえば勤務先のモバイルだと勝手に UI をいじれない。レビューが必要。これは大企業だから官僚的という面はあるし、モバイルだから画面予算の管理が厳しいという面もある。

電子書籍だと、コンテンツホルダとの契約があるのでデータのいじれる範囲に限度がある。社内で実験的になんかいじるのはいいのかもだが、その結果の扱いには制限が多い。新機能のために契約の制限を克服するにはパートナー担当や PM の協力が必須。そしてふだんからパートナーシップに接している PM は契約をどこまで交渉できるかの肌感覚を持っているので、標準的なプログラマとくらべ機能デザインにもカンを働かせやすい。

Web API にしても標準化されてるのでコードがいじれるからといって勝手に増やしていいわけではない。標準化団体で人々を説得するなどが必要。とはいえモバイルプラットフォームとかの方がプログラマが自分で API を決めて実装している色が強い。何らの官僚的なプロセスはあるにせよだいたい会社の中に閉じており、競合他社を説得するとかは必要ない。コミュニティを説得しないと新しい API を使ってはもらえないが。API を決める仕事とっても色々あるね。

様々な場面でプログラマが主導権を発揮できないのは、該当者がボンクラだからという面はゼロではない。UI プログラマならモックくらいいじれるべきだし、電子コンテンツプログラマなら権利関係を理解しているべきだし、Web API プログラマは弁が立って然るべき。といえなくもない。

たとえばカメラの高画質を支えるアルゴリズムを開発したリサーチ部門のトップは製品開発の組織系統に直接は所属していないにもかかわらずめちゃめちゃな影響力をもっており、他のチームが一年かけて作ってきた機能を一声でボツにしたりする。これは実力の帰結と言えよう。

これは極端な例かもしれない。とはいえプログラマなら勝手に書いたコードはそのまま出荷はできないにせよデモくらいはできる。雑な世界にあった自由と力はないにせよ、なんらかの優位はある。ただデモとかハックをするにはある程度ヒマが必要なので、締め切りに追われてるとダメだね。

組織で働く会社員プログラマの仕事場として望ましいのは誰が力を持つチームか。

プログラマが力を持つ環境で一度くらい働いておかないと、それがどういう状態なのか理解するのは難しいかもしれない。今の会社に入る前の自分は、たぶんわかってなかった。一方で他の職能のひとが活躍している様子を見るのは、それはそれで学びがあり、人を humble にする。

あと一つの職能の人だけが活躍しているより、それぞれが主張をしつつ交渉や議論のダイナミクスの中から製品が立ち上がってくるほうがわくわくする面はある。プログラマが主役になってばかりの環境にはない面白さがある。

たとえば UX のひとがもってきた新しいデザインに、ちょっと気の利いたツイストを加えた POC でプログラマが応じる・・・みたいなのは見ていて楽しい。あるいは自分がやっている性能仕事のドキュメントをもとに PM が気の利いたピッチをスライドにするのを見るのも・・・まあ、なるほど、とは思う。自分がもうちょっと野心のある身だったら盛り上がるのではなかろうか。今は若干こっちくんなとか思ってしまうがそれは PM のせいじゃないからね・・・。

ただプログラマが仕切っている環境の方が、その仕切っている人の価値観とズレがないならストレスは少ないね。ストレスが低いのは、それはそれで大切。

Draft の底に沈んでいたやつを Rebuild で話す準備として掘り起こしてみたが、話す時間なさそう。