Content last updated 2026-05-22

ペルソナ

ロールとペルソナの違い

ペルソナは GitLab にとっての理想的なターゲットを表します。メッセージングやマーケティングの提供方法を定義するのに役立ちます。彼らはターゲットとする理論上の人物です。彼らの関心事や情報の収集先を定義することで、この理想的なターゲットに焦点を当てて、マーケティング費用とセールスの取り組みを最適に投じることができます。

ロールは個別の役職です。これらは、セールスの過程で実際に出会う人々です。アカウントの中で特定のロールを持つ連絡先を見つけることになります。IT における各ロールが直面する課題と、彼らが最も関心を持っているものを理解することは、適切な人に適切な価値提案を届けるのに役立ちます。

ペルソナ

ペルソナは、コミュニケーションし設計するターゲットとなる理想像について語る一般化された方法です。メッセージングやマーケティング提供だけでなく、製品の定義にも役立ちます。ペルソナを念頭に置くことで、適切な言葉を使い、彼らの特定の問題や苦痛点に対処するための最善の決定を下すことができます。GitLab には購入者とユーザーの両方のペルソナタイプがあります。

購入者ペルソナ

私たちは、この Buyer Persona ページで購入者ペルソナへの更新をイテレーションしています。

ユーザーペルソナ

ユーザーペルソナは、実際に GitLab を使う人々です。彼らは組織内で GitLab を購入する権限と予算を持つ人物である場合もそうでない場合もありますが、購入プロセスにおいて強い影響力を持つ人々です。ユーザーペルソナは UX リサーチの研究から収集されたデータから作成されます。新しいユーザーペルソナが必要な場合、または既存のペルソナを更新する必要がある場合は、ユーザーペルソナの作成方法に関するハンドブックガイドを参照してください。

ユーザーペルソナはどのように相互作用するか?

ユーザーペルソナはしばしば個別の人物ですが、複数のペルソナがどのように相互作用するかを理解することは、個別のペルソナのワークフローやモチベーションを理解することと同じくらい重要です。その結果、次のことも考慮します。

組織アーキタイプ
ペルソナ構成

組織アーキタイプ

組織アーキタイプは、組織がどのようにソフトウェア開発プロセスとチームを構造化しているかを記述します。共通の構造と、それらの構造内のペルソナが経験する結果として生じる相互作用のタイプを理解するのに役立ちます。

私たちは、リサーチが進むにつれて共通の組織アーキタイプの記述を構築し、これらの新しい組織アーキタイプに適合する新しいペルソナを導入していきます。

ある組織アーキタイプのペルソナが、別の組織アーキタイプの1つまたは複数のペルソナと類似した jobs-to-be-done やその他の特性を持つことが起こり得ます。これらすべてを記述することで、見過ごされる可能性のある違いを理解し、製品開発の過程でより焦点化された決定を行うのに役立ちます。GitLab が対応する組織アーキタイプについて詳しくはこちらをご覧ください。

ユーザーペルソナのリスト

私たちは以下のペルソナを、彼らが行う仕事、モチベーション、フラストレーションの観点から記述します。このレンズを通じてユーザーを理解することは、彼らのワークフローをサポートする製品に貢献するのに役立ちます。

ステージを横断するユーザーペルソナ

私たちのペルソナはステージを横断しています（ユーザーペルソナがステージ間でどのようにマッピングされるかの描写については、以下の表を参照してください）。ペルソナがステージを横断してどのようにマッピングされるかを理解することは、彼らのニーズをサポートするためにクロスファンクショナルにコラボレーションする方法を理解するのに役立ちます。

注: 上記の表を変更するには、チームメンバーは Google スライドデッキを編集できます。

ユースケース別ユーザーペルソナ

注: 上記の表を変更するには、チームメンバーは Google スライドデッキを編集できます。

Parker (Product Manager)

代替の役職: Program Manager、Project Manager、Technical Product Manager、Head of Product

職務概要

プロダクト開発の多面的な側面の中心で、私は戦略的なビジョンを形作り、それを実行可能な計画に変換し、製品がユーザーニーズを満たし真の価値を提供することを確実にする責任を負っています。私の役割は戦術的な責任を超えますが、成功裏な実行を駆動する日々のタスクの管理の重要な性質を認識しています。それらが私の役割で最もお気に入りの部分ではないかもしれないとしてもです。私は強い関係を築き、チームを共通のゴールに向けて整合させ、ステークホルダーが成功するプロダクト開発のためのビジョンに賛同するよう努めます。私のツールキットには、データ駆動の決定、市場認識、効果的なコミュニケーション、明確な戦略的ビジョンが含まれている必要があります。

モチベーション

複雑な問題の解決とユーザー価値の提供: 困難な問題に正面から取り組むことに、私は深い満足とモチベーションを見出します。ユーザーニーズを満たし、真の価値を生み出す革新的なソリューションを開発する機会から、私の駆動力が生まれます。それはより豊かなユーザー体験に結実し、ユーザーの日常生活に積極的な影響をもたらしながら、組織の価値とレベニューを増大させます。
コンセプトからローンチまで製品を導く: コンセプトからローンチまで製品を導くプロセスは、私を興奮させモチベーションを与えます。アイデアが完全に実現された製品へと進化する過程に参加し、課題をナビゲートし、開発を導き、ユーザーへの影響を観察することに満足を感じます。
変化への適応と整合の実現: 変動する企業目標に適応し、チームと効果的なコミュニケーションを維持できたとき、私は誇りを感じます。私は常にチーム間で整合を実現するよう努めており、それが野心的な目標を達成し、共にイノベーションする能力を駆動することを知っているからです。

