要求の理解にも外国語の習得と同様な努力を

　外国語の習得において、中級クラスでの困難はどうも、ヒアリングのようです。相手が何を言っているか解らない。言葉面はわかるが、何を言いたいのかがつかめない。一応返答はするものの、本当の理解に基づいた会話になっていないのでお互いに気持ちが悪い。時間もないのでうやむやのまま会話が終了する。もちろんこれではビジネスに使用するなど望むべくもないということになりましょう。
　ここで一手間かける必要が有ったわけです。つまり、相手の言うことを注意深く聞くとともに、勇気を奮い起こして不明点をこちらの言葉で伝え、お互いに疑問点の解消をはかるように議論を行う。いくつか生まれてきた相互理解をベースとして論理的により深く広い理解に進んでいく。この際助けになるのは、相手の立場の理解、大げさに言うと相手のよってたっている文化をどれだけ理解しているかです。
　要件定義の際に接する顧客は外国人だと思ってください。顧客の言っていることには彼のよってたっているビジネスの世界があります。これを理解することにつとめましょう。その世界の語彙を習得するのが第一段階、ビジネスの仕組みの概要も理解しておき顧客と話します。誤解は当然発生しますので、それをお互いに解消するように議論をリードします。
　一方顧客からみても事情は同じで、われわれは奇妙なシステム用語を話す外国人（宇宙人？）です。顧客にわれわれの立場をうまく説明しましょう。
　こうしたコミュニケーションには特有の「感」というか「運動神経」が必要なのかも知れません。ここは「文科系」の方の腕の見せ所なのでしょう。

「事実」の吟味とモデル化

　たとえば天文学の場合、遠い天体の観測から得られる情報の量は、理論構築に必要な情報量にくらべ非常に少ないし、観測に伴なう誤差がおおきい事が認識されています。そこで、得られた情報の精度やその解釈方法を徹底的に議論します。
　システム開発で顧客の持っている情報をわれわれも「観測」して、それを解釈して顧客のビジネスモデルや要求モデルを作るわけですが、このときに得られた「観測」事実をどの程度吟味しているでしょうか？顧客の発言やビジネスの表面上の姿を、無条件に信用して、モデル作成に使っていないでしょうか？
　顧客が「こういったので」そのとおり作ったのに、なぜ使い勝手が悪いと文句をいわれなきゃならないの．．と不平を言うずっと前に、自分が正しいと思っている顧客からの取材事項をじっくり考えて、その正しい解釈はなにか、見落としはないのか、顧客そのものの発言の正確度はどうなのかを振り返ってみておく必要があります。
　天文学ではものいわぬ天体が相手ですが、顧客はうまくアプローチすれば、物を語ってくれます。これで安心するのではなく正しいシステム化のための重要な手がかりとして大事にする心構えが重要でしょう。

吉田松陰と譜面台

　今日の話題は、ブログ表題｛ITエンジニアの教育」）とは直接関係ありません。
　そもそも吉田松陰を思い出したのがきっかけ。座敷で正座して読書する場合、ちゃぶ台では姿勢が悪くなります。そこで吉田松陰先生や、要するに昔の人がよくつかっていたらしい、足のついた書見台が欲しいと思いつきました。自分で作るのが良さそうですがまずは手近なところで間に合わないかと考えて、息子に以前買ってやった譜面台を物置部屋に探しにいきました。なんとか引っ張り出したが、錆だらけ。錆というより曇がホコリと混じって金属の表面が白っぽくなっています。
　こんなとき効力を発揮する杉の精油のポリッシュ剤を取り出して、磨きをかけました。一応綺麗になったな．．と思いポリッシュ剤をしまおうとしたら、ビンをひっくり返してしまい、あたりが油だらけ。
　つかっていた布巾で余分な油をふき取り、もったいないので部屋中の木材部の効果のありそうなところを磨きまくりました。フローリングの床も輝いたし、いくつかの埃だらけの家具が美しく輝きだしかなり満足。一度終了して布巾はすてたのですが、思い直して、窓や網戸のアルミサッシの表面も磨きました。光沢がなく白っぽい錆状のものに覆われていましたが、これもつやを取り戻しました。
　ここ数年は、いろいろなことがあり、住居の手入れも怠っていたなと感じました。余裕をもった生活をしないと、心も錆びそうです。精彩を失うと心だけでなく、形にも現れます。
　いろいろな職業の修業時代の重要な教育要素として掃除を扱うことが多いのですが、身の回りを整えるやり方にその人の心のあり方や余裕度が現れるからでしょう。うん、やはり最後は教育でまとまったか。前言撤回します。
　譜面台の読書はなかなか気持ちイイですが、やはり本物も欲しいな。

昔の上司を思いだした

