Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Salesforce がアジャイルを採用した理由の理解

この単元を完了すると、次のことができるようになります。

  • Salesforce でアジャイルを使用する理由を説明する。
  • アジャイルのメリットをいくつか挙げる。
  • スクラムを定義する。
  • 「完了の定義」について説明する。
  • Salesforce ではアジャイルプロセスのほうがうまくいく理由を理解する。

せっかく Dreamforce に出かけたのに、基調講演はなく、新しい製品やサービスの発表もなく、イノベーションや翌年リリース可能な機能もないことがわかったら、どう感じると思いますか?

2006 年、Salesforce はもう少しでこうした状態に陥るところでしたが、製品の開発および配信方法を変革する新しいワークフローを実装して、この危機をかわすことができました。

Salesforce では 1999 年の創立以来、技術製品 (T&P) チームが順調に製品を配信していました。T&P チーム内のコミュニケーションもコラボレーションも常に円滑かつ簡潔に進められていました。ところが、驚異的な成長を遂げたことで、2006 年には顧客数、収益、製品数、会社の規模が総じて膨張していました。急成長は往々にして痛みを伴いますが、Salesforce もその例外ではありません。 

それまで簡単に行われていたことが、簡単にいかなくなっていました。その結果として、イノベーションが停滞し始めました。 

コミュニケーションやコラボレーション、管理のすべてを拡張しながら、リリース日に間に合わせることが困難になっていきました。新しいアプローチが必要であることは明白でした。円滑な製品配信プロセスを基軸に、リリースに遅れることのないアプローチです。 

2000 年から 2006 年にかけて、メジャーリリースの間隔が開いていく一方で、各チームが配信する機能数が減少している様子を示すグラフ

そこで、私たちが得意とすることを行いました。リスクを取ってソリューションの配信方法を改革したのです。この時に採択したのが、アジャイルの原則およびその手法です。

アジャイルとは?

私たちが Salesforce で行う業務の大半は、イノベーションに基づく反復的な作業です。つまり、最終的な結果が必ずしも最初からわかっているわけではなく、最終地点に到達する過程も進化していきます。新しい冒険の連続です! 

Salesforce の全チームがアジャイルプロセスを用いているわけではありません。チームの中には、柔軟性がはるかに低いプロジェクト管理プロセスである、ウォーターフォール型のフレームワークを使用しているところもあります。どちらのプロセスを選ぶかは、作業項目の開始時点で判明している事項、あるいは判明していない事項に左右されます。

ここで、ウォーターフォール型の手法を簡単に見てみましょう。

  • すべてあらかじめ計画されています。
  • プロジェクトを立ち上げるに、詳しい要求事項がとりまとめられています。
  • 1 つのステップが完了してから、次のステップに進みます。
  • 開始する時点で結果が特定されています。

計画か適応か

どちらのプロセスが適しているかを判断する場合は、次の点を検討します。絵を描くときに、色彩、場面、絵を描く時間、どのような仕上がりになるかをあらかじめ決定していれば、途中で変更する余地はほとんどありません。ピカソのような芸術的な作品にならないと言っているのではありません。このプロセスは、新しいアイデアやフィードバックを取り入れながら、最終的なイメージが変わる (改良される) こともあるプロセスではないということです。このような場合は、ウォーターフォール型のアプローチの使用を検討します。

他方、反復的な手法を用いる場合は、計画した順序で段階的に描いていくのではなく、受け取ったフィードバックや新しいアイデア、新たに学んだこと (この 2 色は合わない!) などを基に変更を加えていきます。これがアジャイル的なアプローチです。 

以下は、この 2 つの描画プロセスを視覚的に示したものです。 

画像に、作業中の人物画が示されています。ウォーターフォール型のプロセスまたはアジャイル型のプロセスを使用した場合に、絵画の途中の段階がどのようになるかを表しています。

Jeff Patton の作品に基づく画像。許可を得て転載 (jpattonassociates.com)

業務の複雑性

業務の種類によって適するプロセスが異なることがわかりました。では、あなたやそのチームにどちらのプロセスが適しているのかはどうやって判断するのでしょうか?  

ワークフロープロセスを選択するときは、次の点を自問します。 

  • 目下のプロジェクトについてどの程度のことがわかっているか?
  • プロジェクトの目的や要求事項がどのくらい明確か?
  • 解決策がどの程度定義されているか?
  • これらの手法についてチームや関係者にどのくらいの経験があるか?
  • 業務がどの程度複雑か?

ウォーターフォールを選択する場合

単純な業務:

  • 業務がシンプルで予測可能である。
  • 何をもって業務の完了とするかを各人が決定できる。

複雑な業務:

  • 業務に専門知識を要するが、予測可能である。
  • 業務を自動化できる。

アジャイルを選択する場合 

