支払いと住所フォームのベスト プラクティス

ユーザーが住所とお支払い方法をできるだけすばやく簡単に入力できるようにして、コンバージョン数を最大限に増やしましょう。

Sam Dutton

優れたデザインのフォームは、ユーザーをサポートしてコンバージョン率を高めます。小さな修正が大きな違いを生む可能性があります。

すべてのベスト プラクティスを実践したシンプルなお支払い方法の例を次に示します。

すべてのベスト プラクティスを示すシンプルな住所フォームの例を次に示します。

チェックリスト

意味のある HTML を使用する

ジョブ用に作成された要素と属性を使用します。

  • <form>、<input>、<label>、<button>
  • type、autocomplete、inputmode

これにより、組み込みのブラウザ機能が有効になり、アクセシビリティが向上し、マークアップに意味を持たせることができます。

HTML 要素を意図したとおりに使用する

フォームを <form> に追加する

<input> 要素を <form> でラップせずに、JavaScript のみでデータ送信を処理したいと思うかもしれません。

このようなことは行わないでください。

HTML <form> を使用すると、すべての最新ブラウザに組み込まれた強力な機能にアクセスできるほか、スクリーン リーダーなどの支援デバイスからサイトにアクセスしやすくなります。また、<form> を使用すると、JavaScript のサポートが限られている古いブラウザ向けに基本的な機能を簡単に構築し、コードに不具合がある場合や、JavaScript を実際に無効にしている少数のユーザーでもフォームの送信を有効にできます。

ユーザー入力用のページ コンポーネントが複数ある場合は、それぞれを独自の <form> 要素に含めます。たとえば、検索と登録を同じページで行っている場合は、それぞれを <form> に含めます。

<label> を使用して要素にラベルを付ける

<input>、<select>、<textarea> にラベルを付けるには、<label> を使用します。

ラベルの for 属性に入力の id と同じ値を指定することで、ラベルを入力に関連付けます。

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

1 つの入力に 1 つのラベルを使用します。複数の入力に 1 つのラベルだけのラベルを付けないでください。これはブラウザやスクリーン リーダーに最適です。ラベルをタップまたはクリックすると、それに関連付けられている入力にフォーカスが移動し、ラベルまたはラベルの入力がフォーカスされると、スクリーン リーダーがラベルテキストを読み上げます。

ボタンの利便性を高める

ボタンには <button> を使用します。<input type="submit"> も使用できますが、div など、ボタンとして機能するランダムな要素は使用しないでください。ボタン要素には、ユーザー補助機能と組み込みのフォーム送信機能が用意されています。また、スタイル設定も簡単です。

各フォームの送信ボタンに、機能を示す値を設定します。決済までの各ステップには、進行状況を表示して次のステップをわかりやすくする、わかりやすい行動を促すフレーズを使用します。たとえば、配送先住所のフォームの送信ボタンには、「続行」や「保存」ではなく「お支払いに進む」というラベルを付けます。

ユーザーが送信ボタンをタップまたはクリックした後（特にユーザーが支払いや注文を行う場合）は、送信ボタンを無効にすることを検討します。多くのユーザーは、正常に動作している場合でも、ボタンを繰り返しクリックしています。これにより、購入手続きが煩雑になり、サーバーの負荷が増大する可能性があります。

一方、完全で有効なユーザー入力を待機している送信ボタンを無効にしないでください。たとえば、情報が不足しているか無効であるために、[住所を保存] ボタンを無効にしたままにしないでください。ボタンをタップまたはクリックし続けると、ボタンが壊れていると思い込んでしまう可能性があるため、ユーザーの役に立ちません。 代わりに、ユーザーが無効なデータを含むフォームを送信しようとした場合は、問題の原因と修正方法をユーザーに説明してください。これは、データ入力が難しいモバイルでは特に重要です。モバイルでは、データの欠落や無効なフォームデータが、フォームを送信する前にユーザーの画面に表示されない可能性があります。

HTML 属性を最大限に活用する

ユーザーがデータを簡単に入力できるようにする

適切な入力 type 属性を使用してモバイルで適切なキーボードを表示し、ブラウザによる基本的な組み込み検証を有効にします。