　部屋の整理をしていたら、昔書いたメモが出てきました。どうも上司の退職送別会のスピーチネタだったようです。
　Ｔさん（上司）に教えられたこと。
　１．部下には教えない（自分で学ばせる）
　２．酒（酒を飲みに誘うと必ずつきあってくれる。自分から部下は誘わない。無粋な話ぬきで楽しい酒。）
　３．人生は楽しむ。（趣味：単独行登山、旅行、外国語の独習）
　４．表面的マネジメントはなさらない。（なぜか自然に部下は一生懸命やってしまう。なにか問題がおきるといつの間にか責任を取ってくれている。しかも失敗して落ち込むとうまく慰めてくれる。）
　こんなＴさんに、ずいぶんいろいろと「教わった」と思います。昨日今日と仕事がうまくいかず悩んでいたのですが、このメモが見つかったと言う事はＴさんがまた「がんばれ」と言ってくれてるんだなと思います。
　

要件定義での落とし穴

　われわれはソフトウェア屋なので、問題を「表面的に」発見すると、問題の本質（それは海水のなかの氷山のようにその大部分が隠れている。）を見抜こうとせずに、ソフトウェアを使って問題の一部分を解決する方策を懸命に考えはじめる癖があります。それはまるで現在の日本の各種問題へのアプローチに酷似しています。本来、何がしたいのかを見失った議論は不毛でエネルギーを無駄に消費していきます。
　まず、「問題」そのものの大きさとその構造を理解しないといけません。どうもこのためには、いままで受けてきたソフトウェア教育では足りないことが有るのかも知れません。学校で真に「学んで」きた方々は、身につけてきた能力と技術がここで十分に発揮できるでしょう。
　「問題」の本質をとらえるにはどうするか、どう分析・構造化するか、はその人の全人格的能力を傾ける必要のあるところです。経験も必要ですがそれ以上に問題に立ち向かう謙虚な態度が必要です。想像力も必要ですし、想像したことを実際のデータで検証することや、実際のデータおよび顧客の談話を理解する能力も必要です。
　理解することと、理解したことをいかに記述するか、に関しても重要な能力が要請されます。しかもそれらは切り離せないことなのです。

業務領域のモデリングは「科学」であり「芸術」である

　要件定義を行うときにはＩＴエンジニアは顧客に取材して、様々な顧客毎の固有の概念を「言葉」によって整理しモデルによって整理します。まずはシステム化対象業務の世界を理解しようとつとめ、共通の語彙を模索することで顧客との相互理解度を高め、このとき曖昧な用語を使わないように注意します。モデルを使って顧客の世界を記述して検討することが理解を促進します。
　考えてみるとこれは自然科学や社会科学で新しい概念を考え仮説を作り新しい世界の理論を検討していくこととまったく同じです。芸術の世界でも同じで絵画や小説は芸術家が世界を理解するためのモデルと思えば、似たようなものと言うことができましょう。
　なんにせよ、人間がまじめに未知の世界を理解しその中で生きて行くための指針を得るための模索活動はこのようにならざるを得ない。そのようなモデルを創出できる人類の脳はすばらしい能力を持っていると言わざるを得ません。この能力は誰でも持っているので十分活用しないといけないですね。もちろんそうすることを楽しみながら。なおかつ人類の人類たるゆえんはこれを協力して多数の人間でやることが出来ることなのだろうと思います。もちろんバベルの塔というアンチパターンは会ったので、その落とし穴には注意したいです。

大きな意味でのビジネスマナーを学ぼう

　４月も中旬になりました。たいていの新人ＩＴエンジニアの方々はすでに現場に配属されているか、その準備中と思います。
　ビジネスマナーというものを入社直後に教わったと思います。挨拶の仕方や名刺のやりとりに代表されます。これらは「まあ、サラリーマンはみんなこうするんだろう」ということだけで学んでは実はもったいない事柄です。
　入社前の勉強時代とちがい、われわれの仕事はすべてが共同作業です。共同で、一人では出来ないような大きなあるいは複雑なあるいは高度な仕事ができます。ここに喜びを見いださなくては会社人生はつまらないものになってしまいます。このための基礎となるのが「ビジネスマナー」です。
　そしてもっと考えて欲しいのは、ここまでに習った「ビジネスマナー」とはそのすべてなのか？と言うことです。「ビジネスマナー」を広義にとると、人または会社組織の間でいかにしてビジネスつまり仕事を進めていくべきかの倫理にまでたどりつきます。ここまでの事は新人時代だけではとても学べませんので、とりあえず簡単な形だけのビジネスマナーを時間の許す限り教えて、あとは実地で学んでくださいねというのが新人研修です。
　このあと長い年月をかけて、大きな（広い）意味のビジネスマナーを体得し、仕事に生かすことにより、自分の給料も上がるでしょうし、会社も収益があがり、社会に貢献も出来るようになります。このようなことをふまえた上での「挨拶の練習」をやってください。

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

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

企業内教育担当者も研修発注時は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日コースの方がたくさんのことがやれるという事になります、大学生は自分の時間を与えられるのでその時間をいかに過ごすかが問題であるし、企業内の教育では自分でいかに学ぶ時間をとり、意欲をみずからかきたてられるかが鍵となるのでしょう。