サービスやアプリケーションを作り出すためには二通りの道があります。ひとりで作る道と、みんなで作る道です。いずれの道もメリットやデメリットがありますが、ここではそれらに触れません。 今回は、わたしのようにずっとひとりで作ってきた人間が、どのようにしてチーム開発というものに関わっていくべきなのかに焦点を当ててみたいと思います。
はじめに
少しわたしの話をします。
わたしがWeb制作というものを仕事にすることになったのは、前職へ入社してからです。その会社は中規模の紙媒体をメインで扱う制作会社で、自分が配属されたのはWeb事業を担う小さな部署でした。当時はまだWeb黎明期から足が抜けきれていない時分で、いまはなきFlashがまだ目新しく、そのFlashもまだMacromedia製品でしたし、jQueryなどはまだ生まれてもいませんでした。
そこで携わったのは主に中小コーポレートサイトの制作で、今のような分業体制はなく、基本的にデザインからWebサイト構築まで全て一人で完結させていました。そのスタイルは独立してフリーランスになった後も変わらず、ワンストップで完結する「Webのなんでも屋さん」を謳い続けています。
そんな折、数年前から知人からの誘いをきっかけにしてプロジェクトに参加する事になりました。はじめてのチーム開発です。それまでずっとひとりで完結してきた人間がいきなりチームの一員として仕事をする事になり、正直なところ、どう振る舞えば良いのかわからず戸惑いを感じました。
制作物の粒度が小さかった頃はひとりでも大丈夫でしたが、Webアプリケーションが大きな役割を担うようになるにつれ、より大きな規模のシステムをチームで開発しなければならなくなります。Webの成長と共に歩んできたようなわたしぐらいの年代には似たような境遇の方も多いのではないかと思い、この度筆をとった次第です。
この記事は、そんな方々へのちょっとしたヒントやアイデアをまとめたものです。
チームに入る前に、2つの前提
はじめてのチームに参加するにあたって、チームにとって良い存在になるための心構えが必要です。ここに挙げるのはその心構えの基礎をつくるための2つの前提です。あくまで前提なので、実際にそうであるかは大きな問題ではありません。
1. みんな自分よりも強い
チームのメンバーは、全員が自分より強く優秀であるとします。
ここでいう「強さ」というのは、プログラミング能力に長けていたり、技術に対する理解が深かったり、プロジェクトをよく知る古参の生き字引であったり、渉外が得意だったり、ディレクションが上手かったりと、多種多様です。ひょっとすると、筋肉がすごいかもしれません。
言い換えると自分が最も未熟であるという事ですが、これはただの「前提」なので卑下することではありません。自分よりも強いチームメンバーの言動を良く見て良く聞き、尊重し、信頼しましょう。その姿勢をつくるための「前提」です。
2. 目指すゴールは同じ
チームには共通した目標が必ず掲げられていて、メンバーは全員が目標達成のために邁進しているとします。
掲げられた目標はプロダクトやサービスの成功であることが多いでしょう。チームメンバーの関心は常にその目標達成を向いていて、その言動も当然そのゴールに近づく為になされたものです。
例えば、自分のタスクのレビューをメンバーにお願いした際に、すごく当たりの強いコメントをされたとしても、その人は自分を攻撃したいのではなく、ただそのコードをより良い物にしたいだけなのです。そのように好意的に受け取れば指摘内容を素直に理解する事ができますし、脳内で「攻撃」を処理する必要もなくなります。ネガティブな感情を処理するためには多くのカロリーが必要となるものです。
より大切な事は、この姿勢から育まれる帰属意識です。チームメンバーは皆が同じゴールを目指す同志であって、志を同じくする仲間の存在は個々人の、ひいてはチームのパフォーマンスを大きく向上させるでしょう。チームにスパイなどいないのです。
実践 : チームに入ってどう振る舞うか
前提で心構えを固めることができれば、次は実践です。この姿勢をもってどのように立ち振る舞うべきなのか、書き連ねていきましょう。多くは自分の経験則（あるいは自戒）に過ぎませんが、ヒントやきっかけになれば嬉しいです。
アラートは遅滞なく
困ったことがあったら、すぐさまアラートを出しましょう。メンバーは他のメンバーのアラートに常に目を光らせ、力になりたいと思っています。一人で何十分も悩んでいた問題をメンバーが秒で解決してくれるというのもよくある話です。
「アラートでメンバーの作業の邪魔をしてしまわないか」「タイミングをはかった方がよいのでは」といった心配は無用です。言われずともメンバーは自分のリソースの管理をきちんとしたうえで助けてくれます。なぜならみんな強いからです。 アラートが早ければ「いつ助けるか」を選択することが出来ますが、アラートが遅れればその選択肢を狭めてしまいます。「どれくらい急いでいるか」の情報を添えてアラートを出すのはとても良いアイデアです。それは、「いつ助けるか」の判断基準になるでしょう。
「わからない」は胸を張って
人は自分を大きく見せるために、自分がわからないことを隠してしまいがちです。しかし、わからないことは当たり前なので恥ずかしがる事は何もありません。堂々と胸を張って元気よく「わからない」と言いましょう。自分がわかるのは自身の事と、自分が書いたコードの事ぐらいなものです。（時にはそれすらもあやしいです）
ひとりで抱え込んで時間をかけて自力で解決する事にも価値はありますが、多くの現場では速さや正確さも要求されます。ひとりでは間違った解決をしてしまう事もあるでしょう。最も恐ろしいのは、わからないことをわからないまま済ませてしまった結果、それが原因で大きな事故を招いてしまうことです。そうならないために、自分がそれを「わからない」という事実を早めに共有しておくべきです。
質問をする際には、「どこまでわかっているか」「どこからわからないか」を明確に伝えるように心がけます。回答者はこれらの情報から、何の説明に焦点をあてるべきかを判断できます。
ポジティブフィルタを通す
メンバーの言動はポジティブフィルタに通し、まずそれを正しいものとして、好意的に受け取ります。
メンバーはみんな自分よりも強いので、前提として正しい事をします。一見間違ってそうな事でも、様々な理由や経緯があってやむを得ずそうしている場合もあります。そのような背景を理解しないまま一足飛びで指摘してしまうと、相手は不快に思うかもしれません。 ポジティブフィルタは、そういった小さな衝突を防ぐためのクッションです。指摘をする前に、その背景について少しばかり想像を働かせてみましょう。
ネガティブフィルタを通す
逆に、自分の言動はネガティブフィルタに通します。形にして相手に伝える前に、「本当にそれが正しいか」と何度も疑問を投げかけます。コードレビューを依頼する時にはセルフレビューを習慣づけましょう。指摘をうけたらまず自分がミスをしている前提で調査をしましょう。
人間誰しも自分自身を信頼しているもので、自分の失敗には盲目です。そのため、ポジティブフィルタよりも目の細かいフィルタを何枚も用意する必要があります。それでも全ての誤りを検出することはできません。あとはメンバーの器量に期待です。強いですから。
ネガティブフィルタもまた、メンバーとの衝突や摩擦を未然に防いでくれるでしょう。
趣向のレビューは慎重に
個人の好みによるコードレビューは注意が必要です。どのようなレビューが好みによるものなのかは判断が難しいところですが、わたしはざっくりと次のような基準を設けてみました。
- 「どちらでもいいですが」と言葉を足しても内容に違和感がない
- 対応をしなくても具体的な問題が生じない or 要件を満たしている
- 指摘対象のコードがチームのガイドライン、あるいは一般的にメジャーなガイドラインに則っている
これらの条件のいずれかにあてはまる場合は、そのレビューコメントが本当に必要かどうか検討しましょう。趣向の表明は毒ではありませんが、相手のメンバーの趣向と衝突してしまうと不要な議論に発展する場合もあり、多くのカロリーと時間を消費させてしまうかもしれません。 それでも相手に伝えたい場合は、それが個人的な意見であり、判断を相手に委ねる事を明確にすると良いでしょう。例えばこのように。
変更するかどうかはお任せしますが、この書き方を採用するとよりスッキリするかもしれません！ 🎉
そのうえで、他に変更が必要な指摘事項がなければ Approve を押してしまって、あとは相手に任せます。そうすれば、レビューされた側を躓かせる事もありません。
逆に、「どちらでもいいな」と思うレビューコメントを受け取った時は、さっさと折れてしまうのが良いです。どちらでもいいことにカロリーを浪費するのは避けたいですからね。
雑談を楽しむ
用意されたSlackチャンネル等で、積極的に雑談をします。雑談はコニュニケーションの潤滑油となり、緩衝材となり、帰属意識を育む効果も期待できるでしょう。もちろん、雑談が許されるような環境がある場合に限ります。
話題は何でも良いですが、メンバーが共感しやすく、反応しやすい物が良いでしょう。そうでなければ、ただの独り言で終わってしまいます。プロジェクトと全く関わりがない話題は、連発するとノイズになるのでほどほどにします。間接的に関係のある物ならば、改善の足がかりを見つけられるかもしれません。
メンバーが雑談を始めたら、反応できそうな話題ならば是非乗っかります。それを見た他のメンバーも、そのチームが雑談の文化を持っているのだと知る事ができ、次第に雑談がしやすい雰囲気になっていくことでしょう。
テキストを親しみやすくする
リモートワークが増えてきたことも助けて、昨今ではテキストによる非同期コミュニケーションが主軸になりつつあります。しかし、テキストが保持できる情報というのは非常に限られたもので、無機質で無表情なメッセージテキストは相手に固く冷たい印象を与えてしまいがちです。
そこで、テキストの表情を豊かにするために工夫を凝らしてみましょう。以下、難易度順です。
- 感嘆符（！）を使う
- 絵文字を使う
- 言葉遣いをフランクにする
1. 感嘆符（！）を使う
読点（。）を感嘆符（！）に変えるだけです！とても簡単です！感嘆符が付いているだけで不思議と文章が元気になり、少し温かみを増したような印象をうけます！！
ただし、感嘆符が表現するのはポジティブな感情だけではないので注意が必要です。特に疑問符（？）と一緒に使うと、まるで憤慨しているかのような圧を与えかねないので、この組み合わせは避けた方が良いでしょう。
なぜこのような実装になっているのでしょうか！？！？
2. 絵文字を使う
絵文字は、表情やジェスチャーなどで表した感情を一文字に凝縮させて伝える事のできる優れものです。SlackやGitHubなどでは簡単に挿入する事が出来るので、有効に活用しましょう。
絵文字は種類が非常に豊富なので、選択には気を配りたいです。例えば、ネガティブなテキストメッセージに爆笑しているスマイリーをつければ煽りと受け取られてしまいます。文脈に適した絵文字をチョイスしましょう。
こちらのミスでした、申し訳ありません 🤣🤣
それから、これは言うまでもない事だと思いますが、絵文字を多用するとおじさん構文になってしまいますので、節度は守らなければいけません。
3. 言葉遣いをフランクにする
これは加減が難しいうえにチームによっても温度差があるので、難易度が高めです。実際、わたし自身も書き言葉より話し言葉に寄せるくらいが精一杯なところはあるのですが、どの程度の信頼関係が築けているのかを探りつつ、少しずつ部分的に砕いていくのが良さそうですね。
例えば、まずは単語のチョイスから。
「承知いたしました、こちら対応いたします」
↓
「わかりました、こちらやっつけていきます」
音引きなどで語感をゆるくしてみたり。
OKでーす！
それでよいかなぁと思います
しかし、一重に相手次第なところもあるので、無理に採用すべき手法ではないとも感じます。言葉遣いひとつで「失礼だ」と思われてしまうリスクもはらんでいるので、慎重に使いたいですね。
感謝を忘れずに
他者と関わり合う上で当然の事ですが、感謝を忘れないようにしましょう。それは形にしなければ決して伝わる事はありません。会話の最後は必ず「ありがとうございます」で締めくくるぐらいの勢いで感謝を伝え続けましょう。
「ごめんなさい」を言う機会があったら、可能ならば「ありがとう」で言い換えてみましょう。謝罪を連発されてもあまり良い気持ちはしませんが、それが感謝の言葉だったらどうでしょうか。前向きなエネルギーに変換されるような心持ちにならないでしょうか。
感謝の言葉は多用しすぎても毒にはなりません。せいぜい人によっては気味悪がられる可能性があるぐらいでしょう。惜しまずどんどん伝えていきましょう。
おわりに
この記事を書く前に、オライリーの「 Team Geek 」という書籍を読んで感銘を受けました。本記事内容のアイデアや言葉選びはこの書籍から影響を受けているところが多分にあると思いますので、ご了承ください。「Team Geek」はチームをマネージメントする側の視点から書かれていましたが、本記事はチームに参加する新参メンバーの視点から書いています。
チームに参加する限りは、そのチームの役に立ちたい、チームの不利益になるような存在にはなりたくないと考えるのはごく自然なことです。「Team Geek」ではチームにとって良くない振る舞いを「有害な振る舞い」と呼んでいましたが、そのような振る舞いをするメンバーにならないよう、心がけたいものです。
ただし、この記事に書かれている内容はわたし個人の経験則であって、万人にとっての正解ではないはずです。記事内容を丸呑みせずに咀嚼していただき、チームでのコミュニケーションに悩む方にとってちょっとしたヒントになればと、そう願います。