たとえば、メールアドレスには type="email" を使用し、電話番号には type="tel" を使用します。

メールアドレスの入力（type=email の使用）と電話番号の入力（type=tel の使用）に適したキーボードを示す Android スマートフォンの 2 枚のスクリーンショット。
メールと電話に適したキーボード

日付には、カスタムの select 要素を使用しないでください。適切に実装されていないと自動入力のエクスペリエンスが損なわれ、古いブラウザでは機能しません。誕生年などの数字には、select ではなく input 要素を使用することを検討してください。これは、長いプルダウン リストから選択するよりも、手動で数字を入力する方が簡単でエラーも少ないためです（特にモバイルの場合）。inputmode="numeric" を使用してモバイルで正しいキーボードが表示されるようにし、ユーザーが適切な形式でデータを入力できるように、テキストまたはプレースホルダによる検証と書式設定のヒントを追加します。

オートコンプリートを使用してアクセシビリティを向上させ、ユーザーがデータの再入力を回避できるようにする

適切な autocomplete 値を使用すると、ブラウザはデータを安全に保存し、input、select、textarea の値を自動入力できます。これはモバイルで特に重要であり、フォームの放棄率が高いことを避けるために不可欠です。オートコンプリートには、ユーザー補助機能のさまざまなメリットもあります。

フォーム項目に適切なオートコンプリート値を使用できる場合は、その値を使用する必要があります。MDN ウェブ ドキュメントには、値の完全なリストと正しい使用方法の説明が記載されています。

安定した値

請求先住所

デフォルトでは、請求先住所を配送先住所と同じに設定します。フォームに請求先住所を表示するのではなく、請求先住所を編集するためのリンクを表示（または summary 要素と details 要素を使用）することで、視覚的にわかりやすくします。

請求先住所を変更するリンクが表示されている購入手続きページの例。
請求を確認するためのリンクを追加

配送先住所の場合と同様に、請求先住所にも適切なオートコンプリート値を使用します。これにより、ユーザーはデータを複数回入力する必要がなくなります。異なるセクションで同じ名前の入力に対して異なる値がある場合は、オートコンプリート属性に接頭辞を追加します。

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

ユーザーが適切なデータを入力できるよう支援する

お客様は「何か間違っていた」ことを理由に「それを外す」ことは避けてください。問題が発生したらすぐにユーザーが修正できるようにすることで、ユーザーがフォームに迅速かつ簡単に入力できるようにします。顧客は決済プロセスを通じて、企業に商品やサービスの対価を提供しようとします。企業の役割は、罰するのではなく、顧客を支援することです。

フォーム要素に制約属性を追加して、min、max、pattern などの許容値を指定できます。要素の値が有効かどうかに応じて、要素の有効性の状態が自動的に設定されます。また、:valid と :invalid の CSS 疑似クラスも、有効な値または無効な値で要素のスタイル設定に使用できます。

たとえば、次の HTML では、誕生年を 1900 ～ 2020 年の間で入力するよう指定しています。type="number" を使用すると、入力値が min と max で指定された範囲内の数値のみに制限されます。範囲外の数値を入力しようとすると、入力は無効な状態に設定されます。

次の例では、pattern="[\d ]{10,30}" を使用して、スペースを許可しながら有効な支払いカード番号を確保しています。

最新のブラウザでは、email 型または url 型の入力に対しても基本的な検証が行われます。

フォームの送信時に、ブラウザは、問題のある値や必須項目が欠落しているフィールドに自動的にフォーカスを設定します。JavaScript は必要ありません。

パソコンの Chrome のログイン フォームのスクリーンショット。ブラウザ プロンプトが表示され、無効なメールアドレスの値にフォーカスしています。
ブラウザによる基本的な組み込み検証。

ユーザーが送信ボタンをクリックしたときにエラーのリストを提供するのではなく、インラインで検証して、ユーザーがデータを入力するときにフィードバックを提供します。フォームの送信後にサーバーでデータを検証する必要がある場合は、検出された問題をすべてリストアップし、無効な値を含むすべてのフォーム フィールドを明確にハイライト表示します。また、問題のある各フィールドの横に、修正が必要な項目を説明するメッセージをインライン表示します。サーバーログとアナリティクス データに一般的なエラーがないか確認します。場合によっては、フォームの設計を見直します。

