タグ: 新人

はじめに

こんにちは！株式会社オプトプランニングです。

先日リリースについて書きましたが、その際書けなかったクローズ後の変更セットの私なりの使い方を忘備録も兼ねて書いていきたいと思います。

クローズした変更セットの利用方法その１

同じ変更セットを使いまわす

まずは、変更セットの再利用です。

• 同じ変更セットを複数の組織にリリースする必要がある
  
• 本番組織をベースに作成したSandbox環境でリリースの評価・テストを行い、問題なかったので同じ内容の変更セットを本番環境にリリースしたい

など、同一内容の変更セットを別組織にリリースしたい場面はあると思います。

クローズした変更セットは編集はできなくなりますが「アップロード」ボタンは残っています。
これを利用し、クローズした変更セットを別環境にアップロード・リリースすること（再利用）ができます。
（※クローズした変更セットに含まれるコンポーネントは、変更セット作成後に削除や修正をしていない場合に限ります。詳しくは後ほど説明します。）

アップロードする際、対象組織に対してリリース接続の設定を行うことが必要ですので、そこは忘れずに行いましょう。

１つの変更セットを再利用する良い点は、「変更セットアップロード履歴」が残ることです。
アップロードする度に残るので、後からどの組織にアップロードしたかの確認ができます。

Trailheadでは

送信変更セットを別の組織にアップロードした後で、異なる組織にアップロードすることはできません。

インテグレーション環境でのテストと変更のリリースhttps://trailhead.salesforce.com/ja/content/learn/modules/declarative-change-set-development/test-in-the-integration-environment-and-deploy-changes

とありますが、Developer SandboxからDeveloper Sandboxまたは本番組織に向けてのアップロードはできることを確認しています。

Sandboxの種類が違う場合などは検証しておりませんので、うまくいかない場合はTrailheadにあるように変更セットのコピーを行ってください。

クローズ後の変更セットのアップロード方法

変更セットのアップロードボタンは、送信変更セットの一覧や変更セットの詳細にあります。

クローズ後の変更セットをアップロードしようとすると図５のような画面になります。
変更セットをどの環境にもアップロードしていない図４の時と比べてみると、

この変更セットをアップロードすると、編集できなくなり、対象組織から取り消すこともできません。

というメッセージがクローズした変更セットに表示されていないことがわかります。

既にクローズしている変更セットはそもそも編集することができないため、注意書きが現れないようです。

使いまわす時の注意点その１

1つ目に注意したいのは、すでにアップロードした組織も選択できる点です。

同じ変更セットを複数回にわたって同一環境にアップロードしても特に問題は起きません。
逆を言えば、エラーも出ないということです。

アップロードは成功したのにアップロードしたはずの環境（対象組織）に受信変更セットがみつからない…？という時はアップロード先に間違いがないか確認しましょう。

アップロード先は、変更セットアップロード履歴やアップロード完了の通知メールで確認できます。
アップロード完了の通知メールには、送信変更セットのソース組織と対象組織が明記されています。

参考までに、「リリースしてみた＜アップロード編＞」で載せなかったアップロード完了の通知メールはこんな感じです。
システムメールとしてSalesforceから送られてきます。

使いまわす時の注意点その２

2つ目の注意点としては、１度にアップロードできる対象組織は１つだけという点です。
アップロード先を選択する画面はラジオボタンで構成されており、複数の組織を選択することは不可能となっています。

複数の組織に同じ変更セットをアップロードしたい場合はそれぞれアップロード手順を行う必要があります。

使いまわす時の注意点その３

３つ目の注意点としては、クローズした変更セットに含まれるコンポーネントは更新されないという点です。

例えば、前回のリリースしてみた＜変更セット作成編＞で追加した権限セット「MFA」について、変更セットアップロード後に修正を加えたとします。
アップロード後の変更セット（クローズした変更セット）はコンポーネントの更新が行われないので、権限セット「MFA」に行ったは反映されません。

変更セットに変更はないが、変更セットのコンポーネントの内容に変更がある場合は、「変更セットのコピー」を作成しないと修正内容を反映することはできません。

コンポーネントの更新という考え方が少し難しく感じますね…

クローズした変更セットの利用方法その２

変更セットのコピーを作成し編集する

