パテント、著作権

LINEで送る
Pocket

■パテント

 

以前は良く出願していました。

 

一番、大きな範囲で出願したのは、緯度経度を地図上にプロットし、DBと直結させる部分でした。これが取れればチャリンチャリンだったのですが、ダメでした。GISの黎明期のことです。

 

あるいは、道路で最短経路の算出とか、寄棟屋根の簡単なかけ方ロジックとか、キーボード入力とか、出しましたね。

 

パテントや著作権で稼げるのがいいわけです。音楽や書籍の印税のように、自分のプログラムでチャリンチャリンがいいなぁ~

 

 

■著作権

 

昔はいい加減でした。平気でコピーしたりして……。

 

だが、それは間違いというのに否が応でも気づかされた事件。昭和のころです。

 

アメリカのコンピュータメーカーが新製品を発表した少しあとに、山の上の怪しい研究所の大きなシャッターのついた建屋に11トントラックがやってくる。丁寧に梱包された四角い箱。付録のソフトウェアもたっぷりだ。

 

必死で分解解析して、互換機ビジネスの展開をはかる。

だが、そのコードの意味がわからず、消せない行。デットロジックと思いつつ、消して問題が起こっては困るから、残すことになる。

 

トラップ!(そりゃ、質問されても分からないですょ~)

 

マテリアル調査、このロジックは何かを参照したのか?

誰が作ったのか?

そのSEは過去にアメリカのコンピュータメーカーのOSでアプリを開発したことのあるSEなのか?

 

……

 

この調査によって、相手のコンピュータマシンでアプリを開発したことのあるSEは国産メーカーの開発チームから外れた。

頭のなかに経験知として、知らずしらず、その方法が身についているというのが排除の理由。普及の過程には必ず何かを参考にしたりしてきたから、これは大きな出来事でした。

 

ブートストラップ、メモリ、ハードウェアレジスタ(割込)、I/Oデバイスの仕様、ミニマムの環境のみ与えられて、自分で時間管理やガーベージコレクションを作成して、アプリを動くようにしてきた時代があったから、コンピュータの動く原理が分かっているが、いまはブラックボックスが多いなぁ。

 

なんせ、高かったから、メモリとか。

だから、いかに効率良く、美しく作るか、そのお作法が重要だった。アプリの基本設計はデータ仕様とセットだったから、いまのように冗長(設計が不十分で、いきなり画面に打ち込むスタイル)には少々戸惑うことがある。

 

良いお作法は残したいです! な。

LINEで送る
Pocket

プログラミング

LINEで送る
Pocket

■プログラミング

 

大掃除をしていたら、昔のテンプレートが出てきた。長いシステム設計の経験を思い起した。

最初に行ったのが、機械制御、NC制御のプログラムだった。3次元で鉄やアルミを加工する。多軸で刃物干渉のないように、粗削りから仕上げまで軸の回転や送り、複数の刃物を制御しながら、モノを作る。三角関数がメインだった。1年間、朝から晩まで休みなく油にまみれた。周囲は中卒の工員が多かったので、数学を伴う制御プログラムを私が担当した。航空機部品は厳しい品質を求められた。

 

次は主にアセンブラ。モトローラ、ザイログ、インテル。8ビットだ。そこから、16ビットアセンブラに進んだ。マクロアセンブラだ。PDP-8、PDP-11、VAXといったDEC社のもの。コンパイラもビット操作付きのものだ。大型のグラフィックパネルの制御。画素を切って、文字を起こし光らせる。地道な図形処理だ。CADもカーネル部分を設計した。インストラクションオーダーという概念があって、命令にかかる時間が書かれた早見表をポケットに入れて、タイムチャートを頭に描いて、適切な命令(時間管理PG)を書いていく。パッチも当たり前で数字だけでずっとデポジットする。恐ろしく頭脳を使った。そして、Cネイティブ。当時、マシン室は禁煙ではなかった。タバコの煙で8インチフロッピーディスクドライブが良く故障した。紙端末。ASR端末。

 

夜中にハウスマシンの端末を5台ぐらい自分のID(クローン)でログインして、これはソース修正用、これはコンパイラ用、これはデバッグツール用、これはエグゼ生成用、これはスナップショットダンプ解析用として定義して、シーケンスを組んでデバッグのマイ自動化工場を試みた。社員の中で圧倒的に生産性がトップになった。帰宅すると、一部上場企業の副社長から電話がくる、すぐに現場に出てこいという、メチャクチャ働いた(笑)。気づいたら事業部の責任者。

 