また、ユーザーがデータを入力しているときやフォームを送信しているときも、JavaScript を使用して、より確実な検証を行う必要があります。Constraint Validation API（広くサポートされている）を使用して、組み込みのブラウザ UI を使用してカスタム検証を追加し、フォーカスと表示のプロンプトを設定します。

詳しくは、JavaScript を使用して複雑なリアルタイム検証を行うをご覧ください。

ユーザーが必須データの欠落を回避できるよう支援する

必須の値の入力に required 属性を使用します。

フォームが送信されると、最新のブラウザが自動的にプロンプトを表示し、データが欠落している required フィールドにフォーカスを設定します。そのため、:required 疑似クラスを使用して必須フィールドをハイライト表示できます。JavaScript は必要ありません。

すべての必須フィールドのラベルにアスタリスクを追加し、フォームの先頭にアスタリスクの意味を説明するメモを追加します。

購入手続きの簡素化

モバイル コマースのギャップに注意する

ユーザーが予算疲れしているとします。残量を使い切るとユーザーは離れていくでしょう。

特にモバイルでは、煩わしさを減らし、集中力を維持する必要があります。多くのサイトでは、モバイルでのトラフィックは多くなりますが、パソコンでのコンバージョン数も多くなります。この現象は、モバイル コマースのギャップとして知られています。ユーザーがパソコンで購入を完了することを希望する場合もありますが、モバイル コンバージョン率の低下は、ユーザー エクスペリエンスの低下が原因でもあります。あなたの仕事は、モバイルでのコンバージョンの損失を最小限に抑え、パソコンでのコンバージョン数を最大化することです。調査によると、モバイルフォーム エクスペリエンスを改善するには大きなチャンスがあることがわかっています。

何よりも、長く見え、複雑で、方向性のないフォームは、ユーザーが見捨てる可能性が高くなります。これは、ユーザーが小さな画面を使用している場合、注意が散漫になっているとき、急いでいるときに特に当てはまります。要求するデータの量は できる限り少なくします

「ログインせずに決済」をデフォルトに設定する

オンライン ショップの場合、フォームの煩わしさを軽減する最も簡単な方法は、「ログインせずに決済」をデフォルトにすることです。購入前にユーザーにアカウントの作成を要求しないでください。「ログインせずに決済できない」ことが ショッピングカートを放棄する主な理由です

購入手続き中にショッピング カートが放棄される理由。
baymard.com/checkout-usability から

購入手続き後にアカウント登録を提示できます。この時点で、アカウントの設定に必要なほとんどのデータはすでに存在するため、アカウントの作成はすばやく簡単に行うことができます。

購入手続きの進行状況を表示する

進行状況を表示し、次に何をする必要があるかを明確にすることで、購入手続きの複雑さを軽減できます。以下の動画では、英国の小売業者 johnlewis.com がこれをどのように実現しているかを示しています。

購入手続きの進行状況を表示する。

勢いを維持する必要があります。支払いのステップごとに、ページ見出しとわかりやすいボタンの値を使用して、今すぐ行う必要があることと、次の決済ステップが明確にわかるようにします。

フォームのボタンに、次に何が表示されるかがわかるわかりやすい名前を付けます。

フォーム入力で enterkeyhint 属性を使用して、モバイル キーボードの入力キーラベルを設定します。たとえば、マルチページ フォーム内では enterkeyhint="previous" と enterkeyhint="next" を使用し、フォームへの最終的な入力には enterkeyhint="done"、検索入力には enterkeyhint="search" を使用します。

EnterkeyHint 入力属性によって Enter キーボタンのアイコンがどのように変化するかを示す、Android の住所フォームを示す 2 つのスクリーンショット。
Android のキーボタン（[次へ] と [完了] を入力する）

enterkeyhint 属性は Android と iOS でサポートされています。詳しくは、EnterkeyHint の説明をご覧ください。

ユーザーが購入手続きの間を簡単に行き来できるようにし、支払いの最後のステップであっても、注文を簡単に調整できるようにします。限定的な概要だけでなく、注文の詳細全体を表示します。ユーザーが支払いページからアイテムの数量を簡単に調整できるようにします。購入手続きの優先順位は コンバージョンへの進行を妨げないようにすることです