クローズした変更セットは編集することはできませんが、コピーを作成することは可能です。
また、作成したコピーに対しては変更セットの編集ができます！！

このことを利用し、クローズした変更セットを編集したい時はコピーを作成するといいと思います。

• リリースでコンポーネント不備によるエラーが出た
  
• リリースでエラーも無く一安心した後に、リリース環境の確認を行っていて入れそびれたコンポーネントがあることに気づいてしまった

などなど、変更セットの作り直しが発生してしまうのはよくあることだと思います。（きっと私だけじゃない…はず　笑）

リリースしそびれたコンポーネントだけの変更セットを新しく作成してもいいのですが、

• エラーやコンポーネント不足の度に変更セットを作成すると、沢山の変更セットが作られてしまう
  →どんな内容の変更セットをアップロード（リリース）したか履歴を確認する可能性があるため、リリース内容をなるべく１つの変更セットにまとめておきたかった
  
• 「連動関係を参照/追加」を使用することで、変更セットに含めたい関連するコンポーネントが探し出しやすい

といった理由から、変更セットのコピーを作成しコンポーネントを追加（削除）する、ということを行いました。

変更セットのコピーの作り方

変更セットのコピーはとても簡単に作成できます。
対象の変更セットの「コピー」をクリックするだけです。

アップロードと同様、「コピー」は、送信変更セットの一覧や変更セットの詳細にあります。

コピーをクリックすると、「変更セットのコピー」に遷移し、ここで変更セットの名前や説明を変えることができます。

ベースの変更セットと混同しないためにも、名前や説明はコピーであることが分かりやすいものに変更しておいた方がいいと思います。

図１１ではすでに名前や説明を変更してありますが、「変更セットのコピー」の名前と説明にはデフォルトでベースの変更セットと同じ内容がそれぞれ入力されています。

変更セットのコピーを保存すると、ベースの変更セットのコンポーネントを引き継いだ「状況」がオープンの変更セットが出来上がります。

あとは、新規作成の時と同様にコンポーネントの追加を行ったり、不要なコンポーネントの削除を行いましょう。

あとがき

変更セットのコンポーネントの種類は、作成したことがある方ならわかると思いますがとても沢山あります。
以前どのぐらいあるか調べた時は約120種類ありました。（2021年12月ぐらいに調べました）

中には見たことのないコンポーネント種類名もあったりしたので、変更セットの作成は本当に大変な作業だと思います。

今回は、クローズ後の変更セットに焦点を当てて使い道について書いてみました。
クローズ後に限らず、良い使い道を思いついたら第二弾としてまとめられればと思います。

それでは、またお会いしましょう！！

関連記事
リリースしてみた＜変更セット作成編＞
リリースしてみた＜アップロード編＞

はじめに

こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースをやってみようと思います！！

前回までのおさらいと気づき

今までのやってみたこと

前々回 は変更セットの作成を行いました。

そして 前回 は変更セットのアップロードを行い、送信変更セットのアップロード前後の違いを確認しました。

使用環境やリリースの内容については 利用環境と内容 を見てください。

前回のブログアップ後に気づいたこと

今回の本題であるリリースを行う前に、前回のブログアップ後に気づいたことを書いていきたいと思います。

前回、変更セットのアップロード前後の比較・確認を行うために画像を載せていました。
この部分に、前回は全く気づかなかったちょっとした違いがありました。

どこかわかりますか…？？

なんと、変更セットコンポーネントの「名前」が違うのです…！！！！！

リリース作業は実務でも行いましたが、アップロード後にコンポーネントの名前が変わることは気づいていませんでした…！！

なので、全てのコンポーネントの名前が変わるのか、特定の種別のコンポーネントだけなのかなどについても不明です…

今回に関しては、アップロード前はAPI参照名が表示されており、アップロード後は表示ラベルが表示されているようです。
（ちなみに、受信変更セットでは表示ラベルが表示されているようです。）

どうしてこのような動作になるか不明ですが、今まで一貫して以下の権限セット１つをコンポーネントに追加して作成した変更セットを使用しています。

この件については、なぜこのようなことが起こるのか・他の種類のコンポーネントの時はどうなるのかなど、詳細がわかり次第ブログでご紹介できるように調査を続けていきたいと思います。
（もしかしたら、プロファイル関係の変更セットだったからかな…？と思ったり…）

