「問題解決」の版間の差分
提供:作業療法大百科事典OtWiki
編集の要約なし |
編集の要約なし |
||
(同じ利用者による、間の3版が非表示) | |||
1行目: | 1行目: | ||
[[ファイル:問題解決におけるひらめき.jpeg]] | |||
[[問題]]発見、規定し、解決する一連のプロセス。[[作業療法士]]の重要な仕事。[[作業療法]]の存在意義。問題解決がなければ作業療法じゃない。 | [[問題]]発見、規定し、解決する一連のプロセス。[[作業療法士]]の重要な仕事。[[作業療法]]の存在意義。問題解決がなければ作業療法じゃない。 | ||
8行目: | 10行目: | ||
[[作業療法]]の[[理論]]は、[[作業療法]]の問題解決の構造を抽出したものであるといえる。 | [[作業療法]]の[[理論]]は、[[作業療法]]の問題解決の構造を抽出したものであるといえる。 | ||
==温故知新== | |||
やってみるとそこから新しい問題が起こる。それは思いもよらないような。 | |||
[https://sibucho-laboratory.com/knowledge-of-failure-marble-column/ 歴史から学ぼう!!設計失敗学-大理石円柱の保管失敗事例-] | |||
==デバッグ(プログラミング)== | |||
プログラミングにおけるデバッグの手法が参考になる、かもしれない。 | |||
詳細は[[プログラミング]]の記事を参照のこと。 | |||
==要件定義== | |||
マルっと、ニード、デマンド、目標設定の話と重複する。 | |||
顧客に寄りそった要件定義は難しいが出来ると、協力な武器になりうる。 | |||
[https://qiita.com/kimuni-i/items/496ae4d41c8098f32f21 こじれない要件定義を行う方法(顧客は何に悩んでいるのか?をU理論で紐解き、Well-Architected Frameworkに落とし込む) #チーム開発 - Qiita] |
2024年6月5日 (水) 14:57時点における最新版
問題発見、規定し、解決する一連のプロセス。作業療法士の重要な仕事。作業療法の存在意義。問題解決がなければ作業療法じゃない。
問題解決はフレームワークが有効なことが多い。
問題解決を行うのが、作業療法の重要な役割であるから、フレームワークのお勉強は大事である。
一般的なものまで含めて作業療法士はフレームワークに習熟しておくと、より幅広い思考が出来る。それは確実に、顧客である対象者の利益につながる。
作業療法の理論は、作業療法の問題解決の構造を抽出したものであるといえる。
温故知新
やってみるとそこから新しい問題が起こる。それは思いもよらないような。
デバッグ(プログラミング)
プログラミングにおけるデバッグの手法が参考になる、かもしれない。
詳細はプログラミングの記事を参照のこと。
要件定義
マルっと、ニード、デマンド、目標設定の話と重複する。
顧客に寄りそった要件定義は難しいが出来ると、協力な武器になりうる。
こじれない要件定義を行う方法(顧客は何に悩んでいるのか?をU理論で紐解き、Well-Architected Frameworkに落とし込む) #チーム開発 - Qiita