アジリティ@スケールでの役割

 

 

 

collaboration-canstockphoto6717326-smallディシプリンド・アジャイル・デリバリー 1.x において、私達は10種類の役割を定義した。それはデリバリーチームに現れる、5つの主な役割と5つの補助的役割である。5つの主な役割(利害関係者、チームメンバー、チームリード、プロダクトオーナー、アーキテクチャーオーナー)は、デリバリーチームがどんな状況であっても現れる。5つの補助的役割(スペシャリスト、独立テスター、ドメインエキスパート、テクニカルエキスパート、インテグレーター)が必要になるのは、デリバリーチームが1つ以上の戦術的なスケーリングファクターに直面する場合である。

ITのニーズに取り組むため戦略的なアジャイルにスケールするとき、新たな役割が登場する。本稿では次のトピックを扱う;

 

ディシプリンド・アジャイル・ITにおける役割

ディシプリンド・アジャイル 2.0 で、私達はフレームワークのスコープを拡張した。それは、ある組織がIT部門全体でアジャイルになること(be agile)を望んでいるときに、その組織が直面する戦略的アジリティ@スケールの課題に取り組むためである。このスコープ拡張ではプロセスブレードを追加しており、これによってエンタープライズアーキテクチャー<未翻訳>、ポートフォリオ管理<未翻訳>、プロダクト管理<未翻訳> などの重要な能力に対応する。そうすることで、専門的な役割(エンタープライズアーキテクト、ポートフォリオマネージャー、プロダクトマネージャーなど)が出現した。以下の表は、これらの役割と責務<未翻訳> をまとめたものである。

 

【表1】@スケールに登場するディシプリンド・アジャイル・ロール

役割 責務 プロセスブレード
チーフ・アーキテクチャーオーナー
  • アーキテクチャーチームをプログラム(訳注:複数のサブチームで構成される大規模デリバリーチームのこと)の範囲で先導する
  • アーキテクチャーオーナーに対する、プログラムの範囲でのチームリード
  • アーキテクチャーオーナーにプログラムの範囲で助言・指導する
  • 技術的な依存関係を取り決めることを通じて、アーキテクチャーオーナーをプログラムの範囲で指導する
  • エンタープライズアーキテクチャー<未翻訳> のチームと緊密に連携する
  • 1つ以上のデリバリーチームで、アーキテクチャーオーナーの役割を担うことがよくある
プログラム管理
<未翻訳>
チーフ・プロダクトオーナー
  • プロダクトオーナーチームをプログラムの範囲で先導する
  • プロダクトオーナーに対する、プログラムの範囲でのチームリード
  • プログラムマネージャーと緊密に連携し、サブチーム間で作業を割り当てる
  • プロダクトオーナーにプログラムの範囲で助言・指導する
  • 機能的な依存関係を取り決めることを通じて、プロダクトオーナーを指導する
  • プロダクト管理<未翻訳> のチームと緊密に連携する
  • 1つ以上のデリバリーチームで、プロダクトオーナーの役割を担うことがよくある
プログラム管理
<未翻訳>
プラクティス・コミュニティ (CoP) リード
  • CoPメンバーが新しい知識を得るよう指導する
  • CoPメンバーにキャリア・ガイダンスを提供する
  • CoPメンバーのトレーニングと認定の機会を設ける
継続的改善
<未翻訳>
データベース・アドミニストレーター
  • レガシーデータソースを運用・保守し、発展させる
  • デリバリーチームと(理想的にはチームのメンバーとして)協力することで、データソースを高品質に開発・発展できるようにする
データ管理
<未翻訳>
データマネージャー
  • データ管理チームを先導するファンクショナルマネージャー
  • データベースアドミニストレーターのチームリード
  • レガシーデータソースの長期的リファクタリングを先導する
  • 組織内のデータ指向の活動を指導する
  • デリバリーチームと協力することで、異種データソース間でデータ品質を維持・強化できるようにする
  • データ指向ガイダンスの開発を先導する
