ユーザ用ツール

サイト用ツール


it技術:システム開発:教える技術

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン前のリビジョン
次のリビジョン
前のリビジョン
it技術:システム開発:教える技術 [2018/06/04 00:05] yajuadminit技術:システム開発:教える技術 [2023/05/29 21:52] (現在) – [行動科学の教える技術] yajuadmin
行 1: 行 1:
 ====== 教える技術 ====== ====== 教える技術 ======
 ===== 行動科学の教える技術 ===== ===== 行動科学の教える技術 =====
-作業者教育の標準化という中にある、教える際に「カンとコツが伝わっていない」という記述。\\ +作業者教育の標準化という中に教える際に「カンとコツが伝わっていない」という記述がありました。\\ 
-教える際、知識ばかり教えてしまますね。\\ +教える際、知識ばかり教えてしまますね。\\ 
-「カンとコツ」を教えるのは難しいですが、これは参考書にないもので、\\ +「カンとコツ」を教えるのは難しいですが、これは参考書にないもので、その人が経験してこないと教えられないものなので、こういうものを教えられるようになるといいですね。
-その人が経験してこないと教えられないものなので、こういうものを教えられるようになるといいですね。+
  
 以前、読んだ「行動科学の教える技術」という本に書いてありました。\\ 以前、読んだ「行動科学の教える技術」という本に書いてありました。\\
