社内向け知識検証ウェブアプリの作り方

目標と検証基準を明確にする

画面設計や技術選定を始める前に、何を証明したいのかを正確に定めます。「社内知識検証」は組織ごとに意味が大きく異なるため、ここが曖昧だと後工程で手戻りが発生します。

「検証済み知識」の定義

各トピックで受け入れられる証拠を明文化します：

• クイズ合格（例：80%以上、再試行回数制限、必須問題）
• 証拠提出（例：アップロードしたスクリーンショット、チケットリンク、録音、チェックリスト）
• マネージャー／SME の承認（例：高リスク手順は承認必須）

多くのチームはハイブリッドを採用します：基礎理解をクイズで確認し、実務能力は証拠や承認で補う形です。

対象チームとユースケースの絞り込み

最初のリリースは対象を1〜2の聴衆とシナリオに絞って集中させます。一般的な出発点はオンボーディング、新しいSOPの展開、コンプライアンスの確証、製品やサポートのトレーニングなどです。

ユースケースによって厳格さが変わります（例：コンプライアンスはオンボーディングより強い監査証跡を求めることが多い）。

測定可能な成果を設定する

初日から追える成功指標を定義します：

• 新入社員や新しい役割の検証完了までの時間
• モジュール別・チーム別の合格率と再試行率
• 監査準備度：誰がいつどのバージョンで検証したかを証明できること

v1 の範囲と後追い機能を決める

まだ作らないものを明示します。例：モバイルファーストUX、ライブ監視（proctoring）、適応テスト、詳細な分析、複雑な認定パス。

範囲を絞ったv1は早期導入と明確なフィードバックにつながります。

制約と不可欠要件を列挙する

タイムライン、予算、データ感度、必要な監査証跡（保持期間、不変ログ、承認記録）を記録します。これらは後のワークフローとセキュリティ判断を左右するため、早めに関係者の合意を取りましょう。

ユーザー、ロール、アクセスルールを定義する

問題作成やワークフロー構築の前に、誰がシステムを使い何ができるかを決めます。明確なロールは「なぜ見えないのか」「なぜ編集できるのか」といった混乱を減らし、セキュリティリスクを抑えます。

コアユーザーグループ

ほとんどの社内知識検証アプリは次の5つの対象を必要とします：

• 学習者（Learners）：学習項目や検証を完了する従業員
• レビュアー／承認者：証拠を検証し承認するマネージャーやSME
• 作成者（Authors）：質問作成やチェックリスト、学習コンテンツの維持を行う人
• 管理者（Admins）：ユーザー、ポリシー、組織構造を管理する運用担当
• 監査人（Auditors）：読み取り専用の見える化とエクスポートが必要なコンプライアンス／品質担当

権限は明示的に

職名だけでなく機能レベルで権限をマッピングします。典型的な例：

• 割り当てられたコンテンツの閲覧／任意コンテンツの閲覧
• クイズ／アセスメントの受験；再試行可否（回数制限）
• 証拠のアップロード（ファイル／リンク／メモ）；提出物の編集や削除
• 証拠のレビュー；承認／却下；差し戻し要求；レビュアーノートの追加
• 問題作成／編集／公開；問題バンクの管理；項目の廃止
• ユーザー、チーム、ロール、割当ルール、期限の管理

組織における「検証」の意味を決める

検証は個人ベース、チームベース、または役割ベースにでき、役割ベースで個々の完了を追う運用が多く採られます。

契約社員や一時スタッフの扱い

非正規メンバーは初期設定を厳しめにします：期間限定アクセス、割当の可視性を限定、自動無効化の設定など。

監査人のアクセスとエクスポート

監査人には通常、結果・承認・証拠履歴への読み取り専用アクセスと、CSV/PDF等の制御されたエクスポート権を与え、機微な添付ファイルの部分マスキング機能を用意します。

ナレッジコンテンツモデルを設計する

クイズやワークフローを作る前に、アプリ内で「知識」がどう表現されるかを決めます。明確なコンテンツモデルは作成の一貫性を保ち、報告を有意義にし、ポリシー変更時の混乱を防ぎます。

ナレッジユニットから始める

検証する最小単位を定義します。多くの組織では次のような単位です：

