Code.Yuでは品質担保のため、以下のガイドラインを設けています。
日々進化するWeb技術に対応し、ガイドラインは随時アップデートしていきます。

HTML

セマンティックなマークアップ

Webサイトは視覚的に認識するユーザーだけに向けたものではありません。
スクリーンリーダーや検索エンジンへ向けたマシンリーダブルなマークアップを心がけます。

むやみに標準の動きを無効にして、イベントトリガーに使用しません。
クリックイベントにはbuttonタグを使用します。

<!-- ❌NG むやみに標準の動きを無効にしない -->
<a id="js-menu-open">メニュー</a>

<script>
  const menuOpen = document.querySelector("#js-menu-open");
  menuOpen.addEventListener("click", (e) => {
    e.preventdefault()
    // メニューオープンの処理
  });
</script>

div span について

HTMLの可読性にフォーカスすれば、できるだけdivやspanの使用を控え、ネストは少なくするべきですが、divを減らすことに注力すると各タグへのCSSの負担は大きくなります。
そのため、Webサイト全体での保守性を重視してHTMLのネストを使います。
以下の順でマークアップすることで、セマンティックなマークアップと保守性の高いCSS設計を両立します。

デザインの再現は考慮せず、まずはセマンティック要素だけでマークアップします。

<header>
  <h1><a href="/">ロゴ</a></h1>
  <nav>
    <ul>
      <li><a href="/news/">お知らせ</a></li>
      <li><a href="/contact/">お問い合わせ</a></li>
    </ul>
  </nav>
  <button>メニュー</button>
</header>

<section>
  <h2>お知らせ</h2>
  <a href="/article-01/">
    <h3>お知らせタイトルが入ります。</h3>
    <p>お知らせの抜粋が入ります。</p>
  </a>
  <a href="/news/">お知らせの一覧をみる</a>
</section>

デザインの再現に必要なdivとspan を追加していきます。

インナーのような特定の役割を担うdivタグも、CSSの保守性を重視して使用します。
この時点で使い回すパーツを意識します。使い回すパーツがBEM記法のBlock(起点)になるようにマークアップしていきます。

<header class="header">
  <div class="header__inner">
    <div class="header__logo">
      <h1 class="logo-header"><a href="/">ロゴ</a></h1>
    </div>
    <nav class="header__nav nav-header">
      <ul class="nav-header__list">
        <li class="nav-header__list-item">
          <a href="/news/" class="nav-header__link">お知らせ</a>
        </li>
        <li class="nav-header__list-item">
          <a href="/contact/" class="nav-header__link">お問い合わせ</a>
        </li>
      </ul>
    </nav>
    <div class="header__menu">
      <button class="button-menu">
        <span class="button-menu__icon"></span>
        メニュー
      </button>
    </div>
  </div>
</header>

<section class="news section">
  <div class="news__inner inner">
    <div class="news__heading">
      <h2 class="heading-section">お知らせ</h2>
    </div>
    <div class="news__articles">
      <a href="/article-01/" class="news__article article-news">
        <h3 class="article-news__title">お知らせタイトルが入ります。</h3>
        <p class="article-news__text">お知らせの抜粋が入ります。</p>
      </a>
    </div>
    <div class="news__more">
      <a href="/news/" class="button-primary">お知らせの一覧をみる</a>
    </div>
  </div>
</section>

参考サイト

「SEOに強いHTMLの書き方」についての個人的な見解

チェックツール

HTMLの品質チェックに以下のツールを使用します。

• The W3C Markup Validation Service
• Markuplint
• Chrome拡張機能 HeadingsMap

CSS(Sass)

Sass

Dart Sass、SCSS記法を使用します。
公式で非推奨とされているモジュールシステムは使用を控えます。

コンパイル環境

「gulp」または「VS CodeプラグインLive Sass Compiler」を使用します。

CSS設計

「FLOCSS」または「BEM」を使用します。

CSSファイルの出力

ファイル分割はSassで行い、CSSは1つにまとめて出力します。ページ特有のCSSファイルや、リセットCSSなどを分割しません。

.scssファイルの分割

BlockごとにBlock名.scssファイルを作成します。
ファイル数が増える、ファイル作成の手間が増えるなどのデメリットはありますが、得られる恩恵も大きいです。

