とあるStartupに勤めるエンジニアの技術ブログ

Salesforce、テスト関係の技術ブログなどを書く予定

Japan Dreamin' 2021でLT登壇してきた!

f:id:a-kura:20210314135704p:plain

Japan Dreamin' 2021 - なぜ、Salesforceは最強の業務アプリ・プラットフォームなのか?

2021年1月30日(土)に開催された Japan Dreamin' 2021 に参加・登壇してきました。今年はオンライン開催となったので、LT もオンラインでの発表となりました。

www.trailblazers.jp

 

今回の発表では、「なぜ、Salesforceは最強の業務アプリ・プラットフォームなのか?」と題してSalesforce Platformの強みについて話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。

www.slideshare.net

youtu.be

 

なぜ、Salesforceは最強の業務アプリ・プラットフォームなのか?

B2B サービスにおける Salesforce Platform の優位性は「カスタマイズ性」にあります。

B2C サービスであれば、利用者は大きくカスタマイズすることなくサービス提供されるまま利用してくれます。ただし、自分に合わないようであれば簡単に使わなくなったり、別のサービスに乗り換えてしまいますが。

しかし、B2B サービスでは自社の業務に直結するため必ず利用する必要があり、簡単には乗り換えられません。また、一つのサービスでは自社の業務を包含できないため、別のサービスと連携させる必要があります。そのため、利用者は自社の業務が回せるようにカスタマイズすることが必須となってきます。

 

Salesforce Platform の持つカスタマイズ性

このカスタマイズ性の源泉となる要素は No-Code / Low-Code、Pro-Code、AppExchange の3つにまとめられます。

f:id:a-kura:20210314135922p:plain

Salesforce Platform の持つカスタマイズ性

 

ノーコード / ローコード

Salesforce Platformはノーコード、ローコードとして、Salesforce フロー、承認プロセス、レポート・ダッシュボードなどコーディングしなくてもカスタマイズできる汎用的な業務機能を多く提供しています。

特に強力な機能としては、画面やオブジェクトを自在に作成できます。この機能は、新しく開発する画面やオブジェクトだけではなく、SalesCloud やServiceCloud が提供する機能も同じようにカスタマイズできる点です。この機能によって自社の業務に合わせるための糊代が格段に拡がっています。

youtu.be

 

プロコード

プロコードでは、Apex、Visualforce Page、Lightning Web Components によって独自の画面や機能、アクションを開発できます。

特に重要なことは Salesforce Platform の機能として提供されることです。カスタマイズするために別の環境を用意する必要がないため、シームレスに SalesCloud や ServiceCloud の機能を拡張できます。同じ環境で機能開発できるメリットとして、既存機能のデータベースに容易にアクセスできることがあります。

また、IT ガバナンス、内部統制、サービス運用などを考えるとシステムの稼働する環境が増えることは IT 運用部門にとってかなりの負担となります。そのため、同じ環境にさまざまなサービスがまとめられることは嬉しいポイントになります。

youtu.be

 

AppExchange

ノーコード、ローコード、プロコードを利用することで、顧客ごとにアプリケーションを開発できます。しかし、アプリケーションを開発しようとすると、それなりに工数がかかります。一般的なアプリケーションであれば、わざわざ開発するのではなく、市販のアプリケーションを利用したくなります。

AppExchagne はアプリケーション・マーケットで、パートナーによって開発されたアプリケーションを探し、インストールできるようになっています。 SalesCloud や ServiceCloud など Salesforce.com 社が提供するサービスだけでは業務を網羅できない部分があります。このパートナーが開発したアプリケーションを利用することで、その隙間を埋めることができます。

 

ISVforce

AppExchange のマーケットにアプリケーションを登録しているパートナーは AppExchange パートナーと呼ばれ、 SaaS プロダクトを開発・提供・運用するために必要な機能が Salesforce.com 社から ISVforce という名で提供されています。

最初に説明した Salesforce Platform で提供されるノーコード、ローコード、プロコードも AppExchange パートナーが開発したアプリケーションで利用できます。

これらをフル活用することで、AppExchange パートナーは B2B サービスで必要となる汎用機能や SalesCloud、ServiceCloudと同等のカスタマイズ性を手に入れ、さらにインフラ運用は Salesforce.com 社に任せ、アプリケーション開発に注力することができます。