• ポリシー（例：データ取り扱い、反贈収賄）
• 手順（ステップバイステップの運用手順）
• 製品モジュール（機能、ポジショニング、トラブルシューティング）
• 安全ルール（現場固有または役割固有の要件）

各ユニットは一意ID、タイトル、短い要約、適用範囲を持つべきです。

実運用を支えるメタデータを追加する

メタデータは二次的なものではなく主要なコンテンツとして扱います。シンプルなタグ付け例：

• 部署（営業、サポート、オペレーション）
• 役割（チームリード、技術者、マネージャー）
• リスクレベル（低／中／高）
• バージョン（ある時点で何が正しかったかを証明するため）
• オーナー（精度に責任を持つ個人またはチーム）

これにより適切な割当、問題バンクのフィルタ、監査向けのレポート作成が容易になります。

バージョン管理の計画（特にポリシー変更時）

更新時の挙動を決めます。一般的なパターン：

• マイナー編集： 意味を変えない誤字訂正。バージョンは据え置きで強制再検証なし。
• メジャー更新： 意味が変わる場合。バージョンを上げ、影響範囲の再検証を起動。

質問とバージョンの関連付けも決めます。コンプライアンス重視の領域では、質問を特定のユニットバージョンに結びつけておくと、過去の合否判断を説明しやすくなります。

保持ルールを早めに決める

保持方針はプライバシー・コスト・監査準備に影響します。HR／コンプライアンスと合意して、次を決めておきます：

• 試行データやスコアの保持期間
• アップロードされた証拠（ドキュメント、スクショ）の保持期間
• 承認やレビューノートの保持期間

実務的なアプローチは要約結果は長く保持し、元の生データ（証拠）は短くするなど、別々のタイムラインを設定することです。

所有権とレビュー間隔を設定する

各ユニットに責任者と定期的なレビュー周期（高リスクは四半期、製品概要は年次など）を割り当てます。管理画面に「次回レビュー日」を表示して古いコンテンツが埋もれないようにします。

評価フォーマットと問題タイプを選ぶ

どの評価フォーマットを採用するかで、検証の信頼性が変わります。単純なクイズ以上の混成を目指し、速いチェック（想起）と証拠ベースのタスク（実務）を組み合わせます。

コアな問題タイプ（用途別）

選択問題（Multiple choice） は一貫した採点と広範囲のカバーに最適。ポリシーの詳細や製品の事実確認に使います。

真偽（True/false） は短いチェックに向くが当てずっぽうが生まれやすい。低リスク項目やウォームアップに限定します。

短答（Short answer） は正確な語句が重要な場合に有効（システム名やコマンド、フィールド名など）。期待する解答を明確に定義するか、機械採点ではなく「要レビュー」と扱います。

シナリオ型問題 は判断力を検証します。現実的な状況（顧客クレーム、セキュリティインシデント、エッジケース）を提示して最適な対応を問います。記憶中心のチェックより納得感が高いことが多いです。

「証拠必須」オプションを追加する

証拠が「クリックしただけ」と「実際にできる」とを分けます。問題単位やアセスメント単位で証拠添付を必須にすることを検討：

• スクリーンショット（正しい設定の例）
• ファイルアップロード（レポート、エクスポートログ、テンプレート）
• チケットやドキュメント、PRへのリンク
• 必須ステップを含むチェックリストの確認

証拠ベースの項目は手動レビューが必要なことが多いので、UIとレポーティングで明示します。

ルール：プール、ランダム化、制限時間

回答の共有を減らすために 問題プール（30問から10問抽出）や ランダム化（問題順や選択肢のシャッフル）をサポートします。ランダム化が意味を壊さないよう注意（例：「以上のすべて」等）。

制限時間は任意です。共同作業を減らせますがストレスやアクセシビリティ面の問題にもなるため、速度が職務要件である場合に限定してください。

回数、再試行、学習支援

ルールを明確にします：

• 受験回数の上限（例：3回）
• 再試行の間隔（例：24時間）
• 必須の補習ステップ（必読資料、ミニトレーニング、上司とのチェックイン）

これにより公平性を保ち「運試しで合格する」を防げます。

明確で公正な問題作成のガイドライン

トリック表現、二重否定、意地悪な選択肢を避けます。1問1アイデアで、難易度は実際の役割に合わせ、誤答選択肢はもっともらしくも明確に誤りにすること。