データ管理
<未翻訳>
エンタープライズアーキテクト
  • 上級の利害関係者と緊密に連携し、組織の技術ロードマップを策定する
  • アーキテクチャーオーナーに方向を示し、デリバリーチームでアーキテクチャーオーナーの役割を担うことがよくある
  • デリバリーチームと協力することで、チームが既存のインフラストラクチャーを理解して活用し、適切なロードマップに従うようにする
  • オペレーションマネージャーと協力することで、現行の運用環境を理解し、技術ロードマップを進化させる
エンタープライズアーキテクチャー
<未翻訳>
ファンクショナルマネージャー
  • 優秀なITデリバリーチームを編成する
  • 特定のプロフェッショナルなグループ(プロダクトオーナー、チームメンバー、サポートエンジニアなど)に対する権限を持つ
  • キャリア・ガイダンスとマネジメントをグループに提供する
  • デリバリーチームに対して人材管理の権限を持つことがある
  • 特定の職務を果たすためのスキルを備えた人材を適切に確保できるようにする(例えばPOに対するファンクショナルマネージャーは、組織がデリバリーチームのスタッフに十分なPOを確保できるようにする)
  • 注:これはディシプリンド・アジャイルの”スーパークラスの役割”である。”サブクラス”の役割の例として、データマネージャー、オペレーションマネージャー、リリースマネージャー、そしてサポートマネージャーがある
人材管理
<未翻訳>
ヒューマンリソースマネージャー
  • 人材管理全体の責務を担う
  • チームが新しいメンバーを発掘・評価・採用するよう援助する
  • 組織内のチーム編成をファシリテートする
  • キャリア・マネジメントの業務を指導・援助する
  • スタッフ評価・査定の業務をファシリテートする
  • 能力・人材育成の計画をファシリテートする
人材管理
<未翻訳>
ガバナー
  • ITガバナンスを調整・監督する
  • ITガバナンスができるだけ軽量かつ柔軟であることを確実にする
ITガバナンス
<未翻訳>
オペレーションエンジニア
  • 既存のソリューションとIT運用基盤を実行・監視する
  • デリバリーチームと連携し援助することで、チームが既存のインフラストラクチャーを理解して活用し、そこにソリューションを配備できるようにする
オペレーション
オペレーションマネージャー
  • オペレーションチームを先導するファンクショナルマネージャー
  • オペレーションエンジニアのチームリード
  • 運用基盤内の変更を管理する
  • 運用上の災害に備えて計画し、災害を緩和する
  • 運用ガイドラインの開発を指導する
  • エンタープライズアーキテクチャー<未翻訳> のチームと協力し援助することで、チームが現行の運用環境を理解し、組織の技術ロードマップを進化させるようにする
  • リリースマネージャー と協力することで、リリース管理プロセス<未翻訳> 全体を合理化する
オペレーション
ポートフォリオマネージャー
  • 新たな可能性のあるデリバリーの挑戦/主導権/プロジェクトの発掘を先導する(プロダクトマネージャーと緊密に連携して)
  • 新たな挑戦の実現性を探るための実験を開始する
  • 進行中のデリバリーチームを監督する
  • ITの将来性を計画する(そのためにヒューマンリソースマネージャーと協力して)
  • ベンダーとの関係を管理する
  • プログラムマネージャー(もしいれば)とチームリードを指導・助言する
  • ITガバナンスチームと緊密に連携し、多くの場合はそのメンバーである
ポートフォリオ管理
<未翻訳>
プロセスエンジニア
  • 共通の規格とガイドラインの開発を指導する
  • (しばしば規制要件<未翻訳> のために)チームがプロセスを簡潔な方法で文書化するのを援助する
  • チームによるプロセス改善をモニターする
  • プロセス改善と学習項目について、チーム間のコミュニケーションを促進する
