Autodesk での製品体験と企業文化に一体感を

1982 年創業のソフトウェア企業 Autodesk は、建築、エンジニアリング、建設、製造、メディアやエンターテインメント業界で活用されている 140 以上の製品を開発しています。あなたの街にそびえ立つあの高層ビルも、Autodesk のパワフルなソフトウェアを使って建設された可能性は大いにあります。また、過去 20 年間のアカデミー視覚効果賞に輝いた映画作品をご存知ですか？こうした作品の制作にも Autodesk が活躍しています。2017 年の候補作品 5 本すべてに同社のツールが使用されていました。

Autodesk は今、新しい業界へと事業を拡大するために新しい顧客層を開拓しています。しかし、Autodesk の 100 以上ある製品のうちどれが事業に適しているかは、必ずしも明かになっていません。「私たちはこれまで、非常にバーティカルなやり方で開発を行ってきました」と話してくれたのは、Autodesk のオープンソースイニシアチブ Open@ADSK の担当ディレクターである Guy Martin さんです。「しかしこの方法では今後 50 億ドルの増収は見込めません」。

Autodesk の潜在顧客は、デスクトップだけでなく、クラウド上でソフトウェアやデータにアクセスしたいという声も上がっています。こうした声を受けて製品の販売方法を再検討した同社は、プラットフォーム型の企業に移行することになりました。これには、Autodesk の製品体験の統合と一体化への取り組みも含まれます。「顧客のデータはこれまで特定のファイル形式でそれぞれのデスクトップに閉じ込められていましたが、これをクラウドベースにするという転換方針は、まさに私たちのこれまでのやり方を一変させる大きなシフトでした」と Martin さんは続けます。

この転換期を乗り越えるため、Autodesk では仕事のやり方を大幅に変える必要がありました。世界で 8,500 名以上の従業員が働く同社にとっては、会社そのものも変えていくことが不可欠でした。そんな中で浮上したのが、Slack でした。

Slack で縦割り構造をやめてコラボレーションを拡充

すでに確立されたワークフローを変革するためには、Autodesk のバーティカル型のビジネスに起因する縦割り構造を撤廃する必要がありました。2015 年、Martin さんは従業員を支援する全社的なコラボレーションツールの選定を任されました。「私たちが目指したのは、コラボレーションを改善し、透明性を高め、業務の効率化を図るためのツールを見つけることでした」と Martin さんは言います。

候補を探すうちに、社内 85 グループが Slack を活用していることが判明しました。しかし、それぞれのグループが個別に Slack をセットアップしていたため、チャンネルの命名規則も、共通のワークフローも可視性もなく、まるで離れ小島が 85 個もあるような状態でした。しかし、これらの 85 個のインスタンスには大きな有機的な力がありました。そこで私たちは離れ小島を 1 つの Slack インスタンスに集める作業に取りかかったのです。

Slack を取り入れた多くのチームは、プロジェクトや意思決定のプロセスがこれまでになかった視野で見えるようになり、新しい機能や指標へとつながっていったのです。製品チームは、クラウドプラットフォームチームとのコラボレーションにより、変化の激しいエンジニアリングデータを管理する高頻度データ管理の構築を進めています。別のチャンネルでは、リリース前の製品デザインについて短期・長期的な議論をリアルタイムで進めるチームの枠を超えたコラボレーションも行われています。

その結果、Autodesk はエンゲージメントとコラボレーションの評価方法を再定義することになりました。「コードの特定部分について担当チーム以外にどれだけ協力者がいたかなども評価の対象とするようになりました」と Martin さんは話します。

コードの共有や再利用をベースとするエンジニアリング文化を育てることで、エンジニアたちは製品を差別化する機能の開発に力を集中できるようになりました。また、顧客のセキュリティ向上も図りました。よく知られた検証済みのコンポーネントが攻撃範囲を狭めたからです。

リアルタイムの優先順位付けを実現

