「問題解決」よりも「問題発見」を

　「問題解決」よりも「問題発見」を重要視すべきと言うことです。
　過去の学校・企業教育は知識を切り売りすることで成り立ってきましたし、それになれた受講者は、ほぼ間違いなく教場で講師が何か質問はありますかの問いに答えようとしません。そのくせ与えられた演習課題は要領よく解いてしまう。演習問題に潜ませた問題点に気づくことはない。気づいたとしてもそれは演習出題側の不備と見なしてしまい、要するに思考停止に落ちいってしまう。
　この様な方が、顧客のところに出向いてもうまく顧客の状況をつかんで「真の」問題解決をする良いシステムの提案が出来るとは思えません。顧客の述べる問題点を表面的に聞き取るだけになりはしないか？
　限られた時間でいかに有効な質問をするか、そのためにはどのような事前準備が必要か、インタビューの場ではどのように振る舞うべきかを、時間がかかっても練習していただくしかないでしょう。

企業内教育担当者も研修発注時はRFPを書きましょう

　ごく基礎的で当たり前だが、かえってそのせいで行われていないのが外部に研修を頼む場合のRFP作成です。
　通常のシステム開発の仕事ではこのような手抜きはしないはずですが、「どうせ教育だから」という油断が有るようです。きちんと契約しないと結局失敗すると言うお定まりの結果になります。
　できあいの研修にせよオーダーメードの研修にせよ、RFPは書かないといけません。そしてきちんとそれを理解して対応してくれる業者を選びましょう。
　そしてRFP作成も一緒にやってくれる業者にはその対価も与えましょう。要するに教育コンサルタントですね。コンサルタント料金の形式がとれなければやむを得ませんから講師料や研修開発費に含めてあげてください。こうしていかないと社員のレベルアップがはかれません。

プロセス（手順）を学ぶ際の注意点

　たとえば、「要件の定義」をするには「現状把握」をして「要求獲得」をしてそして．．．と研修のはじめに学ばなくてはいけない場合があります。この際には以下の注意をしながら学ばねばなりません。

（１）そもそもこれからあるプロセスたとえば「要件の定義」を議論する必要があるが、議論をなりたたせる前提として、なんらかのプロセスモデルが提示される必要がある。このモデルの導出から話しているときりがないので、講師が用意したモデルを提示します。
（２）このモデルを無理矢理覚えろというのではないが、議論のためにはモデルを頭に入れていただく必要があります。講師が説明します。
（３）受講者は、プロセスモデルを「理解した」（何を言っているかわかった）ならばその適用を考えてみる。自分の課題に即して、このプロセスを頭の中で動かしてみる。考えられる状況を書いてみる。うまくいくだろうか？
（４）プロセスはこの通りでよいか考える。いったん考えたのと違う使い方があるだろうか？たとえば並行して作業できるか、繰り返しが必要か、省略や、追加すべきプロセスがあるか？　もちろんこれも書いてみる。
（５）受講者は自分なりのプロセスモデルを書いてみる。
（６）受講者は自分のプロセスを吟味してみる。Okなら次へ進む。まずければ（３）へ戻る。

ぐらいのことを頭と手で考えながらやらないと、「公式＝プロセスモデル」を機械的に当てはめようとする悪い癖が出て、せっかくの研修時間が無駄になるわけです。

さてこのような思考訓練をしながら学んでいく余裕が持たせられるでしょうか？　なお、この思考訓練の中でいくつかメモを作りますが、これがあとで大いに役に立ちます。

仕事と生活は切り離せない

　朝会社に行き一生懸命に仕事をし、ストレスを解消すると称して帰りに酒を飲み帰って寝てまた朝に．．．
　このような生活はサラリーマンの鏡かも知れませんが、そこに何とか仕事と生活の喜びを感じるようになりたい。そのような思いが高じて独立してしまいました。やってみた結果は（まだ完全には出ていないのかも知れませんが）「よかった」というのが本音です。月々のサラリーがなくなったのは大きな痛手ですが、それを補ってあまりあるのは、コンパクトな生活の中で考えながら仕事もしていく。自分のペースを守ってあるいは興味が生じればペースを変化させて学んでいけること。そしてその結果を本当に望んでいる方々に伝えることが出来るのは今までにない無上の喜びといえましょう。報酬はあくまでもそれについてくるものと自分に言い聞かせる。

　ITエンジニアリングのなかに数々のノウハウがありますが単にそれを適用する事だけを考えるのでなく、そのノウハウの出自や背景そしてその幅広い適用をゆっくり考えながら仕事を進めていくのは興味深い。一方でわれわれ人類の科学技術の進化の様子を（約４０年のブランクのあと）たどることの楽しさもそれに加わります。まあ言ってみれば第２の人生でしょうし、学徒に戻ったとも言えます。

