Dreyfus Model and Offshoring

プログラミングの本当の熟練度とはなんだろうか。

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

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

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

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

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

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

NRI

インド人の友達が最近インドに地所を買った。欧米に移住したインド人の間では母国の不動産に投資するのは良くある事らしい。

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

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

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

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

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

Distraction Free

Writeroom と言うマック用のノートソフトがある。

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

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

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

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

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

Outliers

ちょっと前にOutlierという本を読むのが会社の上層部で流行っていた。日本では「天才」と言うタイトルで和訳が出ていたみたいだ。本屋で安売りしてたので買って見たけどあんまり面白くなくて最後まで読まなかった。

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

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

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

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

Programming by Recipe

プログラミングにしろマネジメントにしろ経験や知識が必要とされる職業だが、既に解がある問題をまた解いている面が強い。既成の問題パターンと解が列記されているハウツー本がいっぱいあるのはそのせいだ。アメリカのプログラミング業界なんかそのものずばりでクックブックと称した本が売っている。これはこれなりに結構重宝するけど。

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

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

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

Managing Humans

Managing Humansを読んだ。シリコン・バレーでソフト開発会社の中堅管理職を渡り歩いてきた人が、その手の会社でチームを率いるのはどういう事か書いた本だ。

アメリカでこの手の職業を渡ってきた人なら、そうそう、まさにそうなんだよとうなずきながら読んでしまう。　すっごく面白かった。

この本で面白いのが人をステレオタイプで説明する事だ。日本語だったら草食系とか新人類とかいうあれだ。そんなのがなんで面白いのか。

日本人は自分をナントカ系と言ったりする時は、他人と同じだという没個性な意味で使う。個性にこだわるアメリカ人はそういったステレオタイプをあまり使わない。使う時は特徴を強調して思いっきりおもしろおかしくする。誇張されたキャラクターがステレオタイプなのだ。　これが自分の過去の経験と重なってやたらと面白い。

この本はステレオタイプを使ってハイテク企業の会社社会をおもしろおかしく説明しながら価値のあるアドバイスを織り交ぜている。　貴重な一冊かも知れない。

クラウドの悪夢 (3)

Intuitのシステムダウンに見るポイントをもう二つほど。

復旧しかけたIntuitのサイトにCIOの名前で謝罪と説明文を掲載していたが、システム停止の理由を「メンテ中に間違って電源を落とした」と説明していた。　この説明はITプロフェッショナルから見ればおかしい。

ミッションクリティカルをうたうデータセンターで電源の冗長化は最初の課題だ。一系統がダウンしたらもう一系統の電源に切り替えて運用を続行せねばならない。　おそらく実際はそれぐらいの事はしていて、何らかの理由で全系統を切ってしまわなければならなかったのだと思われるが、説明にそれが反映されていない。

それどころか簡単に電源が落ちて止まってしまうインフラしか持っていなかったと思わせる説明だ。ITプロフェッショナルだったら忌避すべきイメージを平気で出してしまっているのだ。

これはITをただコストのかかる必要悪と見なす昨今のアメリカのコーポレートカルチャーと関わりがある。　ITが技術革新による効率化をもたらしたのは昔の話で、アメリカでは肥大化したITは真っ先に合理化のやり玉にあげられるご時世なのだ。　IntuitのCIOもオペレーション出身でIT技術畑を歩いてきた人ではない。

ITのトップになるには、例えば掃除夫が間違って電源を切ってもダウンしない強固なインフラを築く能力より、コスト減らしの手腕の方が優先されるのがアメリカのIT社会の現状だという事だ。

会社の価値（株価）の維持・成長のためにどんどんコストを削り続け、簡単に止まってしまうようなインフラで運営されているようなクラウドやサービスプロバイダーは今もあるだろうしこの先も増えるだろう。クラウドはユーザー側には不透明なものだから停まって非常事態が起きるまでわからない危うさは消えない。　クラウドに信頼性は本当にあるのだろうか。

最後に、クライシスにあたってのソーシャルメディアの利用として、今回Intuitのサポート掲示板には商品企画部の人員が出てきて怒るユーザー達の相手をしていた。　同じ説明を繰り返すだけで大した事は出来なかったが、対外的に沈黙しているよりは遥かに好感が持てた。　Intuit側の人間は顔写真をアバターにしているので、例えば若い女性の顔写真付きで出てくるコメントにはキツい事を言いかねるような印象もあった。　今回のように会社に世間の眼が向いたとき、プレスリリースや記者会見よりTwitterやサポート掲示板の方が情報伝達手段としての効用が大きいのを実感できた。

クラウドの悪夢 (2)

