開発ライフサイクルとリリース計画で意識したいこと - TECH BLOG

はじめに

あけましておめでとうございます。昨年4月より公開したTerraSky Tech Blogですが、お陰様で多くのSalesforceファンの皆様に読んで頂き嬉しい限りです。ありがとうございました！今年もテラスカイのSalesforceが大好きなエンジニアと共に毎週お届けしたいと思います。どうぞよろしくお願いします。

さて、2014年の初回となるエントリーですが、特に最近感じたプロジェクトマネージャーやテクニカルアーキテクトが、プロジェクトやアプリケーションの将来的な拡張を見据え、「開発ライフサイクルとリリース計画」で意識したいことをお伝えしたいと思います。

1.プロジェクトの体制と要件の把握

ステークホルダー

プロジェクトを進める上でステークホルダーを見つけることを意識してますか。あるいは具体的にどのようにして見つけるのでしょうか？例えば予算管理者、ビジネス要件を的確に把握しているユーザを見つけている状態、そうでない状態ではプロジェクトの進み方は変わってくるでしょう。

ユーザのSalesforce理解者

プロジェクトを進める上で、Salesforceの標準機能を理解しているユーザは参加していますか？ Salesforceの標準機能のメリットを理解し、それを最大限活用し、継続的な機能強化＆保守を考える上で、ユーザと一緒に検討できる違いはインパクトがあります。可能な限りプロジェクト開始前までに、ユーザのプロジェクトコアメンバーにトレーニングを受けてもらえることをお勧めします。

要件の把握と管理

Salesforceの開発生産性の高さから、標準カスタマイズによるプロトタイプをスピーディーに開発し、定例化したミーティングでプロトタイプを説明し、ユーザからそのフィードバックを得てブラッシュアップしていく方法を採用するケースはとても一般的です。

一方で、UIを介さない機能やインテグレーションなどはどのように把握するでしょうか？あるいは、基幹系システムをリプレースする場合など、ユーザ自身が正確に把握していない内部的なビジネスロジックが隠されているケースは多分にあります。また、これら要件を漏れ無く管理し、開発のスコープや開発状況含めユーザと共有できる方法を選択しているでしょうか？

2.テスト計画と考慮事項

テストの種類と計画

Salesforceの標準カスタマイズで開発を実施した場合、使用する機能自体はテスト済みで品質は保証されていますが、例えば数式や入力規則は設定ミスによるバグは発生します。システムとして非常に重要となるセキュリティに関する設定も同様です。どのようなテストを誰がいつ実施するのが効果的でしょうか？

プロトタイプを通じて常にユーザからのフィードバックを得ているとしても、ユーザはそれをテストと意識して、こちらが期待する全てを実施してくれるのでしょうか？また、業務フローなどをベースにしたシナリオテストを実施しないと検出し難いバグというのもあるでしょうし、外部システムとのインテグレーションでは実際に疎通させてみないと検出できないケースもあります。

ApexやVisualforceで開発したものはどうでしょうか？Apexであればカバレッジは最低限確保すると思いますが、データ量が増大した場合にVisualforceやApexが期待するパフォーマンスを発揮するでしょうか。データ量が増大した結果、VisualforceやApexがランタイムエラーを起こす可能性もあります。

テストは環境面の制約などにより、全てのテストを期待通りに実施できないケースもあります。そのような場合、どのようなリスクが生じるかも意識して計画したいものです。

テスト結果の評価

システムをリリースする上で、運用回避可能な軽微なバグが残る程度の状態であればリリースする場合もあると思います。テストを実施した上で検出されたバグの重大度や、その発生度合いを評価・検討できる仕組みはあるでしょうか？

3.変更管理／ガバナンス

変更管理とガバナンス

システムリリース後の機能強化や拡張は多くあります。例えばSalesforce標準カスタマイズによる変更は設定変更履歴で管理されますがこれだけで十分でしょうか？これだけでは不十分とした場合、Salesforceが備える機能やそれを補う仕組みを検討する必要があるでしょう。

システムの変更を行うことで、業務のプロセス自体の変更を伴うケースもあると思います。このようなケースを含め影響分析は誰が行うのでしょう？あるいは、システムを変更を行わなかった場合における影響の把握も必要となるでしょう。また、システムはリリースがゴールではなく、その利用において効果を享受できる必要があります。定着化・活用を促すための組織的な体制作りの必要性も考えたいものです。

プロジェクトを進める上で、当初の要求仕様からスケジュールやコストに重大な影響がある仕様変更が発生するケースはあります。このような場面で、スコープ、スケジュール、コストを評価し、コントロールを可能とする体制や、あるいはレポートラインも考慮しておきたいものです。

4.環境／リリース管理

環境の構成

アプリケーションの開発からリリースまでの流れとして簡潔に言うと、Sandbox上で開発＆テストを行い、本番環境にデプロイがほとんどのケースになると思います。

このSandboxでの開発＆テストですが、例えば大規模なシステム開発で開発者が多く参加するようなケースの場合、どのような種類のSandboxを、どのような目的で、いくつ用意して開発を行うのでしょうか？

また、多くの外部システムとインテグレーションを伴うアプリケーションであれば、どのような構成でSandboxを準備するでしょうか？ユーザによるUATやトレーニングを考慮したらどのようにするでしょうか？大量の初期データ移行のリハーサルを何度も繰り返さなくてはならないケースもあるでしょう。

一方で、Sandboxはライセンス種類の違いにより提供される種類と数に違いがあり、追加には費用がかかります。こららを考慮し、開発環境の構成を検討する必要があります。

デプロイの手段

開発環境としてSandboxを1つ以上準備し、最終的に本番環境にデプロイするわけですが、役割りに応じたSandbox間、本番環境間へはどのような方法でデプロイするのでしょうか？現状では、Force.com IDE、Migration Tool（Antベース）、変更セットの何れかを選択するケースが殆どかと思います。

こららの手段を使い分けるメリット・デメリットは何なのでしょうか？また、上記3種類のデプロイ手段はMetaデータの移行により実現されるものですが、Metaデータが提供されておらず手作業が生じるケースもあります。リリースミスを防ぐための手順と手段は重要になるでしょう。

5.開発手法の利点とリスク

開発手法の利点とリスク

Salesforce／Force.comを導入する上で、ウォーターフォール、アジャイル、あるいはその両方をハイブリッドに取り入れて行うケースがあります。開発手法のそれぞれの特徴やメリット・デメリットは何なのでしょうか？極端な話として「会社の導入手法は従来からウォーターフォールだから...」といった理由もあるのでしょうが、ウォーターフォールで実施するには、合理的でない場合もあるでしょう。（その逆もあります。）

個人的には、開発手法そのものには拘りはなく、ウォーターフォールを否定するつもりも、アジャイルを熱心に推し進めるつもりもなく、これまでの経験から顧客特性、プロジェクト特性、機能特性などを考慮し、最も適した開発手法が選択できれば良いのでは？と思っています。