継続的改善
<未翻訳>
プロダクトマネージャー
  • ビジネスロードマップを開発し、進化させる
  • 可能性のあるプロダクトのアイデアを探求し、優先順位をつける(そのためにポートフォリオマネージャーと協力して)
  • プロダクト間の機能的な依存関係を管理する
  • 組織内外でプロダクトのマーケティングを行う
  • プロダクトオーナーに指示を与える
  • デリバリーチームでプロダクトオーナーの役割を担うことがある
プロダクト管理
<未翻訳>
プログラムマネージャー
  • プログラムの範囲でサブチームを編成する
  • 大規模デリバリーチーム(プログラム)の範囲で作業を調整する
  • プロダクトオーナーと協力することで、サブチーム間で作業を配分・構築する
  • アーキテクチャーオーナーと協力することで、技術的な依存関係を取り決める
プログラム管理
<未翻訳>
リリースエンジニア
  • デリバリーチームと連携することで、チームがソリューションを製品としてリリースするよう援助する
  • リリース管理ガイダンスを開発・発展させる
リリース管理
<未翻訳>
リリースマネージャー
  • リリースチーム(もしあれば)を先導するファンクショナルマネージャー
  • リリースエンジニアのチームリード
  • 全デリバリーチームの多数のソリューションを製品としてリリースするのを調整する
  • ソリューションを製品化する準備ができているかどうかの決断をファシリテートする
  • 共通のリリースプラクティスの開発を指導する
  • リリーススケジュールを管理する
  • オペレーションマネージャーと協力することで、リリース管理プロセスを合理化する
リリース管理
<未翻訳>
リユーズエンジニア
  • 再利用可能な資産を収集・開発し、進化させ、そしてサポートする
  • デリバリーチームと緊密に連携することで、再利用できそうな資産を収集し、既存の再利用可能な資産をソリューションに統合する
リユーズエンジニアリング
<未翻訳>
サポート(ヘルプデスク)エンジニア
  • エンドユーザーがソリューション(ITによって提供)を理解して作業するよう援助する
  • 既存のソリューションのエンハンスの可能性を発掘する
  • エンドユーザのヘルプリクエストの大部分に対処する
  • 難問を運営者やデリバリーチームへ適切にエスカレーションする
サポート
サポートマネージャー
  • サポートチーム(ヘルプデスク)を先導するファンクショナルマネージャー
  • サポートエンジニアのチームリード
  • エスカレーションプロセスを管理する
  • 利害関係者と緊密に連携することで、サポートチームが適切なレベルのサービスを提供できるようにする
サポート

 

なぜこれほど多くの役割が?

これほど多くの役割が@スケールにあるのは、デリバリー以外で生じる活動の幅広さによるものだ。「デリバリーでない」プロセスブレードは11種類あり(*訳注)、これらの各ブレードでは1つ以上の専門的な役割を説明している。例えば、ポートフォリオ管理ブレードではポートフォリオマネージャーの役割について、オペレーションブレードではオペレーションマネージャーとオペレーションエンジニアについて。

*訳注:表1にある12種類のプロセスブレードのうち、「プログラム管理」以外を指すと思われる。

 

役割を定義することの危険性

役割を定義することの主な危険性として、それらが役職として認識されることが挙げられる。これが起こるとき、人々は自然な流れとしてその「役職」の周りに活動を追加し始め、その「役職」をより重要なものにしようとする。マネジメントに関する「役職」を例に挙げると、その「役職」に報告する人々を増やすことで、マネージャーの影響を強めようとする傾向がある。

ここで重要なのは、本稿では役職ではなく、役割について述べているということだ。各人が1つ以上の役割を担い、時間が経てば役割を変えるだろう。ある役割は、誰もそれをやらないか、または1人以上がその時々でそれを果たし、そして必要に応じて進化するだろう。

オリジナル:Disciplined Agile Roles at Scale
http://www.disciplinedagiledelivery.com/agility-at-scale/disciplined-agile-roles-at-scale/
 (翻訳 大隈登)

Pocket