今回のブログでもコンポーネント名が入った画像が出てきますが、名前が違っても間違いなく同じ変更セットを使用していますので、特に注意書きなどありませんがそのように読み進めていただければと思います。

受信変更セットを確認してみた

初っ端から脱線してしまいましたが、話を戻してリリース作業を再開していきます！！

開発環境で作成した「送信変更セット」はアップロードすることによりリリース環境で「受信変更セット」として受け入れているはずです。

前回は送信変更セットのアップロード完了までの確認を行いましたので、まずはリリース環境の方で受信変更セットの確認から行っていこうと思います！

最初に、リリース環境である「T2Sandbox」にログインし、設定の検索ボックスに「変更セット」と入力して「受信変更セット」を開きます。

受信変更セットを開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

受信変更セットの一覧が表示されます。

「リリース待ちの変更セット」に前回アップロードした変更セットを確認することができます！！

これで、リリース環境に変更セットのアップロードが無事に行われていることの確認ができました。

変更セット名の部分がリンクになっているので、クリックしてしてみましょう。

すると、変更セットの詳細画面が表示されます。

送信変更セットと違う点として、「ソース組織」があります。
（先ほどの受信変更セット一覧の画面でも確認することができます）
ここでどの環境からアップロードされた変更セットなのかを確認することができます。

また、「有効期限」もあります。
受信変更セットには有効期限が設けられています。
有効期限はアップロード後６か月です。

変更セットをアップロードして半年後にリリースを行うことはないと思いますが…

有効期限が切れると、変更セットは永久に削除されます。

引用：送信変更セットのアップロード（Salesforceヘルプより）

と書かれていますので、後から内容を確認したい時に確認ができない…！ということにならないように気を付ける必要はありそうです。

リリースしてみた

受信変更セットを使用してのリリース

受信変更セットの確認も終わりましたので、遂にリリースを行います…！！
ここまで長かった…！！

リリースは受信変更セットから行います。

受信変更セットの一覧を表示させ、先ほど確認した「リリース待ちの変更セット」のアクション欄にある「リリース」をクリックします。

すると、「変更セットのリリース」画面に移動します。

「テストオプションの選択」にいくつか選択できる項目がありますが、今回は「デフォルト」を選択し、「リリース」をクリックします。

このようなポップアップが立ち上がるので、「OK」をクリックします。

リリースが開始され、画面はリリースを行った変更セットの詳細画面に移ります。

変更セットの詳細の上部にさっきまで無かった「開始されたリリース」という強調表示があります。
この表示が、対象の変更セットが現在リリース中であることを表しています。

強調表示部分の「リリース状況」と書かれた部分はリンクになっており、リンク先では対象の変更セットの詳しいリリース状況を確認することができます。

クリックしてみるとリリース状況の画面に移動しました。

今回は変更セットのコンポーネントが少ないため、リリース状況をみるとすでに「成功」の一覧に表示されていました。

これでリリースは無事に完了です！！！

もしここでなんらかの理由でリリースができなかった場合、「失敗」の一覧に変更セット名が表示され、アクション欄の「詳細を表示」でエラー内容を確認することができます。

また、コンポーネントの数が多かったりApexやVFPがたくさん入っていると検証に時間がかかりますので、その時は気長に待ってみましょう。

リリースの確認

では、今回行ったリリースがちゃんと反映されているか確認してみます。

コンポーネントとして含めた権限セットを確認するため、設定の検索ボックスに「権限セット」と入力して「権限セット」を開きます。

表示される権限セットの一覧に、今回コンポーネントとして含めた「ユーザのMFA認証」が追加されていることが確認でき、ちゃんと変更セットでのリリースができていることがわかりました！！

リリース後の受信変更セットを確認してみた

受信変更セット一覧

リリースは無事に終わりましたが、リリース後の受信変更セットについても確認しておこうと思います。

まずは受信変更セット一覧の画面です。

リリースが成功すると、対象の変更セットは「リリース済みの変更セット」の欄に移動します。
また、「アップロード日」ではなく「リリース日」が表示されるようになります。

受信変更セット詳細画面

