Slack がエンジニアリングチーム(あなたのチームを含め)に愛される理由

Slack のこれまで(あっという間でしたね!)

2009 年当時、Slack の前身は、Glitch という大規模なマルチプレイヤー型ゲームを開発するソフトウェアエンジニアが集まる小さなチームでした。

当初はインターネット・リレー・チャット(IRC のことです。覚えてます?)で情報共有を始めましたが、ゲームの開発作業が進むにつれて、IRC チャンネルの基本的なコミュニケーション機能では次第に物足りなくなってきました。そこで、自分たちで機能の追加や調整を加え、作業を効率化するための新しい方法を模索し始めたのです。

残念ながらゲーム自体は不調に終わったので、代わりに自分たちが開発したこのコラボレーションツールに注力することにしました。

これが吉と出て、最終的には、チームメンバーが一緒に作業を進めるための効率化ツールという、市場の求める製品を作り上げることができたのです。

「デザイン」だけにとらわれず、開発に取り組んだのがよかったのかもしれません。エゴも何もなく、想定ユーザーすらいませんでした。自分たち自身がユーザーだったからです。

こうして Slack は生まれました。

Slack は、あらゆる規模の開発者チームに採用され、想定よりもはるかに大きく成長しました。

ご存知のとおり、Slack はほぼすべての部門や分野で使われていますが、すべては「ソフトウェアエンジニアリング」から始まりました。今でもたくさんのユーザーがこの分野で Slack を愛用してくれていて、それがわたしたち Slack チームの原動力となっています。

開発者の日々の業務に直接インパクトをもたらすソリューションを開発できるという喜びが、さらなるやる気を生み出してくれます。

この電子ブックでは、開発者にとって便利な Slack 活用方法をいくつか簡単に紹介しています。

Slack がソフトウェアエンジニアに愛され続ける理由を少しでも理解していただければ幸いです。

Slack がソフトウェアエンジニアリングに最適な理由

Slack は、技術分野以外のあらゆるタイプのチームにも日々使用されています。Slack は、どの分野でもそれぞれの業務にぴったりのツールとなるようですが、

その中でも Slack が特に適している分野は、かなり専門性の高い業務であるソフトウェアエンジニアリングです。

こうした要素は今や、あらゆる業務に該当するように思えますが、理想的なユースケースはやはりソフトウェアエンジニアリングです。なぜなら、メールや対面での会議では実現できないようなコラボレーションが必要な分野だからです。こうした種類の業務には、新しい形のコラボレーションが求められます。

Slack : チャンネルベースのメッセージングプラットフォーム

実際に使ったことのない人には、メッセージングアプリとして捉えられがちな Slack ですが、そんな枠には到底収まらない力を秘めた、 さまざまなチームのワークスタイル、既存のソフトウェア、ひいては… 変化に適応する特質を持ちます。

  • チャンネルベースのメッセージング

特定のタスク、プロジェクト、問題別に専用のチャンネルを自由に作成できます。開発者全員が集まり新しいウェブサイト関連の作業を共同で行う「#開発-新サイト」チャンネル、チームメンバーがモバイルアプリのバグ修正に取り組む「#トリアージ-モバイルアプリ」チャンネルなど、用途はさまざまです。

チャンネルは、適切なメンバーがテーマに応じてタイミングよく参加できるため、1 対 1 のメッセージや非公開のメールスレッドよりもはるかに使いやすい便利なツールです。

  • 検索可能なナレッジベース

製品仕様や新機能についての議論など、関連するドキュメント、会話や意思決定すべてを誰でも見つけることのできるハブです。

それに対して、メールの添付ファイルは目に留まりにくく、cc に入っていないメンバーには表示されません。ナレッジは発見できてこそ活用できるものです。

  • ソフトウェアを 1 か所にまとめるインテグレーション

メンバーが毎日、長時間使うソフトウェア(GitHub、Jira、Jenkins、Trello など)を、業務関連の会話が交わされる場所に集約できます。

メンバーをバラバラのアプリにログインさせるのではなく、すべてのアプリをメンバーのもとに集めることで、複数アプリでの作業につきもののタブやウィンドウの切り替えを最小化できます。

注意 : これら 3 つの要素を一元化することで、それぞれの要素が大幅にパワーアップします。束ねた矢が折れにくいとする「三矢の教え」と同じです。

ソフトウェアエンジニアリングチームにとってのメリット

適切なチャンネルベースのメッセージングプラットフォームの導入は、すべてのエンジニアリングチームにとって最重要事項となる、優れたコードの迅速な提供、バグ解消速度の向上、開発者体験の改善(=エンジニアの幸福度向上)といった面で直接影響を及ぼします。これだけのメリットがあるソフトウェアなら、チェックしない手はありません。

