ファンタラクティブのグレード制度を刷新しました
まえがき
こんにちは、ファンタラクティブ VP of Engineering の久松（hisasann）です。
数社で開発組織を牽引するようになって10年を超えてきて、評価をされる側、または評価をする側も長いことやってきました。
そしてファンタラクティブで働くようになって、今この40人ぐらいの組織がどうなっていくと良いのか、人が増えていった時、どうなっていると働きやすいのか、もっというとどうなっていると良い組織だなと思っていただけるのか、というのを日々考えておりました。
そしてなんとなくここ1年間ほどグレード・評価・目標設定について熟考しておりました。
これらについてはずっと課題としても捉えていて、正解が個人的に全く腹落ちしていなかったので、ここでしっかり考えるのもありだなと考えたのです。
現状のファンタラクティブのグレード制は人数が少ない時代に作られたものなので、採用も含めると刷新する必要があるのではという考えになり、そもそも「刷新するとは？」というところから始めました。
その記録と結果的にどうなったのか、というのをまとめてみようと思います。
悩んだ部分もメモとして記載しておりますので、経過が不要な方は一番下までスクロールしてください。
不確実性の高いジャンルでもあるので、この辺りで悩まれている方の知見になればとても嬉しいです。
結果的にどうなったか
一応、結論だけ読みたい方向けに結果的にどうなったかを書いておきます。
新しいグレード制
旧グレード制とグレードの階層個数は同じにし、わかりやすい状態をキープし、各グレードの定義は書かず、向けるべきベクトルの方向だけを記載しました
目標設定
会社として必須な「目標設定はしない」ということで決まりました
つまり今までと変化なし
評価
一次評価し、キャリブレーション後に伝えるをイキとしました
つまり今までと変化なし
どうしてそうなったのか？は以下の文章に記載しております。
どう調べていったか
基本的にはインターネットに公開されている会社様のスライドなどを参考に、 GitLab 社の本や公開されている handbook などをベースに、今のファンタラクティブではどうなっていると良いのか、というのを考えて、 notion にまとめていきました。
途中経過も大切な情報なので、会社内で公開し、過程も見てもらって私が何に悩んでいるのかも見てもらっていました。
あとはとても貴重なデータとなったのはユーザーインタビューです。社外のテックリードやプロダクトマネージャー、エンジニアリングマネージャー、カスタマーサポート、デザイナー、デザインマネージャーなどたくさんの方達にインタビューさせていただいきました。10数人ほどです。
リアルな生の声を参考にさせていただいて、皆さんが実際どう思っているのかというのを反映させていただきました。
また、私の過去の経験則、つまり N=1 はなるべく入れないようにしました。悪い体験としてあったことは少し加味しましたが、バイアスが発生してしまうため、ニュートラルな気持ちであり続けることに努めました。
グレード制がなぜ必要になりそうなのか？
今後、採用に力を入れていくことで、もっと人が増えていきます。そしてファンタラクティブとしても人を増やす想定です。
オファー面談時にも、なぜあなたの給与がこれぐらいなのかの説明責任含め、今は少し粗めなグレード制の状態なので、あまりうまく説明できていないという問題がありました。
さらには、自分が昇給するにはどんなスキルや経験を身につける必要があるのか、このあたりが透明になっていない、そしてあまり定義もされていませんでした。
なので、いよいよ必要になってきているという感じになります。
ファンタラクティブとしての良さを再定義
グレード制を考えていく前に、まずはファンタラクティブの良さってなんだっけ？というところを見つめ直しました。
結果、こういう作業のおかげで、方向性を見失わなかった気がしています。
組織面
フルリモートワークで働ける
日本全国、さらには海外に社員がいる
海外移住できる、ワーキングホリデー制度を活用できる
フルリモートワークをどうやったらもっと高いレベルでできるかの模索をし続けている
週3勤務など働く日数を選べる
正社員 ↔ 業務委託のように雇用形態の変更ができる
ライフイベントなどで週5フルタイムが厳しい場合に週4に変更などフレキシブルである
カルチャーを大切にしてる
カルチャーワークショップを行うことで、定期的に共通認識を作っている
カルチャー施策は多いが、これのおかげでリモートワークだが、人が身近に感じる
目標をただトラッキングするだけじゃない寄り添う 1on1 がある
そもそも社長が 1on1 を大切にしている
「ひとに向き合う」という共通ワードを普段から社長含め、経営陣、マネージャーが使っている
仲間感がある
Gather などのツールをうまく利用して孤独じゃない感を出している
「Slack は会社である」という認識のもと、テキストコミュニケーションも大事にしている
実況スレッドの文化
times の文化
https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud
副業 OK
ワクワクドキドキすることをとても大事にしてる
事業面
体験設計を軸に事業と組織を作っている
『ファンタラクティブは「体験設計」が事業ドメインの会社です。』
色んな会社に事業ドメインがあるがファンタラクティブにおいてはそれが体験設計
DXパートナー事業部が近距離戦、EXTO（新規事業）が遠距離戦
組織づくり（EX：Employee Experience）
「ユーザーの声をすべての企業に届ける」がパーパス
体験設計とは？
UX はユーザー体験、これは体験設計とは違う
サービス全体の体験のこと
要件定義、設計、開発、テストまで全てに関われる
戦略設計からデリバリーまで
もちろん案件によっては、その限りではない場合がある
先輩や同僚のデータを見たりレビューを受けることができる
モブワークを大事にしているので、壁打ちやフィードバックをすぐにもらえる
さらに、それを嫌がらない文化がある
恐れたこと
このような情報をもとに、これらの良さを壊さないというのも大事な要素と考えました。
何かを刷新するときに怖いのが、「刷新しない方が良かった」ということです。
空中戦施策とも言われますが、人事などが良かれと思って導入して、人事の実績や成果にはなったが、マネージャーの運用が肥大化したり、メンバーもなんでこれをやっているのか分からないなど、結果として誰も喜ばない施策はとても多いです。
人は Value を出したくなる生き物だと思っているので、例えばですが転職してすぐは転職後バイアスと呼んでいる、なんとか Value を出そうと努力をして、何か施策を Add してしまうと。ただ実際には誰も Add されることは望んでいなくて、本当はやりたくないと思っている施策を辞めるという選択の方がいい成果だったりもするものです。
施策の引き算の方を選択してみたが、上司から怒られたなどの経験を体験してしまうと、そこからは引き算は怖くなってしまいます。
というのがあるので、「いらんことをしていないかどうか」 a.k.a 「むやみに Value を出そうとしていないか」を常に肝に銘じました。
グレード制を入れることでやらないといけなくなること
グレード制というものをやることで、すでにやっていることと、増える可能性のものを考えてみました。
そもそもどんなことが増える可能性があるのか、ここは純粋にコストになってくるのでとても重要です。
評価
誰が評価するのか
いつ評価するのか、期末なのかどうか
目標設定
目標管理シートが必要になるだろう
やるのは期初なのかどうか
目標が期中で変わった場合のフローはどうなるのか
その時の手間はどれぐらいか、手間がかかると『本来やらないといけない何か』が発生したとしても、面倒なのでそっちはやらず元々の目標をやってしまう場合がある
マネージャーの承認がいるのだろうか
目標から行動がずれていないかのトラッキング 1on1
評価者との 1on1 は、今までのような気軽に壁打ちできる 1on1 から変化してしまう可能性があるので、評価者は社長だけなど、そういった配慮も必要になってくるのではないか
1on1 が嫌な時間になってしまう可能性があるのは、1on1 を大事にしている会社でそれはどうなのか
グレード表の定義
そこに書かれていることしかやらない人が出てきたらどうするか（評価ハック）
書かれているのだから、それだけやるでも良いのではないか問題
私の過去の経験もありますが、グレード制や目標設定、それに基づく評価が入ることでやることはたくさん増えます。
ファンタラクティブは上期下期ですが、四半期の会社の場合は、年に4回も目標設定と評価をすることになります。そういった場合のバランスも難易度が高いですが、年に2回でもやりようによっては、従業員に苦労を掛けてしまうことは簡単です。
この辺りのやらないといけないことも考慮が必要です。
今後のファンタラクティブの評価について
以下が当時考えていたメモです。
私は GitLab 社にぞっこんなので、かなり引っ張られていますが、それでも一理あるなと思っていました。
結果的にどう評価しているかは、下の方に記載します。
時期は期末にするが一般的だろう。そして妥当だろう。
GitLab 社のが最高にわかりやすい。
ポジションで果たすべき責任やKPI指標、専門性の発報などの「成果」の要素をパフォーマンス評価の60%として評価し、次にGitLab Valueやリモートワーク能力などのコンピテンジー環素を取り40%として計算しています
つまり2軸である。
パフォーマンス評価
成長力評価
刷新前のファンタラクティブのグレード制
現状、なんとなくこれでも全然良さそうな気もします。
ただ、それぞれのグレードがどういったものなのか、それと運用方法含め、そこが固まっていなかったので、再定義しようという流れになりました。
とはいえ、それでも全然悪くはありません。
LP というグレードの説明を貼っておきます。こういうのを読んでみても、すごく良いグレードだなと感じます。良い言語化です。
（ボツ案）クラス+アビリティ制度はどうか
代表井村の「評価制度原案」という資料を見ながら考察しました。
以下が原文ママです。
600万以上の年収帯を定義したい
給料が上がる理由、上がらない理由を明確にしたい
プレイヤーより上を目指す力学を作りたい
現状維持はゆるやかに落ちていくシビアな設計も必要かもしれない
40代〜50代をどう扱うか
40代〜50代ならではの価値を定義する
ファンタで長く活躍してもらうための本人の変化を自然に促す
最悪ファンタを離れても活躍できるキャリア作り
UX戦略 / プロダクトマネジメント / 組織戦略 の3本を提供できる会社になる
本当の意味でクライアントのビジネス成功に伴走する
どれが欠けてもダメ
これらを考慮して自分にアビリティ的なのをアタッチするのはどうか、という案を出しました。
クラス（肩書き）とアビリティ（能力）を掛け合わせて、何がどの程度できるかを明確化し、それを自分のグレードとする制度。という感じです。
これは、GitLab 社の2軸評価に似ているので、良いのではないか、相性が良いのではないかと思いました。
例：
クラス
フロントエンドエンジニア
アビリティ（level 1〜5）
Figma level 1
デザインシステム level 2
Next.js level 3
これを「Funteractive Ability（ファンタビリティ）」という名前にして、掘り下げて行ってみました。
+αとしてアタッチできるパークを自分につけることで、より事業貢献をしてもらう。そして、それによって評価も上がる可能性がある。
勝手にアタッチではなく、用意したものをアタッチする。もし希望があれば、提示していただいて、承諾が出たらアタッチが可能となる。
構想してた時の図、このようにゲーム感覚で自分のスキルを伸ばしていけるのかどうかが鍵になっていました。
デメリットとしては、アビリティがたくさんあると、その時の評価軸がよくわからなくなることです。
level 1 のものが100個付いていた場合、それはいいのかそうでもないのかの判断がつきにくいこともあります。
つまりややこしいのです。
評価者にとって嬉しい制度でもなく、評価される側もこれらをいつ更新するのか、また level はどう判断するのかが不透明なので、そこもややこしいという印象がありました。
大事なのは「持続可能であること、ワクワクすること」そこが担保できない可能性がありました。
これらは実際に社内のメンバーにインタビューをしつつ、ロールプレイをしてみて、結果的にボツにしました。
ちなみにデットバイデイライトのパークというシステムは素晴らしいです。どんなパークをアタッチすると次回のプレイで面白くなるか、それを考えるのはワクワクします。あのようなものを作りたかったというのが本音です。
360度評価（多面評価）について
刷新前になかったものですが、一応議題には出しました。
ピアフィードバックなどもそうですが、従業員がお互いに評価し合う（時にはお互い監視し合うになってしまう）制度、これも実に難しいなと思っています。
過去に、ピアフィードバックが来る時期になると胃の調子が悪くなるという方のお話を聞く機会がありました。自分が言ったことによって人が傷つかないか、または人から嫌われないか、というものです。
そもそもフィードバックというものを幼少期から習いつつ行ってきたのであれば、それに対する慣れはあるかもしれませんが、社会人になってからやる方が多く、目上の方・仲の良い同僚にフィードバックをすることに慣れている人は少数です。
そして何よりも、ピアフィードバックを行ったことで何かが良くなったというケースを実例としてあまり聞いたことがないというのもあります。
「あの人はこういう時にこう感じたみたいだよ」というのを知るいい機会だと思いますが、それなら評価のタイミングにピアフィードバックとして伝えるのではなく、都度伝えた方が良いフィードバックになると思います。半期ごとに言われても言われた側が覚えていないケースも多々あります。
まず大切なことは、どのタイミングでフィードバック面談を行い、相手といかに向き合うかです。
通常の「1on1」の日が近づいているなら、そのときまで待ってもいいですが、何かトラブルが起きているときは、待っている余裕などないでしょう。そんなときは、「リアルタイムフィードバック」が必要です。すぐに呼び出してしまいましょう。 一般に、トラブルが起きてから時間を空けないようにすればするほど、フィードバックの効果は高まります。これを「即時フィードバックの原則」といいます。要するに、間髪を答れず、問題行動が起こったらただちにフィードバックをする方が効果は高いということです。
ということで今のところ、これは無しだと考えました。
ワクワクする目標設定と窮屈な目標設定
「目標設定をする」という言葉を聞いたり、それをやらないといけない時に、テンションが上がってそれができているかはすごく重要と捉えています。
年に数回行う作業なので、ワクワクするのなら大いにやるべきですが、その度にテンションが下がったりしてしまうのなら、ここはもしかしたら改善ポイントかもしれません。
そして、組織の目標と個人の目標を必ずしも結び付かせなくてもいいのではないかという考えをずっと思考してきました。
組織の目標をブレイクダウンして自分の目標にした場合、窮屈な目標設定になったりしないか？ということです。
とはいえ組織の中で働いているので、そこが窮屈なのはしょうがないのではないか？という考えもあります。
ここの思考はよく無限ループしていました。
例えば、OKR は確かに素晴らしい目標設定のアプローチではありますが、それが我々のやり方にうまくフィットするか、こういう流行っているから右に倣えで導入するのではなく一旦疑問として捉えるのは大事だと思っています。
さらに言うと OKR を導入してうまくいっている組織はどれぐらいあるのだろう、 OKR が本来掲げているワクワクする目標設定をするというのをちゃんと理解して導入している組織、そしてその思想を現場レベルまで落としている企業はどれぐらいいるのだろうか、こういう議論も何度もしてきました。
個人的に OKR を使うとそれはそれはうまいこと作用するのですが、組織で使うとなぜかワクワクできないという問題があることはユーザーインタビューで度々出てきました。
ワクワクしない目標設定を無理やりやって従業員の Employee Experience を損なうぐらいなら、そもそも導入しない方がいいのではないか。または従業員の欲望そのものを目標にしても良いのではないか。と考え始めました。
例えば、「いい人になりたい」「地方移住したい」なんてのもありだし、それを成し遂げるためのバックキャスティングをしていくという過程が重要であると思います。
「地方移住したい」とした場合に、それを実現するための社内制度がない場合、そこについてのディスカッションの場を設けるなど、動けることはたくさんあるということです。みんなで会社を作り上げていくというのをベースに考えると、こういう動きも決して悪いことではなく、むしろそこで仕事のパフォーマンスが上がるのなら、それもありだということです。
こういう自分や組織の行動変容を含めた目標設定が真の目標なのではないか、と捉えています。
ワクワクする目標設定をした場合
思考が膨らむ
楽しむマインドセットになるため、行動が変化する、つまりいい動きができるようになる
行動が変わらない目標設定は、わざわざ立てる意味がないのではないか
バックキャスティング
こうなったらハッピーだなーというイメージから逆算して今何をするべきかを決めていく方式
これは個人的にでもそうだが、チームというレベルでも妄想するのはとても大事であり、何より楽しい
例：「有名エンジニアになりたい」のバックキャスティング
この場合、 GitHub でスター1000個、付くのが目標として、それを実現するのはどうしたらいいかを逆算していく
じゃあ知名度を上げつつ、自分の知見を多くするために、毎月登壇してみよう、そのための資料作りや素振りをしよう
そのためには、一週間のうちに複数個のライブラリを触ってみて、それの記事を書いてみよう
書いた記事のライブラリを LT として発表できる機会がないか watch して、あれば登壇する
こうすることで、知名度＋積極的に業界にコミットしている感が生まれるので、そういう人が書いたモジュールにはスターがつきやすい
これが行動に変化が生まれる目標例です
「バックキャスティングとは、最初に目標とする未来像を描き、次にその未来像を実現するための道筋を未来から現在へとさかのぼって記述するシナリオ作成の手法です。現在を始点として未来を探索するフォアキャスティングと比較して、劇的な変化が求められる課題に対して有効とされています。」
https://www.rd.ntt/se/media/article/0022.html#:~:text=バックキャスティングとは、最初,有効とされています。
窮屈な目標設定をした場合
自分が立てた目標がいかに困難であるかを上司に訴えかけてしまう、という騙し合いが 1on1 で行われてしまう
綺麗な文章を作り、あたかもそれがすごく良いことで、それを上司が見ていい評価が得られるような、目標設定をすることが目標になってしまうケースがある
うまく使わないとただのノルマのように感じてしまう
KPI を追いすぎることで、指標への執着などが発生し、ユーザーを裏切り、ビジネス目標を達成できなくなる恐れがある
キャンベルの法則
「ありとあらゆる数値目標はハック可能である」
お給料を増やす方法として捉えられてしまい、やはりハックされてうまく機能しない
この辺りを踏まえると、目標設定はするで良い、ただしあくまでも Will を尊重して、バックキャスティングを元に逆算して目標設定するのが良さそう。
そして、評価と直接結びつけず、評価のタイミングで自慢できる材料として使ってもいいよ、ぐらいに置いておくと、個人 OKR と評価が直接は結び付かずうまく機能するのではないか。
その場合、評価の材料がないではないか？という問いには、評価の時には上長に自分が今期やってきたことを自慢する、その時の個人目標を立てたんだ！そしてそれをこれぐらいやったんだぜ！と自慢を追加しても良い、とすると良さそう。
などと、考えてみました。
グレードについて
ここまで長々と全貌の一部分を説明してきましたが、やっと結果としてどうなったかを書いていきます。
ファンタラクティブグレードは大きく5種類作りました。
FG1 はなしにして、FG2・FG3 はインターンやアルバイトとして取っておきました。なので、 FG4 から始まっております。
それぞれのグレードの違いですが、矢印（ベクトル）の方向だけを定義しました。それぞれの説明欄に書かれたことがこのグレードの役割で、それ以外のスキルの定義やできてほしいことは一切書いていません。ここが最大の特徴かと思います。
矢印というのはどういうことかと言うと、FG4 を例にとると、シニアの協力の元、自分のやるべきことができるということになります。ジュニアであったり新入社員だったりがこの領域になります。なので、まだ個人に矢印が向いている状態なので、ここが FG4 です。
FG5 になってくると、プロジェクトで自分がどう動いていくかを能動的に考えていくことになります。ここが一番人口が多いグレードになると思います。主語がプロジェクトになってくるので、「デプロイをしやすくしたことで、リリース頻度が上がった」や「ミーティングで発言する、率先して画面共有した、コメントを書いた」のように能動的にプロジェクトにアプローチすることが求められます。
各グレードでやってほしいことを書いてしまうとそれだけをやってしまう評価ハックを、防ぐ効果もあります。自分で何をしたらいいのかを考えて得意な領域でやっていく、というのが求められます。故に定義は一切ないのです。
ここで大事になってくるのが 1on1 です。1on1 でそれぞれが自分の Will を元に、目標だったり何か身近なやりたいことをコーチと話をし、そこから応援という形で補助を受け、自分から能動的にゴールを設定していくというのも大切です。自分から出したゴールというのはやはり強く、誰かから押し付けられたものではなく、さらにはコーチから押し付けられたものでもないため、だんだんと楽しくなってきます。そこと今のグレードや上位のグレード、これは矢印の向きを広げていく話ですが、こういう話を 1on1 で相互に大切に会話していきます。そして自分のコンフォートゾーン（居心地が良い空間）をさらに広げていきます。
以下の図はファンタラクティブグレードの範囲を表す図ですが、コンフォートゾーンを表現する「成長の4つの領域」の図と似ています。個人だけの貢献だけではなくプロジェクトに貢献したい、貢献していないことが居心地が悪い、と感じることで、その領域に広げようとする行為が大切なので、似たような図になりました。
給与のレンジも新しくしました。
一つ面白い点としては、各グレードの被りが大きいことです。
これはプログラマー界隈で言われる IC（Individual Contributor / 個人貢献者）と EM（Engineering Manager）という二つのルートのような、スペシャリスト方面か、マネージメントをしていく方面かの二極化するケースを、さらに広く許容するようなイメージをしています。
つまり、 FG5 ならプロジェクトに矢印が向きますが、そこである程度ずっと貢献していても良いのです。貢献の仕方は様々なので、 IC や EM のどちらかのような動きでもいいですし、それ以外の貢献をいくらでも模索しても良いのです。
もし FG6 にいきたいのであれば、矢印の向きはチームへの貢献も含めなければなりません。矢印の方向を変えたくない、あるいは変えると初心者に戻ってしまうというピーターの法則も考慮しているため、融通を聞かせて、このレンジの被りになっています。
余談ですが、この案は、4案目でやっと決定しました。上記のようなアイデアを3つもボツにさせました。内容は恥ずかしいので割愛します。
目標設定について
上の方で、目標設定についての考察を書きましたが、結果的に「目標設定はしない」ということで決定しました。
なので会社からお願いする目標設定はありません。
今までなくてもうまく回っていたのに、良かれと思って目標設定を追加することに意味があるか不明だったので、現状を継続します。
ただ、1on1 でコーチとの会話でゴールを決めたり、自分の Will を元に目標を決めていくことは大いにやってもらって構いません。そしてその目標で実現したことや、頑張っていることを評価のタイミングで自慢していただいても問題ありません。むしろ評価します。
ここが今までと違うポイントになります。
エンジニアリングマネージャーやデザインマネージャーというポジションができたので、 1on1 がより活きてくるようになっているので、そこはとても大事にしていきたいです。
評価について
すでに上記で書きましたが、グレード内での細かい定義がないのと目標設定はやりません、という内容です。
評価は、年に2回行います。
少し大事なことなので書いておきますが、ファンタラクティブはフルリモートワークの会社です。なので、見えていない・話していないことは誰にも伝わりません。自分がやったことや貢献したことは、人に伝えて初めて伝わります。評価者にも同様です。評価者は魔法使いではないので、言っていないがいい感じに見てくれているでしょ？というのはなしにしてもらっています。
以下は私が残したメモです。
上長はあなたのことをちゃんと見ているが、上長も人間なので、見れていないこともある。そこをちゃんと認識していないと、あれだけやったのになぜ見てもらえていないのか、というような考え方が生まれてしまう。これは健全ではないので、ちゃんと自分がやったことを自分の言葉で伝える必要がある。それを元々上長が知っていてもである。
評価で見るポイント
Slack や 他のコミュニケーションツール での振る舞い
Slack であれば URL があるので、ファクトベースになる
人を助ける利他のマインド
定性的なものもファンタラクティブでは大いに評価する
実際にプロジェクトで行ったこと
GitHub であれば Pull Request の URL があればなお良い
デザインは Figma で管理しているのであればなお良い
組織カルチャー貢献
チームへの貢献
越境して他の領域にチャレンジしたこと
採用活動
社外アプローチ
OSS（オープンソースソフトウェア） 貢献
あげるとキリがないのでこのくらいで etc…
一応ですが、評価についての流れなどを書いておきます。ここも今まで明記していなかったので、今回追加したものです。
非常にシンプルになっているかと思います。
一次評価
自己評価を元に上長は、判定をジャッジする。
また、内容によっては、複数回 1on1 などをし、詳細を決めていく。
キャリブレーション
評価会議を経営、マネージャー陣で行い、今期の昇給や昇格を判定する。
昇給・昇格
キャリブレーションを元に決定する。
評価フィードバック
マネージャーから、 フィードバックの面談が予定され、フィードバックが行われる。
あとがき
いかがでしたでしょうか？
まだまだ至らない点はありますが、試行錯誤した感じは伝わったのではないかと思っています。
ファンタラクティブでは体験設計という事業ドメインのもと、従業員体験（Employee Experience）も大切に考えています。それがつまり「ひとに向き合う」ということだと思っています。
仕事でもなんでも、楽しんでやることが一番です。忙しい時はもちろんありますが、そんな時でも楽しいという感覚があれば、結構踏ん張れるものです。
もしもこの記事がそういったエッセンスの何か一部になれるのならとても嬉しいです。
では、良い体験を。
採用デッキ
We Are Hiring!
弊社は様々な職種を募集しております。
このような記事を読んで、グッと来た方は是非ご応募のほどお待ちしております！
参考にさせていただいた他社の事例と書籍
一部ではありますが、大変参考にさせていただいたリンクや本を貼らせていただきます。
本当にありがとうございます。
この記事が気に入ったらサポートをしてみませんか？