ドレイファス・モデルというのがある。熟練度が低い初級者はする事を細かく指図されないとできないし、応用が利かない。　達人は臨機応変に状況を読み経験を元に結果を出す。これを5レベルに分け、各レベルでのスキルや応用ができる能力を明確にしたものだ。

アメリカで看護業界の人手不足と熟練度の低さが問題になった時期がある。看護婦をただの機械的な作業職と捉えた結果だそうだ。現場はマニュアルに載ってない事だらけなのに臨機応変な達人になりにくく、そのレベルに達しても報酬が見合わず達人の人材が定着しなかったのだ。

ソフトやシステム開発で問題になるのが、開発プロセスのマニュアル化だ。　作業や運営の取り決めは必要だ。だが、マネジメントがプロセスのマニュアル化を要求するのには、マニュアル化すれば人間を交換できると言う考えが根底にあるからだ。

極端な話、きちんと作ったプロセス通りにできれば誰でも良い。人材の入れ替わりが激しいアメリカではよくある考え方だ。　もう一段進めればプロセスを人件費が安いオフショアに持っていけば良い。　インドでもエストニアでも賢い人材はたくさん居るから、マニュアル化して（仕様を作って）言った通りに作ってもらえばいい。

でも実際そうだろうか。ちょっとでも高度なシステムだったらユースケースが100パーセント定義された仕様なんかできない。仕様に無い事はどんどん出て来る。　そんな時ユーザーに詳しい達人が開発側にいればコンテキストに応じた判断ができる。だから細かい仕様はいらない。でもオフショアにそんな事を求めるのは無理だし、オフショア先はターゲット業界と隔離されているから人材が達人レベルに育つ道がない。

ソフト開発とは、同じ物をより効率よくより大量に生産するのとは違う。毎回違うビジネスの問題を解く（ソリューションを作る）のが命題だ。　デザインパターンをどれだけ知っていてもそれを実世界の問題に応用できなければ意味が無い。　達人レベルというのはプログラミングの熟練したスキルを、ビジネスニーズに応じて応用する事だ。　だからドレイファス・モデルの上の方の達人・上級者レベルの人材というのはソフト開発のどこかになければならない存在だ。　クォリティの高いソフトを作るためにはそういう組織を作るところから考えるべきだ。

インドの銀行や宅地不動産業界は海外在住のインド人が一番のお客さんなので、Non Resident Indianと呼び国外からでも投資しやすいようにいろいろ便宜を図っているそうだ。彼は妹夫婦が隣の地所を買ったので二つ合わせてマンションを建てて分譲する事も考えていると言っていた。　そう言えば昔一緒に働いたカナダ国籍のモロッコ人も母国から二重に離れているのにモロッコに地所を買っていた。

海外在住の人間が母国に投資するというのは貨幣価値が違うからというのが大きな理由だろう。　でも、母国と言えど自分の目の届かないところに大きな投資をするのはそれなりのリスクが伴う。　それでも海外在住のインド人が母国に投資するのは母国との繋がりが太いからだ。　現にインド人の彼は将来アメリカで住む事を考えているが、いつインドに帰ってもいいとも思っている。

日本での場合をちょっと調べてみたら、非居住者が日本で不動産を購入しようと思ったら手続きだけでも目が回るぐらいややこしい。それに海外在住者には銀行が貸したがらないとある。他にもいろいろと手続きや書類があるし、有形・無形のバリアーがある。難しい事この上ない。

ワタシは印鑑もろくに持っていないのでおいとくとしても、日本は海外永住者が母国へ投資できるような仕組みはないし、流出した優秀な人材が帰ってきたがるような環境でもないのではないか。

インドの話を聞いた後では日本はちょっとひけを取ってるようだ。ちょっと残念な話でもある。

iPad上で使えるリーダーは、iBooks, Stanza, Kindleがある。実際に電子書籍を読む機能には大した差はない。　StanzaとKindleはiPad、iPod Touch, それにKindle はMac のノートパソコンでも使っている。

物理的な本と一番違うのが、Stanza, Kindle は買った書籍は登録したiPad, iPod, Mac 全部で読む事ができ、また現在読んでいるページは全部に反映される。　iPad上で100ページ目まで読んでから、iPod Touchで同じ書籍を開けると自動的にさっきiPadで読んでた100ページ目を開けてくれるのだ。　ソファーでごろ寝しながらiPadで読み、ちょっとスターバックスいってくるわ、と小型のiPod Touchをポケットに放り込んで屋外のテーブルでコーヒーを前に読みかけの続きを読む、といった事ができる。どの端末でも「同じ」本を読んでいるのだ。

