他チームの人とうまくやりとりするための心がけ

catatsuy

·

Follow

14 min read

·

Feb 3, 2019

--

Share

個人的に大切にしていることを書いていきます。少しSREの話が出てきますが、私がSREチームだから出しているだけで、基本的にSREに関係の無い分野でも使えるはずです。

前提となる心がけ

まず前提となる心がけについて書きます。

エンジニアは恐いと思われている

人は自分と関わりの少ない人のことを恐いと思いがちです。

システムはほとんどの人にとってブラックボックスです。そしてシステムを担当しているエンジニアのことも、ほとんどの人にとって未知の存在です。関わりが少ないからこそ、ほとんどの人にとってエンジニアは恐い存在です。

ビジネスをやっていく上で、エンジニアとのやりとりは非常に重要です。そのエンジニアと他の社員のやりとりがしにくい状況だとお互いにストレスが溜まり、不健全な組織となっていきます。

これを解消する一つの手として、例えばチャンネル名が z- から始まるチャンネルは雑談していいというようなルールを決めることで、仕事と関係ないコンテキストで社内の人と話せるようにするのがおすすめです。

そういった工夫もしていくべきですが、それとは別にしてエンジニアは恐いと思われているということを前提にフローなどを考えていきます。

他チームの人はあなたのチームに興味はない

他チームの人はあなたのチームがどういう仕事をどういうフローで行っているかは予想以上に知らないし、ほとんどの場合興味もありません。他チームの人にとっては、その人やそのチームが一定のパフォーマンスを出すために、どうしてもあなたのチームの協力が不可欠だから、あなたのチームに相談をしているだけです。

しかし、あなたのチームに対して迷惑をかけようという気持ちもありません。あなたのチームに対して極力迷惑をかけないように、依頼フロー等が決まっているなら極力それに従おうとしてくれるはずです。また何かの事情により、対応が遅れる場合も、しっかり説明すれば理解をしてもらえるはずです。

依頼フローを決める際に重要なことは、依頼フローなど必要な情報に他チームの人でも簡単にたどり着けるようにしておくことです。

作業はシステムで減らす努力をする

作業が増えると創造的な業務を進める時間がドンドン無くなります。またオペミスも増えるのでシステムの安定性は下がっていきます。

いわゆるSRE本にはSREはトイル（手作業による運用業務などのこと。詳しくは『5章 トイルの撲滅』を参照）が50%を上回らないように自動化する仕組みを開発していくことを求めています。

SRE本の『1章 イントロダクション』から引用します。

常にエンジニアリングを行っていなければ、運用にまつわる負荷が増大し続け、負荷についていくためだけでもチームにはさらに多くの人数が必要になります。
（中略）
これを避けるには、サービスの管理タスクを受け持つチームは、コードを書かなければなりません。そうしないと、そのチームは身動きが取れなくなるでしょう。そのため、GoogleではすべてのSREに対して、チケット、オンコール、手作業といった「運用」業務の合計を50%以下にするよう、上限を設けました。この上限によって、SREチームはサービスを安定して運用できるようにするための開発作業に十分な時間を確保できるようになります。この制限は上限であり、SREチームの自主性に任せておけば時間がたつにつれて、運用の負担は非常に少なく、ほぼ完全に開発のタスクに従事することになるでしょう。これは、基本的にサービスが動作しながら自己修復を行うためです。私たちが求めているシステムは、単に自動化されたものではなく、自動的に動作するものなのです。そして現実には、SREは新機能の追加やスケールアップに忙しくなるでしょう。
Googleにおける大まかなルールは、SREチームは残りの50%の時間を実際に開発を行うために使わなければならないというものです。

とりあえず作業依頼をすればいいという発想は非常に危険です。自動化したり、そもそもコミュニケーションが発生しない仕組みにできないのか考えたり、相談しましょう。

プログラマの三大美徳は怠惰(Laziness)・短気(Impatience)・傲慢(Hubris)です。自動化が美徳とされていて、そういったことが好きな人間が多くいます。気軽に相談してください。

HRTを忘れない

HRTはTeam Geekという素晴らしい本で提唱されたもので、謙虚(Humility)・尊敬(Respect)・信頼(Trust)のことです。

チームメンバーに対して忘れてはいけない気持ちです。お互い人間です。例えフローに則っていたとしても、HRTを忘れた人間とは一緒に働きたくありません。

どちらかが疲弊する仕組みは不健全

このエントリーは同じ会社の他チームの人とのやりとりに関するエントリーです。顧客とベンダーという関係ではありません。

