IBM のエンジニアリングチームのメンバーがハードウェアを見ている

IBM のエンジニアリングチームが Slack を開発ライフサイクルに活用

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

IBMSenior Software EngineerThomas Lawless

IBM のシニアソフトウェアエンジニア Thomas Lawless さんのチームでは、前日に仕事がどこまで進んでいようと、毎朝必ずレビューの必要なコードの確認から仕事を始めるのが日課になっていました。「まるで毎朝、プロセスを作り直しているみたいな感じでした」と Lawless さんは言います。

IBM 最大のイントラネットアプリケーションのプロダクション、デプロイ、配信の監督責任者である Lawless さん。「僕は、開発、持続的インテグレーション、テストとデプロイの自動化とオペレーションなどを担当しているので、どんな日もさまざまなチームのメンバー 40~50 人と関わっています」。

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

IBMsenior software engineerThomas Lawless

 

Lawless さんの主な業務の一つは、運営の改善と配信のスピードアップを図るための開発技術とサービスの導入。そんな中、IBM 社内のチーム間でのコミュニケーションハブとして Slack を使い始めたのは今から 1 年前。システムからの警告や他のサービスからの通知といった非人間的コミュニケーションを集約するのに Slack が便利なことにすぐに気づいたと言います。

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

Slack を活用した開発と展開プロセスの管理

IBM は、チームの活動を #development-team といった Slack のパブリックチャンネルに集約。チームのメンバーはここで問題をオープンに議論することもできるうえ、ほかのチームの専門家が自由に参加して意見を述べることもできます。

チームチャンネルには、メンバーのメッセージに加えて、使用している数々のアプリケーションからのシステムアラートも含まれます。例えば、開発者がユーザーストーリーをソースコードのレビューに提出すると、チームの Slack チャンネル内でシステムが通知をトリガーし、メンバーにレビューすべきコードがあることを知らせます。レビュー担当者はその Slack メッセージから直接システムにアクセスしてコードをレビューできます。

「Slack の導入前は、開発者はまずレビューに適任と思われる人を探し、その人にメールするか、1 対 1 でチャットしなければなりませんでした」と Lawless さん。

チームのワークフローを Slack で整備することで、個々のコードレビューについて必要に応じて通知が届き、それに基づいて Slack からすぐに対応できるようになったので、仕事をスムーズに運べるようになりました。

システムアラートを中心にチームを結集し、インシデント管理を向上

参考までに、IBM でよく使われているチームチャンネルと、そこで交わされる会話や通知の例を以下にまとめました。

  • #help-services: プルリクエスト(PR)通知の収集によりピアコードレビューの自動化を図り、リクエストの承認時はチームにアラートで通知。チームメンバーは、アプリケーションを切り替えなくても最新情報を確認できます。ビルド変更ステータスについての通知は、Jenkins/Travis CI インテグレーションも利用しています。
  • #help-deployments: コード変更がテストの自動化に及んでデプロイエラーが発生したことを通知します。
  • #help-tasks: ジョブの一括処理エラーについての通知を投稿します。
  • #starfleet-monitoring: ランタイムモニタリングとインシデント管理のために、NewRelic、Splunk、PagerDuty からの通知がここにプッシュされます。

「これらのインシデントチャンネルはある意味、監査証跡のような役割を果たしており、私たちは事後検証の根拠として使用しています。履歴がすべて手元に残るので、思い出す必要がないことが最大の利点ですね」

IBMsenior software engineerThomas Lawless

IBM では、エラーのアラートやインシデントのポップアップ通知が Slack に表示されると、関連チームのメンバーがすぐに新しいインシデント専用チャンネルを立ち上げ、解決策を話し合ったり、必要に応じてエキスパートを招待したりしています。

問題が解決したあとは、解決への過程を記録したファイル、スクリーンショット、エラーメッセージを含むインシデント全体の記録とアラートがすべてチームの手元に残ります。

「これらのインシデントチャンネルはある意味、監査証跡のような役割を果たしており、私たちは事後検証の根拠として使用しています。履歴がすべて手元に残るので、思い出す必要がないことが最大の利点ですね」と Lawless さん。

最近は、さまざまなサービスプロバイダーとのやり取りにも Slack を使っていると言います。問題や質問があっても、長々としたやり取りをせず簡単に相談できるので、ほとんどの取引先がチーム全体でプライベートの Slack チャンネルを共有することに前向きな姿勢を取っています。

ほんの数ステップで仕事の効率を大幅にアップ

Lawless さんとそのチームは、初期ソースコードの作成とテストから最終的なデプロイまで、開発のあらゆる段階に Slack を組み込んだところ、毎朝レビューすべき新しいコードの確認に時間を費やす代わりに、前日に終えたところから仕事を再開できるようになりました。

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