こうやって電子リーダーは物理的な本と置き換わるだけでなく、読みかけの本をどの端末にも同じモノとして実在化できる。　という事は本やノートに書き込めたらそれがどこでも同じようにアクセスできる。　これが教科書だったら端末にさえアクセスできれば教科書を持ち歩く必要が無い。ランドセルなんかいらなくなってランドセル業界は大痛手だ。

ランドセルだけでなく、いつでもどこでも自分の読みかけの本ややりかけの勉強や仕事にアクセスできると言う事は、人間の間にどんどん差を作っていく。やる気があってできる奴はどんどん先へ行ってしまう下地ができてしまうのだ。

アメリカではデキル子が学年を飛ばして進級するのはよくある話だ。オレゴンで学校行ってたころの一番の親友は小学校で学級を飛ばした（一つ年下の）同級生だった。そういう人間達の勉強や仕事から時間と場所の制約を取り去ったら更なる可能性ができてしまう。

すごい世の中になったもんだ、とソファーでiPad抱えてゴロゴロしながら思う。

数あるノートソフトの中でこのソフトはとても簡潔だ。スクリーンには打ち込んでいる文章以外何も出ない。メニューだのリボンだのは一切無し。 文章を打ち込む事だけに特化している。

見た事あるな、と思ったらウィンドウズ以前の石器時代に全盛を誇っていたWordPerfectのスクリーンに似ている。　WordPerfectはもともとUnixやVMSのターミナルで使われていて、表示できる文字の数が限られてたので表示がミニマムだった。機能はいっぱいあったので使いにくかったが。　ところがWriteroomは目的の機能だけにわざと絞ってある。マック上で開けると、ごたごたしたサイドバーもメニューも何もないブランク画面が出て来る。後はもう文章を打ち込むしか無い。

このWriteroom、使っているアメリカの物書きやブロガー達はみな絶賛している。　文章を書く事に集中できるからだ。

そういえば石器時代には良くemacsでコード書いてたが、X11版は効率が落ちる気がしてターミナルをスクリーンいっぱいに広げて使っていた。お便利機能はぜんぶ試したり自分でlispコード書いて悦に入ってたが、今思えば本当に必要だったのはgdbでソースステップするのと、コンパイルやgrepの結果に飛んでいくのぐらいだったな。

今時Visual Studio でもEclipseでもやたらといろんな機能がある。ツールいじって一日つぶすのは簡単だし、すぐ目がそれやすい。　この手のツールには使い手の目標に絞って集中効率を上げようという考えが無いのだ。　プログラミングのメインは創作だ。とっかかりをみつけ、考えの流れを作り、それをエレガントで完成度の高い形にする。　途中で注意をそらせばそれだけ効率が下がる。　ツールには集中すべき事から目が離れにくい、簡潔でミニマリストな環境を作るという考えがもっとあっても良いと思う。

説明によると、まず興味や疑問が湧き、飽和するまで情報を取り込み、アイディアを孵化させ, 考えがまとまり、何回でも作り込んで現実の物にする。

これって理想とするソフト開発のステップそのものじゃないか。

頭の中に絵がかけるまで取り込んだ情報は孵化するみたいにプログラムとなって出てくる。形ができたプログラムはリファクタリングを繰り返して完成度を高めて最終形とする。

右脳、左脳というけど、高レベルのプログラミングの解というのはオンデマンドに問題を解くのと違い、非同期に頭の中でまるで孵化するようにまとまってくる。

日本の著名なギタリストは取り込んだ音楽が醱酵して出てくるんだと言ってたが、まさにそんな感じだ。そういう意味でもプログラミングと言うのは実はとてもクリエィティブなプロセスだ。

だから究極のプログラミング法というのはデザインパターンの丸暗記みたいな物ではなく、絵描きや物書きといったクリエィティブなプロセスにとても近いものなのではないかと思う。

この本によるとゴルフでも野球でもその道で一流の人は総計すると一万時間とかすごい努力をしてきたという話だ。どうやら上の連中はその辺に感心してたらしい。才能がある人間は多大な努力を続け偶然の機会を逃さないのだと教訓めいた事を言ってた。

エジソンは発明とは99%の努力と1%の霊感だと言ったそうだが、これをもって努力すれば報われると考えるのは、間違いだ。1%の霊感もない奴が100%努力してもおなじ結果はでない。

才能がある人間が時間を掛けて才能を磨き、機会がくれば一流になれる。才能がない人間には機会があろうがどれだけ時間をかけようがおなじ道はない。

一流の人達からインスピレーションを受けるのは意義のある事だけど、それが自分に当てはまるなんて思っちゃいけない。

