学生の宿題計画用モバイルアプリを作る方法

問題と対象を明確にする

宿題計画アプリが機能するのは、単に「もっと整理したい」という漠然とした欲求を満たすだけでなく、本当に解決すべき痛みを扱うときだけです。多くの学生にとって核心的な問題は努力不足ではなく、締切の見落とし、散在する課題情報、そして学校が忙しくなると崩れる** fragile なルーティン**の組み合わせです。

課題はあまりに多くの場所に散らばっています：教師のLMS、クラスチャット、紙の配布物、授業中に走り書きしたメモ、メール、あるいはそもそも作られなかったカレンダーのリマインダー。学生は多くの場合「後で追加するつもり」でも、そのワークフローは脆弱です。一度入力を怠ると遅延提出やストレス、常に遅れているという感覚に雪だるま式に繋がります。

最初は一つの対象を選び（そしてそのために作る）

v1では単一の主要ターゲットを選んでください。ここでは 高校生 を最初の対象にします。

高校生は良い出発点です：複数の授業と変動する締切がありながら、計画習慣はまだ発展途上です。彼らは携帯を頻繁に使う傾向があり、学生プランナーアプリが現在の方法より速ければ自然に使われます。

高校生向けニーズを満たせれば、後で中学生（保護者の関与が増える）や大学生（自律性が高く複雑な予定）へ拡張できます。しかし、早い段階で対象を混ぜると、肥大化して混乱する製品になりがちです。

「成功」を定義する（測定できるように）

機能の前に結果を定義してください。宿題追跡アプリの成功は測定可能であるべきです。例：

• 期限内提出の増加（例：週あたりの遅延提出が減る）
• 未着手タスクの減少（締切後まで手を付けない課題が減る）
• 計画行動の改善（学生が継続的にタスクを追加し、チェックオフし、計画を調整する）

これらの成果が、何を作るか、何を削るか、ローンチ後に何を改善すべきかの判断に役立ちます。

このガイドで扱うこと

次に、フォーカスされた 勉強スケジュールアプリ を作る実践的なステップを説明します：

• 学生向けのMVP（必須のみ）を明確化すること
• 実際の宿題習慣に合う 学生アプリのUX と画面設計
• データとアーキテクチャをシンプルかつ信頼できるものにすること
• 学生とのテスト、ローンチ、オンボーディング、長期的なエンゲージメント構築

目標：時間を節約し、見落としを減らすため、学生が継続して使う小さな使いやすいv1を作ること。

ユーザーリサーチ：学生が本当に必要としていること

何を作るか決める前に、誰のために作っているか、通常の週に宿題計画がどのように起きるかを明確にしてください。ここで少し構造化されたリサーチを行えば、学生が使わない機能を作る何ヶ月分もの無駄を省けます。

決定を支える2〜3の主要ペルソナ

プロダクト議論で常に参照できるシンプルなペルソナから始めてください。トレードオフを判断するのに十分具体的に保ちます。

• 学生（主要ユーザー）: 複数の授業、課外活動、教師ごとの運用を抱える。速い入力（「後で追加」はたいてい「永遠に追加されない」）を必要とし、うるさくないリマインダーと、遅れが出たときに適応する計画を求める。
• 保護者/ガーディアン（副次ユーザー）: 管理しすぎずに可視化を望む。未提出、今後の締切、学生が軌道に乗っているかを気にする。
• 教師/チューター（早期の任意ペルソナ）: 何が出され、いつまでで、学生が要件を理解しているかを重視する。新しいツールを採用するのは、混乱を減らす場合に限られることが多い。

週次のシンプルなジャーニーをマップする（課題から提出まで）

「典型的な週」をスケッチして、アプリが摩擦を減らせる箇所をマークしてください：

1. 課題の入手: 授業中の発表、LMSへの投稿、黒板、口頭での伝達など
2. 計画: いつやるかを決める（あるいは決めない）、他の締切と照らし合わせ、所要時間を見積もる
3. 実行: 短い作業で進める。コンテキストを頻繁に切り替える
4. 提出: ファイルのアップロード、紙の提出、発表。多くのタスクがここで失敗する

このジャーニーは、重要な瞬間を特定するのに役立ちます：素早い記録、現実的なスケジューリング、そして「完了」と「提出」の明確な区別。