次がUNIXと汎用大型機の図形プログラム。この時代のソフトウェアはハードウェアの付録だった。ここで図形処理を本格的に行った。生まれた初めて数学を本気で勉強した。写像、行列演算、多項式などなど。周囲で最も多かったSEが東大・阪大数学科大学院の出身者。INとOUTを押さえて、鵜匠(リーダー)に徹した(笑)。アン王女が見学に来た時のデモプログラム部分のデータを作った。PL/1、COBOL、FORTRAN、M(32ビット)アセンブラ。3次元のオブジェクトの概念(GKS、PHIGS)。マッキントッシュを評価して、操作性の研究、また、マウスを設計。マニュアルは全て英語。マシンの裏で良く寝た。暖かい風がファンから出て、ファンの静かな周波数が子守歌に聞こえた。

この頃、図形挿入可能なワープロ(OHP用)を空き時間を利用して自作。会社に提案。500円の図書券をもらった。数か月後、会社がそれをパッケージで売り出していた(笑)。図形のデータ標準に関わった。文字もストロークだった。ロケットのシミュレータや衛星データのプロセッサを設計。1億円のディスプレイ。電子銃で打った管の時代。VTAM(ネットワーク)のデバッグで3日間完全徹夜。

 

それから、医療機器、マルチメディア、ロボットなどなど。インターネット上での初GIS。北九州からCD-ROM600枚を預かってきて、1データに仕立てた。「北海道から沖縄までネット上でスクロールさせます」、こう言った。カナダのGISソフト、画面は英語(笑)。信ずる人がいなかったので、サブスクの独占契約をした。後日、「破棄して欲しい、意味を知らずに契約した」と言われ、騙してまで金儲けをしたくないから、会社に内緒で書類が紛失した(もう時効(笑))。担当者全員行方不明(💦)。

 

情シスの地位をあげるため、100%PureJava認定日本の第1号(2号3号はIBMとかテンアントニー)取得。日経system大賞の1回目と3回目。マルチメディア表彰など、対外的な評価から、内部評価の向上を戦略とした。新規事業担当でゲーム開発。ソウル大学出身者のベンチャー企業とマンションのインターネットインフラ機器の合弁会社、機器開発販売……。失敗、反省。

 

この経験からOS、言語やフレームワークを知らないからといって、設計できないことはない事を知っている。問題はどこまで業務自動化や操作性など利用者リテラシーを設計できるかだ。また、社内業務とて同じ。あくまで、付加価値、数理モデルの設定で「あれを買ったヒトはこれを買うなど(アソシエーション分析)」業務課題を打破してほしい(笑)。

 

良いシステムの定義は「役に立つシステム」、「仕組のモデル化のあるシステム」ということだ。コンピュータの得意技は誰が使ってもキレイとか、大量の中から選択するとか、計算が速いとか、そういう時代からクリエイティブな時代に入った。建物の自動設計もそろそろ次の段階にもっていきたい。

LINEで送る
Pocket

フェルミ推定

LINEで送る
Pocket

寒い朝ですね。大昔設計した電力供給システムでケーブルの凍結による電源供給ルートのチェンジとか、

そのようなインフラシステムの設計を思い出しました。

今朝、どれだけの電車が遅延しているのだろう、これをすぐに答えるロジックなど、寝ぼけながら考えていました(笑)。

とのことで、推定のこと

「フェルミ推定」は日常の考えを進めるのに大変役立つ計算テクニックだ。

しかも、面白い。

 

【大雑把に正しい】、このことが重要な局面は多い。

同じく、アプローチの仕方の個別性にその人なりが出てくるから楽しい。

 

入社試験で

◇エジプトのピラミッドの重さは?

こう質問されたらどうしますか?

で、~この答を出すのが簡単になるわけだ。

 

私が最初にフェルミ的なアプローチの重要性に気が付いたのは、上場企業の役員会での質問攻めからだ。訳分からない質問を的確に答えるためには、基本的な数字を全ておさえたうえで、瞬時に加減乗除するスキルを身に着ける必要があった。コンピュータも風邪を引くのか? (ウィルスにかかった)、この質問は論外だったが(笑)

 

