Ateam Group Manager ＆ Specialist Advent Calendar 2020 の11日目はIncrements株式会社の @okoshi が担当します。
はじめに
本記事のタイトルにツールが入っているので、どのようなツールについての記事なのかあらかじめ知りたい方が多いと思いますので先にお知らせいたします。本記事で紹介する記事は以下の通りです。
この中で、最も活躍したツールはSlackなため、大半はSlackの紹介になっていますが、Slackをうまく使わなければ超短期プロジェクトをやりきることはできなかったので多くを費やしています。
なお、本記事では特定のツールの善し悪しを説明するのではなく、有効な使い方を紹介するものなので、ツールのプロダクトが違っても同様な使い方ができれば、うまく活用できるのではないかと思います。
超短期プロジェクトの発足
社内で初めて会ったメンバーで、一ヶ月という短い期間で、プロダクトを開発するという社内コンペに参加しました。
チームを醸成し、プロダクトを完成に導いた背景には、チームメンバーの良いコミュニケーションがあったと考えています。
もしこれから、短い期間で開発を実施しようと考えている方は、是非この記事を参考にしていただければ幸いです。
メンバーとの出会い
本記事で紹介させていただくケースは、短い期間であったからこそ機能したものであると考えているため、色々説明を始める前に、どうして一ヶ月という短期間でチームを組織しなければならなかったのかを簡単に説明します。
１ヶ月の短い期間で、社内の課題を解決するプロダクトを作成する社内コンペが企画されました。１ヶ月とはいえ、空き時間を使って開発を行うため、1日に作業ができる時間は限られていますが、参加したいエンジニアとデザイナー、壁打ち役が募集されて、私はエンジニアとして参加を申し込みました。
コンペ開催の趣旨の一つとして、コロナ禍で、社内の横のつながりがなくなってしまった今、社員同士のコミュニケーションが悪くならないようにしたいということもあり、メンバーはランダムにシャッフルされ、できるだけ普段つながりがない人たちでチームが構成されました。
我々のメンバーは、デザイナー2人、エンジニア3人、壁打ち役1人という構成になりました。壁打ち役は開発には携わらないので普段動く人たちはデザイナーとエンジニアの5人です。
リーダーは年長者である私 @okoshi が立候補し、私が担当することになりました。
コミュニケーションにはリーダーの役割が重要
始まって早々に、構成されたメンバーは、普段全く違う仕事をしていること、メンバーのうち3名は家庭をもっていることから、時間を合わせて集まるといったことが難しい状況であることがわかりました。
社内のメンバーはリモートワークになれているので、離れて作業をすることが問題になるとは思っていませんでしたが、リモートワークとはいえ、Zoomなどのビデオチャットの会話をしながら作業を進めることができないのは、テキストチャットでコメントを残したり作業の依頼をするしかなく待ち時間が多くなりストレスになる恐れがありました。
チームは、全員が役割を認識し自走しはじめるまでの間、リーダーの役割が重要になります。リーダーは文字通り、メンバーをリードしていかなければなりません。私はリーダーとしてビジョンを明確にし、モチベーションの低下につながらないように配慮し、本気であることを示してついてきてもらうことを意識していました。
ビジョンを明確にする
ビジョンは欠けていると混乱を招きます。求める最終状態をはっきりさせました。どんなものを作るのかを決めたら後から覆さないことが大事です。ここで具体的な成果物がどんなものであったかは都合上伏せさせていただきます。
モチベーションの低下につながるような課題を率先して解決する
最も懸念があったのはコミュニケーションです。過去に実績のあるツールを提案し、自ら導入していきました。
リーダーが本気なのを見せる
リーダーが本気であることを示さなければメンバーはついてきてくれません。リーダーの行動としてはこれが最も重要だと思います。やる気を見せるということでもあります。
とにかく明るく、ポジティブに振る舞うことで安心感を与えることも意識しました。
開発の進め方は個人を信頼して任せた
システム開発の進め方には、ウォーターフォール開発などのシーケンシャル開発やSCRUMなどのアジャイル開発がありますが、あまりにも期間が短いのと、開発するもの自体が大きなものになるとは考えにくかったためシーケンシャル開発やアジャイル開発は採用しませんでした。
大きく分けてアプリケーション1名、インフラ1名、デザイン1名、コンセプト・ロゴ・プロダクト名作成1名という形にし、フットワークの軽いメンバー1名をアシスタント的に動けるようにすることで全員が非同期的に動けるようにしました。
このとき重要なのは、成果物の齟齬は許容することです。そもそも大きなものを作る時間はないので、ずれが大きくなりにくいと考えたのでそうしました。プロジェクトの終盤で集中的に差を埋める作業を実施することでプロダクトをくみ上げました。
このような進め方はプロジェクトの規模が大きくなるほど難しくなるので、小さなプロジェクトならではの進め方といえます。
Slackは日常的なコミュニケーションを繋ぐ
元々、メンバーの中で唯一私だけが日常的にコミュニケーションをとるツールとしてはSlackを使っており、使い慣れていました。対面で会議をするときはZoomを使うこともありましたが、同時に話すことはできなかったりするので普段の日常的な作業にはSlackによるテキストのコミュニケーションになりました。
テキストのコミュニケーションだと、どうしてもかしこまった文章になりがちなのですが、テキストによるコミュニケーションは口語調で行うのが良いと思っています。それは普段使っている言葉でコミュニケーションをとった方が、言葉を選ばずに書くことができるのでテキストを書きやすくなるという効果が期待できるためです。
もちろん目上の人など、必要な人には敬語で話しかけましょう。砕けた言葉を使うのは同僚など普段気軽に話している人に対するコミュニケーションだけにとどめましょう。
絵文字の多様がメンバー同士の距離を縮めていく
Slackは絵文字などによる反応でコミュニケーションを円滑にすることができます。絵文字を選択してクリックするだけで簡単に意思を伝えることができます。これはキーボードで文字をタイプしなくても反応を送れるので、気軽に素早く反応できます。
ただ、デフォルトで用意されているものは使い方が難しいものが多いため、自分自身で絵文字を追加するのがお勧めです。とはいえ自分で作るような時間もないので、GitHub上で公開されていたものを使用しました。
その中でも使いやすいと感じた絵文字を紹介します。絵文字というか文字ですが、簡単に意思を伝えられるので重宝しました。
Slackは外部アプリケーションや、Webサイトとの連携が簡単にできます。通知を受けるツールとして利用されている方は多いと思いますが、そういった使い方をする上でお勧めしたいのは、通知用のチャンネルを一つにすることです。Slack以外にも様々なツールを使っていたのですが、通知機能があるアプリケーションはすべてそのチャンネルに通知を流しました。
通知用のチャンネルの名前は #notifications としました。
通知のチャンネルはアプリケーションや用途別にわけたくなりますが、運用をしばらく続けていると、通知を見る前にチャンネルだけを見て見るべきかどうかをスクリーニングしてしまい、通知を自分から見に行かなくなります。通知が目にふれなくなってしまい、たまに起こる重要な情報を見逃してしまう恐れがあります。
それを防ぐためにあえて一つのチャンネルにすべての通知を流すと、普段目にすることのないような通知まで目にすることができます。
大きく成長した組織でこれをやると、通知が膨大で逆に見落とす通知が多くなるはずなので、小さなプロジェクトだからこそできることだと思います。
通知するように設定していたツールは以下の通りです。
- GitLab(CIに関する通知を含む)
- Qiita Team
その他開発するプロダクトのバックエンドにFirebaseを使用していたため、Firebase上で通知がある場合は通知されるように設定を行いました。しかし、開発中は一度も通知がくることはなかったので、必要なかったかもしれません。
その他、デザイナーがFigmaを使用していたため、Figmaへのコメントや操作も通知のチャンネルに流したかったのですが、少々複雑な設定が必要なだったため今回は断念しました。
しかし、それは特に問題にならなかったと思いました。
Slackは、チャンネルを自由に作成することができますが、特に何も言わなければ、使用しないチャンネルが量産されてしまう可能性があり収集がつかなくなる可能性もあります。先述した通知チャンネルである #notifications をのぞき、以下のチャンネルを作りました。
- #general
- #project
- #status_xxxxx
#general にはプロジェクトに関係ない雑談をするチャンネルです。「今日いけません」とか「このサイトの記事最高！」といった感じコメントを書いていました。
#project はプロジェクトに関することを話すチャンネルです。決定事項、相談事、作業に関することを書いていきます。一つのチャンネルに書いてあるため、ログが時間軸で追えるので基本的に一つのチャンネルに書いていきます。
#status_xxxxx このチャンネルは独り言をつぶやくチャンネルで、xxxxxの部分は個人の名前になっており、人数分のチャンネルを作りました。個人に一つ割り当てるチャンネルですが、人に見られたくないことをつぶやくためのチャンネルではありません。チャンネルには全員が参加して誰の目にも触れるようにしていました。
このチャンネルは、適当に思ったことを書いていくチャンネルです。気になることがあれば誰でもコメントを付けることができるものです。このチャンネルは思考を整理するためにアウトプットを繰り返すことで、壁打ち役としての役割も果たします。
自分が困っていることをテキストに起こすことにより、頭の中が整理され、課題や問題の解決がすばやくできるようになるといった効果が期待できます。もちろん内容を見て誰かが回答をくれるといったことも期待できます。
※ 本当に適当に書いていたので、上記スクリーンショットのFirebaseに関する内容は間違っています。
Slackはメンバーとの接点の中心にしたかったのでメンバーには積極的に使ってもらう必要がありました。とはいえ、ただ「使って」というだけでは使われなくなってしまうものです。
そこで私が工夫したのは、テキストが書き込まれたら、少なくとも絵文字で反応するようにしたことです。すべてに対しての反応は無理かもしれませんが、「見ているよ」という意思を表すのと同時に、Slack自体の使い方を伝えるという意味もあります。
また、自分自身のスマホにもSlackを入れ、PUSH通知でわかるように設定することで、できるだけ絵文字だけでもすぐに反応ができるようにしていました。
Qiita Teamに書きためたい記事を書く
Slackは会話するのには適しているのですが、書いた内容は流れていってしまうため開発手順や、マニュアルを記録するのには向いていません。それを解決するために書きためておくことができるサービスであるQiita Teamを選択しました。
Qiita Teamは有料のサービスですが私自身がアカウントを持っていたこともあって導入しました。Qiita TeamはQiitaと同じような形で特定の人たちと記事を共有することができるサービスです。
Qiita Teamの記事には、作成したプロダクトのインストール手順や、打ち合わせの議事録をまとめました。
Qiita Teamには iframe を埋め込むことができるため、設計書であるdraw.ioの図を埋め込んで設計書としても使用しました。
Figmaがエンジニアとデザイナーを繋ぐ
プロダクトのデザインはFigmaで行いました。プロダクトの仕様をFigmaのコメントに書き、仕様はFigmaさえみておけばわかることを目指したのですが、思惑通りにいきませんでした。これはSlackを接点の中心にしたためです。このあたりはもっと工夫する必要があったかもしれません。
ここで重要なことは、思惑通りにいかなかったとはいえ使用を強要しなかったことです。この記事で紹介したツール以外にも開発言語やフレームワークなど、覚えなくてはならないことがたくさんあり、覚えることが多いとそれだけで疲弊してしまいそうだったので、メンバーの様子を見て、Figmaを仕様の確認で積極的に使おうということはやめました。
Googleスプレッドシートが最初のコミュニケーションを助ける
様々なツールでコミュニケーションをとってきたことがわかったと思いますが、本記事で説明したようなプロダクト開発を目指してすべてのツールをいきなり使おうとするのは避けたほうがいいと思います。
使い慣れているものや、すぐに用意できるものでないと、使い方を模索しているうちに時間が経過してしまいます。
はじめてチームが組織されたときに使ったツールはGoogleスプレッドシートでした。開発するプロダクトの方針が決まるまではGoogleスプレッドシートを使っていましたが、プロダクトを作り始めようとなった段階で、もっとコミュニケーションするのに適したツールを使おうという話になりました。
Googleスプレッドシートは会話をするツールではないので、テキストコミュニケーションを行うツールとしては適さないし、記事を残すツールとしても使いにくい、デザインをするツールでもありません。
ここで私はSlackを提案しました。Slackは普段から業務で使っていることや、普段Slackを使っていないメンバーからも使ってみたいという意見もあり、全員の合意がとれたため採用しました。
もちろん私自身、Slackを使うなら、ただしく運用できる自信があって提案したので、責任をもって運用していくことを決断していました。
Qiita Teamはアカウントを持っていたことが理由として大きいですが、Markdownで書かなければなりません。しかし、メンバー全員がMarkdownを使用できたことから、Qiitaのような普段から触れているサービスを使うことが最適だと考えたため、Qiita Teamを選択しました。。
Figmaはデザイナーが使い慣れているため、デザイナーの希望があって採用しました。
使うツールが決まった後、Googleスプレッドシートに書いた内容はQiita Teamに書き写したりする必要はありましたが、これは使うツールを限定することで情報が分散することを防ぐために実施しました。
最後に
私は普段、エンジニアとして働いています。普段の仕事にはリスクがつきまといますし、大きな決断を必要とすることもあります。そういった場合には判断を仰ぐ管理者の立場が重要になってきたりするのですが、今回の挑戦では自分たちの判断のみで作業が進められるといったこともあり、対等な立場の人たちが集まったことで、メンバーの動きがバラバラにならないように心がけました。
ツールの功績ばかりを取り上げましたが、メンバーが一丸となったからこそプロダクトの完成になったのは言うまでもありません。ツールを使ったのは私たちなので、全員が正しく動けるようにツールを使えた結果だと信じています。
短期間でしたが良いチームになりました。このチームでリーダーを務められたことを誇りに思います。
本記事が、皆様の参考になれば幸いです。ここまで読んでいただきましてありがとうございました！