youtu.be

 

このように AppExchange パートナーは Salesforce.com 社のサービスが提供していない機能を提供し、Salesforce.com 社は AppExchange パートナーに SaaS を構築するための業務アプリ・プラットフォームを提供する、相互補完的なエコシステムを構築しています。

 

まとめ

今回の発表では、B2B サービスではカスタマイズ性が重要となること、Salesforce Platform が強力なカスタマイズ性を持つことを説明しました。

Salesforce Platform のカスタマイズ性を分割すると、下記の3つになります。
1. No-Code / Low-Code
2. Pro-Code
3. AppExchange

これらの要素は、AppExchange パートナーもその恩恵を受けられます。それ以外にも ISVforce の機能や堅牢なインフラを活用できることで、AppExchange パートナーは B2B サービスのアプリケーション開発に集中できます。これが、Salesforce が最強の業務アプリ・プラットフォームである理由になります。

 

そして、コミュニティ

最後に、Salesforce コミュニティ・イベントでの発表なので、Salesforce.com 社が作り上げた Trailblazer についても言及しました。これまであまり脚光を浴びていなかったシステム管理者をヒーローにした施策は本当に驚異的です。Salesforce が最強である所以はこの人々の存在が大きいので、イベントの締めで話させてもらいました。

f:id:a-kura:20210314140340p:plain

Trailblazer

 

今年で3年目となりました。今年も運営してくれた人たちのおかげで素晴らしいイベントになりました。運営メンバーの努力と貢献に感謝します。そして、来年はさらに進化したイベントになると確信しています。

 

Enjoy Japan Dreamin'!

 


この記事は、 note.com に投稿した記事の転載になります。

note.com

 

B2B SaaSエンジニアMeetup - Sharing Issues Online #1 に登壇してきた!

2020年11月6日(金)に開催された B2B SaaSエンジニアMeetup - Sharing Issues Online #1 に参加・登壇してきました。

smartcamp.connpass.com


今回の発表では、SaaS プロダクトでは重要となる管理画面について話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。

www2.slideshare.net

www.youtube.com

愛される管理画面の作り方

これまでの受託開発であれば、管理画面はバグなく使えればよいと重視されないことも多かったのではないでしょうか?しかし、SaaS プロダクト開発において、管理画面は重要性が増してきています。

理由としては、SaaS プロダクトの選定・推進・運用が情報システム部門から業務管理部門(人事部、経理部など)にシフトしてきていることが大きいです。ITの専門家でない業務管理部門が自ら SaaS プロダクトを利用していくためには管理画面がITに精通していない人でも習熟できる程度に作り込まれている必要があります。

もし、管理画面が習熟するために多大な労力が必要な場合には、導入時には使いこなせないと判断されてしまう可能性があります。なんとか導入されたとしても他のメンバーに継承されず、管理者が変わってしまうことで活用できなくなると結局解約につながってしまいます。

解約率を下げて活用し続けてもらうことを目指す SaaS プロダクトでは、愛される管理画面を作ることが非常に重要になってきます。

どんな管理画面が愛されるのか?

では、どんな管理画面が愛されるのでしょうか?

f:id:a-kura:20201116121550p:plain
狩野モデル

一般的な品質の考え方として、狩野モデルがあります。当たり前品質を確保し、一元的品質が高めることはもちろんですが、愛されるためには魅力的品質が重要であることがわかります。

管理画面が抱える問題

まず、使い勝手を高めるために管理画面がどういった問題を抱えているか整理します。管理画面が抱える問題としては、下記の3点があります。

① 機能や設定が多く、探しきれない
② 機能や設定がそれぞれ難解である
③ 複数の機能や設定が関連している

これらの問題について、それぞれの解決策を考えていきたいと思います。

PROBLEM ① 機能や設定が多く、探しきれない

SaaS プロダクトはバージョンアップしていくに従い、機能や設定が増えていきます。そのためにどこに設定があるか探しきれなくなっていきます。ツリーメニューなどを準備して探しやすくしたとしても限界があります。

f:id:a-kura:20210314133548j:plain
1st 機能や設定が多く、探しきれない

