テクニカルプロジェクトマネージャーとは何ですか？

公開: 2022-03-11

テクニカルプロジェクトマネージャー（TPM）とは何ですか？答えは、誰に尋ねるかによって異なります、とベテランのITコンサルタントであり事業運営の専門家であるAndiBlackwellは言います。 Toptalのプロジェクトおよび製品管理のリードディレクターとして、Blackwellは、Toptalのフリーランスネットワークの高度なスキルを持つプロジェクトマネージャーと、特定のイニシアチブで優秀な人材を求めている組織とのマッチングを担当するチームを率いています。近年、彼女はTPMの需要が急増しています。

「その用語が実際に何を意味するのかについて、テクノロジー業界全体で確かにいくつかの議論があります」とブラックウェルは言います。「エンジニアリングチームと非常に緊密に連携したり、プロジェクト管理の観点から技術チームを率いたりしたために、自分たちを技術プロジェクトマネージャーと呼ぶ人はたくさんいますが、それは私たちが求めているものではありません。」

Toptalの定義はより具体的です。 Toptalのネットワークのすべてのプロジェクトマネージャーは、スコーピング、予算編成、タイムラインの管理などの従来のプロジェクト管理スキルのほか、反復配信と継続的な改善に関連するアジャイルソフトウェア開発プラクティスの専門家です。彼らは常にエンジニアと緊密に協力しており、必要に応じてスクラムチームを指導および指導することができます。

ただし、TPMとしての資格を得るには、アジャイルプロセスの管理や開発者とのコラボレーションに加えて、追加の経験層が必要です。彼らは開発者自身である必要があります。

貴重な組み合わせ

大小の組織は、この特定のスキルの組み合わせにますます関心を持っています。「ほとんどのスタートアップは、1つのことしかできない人を雇うことはできません」とブラックウェルは言います。大企業は、エンジニアリングプロジェクトに雇う場合、候補者のプロファイルに「開発者」または「建築家」を見たいと考えています。

クライアントが技術的なバックグラウンドを持つプロジェクトマネージャーを特に必要としない場合でも、「開発者」ボックスをオンにすることが大きなセールスポイントです。ソフトウェアプロジェクトを計画および実行し、アジャイルプロセスを実装および最適化し、コーディングできる人はいますか？それは大きな恩恵です。

ただし、実際には、TPMはコーディングすることを期待されていません。多くの場合、何年もコーディングされていません。では、なぜプログラミングの経験が必要なのでしょうか。

Blackwell氏は、技術的な決定を下すにはTPMが必要です。「最新の技術スタック、SDK（ソフトウェア開発キット）、アーキテクチャ、またはテスト自動化プラットフォームについて、比較的最近の実践的な経験がない場合は、潜在的に正しい決定を下すつもりはありません。以前にそれらを使用したことがないので、クライアントとの信頼関係はありません。」

チームでの作業

見込み客に信頼性を示すことは、エンゲージメントを確保する上で重要な要素ですが、それは最初のハードルにすぎません。 TPMは、プロジェクトに割り当てられると、技術チームの信頼と尊敬をすばやく獲得する必要があります。

Michael Poythressは、10代の頃にプログラミングを始めました。 16歳で、彼は父親と一緒に始めた不動産広告ビジネスのための商業ウェブサイトを構築しました。それ以来、彼は複数のスタートアップのCEO兼創設者です。 2018年に、彼はTPMとしてToptalネットワークに参加し、現在はエンジニアリングチームと緊密に連携しています。「私がコーディングの経験がなければ、プログラマーはそれを理解するでしょう」と彼は言います。「彼らは私と一緒にまっすぐに撃つことはありませんでした。しかし、私が彼らに挑戦し、仲間として彼らと話すのであれば、尊敬と信頼関係があります。」

カリフォルニア州オレンジカウンティに拠点を置くToptalTPMであるAllenTakatsuka氏は、タイトルよりも重要なのはテクノロジーの経験です。彼らは、会議を設定してスプレッドシートに記入するように依頼するのは、別のプロジェクトマネージャーだと考えています。」

ただし、共通の基盤が確立されると、「相互作用のフレーバーは大きく異なります。それはエンジニアリングとのパートナーシップのようなものです」と彼は言います。

高塚は、プロとしての人生の早い段階でエンジニアリングチームを率いて数十年を過ごしました。彼はその経験が彼のソフトスキルをレベルアップしたことを認めています。「それは少し異なる共感スキルです」と彼は言います。「あなたはあなたがその言語を話すことができることを示さなければなりません。「進行中の技術的な事柄に基づいて、なぜこれらの課題があるのかわかります」と言うことができます。

バージニア州ヴィーナの技術コンサルタントであるDanAllenは、彼のキャリアの進歩を「建築家、ディレクター、VP、CTO、CIOへの技術的リードへの仕掛けのプログラマー」と説明しています。 2019年にTPMとしてToptalネットワークに参加して以来、彼は忙しく、14のクライアントエンゲージメントに取り組んできました。

「私はめったにコードを読みません。コードを書くことはほとんどありません」と彼は言います。「しかし、開発者が行き詰まる状況がありました。彼らは私にアーキテクチャを案内してくれ、彼らがやろうとしていることと論理を正確に見ることができます。」

彼は、ダイナミックがエッジケースだけでなく、より広く役立つと考えています。「あなたのチームは彼らがあなたのところに来て話をすることができることを知っています、そしてあなたは彼らが言っていることを本当に理解しています」と彼は言います。「彼らが何かを逃した場合に備えて、あなたは彼らがすべての複雑さを考慮するのを助けることができます。あなたは健全なボードになり、フィードバックを提供することができます。」

