転職1年でアプリケーションアーキテクトを目指してみた
こんばんは。きゃらめるです！ かなりご無沙汰の更新になりました。。
JSデベロッパーの記事を書いた以降、止まっていたようですね…。
その間、Data Architecture and Managementデザイナー、Sales Cloud コンサルタント、Sharing and Visibilityデザイナーに挑戦し、
先日、4月16日にアプリケーションアーキテクトになりました！！
現段階で宣言するのも烏滸がましい気もするのですが、来年の今頃までにアプリケーションアーキテクトになりたい...という目標があります...🤤🤤🤤
— きゃらめる🐣 (@CalamelNuts) 2020年9月12日
私が、私のためだけに全力で働ける時間はそんなに長くないと思うので、スピード上げていきたい...
このツイートをしたのが9月の認定アドミンに合格した直後ですね。
本当は転職してすぐくらいから考えていた目標でした。
そういう意味では前倒して達成できた上にJSデベロッパーとSalesCloudコンサルまで取得できて、
我ながら頑張ったなーと大きな自信になりました！(*'ω'*)
私の資格取得目標を応援して援助してくださった会社と社員の皆さま、
Twitterや勉強会などで温かく声をかけてくださるSalesforce界隈の皆さまに感謝です！
これから少しずつ、身に着けた知識で返していけるように頑張るぞ！
２つのデザイナー試験、どうだったか？
アプリケーションアーキテクトになるにはData Architecture and Managementデザイナー、Sharing and Visibilityデザイナーの2つの試験に合格しなければいけないのですが、各試験について所感を残しておこうかと思います。
Data Architecture and Managementデザイナー
正直、いまだにどんな風に勉強すればよかったのかよく分かっていない資格です…(；；)
マスタデータ管理とデータガバナンスの部分がボロボロでした。
紹介されているTrailmixをやると、大量データ周りについてはかなり理解が深まります！
ので、Trailmixはやった方がいいのですが、マスタデータ管理とデータガバナンスの部分はTrailmixだけでは追いつかないような気がします。
Sharing and Visibilityデザイナー
試験内容としては、ケーススタディ的な問題（架空の会社の要件に沿って適切なソリューションを選ぶ形式）のものが大半を占めます。
そのため、他の資格に比べて問題文、答えの選択肢ともに文量が多いです。
試験時間も長く、大体の資格が試験時間90分のところ、この試験だけ120分あります。最後の方はあんまり頭が働きませんでしたｗ
ただ、Trailmixをやっておくと範囲は網羅されていましたし、アクセス権限周りは役割分担がしっかりしていてシンプルだなーと感じました。
私自身はCommunity周りの知識が薄すぎたので、以下の内容を理解＆覚えるのは結構大変でした…
- 各種ライセンス（特にCommunity周り）に与えられている権限
- 共有セットと共有グループ
- Communityを使用している場合のロール
また、Data Architecture and ManagementデザイナーとSalesCloudコンサルタントの勉強で、以下の部分を勉強できていたのはよかったです！
- 大量データ投入時の共有設定のパフォーマンス
- テリトリー管理
- 取引先/商談/ケースチーム
「セーブポイントが見つからない」様の想定問題集は最後の仕上げにとても役立ちました！
savepo.com
おわりに
ということで、受験してみての所感でした。
転職1年でアプリケーションアーキテクト、目標としてはちょっと背伸びするくらいでちょうどよかったかなーと思いました。
一方で、資格取得はできたものの全体的に高得点とは言えない結果となってしまったという反省点もあります。
次からは、「いつまでに」に強くこだわりすぎず、ちゃんと高得点を狙いながらしっかり勉強していきたいと思います。
次の目標はシステムアーキテクトと上級デベロッパー！また新しいゴールを目指して頑張ります！
私のJavaScriptデベロッパー試験まとめ
こんにちは、きゃらめるです。
年明け一発目のブログですが、今日で1月が終わってしまいますね…早いものです。
最近はお家にお迎えしたハムスターに夢中です。この子を見ていると時間が溶ける…
さて今更ですが、今月JavaScriptデベロッパー試験に合格いたしました！
やったー！
JSデベロッパー試験は、昨年秋頃に日本語での受験が開始したばかりのデベロッパー向け試験です。
まだ情報が少ない中での受験でしたが、先人の皆様の情報に助けられたので、
私自身もどんな勉強をしたのか、まとめておこうと思います。
JavaScriptデベロッパーの資格とは
通常の資格試験と同様の多岐選択問題に合わせて、「Lightning Web Components Specialist」のスーパーバッジを取得することで取得できます。
多岐選択問題ではSalesforceの知識は一切問われません。
Salesforce側の知識はスーパーバッジの方で確認＆取得します。
試験問題とスーパーバッジの内容はあまり関係がないので、取得順は正直どちらがいいのか分かりません…。
私は、多岐選択試験→スーパーバッジの順番でしたが、スーパーバッジもなかなかしんどかったので、試験終わってもまだ道のりが…という気持ちになりました。
勉強中、参考にさせていただいた記事など
まだ受験した方が少ない中、すでに受験＆合格しておられた宮本さんの記事は本当に参考になりました！！必読です！
qiita.com
また、いつも通りアンダーソンさんの想定問題集にもお世話になりました！
keneloper.com
もう一点、JavaScriptの勉強用問題集を使いました！こちらで構文等の確認ができます。
github.com
私の勉強方法
（１）試験ガイドを読み、試験範囲と割合を確認
試験範囲の内容から、自分の理解度が何パーセントくらいかを書き出しました。
このチェックは勉強の途中にも行って、分からない部分・分かった部分を明確にしていきました。
（２）JSデベロッパー試験関連の記事を読む
ここらへんで宮本さんの記事に出会いました。躓きポイントを理解しつつ、参考文献にあるトレイルとトレイルミックスを進めることに決めました。
（３）Trailheadを進める
まずは（２）で知ったトレイルミックスを開始しました。
・Salesforce 開発者の JavaScript スキル
・Modern JavaScript Development
ここらへんがJSの基礎部分が分かるので勉強になりました。
特に、「Salesforce 開発者の JavaScript スキル」にある「JavaScriptランタイム」の考え方を覚えておくと、非同期処理が理解しやすいのでおススメです！
（４）JavaScriptガイドを読む
試験ガイドに記載してあるJavaScriptガイドを読みました。
developer.mozilla.org
ここらへんで一番時間をかけた気がします。
JS Binを使って、コードを動かしながら理解を深めました。
JS Bin - Collaborative JavaScript Debugging
（個人的には簡単なScript実行だとCodePenよりJS Bin派です。）
非同期処理も、このガイドで本格的に学びました。（Trailheadも併用。）
そもそも同期処理と非同期処理の考え方とは？というところから、Promiseの書き方、async/awaitの書き方を学びました。
※2021.01.30開催のJapanDreamin' のCodeyセッションで、ぴたデジ株式会社のまたえさんが発表しておられた内容が勉強内容そのままでした！
アーカイブが公開されたら、受験を考えておられる方はぜひ見てみてください！^^
（５）Qiitaや個人ブログを読む
ガイドやTrailheadでも理解ができない部分はQiitaや個人ブログを読んで補完しました。
JSの基礎知識部分なので、Salesforceの技術よりも記事が豊富です！ありがたい！
このタイミングで以下の記事に出会いました。
本当に読んでおいてよかったなと思った記事です。
qiita.com
JSで値が代入される時、参照しているハコの「中身」を変えるのではなく、参照しているハコ「自体」を変えてしまう、
ということだそうです。
正直、試験中もこの参照の考え方をメモに書きながらコードを追っていました。
ぜひとも一読ください！
（６）問題集を解く
アンダーソンさんのブログの問題集や、JSの構文の問題集などを使って知識の確認を行いました。
宮本さんの記事にあったトレイルは、総まとめになっているので、こちらも確認しました。
（３）～（６）については、試験範囲のトピック毎に、それぞれの手段を使って勉強していました。
理解した内容は、ノートやiPadのメモに書き出して、とにかくアウトプットしました。個人的にはこのアウトプットはおススメです！
特に概念理解のときには、絵を書くと分かりやすいです。
JavaScriptに困惑したポイント
私が勉強を始めて、困惑したあたりを残しておきます笑
- 変数や関数の巻き上げについて
varを使うと、変数や関数を巻き上げる（コードの下部で定義した変数名をコード上部で使用する）ことができます。混乱しかないです。
- thisの範囲
アロー関数を使った場合とその他の関数の定義方法を使った場合で、thisの範囲が異なる、というのも一つのポイントです。
今、thisはどこを指しているのか？ということは常に意識して問題を解いていました。
- 型強制
JSは、動的型付けなので、開発者側で型を指定しません。JS側が、よしなに型をつけてくれます。
例えば、console.log(true+1); を実行すると、2が返ります。
これは、Booleanのtrueの後ろに＋があること、その後に数字の1がきていることから、JSがtrueを数字に変換するために起こります。
問題集を解きまくって慣れるようにしましたが、試験の型強制問題を間違えたので何も言えません…。
- ES6以降のJavaScript
JSはES6を境にいろいろ変わっている部分があります。
正直、あまり意識して書けていなかったので、ES6以降の構文周りで知らない書き方も多々出てきました。（分割代入とか特に。）
ここらへんは新しく勉強し直した感じです。
勉強した結果
重たそうなNode.jsの話が一切出てきませんでしたね。
正直、Node.jsの勉強に着手する前に、そのほかのトピックを理解するのでいっぱいいっぱいで、package.jsonとかのあたりだけをさらっと見て試験に臨みました。
全然違うところがでました。
（バージョンのつけ方辺りはちゃんと勉強しておけばよかったです…。）
基本的に、変数・データ型・関数・オブジェクト・非同期処理あたりをしっかりめに勉強した形です。
でも結局ここが配点も高い＆問題の根幹になってくるので、しっかり勉強するのがお勧めです！
結果としては以下のような感じでした。
トピック毎の配分を含めて計算すると74%でした。Node.js…。
正直、試験中に自信があった問題は60問中30問でした…。よく取れた。
さいごに
JSデベロッパーを受験してみて思ったのは、「私は今までなんてふわふわした理解でJSを書いていたのだ…」という後悔というか…恐怖というか…
そういう意味でも、受験できてよかった資格だったかと思います！！
今後受験される方も増えるのではないでしょうか。
どう勉強していいかよく分からない、という方にとって、この体験が参考になれば幸いです！
Salesforceエンジニア初年度を振り返る
こんばんは。きゃらめるです。
2020年の仕事が納まり退勤と相成りましたので、今年の振り返りを兼ねたブログを書いておきたいと思います。
これが今年最後のブログになりますね。皆様良いお年をお迎えください。
今年は世界中、そして日本全国で、状況が目まぐるしく変わった一年でした。
そんなゴタゴタの中、私自身もトピックの多い一年になりました。
ざっくりと月毎に振り返った後、一番大きなトピックである転職に触れつつ、来年やりたいことを書いていきたいと思います。
今年の思い出を振り返る（月毎）
まずは月毎にざっくりと振り返ってみます。
1月
前職での経験史上、最もいい形で進められた(と感じた)ド短期プロジェクトのリリースがありました。
チームメンバー全員の動きが素晴らしくて、このプロジェクトは勉強になることばかりでした。
私自身もそれまでのSalesforceの知識を生かして参画でき、当時の上司とあーだこーだ言いながら賑やかしく技術検証していて、本当に本当に楽しかったです。
このメンバーでチーム賞取りたい！と思っていたらチーム賞をいただきました。わーい！
2, 3月
それまでは社内のエンジニアだったのですが、社外のお客様に対して技術補佐的な形で関わるプロジェクトに参加しました。
いろんな意味で自分の転機になったプロジェクトで、今でも参加できてよかったと思っています。
ただしんどいことも多くて、久しぶりに毎朝憂鬱な状態で会社に行ってました。よく耐えた。
この頃から転職活動的なことを始めていました。現職であるパソナテキーラ時代のサークレイスに出会ったのもこの頃です。
4, 5月
コロナがいよいよヤバいということで3月末くらいからリモートワークになりました。
4月から、チームに新しい後輩君が入ってくれたので、4, 5月は引継ぎ的なことをしていました。
6月
RANGERになりました！あと6月末に退職しました。
大っぴらには書けないいろいろがあって、この会社での私の存在価値って一体なんだったの…？となったりしましたが、一人旅に出かけて復活しました。
最終出社後は、旦那と旅行して、パラグライダーで空を飛んだりしました。最高でした。
7月
サークレイス株式会社に入社しました。最初、Salesforceとあまり関係ないプロジェクトに入ることになり、おおお…？となりました笑
ただ、このプロジェクトで関わった方が皆さんいい人だったので、会社好き度が上がりました。よかった...。
あと、アドミン試験のポイントスタディに出て、自分のSalesforceの知識の点と点が繋がっていく感じが最高でした。感動しました。
あと旦那がM-1に出ることになり、練習に着いていくのが楽しかったです笑
8月
Salesforce絡みの案件に参加しました！正直、めっちゃドキドキしながらソースコードを書いていました…笑
ただ、チームの皆さんもこれまた本当にいい人で、些細なことでも褒めてくださるので嬉しい気持ちでお仕事してました！
自社開発と受託開発の差を感じたのもこの頃でした。（いい部分も、難しい部分も。）
9月
認定アドミン試験に合格しました。前の週にSalesforce Saturdayでアドミン試験の模擬問題の解説をしていただき、コミュニティの温かさに感激しました…；
仕事は、今も参画中の案件が忙しくなり、身体を心配されることがありましたが、私的にはずっとお祭り気分でした。開発ガッツリ触るのも楽しかった！
あと、Woman in Techでパネラーとして参加させていただきました！緊張しましたがいい経験ができました！楽しかった〜！
10月
アプリケーションビルダー試験に合格しました。業務後の勉強と、前月の認定アドミン試験の勉強、前職の経験が生きました。
仕事の案件はまぁまぁ忙しかったのですが、9月よりは少し落ち着きました。
あと、思い立って一人で都内のホテルでワーケーションしていました。これはこれでよかったです！
11月
旦那と二人、博多でワーケーションをしてみました！博多は美味しいものが多かった…。ネットも快適で最高でした。
案件もリリースに向けて少しずつ落ち着いてきました。チームの皆さんと久々に顔を合わせてリリースしたのも楽しかったです〜！！
今年の一大トピック：転職について
一言でいってしまうと、転職は成功だったな〜と今でも心の底から思っています。
前職は、新卒から5年間勤めていた会社なので、よかったこと、救われたこと、辛かったこと、根に持っていること、本当にいろいろあります。
一つ言えるのは、新卒で入った会社が前職の会社だったことについては何も後悔していません。
Salesforceに出会わせてくれたのも前職ですし、仕事の進め方を教えてくれたのも前職です。
何もできないところから、少しは必要とされるまでに成長させてもらえたことに対する恩もあります。
ではなぜ転職を考えたのか？転職のきっかけについても残しておきたいと思います。
上の月毎の振り返りにも書いた、「お客様先でSalesforceの技術補佐をすることになった」時に、経験だけでなく正しい知識が必要だと強く感じました。
それまでの私には経験しかありませんでした。Trailheadを進めていても、点と点が繋がらず、ずっと散らばっているような、根本が分かっていないような感覚でした。
そんなフワフワした知識のままお客様の前に出ることは、知識もないのに「私はSalesforceに詳しいです！」と胸を張っているようで、申し訳ない気持ちと焦りで苦しくなりました。
「体系的な正しい知識を付けて、資格で自分のスキルの証明をした上で、お客様の前に出たい」と思い始めた私と、
「資格は要らないから、経験を活かして今困っているお客様に価値提供して欲しい」という前職の考え方の違いを感じたことが、強く転職を考えるきっかけになりました。
正直、どちらが正解かは分かりません。
今困っているお客様を助けようと思うと、資格勉強からはじめている時間はありませんし、当時の私の経験だけでも力になれることは確かにありました。
でも今、実際に資格を取ってみて考えるのは、「あの時できないって投げたこと、これ使ったらできたんじゃない？」「あの時こんな複雑な方法で解決してたけど、こうしたらよかったんじゃない？」という前職での自分の仕事に対する反省です。
Salesforceは、顧客情報という重要機密な情報を扱うサービスとして、本当によく考えられているなと感じる場面が多々あります。
特に、エンジニアでなくても扱える、という点を実現するために結集された技術は素晴らしいものだと思います。
でもそれを正しく扱うためには、「技術そのものの理解」というより「Salesforceの理解」が必要不可欠なんですよね。
操作は簡単ですが、そもそも扱っている情報がかなり重たいものであることには変わらないので。
ちゃんと理解していないと、やりたいことができないこともあるし、逆にやりたいことをやった結果としてリスクになることもあります。
それを、この一年で強く感じるようになりました。
だからこそ、「Salesforceを正しく使うための知識を得ることに投資をする」「SalesforceのプロとしてSalesforceの案件を受ける」という現職の考え方が私は大好きです。
そして、前職の会社でエンジニアとしてはあまり評価されていなかった中、私と一緒に働きたいと言ってくれる会社があったことは、当時の私にとって何よりも救いになりました。
だから今は、仕事もSalesforceについて学ぶことも、どちらも本当に楽しいです。
ということで、初めての転職は大成功でした！やったー！
来年の目標
まずは前からブログにも書いている目標から…
入社1年以内にアプリケーションアーキテクト を取得すること、です！
私は7月入社なので、7月までになんとか…取得できるように頑張りたいです！！！
もう少し大きな目標もあります。それが、「社内での知名度・信頼度を上げる」という部分です。
入社時からリモートワークだったため、私にどんなスキルセットがあるのか、どんな経験があるのか、という部分のアピールがかなり難しいなーと感じています。
資格取得は分かりやすいですよね。アプリケーションアーキテクトへの挑戦や、1月に受験するJavaScriptデベロッパーへの挑戦は、この目標のためにも必要だと感じています。
社内の信頼度を上げることで、また一段重要度の高い役割で案件を経験させてもらったり、社内のメンバーに何か良い影響を与えられるようになりたいですね！
来年もまた、いい一年だったなーと言えるようにやりきります！来年もどうぞよろしくお願いいたします！m(_ _)m
LWCでデータテーブルを作る場合のコンポーネント分割論（コードあり）
こんにちは、きゃらめるです。
今回はSalesforce Platform アドベントカレンダーの15日目の記事です！
qiita.com
初めてSalesforce Platformのアドベントカレンダーに参加いたします！お邪魔します！
今年は初めてお仕事としてLWCを触ることができ、ブログのネタもLWCに偏っているな…と感じました。
そんなわけで、今回もLWCです。わーい！
今回は、データテーブルをLWCで実装する際にコンポーネントはどんな風に分割しようかな？というお話です。
お仕事でLWCを触った際に後悔していることのひとつが、このデータテーブル的な動きをする要素のコンポーネントの分割方法でした。
実装自体はできているのですが、あまり思っていた形にならなかったな…と感じていて、じゃあどんな風に実装すればよかったのかな？というところを改めて考え直してみました。
ちなみに、データテーブルの要件としてはこんな感じでした。
- データの編集ができる（※テーブル上で編集した内容はApex側で処理して保存する想定）
- 最終行の項目を編集すると、後ろに新しい行が自動的に追加される
- 削除ボタンを押すと、対象行をが削除される
実際の動きとしてはこんな感じです ↓↓
今回のブログでは、
- お仕事で実装した時のコンポーネントの分割について
- 分割方法を変えた方がよかったと感じた理由
- 分割方法を変えて再実装してみた＆所感
の順で書いていきます。
※再実装後のソースコード（上記の画像のようなテーブルのコンポーネント）はGitHub上に公開しています！
github.com
お仕事で実装した時のコンポーネントの分割について
今回作成したページでは、データテーブルはあくまでページの要素の一部分で、他にも様々な情報表示していました。
（Salesforceの標準の詳細ページの一部に、データテーブルが埋め込まれている、みたいなイメージをしていただけるとありがたいです！）
なので、大元のページ（＝詳細ページ的な部分）が1つのLWCになっていて、その中の一部の要素が別のLWCに切り出されたりしながら配置されていました。
その中のデータテーブル部分をどのように分割したのかというと…こんな感じです↓
画像のように、テーブルの各行を1コンポーネントとして分割していました。
もう一つポイントとしては、ヘッダー部分だけは大元のコンポーネント上に記載していて、特にコンポーネントを分けていませんでした。
そして、画面上で変更されたデータ等は、すべて大元のページのLWCに集まる仕組みになっていました。
分割方法を変えた方がよかったと感じた理由
なぜこの部分について公開しているか…理由は大きく二つあります。
- テーブルの中身をコンポーネントとして切り出すと列がキレイに揃わなくなる
- テーブルのデータを子側にオブジェクトとして渡していた場合、子側でデータを変更できない
ひとつずつ説明していきますね。
列がキレイに揃わなくなる
実際の画像がこちらです。
実装としては、tbody内のtr以下を子コンポーネントにした形なのですが…キュッと左に寄ってしまっています。
では、どのように解決したのか。
下記のリンクで、まさに私と同じようなコンポーネント分割をおこなった方が質問投稿しておられたので助かりました；；
salesforce.stackexchange.com
CSSで表示の仕方を指定してあげることで解決しています。
:host {
display: table-row;
}ただ、上記のリンクにこんな回答がありました。
Ideally, you shouldn't use table; lightning-layout and lightning-layout-item work as tables for all practical purposes.
（理想としては、テーブルを使わないでください。lightnin-layoutとlightning-layout-itemが、実用上のテーブルのように動作します。）
こちらの方法は修正に時間かかりそうだったので軽く試してやめてしまったのですが、こういう分割の仕方をする必要があるのであれば、tableは使わないのが得策なのかもしれません。
子側でデータを変更できない
これは、親側から子側に「オブジェクトで」データを渡したときの話です。
通常の文字列や数値を渡している場合、子側でそのデータを書き換えて保持しておくことが可能です。
一方、オブジェクトで渡した場合は、中身の値を書き換えようとすると怒られます。
画面からの入力を受け付けるデータテーブルでは、親側から渡された初期データを表示させると同時に、更新があった場合にはそのデータを保持し、更新後のデータを画面に表示させる必要があります。
そのためには、親から受け取ったデータを、ユーザが更新した内容でそのまま変更できる方が便利なのですが…それができず途中で詰まりました；
そんなときに以下の記事を見つけて、オブジェクトで渡した場合は値を変更できない、という仕様を知りました。
note.com
解決策としては、結局親コンポーネントにすべての情報を集約させる、という形を取りました。
今回の仕様には、データの削除が含まれています。これを今回の行毎のコンポーネント分割で実装しようとすると、以下のようになります。
つまり、更新された内容を親側が認知できていない状態だと、削除を行ったときに古いデータの内容で表示されてしまいます。
「削除時や保存時等、親側で最新のデータが必要になったときに子から貰う」、という手法を考えていましたが、結局子側ではオブジェクトのデータ更新ができないため、親側に集約させておくことで完結させました。
まぁ、これはこれで実装はできましたし、親に集約させておくことで便利な点もありました。
分割方法を変えて再実装してみた＆所感
実装後、上記に書いたような内容を振り返ったとき、「結局、行毎のコンポーネントに分けた意味はあったのだろうか？」という気持ちになりました。
今の私の考えとしては、
のいずれかで、よかったのではないかと思っています。
もちろん、要件によっては何が「よい」なのかは変わってくると思います。
ちなみに、私のお仕事の要件上では「コンポーネント分割しない」は悪手だった（大元のページに機能が多すぎて、ただでさえJSが肥大化している…）と思っていますので、今回は「データテーブル全体を1コンポーネントとして扱っていたら…」ということで再実装をしてみました。
再掲になりますが、実装後のソースコードはこちらで公開しています。
中身は至ってシンプル。datatableとexampleというLWCがあり、exampleはあくまでデータテーブルのデータを渡したり、表示したりするための親コンポーネントとなっています。
本体のdatatableで行っている内容は
- exampleから受け取ったデータ（A）を、表示に適した形式のデータ（B）に整形する
- 画面上でデータが書き換わった際、整形後のデータ（B）を書き換える ※（B）はdatatable内で定義しているため、書き換え可能
- 行追加・削除時も、整形後のデータ（B）に対して行追加・削除を行う
- 画面上の更新を反映しているデータ（B）を、exampleからもらったデータの形式に直すgetterメソッドを用意
といった内容です。
個人的に、保存時に扱いやすいデータ構造と、テーブルでの表示時に扱いやすい構造は違うように感じていたので、example側では保存時に扱いやすい形でデータを保持してdatatable側に渡す→datatable側で表示しやすい形に変えて扱う、という形に落ち着きました。
最後のgetterメソッドは、datatable側でのデータを親のexample側に返す時用にあったら便利かと思って作りました。
これによって、画面上で変更される度にexample側にデータを返す必要がなくなります。
その分、親のexample側で表示データをいじりたいとなるとちょっと厄介かもしれませんが…テーブルの行追加・削除もdatatableコンポーネント内で完結しているので、「親側でデータを変えたいとき」というのは発生しにくいと思っています。
なによりこの分割方法の方が、親が子の実装を知らなくてもいい（決められた形式で値を渡せばいい）、疎結合な関係になっているように感じます。
おわりに
ということで、今年実装したものについて振り返りを兼ねて書いてみました('ω')
実際にこの部分の実装を修正すべきかというと、そこは優先度やリファクタリング工数との兼ね合いだったりするので難しいですが…
ただ、自分の書いたコードについて「こうすればよかったのかも」と思うことはあっても、今まではなかなか振り返れないことが多かったので、こうやってたまに棚卸するのはいいですね。ちょっとすっきりしました。
来年はJavaScriptデベロッパー試験を受験から始まり、アプリケーションアーキテクトに向けた資格に挑戦していきます。頑張るぞ！
また来年もよろしくお願いします！
【GYOMUハックアドベントカレンダー】ステークホルダーとのコミュニケーションを円滑にするには？
こんにちは、きゃらめるです。
こちらは「GYOMUハック/業務ハック Advent Calendar 2020」の5日目の記事です！
今回のブログでは、GYOMUハッカーの皆様が業務で遭遇する「ステークホルダーへの説明やヒアリングが必要な状況」において、円滑に進めるための準備をまとめていけたらと思います。
今回の記事では、以下の3つのプロセスについて、どのように検討していけばいいかをまとめてみました！
- 相手を決める
- 順番を決める
- シナリオを決める
私は前職で社内Salesforceの担当者をしていました。そのためSalesforceに修正を加えることが多々あったのですが、Salesforceを使っている部署は社内全体に存在するため、修正によって複数の部署に影響が出てしまうことがあります。
特に修正内容が大きければ大きいほど、ステークホルダーに対して丁寧に説明やヒアリングをしていく必要が出てきます。
前職で最後に携わったプロジェクトでは、変更内容も影響範囲も大きかったのですが、チーム全体でこの部分に力を注いだことで、なんとか成功で終えることができました。
GYOMUハックは、社内の方に協力してもらって、運用に乗ってこそ力を発揮します。だからこそ、ステークホルダーと直接話ができる場で信頼値を上げておくことが大事です。この信頼値とは、「自分たちのことを気にかけてもらえている」という安心感とも言えます。
業務改善をするとき、「現状を変えてくれないこと」の不満よりも、「現状上手くいっていたもの勝手に変えられたこと」の不満の方が反発されやすい上に、信頼を失います。
正しい相手に・正しい順番で・正しいメッセージを伝えることで信頼値を上げれば、円滑に改善を進められると思っています。
相手を決める
まずは、そもそも誰がステークホルダーなのかを洗い出すことから始めるかと思います。
必要な相手に修正が伝わっておらず、業務に支障が出るようなことがあれば、リリース内容を戻すことになってしまう可能性があります。
それだけではなく、相手に不快な思いや心配を与えてしまうため、関係が悪くなる危険性もあります。
特に大きいプロジェクトであればあるほど、慎重に行きたい部分だなと思います。
普段の会話に着目しておく
普段から、社内の様々な業務に携わって話を聞いておくと、修正をした時にどこに影響があるのかがなんとなく分かってきます。
直近の業務に関係なくても、多くの部署とやり取りをして、どんな業務をしているのかを耳に入れておくだけでも、影響範囲を洗い出すときの取っ掛かりになります。
既知の影響部署の人を頼る
とはいえ、すべての部署のすべての業務を把握するのは無理な話だと思っています。
そんなときは、既に影響の範囲内だと分かっている部署や人を頼るのがひとつの手です。
影響範囲の部署・人に、「ほかにこの機能を使っている部署や人を知っていますか？」もしくは「この機能を修正されて、影響が出る部署や人を知っていますか？」というような質問をすることで教えてもらえることがあります。
もし、依頼部署が存在する場合はラッキーで、その部署から他に影響のある部署を洗い出せる可能性があります。
依頼部署は改修によって恩恵を受ける部署でもあるので、影響範囲を洗い出すことの重要性を説明するこでで、協力的に動いてもらえる可能性が高いです。
なんなら、影響範囲の洗い出し～リリース後の説明についても巻き取ってくださる部署もありました。聞いてみて損はないはずです。
マネージャー層を頼る
一度マネージャー層に状況を伝え、自分の部下に修正箇所を使っているかを聞いてみてもらいます。
ここでの注意点は、マネージャーの方に動いてもらうため、小さな改修であれば割に合わない可能性があるということです。
全体に聞いてみる
最終手段です。全体への確認は、経験上あまり聞いてもらえないことが多いです…。ただ、一度全体に聞いておくことで「確認した」という証拠は残すことができるので、少しだけ自分の身を守ることができます笑
ここで忘れてはいけないと思うのは、こちらが想定していないようなイレギュラーな使い方をしている人の存在です。
想定していない方法で運用が回ってしまっている場合もあり、思ってもいないところから問い合わせがくることがあります；
重要なリリースであればあるほど、できる限り広い範囲に変更を伝えておく必要があるかと思います。
順番を決める
誰に伝えるべきかが決まったら、伝える順番を決めます。言ってしまえば、誰に先に話を通しておけば円滑に話が進むのか？を考えます。
誰を部署の代表とするべきか？
部署単位で何かを伝達する時には、その部署の実質的に一番影響力の高い人を対象にします。これは部署の組織図上のトップでなくてもいいということです。組織図上のトップからの信頼もあり、部下を引っ張ることができる中間層の方には、先に話をつけておいて味方になってもらう方がよかったりします。。
一方でヒアリングの場合は、実際に作業している人に話を聞くことになるかと思います。ただし、後からヒアリングの内容を元にほかの人を説得するため、組織的に説得力のある人を選ぶ or 同席させて一緒に意見を聞くとスムーズかと思います。
部署を跨いだ場合の伝達順番
ヒアリングではなく、説得や説明が必要な場合には、ぜひ伝える順番を考えてみてください。
私はこの順番を考える時、以下の二つに分けて考えています。
- 自分から伝えるべき人か
- 自分の味方になってくれる人（修正によってプラスの影響を受ける人）
- 面倒見がよく、決定権がある人（↑と合わさればなおよし）
- 上層部の決定後に伝えるべき人か
- 反対・難色・不安点があるというマイナスの感情を抱く可能性がある人
- 決定権・決定力がない人
上層部の決定後に伝えるべき人の中でも、なるべく早くに伝えるべき人がいます。それが、修正に一番反対しそうな人です。
反対意見を聞かずに味方ばかりつけても、どこかの部署に大きく反対された場合には後戻りする必要が出てくることがあります。
「会社の上層部が賛成している」という虎の威を借りつつも、なにが反対要因なのかをなるべく早めに洗い出して不安を潰しておく必要があります。
理想の形としては、
１．組織的に説得力があり、一緒に推進してくれる人を味方につける
２．１．の賛成を得られていることを伝えつつ、反対しそうな人の話を聞く＆説得する
３．ほかの人からの同意も得つつ、トップダウンで周知する
組織の性質にも依るかもしれませんが、正規のレポートラインを通る方が遠回りになることもあるので、何か変化を起こしたい時には一度伝える順序も考えてみてください！
※ちなみに、この順番の意識は、プロジェクトのような大きなものでなくても便利に使えます。自分の直属の上司より先に、別の人に話を伝えて了承を得てからの方が、説得力が増して、余計な諍いをなくすこともあります。
シナリオを考える
最後に、どんな伝え方で話をすべきかについてです。
事前ヒアリング
事前ヒアリングをする目標・目的は、現在の運用や業務フローを知ることで「改善に生かすため」「懸念点を最初に洗い出しておくため」という理由があります。
ここで大事なのは、「私たちは味方である」というメッセージをしっかり伝えることです。
事前ヒアリングをする相手が、修正で不利益が発生する場合には、
- なぜこの修正を行う必要があるのか（修正のメリット）
- なるべく不利益を与えないようにしたいので、改善案を考えたい
という視点で話をします。
修正で不利益が発生しない場合は、
- 修正のメリット
- 私たちが知らない運用があると予定外の不利益が発生する可能性があるので、現状の運用を教えて欲しい
という視点で話をすると、後からの問題発生も少なくなります。
意見を通したい場合
決まったことを伝達したい場合など、ヒアリングというよりはこちらの意見に同意してもらうことを目的とする場合は、相手の不安を減らしつつ、自分の身も守ります。
具体的には、通したい内容のメリットを全面的に伝えつつ、やることとやらないことを明確にします。
特に、アフターケアの部分や想定外の不具合があった場合の修正についても触れておくと相手の不安は少し軽減されます。
ただこの時に、すべての不具合を修正することはできない可能性があることを伝え、同意してもらった方がいいと思います。
おわりに
今年の私の一大トピックが転職でした。1年の締めくくりとなるアドベントカレンダーで、前職の振り返りとしてこの記事を残せてよかったです。
アドベントカレンダーへのお誘いありがとうございました！！！
現職での私は、業務改善という動きは全くとれていません。。来年は現職でもアドベントカレンダーのネタになるような業務改善ができたらいいなぁ…。
来年も頑張ります！
Platformデベロッパーの勉強をして意外だったこと3選
こんばんは、きゃらめるです。
滑り込み11月記事2本目です！笑
今日は、1記事にするほどの量はないけど残しておきたい、Platfomデベロッパーの試験で意外だったことを、3つまとめてみました。
ガバナ制限の制限値
多分、デベロッパー試験の中でちゃんと理解できていないとマズそうな部分第一位かもしれないですよね。。
そんな大事なところですが、試験勉強をするまでSOQLとDMLで別々に制限されていることを知りませんでした。
ガバナ制限としては以下のような制限があります。
| # | 制限内容 | 制限値 | Limitsクラスの使用数確認メソッド |
|---|---|---|---|
| 1 | SOQLクエリの実行回数 | 100 | getQueries() |
| 2 | SOQLクエリで取得できたレコードの総数 | 50,000 | getQueryRows() |
| 3 | DMLステートメントの実行回数 | 150 | getDMLStatements() |
| 4 | DMLステートメントで処理されたレコードの総数 | 10,000 | getDMLRows() |
※1トランザクションあたりの件数
このうちの、1と3の回数を合わせて100回を超えてはいけない、2と4を合わせて50,000件を超えてはいけない、だと思い込んでいました；
そもそも、SalesforceはDB操作を、レコードのデータに「影響を及ぼさないもの」「影響を及ぼすもの」に分けていて、前者がSOQLクエリ、後者がDMLなんですね。
SOQLの返り値
SOQLの返り値の型って5種類もあるんですね！
| # | 型 | 備考 |
|---|---|---|
| 1 | sObject[] | 一般的なやつ。0件の時は空になる（nullではない）。 |
| 2 | sObject | レコード件数が1件の時に使用可。0件でも複数件でもエラーになる。 |
| 3 | Integer | SELECTされる項目リストが「COUNT()のみ」の場合に使用する。 |
| 4 | AggregateResult[] | 集計関数を使用している場合はこれを使う。 |
| 5 | AggregateResult | SELECTされる項目リストが「COUNT(項目名)」の場合は、3ではなくこちらを使う。 |
2,3,5が驚きでした…。
特に3,5については、COUNTに引数を渡すか渡さないかで使える返り値が変わるのがややこしいですね；
AggregateResultであれば、COUNT()もCOUNT(項目名)の場合も受け取れるのかと思っていたのですが、そうではないようです。
COUNT()をAggregateResultで受け取ろうとすると普通にエラーになります。注意です。
リリース時のテストカバー率
単体テストコードでのカバー率が75%以上でなければリリースできないという知識はありましたが、ここでも思い違いがありました。
リリースに必要なカバー率は「コードの全量」に対するカバー率であり、「1つのApexクラス」に対してのカバー率は追っていない、というところです。
私は今まで、1つでもテストカバー率75%未満のApexクラスがあればリリースできない、と思っていました。
実際そんなことはなく、クラスAとクラスBとクラスCがあれば、クラスAがカバー率75%を下回っていたとしても、A, B, C合わせて75%あれば問題なかったのです。
テスト問題で上記を問われていたら、危うく落としてました；
おわりに
今回の記事で伝えたかったことがあります。それは、資格勉強もやっぱり大事、ということです。
私は前職で3年間、Salesforceの開発担当として手を動かしてきたわけですが、上記を知らなくても開発はできていました。
それは、ほとんどが安全な方に倒れる形で勘違いをしていたからです。
例えば、全てのApexコードのカバー率を75%以上にしても、テストのカバー率が高くて悪いことはないので、特に今まで問題になったことがなかったのです。
ただ、勘違いで無駄な制約を増やした分、時間を使ってしまっているのは確かです。その分、他に時間を割いた方がいいことだってあったはずです。
ガバナ制限に必要以上に怯えて、なんとかSOQLやDMLの発行を抑えられないかと躍起になって、当時のマネージャーに「そんな複雑に悩まなくても…」と言われたこともありました。
また、SOQLのCOUNT()の件は普通に使ったことがなかったのですが、結構ハマりポイントなのではないかと思っています。
これは他の資格の勉強をしている時にも感じたことなのですが、勉強を進めるほど「あの時のあの問題、これで解決できたのでは？」「あの部分の設定、今の私の知識ならもう少しいい感じにできた or もっと早く解決できた」と思うことがたくさん出てくるんです。
苦労した・時間がかかっただけならまだいいんです。自分の知識にはなっているはずなので。
ただ、実装を諦めた部分が少なからずある、というところが問題です。解決できた課題を解決できていないので。
私の前職はユーザ企業だったので、Salesforceの資格試験を受けることに意味を感じてはもらえませんでした。
そういう企業さん、たくさんあると思いますし、そんな中で働いていらっしゃる方もたくさんおられると思います。
会社から補助が出ない、情報も入ってこない中、試験の有料講座や試験を自腹で受けるのはかなり怖いです。情けないですが、私は無理でした。
今、Salesforce主催の無償ウェビナーで、各資格のポイントスタディのコースを実施しておられますね。
www.salesforce.com
現職に入社早々、認定アドミンのウェビナーも受けましたが、業務でなんとか学び取ってきたことがどんどん繋がるように理解できて、もう感動を覚えたくらいです笑
今回のデベロッパー資格も、無償ウェビナーで学ばせていただきました。体系的に学べる、という点が本当に分かりやすいです。
前職時代の私のような担当者の方には、是非ともこちらに出てみて欲しいです！！
ということで、資格勉強するのはいいぞ！という話でした！
来月はアドベントカレンダーに参加しますので、そちらの更新がメインになると思います！頑張ります！
Salesforceを知ってる人に向けて、クラスとオブジェクト指向を言語化する
こんばんは、きゃらめるです。
今日はApexに限らない、一般的なプログラミングの話をしたいと思います。
タイトルの通り、「クラス」とはなんぞや、「オブジェクト指向」はなぜ使うんやという話をします。
今回の内容は、私が社会人1年目の頃にあやふやな理解をしていた部分でもあります。
この部分をイメージに落とし込むことができたことで、やっと思い通りに使えるようになりました。
イメージに落とし込むには、経験ももちろん大事でしたが、いろんな説明を聞くのもとても役立ちました。
1つの説明を聞いただけではわからなくても、いろんな人の説明を聞いていくと、少しずつ蓄積された知識やイメージのお陰で理解が進んだり、どれか一つの説明が絶妙に理解に刺さったり、ということが多々ありました。
今回の記事でも、なるべくイメージを伝えられるように言語化してみようと思いますが、ぜひ私の説明だけではなく、いろんな説明を読んでみて欲しいです。
クラスの概念
ApexにはApexクラスがありますね。では、クラスってなんなんでしょう？どういう単位なんでしょう？
クラスを大まかな私の理解で表すと、
「一つの概念について、「情報・要素」と「できること」をまとめたもの」
です。
これをインスタンス化すること（= new MyClass()で呼び出すこと）で「実体」となります。
正直、昔の私はこれだけ聞いてもよく分かりませんでした。でも実は、クラスの考え方は実世界にある様々なものにあてはめられます。
実世界とクラスの考えを結びつける
例を挙げます。私も、今このブログを読んでいるあなたも、実在しています。つまり、私たちは「実体」です。
（a）私たちは名前を持っています。
（b）私たちは年齢を持っています。
（c）私たちは生物学上の雌雄を持っています。
（Ⅰ）私たちは食べることができます。
（Ⅱ）私たちは寝ることができます。
（a）～（c）は私たちが持つ「情報・要素」です。（Ⅰ）（Ⅱ）は私たちが「できること」です。
これらは私たちだけでなく、人間全体に共通することですよね。
この（a）～（c）と（Ⅰ）（Ⅱ）をまとめたものが、人間という「概念」です。
※実際の人間が持つ「情報・要素」や「できること」はもっと多いですが、簡略化しています。
クラスは、この人間という概念を記述しておくものです。それを、私たち「実体」として扱うためにインスタンス化を行います。
インスタンス化することで、実体ごとに異なる指示を出したり、情報を変更・閲覧することが可能です。
実体ごとに異なるとはどういうことか、こちらも例を挙げます。
人間は誕生日を迎えると年齢が1つ上がりますよね。では、私が誕生日を迎えたとき、あなたの年齢は上がるでしょうか？
誕生日が一緒でない限り、実世界でそんなことはありえませんよね。
なぜなら、私とあなたは、別の実体として独立しているからです。
この、独立している1つの実体を表しているのが1つのインスタンスです。
なので、「インスタンス化する」ということは、私やあなたのように別の人間を生み出す行為にあたります。
もう一つ追記しておくと、クラスの変数が「情報・要素」にあたり、クラスのメソッドが「できること」にあたります。
Salesforceとクラスの考えを結びつける
Salesforeのオブジェクト自体もこの考え方とつながってくると思いませんか？コードで例を挙げます。
Account acc1 = new Account(Name = '取引先1'); // <- 「取引先1」という名前を持つ取引先の実体(acc1)を作成 Account acc2 = new Account(Name = '取引先2'); // <- 「取引先2」という名前を持つ取引先の実体(acc2)を作成 acc1.Phone = '000-1111-2222'; acc2.Phone = '111-2222-3333';
この時、acc1の電話番号は 000-1111-2222 ですし、acc2の電話番号は 111-2222-3333 になります。独立しています。
Account自体がクラス、電話番号や名前などの項目はクラスの変数です。
このように、Apex内ではSalesforceのオブジェクトもクラスとして扱っていると思うと、Salesforceを触っている人はかなりイメージしやすいのではないでしょうか？
オブジェクト指向を使う理由
オブジェクト指向という言葉もよく聞きますよね。これってなんなんでしょう？
上記で説明したクラスがまさに「オブジェクト」です。
オブジェクトを作成する（インスタンス化する）、オブジェクトを操作する（メソッドを呼び出したり、変数を更新する）ことで、プログラムを組み立てていくのがオブジェクト指向の考え方です。
Apexクラスを実装するとき、newでインスタンス化をし、「インスタンス名.メソッド名()」でメソッドを呼び出したりしているかと思います。
それこそ、オブジェクト指向のプログラミングです。
では、こんな風に組み立てる目的はなんなのでしょう？
もっと言えば、なんでわざわざクラスに分ける必要があるのでしょうか？上から下に順番に処理を記載するだけじゃダメなのでしょうか？
個人的に、オブジェクト指向を使う最大の目的は「変更時の修正コストを下げるため」です。なんなら、設計思想全体がこの目的のためと言っても過言ではないと思っています。
なので、一回きりしか実行しない小規模なソースコードに対してまで、バッチリ設計を考えて実装するのは無駄だとすら思っています。
ただし、一回きりしか実行しないコードでも、規模が大きければ設計をちゃんとした方が実装しやすいというメリットもあるかと思います。なぜなら、規模が大きいものは実装中にほかの箇所を「変更する」可能性が高いからです。
そう考えると、編集されないソースコードというものは多くないはずです。
オブジェクト指向で、なぜ修正コストが下がるのか？
実際に、ソースコードを編集する時をイメージして、どんなソースコードであれば修正に時間がかかるかを考えてみてください。
修正するときは、まず修正する箇所を探すことになります。
例えば、処理が10,000行書いてあるソースコードがあったとして、それがすべて1つのメソッドに記載してあった場合はどうでしょうか？
そのメソッドを上から順に辿っていくことになりませんか？想像しただけでとてもツラいです。。自分が書いたコードでもツラいですが、人のコードであればなおさらです。
これがキレイにクラスに分かれているとどうでしょう？
上で記載した通り、クラスは概念を表現したものなので、同じ概念のものだけが同じクラスにまとまって存在しているのが正しい状態です。
この正しい状態を保っているのであれば、修正箇所に当たりをつけることができます。
Salesforceでも取引先オブジェクトの項目の設定を変えたい時に、商談オブジェクトを見に行きませんよね。
また、修正箇所が1つとは限りません。修正の影響範囲を見誤ると、一部は正しく修正できたけど一部は古い状態が残ってしまうというバグになりかねません。
public class Human { public String firstName; public String lastName; public Human(String lastName, String firstName) { this.firstName = firstName; this.lastName = lastName; } } // どこかのメソッド Human human1 = new Human('姓1', '名1'); System.debug(human1.firstName + ' ' + human1.lastName); // フルネームを表示 // また別のどこかのメソッド Human human2 = new Human('姓2', '名2'); System.debug(human2.firstName + ' ' + human2.lastName); // フルネームを表示
上記は単純なクラスとその使用箇所の例です。Humanクラスには姓（lastName）と名（firstName）があり、メソッドではそれらを結合させたフルネームをデバッグに表示しています。
では、このHumanクラスにミドルネームを追加して、フルネームは「姓＋ミドルネーム＋名」を使用するように変更したいという依頼があったとします。
上記の例であれば、変更は二箇所だけなので簡単！と思うかもしれませんが…
もしこのシステムが大規模なシステムの場合、すべての「フルネームを表示している部分」を見つけ出せるでしょうか？ちょっと不安ですよね。
ではどうしたらよかったのでしょうか？
フルネームを使いたくなった時点で、フルネームの変数もしくは表示用のgetterをHumanクラスに実装しておけばよかったはずです。
public class Human { public String firstName; public String lastName; public String fullName; // fullName変数を用意した場合 public Human(String lastName, String firstName) { this.firstName = firstName; this.lastName = lastName; this.fullName = this.firstName + ' ' + this.lastName; // ★変更箇所 } } // どこかのメソッド Human human1 = new Human('姓1', '名1'); System.debug(human1.fullName); // また別のどこかのメソッド Human human2 = new Human('姓2', '名2'); System.debug(human2.fullName);
これでフルネームの定義が変わっても、「★変更箇所」を変更するだけでよくなりました。
これはつまり、Humanクラスを呼び出しているメソッド側で、フルネームがどのようなロジックなのかを知っている必要がなくなったということです。
最初の例だと、呼び出すメソッド側にフルネームを求めるロジックが記載されていたため、メソッド側がフルネームのロジックを知ってしまっていました。
一方、訂正後の例では、Humanクラス側にフルネームを求めるロジックが記載されているため、呼び出し先のメソッド側ではフルネームのロジックを知らなくても、フルネームを使うことができるようになりました。
実世界でも、ある情報を知っている人が多ければ多いほど、その情報を訂正して回るのは大変です。それと同じで、ロジックを知っている部分が多いほど、修正は大変になります。
だからこそ、クラスの変数やメソッドを利用する側が詳細なロジックを知らなくてもいい状態を作るのがとても大切です。
このような考え方が「関心の分離」です。
そしてこの”関心が分離された状態”こそ、オブジェクト指向で実現したい状態であると思っています。
おまけ：「静的」の考え方
ここまでで、次の抽象クラス・インターフェースの違いの説明はできるのですが、せっかくクラスのインスタンス化などをイメージしたので、「静的」な変数やメソッドについてもイメージを言語化しておきます。
ここまで、クラスの説明で使った人間クラスには「人間」の概念に関する情報が詰め込まれています。
今まで説明した変数やメソッドは、独立した実体がそれぞれに持っている情報や、それぞれが実行できる処理の話でした。
では、人間全体に関する情報…例えば、人間クラスで作成された実体の数（＝人口）はどこで管理するのでしょうか？
これも「人間」の概念の一つなので、人間クラスで管理したいはずです。
しかし今まで通りの変数で定義してしまうと、インスタンス毎に人口が定義されてしまうので総数が分かりません。
このようにインスタンスに対する情報ではなく、クラス全体に関する情報を管理するのが静的（static）変数です。
インスタンスから、静的変数は呼び出せません。同じように、静的メソッドもインスタンスからは呼び出せません。
静的変数や静的メソッドは、インスタンスに紐づくものではないからです。
おわりに
長くなりましたが、私の理解をざっくりと書き出してみました。
なぜこの記事を書こうと思ったかについて少し触れますと、来月受験するPlatformデベロッパー試験の勉強を行っていたのがきっかけでした。
そこで抽象クラスとインターフェースの違いについて学び直したので言語化してみようと思ったのですが、記事を書いているうちにここは先にイメージを共有しておいた方が伝わりやすいのかなーと思う部分があったので、前準備としてこの記事を切り出してみました。
なので、本題のブログについても近いうちに更新したいと思います！
はじめにも書きましたが、ぜひこのブログを読んだあとで、いろんな方のいろんな説明にも触れてみてください！昔読んで、理解できなかった説明を読み直すのもいいと思います。
理解が進むきっかけになると幸いです！
またギリギリの月二回更新になってますね…
明日は、デベロッパー試験勉強で新しく学んだことを、何か一つまとめられたらと思います！