【非IT学部卒未経験学生のエンジニア就職応援】IT研修講師ハンドブック_202604280652

-- Views

April 28, 26

スライド概要

profile-image

何卒よろしくお願い申し上げます。 一流のIT研修講師を目指し、日々研鑽を続けております。 本資料は外部公開用としてご提供するものです。 ALJ Education Plus 株式会社 Yukiko(※趣味枠アカウント)

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

FOR I T T RAI NING INST RUCT ORS / I T 研修講師向け IT研修講師ハンドブック 指導法 × カリキュラム × 対話ガイド 未経験講師でも実装できる、観察 → 誘導 → 並走 → 対話 の完全パッケージ。 PART A PART B PART C 指導法 5日間カリキュラム 問題行動 対話ガイド 受講生をどう観察し、どう動くか 受講生に渡す中身。3つの実践スキル 問題が起きた時の実践マニュアル ・WHY 否定しないとは何か ・WHAT 10典型行動 ・HOW 5ステップ × 5型 ・ACTION 5W1H + 3週間並走 ・Day 1 基本マナー ・Day 2 報連相 (事実×仮説) ・Day 3 仮説思考 (PDCAのA) ・Day 4 質問力 (15分ルール) ・Day 5 エンジニア固有 ・WHAT 対話の3ステップ ・HOW 5W3H で対話設計 ・HOW 4ステップ進行 + フレーズ集 ・HOW 講師の自己チェック ・NG 避けるべき5パターン 対象:未経験〜初級IT講師 / メンター候補 / OJT担当 Instructor Handbook v1.0

2.

02 / 28 OVE R VIE W ハンドブックの使い方 Part A=動き方、Part B=教える中身、Part C=問題対応。それぞれ独立して使える。 PART A PART B PART C 指導法 — 講師の動き方 5日間カリキュラム — 受講生に渡す中身 対話ガイド — 問題行動が起きた時 使うシーン 使うシーン 使うシーン ・受講生の行動が気になり始めた時 ・「指摘していいか」迷った時 ・週次の1on1の準備 ・3週間の並走計画を立てる時 ・新人受け入れ初週の研修 ・OJT前の知識整え ・現場デビュー準備の総点検 ・受講生のセルフチェック ・遅刻・未提出など問題行動が出た時 ・1on1で深く話す必要がある時 ・指摘の前に自分を点検したい時 ・「何と言うか」迷った時 収録内容 収録内容 収録内容 WHY 否定しない / WHAT 10典型行動 / HOW 5ステップ + 5型 / ACTION 5W1H + 3週間並走 Day 1 基本マナー / Day 2 報連相 / Day 3 仮説思考 / Day 4 質問力 / Day 5 エンジニア固有 + 卒業チェック 対話3ステップ / 5W3H / 4ステップ進行 / 質問フレーズ集 / 講師の自己チェック / NG対話5パターン 講師は Part A で動き方を、受講生に Part B を渡し、問題行動が出たら Part C を開く、という三段使いを推奨。

3.

03 / 28 P A R T A 指導法 — 講師の動き方 受講生を観察し、否定せず、習慣を一緒に作る。 講師の仕事はジャッジではなく「並走」。 指導の鋭さは保ち、人格を傷つける言葉だけを取り除く。 WHY 否定しない WHAT 10典型行動 HOW 5ステップ HOW 5型言い換え ACTION 5W1H ACTION 3週間並走

4.

PA RT A WHY 04 / 28 なぜ「習慣」を指導す るのか 「否定しない」=「指摘しない」ではない 人格と行為を分けて、行為についてだけ事実を伝える。これが定義。 ✕ 人格を否定する言い方 ○ 行為について事実を伝える 「やる気あるの?」 「進捗報告で「もうちょっと」が3日続いていますね」 「向いてないんじゃない?」 「この書き方は、現場で問題が起きやすいパターンです」 「こんなコード書いて…」 「データ件数が増えるとメモリで詰まる書き方になっています」 「なんでできないの?」 「情報がもう少しあれば一発で答えられそうです」

5.