業界の数字:日本におけるハウスメーカーの着工棟数、在来工法とのシェア違い。棟数推移、地域別作業単価、家を建てるヒトの年代、などの基盤となる数値だ。

それから会社固有の数値:社員数、展示場の数、情報処理を対象とするアイテムの数、1棟あたりの平均部品数、情報処理社員の平均時間単価……などなど。

これらが基礎情報として分かると、あとは問題へのアプローチ方法だ。

 

◇「1棟あたりの情報処理時間とコストはどうなっているのか?」

◇「なぜ、そうなのか?」

◇「他社はどうなっている?」

……

経営者の疑問は延々と続く……。

 

そこで、信頼を勝ち取るには「フェルミ推定」の出番だ。

ぴったり一致する必要などない、①大雑把に正しい、それと②アプローチに説得力がある、この2点が大切。

 

日本の住宅着工件数が年間100万件あったとする、そのうちの30%が持ち家(注文住宅)だとして、在来工法に比してハウスメーカーのシェアが20%。そのうちの10%がA社のシェア。

A社の平均工期が6か月だとして、全体の現場の工程が部品供給の問題で各7日遅れたら損失はいくらか?

現場の平均作業時間単価は時給4000円。

次に対策案として、現在の現場の数と見える化のコストは?

これを瞬時に計算して会話をする、このスキルがないと事業部長はやっていけない、やってはいけないかなぁ~。

 

 

フェルミの問題は一見厄介なのが多い。

エッ、そんなのどうして分かるの? 的なものが~

 

◇この1冊のなかにある単語の数は?

◇高校生が3年間で消費するシャーペンの芯の本数は?

◇現在飛んでいる飛行機の数は?

……

こうした問題をこたえる醍醐味は役員会での質問攻めから生まれた(個人史)(^_-)-☆

 

最初は、資料が億単位で見慣れない数字だったから、ゼロの数を数えている余裕がない。

で、1万*1万で億との発想になり、1000人の社員に10万円の決算賞与を出す場合の総額費用は? こういう簡単な問題から始まった。桁をずらして、1億と即座に出る。

続いて、その時の税金の減額と効果は?

( ^ω^)・・・

徐々に難解な問題も解けるようになるのが、フェルミの素晴らしいところだ。

◇新商品で屋根パネルが1000枚増えると情報処理コストがいくらかかるか?

 

「世界の猫は何匹?」

ロブ・イースタウェイ

この本を読みながら、思ったことでした~

LINEで送る
Pocket

デザインとシステム

LINEで送る
Pocket

■美のシステム化

 

建築(住宅)デザインにおいて、「美」はシステム化できる。

“美しい”を定義して、システムで評価し、美しいデザインを提案する。

 

いかにも人間特有の所作に思えるが、「美」の標準的な要素のロジック化は可能だ。

もっと言うと、デザイナー〇〇、△△のフィルタといった特徴もセットできる。

 

私自身、マルチメディア系の研究会以外に複数の研究会に所属していた。その中に、1/fのゆらぎをもとにした「感性工学研究会」がある。この研究会では脳波とデザイン(美)を研究した。瞑想などで使う音や環境映像もそうだが、一般の風景写真やネクタイ柄など、デザインを周波数として、そのゆらぎから、デザイン性、心地よさ、快適性を評価した。

 

それから、「形の文化会」。こちらは文字通り文様や街角に溢れるデザイン(シグナル)をウォッチして、観察を楽しんだ。イタリアのアチコチでドアノッカーを撮りまくったのは、この研究会員時代の名残だ。ちなみにノッカー素材としては真鍮が多い事、ドアのノック回数は国際標準があって4回ということも学んだ(笑:余談)。

住宅外観のデザインの良し悪しをシステムで評価するパラメタは、シンメトリック性、視線の長さや動き、相似性、黄金分割、水平ライン、垂直ライン、三次元空間を広く見せるテクニックなどがある。これらを的確に盛り込んだ知的CADが登場しなくてはならない。もうその時期だ。建具の自動配置で満足せずに、敷地のワンクリック入力、まとめたコストダウンの仕上表の松竹梅など、使えそうな数理モデルも数多くある。私の若いころはアフィン変換のような特徴抽出処理やアトラクタの形による特質などを秩序として、アプローチしていた。

 