繰り返し混乱を招く問題はコンテンツバグとして修正し、学習者を責めないでください。

検証ワークフローをマップする（クイズ、証拠、承認）

知識検証アプリはワークフローの明瞭さが成功の鍵です。画面を作る前にエンドツーエンドの「ハッピーパス」と例外処理を文書化します：誰が何をいつ行い、「完了」とは何か。

エンドツーエンドのフローを定義する

一般的なワークフロー：

assign → learn → attempt quiz → submit evidence → review → approve/deny

各ステップの入出条件を明確にします。例えば「Attempt quiz」は学習者が所定のポリシーに同意した後にのみアンロックする、など。「Submit evidence」はファイルアップロード、チケットや短い所感のリンクを受け付ける、といった具体性が必要です。

レビューのSLAとエスカレーション

レビューのSLA（例：「3営業日以内にレビュー」）を設定し、プライマリレビュアー不在時の処理を決めます。

エスカレーションパスの例：

• マネージャー不在ならX日後に代理へ自動再割当
• 代理不在なら機能承認者グループへルーティング
• SLAを破るとレビュアーと学習者へ通知、その後管理者キューへエスカレーション

承認基準と標準化された結果

承認はチーム横断で一貫性が必要です。レビュアー用の短いチェックリスト（証拠が何を示すべきか）と、固定の却下理由セット（証拠欠落、不適切なプロセス、古いバージョン、不十分な詳細）を作ります。

標準化された却下理由はフィードバックを明確にし、レポーティングにも有用です。

部分完了ルール

部分完了をどう表現するか決めます。実用的なモデルは別々のステータス：

• クイズ：未開始／合格／不合格
• 証拠：未提出／提出済み／差し戻し要求／承認

こうすることで「クイズは合格したが証拠が未承認で保留」などの状態を表現できます。

不変の監査トレイル

コンプライアンスや異議申し立てに備え、追加のみ（append-only）の監査ログを保存します：割当、開始、提出、採点、証拠アップロード、レビュアー決定、再割当、上書きなど。誰が行ったか、タイムスタンプ、使用したコンテンツ／基準のバージョンを記録します。

学習者向けの体験とUIを計画する

学習者画面の出来不出来がアプリの成否を分けます。何を期待されているか、どう完了するか、次に何が起きるかが即座にわからないと、未完了やサポートチケット、結果への不信につながります。

"学習者ホーム"は3つの問いに答えるようにする

ホームページは学習者がすぐにわかるようにします：

• 何が割り当てられているか：カテゴリ別（安全、製品、セキュリティ）にグループ化
• いつ期限か：明確な期限、カウントダウン、期限超過表示
• 自分の状況：検証ごとの進捗（未開始／進行中／提出済／承認済）と受験履歴

主要なCTA（例：「検証を続ける」「クイズを開始」）を目立たせ、ステータスは平易な言葉で示します。

クイズはアクセシブルで落ち着いた体験に

全ユーザーに使いやすくするために：

• フルのキーボードサポート（タブ順、フォーカスの可視化、トラップ回避）
• 読みやすいレイアウト（大きめのタップ領域、十分なコントラスト、読みやすい行長）
• 長いクイズは自動保存、かつ明確な「送信」タイミング

小さなUX配慮：残り問題数を示すが、必要以上に密なナビゲーションは与えない。

フィードバックルールを明確にする

フィードバックは学習を促すが、答えの共有を助ける場合もあります。方針に合わせてUIを整えます：

• 各問ごとに即時フィードバック（学習向け）
• 提出後にフィードバック（回答共有を減らす）
• 問レベルのフィードバック無しで合否と次の行動のみ表示（コンプライアンスで一般的）

何を選ぶかは事前に明示（「提出後に結果が表示されます」等）して驚きがないようにします。

証拠アップロードは案内的に、リスクを感じさせないように

証拠が必要な場合のフローは簡単に：

• 何が受け入れられるかの短いチェックリスト
• ドラッグ＆ドロップのアップロードとプレビュー（画像はサムネ、ドキュメントはファイル名／サイズ表示）
• 提出前に欠落や読み取り不能を警告

対応ファイルの上限と形式を事前に示してエラーを減らします。

次に何をすべきかを常に示す

各アクション後に次の状態を明確に示します：

