ポスト
via pixabay.com
はじめに
初めまして。テラスカイ 大阪支店のswataです。
今回は、Salesforceで「アジャイル開発」をする時に気を付けた方が良い落とし穴について、少しご紹介したいと思います。
今回の対象読者は、会社の上司やクライアントから、「これからウチはSalesforceでシステム作るぞー。短納期でいいものが作れるとかいうアジャイルでよろしく」と、突然言われて、
「え？私？ウォーターフォールで基幹系のシステム開発はやってきたけど、Salesforceは初めてだし、アジャイルってのはネットで調べてみたけど・・・」と頭を抱えてるような方々をイメージしています。
また、ここでいう「アジャイル開発」は、世間で言われる「いわゆるウォーターフォールモデルと比較して語られる、短納期でシステムを開発できる開発手法」を指しているとお考え下さい。
× × ×
私がアジャイルに関わり始めた10年以上前に比べて、今の方が遥かに良質な情報が多くなりました。
少しインターネットで検索すれば、多種多様な情報が簡単に手に入ります。
関東であれば、毎日のように各所で無料のイベント・勉強会・セミナーも開催されています。
最近では大都市圏以外でも開催されるようになりました。
そこで、今回はアジャイルの初歩的・基本的なお話についてはそちらに譲って、「Salesforceで開発する時に特に陥りやすい」という事をメインに紹介します。
【落とし穴1：ドキュメントが無い】
「いや、流石に今時アジャイル開発だからドキュメントを作らない、なんて言ってる人はいないでしょ？」と思われたかもしれません。
だからこそこの場で紹介したいと考えました。
私はSalesforceの「メリット・強み」が、一歩間違えるとその落とし穴へ陥る原因になりやすいと考えているからです。
ではそのメリット・強みとは何でしょうか？
それは、スクラッチで一から開発するよりも遥かに早く、お客様が利用できるシステムが作れる、というスピード感です（勿論他にも色々とありますが）。
また、そのスピード感でお客様の要望に対応して変更を加える（＝システムを変化させられる）という事もまた、強みの一つと言えるでしょう。
ただ、逆にそのスピード・変化に（作り方を間違えた）ドキュメントが追いつけなくなるという事が起こりがちです。そしてそれが結果的にドキュメント軽視につながり、最終的に（システムと同期した役に立つ）ドキュメントが無いという状況を作り出しやすくしています。
「いや、そもそもSalesforceで開発する時にドキュメントなんて必要ないんじゃないの？」と思われる方もいらっしゃるかもしれません。確かに一般的なシステム開発における、実装（＝コーディング）に対応するような「詳細設計書」が不要であるという意見については、基本的に（※）私も同意見です。
（※）但し、Salesforceにおいても大規模な開発や、設計者と実装者が完全に分離している場合などは従来の「詳細設計書」のようなドキュメントの作成が必要となる場合は多いでしょう。
（仕様検討～（基本）設計はともかく）Salesforceの開発においては、詳細設計書を作る位なら、その時間で実装を進めてお客様に作成した実物で確認を行い、フィードバックをもらった方がシステム開発全体としては、よほど早く・確実に進むためです。
また、詳細設計レベルの細かいドキュメントを作成してしまうと、Salesforceでのスピーディな開発の足枷になりかねません。そして、その維持コストもSalesforceを採用したメリットを打ち消しかねません。
とはいうものの、ドキュメントはやはり重要・必要ではある、と私は考えています。
では、どのようなドキュメントが必要なのでしょうか？
【落とし穴を避けるには①】
・「なぜその設計、設定を選択したのか」についての、設計・実装の根拠となる、業務制約や前提、選択理由を残す。
⇒ 所謂ウォーターフォール型開発での、「要件定義」「基本設計」のようなレベル・観点でのドキュメントは、Salesforceの開発においても陳腐化しにくく、システムを運用・拡張していく上での大切な資料となります。
【落とし穴を避けるには②】
・逆に「いくつかある手段・方法のうち、なぜそれを選択しなかったのか」という理由についてもできれば残しておく。
⇒ 上記同様、次にシステムを改修するタイミングで、検討しなければならない時間や手間を省いてくれたり、思わぬデグレを防止してくれる場合があります。
いずれにせよ、弊社の某社員のネタではありませんが「WHY?」を考えることを通常のシステム開発におけるドキュメント作成時よりも意識した方が良さそうです。
初めまして。テラスカイ 大阪支店のswataです。
今回は、Salesforceで「アジャイル開発」をする時に気を付けた方が良い落とし穴について、少しご紹介したいと思います。
今回の対象読者は、会社の上司やクライアントから、「これからウチはSalesforceでシステム作るぞー。短納期でいいものが作れるとかいうアジャイルでよろしく」と、突然言われて、
「え？私？ウォーターフォールで基幹系のシステム開発はやってきたけど、Salesforceは初めてだし、アジャイルってのはネットで調べてみたけど・・・」と頭を抱えてるような方々をイメージしています。
また、ここでいう「アジャイル開発」は、世間で言われる「いわゆるウォーターフォールモデルと比較して語られる、短納期でシステムを開発できる開発手法」を指しているとお考え下さい。
× × ×
私がアジャイルに関わり始めた10年以上前に比べて、今の方が遥かに良質な情報が多くなりました。
少しインターネットで検索すれば、多種多様な情報が簡単に手に入ります。
関東であれば、毎日のように各所で無料のイベント・勉強会・セミナーも開催されています。
最近では大都市圏以外でも開催されるようになりました。
そこで、今回はアジャイルの初歩的・基本的なお話についてはそちらに譲って、「Salesforceで開発する時に特に陥りやすい」という事をメインに紹介します。
【落とし穴1：ドキュメントが無い】
「いや、流石に今時アジャイル開発だからドキュメントを作らない、なんて言ってる人はいないでしょ？」と思われたかもしれません。
だからこそこの場で紹介したいと考えました。
私はSalesforceの「メリット・強み」が、一歩間違えるとその落とし穴へ陥る原因になりやすいと考えているからです。
ではそのメリット・強みとは何でしょうか？
それは、スクラッチで一から開発するよりも遥かに早く、お客様が利用できるシステムが作れる、というスピード感です（勿論他にも色々とありますが）。
また、そのスピード感でお客様の要望に対応して変更を加える（＝システムを変化させられる）という事もまた、強みの一つと言えるでしょう。
ただ、逆にそのスピード・変化に（作り方を間違えた）ドキュメントが追いつけなくなるという事が起こりがちです。そしてそれが結果的にドキュメント軽視につながり、最終的に（システムと同期した役に立つ）ドキュメントが無いという状況を作り出しやすくしています。
「いや、そもそもSalesforceで開発する時にドキュメントなんて必要ないんじゃないの？」と思われる方もいらっしゃるかもしれません。確かに一般的なシステム開発における、実装（＝コーディング）に対応するような「詳細設計書」が不要であるという意見については、基本的に（※）私も同意見です。
（※）但し、Salesforceにおいても大規模な開発や、設計者と実装者が完全に分離している場合などは従来の「詳細設計書」のようなドキュメントの作成が必要となる場合は多いでしょう。
（仕様検討～（基本）設計はともかく）Salesforceの開発においては、詳細設計書を作る位なら、その時間で実装を進めてお客様に作成した実物で確認を行い、フィードバックをもらった方がシステム開発全体としては、よほど早く・確実に進むためです。
また、詳細設計レベルの細かいドキュメントを作成してしまうと、Salesforceでのスピーディな開発の足枷になりかねません。そして、その維持コストもSalesforceを採用したメリットを打ち消しかねません。
とはいうものの、ドキュメントはやはり重要・必要ではある、と私は考えています。
では、どのようなドキュメントが必要なのでしょうか？
【落とし穴を避けるには①】
・「なぜその設計、設定を選択したのか」についての、設計・実装の根拠となる、業務制約や前提、選択理由を残す。
⇒ 所謂ウォーターフォール型開発での、「要件定義」「基本設計」のようなレベル・観点でのドキュメントは、Salesforceの開発においても陳腐化しにくく、システムを運用・拡張していく上での大切な資料となります。
【落とし穴を避けるには②】
・逆に「いくつかある手段・方法のうち、なぜそれを選択しなかったのか」という理由についてもできれば残しておく。
⇒ 上記同様、次にシステムを改修するタイミングで、検討しなければならない時間や手間を省いてくれたり、思わぬデグレを防止してくれる場合があります。
いずれにせよ、弊社の某社員のネタではありませんが「WHY?」を考えることを通常のシステム開発におけるドキュメント作成時よりも意識した方が良さそうです。
【落とし穴2：構成管理ができていない】
Salesforceでも大規模な開発であれば、Flosum（https://base.terrasky.co.jp/articles/7AQc6）やGitやSubversion、RedmineやJIRA等を組み合わせた構成管理が恐らく行われているでしょう。
ただ、構成管理の仕組みの構築・維持・運用には、それなりのコストがかかってしまうため、規模の小さい開発の場合、行われていないかもしれません。
（規模が小さい開発にもかかわらず、大規模開発並みの構成管理を実施しようとするとコストが見合わなかったり、そもそも上記で述べたようなSalesforceのメリットを損ないかねないためです）
ですが、激しく、スピーディな変化に対応することが可能であり、それがメリットの一つであるSalesforceの開発でも、いえ、そうであるため余計に適切な構成管理が重要になると私は考えています。
もし、仮に開発者があなた一人で、そのSalesforceのシステムが利用されなくなるまで開発・運用・メンテナンスを行い、その上システムに対して行われた変更を全て記憶できていて、作業も全くミスしない、スーパーマンなら必要ないかもしれません。
ですが、通常は少なくとも数名以上のチームで開発を行い、人の入れ替わりも発生することになるでしょう。
そのような状況において、いつ、どういう理由で、どういう変更をシステムに対して加えたのか、加える必要があったのかを記録・管理することは重要であり、もしそれがなされていなければ、開発全体に対してボディーブローのように後で効いてくるダメージを積み重ねてしまうことになります。
【落とし穴を避けるには①】
・Salesforce からも開発モデルについてのいくつかの提案があります。
⇒ 「パッケージ開発モデル」
https://trailhead.salesforce.com/ja/content/learn/modules/sfdx_dev_model
「Salesforce DX Developer Guide 」
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm
プロジェクトの状況や環境によってうまく適用できる部分、できない部分があるかもしれません。
ですので、それぞれの現場で考えて作っていくこと・カスタマイズしていくことが大切です。
スピーディーに変化を積み重ねていく環境・状況であればあるほど、後になって構成管理の「ありがたさ」「有用性」について実感することになるでしょう。
私は最低限でも、ソースのバージョン管理は必要だと考えており、その際のコミットログはしっかりと記述しておいた方が良いと考えています（実際私は何度も救われたことがあります）
【落とし穴3：いくつかのプラクティスを取り入れる『だけ』になる】
最後はSalesforceにおけるというより、一般的なシステム開発でアジャイル開発を始めようとした時にも当てはまる話を紹介します。
例えばScrumを採用しているのに、「透明性」「検査」「適応」という基本を理解しないまま「朝会」を「進捗報告の場」として実施している、とか、見積の時のプランニングポーカー（※）が単なる数値合わせの場になっている、等にはなっていないでしょうか。
（※）補足ですが「プランニングポーカー」は現時点ではScrumの正式なプラクティスではありません。ただ、Scrumを採用しているチームではよく行われているプラクティスの為取り上げました。
確かにプラクティスは形式が決まっているため、一見するとすぐに取り入れられそうに思いがちです。
ですが、背景や基本的な考え方を理解しないまま、単に形だけ実施していても、恐らく思っていたような効果を上げることはできません。
なぜなら、（少なくともScrumにおいては）プラクティス・ルールにはそれぞれ「狙い」があります。
また、それらは独立しているものではなく、組み合わせて実施されることで、最大限の効果を発揮するように設計されているからです。
例えば先に上げた朝会であれば、「計画からずれているかを検査し、毎日という単位で再計画を繰り返し、状況に適応させる」という事、「それをチームが自律して行っていく」というところがポイントになります。
そして、実はそれはもう一回り大きい単位（Scrumではスプリントと言います）で、うまく実行できたのか、
できなかったのか、できなかったのならどうすればもっと上手くできそうかを考え、試行錯誤を繰り返すという構造の一部になっています。
Scrumで言う「ふりかえり」というプラクティス・ルールになりますが、このように「朝会」「スプリント」「ふりかえり」は連鎖しており、「朝会」だけ取り入れても、片手落ちという事になります。
また、見積におけるプランニングポーカーも、「各ストーリーに対してどれくらいかかりそうかという規模感を出す」事よりも、「規模感を出すために何をするかを関係者間で話し合い、達成すべきゴールに対しての認識のズレ・齟齬を浮き彫りにする」という事がポイントだったりします。
（また、見積が正確だったか、ズレていたかは結果論なので何故ズレたのか？その見積の精度をより上げるためにはどうするか、を「ふりかえり」で分析する・考えるという事も上記と同じように最大限に効果を上げるために必要なこととなります）
【落とし穴を避けるには①】
これはチーム次第、状況次第なので、お困りでしたら是非弊社にご相談下さい。
（機会があれば、改めて紹介していきたいと思います）
おわりに
今回は少し普段の技術的な話とは毛色が違った話になりましたが、少しでも現場の役に立つものであれば幸いです。
Salesforceでも大規模な開発であれば、Flosum（https://base.terrasky.co.jp/articles/7AQc6）やGitやSubversion、RedmineやJIRA等を組み合わせた構成管理が恐らく行われているでしょう。
ただ、構成管理の仕組みの構築・維持・運用には、それなりのコストがかかってしまうため、規模の小さい開発の場合、行われていないかもしれません。
（規模が小さい開発にもかかわらず、大規模開発並みの構成管理を実施しようとするとコストが見合わなかったり、そもそも上記で述べたようなSalesforceのメリットを損ないかねないためです）
ですが、激しく、スピーディな変化に対応することが可能であり、それがメリットの一つであるSalesforceの開発でも、いえ、そうであるため余計に適切な構成管理が重要になると私は考えています。
もし、仮に開発者があなた一人で、そのSalesforceのシステムが利用されなくなるまで開発・運用・メンテナンスを行い、その上システムに対して行われた変更を全て記憶できていて、作業も全くミスしない、スーパーマンなら必要ないかもしれません。
ですが、通常は少なくとも数名以上のチームで開発を行い、人の入れ替わりも発生することになるでしょう。
そのような状況において、いつ、どういう理由で、どういう変更をシステムに対して加えたのか、加える必要があったのかを記録・管理することは重要であり、もしそれがなされていなければ、開発全体に対してボディーブローのように後で効いてくるダメージを積み重ねてしまうことになります。
【落とし穴を避けるには①】
・Salesforce からも開発モデルについてのいくつかの提案があります。
⇒ 「パッケージ開発モデル」
https://trailhead.salesforce.com/ja/content/learn/modules/sfdx_dev_model
「Salesforce DX Developer Guide 」
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro.htm
プロジェクトの状況や環境によってうまく適用できる部分、できない部分があるかもしれません。
ですので、それぞれの現場で考えて作っていくこと・カスタマイズしていくことが大切です。
スピーディーに変化を積み重ねていく環境・状況であればあるほど、後になって構成管理の「ありがたさ」「有用性」について実感することになるでしょう。
私は最低限でも、ソースのバージョン管理は必要だと考えており、その際のコミットログはしっかりと記述しておいた方が良いと考えています（実際私は何度も救われたことがあります）
【落とし穴3：いくつかのプラクティスを取り入れる『だけ』になる】
最後はSalesforceにおけるというより、一般的なシステム開発でアジャイル開発を始めようとした時にも当てはまる話を紹介します。
例えばScrumを採用しているのに、「透明性」「検査」「適応」という基本を理解しないまま「朝会」を「進捗報告の場」として実施している、とか、見積の時のプランニングポーカー（※）が単なる数値合わせの場になっている、等にはなっていないでしょうか。
（※）補足ですが「プランニングポーカー」は現時点ではScrumの正式なプラクティスではありません。ただ、Scrumを採用しているチームではよく行われているプラクティスの為取り上げました。
確かにプラクティスは形式が決まっているため、一見するとすぐに取り入れられそうに思いがちです。
ですが、背景や基本的な考え方を理解しないまま、単に形だけ実施していても、恐らく思っていたような効果を上げることはできません。
なぜなら、（少なくともScrumにおいては）プラクティス・ルールにはそれぞれ「狙い」があります。
また、それらは独立しているものではなく、組み合わせて実施されることで、最大限の効果を発揮するように設計されているからです。
例えば先に上げた朝会であれば、「計画からずれているかを検査し、毎日という単位で再計画を繰り返し、状況に適応させる」という事、「それをチームが自律して行っていく」というところがポイントになります。
そして、実はそれはもう一回り大きい単位（Scrumではスプリントと言います）で、うまく実行できたのか、
できなかったのか、できなかったのならどうすればもっと上手くできそうかを考え、試行錯誤を繰り返すという構造の一部になっています。
Scrumで言う「ふりかえり」というプラクティス・ルールになりますが、このように「朝会」「スプリント」「ふりかえり」は連鎖しており、「朝会」だけ取り入れても、片手落ちという事になります。
また、見積におけるプランニングポーカーも、「各ストーリーに対してどれくらいかかりそうかという規模感を出す」事よりも、「規模感を出すために何をするかを関係者間で話し合い、達成すべきゴールに対しての認識のズレ・齟齬を浮き彫りにする」という事がポイントだったりします。
（また、見積が正確だったか、ズレていたかは結果論なので何故ズレたのか？その見積の精度をより上げるためにはどうするか、を「ふりかえり」で分析する・考えるという事も上記と同じように最大限に効果を上げるために必要なこととなります）
【落とし穴を避けるには①】
これはチーム次第、状況次第なので、お困りでしたら是非弊社にご相談下さい。
（機会があれば、改めて紹介していきたいと思います）
おわりに
今回は少し普段の技術的な話とは毛色が違った話になりましたが、少しでも現場の役に立つものであれば幸いです。
5 件
