TPM / Technical Program Manager という職種がある。以前 Rebuild.fm では "JIRA 職人" として紹介されていた気がする。検索すると各社の求人が見つかるので、そこそこ広く知られた職種らしい。ただ Manager というくらいでそれほど数はいない、ちょっとめずらしめの仕事。最近、そんな TPM と仕事をする機会が続いた。

メタバグ管理

TPM の主要な仕事の一つは、組織のプロセスがきちんと機能する状態を保つこと。プロセスというと身構えがちだけれど、組織の規模がある程度より大きいと、良いプロセスは助けになる。だからプロセスがあるのはいい。一方で下手なプロセスが官僚化に繋がるのも事実だ。TPM にはうまいさじ加減で組織を回す期待がある。

あるとき自分のいるクライアントチームの週例ミーティングにあたらしい TPM がやってきた。サーバ、クライアントからアナリティクスまでを横断的に見る立場だという。しばらくは特にしゃべる事もなくミーティングに参加していたそのひと ... R 氏と呼んでおく... は、数ヶ月後のミーティングでこう切り出した。「バグトラッカーの使い方について提案があるんですけど、聞いてもらえますか」

恥ずかしい話なので詳しくは書かないけれど、それまでチームのバグトラッカーはいまいち機能していなかった。優先度の定義が人によってまちまちだったりで、次のリリースまでの積み残し作業、次になにをすべきかがバグトラッカーからよくわからない。うんざり。トラッカーが仕事の管理に使えないフラストレーションはありつつも既存の担当バグも仕事の締め切りもない自分はすごく困りもせず、適当にやりすごしていた。ただこの環境で締め切りつきの仕事をするのはやだな、とは思った。チームの他の人々がどうしていたのかはわからない。

自分はこの乱れを自社製バグトラッカーの不出来からくる症状だと思っていた。いろいろな機能が足りていない一方で、たとえば優先度をつけるパラメタに P (priority) と S(severity) の二つがある。P/S スタイルのバグ管理ツールはとうに滅びていたと思っていた自分は、これをダメなツールの指標とみなしていた。

「多くのチームはこんなかんじの方針でやってます」そう言って R 氏は短いドキュメントを回覧した。極めてまともな内容。たとえばその文書は S(severity)欄を使わないよう勧めている。紛らわしいから。全体として自分は諸手を挙げ歓迎したい提案だった。ところがチームの一部からはいくつか懸念の声が上がった - どんなプロセスにも支持者はいる。そんななか R 氏はバグトラッカー相手に SQL を書いて集めたデータをもとに反対する人々を懐柔説得し、元の提案もフィードバックをうけ手直ししつつ、プロセスの書き換えに成功したのだった。

使い物にならないと思っていた内製バグトラッカーも、その新しいプロセスなら思ったより使える。悪いのはツールじゃなかった! この発見は relieving だった。ストレスが減り、仕事のやる気が 15% くらい改善した。元反対勢の手前ミーティングでは黙っていたけれど、休憩室ですれ違った R  氏に感謝の気持ちを伝えた。

インテグレーション

また別のあるときのこと。自分はとあるインテグレーション仕事を引き受けた。全社的に使われている便利ライブラリを自分のアプリに組み込む小さなプロジェクト。クライアントサイドのコード書き自体は簡単に終わったものの、たとえばインテグレーションの方法を近隣製品と一本化したいだとか、サーバサイドのデータフローも全社的に使われているパイプラインに便乗しつつ製品単体としてのカスタマイズもしたいとか、全体としては話をつける相手が多く面倒な仕事であることがあとからわかった。

インテグレート担当者ミーティング、のようなものに呼ばれたので顔を出してみると、司会は件の R 氏だった。そのほかの参加者は近隣製品アプリやサーバサイドパイプライン、および共通ライブラリの担当者。自分の製品は特にカスタマイズが必要なくパイプラインも他人任せのため作業はすぐに終わったものの、他の人々は辻褄合わせで苦労していた。

自分からみると、このインテグレーションは全力で妥協しつつさっさと済ます類の仕事だった。でも一部の参加者は独自のこだわりを発揮し、ミーティングのたびに終わらない議論を繰り広げていた - そういう人はどこにでもいるのだよね。R 氏はそのたび適当に割り込んで結論をだしミーティングを切り上げ、その後は議事録の AI フォローアップなどをしつつプロジェクトを進めていた。最終的に何らかの結論は出たが、これ R 氏が仕切ってなかったらそもそも話し合いにならなかったのでは・・・。そんな気配がうかがえた。さっさと済ました自分の実装もちゃぶ台返しをされそうな場面が何度かあった。けれど R 氏が適当にかわしてくれたおかげで余計な仕事をせずに済んだ。

官僚化しない世界の官僚

エンジニアリングプロセスの立て直しや組織横断的な技術仕事の調整。上に書いた二つのシナリオは TPM の仕事をうまく捉えていると思う。この記事で説明されている Facebook の TPM も、大まかには同じような仕事と読める。こういう仕事をできるともしたいとも思わないけれど、たしかに何らかの役割は果たしている。というか、上の二つの場面ではだいぶ助かった。

自分の勤務先は、たぶん規模の割に官僚化してない。でもそれは必ずしも効率的というわけでなく、無秩序ゆえの非効率があちこちにある。そんな組織で歯車のあちこちに秩序の油を差して回るのが TPM なのだろう。良い意味で官僚っぽいとも言える。もっとシステマティックな、官僚的な、あるいは効率的な組織での TPM はまた違った働きをするのかもしれない。あるいはそもそも TPM が必要ない組織やチームもある。自分が以前いたチームにも TPM はいなかった。でも今の部署にはいた方が良さそうだとは思うに至った。

これって管理職/上司の仕事じゃないの？そういう指摘はありうるし、そんな会社も多かろう。実際 R 氏も前職では Engineering Manager をしていたという。TPM は「上司」という伝統的な役割を Team Lead や Engineering Manager といった複数の職種に分解するテック企業らしい手口のひとつと言えるのかもしれない。仕事の細分化が良いとは必ずしも思わないけれど、過剰な権力を備えがちな「上司」業を modularize するのは嫌いじゃない。TPM はあまり権力を持っていない。だから頭ごなしに意思決定はできず、関係者を説得しないといけない。このくらいがよさそうじゃん。

おまけ

雑談中に R 氏が漏らした一言 -「前の会社では JIRA という freaking good なバグトラッカーを使っていたのに、ここにはそれがなくて最初はどうしようかと思ったよ」...なお社内のバグトラッカーは Dremel から叩けるので、できる (T)PM はバグトラッカーの機能不足をDremel 用のダッシュボードで補っている...という噂。