複雑な業務:

  • 業務が、一貫したフィードバック、リスク、イノベーションに基づく。
    • 何かを試して、どのように機能するかを確認し、新たに学んだ内容を踏まえて方向を転じられるようにしたい。
    • 新しい製品、ソフトウェア、サービスを制作中で、今までにしたことのないことを行っている。

アジャイル方式での Salesforce の拡大

アジャイル方式を採用することにした Salesforce の首脳陣は、各種チームにこの手法を導入するパイロットプロジェクトに着手しました。多少の抵抗はあったものの、Salesforce の役員はこの概念を支持し、2006 年に Salesforce の技術製品チームがアジャイル開発チームとして再編成されました。

この新チームはうまくいったのでしょうか? 実際に次のことが行われました。 

  1. 配信に対する考え方を刷新する。
  2. 標準化されたプロセスを実装する。
  3. リーンの原則を取り入れる (リーンについては後ほど詳述します)。
  4. 「業務終了」の意味を標準化する。

アジャイルという新しい考え方 

このアジャイルプロセスは具体的にどのようなものなのでしょうか? アジャイルとは簡単に言うと、ワークフローの柔軟性および製品への反復的な変更を実現する、各種の技術的な手法、プロセス、フレームワーク、原則、価値などの総称です。  

業務に対する反復的なアプローチで、プロジェクトの最後に 1 つの最終製品を完成させるのではなく、開始時点からチームが逐次成果物を構築していきます。アジャイルの手法では、各チームが連携し、品質が向上し、全員が進捗状況を確認して管理するようになるため、顧客に高い価値をいち早く届けることができます。 

Salesforce では、コミュニケーションの問題や成長に伴う痛みの拡大を解決する方法を模索していたため、アジャイルはうってつけの手法でした。

新しいアジャイルプロセス: 上空から眺める 

Salesforce で導入することにしたアジャイルプロセスの 1 つがスクラムです。具体的な原則に従うこうしたプロセスを支持し、その原則によって私たちの今日の業務の進め方が特徴づけられています。

スクラムとは?  

スクラムとは、ロール、ミーティング、成果物が定義されたプロセスで、顧客に質の高い価値をいち早く届けるフレームワークになります。

スクラムを採用した理由 

スクラムは、製品の何が機能して何が機能しないかを判断し、それに応じて変更を行う、柔軟なフレームワークを提供します。スクラムを使用すると、取り組んでいる業務について全員が所有権を有し、期待を共有するようになります。 

Salesforce のスクラムプロセスの概要 

Salesforce ではスクラム導入の際、150 人を部門横断的な小さなチームに編成し、チームごとに短期的な反復作業 (スプリントといいます) に取り組むことにしました。この目的は、配信を安定化させることと、プロセスを整理することでした。現在、Salesforce のクラウドチームの大半がスクラムの何らかのバリエーションを使用しています。 

リーンの原則とは?

Salesforce ではリーンの原則も採用しています。この原則は、ワークフローおよび配信プロセスを説明する 7 つのステートメントです。これは Ohana 文化を反映するもので、成功を目指す組織造りを推進するために協力して取り組むことの大切さが強調されています。この点は後ほど詳しく説明します。

業務「終了」の新たな定義

新しい業務の進め方を習得したチームは、プロセスを反復させ、ワークフローや製品に関する新しい情報を学び取りながら進行させることが可能になりました。けれども、作業項目が本当に完了したかどうかを知るにはどうすればいいのかという疑問が浮上しました。  

この答えは簡単です。技術製品チーム全体の標準となる完了の定義 (DoD) を定め、何かが完了した時点が全員に明確になるようにしました!

次のシナリオを考えてみましょう。製品の新しい機能を作成する必要があるとします。この新しい作業をチームに割り当て、今月中に実装するよう指示します。チームは作業を遂行して、先に進みます。数か月経った後で、終了した作業項目に新たな問題が浮上しました。この問題というのが、インテグレーションが完全にテストされていなかったため、顧客から苦情があったことであるかもしれません。セキュリティ上の問題に対処していなかった、あるいはパフォーマンスが基準に達していなかったという場合もあるでしょう。いずれにせよ、作業項目が実際には終了しておらず、少なくともリリースするレベルではなかったことになります。

Salesforce の完了の定義は、業務が本当に完了したとみなされるために、チームが実行すべき事項を定めた一連のガイドラインです。Salesforce の基本的価値の 1 つである信頼を堅持するためには、この基準の設定が不可欠です。

まとめ

私たちは絶えず「正しいことを正しい方法で行っているか?」と自問しています。つまり、何をするにも必ずお客様を中心に考えるようにするということです。  

スクラムプロセスの徹底、そしてアジャイルおよびリーンの考え方は、配信を向上させ、円滑なリリースを保証するうえで中核となるものです。Salesforce ではお客様に対して年に 3 回メジャーリリースを実施しているため、この点は極めて重要です。 

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む