では、どうすればよいでしょうか?

SOLUTION ① 管理メニューに検索機能をつける

この問題の解決策としては、インデックス型の探し方を諦め、サーチ型に移行することです。つまり、検索機能をつけてしまいます。

f:id:a-kura:20210314133725j:plain
SOLUTION ① 管理メニューに検索機能をつける

では、どうすればよいでしょうか?

SOLUTION ② 運用観点の説明を充実させる

この問題の解決策としては、運用観点の説明を充実させることです。具体的には、ポップアップで説明を表示する、注意事項を表示する、ヘルプページへのリンクを配置する、といったことです。

f:id:a-kura:20210314133826j:plain
SOLUTION ② 運用観点の説明を充実させる

管理画面はたまにしか利用しないため、利用方法が分からないことがあります。設定などは設定するときにならないと、どういった設定なのか知らないことも多いです。そこで、できるだけ管理画面から情報提供できるようにすることで使いやすくなります。

PROBLEM ③ 複数の機能や設定が関連している

複雑化した機能や設定は、一つだけではやりたいことを実現できなくなっていきます。また、管理メニューは機能によって分類します。複数の機能や設定が関連する場合は単純に分類しただけでは管理メニューのなかでは分散してしまいます。そのため、機能や設定を探すのに手間取ったり、手順を抜かしたり前後してしまったりします。

f:id:a-kura:20210314133857j:plain
PROBLEM ③ 複数の機能や設定が関連している

では、どうすればよいでしょうか?

SOLUTION ③ やりたいことから辿れる

この問題の解決策としては、やりたいことから辿れるようにします。管理メニューは機能を分類しており、やりたいことの分類になっていません。その役割はFAQやガイドなど別のドキュメントに役割を持たせたほうがよいです。

f:id:a-kura:20210314133926j:plain
SOLUTION ③ やりたいことから辿れる

FAQにはお客様がやりたいと質問してきたこと、ガイドにはお客様の業務イベントに沿った手順、がまとめられており、やりたいことを抜け漏れ手順前後することなく実施できるようになっています。

このようにすることで、慣れていることは管理メニューから、不慣れなことはFAQやガイドから辿れるようにすることでスムーズにやりたいことを実施できるようになります。

まとめ

今回の発表では、「なぜ、愛される管理画面を作る必要があるのか?」から紐解きながら、どういった機能を備えておくことが望ましいか紹介しました。

f:id:a-kura:20201117074206p:plain
まとめ

プロダクトの状況によって今回紹介したことが当てはまらないこともあると思いますが、管理画面の使いやすさを向上させる一助になれば幸いです。

Enjoy Engineering!


この記事は、 note.com に投稿した記事の転載になります。
note.com

在宅勤務で散財ヒストリー 2020

2020年は突然のコロナ禍によって、オフィス勤務から在宅勤務に切り替わりました。そのため、在宅勤務の職場環境を整える必要がありました。
今回は、今年在宅勤務を快適にするために散財してきた商品を紹介していきたいと思います。

WHALEN Ⅳ メッシュチェアー

まずは1品目。

下記のPodcastのエピソードで紹介されている「WHALEN Ⅳ メッシュチェアー」です。このデスクチェアはコストコジェネリックアーロンチェアとして一部で有名なものになります。
backspace.fm

この「WHALEN Ⅳ メッシュチェアー」は非常にしっかりとした作りになっているにもかかわらず、価格は11,980円(税込)。圧倒的なコストパフォーマンスです!

f:id:a-kura:20201205185844p:plain
WHALEN IV メッシュチェアー

在宅勤務が始まって2ヶ月くらいした頃にハードな腰痛に見舞われて、デスクチェアを買い直しました。以降、腰痛もなく在宅勤務できています。

「この散財、まったく後悔はない」

続きを読む

Salesforceで項目履歴をDIYする!

今年も技術系アドベントカレンダーの季節がやってまいりました。皆さま元気にお過ごしでしょうか?

今年はコロナ禍のため Dreamforce もリアルイベントではなく、バーチャル開催となりました。バーチャル開催となることでこれまで参加できなかった人も参加できるようになりました。どんなイベントになるか楽しみです。
www.salesforce.com

