電子ブック

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

ソフトウェアエンジニアリングのための適応可能なコラボレーションハブ

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

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

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

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

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

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

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

想像したよりも大きく成長した今日の Slack。この成長には、あらゆる規模の開発者チームに採用された点が寄与しています。

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

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

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

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

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

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

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

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

適応するコラボレーションハブの出現

実際に使ったことのない人には、メッセージングアプリとして捉えられがちな Slack ですが、そんな枠には到底収まらない力を秘めた、これまでには存在しなかった全く新しいソリューションです。

さまざまなチームのワークスタイル、既存のソフトウェア、ひいては… 変化に適応するその特質から、Slack では自社のソリューションを「適応するコラボレーションハブ」と呼ぶに至りました。

3つの要素を1つのツールにまとめる、適応するコラボレーションハブ

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

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

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

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

製品仕様や新機能についての議論など、関連するドキュメント、会話や意思決定すべてが誰にでも見つかるたったひとつのハブに集結。

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

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

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

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

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

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

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

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

SlackシニアエンジニアMalika Rajvanshy

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

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

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

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

プランニング

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

  • 新製品や機能のプロセス全体を1つのチャンネルでキックオフ

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

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

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

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

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

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

コーディング

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

コーディング開始の段階では、チームのコラボレーションを Slack がこんな形でサポートします。

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

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

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

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

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

  • 朝礼の新しい形

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

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

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

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

Slack の特長

優れた拡張性

Slack はシームレスなチームワークの実現するコラボレーションハブとして、特にその力を発揮します。そのため、Trello、GitHub や Jenkins など、チームですでに使っているソフトウェアの仕事を横取りするようなことはしません。

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

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

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

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

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

テスト

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

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

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

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

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

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

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

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

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

Jenkins との連携

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

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

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

リリース

Slack は、ワークフローと通知の自動化をサポートすることで、コードをプロダクション環境にプッシュするのに役立ちます。

継続的な配信では、小規模なコードリリースを頻繁かつ大量にデプロイする必要が生じます。Slack は、エンジニアリングチームがその一部を合理化するのに役立ちます。

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

デプロイの進捗に伴い、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 がソフトウェアチームの業務の合理化、自動化、そしてスピードアップにどうに役立つかを簡単に紹介してきました。主なポイントをまとめると、以下のとおりです。

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

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

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

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

    脚注

    1. IDC Research, The Business Value of Slack (Slack 提供、2017年)

    この教材は役に立ちましたか?

    0/600

    助かります!

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

    了解です!

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

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