実際のインプットを集める（短いインタビュー／アンケート10件）

10件の短い会話を、学年や成績の異なる学生から集めることを目標にしてください。軽めに：各回10〜15分、または数問の自由回答を含む短いアンケートで十分です。

良い質問例：

• 「宿題はどうやって把握していますか？」
• 「最後に逃した課題は何で、なぜですか？」
• 「週の計画はしていますか？その計画はどこにありますか？」
• 「リマインダーがうるさくなく役立つには何が必要ですか？」

繰り返し出るパターンや学生が使う正確なフレーズを探してください。その言葉がUIラベルのベストな候補になることが多いです。

制約を早めに特定する（方針、アクセス、オフライン）

学生向けアプリは現実の制約の中で動きます。これらを機能化する前に検証してください。

• 学校の方針: 授業での携帯利用、通知の制限、未成年のデータ収集に関するルール
• 端末アクセス: 端末を共有している学生、携帯／タブレットを行き来する学生、ストレージ制限のある学生
• オフライン要件: 通学中のバス、断続的な校内Wi‑Fi、制限されたネットワークは“常時オンライン”前提を壊す

これらの制約をリサーチノートに文書化してください。サインイン、同期、リマインダー周りのMVP設計に直接影響します。

MVP機能の定義（必須のみ）

学生プランナーのMVPは学生が素早く三つの質問に答えられるようにするべきです：何をやるべきか？いつが締切か？次に何をすべきか？ それ以外は二次的です。

1) 速く更新できる宿題リスト

まずはシンプルな宿題追跡のコア：締切日、科目、ステータスを持つ課題一覧。ステータスは最小限に—to do / doing / done—更新が2タップで済むなら学生は使います。

「締切間近」「遅延」などの軽いソートやフィルタを入れても良いですが、v1で複雑なタグシステムは避けてください。

2) カレンダー＋授業スケジュールを一体化

勉強スケジュールアプリにはリストだけでなく時間の見方が必要です。提供すべきは：

• 週ビュー（週の計画）
• アジェンダビュー（次に何かを確認する用）

学生が基本的な授業スケジュール（日付、時間、授業名）を追加できるようにし、カレンダー上に授業と締切日を両方表示して脳内で結合する必要がないようにします。

3) 締切を防ぐリマインダー

リマインダーは信頼できて分かりやすく：

• 時間ベースのリマインダー（例：今日の18:00）
• デフォルトで 締切前日 に1件のリマインダー

まずはスマートなデフォルトを用意し、編集を可能にする程度にとどめてください。

4) 実際の学校生活に合うクイックキャプチャ

言葉や紙で渡される課題が多いので、素早く入力できるフローをサポートしてください：

• 課題の写真／スキャン
• 手動入力（タイトル＋締切）

写真は学生が全てをすぐに打ち込まなくても安全網として機能します。

5) 基本的な分析（任意）

分析は責め立てるのではなく動機付けに使う：連続達成（streak） や 週間概要（「今週5件完了」）など。気を散らさないようにオプションにしておくのが良いです。

境界を明確にする：v1で何をスキップするか

v1を「完全な学校プラットフォーム」にしないことが最短の成功法です。境界が製品を明確にし、セットアップを簡単にし、初回体験を一つの仕事（宿題を記録し、何が締切かを見て、適切な時間にリマインドされる）に集中させます。

意図的に後回しにする良い機能

価値はあるが初回リリースでは必須でないもの：

• AI提案（自動学習計画、タスク書き換え、負荷予測）
• スマート優先度システム（スコアやラベル、「最適な順番」エンジン）
• コラボレーション機能（共有タスクリスト、グループプロジェクト、クラスチャット）
• ウィジェットや深いカスタマイズ（ホーム画面ウィジェット、テーマ、カスタムビュー）

早すぎる追加は余分な画面、設定、エッジケースを生み、コアワークフローが愛されるか検証できる前に複雑さだけを増やします。

注意すべき一般的なリスク

機能増大は開発を遅らせるだけでなく学生を混乱させます：

• 機能過多: ボタンやモードが多すぎる（「タスク」「課題」「イベント」「セッション」など）
• 複雑なセットアップ: 初日から学校情報、授業、学期、教師メールを要求する
• 通知過多: 学生は通知を無効にするかアンインストールしてしまう

シンプルな判断ルール