• チーム開発の場合コンフリクトが減る
• 可読性の向上
• ブロック単位で管理するため、別プロジェクトへ再利用しやすい
• どこに何が書いてあるか探す手間が省ける
• クラス名の衝突を回避できる

ファイル構造

FLOCSSをベースに拡張したものを使用します。
GitHubはこちら

クラス名の命名規則

予測しやすいクラス名を付けます。

• btn → button
• tit → title
• head → heading

上下右左のような場所ではなく、要素の情報をクラス名にします。

例えば、navタグをheader__rightというクラス名にした場合を見ていきます。

<!-- ❌ NG -->
<header class="header">
  <h1 class="header__left">ロゴ</h1>
  <nav class="header__right">
    <ul>
      <li><a href="#">ニュース</a></li>
      <li><a href="#">お知らせ</a></li>
    </ul>
  </nav>
</header>

上記のコードは、何か要素を追加した際に意味が通じなくなる恐れがあります。
場合によってはheader__centerに書き換えが必要になります。

要素の情報をクラス名にすることで、「予測しやすい」「保守しやすい」コードになります。

<!-- ⭕️ OK -->
<header class="header">
  <h1 class="header__logo">ロゴ</h1>
  <nav class="header__menu">
    <ul>
      <li><a href="#">ニュース</a></li>
      <li><a href="#">お知らせ</a></li>
    </ul>
  </nav>
  <div class="header__tel">
    <a href="tel:03-1234-5678">03-1234-5678</a>
  </div>
</header>

〇〇__topや〇〇__bottomも同様の理由でなるべく使用しません。
また、上部を表すtopと、トップページを表すtopが混合すると、クラス名の予測が難しくなります。
クラス名を決める際には「上部をtop」「トップページをhome」で表すようにしています。

Block__Element–Modifyのルールで命名します。

FLOCSS、BEMの命名ルールに沿って命名します。
Blockの命名は役割-補足 で統一します。

• 例) ヘッダーボタン → c-button-header
• 例) セクション見出し → c-heading-section

主な役割には以下を使用します。

役割を先に持ってくることで、クラスの役割が直感的に理解できますし、名前順にソートされた時の可読性もよくなります。

使い回しを意識したCSS設計

使い回すパーツは、BEMの起点(block)になるように設計します。
blockには外側の余白を付けず、block__elementに外側の余白を付けます。

例えば以下の場合、c-heading p-item-news c-button には外側の余白を付けず、p-news__heading p-news__item p-news__button に外側の余白を付けます。
このようにすることで、外側に余白を持たない使い回しやすいblockになります。

<div class="p-news">
  <h2 class="p-news__heading c-heading">ニュース</h2>
  <div class="p-news__item p-item-news">
    <h3 class="p-item-news__title">ニュースのタイトル</h2>
    <p class="p-item-news__text">ニュースのテキスト</p>
  </div>
  <div class="p-news__item p-item-news">
    <h3 class="p-item-news__title">ニュースのタイトル</h2>
    <p class="p-item-news__text">ニュースのテキスト</p>
  </div>
  <div class="p-news__button">
    <a href="/news" class="c-button">ニュース一覧をみる</a>
  </div>
</div>

参考サイト

• 【暫定】コーダー歴3年で辿り着いた保守しやすいコーディング手法

チェックツール

CSS(Sass)の品質チェックに以下のツールを使用します。

• Stylelint
• W3C CSS 検証サービス

JavaScript

ライブラリの使用について

• なるべくライブラリは使用せず、素のJavaScriptを使用します。
• すでにjQueryが使用されているサイトではjQueryを使用します。
• スライダーUIのような複雑な機能はライブラリを使用します。
  • その際の選定基準として、アクセシビリティと軽さを重視しています。

変数について

可能な限りconst を使って定義します。
constでの定義を徹底していれば変数に関する問題はある程度回避できます。

• 意図しない書き換えによるエラーを防ぐことができる。
• 変数名がバッティングした際にエラーで知らせてくれる。

さらに、変数の使用範囲を限定して、グローバル汚染を防ぐアプローチをしています。

/**
 * アコーディオンの初期化
 */
const initAccordion = () => {
  const button = document.querySelector("#js-button-accordion");
  button?.addEventListener("click", () => {
    // アコーディオンの処理
  });
};

