アジャイルの基本の学習
この単元を完了すると、次のことができるようになります。
- アジャイル宣言について説明する。
- アジャイルの原則と手法の違いを定義する。
- 真にアジャイルになる方法を説明する。
Salesforce がアジャイルになった理由を理解したところで、アジャイルをどのように実践できるかを見ていきましょう。
妙に思うかもしれませんが、アジャイルを実践することと、アジャイルになることは異なります。アジャイルになるとは、何も考えずただプロセスに従うのではなく、なぜ行うのか認識していることを意味します。チームをアジャイルにするためのベストプラクティスはたくさんあります。突き詰めれば、次の 3 つの質問に「はい」と答えることができれば、あなたはアジャイルへの道を辿っています。
- 私たちの活動において、人々に焦点が当てられているか?
- プロセスや製品を進化させるために、継続的に学習して向上しているか?
- 顧客に頻繁に価値や喜びをもたらしているか?
アジャイルの価値
アジャイルプロセスは、喜びが山盛りになった美味しいアイスクリームサンデーのようなものと考えることができます。では、アジャイルの考え方の基本から説明していきましょう。この部分はアイスクリームサンデーの器に相当します。
Salesforce がアジャイルを採用する前の 2001 年、業界中から集まった 17 人のソフトウェアエンジニアが、基盤となる一連の価値を示すアジャイル宣言を書き上げました。大規模かつ高額なソフトウェアプロジェクトが度々中断または失敗し、時間や資金、労力が無駄になっていたことが、この宣言の起草につながったのです。膨大なドキュメントを要し、あらかじめすべてを設計するプロセスが失敗した経験から、エンジニアらは代わりとなる手法を模索していました。
今日では、こうした価値によって Salesforce の基盤が築かれ、アジャイルの考え方が培われています。この宣言の基本となるのが、楽しみながら成功を収める組織造りを目標とする人々およびコラボレーションです。
以下は宣言の引用です。
「私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
- プロセスやツールよりも個人と対話を、
- 包括的なドキュメントよりも動くソフトウェアを、
- 契約交渉よりも顧客との協調を、
- 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」
では、上記の 4 つの価値を詳しく見ていきましょう。
プロセスやツールよりも個人と対話
アジャイルになることの 1 つが、旧式のプロセスによってワークフローが決まるのではなく、チームが自らワークフローを決められるようにすることです。Salesforce では、チームがワークフローや製品開発を管理できる、GUS というプラットフォームを使用しています。
これぐらいの規模の企業になると、チームがさまざまな建物や州、国に分散していることが多くなります。アジャイルプラットフォームがあれば、タイムゾーンに関係なく、大きな規模でシームレスなコミュニケーションを維持できます。
包括的なドキュメントよりも動くソフトウェア
では、私たちが実際に進歩していることは、どうやって確認するのでしょうか? 目に見える結果、つまり機能することが実証済みのソフトウェアやサービス、成果物で確認します。言い換えれば、仕様書そのものによって、正しいことを行っていると立証されることもなければ、お客様に価値が提供されることもありません。
契約交渉よりも顧客との協調
Salesforce では、顧客中心の企業として、お客様にとって何が最適かを決め込むのではなく、顧客が自社にはこれが最適だと実際に述べたものを実装しています。短期的なスプリントや継続的な改善プロセスにより、顧客が望む変化にいち早く対応できます。Salesforce では IdeaExchange (顧客にアイデアを提案してもらうフォーラム) といった制度を使用して、顧客がどのようなものに惹かれ、便利だと思い、すごいと感じるのかを理解しています。
計画に従うことよりも変化への対応
私たちが Salesforce で行う業務も、そのプロセスも、本質的にクリエイティブなものです。私たちはすべての結果を正確に把握することはできず、ジャーニーの各ステップをあらかじめ計画することもできません。冒険では必ずや途中に迂回路がでてきます。それだけでなく、顧客からのフィードバックにすばやく対応する必要があります。つまり、変化は生じるものであり、いつ何時生じるかわかりません。
Salesforce ではこのため、すべてのプレゼンテーションの冒頭でセーフハーバーの通知について説明し、サービスを購入するお客様に対して、将来予測に関する記述ではなく、現在使用できる機能に基づいて購入を決定するよう警告しています。
経験と勘を頼りに物事を行っていると言うのではありません。Salesforce のチームは、全社的な年間計画プロセスから、リリース計画、逐次計画、そして日々の計画ミーティングまで、定期的に計画を立てています。
アジャイルの原則の概要
前述のアイスクリームサンデーの次の層は、反復プロセスに風味を添えるアジャイルの 12 の原則です。容器の山盛りのアイスクリーム (もちろん、各種のフレーバーです) をこの層と考えます。
アジャイルの原則には次のような内容が記載されています。
- 物事をシンプルな状態に保つ
- 競争力を維持するための変化を受け入れる
- 対面コミュニケーションを最適とする
- 事業部門の人々と開発者がプロジェクトを通して協力し合う
ここで原則の全容をご覧いただけます。
フレームワーク
容器に各種のフレーバーのアイスクリームを盛り付けたら、次はチョコレートソースの出番です! 私たちの考え方や理想を実践に移せるように、ロールやミーティングの手法やガイドラインが定義された各種のフレームワークをアイスクリームの上にたっぷりかけます。Salesforce で使用しているフレームワークは、スクラム、Kanban、Scrumban (両者を組み合わせたもの)、エクストリームプログラミング (一連の技術的なベストプラクティス) です。
手法
サンデーのカラフルなトッピングと同様に、人々がフレームワークをアジャイルかつリーンな方法で設定できるようにする、アジャイルの手法、リーンの手法、そして技術的な手法は多数あります。Salesforce で行っている手法として、計画の間隔、チームによる検査および適応方法、各人が担うロールと責任などが挙げられます。業務を管理し優先順位を付ける目的で、各従業員が年間計画書とバックログを作成します。これは、ハイブリッドのエンジニアリングプラクティスや自動化されたテスト環境とは別に行います。
こうしたアジャイルの価値、原則、フレームワーク、手法などが Salesforce Ohana の構築に役立っています。