PA RT A WHAT 05 / 28 評価を下げる10の典型行動 「観察すべき10の行動」一望表 ★印は初級講師がまず3週間集中して観察すべき優先3行動。 1 ★ 質問が「動きません」だ け 6 Slack/MTGの応答が遅 い 2 ★ 進捗報告に具体性がない 7 同じミスを繰り返す/メ モなし 3 締切前日まで遅延を共有 しない 8 朝会で詰まりを報告しな い ※ 優先3行動(★)= 質問の質 / 進捗の具体性 / フィードバック受容。10個全部を同時に追わない。 4 5 レビュー指摘が表面的で 再発 9 ★ FBに「でも」「だって」 が出る 仕様書を読まずに実装開 始 10 自己評価が過大または過 小

6.

PA RT A WHAT 06 / 28 評価を下げる10の典型行動 ★優先3行動 — 観察ポイントと現場影響 未経験講師は、まずこの3つだけを毎日観察する。それ以外は無視してよい。 質問が「動きません」だけ 1 観察 ・自分で何を試したかが書かれていない ・エラー全文が添付されていない ・仮説がない 進捗報告に具体性がない 2 観察 ・「昨日と同じところやってます」が続く ・「あと少し」が3日続く ・%や完了基準で言えない フィードバックに「でも」「だって」 9 観察 ・指摘に対して防衛が先に出る ・「環境のせい」「仕様のせい」が口癖 ・表情が固くなる 現場影響 シニアの時間を奪う。質問の質はエンジニアの実力と直結すると評価される 。 現場影響 PMがリスクを察知できない。隠したつもりが、結果として手遅れに。 現場影響 シニアが「言っても無駄」と判断しFBが止まる。これが最も怖い結末。

7.

PA RT A HOW 07 / 28 カイゼン誘導の伝え方 カイゼン誘導の5ステップ 順序を守る。飛ばすと改善は空回りする。 S TE P 1 S TE P 2 S TE P 3 S TE P 4 S TE P 5 状態観察 要件把握 論点把握 カイゼン誘導 並走 1〜2週間。一過性か習慣化 された問題か見極める。 「何ができていればOKか 」を双方で言葉にする。 改善インパクト最大の1つ に絞る。3つ言うと「全部 ダメ」と受け取られる。 「直して」と言わず、今日 からできる具体行動を示す 。 改善が習慣化するまで一緒 に走る。指摘して放置は NG。 目安:2週間 目安:30分対話 目安:1論点 目安:具体1個 目安:3週間 ポイント:3週間並走する覚悟がないなら、その指摘はしない方がよい。

8.

PA RT A HOW 08 / 28 カイゼン誘導の伝え方 否定しない伝え方 — 5つの言い換え型 迷ったらこの5型に当てはめる。鋭さは保ち、人格を傷つける言葉だけ取り除く。 型 ✕ NG ○ 言い換え 詰問→確認 「なんでこうしたの?」 「これ、何をしようとしたか教えて」 断罪→観察 「質問が雑」 「質問にこの情報があると一発で答えられる」 比較→自分史 「同期はもうできてる」 「1ヶ月前の自分と比べてどう?」 指示→質問 「こうしろ」 「どう進めるのが良さそう?」 脅し→道筋 「現場で潰される」 「現場ではこのレベル。あと3ヶ月でここまで届こう」 言いにくいことは「事実 → 認識 → 行動」の3点セット ①「進捗報告で『もうちょっと』が3日続いていますね」(事実) → ②「サポートしたくてもできない状態です」(認識) → ③「明日から進捗を%で言えるようにしませんか 」(行動)

9.

PA RT A ACTION 09 / 28 未経験講師の具体行動 5W1H — 未経験講師が明日からできる具体行動 講師未経験でも、この6項目を埋めれば動ける。 WHEN WHERE WHO いつ どこで 誰が 毎朝会(15分) / 毎日終業前メモ / 週1の1on1(30分 )。 指摘は「気づいた瞬間」ではなく「2週間観察した 後」。 朝会=チーム全員 / 個別指摘=1on1専用Slackチャ ンネル+DM。 公開で晒さず、必ずDMでフォロー。 観察=初級講師 / 判定=上級講師 / 並走=両方。 判断に迷ったら必ず上級講師にエスカレ。 WHAT WHY HOW 何を なぜ どう 「優先3行動(質問の質・進捗具体性・FB受容)」 だけを観察。 10個全部を同時に追わない。1論点に絞る。 受講生の評価を下げているのは「能力」ではなく「 習慣」。 習慣は「指摘」ではなく「並走」でしか変わらない 。 事実→認識→行動の3点セットで伝える。 「直して」ではなく「今日からこうしよう」と具体 行動を渡す。 迷ったら上級講師にエスカレ。「自分で判断しない」ことが、未経験期の最大の安全策。