フラストレーション

「プロダクト」ではなく「プロジェクト」管理の役割に陥ること: プロダクトマネージャーとしての動的で戦略的な責任ではなく、主にプロジェクトマネージャーとしてタスクとタイムラインの追跡に焦点を当てていることに気づくと、モチベーションが下がります。これは、顧客ニーズへの対処、効果的な市場戦略の立案、明確なプロダクトビジョンの維持を妨げ、私の仕事の満足度を駆動するものです。
時間、開発能力、最終的にはお金の無駄遣い: 牽引力を得られなかったり、ユーザーニーズを満たさなかったりする製品への取り組みやリソースの無駄遣いは、心が痛みます。明確な目的を欠いていたり、意味のあるユーザー価値や全体的な製品の成功がほとんどなかったりするソリューションに投資するとき、フラストレーションを感じます。
プロジェクト状況に迅速にアクセスできないこと: 作業の状況を把握するのが難しく、状況を追いかけることに時間を費やすことを強いられるとフラストレーションを感じることがあります。プロジェクトの状況、特に軌道から外れているときの状況をタイムリーに把握することは、私のロールにとって極めて重要です。なぜなら、コミットメントを満たせない場合に、納品に投資している人々にそれを知らせる必要があるからです。
プロダクトビジョンと能力のバランス: 私は常に、プロダクトビジョンを実行するためのチームの能力を最大限活用しようとしています。市場に説得力のある価値を提供する能力を最大化するために、次に何をすべきかについて正しい決定を行うことを保証するのは、難しいジャグリングです。
予測不可能な期間、機能の遅延、優先順位の見直し: 開発サイクルは予測不可能で、変化は避けられないため、機能の提供についてクライアントやステークホルダーに合理的なタイムフレームを提供するよう求められると、フラストレーションを感じます。

Delaney (Development Team Lead)

代替の役職: Technical Manager、Software Engineering Team Lead、Technical Team Lead、Software Development Director、Development Lead、Head of Development

職務概要

私はプロダクトマネジメントチームと会って機能について議論し、スケジューリングし、コンセプトを実用的なソリューションに変換する責任を負っています。私はキャパシティが適切に見積もられていることを確認し、プログラム仕様を作成し、よくジュニア開発者をメンタリングします。

モチベーション

機能リクエストについて議論するとき、私は製品とデザインチームから明確な要件を受け取り、私のチームが時間通りに納品し、コミュニケーションの往復を減らせるようにしたい。
チームのリソースを評価するとき、私のチームの開発者がキャパシティをどれほど正確に見積もってきたかの履歴を見て、適切なタスクに彼らをアサインできるようにしたい。
重要な期限が近づいているとき、すべてのチームメンバーが私たちのツールを確実に更新し、他のコミュニケーションチャネルで関連情報を探すことなく進捗を追跡できるようにしたい。

フラストレーション

自分たちの担当業務を進めながら、合理的なタイムフレーム内で徹底的なコードレビューをするのは、チームにとって難しいことがあります。
需要が現在のキャパシティを超えると、急いだ仕事から新たな問題を生み出さずに問題を解決することがストレスになります。
開発プロセスに関わっていないステークホルダーに技術的な制限を説明するベストな方法を、私は常に把握しているわけではありません。

Presley (Product Designer)

代替の役職: UX Designer、Interaction Designer、UI/UX Designer、UI Designer、Experience Designer

職務概要

私のゴールは、製品のミッションを効果的で共感的で効率的なユーザー体験に翻訳することです。ユーザーニーズと製品要件を理解し、ユーザーインターフェイスを形作るのに必要なグラフィック要素とコンポーネントを概念化し設計する責任を負っています。UX リサーチやマーケティングなど他のステークホルダーと働くことに加え、主にプロダクトマネージャーと開発者とコラボレーションします。

モチベーション

成果物が要求されたとき、デザインプロセス全体を通じて頼りにできる、明確で最新の要件を持ちたい。
他のデザイナーとコラボレーションするとき、誰がファイルを編集したか確認でき、変更が意図的に行われたかどうかを確認できるようにしたい。
ステークホルダーに成果物をプレゼンするとき、さまざまなツールで一連のファイルを編集することなくデザインを更新できるようにしたい。
開発者が私のデザインを実装しているとき、本番にライブで反映される変更を簡単に追跡し、必要な修正を彼らに知らせられるようにしたい。

フラストレーション

あるツールでファイルを作成し、ファイルをエクスポートし、別のツールでプロトタイプを作成し、別のツールを使って開発者にデザインを渡すことが、フラストレーションです。
イテレーティブなフィードバックプロセスを実行するとき、ステークホルダーが最新のデザインを見ているかを確実にするのは難しいことがあります。
私の会社にデザインの価値をステークホルダーに証明する定義された方法がないとき、より多くのリソースにアクセスするのは難しいことがあります。

Sasha (Software Developer)

代替の役職: Software Engineer、Application Developer、Digital Solutions Developer、Consultant、Database Developer、Mobile Developer

職務概要

私は時間の大部分を計画された開発タスクの完了に費やしており、約30〜40%の時間がミーティング、次のスプリントの計画、バグやカスタマーリクエストの発生に応じた修正に費やされます。私は Issue ベースで作業し、チームと定期的なスタンドアップを行っています。