「Slack は生きたドキュメントハブとして機能しており、すべてが検索可能です」。

SlackシニアエンジニアMalika Rajvanshy

Slack によりエンジニアリングチームの生産性が向上するという Slack の主張は、IDC の調査でも数値的に証明されています。Slack を使用して業務を効率化しているエンジニアリングチーム。

Slack でソフトウェアエンジニアリングプロセス全体を効率化

Slack 社内の開発者チームは当然ながら、日々 Slack を愛用しています。ソフトウェア開発に Slack を使うユーザーの中でも特に高度な利用方法でこのツールを使っています。それでも、ソフトウェアチームが使用している新しいユースケース、アプリやインテグレーションには日々驚かされています。

では、こうした内容をソフトウェア開発サイクルの段階別に見てみましょう。

計画

製品マネージャーやデザイナー、エンジニアが開発内容やその理由を話し合い、最終的な合意に至るまでのプロセスでも、Slack が役立ちます。

Slack チャンネルの詳細
アプリのユーザー向けフィードバックフォームについて話し合っている Slack スレッド
  • 新製品や機能の計画プロセス全体を 1 つのチャンネルで始める

「#機能-新アプリ」などのチャンネル名はどうでしょう?

これで、プロジェクトのスコープ決定、機能要件の収集、代替案についての話し合い、機能と UX 関連の基本的な意思決定などが 1 か所でできるようになります。

  • Slack でドキュメントを共有すればすべてが検索可能に

既存のチャンネル参加者も新規のプロジェクト参加者もみんなで活用できます。Slack はスムーズに Google ドキュメントと連携するため、すべてのドキュメントにワンクリックでアクセスできます。

  • わからない点はチャンネルで質問

質問を投稿すれば、解決策が集まるうえ、メンバー全員の目に留まります。質問と回答の内容はアーカイブされ、その後の検索も簡単です。

コード

Slack を活用することで、開発者チームはコードベース全体を支える多数のパーツそれぞれを調整し、開発をスピードアップし、品質を向上させることができます。

コーディング開始の段階では、チームの共同作業を Slack がこんな形でサポートします。

  • 「#開発-製品名」チャンネルにすべてを集約

プルリクエスト、コードのマージ、設計の改訂、毎日の定例会議やディスカッションなどのエンジニアリングや QA 関連の日常業務を 1 か所に集約できます。

  • コードレビューのための一元化されたハブ

Slack は、バージョンブランチや機能ブランチの開発、マージされたマスターからのものを含め、コードのブランチ、マージ、レビューやリリースに使うあらゆるプロセスに対応します。

Git インテグレーション(GitHub、Bitbucket やその他のリポジトリ)を使えば、すべての変更通知を Slack で受信できます。

  • スタンドアップ・ミーティングの新しい形

スタンドアップ・ミーティングは、アジャイル開発に欠かせないものですが、わざわざ対面で行う必要はありません。開発チームでは、毎朝または毎週のミーティングを Slack で行い、必要がある場合にのみ対面形式とすることにしています(開発者にとっては、会議が少ない方がありがたいものです)。

Standuply などのソフトウェアとのインテグレーションにより、サマリーが自動で Slack に送信されるため、チームでの目標やタスクの共有、事業関連の指標の追跡、議事録の投稿、メンバーの進捗や満足度のモニタリングもしやすくなります。

Slack での Checkpoint のインテグレーションにより、チャンネルでプルリクエストを投稿

コードの再利用を推進 : 効率的なエンジニアリングチームの運営のコアとなるのがコードの再利用です。ただしこれは、数百人もの開発者がさまざまな多数のプロジェクトに参加している環境では、簡単なものではありません。新しいコードを作成する前に、開発者が Slack チャンネルすべてを検索すれば、すでに同様のものを誰かが作成していないかどうかを確認できます。その後、適切なチャンネルで「日付ピッカーはもう作った?」と質問するだけで、 作業の重複を防げます。

スニペットを活用してコードを作成・共有 : スニペットを使えばコードの共有、ファイルの構成がしやすくなり、Slack で直接ファイルログも作成できます。ほかのメンバーは、そのファイルをダウンロードしたり、RAW ファイルを参照したり、コメントを残したりすることができます。

Slack の特長

優れた拡張性

Slack は、PagerDuty、GitHub や Jenkins など、チームですでに使っているソフトウェアの仕事を横取りするようなことはしません。