/**
 * ドロワーの初期化
 */
const initDrawer = () => {
  const button = document.querySelector("#js-button-hamburger");
  button?.addEventListener("click", () => {
    // ドロワーの処理
  });
};

関数を使ったモジュール化

各処理を名前付き関数でモジュール化しています。
即時関数でまとめる方法もありますが、名前付き関数の方が扱いやすいと考えています。

/**
 * viewport切り替えの初期化
 */
const initSwitchViewport = () => {};

/**
 * トップへ戻るボタンの初期化
 */
const initToTop = () => {};

/**
 * アコーディオンメニューの初期化
 */
const initAccordion = () => {};

// 関数の実行
initSwitchViewport();
initToTop();
initAccordion();

1関数1処理

例えばハンバーガーメニューという1つのUIでも、その中で複数の処理が必要な場合があります。
全ての処理を長々と書くと可読性が悪くなるため、1関数1処理でまとめるようにしています。

/**
 * ドロワーメニューの初期化
 */
const initDrawer = () => {
  /**
   * ドロワーのトグル処理
   */
  const toggleDrawer = () => {};

  /**
   * フォーカストラップ処理
   */
  const focusTrap = () => {};

  // 関数の実行
  toggleDrawer();
  focusTrap();
};

// 関数の実行
initDrawer();

ハードコーディングしない

名前付き関数にすることで、関数内で使用する値はある程度予測できますが、いきなり値が出てくると理解に苦労します。

// ❌ NG いきなり3.14という値が出てくると、何の値か理解しずらい
const calCircleArea = (radius) => {
  return radius * radius * 3.14;
}

できるだけ値のハードコーディングは避けます。

// ⭕️ OK 値の役割が分かりやすいい
const calCircleArea = (radius) => {
  const pai = 3.14
  return radius * radius * pai;
}

DOCコメントを書く

DOCコメントを書くことで、メンテやレビューする人の負担を減らします。

基本は関数にDOCコメントを残します。
理解が難しい変数にもDOCコメントを残します。

/**
 * 円の面積を計算する関数。
 * 
 * @param {number} radius - 円の半径。
 * @returns {number} 計算された円の面積。
 */
const calCircleArea = (radius) => {
  const pai = 3.14;
  return radius * radius * pai;
};

チェックツール

JavaScriptの品質チェックに以下のツールを使用します。

• Chrome コンソールタブ
• ES Lint

参考サイト

• 【JavaScript】読みやすいコードの書き方
• JavaScriptでJSDocコメントを書くメリットとは

WordPress

クラシックテーマ開発

現在はクラシックテーマでの開発にご対応しています。
テンプレートはPHPでハードコーディングし、更新が必要な機能に限りWordPressの機能を組み込んでいます。

• カスタムフィールド
• ブログやお知らせなどの投稿機能
  • 使用頻度の高いブロックの組み合わせは、パターンかプラグインを使ってカスタムブロックを作成しています。
• カスタム投稿タイプ
• 特定の要望に応じたカスタマイズ

WordPressコーディング規約

開発環境にPHPCodeSnifferを導入し、WordPressのコーディング規約を導入しています。

チェックツール

• WordPress コーディング規約
• phpcs
• phpcbf

レスポンシブコーディング

モバイルファースト、デスクトップファースト

PCとSPのデザインカンプが揃って支給されるされる場合にはモバイルファーストでコーディングします。

個人的にはどちらが優れているというのはあまり感じません。
display: flex; → display: block; の打ち消しが生じるという理由から、モバイルファーストが適してるという意見を目にしますが、flex-derectionの切り替えでさほど変わらない印象です。

// モバイルファースト
.card-box {
  display: flex;
  flex-direction: column;
  gap: 20px;

  @media (min-width: 768px) {
    flex-direction: row;
  }
}

// デスクトップファースト
.card-box {
  display: flex;
  flex-direction: row;
  gap: 20px;

  @media (max-width: 767px) {
    flex-direction: column;
  }
}

ブレイクポイント

ブレイクポイントはSassのマップ型変数で管理し、Bootstrapのブレイクポイントを参考にします。

// ブレイクポイントのサイズ定義
$breakpoint-size: (
  "sm": 576,
  "md": 768,
  "lg": 992,
  "xl": 1200,
  "xxl": 1400,
);