モチベーション

仕事を計画しているとき、ステークホルダー間のコミュニケーションを改善し、彼らが本当に必要としていて使うものを提供したい。
オンコール中、システムの一部の専門家になりたい。それで、自分がチームの貴重な一員であることがわかる。
多くの開発者とコラボレーションするとき、全員の変更の記録を見て、ミスを特定し、巻き戻せるようにしたい。
チームメイトとペアリングするとき、新しいツールやスキルを学び、キャリアの中で成長し続けたい。
変更を行うとき、組織のソフトウェアの完全性が損なわれないように、セキュアでパフォーマンスの高いコードを提供したい。

フラストレーション

プロジェクトで作業が既に始まった後に要件が変わるとフラストレーションを感じます。
仕事の見積もりが不正確だとフラストレーションを感じます。ストレスを引き起こし、他の仕事のために計画された時間を食いつぶすからです。
脆弱なコードに遭遇し、簡単な修正で済むはずのものが多くのやり直しを必要とするとフラストレーションを感じます。
タスクに想定より時間がかかることで、他人の仕事をブロックしている、または判断されているのではないかと懸念します。

Priyanka (Platform Engineer)

代替の役職: DevOps Engineer、Operations Engineer、Systems Engineer、IT Consultant

職務概要

私の仕事は、開発者がビジネスコードのみに集中できるようにすることです。私のゴールを達成するため、開発チームが使用するパイプライン定義、デプロイテンプレート、CLI ツールを書き、ソフトウェア提供プロセスが組織全体で効率化されるようにします。これらの機能の構築と潜在的なバグの修正に加え、パイプラインやターゲットインフラストラクチャに関連するトピックについて開発チームを教育・サポートし、彼らができるだけ効率的にビルド、デプロイ、リリースできるようにします。

組織や開発チームのニーズに応じて、私は中央のプラットフォームチームの一員、またはアプリケーション開発チームのメンバーです。

モチベーション

開発者が私のサポートを必要とするプロジェクトを計画しているとき、不要な反応的な仕事を避けるために通知を受けたい。
問題を解決するとき、組織での自分の存在感を高めるために、影響やその他の重要な成功指標を追跡できるようにしたい。
開発者向けのソリューションを作成するとき、それが使われていることを確認したい。私の貢献が信頼でき価値があることがわかる。
新しい/斬新な課題に直面しているとき、マニュアルのない問題を解決する満足感を得るため、チームメイトとホワイトボードで議論したい。
新しいプロセスやツールを推進しているとき、客観的な何かでケースをサポートするために、メトリクスやテストを指し示せるようにしたい。

フラストレーション

現在のプロアクティブなタスクに時間を投資することで将来節約できる時間を、定量化し他人を説得することは難しいです。
コミュニケーション不足によって引き起こされる、避けられた危機が私の仕事を脱線させ、リソースを使い果たすことにフラストレーションを感じます。
仕事で多くの帽子をかぶる必要があるため、頻繁なコンテキストスイッチや、自分が得意でないと感じるタスクの責任を負うことが嫌いです。
私の推奨を採用するよう人々を説得する政治にフラストレーションを感じます。

Janell (Enablement Advocate)

代替の役職: DevOps Evangelist、Developer Productivity Engineer、Developer Advocate

職務概要

私の仕事は、現代の DevOps プラクティスの学習曲線を駆け上がる開発者を支援することです。それが必須でない場合の採用も含みます。これには、新しい作業管理、新しいツール、アプリケーションのクラウドへのモダナイゼーションのナビゲートが含まれる可能性があります。私のゴールを達成するため、開発者が依存関係として直接消費できる自動化コードと、新しいプロジェクトが良いスタートを切れるようにスキャフォールディングテンプレートを書き、メンテナンスします。CI/CD 自動化に加え、これにはしばしばクラウドデプロイ、kubernetes マニフェスト、モダンなアプリケーションプラクティスへのチームの移行に対する全体的なアプローチのためのその他の関連部分のサポートが含まれます。この技術的な仕事には、開発者向けの使いやすい「サービス」として企業固有のものを公開することがしばしば含まれます。たとえば、当社全体の Configuration Management Database（CMDB）にアプリケーションを登録するなどです。

私の仕事には、開発チームが新しいアセットや新しい働き方を活用するよう積極的に擁護し啓蒙することも含まれます。これには、私の仕事を製品やサービスのように扱うことが含まれます。安定して管理し、バグを修正し、機能リクエストを受け取り、リリース情報を作成し促進することです。また、ワークショップ、コミュニティオブプラクティスの管理、ピア Q&A プラットフォームの作成も含まれます。

私のマネージャーは、開発者の生産性とイネーブルメントを強い焦点としており、私たちの取り組みが次世代のアプリケーションフレームワークへのオンボーディングをどのように加速するか、そして私たちのイネーブルメントを採用するチームの長期的な生産性向上とビジネス価値の創出にどのように貢献するかに非常に興味を持っています。

私の仕事には、モダンなアプリケーションや DevOps プラクティスや技術の採用を阻害する可能性のあるテクノロジーだけでなく、プロセスや文化に影響を与えることも含まれます。

開発者のイネーブルメントは、開発者の効率的なオンボーディングにおいて非常に重要な役割を果たすため、私は一般的にツール選択に強いインプットを持ちます。なぜなら、それを拡張できる能力をスクリーニングしているからです。