機能を追加するのは、瞬時に宿題を記録 → 次に何をするか理解 → 期限内に終わらせる というコアフローを直接支援する場合のみです。

パワーユーザー向けか多くの設定が必要な機能は、たいていv1には不要です。

フェーズ計画と明確な目標

• MVP: 学生が宿題と締切を確実に追跡できることを証明する
• v1: 便利さを向上（QOL改善）するが複雑さは増やさない
• v2: リテンションと習慣が強固になったら高度な価値（AI、コラボ、ウィジェット）を追加

アプリ構造と主要画面の計画

学生プランナーは構造で成功・失敗が決まります。学生が数秒で今日の宿題を見つけられないなら、どれだけ機能があっても定着しません。学校の実際の仕組みに合ったシンプルな情報設計から始めてください。

学校の実態に合わせたシンプルな情報構造

一案としては：

授業 → 課題 → カレンダー → 設定

授業は学生が既に理解している「コンテナ」（数学、英語、生物）。課題は授業の中に存在し、カレンダーは跨授業の視点で「何がいつ締切か」を答えます。設定はv1では最小限に—アプリを使うのに必要なものだけにしてください。

実装前にスケッチすべき主要画面

コードを書く前に以下の画面をスケッチし、フローを通して検証してください：

• オンボーディング: 授業を追加、週の開始日設定、価値が見えた後に通知許可を求める
• 課題追加: 授業、タイトル、締切日、任意の「種類」（宿題/テスト/プロジェクト）、簡単なメモ欄
• タスクリスト: 「今日 / 近日 / 遅延」ビューと授業でのフィルタ
• カレンダー: 期日が見える月/週ビューと、詳細へジャンプするタップ
• リマインダー: リマインダー時間、スヌーズ、明確な「完了にマーク」操作

入力を速くする（学生は忙しい）

最速のアプリが勝ちます。入力と意思決定の負荷を減らすために：

• デフォルト値（例：締切時間を放課後に設定）
• テンプレート（「リーディング」「ワークシート」「テスト勉強」などの共通課題）
• 毎週繰り返し（例：毎週金曜のスペリングクイズ）

一貫した「クイック追加」ボタンを設け、最後に使った授業をプリセレクトするのが良いです。

早い段階で取り入れるアクセシビリティの基本

アクセシビリティは後付けより構造に組み込む方が簡単です：

• 読みやすいフォントサイズ（小さな二次テキストは避ける）
• 高い色コントラスト（状態表示を色だけに頼らない）
• 簡潔で直接的な言葉（「締切は明日」が「今後の提出物」よりわかりやすい）

この構造が正しければ、通知、カレンダー連携、保護者/教師機能なども後から壊さずに追加できます。

宿題・計画に有効なUXパターン

宿題プランナーが成功するのは、「古いやり方より速い」と感じさせるときです。最高のUXは入力を減らし、意思決定を減らし、学生に明確な次の一手を示します—ただし不安を煽るダッシュボードにしてはいけません。

15秒以内で課題を追加する

「追加」フローをクイックキャプチャとしてデザインし、フォーム感を排してくだいさい。デフォルト画面は本当に必要なものだけを尋ね、後で詳細を編集できるようにします。

実用的なパターンは 一つの主要フィールド＋スマートデフォルト：

• 何をするか？（タイトル）
• 最近の入力から授業を自動提案
• デフォルトの締切を「明日」または次の登校日に（ワンタップで編集可能）

チップやタップで選べるオプション（Math、English、Essayなど）を使い、入力は任意にします。音声入力をサポートする場合は「Math worksheet due Thursday」のようなショートカット扱いにしてください。

ストレスの少ない優先度表示

全てが緊急に見えるとプランナーは放棄されます。複雑な優先度マトリクスの代わりに親しみやすい低負荷のラベルを使ってください：

• 今日
• 今週
• 後で

これらはワンタップで切り替えられるようにし、赤い「遅延」を乱発しないでください。微妙な「要注意」状態の方が常時アラートより効果的なことが多いです。

小さなUX改善：推奨のフォーカス項目（「始める：歴史ノート（10分）」）を一つ表示し、簡単に無視できるようにする。

進捗の見える化：罪悪感を与えない小さな勝利

宿題は反復的なので、UIは達成感を穏やかに与えるべきです。シンプルなパターンが最良：