• 合格：証明書／ステータス、失効日（あれば）、どこに表示されるか
• 不合格：再試行可否、再試行ウィンドウ、推奨学習リンク（例：/training/product-basics）
• 証拠提出："レビュー待ち"、想定レビュー時間、通知方法

期限に応じたリマインダー（期限前の催促、証拠欠落通知、失効前の最終リマインド）を適度に送ります。

作成・管理のための管理者ツールを作る

管理ツールは運用を楽にするか、恒常的なボトルネックにするかを決めます。SME が安全に寄稿でき、プログラムオーナーが公開を管理できるワークフローを目指します。

実用的な作成フロー（コンテンツ→問題→解答キー）

「ナレッジユニット」エディタを用意：タイトル、説明、タグ、オーナー、対象、関連ポリシーを入力し、そこに一つ以上の問題バンクを紐づけられるようにします。

各問題には明確な解答キーを持たせ、誘導フィールド（正答選択肢、許容されるテキスト回答、採点ルール、根拠）を提供します。

証拠ベースの検証をサポートする場合は「必要な証拠の種類」や「レビューチェックリスト」を設定し、承認者が何をもって"良い"とするか分かるようにします。

バルクインポート／エクスポート

管理者はスプレッドシートを要求します。CSVインポート／エクスポートをサポート：

• 問題バンク（解答キー、タグ含む）
• 割当（誰が何をいつまでに）
• マッピング（チーム、役割、ロケーション）

インポート時は事前検証とサマリを表示：欠損列、重複ID、無効な問題タイプ、解答形式不整合などを修正できるようにします。

レビューと承認の流れ：ドラフト→承認→公開

コンテンツ変更はリリース扱いにします：

• Draft： 編集可能、学習者には未表示
• Approved： レビュー承認済みでロック
• Published： 実運用で使用されるバージョン

バージョン履歴を保持し「クローンしてドラフト化」できるようにして、進行中の割当を中断しない更新を可能にします。

テンプレートとガードレール

オンボーディングチェック、四半期リフレッシャー、年次再認定、ポリシー承認などの共通プログラム用テンプレートを提供します。

ガードレール例：必須フィールド、平易な言語チェック（短すぎ／不明瞭）、重複問題検出、プレビューモード（学習者が見る画面の正確な表示）を実装します。

技術スタックと高レベルのアーキテクチャを選ぶ

知識検証アプリは単なるクイズではなく、コンテンツ作成、アクセス制御、証拠アップロード、承認、報告を含みます。アーキテクチャは運用チームの技術的キャパシティに合わせて選びます。

開発方針：モノリスかモジュール化か

多くの内部ツールではモジュール型モノリスから始めるのが有効：一つのデプロイ可能なアプリだがモジュール（認証、コンテンツ、評価、証拠、報告）で分割。速く出せてデバッグや運用が楽です。

独立したサービス化は、真に必要になったとき（別チームが別領域を所有する、解析処理の独立スケールが必要、デプロイ頻度の衝突が常態化した等）に移行します。

維持可能なコアスタックを選ぶ

チームが既に知っている技術を選び、目新しさより保守性を重視します：

• バックエンド： Node.js（NestJS/Express）や Python（Django/FastAPI）が内部アプリで一般的
• DB： Postgres は問題バンク、試行、証拠メタデータ、監査ログに適合
• フロントエンド： React（または Vue）＋コンポーネントライブラリで管理者／学習者画面を速く作れる

多くのレポートが必要なら、初期からリード向けのパターン（マテリアライズドビュー、専用の集計クエリ）を計画しておくと後で楽になります。

プロダクト形状を検証して本格開発に入る前に、プロトタイプを作りたいならチャットインターフェースで学習者＋管理者フローを試せるツール（例：Koder.ai）を使う方法もあります。Stakeholder の確認やスナップショット／ロールバックを使った安全なレビューが可能です。用意ができたらソースをエクスポートして社内リポジトリへ移行できます。

環境とシークレットの計画

local / staging / production を用意してワークフロー（特に承認や通知）を安全にテストします。

設定は環境変数に置き、シークレットはクラウドのシークレットマネージャなどで管理。資格情報のローテーションと管理者アクションのログ記録を行います。

ホスティングとデプロイスタイル

