ブログ

日々これ精進

study & discipline

2024年5月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
最新の記事
カテゴリ
(H) (25)
(O2S) (13)
月別表示
(T06S)

職場の文化、慣習にもいろいろあります(T06S)

■はじめに

どんな職場にもそれぞれ特有の文化、慣習がありますが、ここではとりわけ英語圏で開発されたソフトウェア製品のサポートチームという非常にニッチな職場における文化、慣習をご紹介します。

一般的にソフトウェア製品サポート組織は多層化されており、3層に分かれていることが多いようです。
この記事は日本に技術的なサポートを提供できるチームがあり、上位チームが海外開発部門となっているサポート組織の日本側がモデルとなっています。

サポート現場の多層化については下記が参考になります。

テクニカルサポート – 多層テクニカルサポート
https://ja.wikipedia.org/wiki/テクニカルサポート

もちろん様々な職場(サポートチーム)があり、職場ごとに慣習が異なるためソフトウェア製品サポートといってもすべての職場に当てはまることはありません。
ただ、似たような職場なら必ず持っていそうな文化、慣習をご紹介します。

■穏やかな言葉を使う

製品サポートに来る依頼は障害調査と仕様確認の件数が多いです。
ただ、障害調査時でも不具合という意味でbug,problem,defectという英語がありますが、開発者にとって歓迎されない言葉です。
よほど明らかでない限り、サポートから開発部門に調査依頼を出すときは穏やかな言葉を使います。
大抵はissueやunexpected behaviorという言葉を使って状況を説明します。

■仕様の質問を障害調査依頼に変更

日本でも問題調査を依頼されるとき、いきなり不具合、バグ、欠陥という言葉が使う方は少数派です。
ただ、穏やかな言い方として「このような動作は仕様か?」という質問の形態をとる方が多いです。
そのまま仕様の質問ととらえると優先度が下がり、顧客のためになりませんので意図を汲んで顧客に緊急度や追加情報を求めつつ障害調査に変更します。

たまに製品サポートに問い合わせたとき、質問に対する回答があっていないことがあるとおもいますが、意図を汲んで期待とは異なる対応になってしまっているのかもしれません。

■中途半端な提案は避ける

再現手順が分かっているのであれば必ず伝えます。
ただし「・・・かもしれない」「・・・について確認して欲しい」ということは言いません。
問題切り分けの中で「気づき」があり、よかれと思って伝えた言葉でも開発者の調査をおかしな方向に誘導することになりかねず、解決が遅れる可能性があるためです。
事実と状況を伝え、緊急度をアピールし、原因分析は開発者に任せた方が結果として真摯に対応してくれることが多いです。
よっぽど明白なものでない限り「・・・に修正が必要だとおもう」という提案は行いません。

■クリスマス休暇は調査が進まない

日本は年末年始、GWが大型連休ですが、英語圏は大抵クリスマス休暇があります。
この時期は多くの開発者が休暇を取るため応答がまったくないこともあります。
緊急度の低い問い合わせはこの時期を避けるように調整しています。

■おわりに

ニッチな職場にはニッチなりに慣習があるものですがソフトウェアサポートチームは問題を切り分けた後で如何に開発者に必要な情報を伝えるか、いかに気持ちよく仕事をしてもらえるかが肝なのでそれを重視した文化、慣習となります。
言葉や祝日に気を遣うのもそのためです。

なお、掲載内容は筆者個人の見解であり、必ずしも私が所属する会社、組織、団体の立場、戦略、意見を代表するものではありません。
また、本記事は私の主観で記載したものです。

2023年03月27日

一つ上に戻る

先頭に戻る