組織や開発チームのニーズに応じて、私は中央のイネーブルメントチームの一員、またはチームの仕事のスコープが十分に大きい場合にはアプリケーション開発チームのメンバーです。

モチベーション

開発者向けに構築するとき、幅広い働き方に対応する必要があります。私たちの組織は、全員を単一のイネーブルメントアセットに乗せようとするには多様すぎます。
開発者向けに依存関係を構築するとき、私はコードを安全に拡張し修正できるよう、開発者がそれらにバージョンロックできる必要があります。本番デプロイで問題を引き起こさないためです。
新しいバージョンや全く新しい機能をリリースするとき、開発者がそれを発見できる必要があります。メールキャンペーンを維持していますが、全員がこの方法で情報を消費すると頼ることはできず、また新人の助けにもなりません。

フラストレーション

私がチームのために意見を持てるすべての DevOps ツール製品の機能に対する認識を維持することは、課題になる可能性があります。これにはすべてのテンプレート機能、すべてのパイプラインセキュリティコントロール、すべてのデプロイ機能が含まれます。
私のチームや開発チームのメンバーが適切なバージョンとバージョン管理の規律を維持しないとき、私が本番問題の原因として非難されることにフラストレーションを感じます。
私たちの DevOps プロセスがツール内でどのように機能するかを説明するためのカスタムトレーニングやその他のイネーブルメントコンテンツを維持する負担にフラストレーションを感じることがあります。
各チームが現在のアプローチに進化したすべての有機的な要素が絶対に必要だと感じているため、特定の新しいパターンに対して標準化されたエンドツーエンドのイネーブルメントを提供することが非常に困難な場合があります。DevOps コードだけでなく、チームプロセスも再考することで簡素化させるのは難しいです。

Sidney (Systems Administrator)

代替の役職: Systems Engineer、Database Administrator、Infrastructure Engineer、Site Availability Engineer、Site Reliability Engineer

職務概要

私はインフラストラクチャと構成をメンテナンスしスケールします。私の優先事項は可能な限り自動化することです。必要なときは、サーバーを構築し、開発者がそこにデプロイするのも手伝います。

モチベーション

同じタスクで複数回助けを求められるとき、時間を節約し将来のミスを避けるために、そのタスクを自動化したい。
オンコール中、真の緊急事態がノイズに埋もれないように、ティアード（段階的）通知を受けたい。
改善をリリースするとき、誰にも気づかれないようにしたい。それで、それがスムーズに進んだことがわかる。

フラストレーション

直面する反応的な仕事の量にフラストレーションを感じます。
オンコール通知を受けるチャネルの数（メール、Skype、SMS、Slack、ポケベル）にフラストレーションを感じます。
正しいプロセスに従わなかった人々からのリクエストで溢れかえるとフラストレーションを感じます。
開発者が私の推奨を実装せず、彼らの予防できる問題を私が修正する責任を負うことにフラストレーションを感じます。

Rachel (Release Manager)

Jobs to be done

本番へのデプロイを調整する責任を負っています。パイプラインの最後のボタンを押します。つまり、ロードバランサーを最新のデプロイメントを指すように変更することです。
提供のスコープとタスクを定義してリリースを調整します。
リリースに関する外部コミュニケーション、特に変更履歴やリリースノートの作成を担当しています。
必要に応じて、リリースをサポートする可能性のあるすべての人を集めるためのレスポンスルームを組織します。

モチベーション

スムーズなデプロイメントを望んでいます。
本番に移行する前の最後のことなので、パイプライン内のすべてが機能することを確認したいです。本番にあってはならないものを出荷すると、それは破滅的なものになる可能性があります。
CI/CD パイプラインが正常に動作するか、必要に応じて問題をキャッチしてくれるたびに、私は安心して眠ることができます。

課題

遅い接続や時代遅れの機器など、古いインフラストラクチャに対処することは、誰もがパイプラインに貢献し管理するために必要なファイルを持つことを確実にするのを難しくする可能性があります。
プロジェクトをサポートする十分な開発者、プロダクトマネージャーなどを確保すること。
UI テストが自動化されていないため、テストプロセスから時間がかかります。
リリースを横断するさまざまなチームを調整することは難しい場合があり、彼らがその役割を果たすべきときに果たすことを確実にするには、多くのフォローアップが必要です。

ツール

GitLab
JIRA（非技術系ユーザーからのチケット用）
Trello（Issue とコミュニケーションの計画用）
Slack（コミュニケーション用）

Simone (Backend Engineer)

私の役割

私は Developer Experience または Infrastructure に組み込まれたバックエンドエンジニアで、他のエンジニアが毎日頼りにするシステムやツールを構築・メンテナンスしています。私の目的は、プロダクトチームが自信を持ってより速く出荷できるようにする 信頼性の高いプラットフォーム基盤と開発者向けツールを構築する ことです。私は自分のコードの品質を、設計からデプロイメント、モニタリングまでエンドツーエンドで所有しています。エンジニアリング組織全体のバーを引き上げる CI/CD インフラストラクチャ、開発者アナリティクス、ワークフロー自動化、テストインテリジェンスシステムに貢献しています。

Jobs to be done