顧客とベンダーならば、顧客が正当な対価を払った上で、ベンダーが圧倒的なホスピタリティでサービスを提供することはあり得ます。しかし同じ会社の他チームという関係では、会社全体としてどのようなパフォーマンスが外に向けて出せたかの方がはるかに重要です。コストをかけるべきはアウトプットのスピードや正確さであり、ホスピタリティではありません。

どちらかが疲弊する仕組みでは必要以上の労力を会社全体として払うことになり、ビジネスとしてはマイナスに働きます。また働きにくさから現場の人間が疲弊し、退職する危険性も高くなります。お互いが疲弊せず、スムーズにやりやすい仕組みを模索していくべきです。

やること

ここからは具体的に私や周りの人が実践していることを説明します。参考になれば幸いです。

Slackのpurpose/topic/reminderを使いこなす

Slackの使い方の工夫について紹介します。Slackにはpurposeとtopicという機能があります。purposeはチャンネルの一覧に書かれる説明文で、topicはチャンネルに入ると上の方に表示されます。

purposeにはどういうチャンネルなのかしっかり書いておくと、他チームの人からも適切なチャンネルを見つけやすくなります。topicはチャンネルを開いている間は常に表示されているので、そのチャンネルにおいて重要なことを書いておきます。このことを徹底すると他チームの人に『どのチャンネルで』『どのようなフローで』依頼などをすればいいかが分かりやすくなります。

これだけではなく、Slackのreminderも活用することをおすすめします。

Slackのreminderを使えば毎日決まった投稿をすることができます。every weekdayを使えば平日の時だけ毎日投稿することもできます。人間が毎日口を酸っぱくして言い続けるのはお互いストレスが溜まりますし、健全ではありません。前述の通り、エンジニアは恐いと思われています。自分がちょっと注意をしただけのつもりでも、相手はすごく怒られたと感じてしまうかもしれません。そうなる前にSlackのreminderに毎日投稿し続けてもらいましょう。

どんなチャンネルかをpurposeに、大事なことはtopicとreminderを使って、他チームの人にも分かりやすくしていきましょう。

ここまでSlackの使い方を紹介しましたが、残念ながらSlackのpurposeとtopicには文字数制限があります。短くまとめるしかありません。また定期的に投稿することはZapierなどを使ってもできるので、長文になる場合はreminderよりもそちらの方が使いやすいかもしれません。

他チームとのやりとり専用のSlackチャンネルを作る

他チームの人とのやりとり専用のSlackチャンネルを作ります。

専用チャンネルなのは他の話題と混ざっていると他チームの人が本当にやりとりをしていいのかわかりにくいからです。それに加えて、そのチャンネルを見れば過去にどのようなやりとりがされてきたかが簡単に分かるようになっていることも重要です。他の人のやりとりを見ればやり方を間違えることもありませんし、質問であれば過去に同じ質問がされていて自己解決するかもしれません。

前述の通り、他チームの人はあなたのチームのことに興味はありません。それなのに別の話題が混ざっていたら、やりにくくてうんざりしてしまいます。

依頼方法ですが、ちょっとした依頼ならSlackだけでやりとりをするのが手軽で十分だと思います。しかし過去の作業内容のログが残りにくいため、Jiraなどチームで使用しているタスク管理ツールを使いたいという需要や、Googleフォームなどを使って依頼内容を記録したいなど、チームによって様々な事情があると思います。依頼方法はお互いが疲弊しないような仕組みにして、仕事の依頼方法はSlackのtopicに書いたり、reminderで毎日投稿するなど、他チームの人にも依頼方法が伝わるように工夫します。

またどのようなやり方にしろ、Slackへ適切に通知をすることでお互いの仕事が見えて、お互いの信頼感が上がっていきます。Slackの通知もうまく使っていきましょう。

依頼はまず目的から書いてもらう

まず大前提として、システムに詳しくない人がエンジニアに何をして欲しいかを伝えるのはそもそも無理（他チームのエンジニアでも無理）です。

システムは複雑なだけではなく、日々変化しています。過去に同じ依頼をしていたとしても、今では通用しなくなっているかもしれません。また現在ではもっといいやり方があるかもしれません。

なので依頼は単純に何がしたいのか目的をまず書きます。その目的を達成する方法を考えるのがエンジニアの仕事です。安心して任せてください。質問も同様で、目的が分からないと適切なアドバイスができません。まず何がしたいのかを教えてください。

何度でも書きますが、他チームの人はあなたのチームのことに興味はありません。また日々色んな人があなたのチームに依頼をする可能性があるので、あなたが口を酸っぱくして目的から書くように言い続けたとしても無駄です。ある程度システムで目的を書くように強制しましょう。