次に、リリース後の受信変更セットの詳細画面を確認してみます。

リリース中にあった強調表示がなくなる代わりに、「リリース履歴」が追加されています。

この部分、エラーでリリースが失敗した場合も履歴として追加されていきます。
エラーの場合、「アクション」の「詳細を表示」でエラー内容の詳細を確認することができます。

また、今回は行っていませんが「検証」を行った場合もこの履歴が追加されていきます。

「リリース待ちの変更セット」欄に表示されている変更セットで、この「リリース履歴」にエラーがある場合はリリースを行う前に内容を確認しておく方がいいでしょう。

リリース履歴には開始時刻と終了時刻が表示されているので、どのぐらいの時間でリリースが完了したか確認することもできます。
（今回のリリースは全く時間がかかっていないことが分かります。）

あとがき

リリースはあっけなく終わってしまいましたが、これで無事に変更セットを使用したリリースを完了することができました。

確認作業は別として、実際のリリースも変更セットの作成が一番比重の大きい作業だと思います。

今回は１つのコンポーネントでしたが、リリースするコンポーネントが増えるにつれエラーも起きやすいので、リリースでエラーがでたら変更セットの作り直し＆アップロードの繰り返し…を行っていくことになると思います。

変更セットの作り直しやアップロードのやり直し、使いまわしについて、実際にやってみてこのような使い方をすれば効率がいいかも…？と感じたことがいくつかあるので、近いうちにまとめをブログでアップできればと思います。

では、またお会いしましょう！！

関連記事
リリースしてみた＜変更セット作成編＞
リリースしてみた＜アップロード編＞

はじめに

こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースに向けて変更セットのアップロードをやってみようと思います！！

前回までのおさらい

前回 は送信変更セットを作成しました。

無事に作成できたのでアップロードを行おうとしたところ、このような画面が出てしまいました。

リリースするためには変更セットを作成するだけではできない…！！

ということに気づいたのが前回の変更セット作成編でした。

アップロードの準備をやってみた

アップロードに必要な設定とは

変更セットをアップロードするには、アップロード先の環境（変更セットを受け取る環境）でリリース接続の設定を行う必要があります。

デフォルトの状態では、本番組織・Sandbox問わず全環境で変更セットのアップロードを受け付けていない状態となっています。
そこで、どの環境からの変更セットを受け付けるか受け取る側の環境で設定する必要があります。

変更セットの作成はアップロード先の環境があってもなくてもできますし、リリース接続の設定は変更セットを作成する前に行っても後に行っても問題ありません。

リリース接続の設定を行う

今回は先に変更セットの作成を行ったので、次にアップロード先の「T2Sandbox」でリリース接続の設定を行います。（使用環境などは 前回の使用環境と内容 を参照）

変更セットの作成は「TSandbox」で行っていたので、現在のログインしている環境は「TSandbox」です。
まずは「T2Sandbox」に環境を変えるためログインし直します。
ログイン出来たら、設定の検索ボックスに「リリース」と入力して「リリース設定」を開きます。

リリース設定を開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

リリース設定を開くとリリース接続先として組織の一覧が表示されます。
この一覧から、どの環境に対しての変更セットを受け付けるか個別に設定していくことになります。

「TSandbox」からの接続を許可したいので、「TSandbox」の左横にある「編集」をクリックします。

「リリース接続の詳細」画面が開くので、「アップロード認識方向」内の「変更着信を許可」にチェックをつけて「保存」をクリックします。

「保存」をクリックすると「リリース設定」の画面に戻ります。

リリース設定画面を見ると、先ほど設定を行った「TSandbox」の右端にある「アップロード認証方向」が変わっていることがわかります。

このような表示になっていれば、リリース接続の設定は完了です。

これで「TSandbox」から「T2Sandbox」へ変更セットをアップロードできるようになりました！！

送信側のリリースの設定を確認

アップロードを行う前に、送信側の「TSandbox」のリリース設定を確認してみたいと思います。

「TSandbox」にログイン後、先ほどと同様の手順でリリース設定を開くと、「TSandbox」から「T2Sandbox」に向けて矢印がついていることが確認できます。

アップロード認証方向は現在ログインしている環境を基準に表示されるので、「TSandbox」と「T2Sandbox」で表示のされ方が違いますが認証方向に違いはありません。