その代わりに、Slack はこうした多彩なアプリを 1 つにまとめ、これらアプリからの関連情報を業務についての話し合いが行われるチャンネルへと集約します(そして、こうしたアプリのアクションを Slack 内からトリガーする形で実行します)。

「Slack が統合されているものはすべてオンにしてあります。インテグレーション機能は本当に便利で、プロセス内の手順を大幅にカットできました」。

IBMシニアソフトウェアエンジニアThomas Lawless 氏

こうしたインテグレーションの活用で、開発者は本来の目的である「思い通りに動作するシステムの開発」に集中して取り組むことができるようになります。

この電子ブックで紹介しているユースケースは、ほんの一例に過ぎません。ユーザーであるソフトウェアチームの数だけ、Slack の使い方が存在します。

テスト

今日の開発/デプロイプロセスにはテスト工程が組み込まれています。Slack は、透明性の高い、コラボレーション型のダイナミックなテストアプローチをサポートしています。

新しいコードチャンクをマージするたび、継続的インテグレーションによってテストスイートが実行されます。Slack は、以下の大小さまざまな方法でプロセスを効率化します。

  • 「#テスト–機能」チャンネルが QA を調整

公開フォーラムで QA チームと開発者の共同作業を実現します。

  • Jira のインテグレーションでテストのワークフローを自動化

Slack 内で課題を把握し、自動でパイプラインに流し込み、Jira からカスタマイズ可能な通知をチャンネルに送信します。課題をメンバーにすばやく割り当て、適切な場所で記録できます。

Slack で変更リクエストを新しいチャンネルに自動で移動させ、Trello や Asana を同時に更新しているチームもあります。

  • クライアント別にチャンネルを作成

iOS、Android、ウェブに分けて専用のテストチャンネルを作成できます。

Slack での Jira スラッシュコマンド

Jenkins との連携

Jenkins は、継続的インテグレーションサーバーとして多くのチームで使われています。早い段階から、さまざまなチームで Jenkins を Slack と連携させ、あらゆる開発関連の定型タスクの自動化に活用する動きが見られてきました。

例えば、あるソフトウェアチームの Slack カスタムインテグレーションでは、開発者がプルリクエストを開くたびに大規模なテストスイートを実行する Jenkins サーバーがスピンアップされます。

テストが実行されると、適切な Slack チャンネルに通知がポップアップ表示されます。コードのテストが失敗した場合は、開発者に通知が送信されます。

リリース

Slack は、ワークフローと通知の自動化をサポートしているため、コードを本番環境にプッシュするのに役立ちます。

継続的デリバリーでは、小規模なコードリリースを頻繁かつ大量にデプロイする必要が生じます。Slack を使えば、エンジニアリングチームは、その一部を効率化できます。

例 : Slack のソフトウェアチームでは、運用サイドと連携してチャンネル内のコードのステータスを伝える「Deploy Wizard」というアプリを作成しました。これは、「カナリア」ステージ(突然の失敗を把握するための小規模なリリース)から始まり、10%、25%、75%、そして 100% のユーザーベースへと対象を拡大するものです。

Slack での Deploy Wizard のインテグレーションにより、進捗のアップデートを投稿

デプロイの進捗に伴い、Deploy Wizard が適切な開発者とチャンネルに Slack で通知を送信します。このプロセスはすべて、勤務中のデプロイ管理者(訓練を受けたエンジニアが 3 時間シフトで対応)が管理します。

開発者がステージング環境でコードをテストする場合は、マージリクエストでコードを指定します。開発者がコードをテストしたことをデプロイチャンネルで報告するまで、デプロイはステージング環境で停止します。

スラッシュコマンド(/deploy_productname_staging など)で Slack から直接デプロイをトリガーしている開発チームもあります。デプロイが成功した場合は、詳細をチェックするためのリンク(または、プロダクション環境にプッシュするボタン)付きの自動メッセージが表示されます。

オペレーション

開発チームは、Slack を使って問題のチケットをトリアージし、問題の精査やバグの解消を行います。

  • すべての問題を「#トリアージ-製品名」チャンネル経由に

カスタマーサポートからの報告(手動または Zendesk などのインテグレーション経由)も含みます。

  • インテグレーションですべてのアラートを集約

開発者にメールやダッシュボードをチェックしてもらう代わりに Slack にアラートを集約すれば、対応に最も適したメンバーがすぐに見つかります。

PagerDuty イベントや Asana チケットを 1 か所に集め、適切なチャンネルへ投稿することで、インシデント対応の所要時間が短縮され、トリアージのプロセス全体が確立されます。チームメンバーが共同で、Slack から直接インシデントのトリガー、閲覧、認識、解決に取り組むことができます。