• チェックマークと控えめなアニメーション
• 日次でリセットされる「今日の完了数」
• 何が終わり、何が先送りになったかを示す週間レビュー

週間ビューは反省のためのものであり、評価する場にしないこと：「3件を翌週へ移動しました」は「3件締切を逃しました」より前向きです。

通知：少なく、賢く、ユーザーが制御

通知は驚きを防ぐためのものであり、雑音になってはいけません。最小限のデフォルトを提供し、追加はユーザーに任せましょう。

良いパターン：

• 選べる時間での1日ダイジェスト（「今日2件、明日1件」）
• 当日用のジャストインタイム通知
• スヌーズ（30分、2時間、今夜）

グローバル設定と課題ごとの上書き設定を分かりやすい言葉で提供してください（「前日の夜に通知」など）。カレンダー連携を後で追加する場合は任意にして、学生がスケジュールに縛られないように配慮します。

データとアーキテクチャ：シンプルで信頼できることを優先

宿題プランナーは信頼が命です：タスクが消えたり、リマインダーが遅れたり、ログインが分かりにくいと学生はすぐ離れます。アーキテクチャは巧妙さより信頼性を優先してください。

認証：摩擦を減らす

サインイン経路は一つを主とし、他を任意にします。

• メール登録は普遍的だが、パスワードリセットはサポート負担になる
• Google / Apple サインインは学生にとってスムーズでパスワード問題を減らすことが多い
• ゲストモードは「試してからコミット」するのに有効。ただしアンインストールでデータが消える旨を明確に

実用的なアプローチはGoogle/Apple + メールを主にし、オンボーディング離脱が目立つならゲストモードを追加することです。

コアデータモデルは地味で良い

複雑なスキーマは不要です。一文で説明できる小さなエンティティ群から始めましょう：

• ユーザー（設定、タイムゾーン、通知設定）
• 授業（名前、教師ラベル、スケジュール色）
• 課題（タイトル、ノート、ステータス、締切日）
• リマインダー（時間、配信方法）
• 添付ファイル（写真／PDFリンク、任意）

課題は授業無しでも存在できるように設計してください（学生は個人的タスクも追跡したいことがある）。

同期戦略：実際の利用に合わせる

• オフラインファースト: Wi‑Fiが不安定な場合に最適。ローカルに保存し、可能なときにバックグラウンドで同期
• クラウドファースト: ほとんど常時オンラインでクロスデバイスアクセスが重要ならシンプル

不確かな場合はハイブリッドが多くのケースで機能します：瞬時の使用のためローカルに保存し、クラウドでバックアップ。

管理とサポート：基本を早めに計画

v1でもクラッシュ/エラー報告、アカウント削除対応、不審な活動のフラグなどの基本はあると良いです。ツールは最小限にしても、全くないのは避けてください。

学生アプリの技術選択

技術選択は製品の最小版（速い記録、確実なリマインダー、壊れないスケジュール）を支えるべきです。最良のスタックとは、チームが出荷・維持できるスタックです。

ネイティブ vs クロスプラットフォーム（iOS/Android）

ネイティブ（iOSはSwift、AndroidはKotlin）は滑らかな性能とプラットフォーム固有機能の利用に有利。トレードオフは「二重に作る」必要があること。

クロスプラットフォーム（Flutter、React Native）はiOS/Androidでコードを共有でき、v1の時間とコストを削減できる。トレードオフは各プラットフォームの自然な挙動に合わせるための追加工数やデバイス統合のエッジケース。

両プラットフォームを最初からターゲットにし小規模チームなら、クロスプラットフォームが実用的な出発点です。

バックエンド：マネージド vs カスタムAPI

マネージドバックエンド（Firebase、Supabase）はユーザーアカウント、DB、ストレージが既に用意されているためローンチが早い。MVPに適していることが多いです。

カスタムAPI（独自サーバ＋DB）は制御性（データモデル、特別ルール、学校システムとの連携）を提供しますが、時間と保守コストがかかります。

もしカスタムを短期間で試したければ、Koder.aiのようなコード生成支援でベースを作り、実際の学生テストを経てからエクスポートして継続開発する手もあります。

学生をうるさくしないプッシュ通知

プッシュ通知は以下を要します：