　１日２４時間がすべて仕事でもあるしすべてが趣味でもある。生活そのものを自分の考えで統御できるのが良いところです。

良い課題を発見するのが良い研修

　最近放送大学に入り、ある講義を取ることにしました。もちろん怠惰だった実際の学生時代とはちがい、きちんと予習をおこたりません。（放送大学の手引き書によると単位を与える前提として１時間の講義に当たり２時間の自己学習が課されています。）予習では、テキストを見ながら、講義のあらすじを自分で書き出し、わかっていることは確認し、疑問点を見つけだして時間の許す限り解決策を調べて置きます。講義中に解決できればいいなと思うわけです。
　実際の講義を聴くと、驚くのは、テキストの筋書き通りには必ずしも講義は進まないのと疑問は解決されるどころかもっと増えるまたは深まることです。それはそうだよなと言う気持ちとなるほどという気持ちになります。
　一方通行の講義なのでこうなるのは当たり前なのですが、もっと深い意図も含まれていそうです。
　疑問あるいは課題は、単純なものならその場で解決できますが、理論の背景とかその応用上の意味づけなどはそもそも解答が得られない、あるいは一見して得られたとしても立場が変わる（一般にはその領域の理解が進む）ともっと課題が進化（深化）してしまう。
　そもそもそのような課題を見つけることが重要なのではないか？と感じはじめました。
　学生時代や研修受講時に何とかして「良い課題」を発見しその解決に向けて自分をコントロールしていくことが大切なのでしょう。すると、研修終了時によくわれわれは「アンケート」をとったりとられたりしますが、「よくわかりました。満点です。」というアンケート結果は必ずしも喜ぶべきでなく、「わかりませんでした」という結果には「ある疑問を抱いていたが、その疑問はもっと深くなった、困った。でも自分で解決しようと思えた。」という意味が含まれているのならば、大成功と思われます。ただし、その疑問つまり課題の解決に向けての学び方のヒントを与えてくれるのが良い研修・講義なのでしょう。

コミュニケーションの基本は相手の立場の理解

　研修の障害の第一は、相手が（講師からは受講者、受講者からは講師や他の受講者）なんでそんなことを言っているのか理解せずに、言葉面だけを理解（記憶）しようとすること。
　これをさけるために、講師は通常まず自分の紹介と称して自分の立場を説明する。いわく「XXのコンサルをこんな形でやっているのでこのコースのテーマに関してはこんな興味を持っており、今日はこのような視点でしゃべりたい。」
　次に研修のテーマの概略とその目的を説明し、研修で学ぶ項目（目標）を説明し、参加者の前提知識と受講後の達成レベルを述べる。ここまでは基本なので、これをやらない講師ならそこで席を立ってもよい。（でも受講料は払ってるので無理ですが。）
　講師側は、受講者に自己紹介をやらせたり、初期の質問をしたりして、受講者のプロフィールを探ります。これも基本技。
　受講者としても質問の前に、自分の立場を簡単に説明した上で、疑問点を聞くのが効率的です。いきなり質問をしていきなり答えようとするとほぼ間違いなく、とんちんかんな応答になります。
　多分このような事は、教場にいるのでわかる事であって、実際の仕事の場でのコミュニケーションでは程度を問わなければ行き違いが毎回起きていると思わなければなりません。不幸な行き違いを防ぐ一助としてまずは研修の場で基本を確認しながら話を進めましょう。

IT研修における「演習」の取り組み方

　各種の研修で、いわゆる「演習」課題がだされます。演習をうまくやることで研修の効果が何倍もちがいます。
　効果的な演習への取り組みへのヒントをすこしあげてみます。
　（１）多少ゆるめに取り組む。
　（２）正解は一つではない。
　（３）何のための演習か？を常に考える。

　（１）は、怒られる表現かも知れませんが、「まじめになりすぎるな」ということです。スポーツ選手は知っていると思いますが、筋肉をリラックスさせないと良いプレーができません。われわれの場合も「頭の筋肉」をリラックスさせないと思考力が弱まります。せっかくの問題、できないと恥ずかしいとばかりに、必死で取り組むのは百害あって一利なし。演習なので間違っても別に困りませんよという態度の方がよくできますよ。大事なのは笑顔やユーモア。

　（２）は最近の受験勉強を勝ち抜いたばかりの人だけでなく、会社で昇進競争に勝ち抜こうと努力される方も陥りがちな落とし穴にご注意くださいという事です。われわれの取り扱うシステムの要素全般に言えるわけですが、課題に対する解決策は一つではありません。よりよい回答があるだろうと考えるかもしれませんが、それもありません。せいぜい言えるのは、「ある条件下でこの解決策はより好ましいなぜならXXXと私は考えましたので」という表明が他の方（たとえば顧客）に認められれば、よかったねと思いましょうと言うことぐらいです。解決策やその考え方を整理するやり方を練習するのが演習課題への取り組みの趣旨と思いましょう。