Intuitのシステム停止から得る教訓はいくつもあるだろう。クラウドという点に関してワタシはこう見る。

まず、SAASのようなクラウド上のサービスに頼っているユーザーにはバックアップシステムが無い。クラウドが使えなくなればビジネスは完全停止。お手上げだ。自前でバックアップシステムも含めたインフラを整えなくてすむという理由でクラウドを利用しているから当たり前だが。

またクラウドを利用するユーザーは自分たちが使っているクラウドサービスの信頼性を判断する能力が無い。そんな判断ができるIT技術力に投資しなくてよいからクラウドを使うのだからこれも当たり前だ。

ユーザー達はITインフラの投資やメンテのコストを免れる代わりに自分のビジネスがいつどれだけの期間完全停止してしまうかわからないリスクを抱えているのだ。今回のように大規模なシステム停止があったりしてそんなリスクが知れ渡ってしまえばこの先クラウドの発展にも影響してくるだろう。

それを考えると将来システムダウンなどのリスクマネジメントはクラウドサービスの一部として提供されるようになるべきなのかもしれない。オプションとして別コストなら選択もユーザーの自由だし、通常サービスと違った利益マージンの設定にできればビジネスにもプラスだ。

また、そんなビジネスモデルが可能ならクラウド使用の安心を売り物にするセキュリティ市場が出来るのかも知れない。これは起業家達にとってはある意味チャンスでもある。　(続く）

クラウドの悪夢 (1)

ウチのカミサンは小さいながらビジネスをやっていて、クレジットカードの決済にIntuitという会社のサービスを使っている。　IntuitというのはTurboTaxやQuickenと言った一般向けの経理・税金ソフトのシェアでアメリカ一の大手の会社だ。　デスクトップソフトだけでなく、インターネット上でソフトをサービスとして売るという最近流行のSAASクラウドモデルも積極的に取り入れ、年商＄3.3billion , 円換算でざっと30億を達成している。

一昨日から昨日にかけてこのIntuitのオンラインサービス全部一斉にダウンし、なんとそのまま約24時間ダウンし続けるという事態が起きた。

これはユーザーに突如として深刻な事態を引き起こした。例えばウチのカミサンは売り上げも商品もあるのに決済が出来ないので出荷不能になってしまった。　カミサンのビジネスは決済できなくても売り上げは入り続けるので復旧さえすれば大きな損にはならない。だが、オンライン版の経理ソフトを使っていたユーザーは見積もりも請求書も作成できなくなり、カード決済をIntuitと直結して自動化していたユーザー達は売買のトランザクションを終了できなくなってしまった。

つまり積極的にIntuiのクラウドサービスを取り込んでいたユーザー達は唐突に売り上げが止まりお金の出し入れが出来なくなり、ビジネスが停止してしまうという悪夢の状況になってしまったのだ。

スモールビジネスにとってはこれは死活問題だ。怒ったユーザー達は他システムがダウン中なのになぜか動いているIntuitのサポート掲示板に殺到し、商品企画部らしい連中が懸命に相手をしていたが掲示板は炎上状態になっていた。

そして昨日、ようやく復旧したのは良いが、IntuitのCIOの説明によると全システムがダウンした理由が「通常メンテの際に間違って電源を落としたから」というお粗末な内容だった事が判明した。　（続く）

Hard days night

Office

トラブル続きの出張から帰って一週間。

ワタシの仕事は出張中でも山のようにあるので出張ははっきりいって好きでない。　今回はノートパソコンが壊れた事もあり、帰ってからの仕事のたまり方は悲惨なほどだった。

タイムリミットぎりぎりなそういう時に限っていろいろ問題がおこる物で、おかげで今週はほぼ毎晩徹夜するはめになった。　毎日少しは寝るけど、続けて寝ると脳がぼやけてしまうので３０分、１時間と少しずつ寝て、毎日平均３、４時間ぐらいの睡眠で過ごした。

これは実はヨットで長距離レースをした時に覚えたテクニックだ。昼夜ぶっ続けでヨットで走る場合、数時間ずつでクルー交代をする。　とはいうものの、自分の船だからスキッパーとしていつでも起きてデッキに上がれるようにしておかないとならない。　そのために少しずつ寝る事を覚えたのだ。

日中は部下に指示を出して手伝わせ、夜はヨーロッパと連絡し、ソファーで気持ち良さそうに寝ているカミサンをうらやましく思いながら、なんとか二つ重なっていた納期に間に合った。

昨日は久しぶりにベッドで普通に寝て、今日はまともな日曜日を過ごしている。

なんとかなるもんだね。　ほんとに。