• デバイスでの許可
• 通知を送るサービス（通常バックエンド経由）
• タイミングとルールの慎重な設計

スパム防止のため、イベントベース（締切間近、遅延、スケジュール変更）にし、静かな時間帯（quiet hours）を許可し、簡単なコントロール（「1時間前に知らせる」など）を提供してください。

写真／添付：ストレージ計画を早めに

宿題には写真（ワークシート、黒板、教科書ページ）が頻繁に含まれます。決めるべきは：

• 許可ファイル種類とサイズ上限
• 画像圧縮の可否
• 添付ファイルの保存期間

ストレージはコストドライバーになり得るので、制限やオプションのクリーンアップポリシーを初日から検討してください。

プライバシー、安全性、信頼の配慮

学生（と保護者、教師、学校）は、プランナーが安全に感じられなければ使い続けません。プライバシーは単なる法的要件ではなくプロダクト機能です。信頼を得る最も簡単な方法は、収集を最小限にし、分かりやすく説明し、驚きを避けることです。

学生データを最小限に（分かりやすく伝える）

アプリを有用にするために絶対必要なものだけを最初に列挙してください：宿題タイトル、締切日、授業名、リマインダー設定。その他は任意にします。誕生日や連絡先、正確な位置情報、フルネームが不要なら聞かないでください。

アプリ内に短い「保存するデータ」説明をオンボーディング時に入れておくと混乱を防げます。

権限の取り扱いに注意

権限は信頼を失う最速の経路です。必要なときにのみ要求し、理由を説明してください。

例：

• カメラ/写真: 課題に写真を添付する場合のみ要求
• 写真を全部読み取るような広範なアクセスは避け、選択してアップロードできれば十分

権限なしでも機能できるなら（例：手動入力でカレンダー読み取りを避ける）それがv1の良い選択です。

アカウントの安全性（過剰設計は不要）

MVPでも基本はカバーしましょう：

• パスワードルール: 合理的（長さ＋一般的なパスワードチェック）にして複雑すぎる要求は避ける
• セッションタイムアウト: 共有端末での利用を考え、ログアウトを分かりやすく
• 基本的なレート制限: ログインやリセットエンドポイントのブルートフォース防止

Sign in with Apple/Google のような低摩擦オプションは、パスワード管理負担を減らすのに有効です。

準拠すべき法規：対象年齢と地域を確認

対象とする年齢と地域によって規則が異なります。ローンチ前に確認してください：

• COPPA（米国の13歳未満の子ども）
• FERPA（米国の教育記録、学校と連携する場合に関係）
• GDPR/UK GDPR（EU/UKのユーザー、同意とデータ権利）

将来的に保護者/教師機能を追加するなら、データの所有権（誰が何を見られるか、誰が誰を招待できるか、同意の記録方法）を早めに設計しておくと後での手戻りを減らせます。

開発計画：プロトタイプから最初の動くバージョンまで

宿題プランナーは基本が「簡単である」ことが重要：素早く追加でき、何が締切かが分かり、適切な時間にリマインドされること。最も安全な到達法は、コードを書く前にフローを検証し、小さなテスト可能なステップで作ることです。

まずプロトタイプ（コード前）

クリックできるモック（Figma、Sketch、またはリンク付き紙でも可）から始め、コアのジャーニーだけテストします：

• 30秒以内に宿題を追加できるか
• 今日と今週の締切が見つかるか
• 作業を完了にして取り消し（Undo）が使えるか

5〜8人の学生で素早くセッションを回してください。躊躇があれば、それが次のデザイン変更の兆候です—安価に直せます。

小さな反復で構築する

薄いが動くスライスを出荷し、順次拡張します：

1. 宿題リスト: タイトル、締切、授業、ステータス（open/done）

2. カレンダービュー: リストを反映する週ビュー（複雑なスケジューリングは後回し）

3. リマインダー: 基本的なプッシュ通知（前日の夜＋当日の朝など）

4. 添付: 課題の写真、配布物、リンク

各ステップは単体で使えるべきで、途中半端な機能の約束に終わらないようにします。

Koder.aiのようなツールを使えば、チャットで素早く薄いスライスを作り、スナップショットやロールバックで変更を管理し、MVPフローが検証できたらソースコードをエクスポートすることも可能です。

v1の品質チェックリスト

追加機能の前に確認すべきこと：