// ブレイクポイント (SP基準)
$breakpoints: (
  sm: "(min-width: #{map.get($breakpoint-size,'sm')}px)",
  md: "(min-width: #{map.get($breakpoint-size,'md')}px)",
  lg: "(min-width: #{map.get($breakpoint-size,'lg')}px)",
  xl: "(min-width: #{map.get($breakpoint-size,'xl')}px)",
  xxl: "(min-width: #{map.get($breakpoint-size,'xxl')}px)",
);

メディアクエリはmin-widthかmax-widthで統一します。双方から指定が必要な場合はnotを使用します。

$breakpoints: (
  sp: "not (min-width: 768px)",
  pc: "(min-width: 768px)",
);

デザインカンプにないブラウザ幅の対応

リキッドデザインでコーディングします。
リキッドデザインとは画面サイズに合わせてコンテンツが柔軟に調整されるデザインです。
その反対にソリッドデザインがありますが、ソリッドデザインはレイアウトが固定されたデザインのことで、画面サイズによって水平スクロールするのが特徴です。

対応ブラウザサイズ

320px〜1980pxで表示崩れがないか確認します。

ジャンプ率を意識したレスポンシブコーディング

よしなに対応する場合には、全体のジャンプ率を意識してコーディングします。

フォントサイズの可変やrem変換

font-sizeをremで指定する際には、htmlタグのfont-sizeに依存しない形で指定します。

pxをremに計算する方法

// rem計算
@function rem($font-size-px) {
  @return calc($font-size-px / 16 * 1rem);
}

h1 {
  font-size: rem(30);
}

中間サイズを可変にする方法

ジェネレーターやSassの関数を使って、要素に直接指定します。

p {
  font-size: 16px;

  @media (min-width: 768px) {
    font-size: clamp(18px, ブラウザ幅に応じた可変サイズ, 22px);
  }
}

ジェネレーター
https://min-max-calculator.9elements.com/

参考
https://zenn.dev/hilosiva/articles/e9ae1bee08bdfc

以下のような実装はあまり良い方法ではないと考えています。

• htmlタグのfont-size をvwで調整して、各要素をremで可変にする方法
• htmlタグのfont-size を62.5%にして、remの計算を容易にする方法

画像について

命名規則

ページ/役割_位置-詳細+番号_状態を基本の型とします。
※詳細はハイフンで繋いで複数指定できます。
※不要な項目は省略します。

例) contact/img_top-swiper1_sp.webp
お問い合わせページのトップスワイパー1枚目スマホ画像

例) common/icon_arrow-right-red.svg
共通の赤い右向き矢印アイコン

役割の命名

役割には以下を使用します。なるべく種類を絞って使用します。

役割を付けることで、altを書く際にも迷いを減らすことができます。

• bg と deco → 装飾のためalt不要
• logo と text → ロゴやテキストの文字をそのままaltに書く
• img → 「写真:〇〇」や「グラフ:〇〇」や「〇〇な様子」のように、画像の説明まで付ける。

画像の書き出しサイズと圧縮について

画像は全て2倍サイズで書き出し、圧縮とWebp変換を行います。

遅延読み込みとdecoding

様々な考え方があるかと思いますが、imgタグにはdecoding="async" を付けます。
また、遅延読み込みをするimgタグにはloading="lazy" を付けます。

レイアウトシフト対策

画像にはwidth属性とheight属性を書きます。
最終的なimgタグは以下のようになります。

<img src="パス" alt="代替えテキスト" width="300" height="300" loading="lazy" decoding="async">

レスポンシブ対応

PCとSPで比率や表示が異なる画像は picture タグを使って切り替えます。
画像サイズのみ切り替える場合はimgタグのsrcset属性を使用します。

サポートブラウザは限られますが、pictureタグにもwidth属性とheght属性を付けます。
サポートされていないことで、何か不具合が起きるものではありません。

<picture>
  <source media="(min-width: 768px)" srcset="./img/bg_top_pc.webp" width="1440" height="800">
  <img src="./img/bg_top_sp.webp" alt="代替えテキスト" width="375" height="700" loading="lazy" decoding="async">
</picture>

アクセシビリティーの取り組み

Code.Yuのホームページ制作では、JIS X 8341-3:2016 達成基準A を目指します。
コーディング代行業務では、指示された仕様やデザインを優先します。