色も同様に美しい組み合わせがある。色彩工学、自然言語との関係性など、こちらも研究が深まっている。形、色とヒトの五感において、眼から入る視覚情報が脳に与える影響の割合が大きいことは承知の事実である。

 

デザイン(ライン、面、形、色、組み合わせ)もそうだが、住宅の間取や設計の自動化を深く考える仕事をしていると、一つひとつの人間の営みが美とつながっていることが良く分かってくる。

 

 

美しく歳を重ねる。

美しく生きる。

美しいデザインが分かる。

美しい言葉づかい。

美しい振る舞い。

 

美しい……。素敵に……。

 

私にとって、月々の決算書も【美しさ】を追求するテーマの一つである。

負債の中にも美がある(笑)、こう言いたい。

LINEで送る
Pocket

プロの仕事

LINEで送る
Pocket

たまには真面目な話。

 

長い事、【IT】と【住宅】・【建設】を生業としていると、時間とともに、自ずとプロ化する。

 

勿論、なんでもシステムが解決すると思うと間違う。業務や運用ルールが不整備なケースが多々ある。ここをきちんと説明して提案できることが重要。建物の設計は、デザインは誰(建築家や設計事務所)と決まっているが、システムにはない。企業単位だ。これが問題。プロ化を阻害している。

 

このシステムデザインは誰。バイネームにすべきである。

 

これがないがために、付加価値が低くなっている、工数(費用)は【人月単価*期間】という、能力と比例しない費用が登場してしまう。労働型なので、早くて良いものを作ると儲からないのだ(契約種別は未考慮)。このことも手伝って、無責任な部分が存在してしまう。

 

実際、住宅や建設の自動設計を長く手掛けていると、ヒトとシステムの関係で気が付くことがいくつもある。お互いの良いところの発見とあるべき処理の姿と言い換えてもいいだろう。それは世の中の原理にも似ている。性質の異なる素材をつなぐ方法とか、くっ付けてもヒビ割れしないとか、そういうようなものだ。なるべくプリミティブな上流で加工して成立できるプロトコルをつくる。これが肝心。データをいじると目的から外れ意味を失うことがある。そうなると泥沼。複雑よりシンプル、ここが大切。

 

さて、建設のこと。

敷地を読んで、即座にイメージが湧くのが人間の良いところだ。法規の詳細は横に置いて、頭のなかで複数のイメージが出来上がる。同じ用途地域なら近隣の建物をみると建物の制限が理解できるし、周辺環境や予算などを読んで日当たりや防火などのイメージも湧く。柔らかいゾーニング部分だ。

 

ゾーニングのような、このボワーッとした部分、実際、このようなことが、システムは苦手。真面目過ぎるのだ、ボワーッとできない。直ぐに白黒をつけたがり、断片化したがる、システムの悪いところだ。自動設計でも方位や道路付、斜線や面積などの法規、近隣との関係、施主の要件、予算と考えて、サッと配置案を出すヒト。システムは手順を示さないと動いてくれない。

 

加えて、システムは工程や業務間の双方向行き来が苦手

意匠、構造、設備、施工、積算、外構などの要素があって、ちょっと、予算を減らしたいとかクライアントが言っても、システムはどこを直せばいいのか、最適解を外部の決め事で定義しないと動いてくれない。エレベータをもう一基ふやすとか、口で言うのは簡単だか、最適な処理は当初から予定していないとできないのだ。

行き来、この部分でもう少し書くと、データ構造が解決の術となり得るのだが、残念ながら、現在は上手なデータ設計が乏しい時代だ。メモリが高かった時代の方が上手だったように思える。効率を考えなくともフンダンに使える時代のデメリットだ。もちろん、オブジェクト型で一元管理が容易な技術進展のデータ構造もある。メタ化や仮想化も進展した。だが、オールドスタイルが大半なことを考えると、苦言を呈したい。

 

このデザインで、構造的に正しく、法律的に問題なく、予算スケジュールを遵守して建設する。

 

言葉で言うのは簡単だが、これをシステムで最適に処理するのは難しい。このルール化出来ないところに、AIテクノロジーなどの実績データを積み重ねて解を導くフィードバック系(数理モデル)が意味をもつ。

 

「ボワーッ」とした部分と「行き来」、これを上手に提案(設計)するのがITと業務に精通しているわが社のミッション(プロの技)、そう考えている。

LINEで送る
Pocket