Content last updated 2026-08-27

ユーザーペルソナ

バイヤーペルソナについては、バイヤーペルソナページを参照してください。

ユーザーペルソナは、実際に 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 (Software Engineer in Test)

代替の役職: Software Development Engineer in Test

職務概要

私は品質への強い関心と、それを推進するために必要なスキルを持つ組織のソフトウェアエンジニアです。私の目的は、開発プロセスに品質を組み込むことと、すべてのチームで品質のオーナーシップを推進することです。これを達成するため、テストプロセスと品質レポートを支援するツールを開発します。また、テストピラミッドのあらゆるレベルでテストを書きます。組織のテストを整えて効率的かつ効果的にし、部門全体で品質に対する意識を育てる支援もします。

達成すべきこと（Jobs to be done）

テストフレームワークの開発と保守: 適切なレベルでテストを書きやすくする、よく保守された 1 つ以上のテストフレームワークを組織のエンジニアに提供する必要があります。
品質を促進するツールとレポートの提供: 開発者が品質に関するタスクをより容易に達成し、エンジニアリングとマネジメントにフィードバックを提供できるようにするツールとレポートを作成・保守する必要があります。
対応する担当者との品質計画の実施: エンジニアリングの担当者と定期的にやり取りし、今後開発されるもの、現在進行中のもの、提供されるものを追跡したいと考えています。その情報をもとに、最もリスクが高く重要な作業を特定し、コードレビューと機能の設計・実装に関する議論を通じて、適切なタイミングで品質フィードバックを提供できる必要があります。
テスト環境の管理 本番で使われるソフトウェアを代表するテスト環境もプロビジョニング・保守します。これらの環境を通じて、可能な限り現実に即したテストを行い、問題をより早く検出できます。

スキル & 個人特性

集中力: エンジニアリングロールにおける品質とその意味に強く集中している
適応力: 開発者とアーキテクトの両方のように考えられる
好奇心旺盛: 物事の仕組みを学んだり、分解したりすることを楽しむ
技術的: ツール構築を楽しむ（コーディングスキルを持つ）
情熱的: ツールとプロセスの改善、品質の提唱を好む
効果的なコミュニケーター: 口頭でも文書でも明確に表現できる

フラストレーション

不安定なテスト
実行時間の長いテストスイート
代表的なテストデータがないため、Issue を再現できないこと
不安定なインフラストラクチャ
開発作業についてより早くフィードバックできないこと

キーツール

トラッキング、ドキュメンテーション： GitLab Issues
コミュニケーション： Slack、Zoom、GitLab Issues
リアルタイムドキュメンテーション： Google Docs
ターミナル、コーディング環境： Ruby、JavaScript、Terraform、その他のサポート言語を使用する VIM、VS Code、または RubyMine
テスト自動化フレームワーク：プロダクトに適したテストツールの実装
クラウド管理コンソール：インフラストラクチャにアクセスするため（Google Cloud Platform、Amazon Web Services、Azure）
環境プロビジョニング： Terraform と Ansible
トリアージと緩和：
- Docker - Issue を再現し、環境をエミュレートするため
- 異なる環境用のアカウント - テストとインフラストラクチャのため
- データリポジトリとジェネレーター
- ロギングツール
  - Elastic Stack（Elasticsearch、Kibana、Beats、Logstash）
  - Sentry
  - Prometheus

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

開発チーム
プロダクトチーム
Infrastructure
UX チーム
Support

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

職務概要

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

モチベーション

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

フラストレーション

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

Dana (Data Analyst)

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

職務概要

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

モチベーション

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

フラストレーション

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

最終更新 September 12, 2026: Merge pull request #526 from kyama0/translation/batch-2026-09-12-1 (a1f3c26a)

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