次に、組織一覧の中の「T2Sandbox」横の「編集」をクリックして詳細を開いてみます。

詳細を開くと、すでに「変更送信を受け入れる」にチェックがついていることが確認できます。

こちら、画像では分かりにくいですが「変更送信を受け入れる」のチェックボックスは操作することができないようになっています。
このチェックボックスは対象組織の「変更着信を許可」と連動しているようです。

他組織の受け入れ設定を変更することはできないので、リリース接続の変更を行うときは先ほど「T2Sandbox」を設定したように設定変更したい組織にログインする必要があります。

ちょっと脱線：相互で変更着信を許可してみた

「TSandbox」のリリース設定の確認ができたところで、相互に「変更着信を許可」するとどうなるかやってみます。

保存をしてリリース設定画面に戻ってくると、「アップロード認証方向」の矢印が両方向に変わっていました。

それぞれ設定すれば相互にアップロードを許可できることがわかりました。（実際に設定するかは別として）

変更着信の設定は対象組織にログインすれば簡単なので、想定と違う組織にアップロードすることを防ぐためにもどの組織でどのように変更を許可しているかの管理は行わなければならないでしょう。

変更セットのアップロード再挑戦してみた

変更セットのアップロード：二回目

少し寄り道してしまいましたが、変更セットのアップロードに再挑戦します。

前回　と同様に「アップロード」をクリックすると、対象組織として「T2Sandbox」が表示されるようになりました。

「T2Sandbox」が選ばれていることを確認して、「アップロード」をクリックします。

今回は無事にアップロードができました！！

アップロードを行うのに少し時間がかかる場合がありますが、完了のメールも送られてきますよ。

アップロード前後の変更セットの違い

アップロード前後で何が変わるのか詳細画面を見比べてみました。

アップロード前後で変わることとして

• 状況の変化
• 「編集」ボタンの有無
• 変更セットアップロード履歴の有無
• 変更セットコンポーネントのアクションの変化

が挙げられます。

状況の変化としては、アップロード前が「オープン」アップロード後が「クローズ」に変化します。

また、アップロードするまではコンポーネントの追加及び削除といった編集を行うことができますが、アップロード後はそれらができなくなり、コンポーネントのアクションが「削除」から「ソースを表示」に変わります。

一番の違いは変更セットアップロード履歴の有無です。
アップロード後はどの組織にいつ誰がアップロードを行ったかという情報が追加されます。

あとがき

リリース接続を行うことで無事にアップロードができました。

後はリリースするだけ…となりましたが、変更セットのアップロードについて掘り下げていたら長くなってしまったので、リリースについては次回に持ち越したいと思います。
また、アップロード関連についてはまだ書き足りないことがあるので近いうちに別で紹介しようと思います。

リリースはあと少しで完了しそうですが、何事もなく進むといいな…

では、またお会いしましょう！！

関連記事
リリースしてみた＜変更セット作成編＞
リリースしてみた＜リリース編＞

はじめに

こんにちは！株式会社オプトプランニングです。
Salesforceでいろいろやってみた中での「ちょっとした気づき」を書いていこうと思います。

Salesforceの削除は、基本的に物理削除ではなく論理削除です。
このことについては多くの先輩方が詳しく説明して下さっているので私からの説明は割愛させていただきます。
論理削除ということで、レコード・カスタム項目・カスタムオブジェクトについて削除した後のデータについて気づいたことを書いていこうと思います。

また、普段Lightning Experienceを利用している場合の内容です。

レコードの削除後

削除後のレコードの行方は？

レコードの削除後、削除したレコードはどこにいくか知っていますか？？
削除したレコードは一定期間「ごみ箱」にいます。

間違って削除した！！という時は「ごみ箱」を見てみましょう。

ごみ箱の場所は？

ごみ箱はアプリケーションランチャー内にあります。

左上にあるカラフルな９つの「・」をクリックすると表示されるポップアップの一番下にある「すべて表示」をクリックします。

アプリケーションランチャーが開くので、「すべての項目」を見てみましょう。
「ごみ箱」を見つけることができました。