10.

PA RT A ACTION 10 / 28 未経験講師の具体行動 3週間並走の設計図 改善は1回の指摘では終わらない。最低3週間並走する覚悟で。 1〜3日 4〜10日 11〜21日 22日〜 1 2 3 4 認識共有 行動変容 習慣化 定着確認 何を改善したいか、双方で言葉にす る。本人が「直すべき1つ」を自分で 言えるまで対話。 新しい行動を試す。良い変化が見え たら即フィードバック。1日1回は短 く声かけ。 戻り気味な場合のリカバリー設計。 責めずに「もう一度試そう」と言え る距離感を保つ。 別の改善ポイントに移る。並列で2つ を同時には絶対にやらない。 並走中の上級講師セルフチェック(毎週金曜) □ 改善ポイントは本人と認識が合っているか を拾えているか □ 良い変化が見えたとき即承認したか □ 別の改善ポイントを並行で持ち出していないか □ 1on1で「うまくいかなさ」

11.

11 / 28 P A R T B 5日間カリキュラム 受講生に渡す中身。3つの実践スキルで「現場デビュー準備」を完成させる。 Day 1で型を、Day 2-4で核となる3スキルを、Day 5で統合する設計。 このPart B は、受講生に直接渡してもよい完成された教材です。 講師は Part A を片手に、この教材を「一緒に並走する」イメージで使ってください 。 ①報連相 事実と仮説 ②仮説思考 PDCAのA ③質問力 15分ルール

12.

PA RT B 12 / 28 5日間カリキュラム全体 マップ 5日間カリキュラム 全体マップ Day 1で型を、Day 2-4で核となる3スキルを、Day 5で統合する設計。 D1 D2 D3 D4 D5 Day 1 Day 2 Day 3 Day 4 Day 5 IT現場の基本マナー ①報連相 ②仮説思考 ③質問力 エンジニア固有マナー & 統合 型を作る 挨拶/服装/時間/応答 名乗り/メール署名 事実 vs 仮説 報告テンプレ NG/OK実例 演習 PDCAのA PDCAサイクル IF-THEN形式 Aの最小手順 15分ルール 自己解決vs質問 質問テンプレ 誰に聞くか 現場デビュー PR/レビュー作法 コミット作法 卒業チェック 毎日の終わりに「今日の3行ふりかえり:事実1つ・気づき1つ・明日試す1つ」を提出。これがDay 3で学ぶPDCAのAそのもの。

13.

13 / 28 D A Y 01 IT現場の基本マナー K E Y M E S S A G E 「即返信」が信頼を作る ✕ 既読スルー / 半日後返信 ○ 30分以内に「見ました」 先輩は「届いたか」「見たか」が分からず、別の人に振 り直すか自分でやることに。 「見ました。今のタスクを17時に区切って取り掛かりま す」だけで、先輩は安心して次の仕事に進める。 即返信ルール 3か条 ① 30分以内に「見ました」だけでも返す ② 「いつ返せるか」を添える(例:17時頃) ③ 返せない時は理由を1行(例:今障害対応中) Day 1 / 5

14.

14 / 28 D A Y 02 Day 2 / 5 ① 報連相 K E Y M E S S A G E 「事実」と「仮説」を分けて伝える 事実 (Fact) 仮説 (Hypothesis) 誰が見ても同じになるもの。 ・エラーメッセージ全文 ・コマンドの出力 ・実行手順 ・観測した数値 自分の解釈・推測。 ・「○○のせいだと思う」 ・「たぶんこれが原因」 ・「○○すれば直りそう」 → 必ず仮説とラベル付け

15.