さて、今年も技術系アドベントカレンダーがクリスマスまで25日間続きます。今日から毎日投稿されるアドベントカレンダーの記事を読んで楽しみましょう!

はじめに

エンタープライズでは項目の監査履歴を求められることがあります。Salesforce Shieldで提供される項目監査履歴を利用するのが定跡ですが、有償機能にしないと制限があり、かつ有償機能を利用しても60項目までしか履歴を追跡できません。

そこで、今回は項目履歴をDIYしてみましょう。

項目監査履歴

まず、標準的に利用できる項目監査履歴についてです。
Salesforce Shield で提供される機能となり、設定した項目監査履歴保持ポリシーにしたがって項目履歴をアーカイブしていきます。Salesforce Shield は有償機能ですが、無償でも一部の機能を利用できます。

有償の場合
・1 オブジェクトにつき60個までの項目追跡
アーカイブされた時点から最長 10 年保持

無償の場合
・1 オブジェクトにつき20個までの項目追跡
アーカイブされた時間から 18 ヶ月

より詳細はSalesforceセキュリティガイドなどを参考にしてください。
developer.salesforce.com

項目履歴をDIYする

さて、ここからは項目監査履歴を利用してもいろいろと制約があるため、せっかくなのでDIYしていきます。

今回利用する機能は、変更データキャプチャとBig Objectになります。普段聞き慣れない機能なので、簡単に紹介していきます。

変更データキャプチャ

変更データキャプチャはSalesforce データを外部データと効率よく統合できるようにするための機能です。詳しくはTrailheadのモジュールを学習してもらうと理解できると思います。

今回は、例外的な使い方になりそうですが、カスタムオブジェクトの作成・更新・削除・復元のイベントでログを記録するために利用します。通常のApexトリガーでもよいのですが、変更された項目が取得しやすいので使ってみました。
trailhead.salesforce.com

Big Object

Big ObjectはSalesforce Platform 上で大量のデータを保存して管理するための機能です。用途としては、顧客の360度ビュー、監査と追跡、履歴アーカイブなど、まさに今回の用途に利用することが想定されています。
trailhead.salesforce.com

設計

設計としては下図のようになります。

f:id:a-kura:20201201234700p:plain
設計図

項目履歴を記録した対象のカスタムオブジェクトに変更データキャプチャの設定、およびChangeEventに対するApexトリガーを設定します。このApexトリガー内で履歴データを作成し、BigObjectに書き込みます。

変更データキャプチャを利用すると強制的に非同期実行となるため、同期処理に負担をかけず処理できるところがよいところです。今回のケースでは、Big Objectへの書き込みも非同期処理となってしまい、やりすぎな感じがします。

実装

続いて、実装になります。ChangeEventHeaderに更新操作で変更された項目のリストであるchangedfieldsがあり、変更点のログの組み立てが簡単にできるようになっています。

trigger ChangeCustomObjectChangeTrigger on ChangeCustomObject__ChangeEvent (after insert) {
   List<FieldHistory__b> historyList = new List<FieldHistory__b>();
   
	for (ChangeCustomObject__ChangeEvent event : Trigger.New) {
    	EventBus.ChangeEventHeader header = event.ChangeEventHeader;
        
        FieldHistory__b history = new FieldHistory__b();
       
        switch on header.changetype {
            when 'INSERT' {
                // 追加時に記録するログを組み立てる
            }
            when 'UPDATE' {
                // 更新時に記録するログを組み立てる
            }
            when 'DELETE' {
                // 削除時に記録するログを組み立てる
            }
            WHEN 'UNDELETE' {
                // 復元時に記録するログを組み立てる
            }
        }
        historyList.add(history);
    }
    if(historyList.size() > 0) {
        Database.insertImmediate(historyList);
    }
}

カスタムオブジェクトの項目値の変更をJSON形式に変換して履歴として保存しておくことで項目履歴が記録できるようになります。時間の関係でJSON形式の文字列を組み立てるコードは割愛させてもらっています(作業時間が取れれば追記します)。

おわりに

変更データキャプチャとBigObjectを利用した項目履歴のDIYについてご紹介しました。