• 主要デバイスと古いOSでクラッシュしないこと
• 宿題リストの読み込みが速いこと（学生は授業間に確認する）
• 明確な空状態（「まだ宿題はありません—最初のタスクを追加しましょう」）とエラー状態

進捗の短いマイルストーンで管理

1〜2週間単位の短いマイルストーンと週次レビューで：

• 何を出荷したか？
• 学生はどこで困ったか？
• 新機能を追加する前に何を直すべきか？

このリズムが、要望リストではなく実際の学生の行動に基づいてフォーカスを維持します。

学生とのテストと、正しい問題の修正

宿題プランナーのテストは「好きかどうか」を聞くことではなく、学生が助けなしに本当のタスクを速く完了できるか、ルーティンを壊すミスをしないかを観察することです。

小規模で現実的なセッションを実施（15–30人）

学年、スケジュール、端末の混合を募ります。各学生に10–15分与え、4つのコアアクションをやってもらいます：

• アプリのセットアップ（初回起動、権限、基本設定）
• いくつかの課題を追加（締切、科目、メモあり）
• 次に何が締切かを見つける（今日／明日／今週）
• リマインダーをオンにして理解する

機能の説明はテスト中にしないでください。学生が「これは何？」と聞いたら、それはUIの明瞭性の問題だと記録します。

シンプルな数字で使いやすさを測る

ビルド間で比較できる指標を追跡します：

• 課題追加にかかった時間（開始：タップ“追加” → 終了：保存完了）
• 失われたステップ（締切を忘れる、保存ボタンに気づかない等）
• 混乱ポイント（一時停止、やり直し、繰り返しタップした箇所）

数値に短いメモ（例：「‘締切’は授業開始時刻と思われた」）を組み合わせると、何を改名・再配置・単純化すべきかが分かります。

エッジケースを見逃さない

学生のスケジュールは雑多です。テストしておくべきは：

• 異なるタイムゾーン（留学、旅行、端末設定）
• 夏時間の変更（リマインダーが1時間ずれる問題）
• 週次繰り返しやローテーションスケジュール（毎週の小テストなど）

バグの優先順位付け

修正は以下の順で行ってください：

1. クラッシュ、フリーズ、ログイン問題
2. データの消失や同期問題（信頼を失わせるもの）
3. リマインダーの失敗（遅延や欠落）
4. UXの問題（文言、ボタン配置、余分なタップ）

動きにくいフローは後で改善できますが、失われた宿題データは許されません。

ローンチ、オンボーディング、長期的な定着

良いプランナーでも最初の5分が混乱すると失敗します。ローンチとオンボーディングはマーケティング作業ではなくプロダクト機能と考えてください。

ストア用の要点（実際にダウンロードに効くもの）

ストアページは「何をするか」「誰向けか」「見た目」を素早く答えるべきです。

• スクリーンショット: 今日ビュー、課題追加、週ビュー、リマインダー設定、日程変更の画面を4–6枚見せる
• 説明文: 「締切を逃さない」といった成果を先頭に置き、機能リストは短めに
• シンプルなプライバシー要約: 収集するデータ、理由、削除方法を平易な言葉で（売却しないならその旨も）

コンバージョンするオンボーディング

オンボーディングは学生にすぐに「勝ち」を見せるべきです：自分の週と1つの差し迫った締切が見えること。

• スケジュールのインポート（カレンダーインポートやテンプレート）を提案し、だが「今はスキップ」オプションを必ず用意
• 最初に授業を追加し、次に最初の課題を追加させる
• 成功を確認したら明確な次の提案：「前日の夜にリマインドしますか？」

しつこくない定着施策

複雑さより一貫性が重要。習慣化には小さな後押しを：

• 週間計画のリマインド（日曜夜または月曜朝）：「今週の締切は？」
• タスクが2回スヌーズされたら頻度を下げるか再スケジュールを提案する優しい適応
• 簡単なリスケジュール: ワンタップで締切を移動、理由を素早く選べる（「教師が延期」「未着手」など）

v1以降の次の一手

価格モデル（無料＋プレミアム、学校ライセンス等）を早めに決め、透明にしてください—参考は /pricing。

サポートの準備も早めに（FAQ、バグ報告フォーム、応答時間）。アプリ内フィードバックボタンと /contact を用意しておくと良いです。