不要な写り込みを消去

商品のプロモーションなど、見た目が乱雑なものや気を散らすものを削除して、離脱点をできるだけ抑えます。 成功を収めている小売業者の多くは、購入手続きからナビゲーションや検索まで削除しています。

johnlewis.com の購入手続きの進行状況を示すモバイルのスクリーンショット。検索、ナビゲーション、その他の不要なものは削除されます。
購入手続きの際に、検索、ナビゲーション、その他の注意散漫を排除。

プロセスに集中しましょう。今は、ユーザーに他の行動を起こさせるタイミングではありません。

無料ステッカーの気が散るプロモーションを表示しているモバイルの購入手続きページのスクリーンショット。
ユーザーが購入を完了するのを妨げることがないようにしてください。

リピーターに対しては、必要のないデータを非表示にすることで、購入手続きをさらに簡素化できます。たとえば、配送先住所を（フォームではなく）書式なしテキストで表示し、ユーザーがリンクを使用して変更できるようにします。

購入手続きページの [注文の確認] セクションのスクリーンショット。書式なしテキストで表示され、配送先住所、お支払い方法、請求先住所を変更するためのリンクが含まれていますが、それらは表示されません。
ユーザーに表示する必要がないデータを非表示にします。

名前と住所を簡単に入力できるようにする

必要なデータのみをリクエストする

名前と住所のフォームのコーディングを開始する前に、必要なデータを確認してください。必要のないデータはリクエストしないでください。フォームの複雑さを軽減する最も簡単な方法は、不要なフィールドを削除することです。これは顧客のプライバシーの保護にもつながり、バックエンド データの費用と法的責任を軽減できます。

単一の名前を入力

名、姓、名誉、その他の名前の構成要素を別々に保存する正当な理由がない限り、ユーザーが 1 回で名前を入力できるようにします。入力内容を 1 つにすることで、フォームの複雑さが軽減され、切り取りと貼り付けが容易になり、自動入力が簡単になります。

特に、正当な理由がない限り、接頭辞やタイトルに別の入力を追加しないでください（Mrs、Dr、Lord など）。ユーザーは必要に応じて自分の名前を入力できます。また、現在のところ、honorific-prefix のオートコンプリートはほとんどのブラウザで動作しないため、名前の接頭辞またはタイトルにフィールドを追加すると、ほとんどのユーザーにとって、住所フォームの自動入力が機能しなくなります。

名前の自動入力を有効にする

フルネームには name を使用します。

<input autocomplete="name" ...>

名前の部分を分割する正当な理由がある場合は、適切なオートコンプリート値を使用するようにしてください。

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

国際名を許可する

入力内容を検証したり、名前データに使用できる文字を制限したりできます。ただし、アルファベットでは可能な限り制限を緩める必要があります。名前が無効だと言われるのは失礼なことです。

検証で、ラテン文字のみと一致する正規表現は使用しないでください。ラテン文字のみを使用すると、名前または住所にラテン アルファベット以外の文字が使用されているユーザーは除外されます。代わりに Unicode 文字のマッチングを許可し、バックエンドで入力と出力の両方で Unicode を安全にサポートするようにしてください。正規表現での Unicode は、最新のブラウザで適切にサポートされています。

すべきでないこと
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
推奨事項
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
Unicode 文字一致とラテン文字のみの文字一致の比較。

さまざまな住所形式に対応

住所フォームを設計する際は、1 つの国内であっても、住所形式が非常に多様であることに留意してください。「通常の」アドレスであると仮定しないように注意してください。（よくわからない場合は、UK Address Oddities! をご覧ください）。

住所フォームを柔軟に活用

ユーザーに住所の収まる範囲に収まらない項目に住所を詰め込もうとしないでください。

たとえば、番地と番地を別々の入力にする必要はありません。多くの住所でこの形式が使用されていません。また、不完全なデータがあるとブラウザの自動入力が機能しなくなる可能性があります。

required の住所フィールドは特に注意が必要です。たとえば、英国の大都市の住所には郡がありませんが、多くのサイトでは郡名の入力が求められています。