PA RT B Day 2 15 / 28 ①報連相 — 事実と仮説を分ける Day 2 詳細:報告テンプレと NG/OK実例 テンプレを毎回使う。最初は遅くてもよい。3週間で習慣化する。 ✕ NG報告 ○ OK報告 「APIが死んでます。 たぶんサーバーの問題です。 直してもらえますか?」 「/api/users にPOSTを3回送信、 すべて HTTP 500 が返ります(事実)。 サーバー側の問題と推測しています(仮説)。 ログ確認まで自分でやれます。 権限の付与をお願いできますか?」 報告テンプレート 1 事実 観測されたこと(全文) 2 仮説 自分の推測(ラベル付け) 何がダメか 何が良いか ・「死んでる」は事実か仮説か不明 ・「サーバーの問題」と断言してる ・自分は何を試したか不明 → 先輩は最初から状況を再調査する必要 ・「事実」「仮説」がラベル付き ・自分でできる範囲を明示 ・依頼内容が具体的 → 先輩は10秒で次の判断ができる 3 やったこと 自分が試した手順 4 依頼/相談 次に何が欲しいか Day 2の演習:今日の作業の中で「事実3つ・仮説3つ」を書き分けて先輩に報告する。

16.

16 / 28 D A Y 03 ② 仮説思考 K E Y M E S S A G E 解決するのはPDCAの「A」だけ P D C A Plan Do Check Action / Adjust 仮説を立てる 実行する 結果を見る 学習する ★ ★ 多くの人が P・D・C で止まる。Aを書く人だけが、3ヶ月後に伸びる。 Day 3 / 5

17.

PA RT B Day 3 17 / 28 ②仮説思考 — PDCA のAで「学習」を作る Day 3 詳細:IF-THEN形式とAの最小フォーマット 仮説は「もし○○なら△△が起きるはず」の形で書く。これだけで思考が整理される。 実例:APIエラーへの仮説思考 仮説の形式:IF-THEN 「もし [原因] が正しければ、[結果] が起きるはず」 例:もしDB接続が原因なら、DBサーバーを再起動するとエラーは消えるはず。 P 仮説 → 検証して結果を見れば、原因か違うか1回で分かる。 → 結果が予想と違ったら、それが「学習」になる。 D 実行 Aの最小フォーマット (毎タスク末) ① 予想と違ったこと ________ ② 次回試すこと ________ ③ 覚えておくこと ________ C 結果 A 学習 もしDB接続文字列が間違っているなら、DB再起動しても500の ままのはず。 DBサーバーを再起動。 500エラーは消えなかった。仮説は外れた。 ①予想と違ったこと=DB再起動で直らなかった →接続文字列が 原因確定。 ②次回試す=接続文字列を確認。 ③覚える=エラー時はまずsettingsを見る。 Day 3の宿題:終業前に「Aの3項目」を1日3回(朝/昼/夕)書く習慣を始める。

18.

PA RT B Day 4 18 / 28 ③質問力 — 選択して先輩に聞ける Day 4 ③質問力 — 「選択して」聞ける 「聞くか・自分でやるか」を毎回判断する。これが「選択して聞ける」の意味。 15分ルール 質問の判断フロー 1 2 15分自分で考えて解けないものは聞く。ただし「何を15分やったか」は必ずメモして質問に添える。 質問テンプレート (5項目) エラー全文で検索したか? ① やりたいこと → Yes 次へ / No まず検索 ② やったこと(手順) 公式ドキュメントを開いたか? → Yes 次へ / No まず読む ③ 出たエラー(全文) ④ 自分で調べたこと ⑤ 自分の仮説 3 15分以上詰まっているか? → Yes 質問する / No もう少し試す 誰に聞くか — 階段を1段ずつ 4 「自分の仮説」を1つ持てているか? → Yes 質問する / No 仮説を作ってから 直属の先輩 → チームSlackチャンネル → 全社の質問チャンネル 身近な人に聞いてダメな時だけ広げる。 Day 4の演習:今日の質問を1つ選んで、5項目テンプレで書き直す。

19.

PA RT B Day 5 19 / 28 エンジニア固有マナー & 統合 Day 5 コードでのコミュニケーション3点 コミットメッセージ・PR本文・レビュー受けは、すべて「文章での報連相」。 コミット作法 PR(プルリク)作法 レビューの受け方 ✕ NG fix ✕ NG 色々直したPRです お願いします ✕ NG 「直しました」だけ 再提出 → 同じ指摘 → 学習速度が遅い評価 ○ OK fix: ユーザー登録時のメール検証エラーを修正 ○ OK ## 目的 ユーザー登録の不具合修正 ○ OK 「ありがとうございます。 なぜこの書き方が良いのか 教えてください」 → 理由を聞く → 次から自分で気づける 空文字を許容していたバリデーションを is_valid_email() で厳密化。 #1234 1コミット1意図。Whyを必ず書く。後で自分が読 み返す。 ## 確認ポイント ・空文字メールが弾かれるか ・既存テストが通るか 目的・確認ポイントを書く。レビュアーの時間を短 縮する。 指摘は人格否定ではない。「Thanks → Why?」 のセットで返す。