行 16: 行 15:
 [[http://anond.hatelabo.jp/20170511230227|自分で考えろは新人に使ってはいけないと思う]] [[http://anond.hatelabo.jp/20170511230227|自分で考えろは新人に使ってはいけないと思う]]
  
 +「遠慮なく質問してね」と言ったら、ホントに遠慮なく何でもかんでも質問されちゃったケース\\
 +[[https://qiita.com/ysktsuna/items/fced3a9515c8f585ca50|新卒からの質問をソシャゲっぽい仕組みにしたら捗った話]]\\
 +質問する側の心理負担\\
 +[[https://qiita.com/morry_48/items/86ce93c34e5789f38be3|良い質問をして自己成長に繋げるためのあれこれ]]
 +
 +==== 正しい努力 ====
 +予備校講師の林修先生が述べた「努力」に対する言葉
 +>努力は裏切らない、という言葉は不正確です。
 +>正しい場所で、正しい方向を向いて、十分な量なされた努力は裏切らない、が正しいんです。
 +
 +{{:it技術:システム開発:正しい努力.png|}}
 +===== 理解度 =====
 {{:it技術:システム開発:理解度.jpg}}\\ {{:it技術:システム開発:理解度.jpg}}\\
 [[https://togetter.com/li/1217505|「知ってるだけ」では意味がない…?「知る」「分かる」「できる」「している」の違いを表した図が秀逸]] [[https://togetter.com/li/1217505|「知ってるだけ」では意味がない…?「知る」「分かる」「できる」「している」の違いを表した図が秀逸]]
 +
 +人によって"分かった"の基準がかなり違う、10人いたら10通りの「分かった」が存在して10人がすべて「分かった」といっても、正確に情報を理解し本当の意味で分かっているのは実は1人だけしかいなかったりとか・・・\\
 +
 +実際に分かったつもりになっていないかを確認するにはどうするのか?\\
 +「自分の理解度」を他人を通してチェックしてみればいいのです。\\
 +「人にキチンと説明できる」という状態になって初めて「分かった」ということが出来るのです。\\
 +「分かる」と「伝えられる」を同じにするように心掛ける。
 +
 +===== 教え方が上手い人は何をしているか? =====
 +{{:it技術:システム開発:教え方.png|}}\\
 +  * [[https://togetter.com/li/1238478|『教え方が上手い人は何をしているか?』を具体的にまとめた表がとても参考になると話題に]]
 +  * [[https://speakerdeck.com/e869120/wakariyasuisetsumei-10-tessoku|わかりやすい説明のための 10 の鉄則]]
 +===== 「なにがわからないか、わからない」ときの質問のしかた =====
 +>「何が分からないのか」の言語化を試みる、ということでもありました。
 +>**何もわからないなら何もわからないなりに、あてずっぽうでもいいから何らかのアプローチをして、それを失敗させなくてはいけない。**
 +>そうすれば、そこには「何故失敗したのか」「そのアプローチは正しかったのか」というとっかかりが出来る。
 +>その「とっかかり」があるかないかで、質問の価値、質問によって問題を解決出来る可能性というものは根本的に変わります。
 +>**「分からない」を解決する、というのは、一種の宝探しのようなものでして、「どこに理解を妨げている要因があるのか」というものをどうにかして探り当てなくてはいけません。**
 +>それは単純に知識不足なのかも知れないですし、アプローチの方向性が間違っているのか、何か理解を妨げる勘違いをしているのか、あるいは内容について読めていない部分があるのかも知れません。
 +>[[https://blog.tinect.jp/?p=68951|大学の恩師に教わった、「なにがわからないか、わからない」ときの質問のしかた。]]
 +
 +[[https://b.hatena.ne.jp/entry/s/blog.tinect.jp/?p=68951|はてブコメントから抜粋]]
 +
 +  * 要は「質問」の形に落とし込まず「何をしたら」「どうなって」「どうしたいのか」状況と希望を説明せよって事だよね
 +  * 議論とかもそうだけど、自分の立ち位置を確認し相手に伝えるとこから始まる。
 +  * 新しい領域(自分だけでなく周辺も含めて知見のない分野)にチャレンジする際は、「とりあえずやってみる」はとても重要。上手くいかないのが当たり前で、「失敗の仕方」が知見になる。失敗を得るために動く。
 +  * 思考力というか。ググっても出てこない課題をやっつけないといけないとき、仮説や問いを自分で考えながら何がわからないかを組み立てないといけないが、これができない社員が一定数出現するのでマネジメント難しい
 +  * 主題が何で、自分の状況を説明してくれると、とても助かるよ。 "自分の思考過程、「自分はその問題に対して何を試みて、それがどのように失敗したのか」"
 +  * プログラミングの質問サイトでも、「まずお前の書いた動かないコードを貼れ。話はそれからだ」と言われますね
 +
 +[[it技術:システム開発:質問の技術|]]
 +===== 自分で考えさせる仕組みをつくる =====
 +>また、5,6人以上の受講生に教えていると大抵1人は献身的な学習方法を取る方が居ます。周りの遅れている方を率先的にフォローし、フォローをするリソースを空けるために先の単元をどんどん吸収していく方です。
 +>(中略)
 +>人に教えるという方法は非常に有効な学習方法です。言語化することで知識は整理され、教えていく中で不足している知識が明確になり、次に何を掘り下げるべきなのか、と自身の状況を俯瞰できるようになる上に、その知識が必要とされる背景、文脈を捉えてから学習をするという非常に理想的な知識の定着フローを自然と踏めるようになるのです。
 +> こうした学習方法を自然にとれる受講生がいると、私たちとしては教えるのが非常に楽です。しかし一方で、このような方はその当人しか伸びず、他者の成長を阻害してしまうという事態を起こす危険を孕んでいます。
 +>(中略)
 +>人から教えられることや社会のセオリーから学ぶものは、確かに必要な知識として私達の中に蓄積されていきます。しかしその知識がどの程度内面化されるかというのはまた別の話です。私はその内面化の鍵は自発的な経験であると考えています。訳もわからず人に与えられた課題をこなすより、自身で論理から組み立て設定した課題を解決するほうが、より大きな達成感を得られることは自明と言えるでしょう。
 +
 +[[https://qiita.com/shoki_kitajima/items/9b82d28c684751c466eb|プログラミング講師が考える、プログラミング学習に必要な資質と講師側の規範、また教育というものについて]]
 +
 +===== インストラクショナルデザイン =====
 +インストラクショナルデザインとは、「何を(What)できるようにするのか?」を明確にしたうえで、「どうやって(How)できるようにするのか」をルールに基づいて体系的に考えることにより、効果的・効率的・魅力的な教育プログラムを作成するための方法論です。
 +
 +  * [[https://www.leapkk.co.jp/2020/04/27/instructional-design/|教え方にはルールがある!?「インストラクショナルデザイン]]  
 +  * [[https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%AB%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3|インストラクショナルデザイン - wikipedia]]
 +  * [[https://nowokay.hatenablog.com/entry/2021/01/06/233326|プログラムを教えて理解されない場合は教える技術の不足]]
 +  * [[https://togetter.com/li/1648653|プログラミングを教えるということ]]
 +
  
 ---- ----
行 93: 行 153:
 そのような上司や先輩の下では、部下たちは心地よく感じ、仕事ものびのびできます。 \\ そのような上司や先輩の下では、部下たちは心地よく感じ、仕事ものびのびできます。 \\
 「みほこさん」って覚えやすいですよね。 「みほこさん」って覚えやすいですよね。
 +
 +===== 魚の釣り方 =====
 +老子の格言『授人以魚 不如授人以漁』
 +
 +>お腹を空かした人が居た場合、魚を与える事は一時的な空腹を満たすためには簡単な方法だけど、それでは、その人は空腹になる度に誰かを頼り、魚をもらい続けなければならないし、もらい続ける癖がついてしまう。どちらが本当にその人のためになるのか?と言うお話です。
 +>これに対し、釣りの道具を与えて魚の釣り方を教え、実践して身につけて貰えば、空腹になっても自らの力で魚を捕まえて食べられるようになります。勿論、目先の困難を助ける事も時には大事です。しかし「本質的には相手のためになる」とは限りません。本当は「相手のためには何が1番か?」と言う事を考え、教えてあげたり、環境を作ってあげたりする事も大事です。
 +
 +魚を与えるのではなく、魚の釣り方を教えよ!\\
 +https://xlab-online.com/mindset/3367.html
 +
 +===== 問題対応力 =====
 +[[https://bufferings.hatenablog.com/entry/2019/03/31/005750|エンジニアが何か問題にぶつかったときにあるといい力を5個]]
 +
 +===== ぼんやり上司とガツガツ上司 =====
 +[[https://wirelesswire.jp/2021/05/79790/|ぼんやり上司とガツガツ上司、どっちが良いか]]
 +===== 叱り方 =====
 +[[https://togetter.com/li/1592082|【漫画】「怒られると絶望する子」が親となり、子供の成長につながる「叱る時の5つルール」に集まる共感の声「こんなふうに叱って欲しかった」]]
 +
 +==== アンガーマネジメント ====
 +「6秒」で人生が変わる アンガーマネジメントのススメ\\ 
 +http://www.j-cast.com/kaisha/2014/11/06220126.html
 +
 +諸説あるのですが、怒りの感情のピークは最大でも6秒程度と言われています。\\ 
 +「カチン」と来てから6秒以内で発する言動は感情的になることが多く、非建設的な対応をしてしまうことが少なくないのです。
it技術/システム開発/教える技術.1528038344.txt.gz · 最終更新: 2018/06/04 00:05 by yajuadmin