正直なところ、変更データキャプチャはオーバーエンジニアリング気味です。本来、変更データキャプチャはサービス間のイベントをストリーミングでやりとりします。SalesforceではこれをApexトリガーで扱え、複雑な実装なしで利用できる点は非常に優れていると感じました。

プラットフォームイベントと合わせて、難易度の高かったサービス間連携が比較的簡単に実装できそうです。今回は技術に触ってみるといったところまででしたが、利用方法を研究していきたいと思います。

Enjoy Advent Calendar!


この記事は、 note.com に投稿した記事の転載になります。
note.com

ノーコード/ローコード開発時代における技術選定

はじめに

先日のテラスカイ横山さん、TAOドライブ米井さんとの収録で、Salesforceでのノーコード/ローコード開発とプロコード開発の技術選定の基準について話しました。

migration.fm

とても複雑な問題であり、その場はあまり深く踏み込まずに終わりました。その後、独りで掘り下げて考えてみたので、私なりにエッセンスをまとめたいと思います。

 

技術選定基準

技術選定するために必要なことはなんでしょうか?
今回はノーコード/ローコードで開発すべきか、プロコードで開発すべきか、どちらにすればよいかを判断するための基準が必要だと考えました。

 

私が考えた技術選定の基準は下記の3つになります。

  1. 価値 Value
  2. 複雑さ Complexity
  3. 技術力 Technical Capabilities
続きを読む

Salesforceにおける継続的ノーコード開発のベストプラクティス

はじめに

先日のMiryさんとの収録でSalesforceでのノーコード開発で実践すべきプラクティスを伺うことができました。

migration.fm

Salesforceを活用しきる点において非常に先行する取り組みをされており、さまざまなノウハウがあることがわかりました。Podcastという音声メディアではググラビリティ(検索性)に劣るので、私なりにエッセンスをまとめたいと思います。

ベストプラクティス

ビジネスが成長する中でSalesforceを利用したノーコード開発を継続するためのベストプラクティスを下記の3点にまとめました。

  1. ノーコーディングルール
  2. ドキュメンテーション
  3. リファクタリング

以下では、それぞれのプラクティスについて掘り下げていきます。

ノーコーディングルール

ノーコードにおいても設計指針を策定することが重要です。
決めていくことはさまざまありますが、例えばトリガー系処理の優先順などです。

具体的にはトリガー系処理を下記のような優先順に取り決めます。

  1. 数式
  2. ワークフロールール
  3. プロセスビルダー
  4. フロー
  5. Apexトリガー

このような優先順にしている理由として、「できるだけSalesforce Adminが理解・対応できるようにして開発エンジニアではなくても対応する」という考えがあります。これによって、プログラミングできないようなビジネス寄りの人が設定変更できるようになり、業務と開発の両方を理解した人が作業することで適切な要件の落とし込みが素早くできるようになります。

なぜ、このようなルールが必要なのかというと、開発エンジニアは慣れているプロコードの方が楽なのでルール化しておかないとSalesforce Adminが理解・変更できる領域が狭まってしまいます。そのため、この方針を背景とともにメンバーが理解し、設定を考える上での具体的なルールに落とし込むことが重要になります。

ドキュメンテーション

Salesforceの設定は簡単に変更できるため、ついその場の対応で設定を変更していきがちです。そういった場当たり的な対応を続けていると、下記のような負の連鎖が起きてしまいます。

まず、現在Salesforce組織にどういった設定がされているか分からなくなります。記憶力がいい人がすべてを把握して対応していれば、まだ管理できた状態を保てます。しかし、歴史が長くなり忘れてしまったり、別の人が対応することになったりすると問題が表出してきます。

このような状態では、現在の設定がどういった経緯で設定されたか分からないため、安易に変更できなくなり、下記のような問題が発生してきます。

まず、既存の設定を変更するために経緯を確認し、影響範囲を調査する作業が必要となるため、設定変更に時間がかかってしまうことです。Salesforceでは設定画面を操作して設定していくため、関連する設定を探しにくいところがあります。

次に、そのような調査や検討が飛ばされてしまうことです。調査する時間が取れないため、時間のあるときに見直そうと現在の設定に影響しないように追加で設定ししてしまうことです。しかし、こういった負債は日々の作業に追われて返済されることなく溜まっていくことになります。