20.

PA RT B 20 / 28 5日間 卒業チェックリスト 5日間 卒業チェックリスト 全項目が□になったら、現場デビュー準備完了。1on1で先輩と一緒に確認する。 Day 1 - 基本マナー Day 2 - 報連相 Day 3 - 仮説思考 Day 4 - 質問力 Day 5 - エンジニア固有 始業10分前にログインして いる 報告に「事実」「仮説」の ラベルを付けている 仮説をIF-THEN形式で書け る 15分ルールを使い分けてい る コミットメッセージにWhy を書いている Slackメンションに30分以 内に1行返している テンプレ4項目(事実/仮説/ やったこと/依頼)で書ける 毎タスク末にAの3項目を書 いている 質問テンプレ5項目で書け る PR本文に目的と確認ポイン トを書いている 「いつ返せるか」を添えて 返している エラーメッセージは全文で 報告している 予想と違った時を「失敗」 ではなく「学習」と捉えて いる 「自分の仮説」を添えて質 問している レビュー指摘に「Thanks → Why?」で返している 各項目「□ できる」と「□ 教えられる」の2段階で評価。教えられる=自分の言葉で後輩に説明できる状態。

21.

21 / 28 P A R T C 問題行動 対話ガイド 講師経験ゼロでも大丈夫 — このガイドの通りに進めれば必ずできる。 責めるのではなく「一緒に原因を探る」対話。 本人が「直す1つ」を自分の口で言えるまで導く。 5W3H・4ステップ進行・質問フレーズ集を使えば、未経験でも対話を組み立てられ る。 WHAT 対話3ステップ HOW 5W3H 設計 HOW 4ステップ進行 HOW フレーズ集 HOW 自己チェック NG 5パターン

22.

PA RT C WHAT 22 / 28 対話で何をするのか 問題行動への対話 — 3ステップ 「責める」のではなく「原因を一緒に探る」。3ステップなら未経験でも迷わない。 11 STEP 1 データ収集 22 STEP 2 原因のヒアリング 33 STEP 3 改善の言語化 事実を集める 本人の視点・背景を聞く 本人が「直す1つ」を言う いつ・何が・どこで起きたか。観察できる事実 だけを集める。 本人の解釈や自分の推測はまだ入れない。 「そのときどう思っていましたか?」 本人の認識・状況を、こちらの判断を挟まず先 に全部聞く。 答えを与えず、本人の口で「変えたいこと1つ 」を言わせる。 出るまで待つ。これが対話のゴール。 例:今月の遅刻3回 / 報告メール未送信2件 例:体調 / 家庭事情 / 業務量 / 指示理解のズレ 例:「明日から朝のSlack投稿を必ずします」 仮説を事実のように話すと、本人の信頼を一瞬で失う。「やる気がない」ではなく「やる気がないかもしれない」と言う。

23.

PA RT C HOW 23 / 28 対話を設計する 5W3H で対話を設計する 「何を・いつ・どう聞くか」を事前に準備する。まずは Who・What・Why の3つだけで十分。 Who ★ What ★ When Where 誰が 何を いつ どこで 問題行動を起こしているのは誰か 何をしたか(事実ベースで) いつ起きたか(頻度・パターン) どの場面・状況で起きたか How How much How many なぜ どう どの程度 どれくらい なぜそうなったか(本人の認識) どんな方法で対話を進めるか 改善度合いをどう測るか 何回・どの期間で確認するか Why ★ ★印 = まずこの3つだけ意識する。慣れたら他の5つも入れていく。全部一度に使う必要はない。

24.

