読者です 読者をやめる 読者になる 読者になる

Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

プロダクト開発を支えるサステイニングチームのはなし

本記事は、「アプレッソ Advent Calendar 2015」8 日目の記事です。

qiita.com

プロダクトが成長していくためには組織の成長がかかせません。私自身、アプレッソでプロダクト開発に携わって 10 年以上になりますが、そこで得た経験や知識をもとに私になりに考えるプロダクトの成長を支える開発組織、特に私が所属しているサステイニングチームについて説明したいと思います。

開発、保守、テストの 3 つの業務

この記事の中では、プロダクト開発に関わる業務を「開発」、「保守」、「テスト」の 3 つに分けてます。それぞれの業務内容は以下のとおりとします。

  • 開発・・・バージョンアップに向けた「新機能の開発」や「バグフィックス」
  • 保守・・・カスタマーサポートの中で、「ソースコードを見ないと対応が困難なインシデントの調査」や「リリース済みプロダクトのバグフィックス(パッチ作成)」
  • テスト・・・コードレベルの「単体テスト」やプロダクトの品質を担保する「ソフトウェアテスト」

開発、保守、テストを一人で行う

プロダクトの機能ごとに開発、保守、テストを 1 人の開発者がすべて行うことは、プロダクトが成熟しきっていないスピード重視の立ち上げ時期にはよくある光景です。大抵の場合、チームは少人数で構成されており、開発、保守、テストの各業務を分担するよりも、1 人の開発者がすべてを行うほうが効率的です。また、前提として、少ないコミュニケーションコストでメンバー間の意思疎通ができることが挙げられるでしょう。

プロダクトが成長していくと 1 人で対応することが難しくなっていく

ただし、顧客が増加してプロダクトが成長していくと、1 人ですべてを行うことが難しくなってきます。プロダクトのリリーススケジュールは引かれている中で新機能の開発をしつつ、サポートからはフロントで捌くことが困難な問い合わせが緊急で入ってきて当日回答を求められる、さらに、プリセールスからは「この機能があると受注できる」という話が舞い込んで、予定していなかった機能追加に追われる、結果、プロダクトのリリーススケジュールに影響が出て延期せざるを得ない状況に……。これはもう精神と時の部屋に入らないと対応できないレベルです。

「タスクの優先度が正しく設定できていればこんなことにはならない」、「あれもこれも手を出し過ぎじゃない?」みたいな声が聞こえてきそうですが、1 人で開発、保守、テストのすべてを行うことは、プロダクトをある程度以上に成長させるうえでボトルネックになり得ると考えます。

「ソフトウェアテスト」を行うQAチームの立ち上げ

プロダクトが成熟してきて、1 人で開発、保守、テストを行うことが困難になってきた場合、テスト専任の「QAチーム」の立ち上げというのが考えられます。テスト専任というと単なるテスターのような印象を受けるかもしれませんが、そうではなくプロダクトが定めた品質を保証するチームになります。QA チームについての説明はここでは省略しますが、アプレッソの QA チームについては、アプレッソ東が昨年の Advent Calendar で執筆した「QAチームって何ぞや?」に書かれています。

QA チームの立ち上げによって、プロダクトの品質を担保する「ソフトウェアテスト」は QA チームが行うことになるので、開発者はコードレベルの「単体テスト」に注力できる効果が期待できます。しかしながら、開発と保守は依然として 1 人で行うことになるので、さらなる変革が必要です。

保守を行うサステイニングチームの立ち上げ

ようやくこの記事の本題に入ってきました。

ここでいう保守とは、カスタマーサポートのうち、特に「ソースコードを見ないと対応が困難なインシデントの対応」やリリース済みプロダクトの「バグフィックス(パッチ作成)」のことで、その業務を専任で行うのがサステイニングチームです。

アプレッソでもサステイニングチームが存在していて、このチームのメンバーはDataSpider Servistaをはじめ、PIMSYNC、DataSpider BPM、Thunderbusなど、アプレッソのすべてのプロダクトを横断的に対応しています。したがって、特定のプロダクト、機能に依存しない広い視野と知識、スキルを求められますが、ときには他部署や協力会社、顧客とコミュニケーションを取ることもあり、技術のみにフォーカスしているだけでは回らない業務も担当します。

サステイニングチーム立ち上げの背景

サステイニングチームを立ち上げることになった背景として、カスタマーサポートからの問い合わせの対応や他部署との調整などのコストが増加し、プロダクトのリリースに影響して延期したことが起因しています。

開発タスク以外の対応がスケジュールを遅延させていく