カルーセルUIや動画埋め込みは自動再生しない。

原則自動再生では再生ボタンで動作を開始し、一時停止機能を実装します。

袋小路に陥らせないようにする

モーダルUIやドロワーUIが開いた状態で、元の画面に戻れなくならない配慮をします。
キーボード操作だけ閉じることができるかも確認します。

光の点滅などのアニメーションは避ける

ホバーアニメーションやスクロールアニメーションはコーダーがよしなに対応する場面も多いですが、光が点滅するアニメーションは避けます。

imgタグには代替えテキスト(alt)を適切に付与する

装飾画像

デザイン装飾やコンテンツとして意味を持たない画像はalt属性を空にします。

ロゴ画像

画像に書かれた文字をそのままalt属性とします。

テキスト画像

可能な限りテキストは画像化しないアプローチを行います。
やむをえず画像化する場合は、文字をそのままalt属性とします。

画像の種類を伝える

「〇〇の画像」「〇〇の写真」または、「画像:〇〇」「写真:〇〇」のように、画像の種類や状態を書きます。

図や表の画像について

図や表の意味が適切に伝わるようにaltを付与します。
alt="〇〇の表" のようにはしません。

<img src="path" alt="診療案内表:月曜から金曜、及び日曜は診療日で、土曜日は休診日です。診療時間は、前半の部が午前9時から正午まで、そして後半の部は午後1時から午後10時までとなります。">

複雑な表やグラフなどで、altの文字数があまりに多くなる場合にはaria-labelledbyを使ったアプローチも検討します。

<img src="path" alt="診療案内表" aria-labelledby="table-description">
<p id="table-description" class="u-hidden-visually">月曜から金曜、及び日曜は診療日で、土曜日は休診日です。診療時間は、前半の部が午前9時から正午まで、そして後半の部は午後1時から午後10時までとなります。</p>

キーボード操作でアクセスできるようにする

フォームの操作やドロワーメニューのオープンなど、すべてキーボード操作できるようにします。

• JavaScriptのクリックイベントのきっかけになるタグにはbutton タグを使用します。
• キーボード操作が無効になるため、チェックボックスやラジオボタンをdisplay: none; で消してスタイルの上書きをしません。要素本来の機能を損なわないアプローチをします。

操作に制限時間を設けない

操作に制限時間は設けません。

アイコンのみで情報を伝える場合

視覚的に認知できるユーザー以外も考慮します。
視覚的には要素を非表示にするユーティリティクラスを用意します。

.u-hidden-visually {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding: 0 !important;
  margin: -1px !important;
  overflow: hidden !important;
  clip: rect(0, 0, 0, 0) !important;
  white-space: nowrap !important;
  border: 0 !important;
}

3本線のアイコンのみでメニューを表す場合には、u-hidden-visuallyクラスを使って、メニューボタンであることを伝えます。

<button class="button-menu">
  <span class="button-menu__bar"></span>
  <span class="button-menu__bar"></span>
  <span class="button-menu__bar"></span>
  <span class="u-hidden-visually">メニュー</span>
</button>

もしくはaria-label を使って、メニューボタンであることを伝えます。

<button class="button-menu" aria-label="メニュー">
  <span class="button-menu__bar"></span>
  <span class="button-menu__bar"></span>
  <span class="button-menu__bar"></span>
</button>

スクリーンリーダーで読み上げた時に意味が通じるマークアップ

• 文字間のスペースはCSSで調整を行います。文字列のスペースで調整すると、ツールによっては別の意味で読み上げられます。
  • 場 所 「ばしょ」ではなく「ばところ」
  • 時 間 「じかん」ではなく「ときあいだ」

<!-- ❌ NG -->
<dl>
  <dt>場  所</dt>
  <dd>東京都</dd>
  <dt>時  間</dt>
  <dd>11:00</dd>
</dl>

マークアップの順番

ヘッダーやトップへ戻るボタンのようなposition: fixed;で固定する要素は、どの順番でマークアップしても視覚的には問題ありません。
ですが、フォーカス順や読み上げツールを考慮した適切な順番でマークアップします。

<!-- ❌ NG -->
<button>トップへ戻る</button>

<h2>お知らせ</h2>

<header>ヘッダー</header>

<h2>お問い合わせ</h2>