• コンテナ（Docker + オーケストレーション）： 可搬性と制御のバランス良し
• PaaS： 小規模チームの最短経路、運用負荷低減
• サーバーレス： APIやスケジュールジョブで有効だが、コールドスタートやバックグラウンド処理の複雑さに注意

非機能要件を文書化する

稼働率、パフォーマンス（クイズ開始時間、レポートの読み込み時間）、データ保持、サポート体制などを明文化します。これらはホスティングコストからピーク時の対応までを左右します。

データ、セキュリティ、プライバシーの対策を設計する

この種のアプリはすぐに記録系システムになります：誰が何を学び、いつ証明し、誰が承認したか。データモデルとセキュリティ計画を製品機能として扱ってください。

コアエンティティをモデル化し、監査トレイルを保つ

初期はシンプルで明示的なテーブル群から始めます：

• Users（名前、メール／社員ID、ステータス）と必要に応じたPIIフラグ
• Roles とロール割当（誰がどの範囲でどの権限か）
• Content（モジュール／ポリシー／手順）とVersions
• Questions（タイプ、難易度、タグ）と問題バンクのメタデータ
• Attempts（誰がどの評価をいつ受験したか、スコア、合否、デバイス／IPメタデータ等）
• Evidence（ファイル参照、アップローダー、関連する試行、ステータス）
• Approvals（承認者、決定、コメント、タイムスタンプ）

追跡可能性を重視して重要フィールドを上書きしない、イベントを追加していく設計にします。

デフォルトで安全に：暗号化、保管、アクセス

• 転送中はHTTPS を徹底
• 保存時も暗号化（DBやバックアップ）
• 証拠ファイルは プライベートなオブジェクトストレージ に保管。短命の署名付きダウンロードリンクを使い、ウイルス／マルウェアスキャンを行う

最小権限のRBACを実装し、デフォルトを厳しくします：

• 学習者は自分の割当と結果のみ閲覧
• レビュアーは自分のスコープ内の証拠と試行のみアクセス
• 管理者は問題バンクやレポートを管理するが、センシティブ操作はすべてログ

追加しておくと嬉しいプライバシー制御

必要最小限のPIIに抑える方針を取り、次を実装します：

• 管理者／レビュアーによる試行や証拠閲覧のアクセスログ -保持制御（Xか月後に証拠を削除、合否メタは長期保管など） -エクスポートや削除ワークフロー

よくあるリスクへの対策

早めに対策を計画します：

• 危険なアップロード： ファイル種別／サイズ／パスの制限、アップロードのスキャン
• 総当たり攻撃： ログインや検証試行のレート制限、ロックアウトと安全な回復
• セッション乗っ取り： セキュアクッキー、管理者セッションの短寿命化、感度の高い操作での再認証

これらを適切に実装すると、学習者の信頼が高まり、監査人も記録を信用できます。

採点、報告、分析を作る

採点と報告は単なる"クイズツール"から、マネージャーが意思決定に使えるプラットフォームへ変える部分です。ルールを早めに定義しておくと作成者やレビュアーの迷いが減ります。

明確で説明可能な採点ルール

まずは単純な基準（例：合格ライン80%）から始め、必要なときだけ加味を入れます。

重み付けは安全性や顧客影響が大きいトピックに有効。特定の問題を必須にして、そこが外れたら合計点が高くても不合格とするルールもあります。

再試行後の扱い（最高スコアを採るか、最新を採るか、全てを保持するか）を明示してください。これは報告や監査に影響します。

短答の採点方針

短答は理解度チェックに有効ですが、採点方針を合わせる必要があります。

• 手動レビューは防御力が高いが運用負荷が増す
• キーワード／ルールベースの自動採点はスケールするが誤判定に注意

実用的なハイブリッドは自動採点＋信頼度が低い場合は「要レビュー」フラグを立てる方法です。

マネージャーが実際に使うレポート

日常的に必要なビューを用意します：

• 誰が期限超過か（チーム／役割別）、次に何が来るか
• 合格／不合格、そのまでの試行回数
• 証拠の状態：提出済み／レビュー待ち／承認済み／却下、タイムスタンプ付き

トレンド指標と監査向けエクスポート

完了率の推移、よく間違われる問題、コンテンツ不明瞭のシグナル（高い不合格率、繰り返されるコメント、高頻度の異議申し立て）などを追加します。