柔軟な住所を 2 行使用すると、さまざまな住所形式に対応できます。

<input autocomplete="address-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

一致するラベルを追加:

<label for="address-line-1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line-1" id="address-line1" ...>

<label for="address-line-2">
Address line 2 (optional)
</label>
<input autocomplete="address-line-2" id="address-line2" ...>

以下に埋め込まれたデモをリミックス、編集して、この機能を試すことができます。

住所に単一のテキストエリアを使用することを検討する

住所に関する最も柔軟なオプションは、単一の textarea を指定することです。

textarea アプローチはあらゆる住所形式に適合し、切り取りと貼り付けに適していますが、データ要件には合わない可能性があることに留意してください。また、ユーザーがこれまで address-line1 と address-line2 でフォームのみを使用していた場合、自動入力を行えない可能性があることに留意してください。

テキスト領域の場合は、オートコンプリート値として street-address を使用します。

住所に単一の textarea を使用するフォームの例を次に示します。

住所フォームの多言語化とローカライズ

住所フォームは、ユーザーの所在地に応じて、多言語化とローカライズを考慮することが特に重要です。

同じ言語であっても、住所部分の名称は住所の形式によっても異なります。

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

住所に合わないフォームや、期待した単語が使用されないフォームが表示されると、不快に感じたり、戸惑ったりする可能性があります。

サイトで複数の言語 / 地域向けに住所フォームをカスタマイズする必要がある場合もありますが、上記のようにフォームの柔軟性を最大化する手法で十分である場合もあります。住所フォームをローカライズしない場合は、さまざまな住所形式に対応できるよう、重要な優先事項を把握してください。 * 番地や番地を強要するなど、住所の部分を過度に限定することは避けてください。* 可能な限り、フィールドを required にしないでください。たとえば、多くの国では郵便番号がありません。地方部の住所には番地や道路名がないこともあります。* 「国」ではなく「国 / 地域」や「郵便番号」ではなく「郵便番号」のような包括的な名前を使用してください。

柔軟性を保つ上記の単純な住所フォームの例は、多くの言語 / 地域で適切に機能するように適応させることができます。

郵便番号による住所の検索を避けることを検討する

一部のウェブサイトでは、郵便番号に基づいて住所を検索するサービスがあります。ユースケースによってはこれが理にかなっている場合もありますが、潜在的なデメリットに注意する必要があります。

郵便番号に基づく住所の候補は、すべての国で利用できるわけではありません。また、地域によっては、郵便番号に多数の住所が含まれている可能性があります。

郵便番号には複数の住所が含まれている可能性があります。

ユーザーが長い住所リストから選択するのは困難です。特に、急いでいる場合やストレスを感じているモバイルの場合は、そのリストから選ぶのは困難です。ユーザーが自動入力を活用して、1 回のタップまたはクリックで完全な住所を入力できるように、より簡単に、かつミスを犯しにくくなります。

名前を 1 つ入力すると、ワンタップ（ワンクリック）で住所を入力できます。

支払いフォームをシンプルにする

支払いフォームは、購入手続きにおいて最も重要な部分です。お支払い方法のデザインの不備は、ショッピング カートが放棄される一般的な原因の一つです。細部に悪影響がある: 特にモバイルでは、小さな不具合がユーザーに購入の放棄につながることがあります。あなたの仕事は、ユーザーができるだけ簡単にデータを入力できるようにフォームを設計することです。

ユーザーが支払いデータを再入力しないようにする

支払いカードのフォームに適切な autocomplete 値（支払いカード番号、カードの名義、有効期限の月と年など）を追加してください。

  • cc-number
  • cc-name
  • cc-exp-month
  • cc-exp-year

これにより、ブラウザは支払いカード情報を安全に保存し、フォームデータを正しく入力することで、ユーザーを支援します。オートコンプリートを使用しない場合、ユーザーが支払いカードの詳細を物理的に記録することや、支払いカードデータをデバイスに安全でない状態で保存してしまう可能性が高くなります。

支払いカードの日付にカスタム要素を使用しない

