人と言う漢字には四千年の、重みがあります。
一人の一本のノの字を支える、もう一人の人がいます。それが夫婦であれば、二画は夫と妻です。これは別に夫婦である必要はありません。仕事であれば本田宗一郎と藤沢武夫です。井深大と盛田昭夫です。決して人は、ノの字だけでは生きていくことはできないと、このヒトと言う漢字が教えているのです。
今一人の若者がいて、以前のエントリーに書いたように才能があって、飛び立とうとしています。
この若者の運命は、恐らく、もう一人の人の存在が左右するでしょう。筆者の予知能力が強く示唆しています。運命なり、天命なり、知命とはこう言うことのようです。 KAI
和風肉豆腐
ウェンさんの麻婆豆腐もそうですが、豆腐料理って、どうして母の味がするんでしょう。今回の肉豆腐も、食べながら目一杯、田舎で一人雪の中に閉じこめられている老母が、まぶたにうかんできました。
で、作り方ですが、うまみのオンパレードです。
まず、カツオ節とコンブでダシをとり、ショーユ三兄弟（シーユーカオ・タイ醤油、ナンプラー、醤油）と砂糖で味付けします。このダシにバター炒めしながらタマネギのみじん切りを加えます。これに、絹豆腐、豚ばら肉を入れ、弱火でコトコト煮込みます。
仕上げに長ネギを入れて少し火を通し、塩で味を整え器に盛り、七味とうがらしをふりかけ水菜をのせて、ごま油を回しかけたら出来上がり。
二人でまるで競争するように、一気に口の中にかきこんで、あっという間になくなってしまいました。そのあとの、口の中に残る、何とも言えない懐かしいウマミ感覚。たまらず、ユーイチ君、おかわり！ KAI
年末の大掃除です。なぜ人は年末に掃除をするのか、別に年末でなくてもよさそうに思うし、しかも“大”までつけるし。しかし、かたづけるのは、家の中だけではありません。仕事もかたづけないといけないし、場合によっては人間関係もかたづける必要があります＾＾；。
かたづけると言う行為は、わたくしの中の“内なるもの”のエントロピーの減少を意味します。この内なるものについては、以前のエントリー内なるものと外なるもので触れていますが、この“内なるもの”の中にあるゴミ、シワ、ヨゴレ、ミダレ、フメイ、フジョーリ、フアンなるものを、“外なるもの”の世界へ排出することにより獲得するスッキリ感、サッパリ感こそ、かたづけると言う行為の本質です。
つまり、年末にセッセ、セッセと掃除して、スッキリ、サッパリと新年を迎えたいと言うことです。
が、しかし、これは本当でしょうか。
ウチのカミさんの掃除をする一番の動機は、“人が来る”からです。決してスッキリ、サッパリしたくて掃除をしているようには、端から見ていても、思えないかわりに、誰か我が家に訪ねて来ると言うとオニのようにかたづけ始めます。
この数少ない事例＾＾；から大胆な仮説を立ててみました。
人はなぜかたづけるのか、それは、“内なるもの”に新たなるものを招き入れるためのスペースを創るためである。
脳内活動において、私たちのマクロレベルではこの仮説は有効なように思います。脳内で情報が混沌としている間は、新たな情報を受け付けることはできません。新たな情報を受け付けるために、古い情報は忘却と言う手段でかたづけるとか、沢山ある情報を捨象と言う形で情報量を減らすとか、積極的に脳内の情報のかたづけをやっているように思います。
実際に、感じる脳（２）で取り上げた感じる脳（ダイヤモンド社、アントニオ・ダマシオ、2005）の中の記述を、筆者の都合よく引用すれば、人の意識は、脳内マップと言う形で、具体的な物質的空間的領域と結びついていて、つまりスペースを持つと言うことです。このスペースの中のお掃除（マップの変更）が実に0.1秒以下の時間スケールで行われている（p.162）ことは驚異的です。
仕事をかたづけるのも、次の仕事ができるスペースを創るためと考えるとなんとなく納得いきます。特に締め切りぎりぎりにならないと書けないレポートなどは、有限な仕事スペースから締め切り棒でむりくり押し出されるトコロテンと言ったトコロ、です。
と言うことで、年末の大掃除です。家の中を大掃除して、玄関にしめ縄かざって、神棚にろうそく立てて、心を新たにして新年を迎えます。心の中のスペースをあけて迎え入れるもの、それは、福の神です。
どうか来年も福の神が来てくれますようにと、心をこめて大掃除をします。手抜きするだけ福の神もご遠慮あそばすようですので、そこんところ、くれぐれもよろしくお願い致します。（って誰に言ってんの？） KAI
オンデマンドで番組を配信し始めたとたん、番組枠と言う機能単価の概念は消失します。替わって登場するのが情報単価と言う概念です。これは、ケータイによる楽曲などの、消費者への直接的な情報配信をはじめとして、インターネットの検索広告に至る、通信全般に適用できる概念です。
もちろん通信そのものの機能としてケータイ1台月と言う機能単価がありますが、これにコンテンツがからむとすべて情報単価で説明できる世界になります。更に広告モデルでは、この情報単価が小数点の世界になると言う話は、モデル指向はなぜ必要か（４）の中で述べたとおりです。
つまり、広告モデルによって番組をオンデマンドで配信しようとすれば、従来からの番組枠をスポンサーに販売する広告モデルを捨て、新たに小数点の情報単価と言う広告モデル（とそれを実現する仕掛け）の導入が欠かせないと言うことです。もちろん、広告モデルによらない、情報性の高い番組の有償販売も考えられますが、現在のテレビ番組の中にこれが該当するのはごくわずかであることは、みなさん無条件で同意いただけるものと思います。
さて、それでは小数点の情報単価と言う広告モデルとは、具体的に何を指しているのでしょうか。これを一言で言うと、番組とコマーシャルのアンバンドリング化、です。番組枠の広告モデルでは、番組枠とコマーシャルが一体不可分なものでした。もちろんスポット枠もありますが、番組と番組の間にあるだけで番組枠から独立であるわけではありません。
これに対して、アンバンドルされたコマーシャルは、番組が固定化されません。過去の膨大な蓄積された番組の中から一定のルール（この部分がキモになります））にヒットした番組に、該当するコマーシャルが配信され、その実績によりスポンサーは料金をテレビ局に支払います。
現在放送されている番組に、任意のコマーシャルを挿入する技術は、CMキャンセラーの技術を使えば簡単に実現できます。更に、デジタル放送ですので、簡単にCM企業のホームページとリンクできます。この仕掛けであればネット専用のコマーシャルを制作する必要もなく、現状流しているCMをそのまま流用できます（広告会社との権利関係は残りますが）。
KDDIとクアルコムの提携は、ケータイ向けの新たなるテレビ局開局の動きのようですが、このあたりのことを考えて動いているとすれば、相当大きな台風の目になるのは間違いありません。 KAI
放送と通信、この二つの言葉の周辺がまたもやにぎやかになってきました。まだネットにはあがっていないようですが、今朝のNHKのニュースで報じていたKDDIとクアルコムの提携の話はなかなか興味深い内容です。しかし、ケータイにテレビのコンテンツを流す話は、ワンセグもそうですが、なかなか簡単にはいかないようです。
それは、放送にも通信にもビジネスモデルが必要で、いかなる技術が開発されようとも、このビジネスモデルが明確に見えてこない限り、世間一般への普及などおぼつかないからです。楽天のTBS買収問題が頓挫したのも、このビジネスモデルを打ち出せないまま放送と通信の融合などと言う抽象論に終始したことが根本の原因であると、筆者は考えています。
そのビジネスモデルです。結論を先に書くと、放送と通信、どちらも主流のビジネスモデルは広告モデルなのですが、互いのモデルの中身は全く異なるモデルであると言うことです。
詳しく説明する前に、以前のエントリーモデル指向はなぜ必要か（４）の復習から。
定額制モデルはＰ＝「機能単価」、従量制モデルはＰ＝「情報単価」
この機能単価と情報単価の違いが、そのままモデルそのものの違いになることを、このエントリーで説明しました。実は、今回取り上げている放送と通信の、それぞれの広告モデルの違いも、この機能単価と情報単価の違いによって明確に説明することができるのです。
放送における広告モデルは、Ｐ＝「機能単価」となります。これは、放送と言うビジネスモデルでは、番組と言うコンテンツを販売しているのではなく、番組枠と呼ばれるバラバラに分解された放送時空間をスポンサーに販売しており、放送時空間＝機能と見なせることを意味しています。従って、放送における番組と言うコンテンツは、その番組枠と言う「機能」のパフォーマンスを高める役割をするだけで、番組そのものがコンテンツとして販売されてはいません。
この考え方をワンセグに適用すると、視聴率に支えられた番組枠のパフォーマンスを、そのままワンセグに持ち込めないことは簡単に理解できます。しかし、統計上の数値である視聴率に替わって、全件の視聴状況を把握できることに注意する必要があります。つまり、ケータイ向け機能単価メニューを別途設定するだけで、その費用対効果を瞬時に測定できるようになります。これは視聴率にかわるとてつもない大きな武器になることをテレビ局側は理解する必要があります。（現状、まったく逆の理解にとどまっていますが）
一方で、通信における広告モデルと言うと、この放送時空間＝機能と言う概念が成立しません。なぜなら、テレビと言う閉じた世界の放送時空間が有限であるのに対して、通信における時空間である番組枠はいくらでも無限に増やすことができるからです。
そこで通信における広告モデルに、Ｐ＝「情報単価」が登場するのですが、すでにヨッパですので、続きは、アシタ。 KAI
以前書いたように日経バイトの最終号である2006年1月号が届きました。
特集記事「本誌記事に見るコンピューティングの21年」は、さすが、1984年創刊の雑誌だけあって、懐かしい記事が満載でした。こうして20年余りの「歴史」を俯瞰すると、コンピュータの歴史って、まだまだ草創期なんだと、筆者は強く思います。
世間では、もうビジネスモデル的に可能性の余地があまり残されていないなどと、まことしやかに喧伝されていますが、この「歴史」を見れば、まったくそんな話ではないことがよく分かります。
生き物の進化の歴史になぞらえれば、やっと生き物としてのハードウェアが整って、これから大脳系と言うソフトウェアの進化に比重が移ろうとする、まだまだ一合目の手前です。つまり、コンピュータはソフトウェアがなければただの箱とは、よく言われるセリフですが、今までの歴史が通信を含めた「ハードウェア」の歴史だったってことです。
あと20年たって2005年を振り返ってみたら、この言っていることの意味がよく分かると思います。ハードウェアとソフトウェアは車の両輪です。進化するハードウェアに見合うソフトウェアが自然と生まれ育っていくと言うのは最適環境論と言う、昔からのKAIの持論です。
はてさて、ヒトはどこまで進化するのでしょうか。 KAI
とりあえずメールとネットが見れるようになりました。
メールは、会社のサーバーに入ってチェックするのですが、保存されているメール（3000件）すべてを読みに行くので、あわてて本体をすべて削除しました。考えれば当然なのですが、今後外部でB5ノートで見るためのものとどう使い分けるか悩ましいところです。
ネットの方は、このBlogが全然ダメでした。このレイアウトではうまく表示できないようです。さすがにYAHOO!やGoogleは全く問題なしで、まあそこそこ使えそうです。
で、肝心の本体の使い勝手ですが、さすがにスライドして出てくるキーボードで文章を作成するのは苦労しそうです。KAIをご存じの方はすぐおわかりになると思いますが、指の太さに対してキーの大きさが小さすぎます。それでも意外に大きくはずさなければ、右手と左手の人差し指でピッピッピッピッと正確に入力できるのは驚きです。
気になるのが、画面のガラス。以前もアップルのニュートンでガラスを割ってしまって（もちろん筆者ではなく某yoot氏がですが）、ガードの板がほしいところです。いちいちケース袋に入れるのはめんどくさい。
そこで、本体の設計を、いろいろ考えてみました。やはり手帳のように開封型が基本です。それも360度開封型です。つまり今のようにキーボードなし操作は360度反転させてやれば可能になります。この状態で通話もできるし、ネットの操作もできます。それでは最初の閉じた状態ではどうか。もちろん電話の受信はできます。ミニ窓で最小限の情報も表示できます。では発信はどうするか。う〜ん、360度反転して使用するしかないか。
まああまり悩んでも仕方のないことですが、こう言った考えるきっかけを提供してくれる製品こそ、価値があると、筆者は強く信じています。ウイルコム、健闘を祈る。 KAI
今届いたW-ZERO3で遊んでます＾＾；。12/9の時点であっと言う間に初期ロット売り切れ、と言うことで急遽抽選。これに見事当選しました。
たった一つの違い、話ができるかどうか、箱から出してセットアップしてまず一番に、自分のもう一つの携帯に電話しました。この手帳のように四角い物体で、まるで未来のテレビドラマのように電話する、これが筆者の予知夢だったのです。耳にあてて話す快感＾＾；です。
しかしやっとです。
前回書いたように、このケータイはPDAに電話機能がついたのではありません。フォルム的に、ケータイの進化形が、この手帳型であると言うことです。ながらく携帯電話は、固定電話の受話装置の呪縛から抜け出せませんでした。海外で発売されてきたスマートフォンでさえ、この例外ではありませんでした。
しかし今の世間のケータイを通話以外の機能で使用しようとしたら、あんな小さな画面では、実際問題使い物になりません。機能が増えれば増えるだけ、そろそろ従来のケータイに限界が来ていたと言うことです。
さて、これをどう使うか。星条旗のカウンターは今までどおりエアエッジで繋がったB5ノートのまま。役に立つのはアウトドア。特に筆者の場合は週末のテニスの間。オンラインサービスを始めて以来、365日24時間メールをチェックする必要がありますが、これはとてもケータイメールでは無理。かと言ってB5ノートを持ち歩くのも大変（今実際にこれをやってますが＾＾；）。
更にフルブラウザで基本的にアプリは自由です。つまり、星条旗以外の処で飲み食いしながら、しっかりWebチェックが可能になります。いやはや楽しみ、楽しみ。 KAI
またまた小室直樹パパが吠えてます。日本国民に告ぐ（ワック出版、小室直樹、2005）、週末の散策で見つけた1冊です。
小室パパの頭の中はだいたい見えていますので、パラパラパラと途中を読んだだけで、15分くらいで読破＾＾；できました。
生年台関係なく、フツーの論理思考ができる人間であれば、朝日やTBSやその他マスコミの論理誘導の欺瞞性に、とうに気付かれておられるはずで、これをBlogが加速している状況は、筆者にとって快感すらあります。
おそらく本質は、マスメディアであるとかBlogとか関係なく、「編集」機能のオープンソース化、すなわち、価値観の自己組織化現象であることは、間違いありません。またまた少々ヨッパですので、続きは後ほど論じますが、いまやっとこう言う議論が、むかし居酒屋のカウンターではなく、500人の読者がいるところの星条旗のカウンターでできる、これこそ真実です。 KAI
牡蠣と春菊のペペロンチーノ
この時期、筆者はひたすらかきフライを食べ続けるのですが、事務所を引っ越して以来、このおいしいかきフライを食べさせてくれるお店が遠くなってしまったのが、ツライ。と思っていたところで、かき料理はマッテマシタ。
作り方。オリーブオイルでみじん切りにしたニンニク、鷹の爪、オイルサーディンを炒める。片栗粉をまぶした牡蠣を入れて両面に焼き色がつき表面がカリッとなるまで火を通す。白ワイン、塩、コショウ、あらかじめサッと湯どうしした春菊、生姜の千切りを順番にいれ、全体をからめて出来上がり。
しっかり炒めものの基本に忠実ながら、あの牡蠣のホクホク感とこれに春菊がからみついて、まったくこれは牡蠣料理の新境地ですよ、ユーイチ君。牡蠣のホクホク、ニガプリ、春菊のサクサク、ニガプチ。ホクホク、ニガプリ、サクサク、ニガプチ。料理とは、音楽ですよ、ユーイチ君。 KAI
えびのチリソース−フレッシュトマト仕上げ
1ヶ月ぶりのウェンさんの料理です。ウー・ウェンのおいしいよ!うちのご飯の、p.76です。
普通のえびチリソースは、ピリリと辛くて、えびが殻つきで固いイメージがあるのですが、今回のウェンさんバージョンは、まったく逆。チリソース自体にボリューム感があって、しかも、とってもまろやか。えびはいつものようにプリウマ。
作り方は、KAI的にはちょっと高等テクニック。むきえび、背わたをとって水洗いし水気を切る。トマト、皮を湯むきし種を取りざく切り。玉ねぎ、みじん切り。で、まず炒め鍋で、サラダ油を熱し、えびを入れて色が変わったら一旦取り出す。その鍋にサラダ油を足し、にんにく、しょうがを炒め香りが立ったら、豆板醤、玉ねぎを加え、かさが半分くらいになるまでよく炒める。これにトマトを加えて、時々混ぜながらソース状になるまで4〜5分煮つめる。オイスターソース、塩で味を調え、えびを戻し入れて、全体に味を絡め、コーチェンしてできあがり。
トマトと玉ねぎによる、このまろやかボリューム感。なんて新鮮な感覚なんでしょう。これにむきえびがはまりすぎ。この感覚、むかしどこかで体験したような・・・思い出せない・・・、と言いながらあっと言う間にご飯と一緒になくなりました。 KAI
お客様は神様です、古くから言い古されたセリフです。
しかし筆者は、一度としてお客様に（心の）頭を下げたことはありません。喜寿になった母親が、むかし筆者が若いころ、こう言う筆者を心配して、「頭を垂れる稲穂かな」と言う言葉を使って、二度三度筆者をたしなめた記憶があります。
今回、みずほ証券、東証のトラブルを見ながら、はてさて、一体お客様は誰？お客様と主人の関係が、すべての事例で正常に機能すれば、筆者の考える限り、問題はあっと言う間に解決します。ここに書いたとおり、お客様をもてなすのは主人です。決してサーバント、召使ではありません。
ソフトウェアビジネスに欠けているのは、このお客様と主人の関係と言う概念です。東証がお客様？サーバントは富士通？では一体主人は誰？
コンピュータユーザーのみなさん、ぜひ覚えてください。あなたは決して神様ではありません。もしあなたが、お客様と呼ばれたいなら、誰を主（ぬし）とするか、はっきりと自覚すべきです。もし自覚できたなら、相手は“主人”であることもついでの自覚をお願いします。 KAI
松下幸之助も本田宗一郎も井深大も、みんなものづくりに励んだ実業家です。これに対してリクルートを創業しながら戦後最大と言われる構造汚職事件を起こして失脚した江副浩正は、自ら起こした就職情報と言う広告ビジネスを虚業と考えていたそうです。これを虚業ながらより盤石のビジネスにすること、彼の実業と考えるコンピュータビジネス、不動産ビジネスを取り込むことに突き進んだ結果、彼はリクルート事件を起こしたと言われています。
コンピュータビジネスも不動産ビジネスも実業かどうかは直ちに首肯しかねますが、実業と虚業を区別することは簡単です。それは“ものづくり”かどうかです。
del.icio.usがYahoo!Incに買収されたことをきっかけにネットビジネスの方向性に関する議論があちこちで起こっていますが、この議論には実業と虚業と言う観点が不可欠なような気がします。
どう言うことかと言うと、ビジネスには常に実業と虚業の部分があり、このビジネスの企業家がどちらに軸足をおいているかどうかで実業家か虚業家かが決まってくると言うことです。例えば不動産ビジネスでは、次々とビルを建てていくこと自体は実業そのものですが、そこからあがる収益を無視した単なる転売による不動産売買のビジネスは、虚業以外の何者でもありません。今マンション販売で問題を起こしている企業家は明らかに虚業家です。
ネットビジネスにおいても、その仕掛けを構築して最終的に巨大資本に売却することを“あがり”と考える限りそれは虚業であり、虚業家です。
ここで注意しないといけないのは、筆者は、実業家がエライ、虚業家はエラクない、と言っているわけではありません。そうではなく、実業家は実業家として、虚業家は虚業家として、天から与えられた分をわきまえなさいと申し上げているのです。
冒頭にあげた実業家はみな、もちろんものづくりに励みましたが、それを売上に結びつけるための販売に筆舌に尽くしがたい努力してきた人たちであると言うのも、紛れもない事実です。同様に戦後の流通と言う虚業を実業の地位にまで押し上げた中内功は、メーカー指向のものづくりを消費者指向のものづくりへと、戦後のものづくり革命を推進した一番の功労者であると、筆者は考えています。
かように実業家は虚業を、虚業家は実業を、互いに尊重しあい、敬いあう、そう言う関係であるべきだと言うのが筆者の考えです。しかしまた両者は、その間に深くて暗い河のある男と女の関係と同じように、なかなかお互い理解し合うことのない関係なのかもしれません。 KAI
KAI「いい仕事をして、人生をおえたいと思うよ。」
YUM「そのためにがんばっていて、しかも楽しんでいるのに、どうして其処にたどり着く前の段階で虚しい涙があふれるんですか？」
KAI「人は、涙を流すたびに、流した涙の量だけ、涙川の上流へ行くことができるのだよ。そこが涅槃の世界なんだよ。」
YUM「ってことは、これは今すぐには解決しない問題だと言うことですか？」
KAI「そうだよ。人は人生と言う流れの中にとどまることはできないんだよ。たとえ解決してもそのとたんに、次の悩みが出てくるんだよ。」
こうして、おぼろげながらソフトウェアの設計とは何かをつかんだ上で、市販の書籍や社内の技術ドキュメントに目を通すと、書いてある内容が面白いように頭の中に染み通っていきます。今では、どういったアプリケーションをつくりたいかを言われれば、またたくまに必要な道具立てと仕掛けが頭に浮かんできますが、当時は、そのための技術情報が圧倒的に不足しています。そんな状況の中で、手にするもの、目にするもの、耳にするものすべてが、ソフトウェアを設計するための貴重な情報、知識となって自分の中に蓄積されていく、これを実感できる毎日が、快感でした。
技術情報と言うものは、具体的に、このソフトウェアを設計すると言う目的があって初めて意味をなします。筆者の場合、以前書いたように、今では常時十数件の設計案件をかかえていますので、このヒントになる情報に出会うと、心の中で小躍りしながらむさぼり読みます。
この流れはインターネット時代になってますます加速しています。もちろん検索エンジンで直接収集するpull情報もそうですが、CNET、IT Pro、@ITと言ったIT系のトップページに掲載されるpush情報の中に、見逃せないものがいくつかあります。更に個人のBlogのいくつかも、毎日のチェックが必須です。
そして欠かせないのが、やはり週末の本屋の散策です。以降の話は以前の負のエントロピー問題の通りです。と言うことで週末の明日は昼間ずっと忙しいので、これから本屋へ出かけることにしましょう＾＾。 KAI
今まであえて書いていませんが、マニュアルを読んでわからないことがあると、ソフトウェア工場の技術者に電話して直接聞いていました。もちろん文法を教えてなんて話は一切受け付けてくれませんから、このマクロのレジスタ1にセットされるビット0がなんたらかんたらと、マニュアルに書いてない話を訊くついでに、そもそもこのマクロの使い方ってこれでいいんですかねえ、なんて調子でもともと訊きたかったことをちゃっかり教えてもらっていました。
これも、実際に現場でやるうちに、こちらのほうも詳しくなって、VSAMマクロがシステムエラーを起こす原因を尋ねたら、某国際ビジネスマシン社もそうなっているから移行性維持のため仕方ないんだってことで、こちらで回避策をとったりしてました（そう言えばこのときからですよ、システムバグの回避策に明け暮れる日々の始まりは＾＾；）。
システムが順調に立ち上がると、今度は山のように運用上のトラブルが発生します。ただすでにマニュアル30冊を読破していましたので、現象が見えると、あ、これはあのマニュアルのあそこらへんに書いてあったやつだなんて、仕舞いに何ページかまで覚えてしまう始末です。
とは言え、順番にマニュアルも当てにならなくなります。まもなくして新しくTSS端末が導入されるのですが、これによって今までの共同計算センターの運用方式が一変します。センターのオペレータがジョブの依頼を受けそれを実行し実行結果（印刷物）を返す方式から、ユーザーが直接TSS端末を操作しコンピュータを使用する方式への転換です。
ユーザーは、オペレータと違って、何をしでかすかわかりませんから、想定外の使用に耐えられるよう、あちこちにプロテクトをかける必要があります。当時のOSには、こういったユーザー管理の機能が十分に備わっていなかったため、KAIが自分で作ることにしました。平日は業務に追われて休日しかやる時間がありません。自宅の近くの喫茶店に朝から晩までいて自分だけ理解できる仕様書を作り上げました。入社2年目の5月のゴールデンウィークのことです。これをフリーチャートにして更にコーディング、デバッグと完成したのが7月頃でした。これと似たような機能を持った有償プロダクトが、この2年後にメーカーからリリースされ、その後VM（仮想マシン）システムへ切り替えるときに、KAIの作ったシステムはその有償プロダクトに置き換えられたのでした。
しかしこの仕様書づくりは本当に苦労しました。今までは、どこかを探せばなにがしらの答えが見つかる問題ばかりでした。それが今回はまったく、手本すらありません。その時から筆者が問題を解くときの口癖が、「ディスクが・・・、ディスクが・・・、」。こう呪文をとなえると、その後に続いて答えが出てくるのです＾＾；。
何も手本がない中で一体何を手本にしたかと言うと、「常識」です。一旦コンピュータを離れて、人間世界でやるんだったら、一体どうやればいいか。ふつうはこんなことはこうやるよな、こうしたらこうやり、ああなったらそうやればいいんだよな。当時のKAIにとって技術情報の蓄積はほとんどないに等しい中で、大学時代、体育会の硬式庭球部（一応一部リーグ）できたえた部員管理と言う“立派な”リアル社会の常識がありました。
TSS端末からアクセスしてくるユーザーを庭球部の部員に見立てて、彼らのコートの中でのふるまいをシミュレーションしました。そうするといままで皆目見えなかったことが、まるで彼らが自由にテニスをプレイするがごとく、ユーザー一人一人の振る舞いが目の前で展開され始めたのです。そうか設計するってこう言うことだったのか。ここでもKAIは天の啓示を受けます。 KAI
作成した運用マニュアルに基づき、年末までの2ヶ月間、デバッグセンターで実機確認を行います。一緒に、共同センターの稼動管理システムも作ることになりました。今から丁度30年前です。
この春の入社以来半年あまりで、すでにアッセンブラーとCOBOLのプログラムは何本か書けるようになっていましたが、このシステムはPL/1で書くことになりました（自分で好きにしていいと言われて新し物好きのKAIが選んだ結果です＾＾；）。もちろんまわりに誰もPL/1を知っている人がいませんので、頼りになるのはやはりマニュアルだけ。これも3日くらいで読破して、文法は理解できました。
問題はフローチャート（実際はフリーチャートを書きましたが、フリーチャートについてはこちらを参照ください）。どう言うものをつくればいいかは、すでにリアルOS時代のものがありますから、これをバーチャルOS用にアレンジするだけで簡単です。それをどうやればPL/1で書けばいいか、ここでも最初はまったく手付かずのまま、あっという間に1週間、2週間が経って行きました。
結局これは年末までに出来上がらずに、本番が始まってから、本番マシンを使って完成させるのですが、今から考えると笑い話のようなことを必死でやっていました。1日のシステムの稼動状況をプロットするために、開始から終了までの時間で秒単位でループさせて、文字通り、いつまで経ってもループして終わらないロジックをつくったり、マルチで稼動している時間を計算するのに悩んだり、それを印刷するのにそもそも改ページって何か分かってなかったりと。しかしそれもマニュアルの記述を穴が開くくらい読み倒して、実際に何度も何度もやり直しているうちに、すべて解決して行きました。
こうして、この大型の汎用機を、今のパソコンのように一人で使い倒したおかげで、最新鋭の大型コンピュータの仕掛けが、新入社員と言う立場ながらすみからすみまでわかるようになりました。偶然だったとは言え、新機種への移行に当たって他に誰もわかるものがいない中で、神が与えてくれたチャンスだったのです。
かくしてマニュアルを読めばすべて解決すると言う確信にいたるのですが、やがてそれでは解決できない問題にぶち当たります。 KAI
マニュアルを読め
当時の汎用機は、メインコンソールとサブコンソールで操作し、後のプログラムの実行はカードリーダーから、パンチカードを読み込ませて行うものでした。これ以外の端末は専用回線で接続された、オンラインリアルタイムシステム用のダム端末が何台か接続されているだけです。本番稼動後、RT（リモート）端末やTSS（タイムシェアリングシステム）端末が追加されていきますが、当時の環境には現在のようなクラサバ環境は影も形もありません。
こいつをどうやって使いこなすように設計するかって、オイオイ入社1年目の人間にそんなこと頼むほうがおかしいよとぶつぶつ文句言いながら、積み上げられた30冊のマニュアルを読み始めました。参考になるのは、リアルOS時代の運用マニュアルだけ。気持ちはオランダ語でかかれた医学書を初めて翻訳する緒方洪庵（全然違うけど＾＾；）。
しかし人間と言うものは不思議なもので、ただの一度も使ったことがないバーチャルOSマシン（この作業を終えてから年末まで死にそうになるくらいかわいがってあげました）が、4日目くらいから見え出すのです。会社の近くの銭湯に入って下着を替えながら会議室に泊り込んですでに1週間の二度目の土曜日。やっと理解できました。理解できるとなんとも簡単。粛々とリアルOS版運用マニュアルをバーチャルOSの言語に書き換えるだけ。やっと月曜の明け方、できあがりました。
その月曜が、農水省の統計情報部担当者との打ち合わせの日です。何とか間に合いました。
その後、技術会議側にも説明するのですが、その担当者が東大の統計学の権威奥野教授の奥様。この奥野女史相手に筆者は、とんでもないミスをしでかすのですが、この話は墓場までもって行きます＾＾；。この経験をするまで筆者は、大学時代、ゼミで論文講読をやった程度で、人生これほど集中して短期間に書物を大量に読んだ経験は初めてでした。
ある意味、この経験が、その後の筆者のソフトウェアと言うエンジニアの支えになっています。ソフトウェアエンジニアは量との戦いです。量を制御することこそ、ソフトウェアエンジニアリングの本質ですが、この話を始めると長くなるので、これはまた別の機会に。
そうして得た結論が冒頭のマニュアルを読めになるのですが、まだまだドラマのような展開があります。（続く） KAI
相次いで日経バイトと日経WindowsPROが休刊するので返金すると言ってきた。日経バイトは創刊当初から購読し、途中つまらなくなって永らく止めていたものを、ついこの間また読み始めたとこでした、トホホ。
日経BP社には、会社購読を含めて十誌前後の定期購読で、随分売上に貢献していますが、今までこれらは筆者にとって貴重なIT技術関連の情報源になってきました。その情報源が、そう言えば確かにこのところ、@ITなどネットである機会が増えていると言うのも事実です。
ふりかえると（このあたりが相対的年寄りのイヤなとこやけどムシ！）、それは、筆者が新入社員で入ったその秋、翌年の年始早々本番稼動が始まる農水省システムの運用マニュアル作成の為に、1週間会社に泊まりこんだ時に始まりました。
当時の農水省は汎用機2台を、本省統計情報部と技術会議（農水省の研究機関）が共同の計算センターとして運用していました。その汎用機2台を、今回、新たにリアルOSのマシンからバーチャルOSマシンへ置き換えると言うのがミッションです。当然がごとく当時まわりに、このバーチャルOSを知っているSEは誰もいません。おい、KAIやれってなもんです。
会社に泊まった1日目は仕事になりませんでした。新入社員ですからバーチャルOSどころかリアルOSさえ理解できていません。そこにあるのは新OSのマニュアルが30冊。これを使って新年から始まる共同計算センターの運用設計プラス具体的な運用マニュアルをこしらえ始めました。（続く） KAI
このところものづくり魂にもとる出来事が相次いでいますが、筆者にすれば信じられない思いで一杯です。
技術者にとってものをつくる喜びは、他の何事にも代え難いものです。しかしそれ以上の喜びがあります。それは、苦労をしてつくったものを使ってもらう喜びです。車であれば、快適な乗り心地を、マンションであれば、快適な住み心地を、お客様に感じてもらえることこそ、技術者にとって至上の喜びであります。料理人が、つくった料理を目の前でウマイウマイと言って食べてもらえる、これこそが料理人にとってもっともやりがいを感じるときであることと一緒です。
ところが今、技術が高度化すればするだけ、このお客様の「顔」が見えないところで、ものづくりを強いられる傾向が強くなっています。ソフトウェア開発の現場では頓にその傾向にあります。
そこで私たちは、以前のエントリーに書いたとおり常にエンドユーザーを相手に仕事することを一貫して行ってきました。もちろん技術者とエンドユーザーの間に営業が入ることはありますが、営業はあくまで窓口であって、すべての対応は技術者が直接行います。その上、これも以前のエントリーのプログラマと言う職業のすばらしさの中で書いたとおり、技術者と言っても私たちはプログラマが直接エンドユーザーと話をして作業を進めていきます。
このやり方に対してすぐ出てくる言い訳が、大規模開発ではそれは無理だ、と言うものです。しかし私たちのシステムも200万ステップと言う大規模です。確かにハードウェアの世界では上下の分業化は避けられませんが、ソフトウェアは逆にこの上下の分業化は不要であるし、害悪さえあります。なぜ不要であり害悪かと言えば、これも「ソフトウェアの上流、下流論の本質」で述べたとおり、つまり、ソフトウェアには上流と言う概念しかなく、下流と言う概念は実は、上流概念の詳細化に過ぎないからです。上流概念しかないものを上下に分けたために、下流におかれたプログラマから、お客様の「顔」が見えなくなっているのです。
このお客様の「顔」を見ながらソフトウェアを開発していくための技術が、先日のオンライブテクノロジーであると言うのは言うまでもありません。 KAI