　（３）どのように考えるべきかを練習すべきなのですが、せっかく練習したことをどのような場面で活用すべきかまたは活用すべきでないかについて常に頭に置きながら演習を行いましょう。

イメージを伝える手段ペルソナは大学の講義でも使える

　放送大学講義を受けるための予習をしています。一般には１時間の講義に対し２時間程度の準備が必要とされています。（もちろん前提となる知識が足りない場合はこの限りではありません。）
　たまたま今やっているところは天文学の基礎となる各種物理法則のおさらいです。端的に言うと公式が出てきます。ローレンツ力の公式や理想気体の状態方程式と言ったものが
　（１）何を意味しているか
　（２）公式はどの場合どのように応用できるか
知っていなければ議論がすすみません。
　これをうまく伝えるには受講者のペルソナを意識して、このペルソナにいかにして上記のことを伝えるかが大切になります。なお、伝える「もの」はこの講義の場合概念的なイメージです。講師の頭の中にあるイメージをうまく受講者の頭に移し替えなければなりません。もちろん単にポンチ絵のイメージを覚えさせるという低いレベルの話ではありません。
　ビジネスシステムの開発時にもこのような場面は数多くありそうです。

要件定義にペルソナ法で魂を入れる

　せっかく作ったシステム、懸命に要件定義し、設計し、実装したのにさっぱりお客さんが喜ばない。これがわれわれSEの一番がっくりすることですね。
　正しく作るのではなく、正しいシステムを作れとよく言われます。「正しい」かどうか判断するのは顧客です。その顧客に役立つ、使いやすいシステムを作ればいいわけです。
　顧客とよく相談すれば良いのか？そうですね。でもそれだけでは不足です。実際に要件定義をするときに顧客の要求をとらえ、推測し、補いながら「正しい」システムの姿をとらえないといけません。
　このためにわれわれが使える手法の一つが「ペルソナ」法です。ペルソナつまり典型的なエンドユーザーの実際の性格や行動パターンや価値観などを具体的にとらえ、このエンドユーザーはいかなるシステムであれば満足するのかをイメージして要件定義を進めます。
　ここでイメージしたペルソナは設計や実装時の担当者にも、イメージを共有してもらいます。それによりシステム開発中の誤解を防ぎ、顧客またはエンドユーザーに使いやすいシステムを供給することができます。
　このペルソナ法は、実は、社会生活のいろいろな場面で応用されています。たとえばお医者さんや看護師さんの世界で「病気をみるな、患者をみよ」とか、「患者の生活全般をよく見た上で治療方針を立てる」と言われますが、これはペルソナ法の典型的応用でしょう。　皆さんもペルソナ法を学び、システム開発だけでなく、生活に応用しましょう。

放送大学、入学者の集い

　4日日曜日は弘明寺の神奈川学習センターで入学者の集いが10時からあったので出席しました。横浜市営地下鉄の駅が近いとのことで行きましたが、うっかりして手前の上大岡で降りてしまい、さんざん探してもわからず。駅前の不動産屋さんの店員さんにうかがったら、そもそも駅が違いますといわれ、初めて気がつきました。そんなことで10時ギリギリに到着。主たる目的の学生証の引換番号を渡されたが190番。その後も20人くらい到着していたようなので200人強のひとが参加していたようです。立ち見も出ていました。全国の今期入学者は8万人であるとか。全盛期は15万人くらい入学したようです。
　お年を召した方が大部分です。若い人もちらほらおられます。若い人は忙しくて出席していない可能性があると思います。
　先輩（文字通り）のお話などありましたが、修士課程も終了したとか、1992年から何回も入学しているとかの猛者が多かったです。最後にサークルの勧誘まであり、大学生生活に戻ったような懐かしさです。
　ところで私のとった科目の授業（放送）は土曜日からすでに始まりました。45分のビデオ放送ですがあらかじめ2時間以上予習してノートを作っておいたので内容は（まだイントロダクションですが）よくわかりました。逆に言って自分で勉強しないと45分の一方通行ではほとんど学べないということです。15回シリーズ（15週間）で1単位ですが放送時間では1日7時間としても2日弱です。企業の教育の1日、2日、3日コースの方がたくさんのことがやれるという事になります、大学生は自分の時間を与えられるのでその時間をいかに過ごすかが問題であるし、企業内の教育では自分でいかに学ぶ時間をとり、意欲をみずからかきたてられるかが鍵となるのでしょう。