カスタム要素が適切に設計されていない場合、自動入力が中断されて支払いフローが中断される可能性があります。また、古いブラウザでは動作しません。その他の支払いカード情報がオートコンプリートからすべて確認可能であっても、カスタム要素に対して自動入力が機能せず、ユーザーが物理的な支払いカードを見つけて有効期限を調べることを余儀なくされる場合は、販売を失う可能性があります。代わりに標準の HTML 要素を使用し、それに応じてスタイル設定することを検討してください。

自動入力が中断されるカードの有効期限に関するカスタム要素が表示されている支払いフォームのスクリーンショット。
有効期限を除くすべてのフィールドにオートコンプリートされました。

支払いカードと電話番号を 1 つの入力で使用可能

支払いカードと電話番号は 1 つの入力のみにします。数字を分割せず、これにより、ユーザーによるデータ入力や検証の手間が軽減され、ブラウザでの自動入力が可能になります。PIN や銀行コードなどの他の数値データについても同様に検討してください。

クレジット カード フィールドが 4 つの入力要素に分割されている支払いフォームのスクリーンショット。
1 つのクレジット カード番号に複数の入力を使用しないでください。

慎重に検証する

データ入力は、リアルタイムとフォーム送信前の両方で検証する必要があります。これを行う方法の 1 つは、支払いカードの入力に pattern 属性を追加する方法です。ユーザーが無効な値を指定して支払いフォームを送信しようとすると、ブラウザは警告メッセージを表示し、入力にフォーカスを設定します。JavaScript は必要ありません。

ただし、pattern 正規表現には、支払いカード番号の長さの範囲（14 桁（場合によってはそれ未満）から 20 桁（またはそれ以上））を処理できる柔軟性が必要です。支払いカード番号の構造について詳しくは、LDAPwiki をご覧ください。

ユーザーが新しい支払いカード番号の入力時にスペースを含められるようにします。これは、物理的なカードでは番号がこのように表示されるためです。これにより、ユーザーにとっては「何か間違っていた」と伝える必要がなくなり、コンバージョン フローが中断される可能性が低くなります。また、処理前に数字のスペースを簡単に削除できます。

さまざまなデバイス、プラットフォーム、ブラウザ、バージョンでテスト

フォーム要素の機能と外観はさまざまであり、ビューポートのサイズの違いによって配置に問題が生じる可能性があるため、ユーザーが最もよく使用するプラットフォームで住所と支払いフォームをテストすることが特に重要です。BrowserStack を使用すると、さまざまなデバイスやブラウザでオープンソース プロジェクトの無料テストを行えます。

iPhone 7 と 11 での支払いフォーム、payment-form.glitch.me のスクリーンショット。[お支払いを完了する] ボタンが iPhone 11 では表示されるが、7 では表示されない
iPhone 7 と iPhone 11 の同じページ。
モバイル ビューポートが小さい場合はパディングを減らし、[支払いを完了] ボタンが非表示にならないようにしてください。

分析と RUM を実装する

ユーザビリティとパフォーマンスをローカルでテストすることは有用ですが、ユーザーが支払いフォームと住所フォームをどのように使用するかを適切に把握するには、実際のデータが必要です。

そのためには分析と Real User Monitoring が必要です。これは、購入手続きページの読み込みにかかる時間や支払いの完了にかかる時間など、実際のユーザー エクスペリエンスに関するデータです。

  • ページ分析: フォームがあるすべてのページのページビュー数、直帰率、離脱数。
  • インタラクション分析: ゴール ファネルとイベントは、ユーザーが購入手続きのフローを放棄した場所と、フォームを操作したときにどのようなアクションを取ったかを示します。
  • ウェブサイトのパフォーマンス: ユーザー中心の指標から、購入手続きページの読み込みが遅いかどうかや、遅い場合は原因を把握できます。

ページ分析、インタラクション分析、実際のユーザー パフォーマンスの測定は、サーバーログ、コンバージョン データ、A/B テストと組み合わせると特に有用です。これにより、割引コードが収益を増やすかどうかや、フォームのレイアウトの変更がコンバージョンを改善するかどうかなどの質問に答えることができます。

その結果、取り組みに優先順位を付け、変化を起こし、成功を称える確固たる基盤となります。

さらに詳しく

写真提供: @rupixen（Unsplash）