テキストの拡大縮小機能で読み取れる設計にする

ブラウザの画面拡大機能で文字サイズを変更できるようにします。

<meta name="viewport" content="width=device-width, initial-scale=1">

＊(アスタリスク)や※(米印)について

＊や※だけで特定の表現をしません。記号が意味する情報を伝えます。

<label>
  お名前*<span class="u-hidden-visually">必須項目</span>
  <input type="text">
</label>

<p>「*」は必須項目です。</p>
<label>
  お名前*
  <input type="text" required>
</label>

スムーススクロールについて

スムーススクロールはaタグ本来の動きを損なわないようにします。
prevendDefault()で無効にしてアニメーションする場合、カバーしなければいけない項目が多いです。

• フォーカス位置の考慮
• 読み上げツールの考慮
• デフォルトのクリックイベントとJavaScriptのクリックイベントの違いの吸収

上記を考慮して、aタグ本来の動きを損なわない実装をします。
細かいカスタマイズができないなどのデメリットはありますが、CSSでの実装が最適と考えています。

html {
  scroll-behavior: smooth;
}

参考サイト

• ウェブアクセシビリティ導入ガイドブック
• alt属性の良い事例(つけ方・書き方)｜情報バリアフリーポータルサイト
• JIS X 8341-3:2016 達成基準 早見表（レベルA & AA） | ウェブアクセシビリティ基盤委員会（WAIC）

チェックツール

品質チェックに以下のツールを使用します。

• 開発の補助に「Markuplint」を使用します。
• スコアの確認に、「みんなのアクセシビリティ評価ツール：miChecker (エムアイチェッカー)Ver.3.0」を使用します。

CoreWebVitalsに関する取り組み

CoreWebVitalsとは、Googleが発表したWebページ上でのユーザーエクスペリエンス（UX）を向上させるための重要な指標で、「LCP」「FID」「CLS」で評価されます。

• LCP : 最も大きな画像やテキストブロックのようなコンテンツが完全に読み込まれて画面に表示されるまでの時間を測定します。
• FID : ユーザーがページ上で何かの操作を試みたとき（例えばリンクをクリックするなど）に生じる遅延を測定します。
• CLS : ページのロード中やインタラクションの間に起こる予期せぬレイアウトの変更の程度を測定します。

要約すると「表示が素早く(LCP)、スムーズに操作でき(FID)、画面がガタガタしない(CLS)サイト」を表します。
CoreWebVitalsに関する取り組みとして、以下を行っています。

画像の圧縮とWebP変換

サイトの表示スピードにおいて最も重要な部分です。
画像を圧縮して、WebP形式に変換します。

適切な画像サイズを使用

必要以上に大きな画像を読み込まないようにします。
画像サイズのみ切り替える際はimgタグのsrcset属性を使用します。
アートディレクションが必要な場合は、pictureタグを使用します。

遅延読み込み

すぐに読み込む必要がない画像はloading="lazy" で遅延読み込みします。
imgタグだけではなく、iframeタグにも使用できます。

レイアウトシフト対策

imgタグにはwidthとheightを付けます。

外部ファイルはまとめる

CSSは1つにまとめて外部ファイルとして読み込みます。
ファイルの分割はSassで行います。

不要なライブラリやプラグインを見直す

jQueryや、その他ライブラリの使用を見直します。

フォントのサブセット化

サブセット化したフォントを、セルフホスティングして使用します。

CoreWebVitalsの計測ツール

サイト公開前にチェックを行うことが多いため、Lighthouseをチェックツールとして採用します。
PageSpeed Insightsもメジャーなチェックツールです。

CoreWebVitalsの計測環境について

Lighthouseのスコアは計測環境によってスコアが変動するため、以下の環境での計測を推奨しています。

• 本番環境
  • 実際の環境でパフォーマンスを計測できます。
• 本番環境と同じサーバーのステージング環境
  • 実際の環境に近い条件でパフォーマンスを計測できます。
    

開発中に上記環境をご用意できない場合には、当方エックスサーバーのステージング環境で計測します。ローカルホスト環境でのスコアは参考程度にとどめます。

まとめ

以上がCode.Yuのコーディング品質ガイドラインになります。
すべてのお客様に高品質なホームページをご提供するため、これからも品質向上に努めて参ります。