開発者向けツールの構築とメンテナンス: 開発者のベロシティを向上させるツールを開発・メンテナンスします。CI/CD の最適化、パイプラインインフラストラクチャ、トリアージ自動化、プロダクトチームが日々頼りにするビルドツールなどです。
品質をエンドツーエンドで所有する: 私が構築するシステムの信頼性と品質を完全に所有し、あらゆるレベルでテストを書き、自分のコードが本番でよくテストされ、オブザーバブルで、パフォーマンスが高いことを確実にします。
チームをまたいだコラボレーション: プロダクトエンジニアリングチームと密接に協力して、彼らのペインポイントを理解し、開発ワークフローの摩擦を減らすソリューションを構築します。
信頼性の高いインフラストラクチャの運用: IaC ツールを使ってインフラストラクチャをプロビジョニング・メンテナンスし、インシデントに対応し、オンコールローテーションに貢献して、プラットフォームの信頼性を確保します。

スキル & 個人特性

システム思考: 変更が複雑な分散システム全体にどのように伝播するかを理解している
オーナーシップ・マインドセット: コードの品質、テスト、本番の信頼性に対して完全な責任を負う
協調的: エンジニアリングチームとの関係を築き、彼らのペインポイントを理解して解決する
技術的: スケーラビリティと信頼性に焦点を当てた強力なコーディングスキルを持つ
好奇心旺盛: 内部システムがどのように機能するかを理解し、それを改善する機会を見つけることを楽しむ
効果的なコミュニケーター: 技術的なトレードオフを、書面でも会話でも明確に説明する

フラストレーション

フィードバックループを遅らせる遅い CI パイプライン
不安定で信頼性の低いテストインフラストラクチャ
システムの動作に対するオブザーバビリティの欠如
ツールのイテレーションを困難にする技術的負債
インシデントと計画された作業の間のコンテキストスイッチング

キーツール

トラッキング、ドキュメンテーション: GitLab Issues、GitLab Merge Requests
コミュニケーション: Slack、Zoom、GitLab Issues
リアルタイムドキュメンテーション: Google Docs
ターミナル、コーディング環境: Ruby、Go、およびサポート言語を使った VS Code または RubyMine
インフラストラクチャ: Terraform、Ansible、Kubernetes、GCP、AWS
オブザーバビリティ: Grafana、Kibana、Prometheus

Allison (Application Ops)

代替の役職: DevOps engineer、Lead developer、Site Reliability Engineer

私の役割

私は所有するアプリケーションがそのユーザーに対してアクセス可能でパフォーマンスがあることを確実にする責任を負っています。私は Application Ops の帽子をかぶっていますが、Software Developer の T シャツも着ています。

Jobs to be done

他のチームの行動を必要とせずに、本番および非本番環境に自動的にデプロイできるようにしたい。
「デプロイ」が何を意味するかを予測可能に理解できるよう、自分で選択したデプロイメントツールを使いたい。
新しいデプロイメントのリスクを最小限に抑えるよう、Platform Engineer の Priyanka が定めた会社のベストプラクティスに従ってデプロイしたい。
所有するアプリケーションのパフォーマンスと健全性について安心できるよう、所有するシステムコンポーネントについて最新のリアルタイム情報を取得したい。
ダウンタイムや劣化が発生する前に行動して回避できるよう、所有するアプリケーションの潜在的な問題について通知を受けたい。
システムを機能的に保つために、誤ったデプロイメントからロールバックまたはロールフォワードしたい。

フラストレーション

監視プラットフォームのコンシューマーとして、アプリのインスツルメンテーションが監視システムでレポートしないとフラストレーションを感じます。
監視システムのエラーの根本原因を特定できないとフラストレーションを感じます。
問題があることを特定するために複数のツールを使用する必要があるとフラストレーションを感じます。
デプロイメントを遅らせるプロセスにフラストレーションを感じます。
監視システムからのデータを信頼できない（偽陰性または偽陽性）とフラストレーションを感じます。

Ingrid (Infrastructure Operator)

代替の役職: Systems Engineer、Database Administrator、Infrastructure Engineer、Site Availability Engineer、Site Reliability Engineer、System Administrator

私の役割

私はアプリケーション開発チームがソフトウェアをより迅速に開発、テスト、出荷、運用するために利用する共有インフラストラクチャを提供、メンテナンス、運用する責任を負っています。

Jobs to be done

新しいインフラストラクチャをセットアップするとき、他者が私の変更をレビューでき、必要に応じてステップを繰り返せるよう、プログラム可能な方法でやりたい。
インフラストラクチャリソースを所有するとき、夜安眠できるよう、セキュリティパッチで最新の状態に保ちたい。
インフラストラクチャリソースを所有するとき、SLA を満たすよう、その目的をうまく果たすことを確実にしたい。
インフラストラクチャリソースを所有するとき、予算内で実行できるよう、コストを意識したい。
開発者をサポートするとき、彼らのプロセスのボトルネックにならないよう、統合ポイントを自動化したい。
オンコール中、真の緊急事態がノイズに埋もれないように、ティアード通知を受けたい。
改善をリリースするとき、誰にも気づかれないようにしたい。それで、それがスムーズに進んだことがわかる。

フラストレーション

直面する反応的な仕事の量にフラストレーションを感じます。
オンコール通知を受けるチャネルの数（メール、Skype、SMS、Slack、ポケベル）にフラストレーションを感じます。
正しいプロセスに従わなかった人々からのリクエストで溢れかえるとフラストレーションを感じます。
開発者が私の推奨を実装せず、彼らの予防できる問題を私が修正する責任を負うことにフラストレーションを感じます。

Dakota (Application Development Director)

職務概要

