隠れた IT グループ
隠れた IT グループ
「隠れた IT グループ」とは?
IT 組織の中には、役割と責任が定義された正式な組織図が存在します。これらは IT Operations、Application Development、Security、Portfolio Management、Service Management のような機能領域を中心に形成されることが多いです。一方、人々が共有する性質や特性によって定義される、隠れていて目に見えない「グループ」もあります。これらのグループは正式な組織図上の組織と一致する 可能性もあります が、必ずしもそうとは限りません。
なぜ隠れたグループが重要か
現代の組織と文化を考えると、私たちはしばしば共通の価値観、文化、プロセス、言語、標準、規範を共有するグループに組織化されます。これらのグループの文化と価値観を理解することは、彼らとつながり、彼らの痛みを和らげる解決策を提供しようとする際に、信じられないほど重要です。
| 特性 | 説明 |
|---|---|
| 価値観 | ある人々はイノベーションを重視し、別の人々は品質を重視するかもしれません |
| 文化 | 人々の働き方は異なるかもしれません |
| 課題 | 彼らは自分の仕事において異なる課題を認識します |
| ソートリーダー、アナリスト、カンファレンス | 彼らはそれぞれ異なるリーダーをフォローし、学びます |
| ツール | 彼らが選ぶツールは、彼らの特定のニーズを満たします |
| プロセス、プラクティス、標準 | ITIL、CMMI、Agile、PMI など |
| 対立 | 彼らは他の「IT グループ」と物事を異なる視点で見るかもしれません |
エンタープライズ IT/テクノロジーの IT グループ
IT には、人々のグループとその共有する価値観や共通特性を表すいくつかの「隠れたグループ」があります。探索可能な「IT グループ」はたくさん考えられますが、ここでの目標は、彼らのニーズ、ゴール、課題、言語を理解するために、最も典型的で一般的な区分のシンプルなフレームワークを提供することです。
グループ vs ペルソナ
- グループは ペルソナではありません。むしろ「ペルソナ」は異なるグループの中に見つかります。これらの IT グループを、異なる役割とペルソナの集合と考えてください。
- グループは (必ずしも)組織ではありません が、多くの場所では、これらの「グループ」境界に近いチームが定義されているかもしれません。