PA RT C HOW 24 / 28 対話の進め方 対話の進め方 — 4ステップ この順番通りに進めれば、誰でも迷わない。STEP 4 が出るまで待つのが講師の仕事。 S TE P 1 S TE P 2 S TE P 3 S TE P 4 事実を伝える 本人の話を聞く 一緒に改善策を考える 「直す1つ」を本人の口か ら Whatから始める Whyを引き出す Howへ ゴール 「○○の場面で、○○がありまし た」と事実だけ話す。 感情・判断・自分の解釈は一切入 れない。 「そのときどう思っていましたか ?」 本人の背景・視点を、口を挟まず 先に全部聞く。 「次はどうしたいですか?」 答えを与えず、本人に考えさせる 。沈黙を恐れない。 「一番変えたいことを1つ言葉にし てみてください」 出るまで待つ。本人の言葉になっ て初めて改善が始まる。 → → → STEP 4 で本人が自分の言葉で言えたとき、はじめて本当の改善が始まる。焦らず待つ。

25.

PA RT C HOW 25 / 28 そのまま使える質問フ レーズ集 そのまま使える 質問フレーズ集 迷ったらこの言葉をそのまま使ってOK。「短く・優しく・具体的に」が最強。 事実を確認するとき 本人の気持ちを引き出すとき 「あの場面、具体的に何がありましたか?」 「そのとき、自分ではどう感じていましたか?」 「それは何回くらいありましたか?」 「なぜそうしようと思ったか、教えてもらえますか?」 改善を考えさせるとき 1つに絞らせるとき 「次に同じ場面になったら、どうしたいですか?」 「今日の話で、1つだけ言葉にするとしたら?」 「今一番変えてみたいと思うことは何ですか?」 「まず最初にやってみることを1つ決めましょう」 難しい言葉は要らない。短く・優しく・具体的に。これだけで対話は前に進む。

26.

PA RT C HOW 26 / 28 本人を指摘する前に まず自分をチェックする 本人を指摘する前に、講師側の改善余地を必ず確認する。これが公正な対話の出発点。 本人への指摘の前に「自分はどうだったか?」を必ず問いかける。 指示・期待値は明確に伝えていたか? → 曖昧な指示が原因のミスは、講師の責任 声がけ・フォローの頻度は十分だったか? → 孤立させると問題行動が見えにくくなる 本人が相談しやすい雰囲気をつくれていたか? → 話しかけにくい環境が隠蔽を生む フィードバックは都度できていたか? → 溜めてまとめて言うのは逆効果 4つ全部チェックできてから、はじめて本人への対話に進む。

27.

PA RT C NG 27 / 28 避けるべき対話パター ン やってはいけない NG対話 5パターン これだけ避ければ、対話は確実に前に進む。完璧を目指さなくてよい。 ✕ NG 1 ✕ NG 2 ✕ NG 3 ✕ NG 4 ✕ NG 5 仮説を事実として話す 複数の改善点を一度に渡 す 答えを先に言ってしまう 感情的になって話す 確認しないまま終わる 「やる気がない」などの決めつけ は反発を生む。 「あれもこれも」では本人が混乱 し、何も変わらない。 「〜すべき」と正解を与えると、 本人の気づきが育たない。 怒りや失望を前面に出すと、本人 は委縮し本音を話せなくなる。 「言いっぱなし」で終わると変化 が起きない。 → 仮説には必ず「〜かもしれ ない」をつける → 必ず「1つ」に絞る → 待つことが大切 → 1日置いてから話す NGを1つ減らすだけで、対話の質は大きく上がる。完璧を目指さなくていい。 → 次回のフォロー日を必ず決 める

28.

28 / 28 C L O S I N G 講師の仕事は、ジャッジではなく 「習慣を一緒に作る」こと。 PA RT A 講師 の3 ルー ル PA RT B 受講 生の 3 アク ショ ン PA RT C 対話 の3 原則 ① 本人を否定せず、行為について事実を伝える ① 事実と仮説を分けて報告する ① 事実→Why→改善案→「直す1つ」の順で進む ② 観察→要件→論点→誘導→並走の順序を守る ② 毎タスク末に「Aの3項目」を書く ② 指摘の前に自分を4点チェックする ③ 最低3週間の並走を覚悟する ③ 15分ルールで「選択して」聞く ③ 「正解を与える」より「気づきを支える」 習慣にしてしまえば、毎日の負担はゼロ。講師も受講生も、自然と伸びる。