Dakota は、特定のビジネスアプリケーションをサポートする複数の開発者チームを管理しリードする重要な IT リーダーです。詳細は、購入者ペルソナと Engineering Director Persona リサーチを参照してください。

モチベーション

ビジネス満足度: 一貫した予測可能なビジネス成果を提供すること。
DevOps トランスフォーメーション: DevOps プロセスとツールで新しい価値を生み出すよう組織を変革すること。
チームビルディング: マネージャーを通じてチームを成長させ改善すること。
プロセスエクセレンス: チームがビジネス価値をうまく提供するためのツール、トレーニング、リソースを持つことを確実にすること。

フラストレーション

リアクティブ対プロアクティブ: 緊急の障害、組織の問題、緊急事態が時間とワークロードの管理を困難にします。
コンテキストスイッチ: すべてのプロジェクトとチームでカバーすべき多くのコンテンツがあります。
ビジネスケースの作成: 新しい戦略的イニシアチブとチームのリソースのために予算を確保することは、労働集約的で時間がかかります。

Amy (Application Security Engineer)

代替の役職: Application Security Analyst または Specialist

私の役割

私は、開発者を支援し、セキュアなアーキテクチャを設計し、リスクを積極的に特定し、脆弱性の修正を監督することで、当社が構築するアプリケーションが最初の設計段階から本番までセキュアであることを確実にします。

Jobs to be done

新しい脆弱性のアセスメントをセットアップするとき、脅威が発生するのを防ぐために、特定の脆弱性が組織のアセットに対して表す潜在的な脅威を理解したい。
機能提案またはコード作成者のコードをレビューするとき、ビジネスクリティカルな脆弱性が少なくなるよう、新しいコードが組織のアセットにセキュリティ脆弱性をもたらさないことを確実にしたい。
セキュリティフィックスをレビューするとき、組織がそのセキュリティについて自信を持てるよう、組織のアセットに対する残存する脅威がないことを確認したい。

モチベーション

脆弱性ダッシュボードを監視するとき、仕事をより簡単かつ効率的にできるよう、監視しているすべてを1つのツールで見たい。
プロアクティブであり続けるため、コードがリリースされる前に必要なすべてのセキュリティスキャンを実行することを確実にしたい。
仕事中、キャリアの中で成長できるよう、情報セキュリティの最新情報と教育について最新情報を保ちたい。

フラストレーション

直面する脆弱性の大量さにフラストレーションを感じます。
直面するすべての脆弱性を評価する十分な時間が与えられないことにフラストレーションを感じます。
コード作成者がコード変更のセキュリティに関連する十分なドキュメントやコンテキストを提供しないことにフラストレーションを感じます。

他チームとのコラボレーション

インフラストラクチャセキュリティチーム
開発チーム
コンプライアンス

リソース

関連する UX リサーチの調査結果

Isaac (Infrastructure Security Engineer)

代替の役職: Infrastructure Security Analyst または Specialist

私の役割

私は、セキュリティツールの作成とメンテナンス、本番環境の監視、組織のアセットがセキュリティ要件に準拠していることを確実にするためのセキュリティツールの評価を担当しています。

Jobs to be done

組織が遵守すべき新しいセキュリティポリシーがあるとき、脅威が発生するのを防ぐために、組織のアセットがポリシーに準拠していることを確実にするセキュリティツールを作成したい。
コード作成者のコードをレビューするとき、ビジネスクリティカルな脆弱性が少なくなるよう、新しいコードが組織のアセットにセキュリティ脆弱性をもたらさないことを確実にしたい。
組織のアセットを評価するとき、組織のアセットに非準拠領域がないことを確認したい。

モチベーション

ダッシュボードを監視するとき、仕事をより簡単かつ効率的にできるよう、監視しているすべてを1つのツールで見たい。
本番環境のセキュリティを評価するとき、悪者が先に行うより前に潜在的な脅威や脆弱性を予想できるよう、リアクティブよりプロアクティブでありたい。
プロアクティブにできることをすべて行ったとき、最後の防御層としてリアクティブなツールも有効にし、それらからのデータを調査できるようにしたい。
仕事中、キャリアの中で成長できるよう、情報セキュリティの最新情報と教育について最新情報を保ちたい。

フラストレーション

内部の開発チームが、私が作成しメンテナンスしているセキュリティポリシーやセキュリティツールを回避してセキュリティポリシーに非準拠であるとフラストレーションを感じます。
内部の開発チームが、本番環境で検出された新しい脆弱性を修正するためにタイムリーに対応しないとフラストレーションを感じます。
コード作成者がコード変更のセキュリティに関連する十分なドキュメントやコンテキストを提供しないことにフラストレーションを感じます。
開発チームがセキュリティ変更に抵抗するとフラストレーションを感じます。

他チームとのコラボレーション

アプリケーションセキュリティチーム
セキュリティオペレーションチーム
開発チーム
コンプライアンス

リソース

関連する UX リサーチの調査結果

Alex (Security Operations Engineer)

代替の役職: Security Operations Analyst または Specialist

私の役割

私はセキュリティチームの消防士です。私の目的は、悪意のある攻撃を防ぐ ことと、発生したアクティブなリスクを できるだけ迅速に 緩和することです。それを行うために、信頼できるアラート を生成する検出ツールを開発し、Incident Responder として機能するオンコールローテーションに参加します。

「私は何でも屋でなくてはなりません: SecOps が呼び出されると、何についてもありえます。インシデントは、あなたがこれまで対処したことのないものについてである可能性が高いです。空が落ちてくる可能性があり、多くのことが懸かっているので、セキュリティオペレーションの人のロールはかなりストレスが多くなる可能性があります。」

