言うまでもなく現代はプロジェクト・エコノミーであり、仕事≒プロジェクトです。私達エンジニアも例外ではなく、ほぼ必ず何らかのプロジェクトにジョインする形となるでしょう。
プロジェクトというあり方には限界があります。まず 横断的に立ち回れません。自分が属するプロジェクトに関することしかできないからです。当然ながらプロジェクト外の支援もしづらくなります。プロジェクトは、実は階層的組織よりも強いサイロになっていることがあります。
もう一つ、プロジェクトは人を選びますので人材コストがかかります。具体的には、
などです。
このとおり、プロジェクトは実は万能ではありません。新しいあり方が必要でしょう。
トランスジェクト（Transject） とは、プロジェクトに変わるあり方です。
プロジェクトは Pro- のとおり、前に進めるために管理と集中に徹していますが、トランスジェクトは違います。トランスジェクトは Trans- の接頭辞のとおり、越境を前提としています。特定のプロジェクトにジョインすることはなく、全社員を幅広く支援します。
DevEx や DevRel など、社内の開発者を顧客とみなして真摯に取り組む例が増えてきましたが、このようなものを一般化したものだと考えてください。現在のところ、DevEx や DevRel もプロジェクトベースで遂行されているかと思いますし、たしかにプロジェクトも必要ですが、それだけでは実は不十分です。プロジェクトという制約の強いあり方がそもそも間違っています。
違いを比較していきましょう。
プロジェクトには終わりがあります。トランスジェクトには終わりがありません。トランスジェクト・メンバーは、その都度できることややるべきことを自分で考えて動きます。あるいは要求に応えます。
プロジェクトは本質的にウォーターフォールであり、計画をつくってそのとおりに動きます。破ってはならない締切が事実上存在することも多いです。しかし トランスジェクトには計画も締切もありません。もちろん、羅針盤や説明責任のためにラフなものをつくることはありますが、絶対ではありません。
プロジェクトは通常、特定の成果物を保証します。これは契約として定められ、破ると組織として大きなダメージを負います。だからこそ破らないためにはデスマーチすら厭わなくなります。一方、トランスジェクトでは成果物は保証はしません。
変動とはリソースの話です。プロジェクトでは予算、人員、期間といった予算は変動しません。一度決めたリソースを使い切ります。あとで追加投入したり、逆に削ったりすることもありますが、例外的です。ウォーターフォールのようなものですね。
逆に トランスジェクトでは変動します。トランスジェクトではミニマムリソース（許容可能な最低限のコスト）を割り当てて、その間は好き勝手に動いてもらいます。足りなくなれば足します。まるで API の従量課金やクレジット補充のようです。
トランスジェクトを一言でいうと、アジャイルです。
アジャイルを取り入れたプロジェクトは数多いでしょうが、実は プロジェクト自体が本質的にウォーターフォール的 なので、さしてアジャイルになりません。真にアジャイルにしたいなら、プロジェクトというあり方そのものを変える必要があります。
それがトランスジェクトです。前の vs の項で比較したように、プロジェクトがいかにウォーターフォール的であるかはおわかりいただけましたよね。その対抗として、トランスジェクトがいかにアジャイルにつくられているかもおわかりいただけたはずです。ここまでしなければならないのです。
プロジェクトは Work and Busy と言えます。忙しく働くことが要求されます。なぜならプロジェクトは前に進めるものであり、前に進むことが正義だからです。
トランスジェクトは、この理から外れます。Play and Slack です。余裕を持って遊びます。
プロジェクト・メンバーは、前に進むことだけ考えればいい。それ以外をトランスジェクト・メンバーがやります。
プロジェクトは必要です。ビジネスですから、ストイックに前に進むことにはこだわらねばなりませんし、この大変な作業は誰かが負わねばなりません。
ですが、それだけでは足りない。プロジェクト・メンバー達の取りこぼしを回収したり、彼らを鍛えたり楽しませたり悟らせたり、そもそも組織のために中長期的な取り組みをしたりといったことも必要です。またプロジェクト・メンバーに向いてない人材もいて、このような人材を排除していては人材コストも高くつきます。だからトランスジェクトです。
トランスジェクトが広く後方で支援する。プロジェクトは狭く前線で戦う。役割分担なのです。
トランスジェクトとしての具体的な役割は、必要に応じて自由につくってください。プロジェクトにおける役割ほど固定的ではありません。何なら役割名がなくてもいいです（そのうち見えてきます）。
いくつか例を示します。
Internal Evangelist とは、社内での発信や啓蒙を務める役割です。テーマはエバンジェリストによって違います。私の場合、ソフトスキルになるでしょう。あるいはもっと狭く「タスク管理」「クリエイティブ・シンキング」「非同期ワーク」でも立ち回れます。
具体的な活動は三つあります。
あくまでエバンジェリストなので、特定の仕事は負いません。伝えるところまでやります。
Glue Work Engineer とは、その名のとおり Glue Work に専念するエンジニアです。プロジェクト・メンバーではなく、トランスジェクト・メンバーとして様々なプロジェクトに出入りします。
かんたんに見えますが、テクニカルな理解とドメインの理解、そしてもちろんプロジェクトに入り込んでコミュニケーションを取る必要もあります。向き不向きが明確に分かれるほどの、難しくてやりがいのある仕事です。
注意点として、トランスジェクトなので具体的な責任は負わないことに注意してください。つまり Glue Work Engineer が何かをこなせなかったとしても、それはそのエンジニアの責任ではない。この原則を忘れないでください。トランスジェクト・メンバーであるからこそ、Glue Work Engineer は融通を利かせた立ち回りができます。プロジェクトのように縛っては意味がありません。
私が何度か伝えている役割で、ソフトスキルに関して越境的に立ち回ります。
活動は以下二つです。
2: については、たとえば「形骸化しないナレッジ・マネジメント」の仕組みを考えてほしいとか、メンバーともっと深く関係を築ける手軽な 1on1 の手法を開発してほしいといったものです。最適なソフトスキルや概念を提示、もしくは開発します。
Transtester とは、越境的なテスターを指します。「～～を試してほしい」といったテスト的な要望にひたすら応える役割です。Q&A エンジニアやデバッガーほどプロジェクトに入りこまず、もっとカジュアルに応えます。
プロジェクト・メンバーから見ると、「ちょっと誰かに試してほしい」「部外者の意見を聞きたい」といった場合に重宝します。あるいはアンケートやヒアリングを伴うような仕事を行う人達が頼る先でもあります。
社内には Transtester のプールがあり、プールに対して依頼をすると、中の Transtester たちが答えてくれるというイメージです。もちろん Transtester 個人に直接依頼しても構いません。
こう書くと、Transtester は「サブの」役割に思われがちですが、意外とそうでもありません。引っ張りだこなので、実は専任か、少なくともメインとして据えた方がいいでしょう。
一言で言えば、プロジェクトのあり方ではこぼれ落ちていたことを回収できます。
例:
ですので無尽蔵に増やすわけにはいきません。目安としては、トランスジェクトとして働ける何らかの強み（とできれば熱意）があることです。
また、契機としては「プロジェクト・メンバーとしては合わない」「代わりの役割が欲しい」が多いと思います。従来、このような状況だと別のプロジェクトに回されていたか、最悪クビにしていましたが、この記事を読んだ皆さんには選択肢が一つ追加されました。トランスジェクトメンバーを検討してください！
見ての通り、トランスジェクトは 全社員を 相手にします。たとえば全社員が読むブログ記事を持続的に更新したり、全社員から問い合わせが来ることを想定したりといった立ち回りは当たり前に行えないといけません。これは思っているよりも難しいことです。
また、vs の項でも述べたとおり、計画や管理も無いので、自律的に動けないといけません。サボっていないことを示すためにはアウトプットも向上的にやらねばなりません。そういう意味でも適性が分かれます。