最後の問題は、継ぎ接ぎだらけの設定になることで複雑化してしまうことです。複雑化してしまった設定のメンテナンス性は低下し、処理も遅くなってしまいます。

このようにして、設定は日々肥大化し、複雑化していきます。では、このような状態にならないようにするためにはどのようにすればよいのでしょうか?

設定が肥大化・複雑化していく問題に対する万能な解決策「銀の弾丸」はありません。地道なエンジニアリングで負債を溜めないようにしていくしかありません。
その中でもドキュメントを残すプラクティスが重要です。ドキュメントに過去の経緯や影響範囲などがまとまっていることで上記のような問題が起こりにくくなります。ドキュメントベースで他の人とレビューしたり、共有したりできるようになります。

このようにドキュメンテーションしていくことで、肥大化・複雑化しがちな既存の設定を見直し最適な状態に保つ礎を築くことができます。

リファクタリング

ドキュメンテーションのプラクティスでも触れましたが、ノーコード開発を継続するためにはメンテナンス性を高い状態に保つことが重要です。

ドキュメンテーションによって日頃から肥大化・複雑化する設定を増やさないことも重要ですが、日々忙しくしているとどうしても負債が蓄積されていってしまいます。また、ビジネスの変化によって不要となる設定や項目があったり、新しい機能がリリースされることでより良い設定ができるようになったりします。

そのため、定期的に時間を確保して、既存の設定や項目を見直す作業「リファクタリング」を実施することが重要です。
リファクタリングでは下記のようなことを実施します。
1. 不要になった設定や項目がないか確認する
2. 肥大化・複雑化している設定を簡潔に直せないか考える
3. 新しい機能で利用できるものがないか考える

Salesforceの設定はビジネスに合わせてスピード優先で走りながら直していく側面もあります。ビジネスの変化が落ち着いたところで設定を最適化した方がよい局面もあるので、リファクタリングをプロセスに取り込んでいくことでメンテナンス性とスピードのバランスを取ることが重要です。

今後の課題

Salesforceにおける継続的ノーコード開発において課題と考えていることが2点あります。

テスト

Miryさんも話していましたが、ノーコードで開発した物はマニュアルテストを頑張って実施していくしかありません。開発物が増大すると影響範囲も広くなり、既存の設定に影響ないことを確認するためのマニュアルテストの負担が増えていきます。

テスト自動化ツールを利用して、マニュアルテストの一部を自動テストに置き換えていく、などの取り組みも必要になると考えます。

構成管理

Salesforceの設定の構成管理をどのように実施していくか、はまだ解決できていない課題だと考えています。SalesforceDXによってメタデータの取り扱いやソースコード管理ができるようになってきていますが、まだ開発エンジニア向けの機能であり、Salesforce Adminが扱うには難しいのが現状です。

SalesforceDXの機能拡充が進み解決していくとは思いますが、それまでは工夫して対応していく必要があると考えます。

まとめ

この記事では、継続的にノーコード開発を実践するためのベストプラクティスとして、ノーコーディングルール、ドキュメンテーションリファクタリングを紹介しました。

一貫する考え方としては、エンジニアリング手法を導入しながら Salesforce Admin をエンパワーメントすることです。今後ますます Salesforce Platform が強力になることで業務要件を簡単に開発できるようになっていき、Salesforce Admin によるノーコード開発はより広く実践されていくことになります。しかし、ノーコード開発は開発モデルがまだ成熟しておらず、このようなベストプラクティスが蓄積されていくことが重要だと感じました。

この記事は、 note.com に投稿した記事の転載になります。
note.com

Japan Dreamin’ 2020 登壇してきた!

遅くなりましたが、2020年1月25日(土)に開催された Japan Dreamin' 2020 に参加・登壇してきました。 

今回の発表では、AppExchange プロダクトを継続して開発していく中で注意すべき点について話しました。こちらから資料を見ることができますので、よろしければご覧ください。

www.slideshare.net

Japan Dreamin' 2020

Japan Dreamin’2020 での発表資料を参照できるものもあります。さまざまなテーマで発表されており、参考になる発表も数多くあると思いますので、ご自身の興味のあるテーマを探してみていただければと思います。

www.japandreamin.com

続きを読む