Jobs to be done

インシデント対応の管理: オンコール中、組織のリスクをできるだけ迅速に緩和するため、発生したインシデントに対応し管理する必要があります。
リアルタイムドキュメンテーション: インシデントが展開する中で、後でその情報をランブックの更新や作成、または RCA（根本原因分析）の作成の一部として使えるよう、可能な限り何が起きているかを文書化したい。
検出ツールの構築: オンコールでないとき、組織のセキュリティ態勢を改善するため、検出とアラート機能を強化するツールを構築したい。
短期プロジェクト管理: インシデントが展開する中で、リスクを修正するためにできるだけ迅速に動けるよう、組織を横断する複数の個人にタスクをアサインし、彼らの仕事を調整したい。

スキル & 個人特性

注意を効果的に分割し、新しいアラート、新しいデータ、同僚からの緊急要求などの中断に対処する優れた能力
立った状態で素早く考え、ストレスの多い状況でも冷静を維持することが得意
防御者と同様に攻撃者のように考えることができる
ツールの構築が好き（コーディングスキルを持つ）
プロセスの改善に情熱を持っている
効果的なコミュニケーター: 口頭でも書面でも明確に表現できる
SecOps 作業の多様性を楽しむ
未知の未知の処理に比較的快適に感じる

モチベーション

セキュリティアラートやインシデントのダッシュボードを監視するとき、仕事をより簡単かつ効率的にできるよう、監視しているすべてを1つのツールで見たい。
セキュリティテストするとき、悪者が先に行うより前に潜在的な脅威や脆弱性を予想できるよう、リアクティブよりプロアクティブでありたい。
プロアクティブにできることをすべて行ったとき、最後の防御層としてリアクティブなツールも有効にし、それらからのデータを調査できるようにしたい。
仕事中、キャリアの中で成長できるよう、情報セキュリティの最新情報と教育について最新情報を保ちたい。

フラストレーション

タイムラインの説明をリアルタイムで編集するのは面倒で、後で振り返って行うのは特に難しいです。多くの場合、タイムラインのドキュメンテーションは完成しません。
インシデントを処理するために必要な情報の重要な部分が完全に伝達されていないか、集約や検索を困難にする非構造化な方法で伝達されていることがよくあります。

キーツール

GitLab Issues: トラッキング、ドキュメンテーション
PagerDuty: 開始の起点、ページがそこから送信される
Slack、Zoom、GitLab Issues: コミュニケーション
Google Docs: リアルタイムドキュメンテーション
ターミナル、コーディング環境: 主に Python、一部 Go - ツールの構築および/または実行用
The Hive: セキュリティインシデント管理トラッキングツール
- Cortex - The Hive の一部、簡単な自動化を可能にする
クラウド管理コンソール: インフラストラクチャにアクセスするため
トリアージと緩和のためのさまざまなツール:
- Docker - セキュリティ問題を再現しアプローチをテストするため
- 異なる環境のためのアカウント - テスト用
- ELK スタック - ログを確認するため
- Stackdriver または BigQuery - 長期保存、長期間オープンになっているインシデントに使用

他チームとのコラボレーション

インフラストラクチャ
法務
コンプライアンス、AppSec
サポート
開発チーム
さまざまな SME

Cameron (Compliance Manager)

代替の役職: Compliance Program Manager、Audit Report Analyst、Audit Events Analyst

職務概要

私は、組織のサードパーティソフトウェアの使用が社内ポリシーに準拠していることを確実にする責任を負っています。これには、SDLC、アクセス管理、変更管理、その他多数のポリシーが含まれる可能性があります。私は社内のコンプライアンス、監査、および/またはセキュリティチームと定期的に連携し、組織のコンプライアンスプログラムに必要な情報を提供します。

Jobs to be done

自社が肯定的なコンプライアンス姿勢を維持するのに役立つエビデンス成果物を内部コンプライアンスチームに提供できる必要があります。
組織がコンプライアンスプログラムを管理し、アプリケーションとその使用におけるリスクを緩和できるツールを見つける必要があります。
私たちの主要な職務責任に対する義務を満たしながら、チームが生産的で効率的なままでいられるよう、コンプライアンスのための簡単なプロセスを作成する必要があります。

モチベーション

監査をサポートしているとき、エビデンス収集プロセスに伴う時間と中断を減らせるよう、情報を迅速かつ簡単に利用できる必要があります。
チームとプロジェクトを管理しているとき、会社を責任から保護できるよう、不必要なリスクを導入していないことを知る必要があります。

フラストレーション

監査目的で必要なすべてのデータを見つけ、集約し、レポートすることが難しいためフラストレーションを感じます。
組織のコンプライアンス姿勢について安心感を与える機能がツールにないとフラストレーションを感じます。
内部監査やコンプライアンスチームにとって効率的で価値のあるフォーマットでデータをコンパイルすることは難しいです。
ツールのコンプライアンス姿勢のギャップを特定するたびに、カスタムツールとサービスを構築することは難しいです。

Daphne (Data Scientist)

代替の役職: Data Analyst、Machine Learning Engineer

職務概要

私はデータを収集、前処理、分析して洞察を導き出し、予測モデルを構築します。

Jobs to be done