監査用にはワンクリックで出せるエクスポート（CSV/PDF）を用意し、チーム／役割／期間でフィルタリングできるようにします。証拠を保管するならリンクやID、レビュアー情報を含めて完全なトレーサビリティが出るようにします。

参考：/blog/training-compliance-tracking（監査に適したレポートパターンの案）

統合と通知を追加する

統合があれば知識検証アプリは日常ツールになります。手動作業を減らしアクセスを正確に保ち、人々が割当を見逃さないようにします。

アイデンティティ連携（SSO とライフサイクル）

既存の認証でログインできるよう SSO（SAML または OIDC）を導入します。

同様に重要なのがユーザーライフサイクル：アカウントのプロビジョニング／更新とアクセス剥奪を即時に行えること。ディレクトリから役割や部署属性を引き、RBAC の基盤にすると管理が楽になります。

チームの働き方に合った通知

割当が放置されないよう、少なくとも1つは組織で使われているチャネルを使います：

• メール（全社に普及）
• Slack／Teams（迅速）
• 社内メッセージシステム（あれば）

通知イベント例：新規割当、期限間近、期限超過、合否結果、証拠承認／却下。該当タスクへの深堀リンク（例：/assignments/123）を含めます。

既存業務と証拠の同期

HRシステムやディレクトリグループがすでに誰が何をやるかを定義しているなら、そこから割当を同期します。手入力を減らしコンプライアンス追跡を改善できます。

証拠が既に別システムにある場合は無理にアップロードさせず、チケットやドキュメント（Jira、ServiceNow、Confluence、Google Docs 等）へのURLを添付できるようにして、リンクと文脈を保存します。

自動化のためのAPIとWebhook

初日からすべての統合を作る必要はありませんが、クリーンなAPIエンドポイントとWebhook設計は計画しておきます。他システムが：

• 割当を作成する
• 完了を記録する
• リマインダーをトリガーする
• 結果をレポートに流す

といったことを自動化できると将来性が高まります。

テスト、パイロット、ローンチ、継続的運用

社内知識検証アプリは"デプロイして終わり"ではありません。技術的に動くこと、学習者にとって公平に感じられること、管理負荷を減らすことが目標です。

実用的なテスト計画を作る

信頼を失わせる箇所（採点や権限）を重点的にカバーします：

• ユニットテスト： 採点ルール、受験回数制限、合否閾値、失効ロジック
• 統合テスト： クイズ提出→スコア保存→報告、証拠アップロード→レビュアー決定→ステータスの遷移
• UIテスト： アクセシビリティの基本、モバイル表示、エラー状態（タイムアウト、アップロード失敗）、途中再開
• 権限テスト： RBAC のシナリオ（学習者／レビュアー／管理者）、チーム変更や一時アクセスの端ケース

自動化できるフローが限られるなら優先順位は："受験する"、"証拠提出する"、"承認／却下する"、"レポートを見る"です。

まずは1チームでパイロット

実際にトレーニング圧があるチームでパイロットを行います（オンボーディングやコンプライアンス部門など）。範囲は小さく：1つの知識領域、限定された問題バンク、1つの証拠ワークフロー。

フィードバック項目：

• 問題と合格基準の明確さ
• 摩擦点（ログイン、操作、アップロード制限、通知）
• 公平感（再試行、部分点、レビュアーノート）

途中で離脱した箇所や質問が多かった箇所が改善優先です。

ローンチチェックリストを用意

本番前に運用とサポートを整えます：

• データ移行（ユーザー、チーム、既存の認定情報）
• モニタリングとアラート（エラー、遅いページ、送信失敗）
• バックアップと復旧訓練
• 管理者向けトレーニング（作成、質問修正、異議対応）
• シンプルなサポート経路（FAQ＋内部の"問い合わせ"チャネル）

成功基準と継続ガバナンスを定義

採用率、レビュー時間の短縮、繰り返しミスの減少、手動フォローの減少、目標期間内の完了率といった測定可能な指標で成功を評価します。

コンテンツオーナーを割り当て、レビュー周期（例：四半期）を設定し、変更管理の流れ（何がトリガーで更新するか、誰が承認するか、学習者への通知方法）を文書化します。

頻繁に変更する場合はスナップショットとロールバックの仕組み（デプロイパイプラインやプラットフォームの機能）を使って、進行中の検証を邪魔せずに改善を進められるようにします。