ふと読み返していた書籍 The Manager's Path の序盤に "Imagined Life of a Senior Individual Contributor", "Real Life of a Senior Individual Contributor" というセクションがある。そして "of a Manager" のペアがそのあとに続いている。理想と現実というやつ。きみほんとマネージャやりたいのかと問う序盤の一幕。
マネージャは知らないが、IC の Imagined Life / Real Life は戯画的ながらよく書けている。そして自分はそこそこ "Imagined Life" に近い日々を過ごしているなと思う。日々は純粋な deep work ではなく雑用もままあるが、テクニカルに難しいことをよく考えてなんとかする、という部分は割と達成されている。あと雑用は出世の足しにならないだけで、必ずしも嫌いではない。
けれどセクションの締めくくりを読むと客観的な Imagined Life 達成率はそんな高くもない気がしてくる:
In short, you have the perfect balance of engaging work, fame, and accumulated expertise that makes you invaluable and respected, highly paid, and influential.
Imagined Life of a Senior Individual Contributor, The Manager's Path
ニッチな部分である程度 invaluable になってはいるが、fame や respect, influential あたりは全然ない。給料もまわりの出世してる人々と比べると highly paid でもない。人々は仕事に色々なものを求めているのだな、と思う。自分は engaging work の重みが高くて、他はそんなでもないらしい。給料はもっと欲しいが別にマネージャやっても上がんねーしな。Fame とかねー。昔は欲しかったような気もするしあったらあったで素敵なんだろうけれど。
なお "Real Life" のみならず "Imagined Life of a Manager" のセクションは読んでもまったくときめかないので、自分のマネージメントの興味の無さはなかなかのものだなと見直した。昔はもうちょっと興味あった気がするんだけどねー・・・。
マネージメントを試してみるのは程度テクニカルな経験を積んだあとが良いと本書は指摘しているが、あまり時間が経ちすぎると興味が失われてしまう危険(?)があるので、若者はそうなる前に早いところ一回くらいやっとくといいんじゃないでしょうか管理職。権力とか野心とか、体力ないと追求できないと思うのだよね。同世代の権力者はみんな体力あって立派。
大企業にいるせいか、時折「プロダクトの移管」を目にする。ある製品、あるモジュールの担当チームを、元々の持ち主からまったく別の持ち主に引き渡す。国をまたぐことも多い。「東京のチームがやっていたこのアプリを新しくできた NY のチームに移管します」というかんじ。
移管は基本的にはトップダウンである。開発チームがわざわざ自分からコードを手放すことは、あまりない。（世間では「v2 を作るから v1 を誰かに押し付けたい」みたいなクソ野郎もいるらしいが、今はそれは置いておく。）えらい人々が決める移管には色々な説明が与えられるものの、外野から見るとだいたい二通りの理由に落ち着いている。つまり 1) テコ入れか、2) コスト減の、どちらか。
自分は、プロジェクトの移管は良くないと思っていた。今も良くないと思っている。良くない理由は、ソフトウェア開発者にとっては直感的に自明だろうけれど、いちおうあとで議論する。
昔々に受託開発の仕事をしていた頃、移管と似たようなことはよく起きた。製品 X を開発するプロジェクト A を受注、開発してバージョン 1.0 を出荷する。ここで一旦プロジェクトは終わる。しばらくしてから X のバージョン 1.1 を開発するプロジェクト B を受注する。しかしプロジェクト A の開発者たちは既に他の仕事を受けており忙しいので、プロジェクト B の開発はバージョン 1.0 とは別の開発チームが担当する、というか、プロジェクト B のための新しいチームが組織され開発に当たる。この新しいチームには、運が良ければ A の開発メンバーの一部が含まれていることもある。とはいえ基本的には別ものである。
受託開発におけるこうした「移管」は、受注したプロジェクト単位でチームを構成するためにおこる。チームの再構成は自社製品を開発している企業では起こらない。同じソフトウェアを、多少の入れ替わりや組織改編はありつつも基本的には同じチームで開発しつづける・・・えらい人々が移管を言い出さない限りは。
移管の大きな問題点の一つは、コード、運用、デザイン原則など製品に関する暗黙の知識が失われてしまうことだ。文書化によって「暗黙」の程度を減らせると信じる人もいるが、個人的には文書化なんてたかが知れると思っている。文書化が必要ないという話ではなく、文書化でカバーできない大事な知見は沢山あって、それらは人と一緒に失われてしまう。
Products Over Projects という記事は、移管と似た性質を持つ「プロジェクト指向チーム」が孕む問題を包括的に議論している。ただ製品指向の組織で働いている人にとっては当たり前の話なので、今更ここで繰り返したいとは思わない。
こうした問題がありながら、なぜえらい人は移管をするのだろうか。なぜ製品開発チームの強みを自ら捨ててしまうのか。それが自分の疑問だった。
えらい人はわかってない。そう主張することはできるし、細部のニュアンスをわかっているえらい人がどのだけいるのかはまあまあ疑わしい。ただ荒い粒度ではわかっているのではないか：つまり、移管を通じてその製品・ソフトウェアがよくなりはしないとわかってはいる、と思う。
ではなぜ移管するのか。
１つ目の移管の動機、つまりテコ入れ型の移管では、それまでの開発チームを、たとえば買収などで連れてきた「頼れそうなチーム」で置き換える。この時、えらい人は従来の開発チームの成果に満足していない。「頼れるチーム」にはやり直しが期待されている。だから従来チームからの知識の継承などは求められていない。
２つ目の移管の動機、つまりコストカットにおいても、やはり従来の開発チームの成果は評価されていない。えらい人は、移管の対象となったソフトウェアは十分な価値を生み出しておらず、かつ生み出せる見込みもないと考えている。見込みはないが、顧客の存在やシステム内での依存関係など様々な事情で捨ててしまうこともできないので、オフショアとかで安く上げようとする。壊れなければいいとしか思っていないから、チームに溜まった知見を活かす気もない。
コミュニケーション強者たるえらい人たちがこうした評価を表立って口にすることはまずない。けれどこれらの説明がフィットしない移管も思い当たらない。
現実に移管、特にコストカットバージョンの移管を目の当たりにしたとき、湧き上がる腹立ちや悲しみを抑えるのは難しい。えらい人は間違っていると言いたくなる。ただ上のような理由から「間違っている」は筋違いと思うようになった。
コストカットの対象になったとき、そのソフトウェアは期待値を満たせていない。雑にいうと「負けている」あるいはより穏当に「役割を終えている」。負けを認めるのは難しいし、負けるのは悲しい。終わってしまうのも同じく悲しい。そしてえらい人は負け戦の指揮者である。綺麗事を言わず、まず負けや終わりを認めてほしい。腹立ちは負けを認めない不誠実さに向けるといい。あるいは負けていないにせよ期待値を満たせていないのだとしたら、その期待値をセットしたのもやはりえらい人である。その見通しの甘さも責められていい。あるいは、もしまだ勝ち目があると思うのなら、えらい人の根性の無さを責めてもいい。でも移管のコストをわかっていないと責めるのは、なんというか、煙に巻かれている。
移管の悲しみは敗北と終わりの悲しみだ。その事実から目を逸らすと悲しみを癒せず傷が膿んでしまう。まずは悲しみを弔うといい。