削除したレコードはすべてこの「ごみ箱」の中に一定期間保管されています。
間違って削除したレコードはここから復元することができますし、完全に削除することもできます。

カスタム項目の削除後

削除後のカスタム項目の行方は？

カスタム項目の削除後、削除したカスタム項目はどこに行くか知っていますか？？
削除したカスタム項目は一定期間「削除済みの項目」にいます。

間違って削除した！！という時は「削除済みの項目」を見てみましょう。

削除済みの項目の場所は？

削除済みの項目は各オブジェクトの「項目とリレーション」の右上にあります。

削除したカスタム項目は、カスタム項目を作成したオブジェクト詳細の「削除済みの項目」からでしか見ることができないことに注意してください。
レコードとは違い、削除後一か所に集約されているわけではありません。

間違って削除したカスタム項目はここから復元することができますし、完全に削除することもできます。

カスタムオブジェクトの削除後

削除後のカスタムオブジェクトの行方は？

カスタムオブジェクトの削除後、削除したカスタムオブジェクトはどこに行くか知っていますか？？
削除したカスタムオブジェクトは一定期間「削除済みオブジェクトリスト」にいます。

間違って削除した！！という時は「削除済みオブジェクトリスト」を見てみましょう。

削除済みオブジェクトリストの場所は？

この「削除済みオブジェクトリスト」ですが、レコードやカスタム項目と違いLightning Experienceでは表示することができません。

ではどうすれば表示できるかというと…

Salesforce Classicだと表示できます！！！

長い道のり

まず、Salesforce Classicに切り替えましょう。

切り替えはプロファイルを参照すると表示される「オプション」内にある「Salesforce Classicに切り替え」をクリックするとできます。

Salesforce Classicに切り替えるとホーム画面が表示されます。

画面上部にある「設定」をクリックすると、

次のような設定画面に変わります。

この画面を下にスクロールしていくと左の赤枠部分に「ビルド」が出てくるので、その中の「作成」内に「オブジェクト」があるのでクリックします。

カスタムオブジェクトの一覧が表示され、最下部に「削除済みオブジェクト」というのが確認できます。
この「削除済みオブジェクト」ですが、削除したカスタムオブジェクトがない場合、表示されません。

こちらが探していた「削除済みオブジェクトリスト」です。
やっと見つかりました…！

削除したカスタムオブジェクトはすべてこの「削除済みオブジェクトリスト」の中に一定期間保管されています。
間違って削除したカスタムオブジェクトはここから復元することができますし、完全に削除することもできます。

おまけ

15日間以上削除されない…？

カスタム項目やカスタムオブジェクトを削除する前、注意事項がかかれたポップアップが出現すると思います。
以下はカスタム項目を削除する前に表示されるものです。

15日を過ぎると、自動的に項目とそのすべてのデータが完全に削除されます。

とありますが…
15日経過後も残っていました～

2021年12月1日に削除した項目が、2022年2月7日の時点で残っていることが確認できます。
約二か月経過していますね！

「15日を過ぎると」とありますが、「15日後」ではないのです。
もちろん、15日経過後はいつまでデータが残っているかはわかりませんので、あくまで「こんな事例もあったよ」という参考までに。

もし、15日以上経過後に削除したものを復元したい場合は念のため削除後の各データ保存場所を確認してみたほうがいいかもしれません。

また、15日以上経過していても完全削除されているとは限らない、という点は留意しておいたほうがいいと思います。

念のため復元できるか試したところ、復元できました！！

あとがき

今回きっかけとなったのは、削除したものの復元のためではなく、削除したものの完全削除のためでした。

データが残っている状態だと作業が進まず、完全削除を行おうにも「削除済みオブジェクトリスト」がみつからなかったのです。
私がSalesforceに携わった時には既にLightning Experienceが存在したので、Classicはあまりなじみがないのも原因ですぐに見つけることができませんでした。

プロファイルの設定を行っても一部権限が付与されている場合はSalesforce Classicに切り替えるスイッチャを非表示にできません。
今まで何故だろう？と思っていましたが、まだLightning Experienceで使用できない機能があるからなのだと身をもって体験でき、いい勉強になりました。

カスタムオブジェクトやカスタム項目の作成は近いうちに「やってみた」で書いていこうと思います。

それではまた会いましょう！！