複数のソースからデータを収集し集めます。
データを分析のためにクリーン、変換、前処理します。
データを探索し分析して洞察を導き出します。
ビジネス問題を解決したり、データ駆動の予測を行ったりするための予測モデルを構築します。
関連性を維持するため、新しいトレーニングデータでモデルを更新します。
モデルをデプロイし、データパイプラインをメンテナンスするため、ML エンジニアとコラボレーションします。

モチベーション

データサイエンティストとして、私の焦点はソフトウェア開発ではなく、データ分析と効果的なモデルの構築にあります。
実用的なソリューションを提供しビジネス価値を駆動するモデルを作成することを目指しています。

フラストレーション

データアクセス
計算リソースの不足
組織におけるデータおよび/または ML/AI リテラシーの不足
効率化されたプロセスと自動化の不足
データガバナンスの不足とポリシー、データオーナーシップ、データスチュワードシップに関する曖昧さ。

Mia (ML Engineer)

代替の役職: MLOps Engineer、ModelOps Engineer

職務概要

私は機械学習モデルを構築、最適化し、本番環境にデプロイする責任を負っています。

Jobs to be done

機械学習モデルを構築、最適化し、実験します。
モデルを本番環境にデプロイし、他のソフトウェアシステムと統合します。
デプロイされたモデルを監視し、パフォーマンスの問題やドリフトを検出します。必要に応じてモデルを再トレーニングし更新します。
スケーラビリティ、パフォーマンス、効率のために ML システムを最適化します。
エンドツーエンドのモデルおよび機械学習ライフサイクルをサポートするためのデータパイプラインとインフラストラクチャを開発しメンテナンスします。
ML ソリューションを提供するため、データサイエンティスト、ソフトウェアエンジニア、その他のステークホルダーと密接に働きます。

モチベーション

スケーラブルで運用可能な ML システムを構築する。
データインサイトを製品に変える。

フラストレーション

自動化と再現性の不足
計算リソースの制限
専門知識と知識共有の不足
MLOps と ModelOps を採用する組織の賛同の不足

内部ペルソナ

内部ペルソナは、GitLab チームメンバーが直面するワークフロー、ニーズ、課題を反映します。これらのペルソナは、内部ユースケースに対応する GitLab グループの仕事をサポートし、影響を与えます。

内部ペルソナのリスト

Eddie (Content Editor)

代替の役職: Content Marketer、Technical Writer

職務概要

私は自社のサイト用のコンテンツを作成、更新、キュレーションする責任を負っています。既存のページへの変更をレビューし提出し、必要に応じて新しいコンテンツを追加するためにページを作成します。

モチベーション

既存のページコンテンツを改善する必要があるとき、コンテンツが一貫性があり最新であることを確実にできるよう、更新が必要な領域を迅速に見つけたい。
新しいページを作成する必要があるとき、適切な場所に変更を提出できるよう、正しいディレクトリを簡単に見つけたい。

フラストレーション

大量のコンテンツがあるサイトを管理する責任があるとき、どのページを更新する必要があるかを知ることは難しいです。
ワークフローで技術的な編集ツールを使うことに慣れていない場合、コンテンツの変更を行うのは怖い場合があります。
特に小さな変更を行うとき、ディレクトリ構造のどこにコンテンツがあるかを把握するのに時間を費やすことはフラストレーションです。
コンテンツを find-and-replace できるツールがないと、ページの一括更新を行うのは難しいです。

Dana (Data Analyst)

代替の役職: Data Analytics Consultant、Business Data Analyst

職務概要

私のゴールは、さまざまなソースからのデータのライフサイクルを深く理解し、まとまりがあり正確な分析を促進する方法でモデル化することです。私は高品質なデータの維持、レポートとダッシュボードの構築、データソースを横断するトレンドの説明に責任を負っています。私は会社を横断するステークホルダーとコラボレーションし、より強い製品と組織を構築できるよう支援する有用な分析と洞察を提供します。

モチベーション

ディレクターが主要なパフォーマンス指標を評価するとき、データから引き出される結論に自信を持てるよう、信頼性のあるデータでダッシュボードを構築したい。
製品チームが機能の価値を測定する必要があるとき、人々が製品とどのように相互作用しているかをより理解できるよう、利用データのパターンについてより詳細とコンテキストを見たい。
重要な会社のイニシアチブが議論されているとき、データ駆動の洞察を使って重要な決定を情報に基づいて行えるよう、クエリ可能なデータを提供し同僚が自分の分析を実行できるよう力を与えたい。
同僚がデータ分析を必要とするプロジェクトに取り組んでいるとき、彼らが洞察をアクションする時間をより多く費やせるよう、クエリを最適化する方法を見つけたい。

フラストレーション

適切に構造化されておらず、結果として品質と信頼性が低いデータを扱うことはフラストレーションになる可能性があります。
同僚が彼らが持っている質問と、データの特定の側面を探りたい理由について明確でないとき、分析にどうアプローチすればよいかを正確に知ることは難しい場合があります。
一貫性のないトラッキングが主要なイベントのコンテキストの欠落をもたらすとき、データの整合性を信頼するのは難しいです。
機能パラメータと使用基準が完全に定義されていないとき、機能利用やユーザー維持に関する大局的な質問に答えるのは難しいです。

組織アーキタイプ

組織アーキタイプとは? 組織アーキタイプは、組織のセットアップの典型的な例です。私たちの場合、組織がどのように GitLab とエンゲージするかに関連する組織アーキタイプに特に関心があります。私たち …

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)

ページのソースコードを見る - ページの編集 - please contribute.