3分で分かるPagerDuty~PagerDutyだから実現できる迅速でプロアクティブなインシデント対応~
この資料では、日本企業が抱えるインシデント対応の課題を明らかにし、それを解決するPagerDutyの迅速かつプロアクティブなインシデント対応をご紹介します。
ソフトウェア開発の一連の工程は、開発者とチームリーダー、マネージャーからなるエンジニアリングチームで進めます。
開発や運用の効率を高めるには、企業の性質や目的に合ったエンジニアリングチームを構成し、適切にマネジメントすることが重要です。
この記事では、エンジニアリングチームを構成するメンバーそれぞれの役割や、チームのマネジメントにおけるポイントを紹介します。
目次
エンジニアリングチームは、製品やサービスの開発・保守などを行なうチームです。顧客が使用するプロダクトの大部分に関わります。
チームを構成するのは、開発エンジニアや運用エンジニアなど、チームの目的に応じた専門知識を持つメンバーです。互いにサポートをしてプロジェクトを遂行し、企業の技術的な基盤を支えています。
特に、エンジニアが開発と運用の両方に携わるDevOpsの環境下では、開発や運用の効率性を高めるためにエンジニアリングチームをどう構成し、マネジメントするかが重要です。
エンジニアリングチームは、大きく開発者、マネージャー、チームリード、品質管理スペシャリストで構成します。
エンジニアリングの役割や役職は、企業によって異なります。そのため、役割を理解し、役割分担を明確にすることが重要です。
ソフトウェア開発者は、コードを記述するなど、終始純粋に技術的な業務に従事します。
一般的なソフトウェア開発者には、以下の職位・役職があります。
職位は、おもに経験や勤続年数によって決定されます。例えば、シニア開発者の役職は、5~10年のコーディング経験を有するソフトウェア開発者に与えられるのが一般的です。
ソフトウェア開発者は個人での作業が多く、基本的には管理や人事的責任がありません。
しかし、現在のアジャイルな開発環境では、開発者同士の連携が重視され、コミュニケーションやチームワーク、柔軟性などのスキルも求められるようになっています。
ソフトウェア開発チームのリードエンジニアやマネージャーは、ソフトウェア開発者でありながら、おもにマネジメントに携わります。
コードの記述や新規製品・機能の設計支援といった仕事に加え、管理・指揮するチームに所属するエンジニアたちの直属の上司としての役割もこなします。
企業ごと、もしくは特定の管理レベル・責任ごとにチームのリードエンジニアおよびマネージャーが設置され、10~100人のチームメンバーを束ねます。
エンジニアリングチームには、チーム構造や特定のニーズに基づき、複数の種類・レベルのリードエンジニアおよびマネージャーが存在します。
以下は、一般的なリードエンジニアおよびマネージャーの職位・役職です。
なお、リードエンジニア(リードエンジニアまたはシニアリードエンジニア)は、必ずしもマネジメントの役職にあるわけではありません。
技術面でのリーダーがメインの役割です。
品質保証(QA)の技術者は、製品のテストと修正の責任を担います。テストのためにコードを記述することもありますが、品質保証技術者は、初期開発には関わりません。
ソフトウェア開発チームのリードエンジニアやマネージャーと同様に、QAマネージャーはテストやコード記述を行なうこともありますが、おもな職務は人材管理です。
以下は、エンジニアリングチーム構成における一般的なQAの役割です。
エンジニアリングチームにとって、役割と同様に重要なのが、チーム構成です。
技術スペシャリストを重視し、ウォーターフォール型の生産手法を採用するチームもあれば、横断的なチーム構成と、スクラムのようなアジャイルな開発フレームワークを好むチームもあります。
以下は、特に一般的な3種のエンジニアリングチーム構造です。
技術スペシャリストによる横断的チーム構成で、ミッション遂行を重視した構造です。
生産キューに対して、ウォーターフォール手法を用います。新製品や修正の市場投入に時間がかかりがちなところが難点です。
プロダクト型チームの構造も、ミッションを重視していますが、生産にスクラムのようなアジャイルな手法を適用し、横断的なチーム構成となっています。
アジャイル手法の最大のメリットは、プロダクトリリースのライフサイクルが短いことです。ユーザーの期待に機敏に対応し、継続的改善の実現を期待できるでしょう。
マトリクス型チーム構造(Spotify型チーム構造)は、技術型チームとプロダクト型チームの中間に位置付けられます。
マトリクス型チームはプロダクト型チームのような横断的機能を備えている場合が多い一方、1人ではなく複数のマネージャーへのレポートラインを持つこともあります。
このようなチーム構造のマネージャーは、プロダクトリーダーというよりも、人事管理マネージャーのように機能することが特徴です。
エンジニアリングチームは、構造によってそれぞれ異なる特徴があります。チームを構成する際には、以下の2点を押さえることが重要です。
企業やプロジェクトによって、適切なチームの構造は異なります。
他のチームでうまく機能した構成をまねても、自分のチームにそれが当てはまるとは限りません。
チームの目標や企業の性質を踏まえたうえで、構成する必要があります。
技術型、プロダクト型、マトリクス型といったチーム構造は、三位一体といわれることがあります。
各構造にはそれぞれメリットとデメリットがありますが、類似点もあります。
近年、多くの企業はこれらの構造のバランスを微調整してチーム構造を独自にカスタマイズし、自社に適したチーム機能を確立しています。
エンジニアリングチームのマネジメントでは、チームにとって何が最適で、何が適合しないのかを積極的にモニタリングします。そして、調整を加え、チームの能力とプロセスの効率性を継続的に改善することが大切です。
エンジニアリングチームの力を発揮させるためには、以下を実施しましょう。
心理的安全性とは、組織の誰に対しても、安心して自分の考えや気持ちを発言できる状態のことです。
この状態を確保するために、メンバーが皆、仲間のサポートがあり、意見に耳を傾けてもらえると感じられるようにしましょう。
誰かを責めたり責任をなすりつけたりする環境ではなく、問題を解決するマインドセットを強化できるような職場環境を作ることが大切です。
エンジニアチームにとって、明確さは中核を成す重要なポイントです。
チームメンバーに対し、何を求めているか明確にすることを意識して、コミュニケーションを行ないましょう。
メンバー間の協力体制が向上し、具体的なフィードバックを頻繁に得られるようになります。
ソフトウェア開発は、一筋縄にはいかないものです。そのため、変化する環境にスムーズに適応し、課題が発生しうる場所を探すことが重要です。
優れたエンジニアリングチームを構築・管理するには、製品やサービスと同様に、独自に構築する必要があります。
最適なチームのあり方についてじっくりと検討し、適切な役職とチーム構造を選択して、チームの力や効率性を伸ばしましょう。
システムの安定運用には、運用に多くのリソースがかかります。運用エンジニアの負担を軽減するには「PagerDuty」などのインシデント管理ツールにより、対応時間を圧縮することが有効です。
エンジニアが開発と運用の両方を担うDevOps環境下においても、開発へのリソース確保に役立ちます。
「PagerDuty」を活用してエンジニアリングチームの力を高めましょう。詳しくは、お問い合わせいただくか、14日間の無料トライアルをご利用ください。
「PagerDuty」に関する資料や導入事例は、以下のページからダウンロードいただけます。
https://www.pagerduty.co.jp/resources/
また、14日間の無料トライアルは、以下のページからご利用いただけます。
https://ja.pagerduty.com/sign-up/
この資料では、日本企業が抱えるインシデント対応の課題を明らかにし、それを解決するPagerDutyの迅速かつプロアクティブなインシデント対応をご紹介します。
目次