乗数効果

この種のフィードバックと洞察は、関係構築以上に重要です。 TPMは、組織に異なる価値提案を提供します。それらは情報の導管としてではなく、知識の源としての役割を果たします。はい、彼らは計画、調整、コミュニケーションを行いますが、クライアントやチームが複雑なテクノロジーの決定を行うのにも役立ちます。

「あなたには技術的に意見を述べる能力があります」と高塚は言います。「これにより、組織化とコラボレーションだけでなく、より多くの乗数効果が得られるため、組織に付加価値がもたらされます。」

高塚氏は、TPMが問題を解決するために必要なフープの数を減らす必要があると述べています。特に大規模な組織では、技術的でないプログラムまたはプロジェクトマネージャーが、関連するプレーヤーと利害関係者を特定し、コンテキストを提供し、情報を集約し、結果を選別して決定を下すことにより、技術的な課題に取り組む場合があります。 TPMは、独自の知識を生かすことができます。

「リスクにはるかに効率的に対処できます」と東京を拠点とするTPMのOanaCihereanは言います。「そして、それらのリスクは非常に多くの場所から発生する可能性があります。彼らはチームからの間違った見積もりから来る可能性があります。つまり、「このコードは、実際には2日なので、作成に1週間もかからないはずです」と言うことができます。したがって、実際にユーザーのブロックを解除できます。あなたは彼らが立ち往生していることを理解したので、それが彼らに5日かかる理由です。あなたはそこにいて、立ち往生しているので、それを知っています。」

バランスを見つける

Cihereanは開発者としてのキャリアを開始しましたが、全体像に関与したいという願望からすぐにプロジェクト管理に移行しました。しかし、それらの役割では、彼女はコーディングを逃したことに気づきました。彼女は、Technical Project Managementは、両方の長所を提供していると述べています。

Poythressも、自分のスイートスポットを見つけたと感じています。「私は、アイデアを持っている先見の明のある人と、それを構築して実現する方法を知っている技術的な才能との間の翻訳者または連絡係です」と彼は言います。「私は両方の言語を流暢に話します。私は「普通の人」を話し、「技術者」を話します。」

ミニCTO

新興企業や中小企業のために働くTPMは、ビジネスとテクノロジーの交差点で特に主要な席を占めています。これらのエンゲージメントでは、TPMがプロジェクトの開始時に最初に参加することがよくあります。次に、製品の実行可能性を評価し、技術的な範囲と要件を定義し、クライアント（場合によってはアイデアの苗を持った単一の創設者）が技術スタックを選択し、サービス提供のためにベンダーを評価し、DevOpsのベストプラクティスを実装するのを支援します。適切なチームを編成します。

高塚氏は、これらの取り組みを「ミニCTO」の役割と考えており、TPMはビジネスと技術の領域を橋渡しして物事を軌道に乗せます。一部のクライアントは、ソフトウェアの開発についてほとんど何も知らない、と彼は言います。アジャイルについて読みました。それ、どうやったら出来るの？"

Poythressは、2つの役割が重複していると見なしており、場合によっては互いに区別がつかないことさえあります。「他家受粉がたくさんあります」と彼は言います。「小規模な組織のCTOは、大規模な組織の上級技術PMの役割に非常に簡単に移行でき、自宅にいるように感じることができます。」

敏捷性の実現

アジャイルの仕組みは、ソフトウェア開発の経験を持つ事実上すべてのプロジェクトマネージャーの操舵室にいますが、技術的な適性を持っている人は、プロセスの管理により微妙な視点をもたらすことができます。

Cihereanは、アジャイル手法が本によって厳密に実装されることは決してないことを発見しました。それらは、チームやプロジェクトの特定のニーズに合わせてカスタマイズ、ブレンド、および適合させる必要があります。

「プロセスとして設計しているものが開発者の作業に干渉せず、実際にそれをより効率的または生産的にすることを確認する必要があります」と彼女は言います。「これは、GitHubワークフローを深く掘り下げて、たとえば、コミットの実行方法、コードのブランチの作成方法、プロセスがワークフローに適合するかどうかを確認することを意味する場合があります。次に、プロセスを修正するか、ワークフローを修正します。」

TPMの専門知識は、製品のバックログや相対的なサイズの見積もりなど、特定のアジャイルアーティファクトやプラクティスにも情報を提供できます。

「技術を理解していれば、バックログにあるものの大まかな複雑さを知っています」と高塚氏は言います。「そうでなければ、あなたが持っているのはこのリストだけであり、1番が2番に比べて大きいTシャツサイズであるかどうかを知るのは難しいでしょう。難しいと思うかもしれませんが、舞台裏が何なのかはよくわかりません。「極端な」TPMは、「チームが参加すると、独自の速度を持つことになりますが、自分でサイズを決めることができます」と彼は言います。

Poythressは、サイズ見積もりの理解をゲージとして使用して、プロジェクトで検討している技術リーダーとエンジニアを評価します。彼が何かを小さな仕事だと思っていても、他の誰かがそれを巨大だと考えている場合、それは危険信号です。私は、「わかりました、まあ、それはよく合いません」のようです。これを本当によく理解していて、単純な機能であるべきものに恐れを感じない人が必要です。」

TPMは、非機能要件についてクライアントを教育するのにも役立ちます。高可用性にどのように対処しますか？災害復旧にどのように対処しますか？「技術的な理解がなければ、どうやってその議論をしているのかわかりません」と高塚は言う。「おそらく、スクラム要件レベルで停止し、技術者が来るまで1日と呼びます。さて、あなたはこの巨大な割れ目を持っています。」