| 隠れた IT グループ | Organize | Build / Develop | Test | Run | Protect |
|---|---|---|---|---|---|
| 価値観 | 時間どおり、予算どおり、計画どおり。組織化。ビジネスへの提供のためにチームを集中させ続ける。 | できるだけ早くクールな新しいソリューションを イノベートし提供 し、ニーズを満たす最高のソリューションでビジネスが競争できるよう支援する。 | 品質 が鍵で、欠陥を見つけ、ユーザーが悪い体験をしないよう 守る | 稼働時間、パフォーマンス、可用性、効率。最低コスト で稼働させ続ける。サービスをできるだけ早く 復旧 する。停止(ディザスター)を避け 回復 する | リスクを管理・最小化し、内外問わずあらゆる場所からのサイバー脅威から 私たちのシステム、データ、ビジネスを 守る。 |
| 文化 | 複雑なプロジェクトとプログラム、提供のためにマトリクス化された世界でチームを確保する。Agile では将来の提供を予測しにくい。 | コラボレイティブで創造的。新しいテクノロジーの早期導入者。 | プロセスとトレーサビリティで、各リリースが本番にふさわしいかをダブルチェックする。多くの場合、自分の役割を欠陥からユーザーを守る守護者と見なす。 | プロセス指向で、しばしば ITIL プロセスに基づく。 | 人、プロセス、テクノロジーは常にバランス取りが必要。十分な量のそれぞれを持つことが目標。100% セキュアにはなれないが、セキュリティに対して階層的なアプローチを持つ必要がある。セキュリティは摩擦を生むものの、目標はビジネスを可能にすることである。 |
| 典型的なタイトル | プロジェクトマネージャー、Scrum Master、プロダクトマネージャー、Business Analyst | 開発者、アーキテクト、DBA、DevOps Lead、DevOps Engineer、DevTest | QA Lead、Tester、Performance tester、Automation Tester、DevOps Lead?、DevOps Engineer、DevTest | Sys Admin、Perf Monitoring、Incident Mgt、Release Mgr、SRE、DevOps Lead、DevOps Engineer | Security Operations、Security Analyst、Application Security、Penetration Tester、その他 |
| 隠れた IT グループ | Organize | Build / Develop | Test | Ops | Protect |
| 使うツール | PPM、Agile Portfolio Mgt、Project Management、Value Stream mgt、Requirements Mgt | SCM、Code Review、Code Quality、API Mgt、Architecture Mgt、Binary Repository、CI | ALM、Quality Mgt、Test Automation、Perf Testing | CD、Container Mgt、Cloud Mgt、ITSM、Service Desk、Incident Mgt、APM | App Security、Web App Firewall、SEIM?、SW Composition Mgt |
| プロセス | PMI、PMBOK、Prince2、SAFE、Earned Value、WBS | CI、Agile、RUP、Pair Programing | Risk Based Testing、Traceability、TMMI、CMMI | ITIL、Release Mgt、Change Mgt、Incident Mgt、Service Management | COBIT、ISO |
| 課題 | 複雑なプロジェクトとプログラム、提供のためにマトリクス化された世界でチームを確保する。Agile では将来の提供を予測しにくい。 | 複数のプロジェクト、ワークストリーム、システムへの貢献。本番と新規開発の両方をサポート。負担の重いプロセスが価値の提供を妨げる。 | 正確にテストすることが難しい複雑なソフトウェア変更。本番と一致しないテスト環境と、Dev からの変更スピードに追いつくこと | ビジネスがコストゼロで 24x7 を期待する複雑なレガシーインフラの管理。一方、開発者は変更を加えて壊したい。あなたのコントロール外の理由で物事が壊れる。 | あらゆるものを守ることが期待されているが、プロジェクトに早期や頻繁に関与することがほとんどない。プロジェクトの遅延と手戻りでよく非難される。SDLC の後半になりがちで、孤立したチームで、新しい要件の開発・テストなどに含まれない。運用の観点からは、シグナル疲労が真の問題。 |
| ユートピア | ビジネス需要を素早く優先順位付けし、プロジェクトを開始してリソースを組織化し、時間と予算どおりに提供 できる。実行への可視性が問題を早期に解決するのに役立つ。 | イノベーションとビジネス問題の解決に集中できる。変化に応答し、官僚的なプロセスに負担されない。彼らは自分のソフトウェアと、提供するビジネス価値を大切にする。 | テスト可能な要件 と テスト可能なアプリケーション が、すべての変更の 自動テスト を可能にし、欠陥を特定し、QA チームが探索的テストとエッジケースに集中できるようにする。 | 変更が SLA を破ることはない、問題が起きたとき MTTR は迅速。本番インフラは 管理しやすく、スケーラブルで、効率的 で、ビジネス需要をサポートできる。セルフサービス が日々の作業を可能にし、スノーフレークはない。 | セキュリティは決して 100% ではないため、理想的には プロアクティブとリアクティブ の両方の能力を持ちたい。たとえば、アプリケーションセキュリティとシフトレフトはプロアクティブな対策で、開発者向けの セキュアな SDLC トレーニングと組み合わせる。リアクティブ側では、プロセス早期で発見されなかったものをキャッチする セキュリティオペレーションとレッドチーミング 能力を持つ。これらの能力すべてが ポリシーとプロセス によって駆動・統制される必要があり、成功を保証するために十分なテクノロジーをデプロイする必要がある。 |
| 隠れた IT グループ | Organize | Build / Develop | Test | Ops | Protect |
| GitLab ステージマッピング | Manage、Plan | Create、Verify の一部 | Verify、Plan の一部 | Package、Release、Configure、Monitor | Secure、Protect |
- DevOps はどうなのか?
DevOps はムーブメントであり、グループの違いを越えて働くためにチームをまとめます。
- ステージはどうなのか?
これらの隠れた IT グループは、1 つまたは複数のステージに関連します。上記の表を参照してください。
- 他の「隠れたグループ」はあるか?
これらのマクロなグループのいずれかをよく見ると、その中に「サブグループ」が見つかるかもしれません。たとえば Run グループの中には、service 派閥や infrastructure/network 派閥が見つかるかもしれません。あるいは QA/Test グループでは、performance testing と devtest 派閥が見つかるかもしれません。