カスタマーサポートへ問い合わせが来るタイミングは当然予測できるものではなく、フロントで捌くことが困難な問い合わせが入ってきた場合、開発者は現時点の開発タスクを一旦止めて、カスタマーサポートから来た問い合わせを対応します。開発者から見て比較的軽いものであれば対応に費やした時間はその後の調整や頑張りでキャッチアップ可能ですが、重たいものは確実にスケジュールに影響していきます。また、軽いものでも数が多いと、都度開発タスクを中断しなければならず、対応後に開発タスクの作業を復帰しても同じパフォーマンスを出すまでに時間がかかってしまい、生産性の低下は避けられません。

さらに、プリセールスや他社との協業の話で技術的課題が発生し、営業側では対応が難しいケースがあります。この場合、技術的な観点でプロダクトに造詣が深い人間の支援が必要になるわけですが、サステイニングチーム立ち上げ前は、開発チームが対応していました。そうなると、開発タスクの中断を余儀なくされることになります。

開発チームの疲弊とリリーススケジュールの延期

開発タスクの中断が頻発すると、開発チームでは、本来やりたいこと、やるべきことに対して「割り込み」が発生したと捉えられ、負のオーラが蔓延していきます。また、担当する開発メンバーによっては、そういった外部からの情報は、開発には役に立たない情報、いわゆる「ノイズ」として受け止めて、精神的にも時間的にも余裕のない状況に追い込まれていきます。

これら複数の要因が積み重なり、過去にプロダクトのリリースを延期せざるを得ない状況になった経緯があります。

開発チームを守る「壁」

この状況を改善するべく、プロダクトのリリースに向けた開発タスクを担当する開発チームを守る「」の役割としてサステイニングチームが立ち上がりました。 現在は、カスタマーサポートのフロントで捌くことが困難な問い合わせの対応や、営業側との相談ごとの窓口や技術支援などもサステイニングチームのメンバーで対応しています。結果として、開発チームの気を逸らすような情報はサステイニングチームで遮断され、プロダクトのリリースに向けた開発タスクに注力することができるようになりました。

外部の情報を正しく聞いて正しく伝える

上記ではサステイニングチームの役割として開発チームを守る壁と記述しましたが、壁となって頑なに外部からの情報を遮断してしまっては、「開発チームに役立つ情報が伝わってない」、「伝わったけど誤認識されてしまう」というケースが考えられます。外部からの情報としては、社内外でさまざまなものがありますが、特にプロダクトに対する顧客の声はこのようなケースに陥らないように注意しなければなりません。

顧客からのエンハンス要望の聞き方、伝え方

プロダクトに対する顧客の声としては、例えばエンハンス要望があります。カスタマーサポートでエンハンス要望を受けると、サステイニングチームで対応の可否を判断したうえで、可能な場合は開発チームで対応を検討してもらうように依頼します。その際、エンハンス要望を正しく聞けていない、または聞いたことを開発チームに正しく伝えられていないと、要望したものとは異なる機能がプロダクトに入る可能性があります。

このような不幸な出来事を防ぐためには、エンハンス要望を「正しく聞く」ことが重要です。正しく聞くというのは、文章としての正しさではなく、「なぜその機能を要望しているのか」という背景を汲み取る本質的な正しさになります。サステイニングチームは、顧客目線で要望の背景を聞いて対応を検討し、十分納得できるものであれば、開発チームにその情報を正しく伝えます。

また、ここでいう「正しく伝える」ということは、顧客からのエンハンス要望をそのまま伝えることではありません。サステイニングチームで検討した結果、要望された機能がなぜプロダクトとして必要なのか、開発チームに理解してもらえるような用語に「翻訳」することも重要です。

この一連のコミュニケーションにおいては、「正しく聞く」と「正しく伝える」が達成できれば、手段は問いません。メールやインシデントの文字だけでは理解が難しいと感じれば、顧客を担当している社内の営業に聞いてみることや、ときには顧客から直接ヒアリングしてみることもアリだと思います。また、開発チームに正しく伝えるにも、バグトラッキングシステムに書いたからそれで終わりではなく、サステイニングチームからコードレベルで修正案を提示することも有効な手段だと思います。

最後に

サステイニングチームは開発組織の中では縁の下の力持ち的な存在で、プロダクトを成長させていくためには重要なロールだと考えます。しかしながら、サステイニングチームのタスクは、他部署との調整やカスタマーサポートから入る突発的事態の対応など、開発チームの多くのメンバーがやりたがらない、または苦手なタスクがほとんどです。

そのような業務を行うサステイニングチームに対して、開発チームから見た場合、外部から自分達を守ってくれる壁として、また、ときには開発に役立つ情報を効率良く流してくれる頼もしい存在として映ることもあるでしょう。ただし、ここで注意したいのは「サステイニングチームを過度に賞賛しないこと」です。サステイニングチームは、あくまでも後方支援の立場で開発チームを支える裏方であり、プロダクトを前進させる花形は開発チームだと考えます。この陰と陽の 2 つのチームが同じ目的に向かって自分達の役割を全うすることができれば、より良い方向にプロダクトを成長させていけるのではないかと思います。