« 12.11 情報は見せ方 | ココ | 12.13 強制決済 »
2005年12月12日
SEにはファシリテーション
ステップ1：理想的な会議をイメージする。ちなみに。
ステップ2：現状を観察する。
ステップ3：理想と現状のギャップから問題を考える。プログラム言語の上達もこのステップですよね。上級者のきれいなソース（理想）を見て、自分のソースを見る（現実）。そしてその違い（改善点）を考えて、よいソースをまねながら上達していく。上達方法はJavaもVisual Basicも同じです。
facilitation
【名】 容易｛ようい｝にすること［もの］、円滑化｛えんかつか｝、簡易化｛かんいか｝、促進｛そくしん｝あ～なるほどね。僕はコメントの書き方があまり上手くないけど、今まですばらしいコメントの書き方をした人のコードを見たことがないからなのかぁ。
いや、確かにこのステップは重要やと思う。教えてもらう以外にも、やっぱり自分で見てそれをまねるってことが上達には大切よね。僕も実際にコードは「ベーマガ(マイコンBASICマガジン)」(めっちゃ懐かしい!)を見てそれをそのまま入力してたところから覚えていってたし。VBのコードはDDJJ（Dr.Dobb's Journal Japan?)にあった西田氏の連載見て、APIとかの世界に引き込まれていったしなぁ。まぁ、今書いたことはソースコードの書き方、じゃなくて理想とする動作の実現の仕方(つまり設計の方法)やけどね。
あと、ここで使われている「ファシリテーション」は「円滑化」の意味やけど、そのほかにも「簡易化」というのも同じくらい重要よね。
理想と現実を比較して、「どうすればいいのか」を考えるときには問題点の1つ1つをできるだけ単純化する、つまり簡易化する必要がある。そうすることで、一見複雑に絡み合っていて解決困難であるような課題も細かく分け、分類し、その結果独立した複数の問題として見ることができる。こうすれば、改善点も見えやすくなる。
お手本がある場合は改善点は見て判断することができるけど、そうでない場合はこうやっていくしかない。しかし、理想と現実を比較する前に現実がどうなのか知らなければならない。ただじっと聞いているだけで比較ができるのならばもう立派なファシリテーターやと思う。そうでない人に役に立つのが「メモ」を取ること。話の焦点を把握するにはちゃんと記録しておくことから始めないと難しい。整理してメモを取る＝簡易化ってなるわけ。
そして、ソフトを設計するにもこの「簡易化」こそが肝になる。漠然とした動作イメージをプログラムコードにしたい場合、コンピュータは所詮単純な命令しか実行できない。単純な命令が積み重なって、「やりたいこと」ができるようになる。よって、実現したいことをできるだけ細かく区切って、単純化することこそがキーになるっていうことやね。それができれば、後は流れを組んで、その流れのとおりに実行できるようにコードを作っていけばいい。
会議の進め方も、ほとんど同じやと思う。
学生委員も、上回生に求められるのはファシリテーターの役割が強くなってくるよね。それを一番実感するのは1回生が新プロ会議やってるときとか、2回生会議やってるときとか。
ファシリテーションに関連して、以下のページも表現方法の参考になるなぁと思った。
By ただ at 23:16 カテゴリー ; mein Erbe , 仕事関係
« 12.11 情報は見せ方 |
12月の記事
| 12.13 強制決済 »
トラックバック
このエントリーのトラックバックURL:
http://pinmarch.sakura.ne.jp/mt/mt-tb.cgi/306