同様に、New Relic からのウェブ、トランザクション、サーバー、モバイルといった種類のアラートすべてを Slack チャンネルで取得すれば、対応もスピーディになります。インシデントに関心があるメンバーなら誰でも、情報すべてが集まるチャンネルに参加して詳細を確認できるうえ、インシデント対応担当者が頻繁に状況報告する必要もなくなります。

絵文字とリアク字で問題のトリアージ化とワークフローのトリガーをサポート

チームメンバーの対応状況をひと目で把握する以外にも、リアク字は自動ワークフローのトリガーにも使用できます。アプリで絵文字やリアク字を収集すれば、集計、フラグづけ、対応もしやすくなります。未対応の問題(チェックマークなしの目の絵文字)はすべて PagerDuty に表示されます。

「#意思決定」チャンネルの自動化 : なんらかの意思決定があったことを伝えるのに、小槌の絵文字を活用しているチームもあります。その後、ボットがこれらの決定を「#意思決定」チャンネルへプッシュします。このチャンネルでは、経営陣が意思決定の流れを確認し、チームメンバーが簡単に内容を検索できます。

加えて、これらを収集し、専用チャンネルで報告するボットも作成しています。

エンジニアの視点から

ソフトウェアエンジニアの獲得競争が激化する昨今、人材を維持するためには、従業員に最高の職場体験を提供することが欠かせません。

こうした取り組みには、適切なツールの導入がカギとなります。業務上の摩擦の軽減、透明性の向上、日常的なタスクの自動化、チーム間の共同作業の支援など、より良い仕事環境の構築に役立てることができます。

Slack を使っているソフトウェアエンジニアリングチームに聞いてみましょう。

チャンネル、アプリ、インテグレーションをどう使っているか。

そして、もし Slack が使えなくなったらどうなるか、尋ねてみましょう。

新任開発者向けの研修

新任開発者 2 人がチームに参加するとしましょう。業務にできるだけ早く慣れてもらうにはどうすればいいでしょうか?

これまで : 多数の対面研修とメールスレッドの大量転送で、あとは本人のやる気まかせ。

これから : 「#開発–新製品」チャンネルへ招待して以下のようなピン留めしたポストを確認してもらう。

  • 製品仕様
  • 技術仕様
  • 設計

(Google ドキュメント、Dropbox、OneDrive の場合、ドキュメントは常に最新の状態に保たれます)

また、これまでの会話、意思決定や関係者をすべてチェックすることもできます。これからの開発者導入研修には、Slack の活用が欠かせません。

ソフトウェアエンジニアリングでの Slack 活用法 - まとめ

本電子ブックでは、Slack がソフトウェアチームの業務の合理化、自動化、そしてスピードアップにどう役立つかを簡単に紹介してきました。主なポイントをまとめると、以下のとおりです。

  • 新たに登場した「ハブ」という概念 : Slack は、エンジニアの新しい働き方を支援する適応可能なコラボレーションハブです。単なるメッセージングアプリではありません。
  • 群を抜く柔軟性 : チームがワークスペース、チャンネル、アプリやインテグレーションをチーム独自の「自分たちらしい」働き方に合わせてカスタマイズ可能です。
  • 既存のソフトウェアの能力を最大限に引き出すソリューション : 開発、製品、QA、サポートチームの業務を Slack に集約すれば、GitHub、Bitbucket、Jenkins、Jira、PagerDuty、New Relic、Zendesk など、チームが使っているあらゆるツールをさらに効率的に使えるようになります。
  • 開発サイクルのあらゆるステージでバリューを付加 : 計画から開発、テスト、運用、デプロイやバグの解消に至るまですべてのステージに対応できます。
  • ソフトウェアエンジニアに愛されるツール : 実際のユーザーであるエンジニアに愛用されるツールは、導入後も次第に使用範囲を拡大してゆくツールとなります。

「当社には、『エンドツーエンドのデリバリーパイプライン』と呼ばれる、ソースコードからプロダクション展開まで一貫した仕組みがあります。そして今や、その仕組みの中の重要なマイルストーンのすべてに Slack を組み込んでいるのです」。

IBMシニアソフトウェアエンジニアThomas Lawless 氏

詳細に関心をお持ちであれば、ぜひデモで実際にご覧ください。または、Slack の開発者から実際の Slack インスタンスを披露することも可能です。

脚注

  1. IDC research, The Business Value of Slack, 2017, sponsored by Slack

この情報はお役に立ちましたか?

0/600

助かります!

ご意見ありがとうございました!

了解です!

ご意見ありがとうございました!

うーん、システムがなにか不具合を起こしてるみたいです。後でもう一度お試しください。