テクニカルでもビジネスでもあるレベルに達すると、実世界のややこしさがいっぱいつまった問題を解く事を迫られる。この際の問題はバグとかではなく、ビジネス上の問題を解くという意味だ。この手の問題は特定のシナリオで起こる複雑多様な問題なので、解が無い。　探してもコピペできるコードが載っているレシピは無いのだ。

レシピを応用する事を第一に考えている２流、３流のプログラマーはこういう場面ではたいした仕事ができない。全体が見えず、自分で解を創造する訓練をしていないからだ。世の中にごまんといる２流、３流のエンジニアが作ったちょっとしたシステムやプログラムは中身がつぎはぎだらけの事が多い。全体像が見えないから次から次へと想定しなかった（想定できなかった）問題に当たるからだ。　できてきたモノがかなりの確率で肥大してて遅くメンテしにくいのはまさにこのせいだ。

目先の解答を探して来るのは誰でもできる。　実世界の混沌として束縛が多い問題をエレガントで効果的に解くのはそれではレベルが足りない。ビジネスにしろプログラミングにしろ一流レベルとは解を創造できるという事だ。

けど、幸いざっと勉強したらわかるようになった。　英語で元のニュアンスがわかっているから後は「このコンセプトは日本語でこう呼ぶ」と覚えれば良い。　大げさに書いたが、よく考えてみたらもっぱら〜子という日本語表記を幾つか（記述子、限定子とか）知らなかっただけだった。　そういうのは英語ではわかってるので、MSDN英単語100選にでてくる日本語は全然問題無くなった。

で、もうちょっといろいろとプログラミングで使う日本語表現を見てたのだけど、日本語と英語の違いに面白い物がある事を発見した。　例えば「内包的」という熟語は、英語だったらcontained, encapsulated, included とかいろいろなケースをひっくるめて使ってしまう。　でも、英語で「クラスに内包されたメソッド」といったら、自然とcontained を使う。　メソッドだったらencapsulatedは使わないけどメンバー変数だったら使うな。　includedはメソッドでもメンバーでも間違いとまで言わないけどなんか違う。だから使わない。といったニュアンスの違いがある。「辞書にはこう書いてあるから」という人がいるかも知れないけど、感覚で使いわけているボクタチアメリカジンにそんな事いっても通じないよ。

この場合、漢字熟語はニュアンスの範囲が広い、逆に言えば英語の方が細かいニュアンスの違いがあるという事か。　この辺、辞書には載ってないから日本語に取り入れる時ニュアンスがどう伝わっていったのだろうか。

スパムフィルターに引っかかって見なくて済むのだけど時々新手がスパムフィルターをかいくぐって来る、というのは前にも書いた。今回かいくぐって来たのは、「アナタと同姓の人が2004年に不幸な事故で亡くなった。その方の遺産1950万ドルを分配するのを手伝ってほしい」という内容だった。

この手のスパムメールはアフリカのどっかの国の亡命した政治家の隠し預金を動かすのになんたらかんたら、と金額に合わせたスケールの大きい話なのが普通だ。世界をまたに掛けた壮大なスケールのスパムメールがインターネットを飛び交う中、これはかなり気の抜けたストーリーに属する。

気の抜けているくせに、金額だけはご丁寧に1950万ドルを Nineteen Million Five Hundred Thousand とわかりやすく書いてくれている。あぁ、ストーリーがいたらない分、金額に注目させようと思ったわけね。なんだか情けない。

スパムフィルターもこういうのは「お前、かわいそうだから通っても良いよ」と通してしまうんではないかと思う。

読んでみたらわかんなかったんだな。 いやいや、英単語じゃなくて日本語の方が。 ちょっとショックだった。

プログラミングとかソフト開発はアメリカで学んだ。アメリカに住んで30年になるからそれは当たり前だが、カタコトの日本語使って馬鹿にされたくない一心で普通に日本語は使えるようにしてきたつもりだったのだ。なのに生業のプログラミングに使う日本語はあまりわからないのだ。

小説本とかは同じ内容を英語と日本語で読むことはしない。けどプログラミングは英語の本買ってまた同じ内容を日本語で読まないと対比して覚えられない。

日本語のプログラミング用語は英語からくるものだ。元の英語でもプログラミング用語は普遍的な意味とニュアンスが違ったりする。その意味は日本語に簡単に訳せるものではないから、似たような意味の日本語を当てはめてそのニュアンスを持たせる事になる。

この用語の英語と日本語の対比はバイリンガルでも知らなきゃ訳せるものではない。知識として取り入れないとならないのだ。いや、結構大変な話だ全く。

今回Codezineの記事を読んで言語って難しいなと再認識した訳でした。

- Posted from iPad