Slack 以前は、緊急案件の管理は電話やメールで行われており、なかなか急ピッチには進められませんでした。

そんな中で Slack は Autodesk エンジニアリングチームのインシデント管理の効率化を図りました。さらに Slack に Jira と PagerDuty を連係することで、できるだけ急ピッチでプロセスを進められるようになりました。

PagerDuty でアラートが発生すると、障害インシデント番号がついた新しい Slack チャンネルが作成され、障害の発生に気づいたエンジニアたちがそのチャンネルにすばやく集結。さまざまな解決方法をテストし、結果をグループに伝え、インシデントの解決に導きます。「こうしたリアルタイムツールの使用効果は測り知れません」と Martin さんは言います。しかも、こうした障害対応の結果はアーカイブされるため、今後の障害発生時の迅速な問題解決にも役立っています。

さらに Martin さんは、「問題修復にかかる平均時間や問題解決能力の面でも、Slack の影響はかなり大きいと考えています」と話してくれました。

解決策をすばやく見つける

「コラボレーションはとかく乱雑になりがちですが、乱雑と無秩序とでは大きな差があります」と Martin さんは言います。無秩序な状態を避けるため、Autodesk は 2 つのポリシーを設けました。

Autodesk は、チャンネルの作成は「公開設定が基本」という強い信念を持ってます。つまり、Slack チャンネルは可能な限り公開チャンネルにするというものです。Martin さんはコミュニティと透明性の文化を築く上で、このポリシーが役立っていると考えています。一般的な質問に対して #ADSK-slack-help と #ADSK-announcements の全社チャンネルで回答があると、参照しやすいようにチャンネルにピン留めされた FAQ に追加されます。また、Slack に新しい質問があった場合は、答えを見つけられる場所を教えることもできます。こうした仕組みの中で、従業員がすばやく答えを見つけられるようになっただけでなく、自発的な解決をうながす文化の育成にもつながりました。「自立したコミュニティが育っているということは、成功の証だと言えます」と Martin さんは指摘しています。

またチャンネルの目的がすぐにわかるよう、チャンネルの命名方法を標準化しました。#ADSK- というプレフィックスがつくチャンネルは全社向け、#Tech- は技術関連、#Project- は特定のプロジェクトやチームに関するものというルールです。Martin さんは、チャンネルの命名規則でチャンネルが見つかりやすくなり、チーム間のコラボレーション強化にもつながっていると考えています。

「あるチームが顧客から報告された Autodesk 製品の技術的な問題を解決したいと考え、#ADSK-general チャンネルにその件を投稿しました。すると、その内容にもっと適したチャンネルがあるのを知っていたメンバーがすぐそのスレッドに投稿したところ、わずか 30 分後に問題の解決方法がわかりました。以前はとても考えられなかったことです」と Martin さんは話してくれました。

チームとツールの連携

Autodesk がプラットフォーム型企業への変革を進める中、Slack はプロセスの効率化に役立てられています。システム停止の修復手順をオンザフライトリアージチャンネルで探す時も、OrG 間で密接なコラボレーションをとる時も、Autodesk は透明性を活用して新たな問題を解決してきました。「Slack が全社に浸透しているので、誰かがある問題の解決法を質問すると、その答えがほぼリアルタイムで得られるようになりました」。

Autodesk はこれまでも常にオープンソースの理念を提唱してきましたが、Slack の導入以降、組織の運営方針はさらに一歩この理念に近づきました。その成果は、目に見えて有益なものだったといいます。「まず自社の文化を理解し、企業としてあるべき姿を理解することが重要です。そうして初めて、それらを補強するツールを選べるようになるのです」と Martin さんは言います。企業では、コストや既存のエンタープライズシステムとの統合など、その他の視点に基づいてツールを選び購入することが多いと思います。ユーザーが喜んで受け入れてくれるかという、一番大事な視点が欠けているのです。私たちは文化を第一とし、ツールは二の次と考えています」。