とにかく机に向かう

　村上さんのエッセイにはレイモンド・チャンドラー式の執筆方法が紹介されている。とにかく机にむかって2時間は座っていろと。辻さんはトーマス・マンの方法、すなわち毎日朝9時から12時までは机に向かって仕事をする、について書いている。実際に辻さんもそうしたらしい。そのトーマス・マンの魔の山にはセテムブリーニ氏の魅力的な下宿の魅力的な立ち机が出てくる。ワインバーグ先生の「文章読本」にも書くための名案（迷案も）が満載されている。モンテーニュ様の塔型の書斎にも（寒そうなのだが）憧れる。ちょっとずつ真似してみている。
　書くべきものは小説やエッセイだけでなく研修のテキストや教案などたくさんある。とにかく質と量に関しあるレベルを達成しなければならない。仕事をするのは孤独で単調な仕事だ。でも続けているとライターズ・ハイ（ランナーズ・ハイの類推）みたいなものが襲ってくる。なんとなく麻薬的なところもある。（麻薬はやったことがないが。言葉のあやです。）
　別の話ですが、このようにほとんど世間とは交渉がなく（たまの講師稼業以外は）本をよみ何かを書き続けるという「生活」に実は昔から憧れていた。学生時代はそれで下宿にこもっていたし、会社員になってからも本当はそうしたかった。できなかったけれど。結局人間は自分のやりたい事をやりだすものであるようだ。

技法にはとらわれるな

　システム開発に関わる研修では多くの場合、ある手法を用いて研修を進め演習も行います。ここでの間違った態度は技法にとらわれて技法の使い方にばかり論議してしまうことです。似たようなことはプレゼンテーションでも起きて、プレゼンテーション画面に使われたテクニックにのみ感心してしまう。結果としてプレゼン技法は頭にはいったがプレゼンで言われたことは忘れたと言うことになってしまったりします。
　技法は手段にすぎず、それは論理を進めるためのツールにすぎません。演習である技法を使った図の書き方たとえば線の引き方がまっすぐがよいか曲線であるべきかといった些細なことに気を取られ、本筋のこの図の意味は誰も気にしていないといった状況はナンセンスそのものです。
　この傾向は物理学や天文学の世界でもありそうです。数式の操作にのみ習熟し、複雑怪奇な計算はできるが、その数式の意味することはよくわかっていないというケースです。数式は強力な道具ですが、単なる数学だけでは現実の世界は説明できません。
　テクノロジーが現代には必要不可欠ですが、テクノロジーだけでは十分ではありません。自分の思考を統合的に導くためのより深い思索が必要です。これには時間がかかりますが。

多忙なので勉強できないのではない

　忙しいから、余裕がないので勉強できないということをよく聞きます。いかにも最もらしいのですが、本当にそうなのかよく考える必要がありそうです。
　学生時代には勉強する暇はあったはずですが、勉強している人はどのくらいいたのでしょうか？一方、忙しい仕事の合間に新しいことを学び、一方では学んだことを他の人に伝えるための筆をとっている人はたくさんいます。そもそもそうでないと現代の社会は成り立ってこなかったでしょう。
　忙しいが学ぶ、余裕は気持ちの持ちようで生まれるという態度で暮らさないと、人生の最良の部分を味わわないうちに老いてしまいます。
　楽しいから学ぶというのが一番です。自分がいままで知らなかったことを知り、それによって人生が広々としたものに感じられるこの喜びをひとりでも多くの方に感じて欲しいものです。
　多忙なので勉強できないのではなくて、勉強しないから多忙なのです。ついでに言うと、業績不振だからといって従業員の教育をおこたる組織はさらなる業績不振に陥るでしょう。

研修理解のコツ－まず課題を調べよう

　はじめての事柄を学ぼうとする皆さん。どのように手をつけますか？基本を理解すべきなのでまず基礎事項をじっくり予習しよう．．．。これは大きな間違い（言い過ぎならば、時間の浪費）です。
　まず、テキストを後ろから見て、演習課題をみつけ、読んでみましょう。演習が解けない？当たり前です。ここで読み取って欲しいのは演習で何をやろうとしているかと、演習の状況とキーワードです。
　演習で何を問題としているか、これがこの研修の主題です。たとえば「Webアプリケーションの要件定義」。これがわかるということは研修の肝をつかんだということになります。次に演習課題の背景にある状況を読み取ります。これで、研修内容の背景と前提条件が理解できます。最後にキーワードを調べます。これはたいてい、設問で求められていることに相当します。「要件定義リスト」を書きなさいとあれば「要件定義リスト」です。
　これらを頭において、テキストの目次を調べます。テキストはどのような筋書きで主題に向かって構成されているかを見ます。ときには主題とはずれたこともありえますが、そこは講師の説明でストーリーがつかめるだろうと楽観視しておきましょう。あとは、キーワードがどこに出てくるかを調べたうえで、テキストを流し読みします。途中でむつかしそうな部分や単語がでてきても問題ありません。わからないことはまずは無視しましょう。全体の話の流れをつかむことが大切で、わからないことは９９％テキストの後ろの方ででてきます。
　「学ぶ」ということは、単に知識を得てそれを一つ覚えで繰り返すことではありません。どのように考えるかを学ぶという姿勢が大切です。しかもわれわれは得た知識を活用すなわち現場で応用しなければいけません。このためにも「課題」からはいるという姿勢は大切です。将来的には皆さんの多くは、課題を抽出してその解放は誰か適切な人に依頼するという仕事の仕方が求められます。

「ツール」でものを語らないこと

　仕事の内容や研修（演習）の内容を言わないで、使用した「ツール」の名前で話をすませる事があります。　「今夜は「ユースケース図」を書き終えるぞ」、とか、「今回の演習ではエクセルの表をかいてもらいましょう」などなど。
　一見わかりやすいのですが、システム屋さんの陥りがちな落とし穴にはまります。きれいなユースケース図を書くことに熱中して肝腎の顧客の業務機能が正しく反映されていなかったり、エクセル表は罫線や色つけしてきれいに書けておりマクロのテクニックもすばらしいが内容のデータが間違って記入されていたり．．．
　プロ野球選手は打席にはいるときにはヒットを打とうと思っているのであって、バットを振るフォームを見せようとはしていません。ぼてぼての内野ゴロでも結果としてタイムリーになれば良いのです。
　したがって、「今夜はあのお客さんのこの業務に関する機能をうまくまとめて機能の一覧を作ろう」、とか「課題の前半の文章を分析して売り上げデータの変化を表すような表をかいてもらいましょう」と言って欲しい。
　これには上司なり講師が気を付けて、何のために仕事や演習をやるのかを言葉で表現させるようにし向けることです。＃ところで今回もらった研修用のテキストには開発プロセスの説明図としてユースケース図やロバストネス図とかごまんと書いてあるがよわった。

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

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

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

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

吉田松陰と譜面台

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

昔の上司を思いだした

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

要件定義での落とし穴

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