Slack がソフトウェアエンジニアリングに愛される理由

開発者の成功を支援する Slack はどのように形作られたのでしょうか?Slack の原点からエンジニアリングの最新ベストプラクティスに至るまで、さまざまな内容をご紹介します

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

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

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

残念ながらゲーム自体は不調に終わったので、代わりに自分たちが開発したこのコラボレーションツールに注力することにしました。これが吉と出て、最終的には、チームメンバーが一緒に作業を進めるための効率化ツールという、市場の求める製品を作り上げることができたのです。

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

想像したよりも大きく成長した今日の Slack。この成長には、あらゆる規模の開発者チームに採用された点が寄与しています。ご存知のとおり、Slack はほぼすべての部門や分野で使われていますが、すべては「ソフトウェアエンジニアリング」から始まりました。今でもたくさんのユーザーがこの分野で Slack を愛用してくれており、私たち Slack チームの原動力となっています。開発者の日々の業務に直接インパクトをもたらすソリューションを開発できるという喜びが、さらなるやる気を生み出してくれます。

このガイドでは、開発者にとって便利な Slack 活用方法をいくつか簡単に紹介しています。Slack がソフトウェアエンジニアに愛され続ける理由を少しでも理解していただければ幸いです。

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

Slack は、技術分野以外のあらゆるタイプのチームにも日々使用されています。どうやらどの分野でも、Slack はそれぞれの業務に有機的に適応していくようです。

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

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

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

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

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

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

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

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

ナレッジは発見できてこそ活用できるものです。対して、メールの添付ファイルは目に留まりにくく、cc に入っていないメンバーには表示されません。一方 Slack では、製品仕様や新機能についての議論など、関連するドキュメントや会話、意思決定すべてを 1 か所で誰でも見つけることができます。

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

Slack では、開発者が毎日、長時間使うソフトウェア(GitHub、Jira、Jenkins、Trello など)を、業務関連の会話が交わされる場所に集約できます。こうすることで、複数アプリでの作業につきもののタブやウィンドウの切り替えを最小限に抑えることができます。

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

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

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

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

SlackSenior EngineerMalika Rajvanshy

Slack によりエンジニアリングチームの生産性が向上するという私たちの主張は、IDC の調査でも数値的に証明されています

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

Slack 社内の開発者チームは日々 Slack を愛用しています。ソフトウェア開発に Slack を使うユーザーとしては最も高度な部類に属することでしょう。それでも、ソフトウェアチームが導入している新しいユースケース、アプリ、インテグレーションには日々驚かされています。

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

計画

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

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

#feature-新アプリ」などのチャンネル名はどうでしょう?プロジェクトのスコープ決定、機能要件の収集、代替案についての話し合い、機能と UX 関連の基本的な意思決定などが 1 か所でできるようになります。

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

Slack は Google ドキュメントとスムーズに連携するため、協力者も新しい参加者も同様にすべてのドキュメントにワンクリックでアクセスできます。

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

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

コード

Slack を活用することで、開発者チームはコードベース全体を支える多数のパーツそれぞれを調整し、開発をスピードアップし、品質を向上させることができます。コーディング開始の段階では、チームのコラボレーションを Slack がこんな形でサポートします。

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

エンジニアリングや QA 関連の日常業務 : プルリクエスト、コードのマージ、設計の改訂、毎日の定例会議やディスカッションなど。

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

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

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

  • 朝礼の新しい形

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

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

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

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

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

Slack の特長

優れた拡張性

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

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

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

IBMSenior Software EngineerThomas Lawless 氏

こうしたインテグレーションの活用で、開発者は本来の目的である「思い通りに動作するシステムの開発」に集中して取り組むことができるようになります。このガイドでご紹介するユースケースは、ほんの一例にすぎません。ユーザーであるソフトウェアチームの数だけ、Slack の使い方が存在します。

テスト

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

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

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

QA チームの公開のフォーラムでのコラボレーションを実現。

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

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

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

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

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

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

Jenkins との連携

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

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

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

リリース

継続的な配信では、小規模なコードリリースを頻繁かつ大量にデプロイする必要が生じます。Slack を使えば、ワークフローや通知を自動化することでエンジニアリングチームはその一部を合理化できます。

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

ステージングの更新を投稿する Slack の Deploy Wizard インテグレーション

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

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

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

オペレーション

開発チームは、Slack を使って問題のチケットをトリアージし、驚く速さでインシデントを発見し、問題を精査します。

  • すべての問題を「#triage-製品名」チャンネル経由に

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

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

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

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

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

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

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

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

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

エンジニアの視点から

ソフトウェアエンジニアの獲得競争が激化する昨今、人材を維持するためには、従業員に最高の職場体験を提供することが欠かせません。こうした取り組みには、適切なツールの導入がカギとなります。業務上の摩擦の軽減、透明性の向上、日常的なタスクの自動化、チーム間の共同作業の支援など、よりよい仕事環境の構築に役立てることができます。

Slack を使っているソフトウェアエンジニアリングチームに聞いてみましょう。チャンネル、アプリやインテグレーションをどう使っているか。そして、もし Slack が使えなくなったらどうなるか、尋ねてみましょう。

新任開発者向けの研修

新任開発者 2 人がチームに参加。業務にできるだけ早く慣れてもらうには?

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

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

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

Google ドキュメント、Dropbox、OneDrive の場合、ドキュメントは常に最新の状態に保たれます。また、これまでの会話、意思決定や関係者をすべてチェックすることもできます。これからの開発者導入研修には、Slack の活用が欠かせません。

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

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

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

ソフトウェアエンジニアに愛されるツール : 実際のユーザーであるエンジニアに愛用されるツールというのは、導入後も次第に使用範囲が拡大してゆくツールとなります。

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

IBMSenior Software EngineerThomas Lawless 氏

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

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

0/600

助かります!

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

了解です!

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

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