Slackのtopicやreminderにそのことを書くことも考えられますが、例えばJiraならテンプレート経由でissueを作成してもらったり、Googleフォームなら目的を書くフォームを用意するなどの方法があります。必要事項を記入するスタイルの方が、依頼する側も何が必要なのかが明白になるので楽です。ストレス無くお互いに仕事ができるようにするよい工夫です。

ちなみにJiraのIssue Templateなど、Jiraの使い方については以下のエントリーで紹介したので、興味のある方は参照してください。

そもそもやりとりをする必要がない仕組みにする

他チームの人とのやりとりのコストは非常に高いものです。ただでさえ高いのに、エンジニアは恐いと思われているのだからなおさらです。そもそもやりとりを減らす努力をします。

例えばよく来る質問であれば、wikiなどにその質問と回答を書いておきます。そしてそのURLを掲示した上で、『それをすべて読んだ上で解決しないなら質問をしてください』とアナウンスします。もちろんアナウンス方法はSlackのtopicやreminderを使います。wikiのようにチーム内の人間ならば誰でもいじれるところに書いておいて、wikiの内容は常にメンテナンスするようにします。

あまりにも似た依頼が多い場合は自動化したり、システム化します。それには単純な人件費以上の価値があるはずです。

依頼チームが誤っている場合は適切なチームを案内する以上のことはしない

他チームの人はあなたのチームの業務内容に興味はないし、そもそも何をやっているのか知りません。なので、あなたのチームの管理下ではないシステムの作業依頼が来ることがあるかもしれません。

その際は無視してはいけません。他チームの人はあなたのチームに迷惑をかけたいわけではありません。自分のチームが一定のパフォーマンスを出すことに必死なのと、無知であることから、依頼先を誤ってしまっただけです。

その依頼の適切な依頼先をあなたが知っていれば教えてあげます。もし知らなければ、どこのチャンネルに聞けば分かりそうかだけでも教えてあげるとよいです。

しかし他チームの人とあなたは顧客とベンダーの関係ではありません。そもそもタスクの遂行責任はそのチームの人にあります。必要以上に関わる必要はありません。こういったことも疲弊することの1つなので、一言適切な依頼先を提案して終わりにしましょう。

やってはいけないこと

絶対にやってはいけないことを紹介します。

質問すると怒る

質問や依頼をしただけで怒られると、もう二度とあなたに仕事を依頼したいとは思いませんし、一緒に働きたいとも思いません。

そもそもあなたにとって、その質問は100回目かもしれませんが、質問した人にとっては初めての質問です。あなたが質問されたことは他の人にとっても疑問である可能性が高いです。複数回質問されることがあればwikiなどに書いて、今後質問が来ないようにしましょう。

他チームの人はあなたのチームのことに興味はないし、仕事内容も知りません。そして迷惑をかけたいわけでもありません。あなたのせいで社内が働きにくくなっていることを自覚してください。

質問や依頼する場を与えないことで見かけ上の質問や依頼を減らす

会社は組織として動くことで最高のパフォーマンスを出すために組織を作っています。あなたの見かけ上の仕事を減らすことで組織全体のパフォーマンスを落としてはいけません。

あなたがやるべきは効率化です。そんな仕事のやり方では組織の人数が少し増えただけで破綻してしまいます（気付いてないだけで、もう破綻しているのかもしれません）。

組織全体のパフォーマンスを落とすことで、社内の雰囲気も悪くなり、人が退職する原因にもなります。こういうことを言い出す人がいたらかなり危険です。

DMなど他の人に見えないところでやりとりする

他チームの人が何か仕事を依頼したくても、そもそもどのチームに依頼すればいいのか、そのチームに所属しているのは誰なのか、ほとんどの人は分かりません。なぜならば他チームの人はあなたのチームのことに興味はないからです。

またお互いがどのような仕事をしているのかが見えないので、不信感が溜まっていきます。社内の雰囲気は悪くなっていきます。

またDMが中心になると、情報格差が発生します。それを社内政治に使う人や、自分の頭の悪さを隠すために密室でのやりとりを中心にしようとする人が出てきます。こういう雰囲気になった組織を是正することはかなり難しいです。早めにDMで仕事をすることを禁止にしましょう。これは非常に重要なことでかつ、破ろうとする人が簡単に現れるので、トップダウンで明確に禁止することが重要です。

まとめ

お互いに気持ちよく働けるようにしている工夫などを書き出してみました。参考になれば幸いです。