シン・ゴジラを見てきた

 昨日、シン・ゴジラを見てきました。映画館でゴジラを見るのは小学生の時以来なので約30年ぶりの事です。
 その時とシン・ゴジラの共通点が、初代ゴジラをモチーフにその時代に合わせて作られているという事なんですが、小学生当時の記憶はゴジラの悪役ヅラとか、でかいフナムシとか、スーパーXとかぐらいなんです。。でも、映画としてのクオリティはともかく、映像としては白黒の初代から見れば断然進歩していました。小学生の時に白黒のゴジラを見ても正直何がよいのかよくわからなかったのです。
 シン・ゴジラを見て感じるのは、映像だけでなく全てが進歩しているという事です。今という時代に与えられたリソースを最大限に駆使した結果、シン・ゴジラがこうなったというのが感じられます。
 筆者は基本的に、現在というものは過去からの進歩の上に成り立っていると考えるクチなので、シン・ゴジラは昔のゴジラより確実に進歩していると思いますが、それは過去を否定する事では無く、過去の延長線上にある現在が進歩しているんだから、結果的に過去は肯定すべきものになるのです。
 映画のようなコンテンツの一方で、例えば音楽や絵画といったものは別のベクトルなんだと思います。その違いは早い話、多数の人が関わった仕事かごく少数の仕事か、技術要素が強いかどうかなのかと。今の時代、技術要素といえば殆どがコンピューターと切り離せないものになってます。なので、筆者の偏った考え方は仕事柄かも?
 圧倒的な破壊シーンだけでなく印象に残ったのが、最後の「日本はスクラップ・アンド・ビルドでやってきたんだ」的な言葉でした。
 映画には元気をもらいましたが、アクアラインを通るたびに崩落シーンを思い出してしまいそうです。。

SSL証明書を入れてみた

 SSL証明書が欲しくなったので、出来るだけ安くという事で下記にしてみました。なお、サーバは別の所にあります。
http://www.sslbox.jp/
 サポートページにあるとおりに秘密鍵を作成し、格安証明書3年で税込み2,559円のCoreSSLを管理画面より申込&決済&証明書申請。数分で証明書をゲット出来ました。
 ゲットした証明書はこれまたサポートページを見ながらサーバに配置&ssl.confをセッティングし、リスタート。
 で、稼働確認も済んだとして、サーバ設定をもとに戻したら、見つかりません状態に。。
 何で??と思ったらiptablesで弾かれていました。。
iptablesのコンフィグファイルに下記を追加し、リスタートで作業終了!
-A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

Windows2012ServerR2評価版を入れてみたが、、

 先日、とあるシステムの導入に向けてのトライアル環境を作る手伝いをしていたのですが、OSがWindows指定なので評価版のWindowsServer2012R2をインストールしました。
 OSのインストール自体は簡単なのですがインストールの数日後見てみると勝手に電源が落ちていて、誰かに落とされたかな?とあまり気にしていなかったのですが、とあるシステムの導入作業時に勝手にシャットダウンし始めて困った事に。180日間使用できると書いてあったはずなんですが。。
 で、インストール時を思い出してみるとサーバ日付がだいぶ古くなっていたのを直していたので、それで180日間が終わってしまったような状態になっていた模様。。さらに調べてみると期限切れ後も延長できると下記を発見。

https://msdn.microsoft.com/ja-jp/library/dn303418(v=ws.11).aspx

これで暫くは持ちますが、こんな落とし穴があるのでインストール前にちゃんと時間合わせしとくべきでした。
他にもネットワークのセキュリティ設定あたりも結構引っかかったので、ちゃんと調べてから作業をしないといけませんね。

ロダンは地獄の門を作ったけど彫ってなかった

 先週末、嫁さんに誘われて静岡へ美術館巡りに行ってきました。静岡県立美術館と静岡市立美術館でどちらも初です。
 静岡県立美術館の方は、残念ながら今話題の若冲さんの有名な絵が前週で終わってましたが、ロダン館は結構凄かったです。考える人、地獄の門といった有名な彫刻が勢ぞろい状態です。静岡になんでこれだけのものが揃ってるんだろう?筆者は全然美術に詳しくないので後で知った事なんですが、これらの彫刻は一つだけでなく複数存在しているようです。なぜかというと、ブロンズ像は型を取って銅を流し込んで作るものなので、同じ型から作ったものは全てオリジナルという扱いになっているようなのです。静岡県立美術館だけでも考える人は地獄の門についているのを合わせて大・中・小と3体ありました。
 で、地獄の門の方ですが、こちらは世界に7つあって、日本には上野の国立西洋美術館とここ静岡県立美術館の2か所あるようですが、この地獄の門は、全てロダンの死後に作成されたものであり、しかも静岡にあるのは結構最近作成されたものとの事。これをロダンが作ったものと言えるのでしょうか?
 どうやら元々ロダンは自分で彫刻を彫っている訳では無く、粘土で原型を作った後にその型を取って石膏の原型を作って確認した後は、その型から鋳造してもらう工房にブロンズ像の制作を依頼するという形だったようなのです。静岡にあるのはその原型を使っているので本物という事になってます。
 そこで思い出したのですが、筆者が社内SEに転職して最初の仕事、利用部門内に設けられたシステム開発室という部署と兼務になりシステム構築プロジェクトの担当をしていた時の事です。半年近くを要件定義作業で費やし、その後は複数のベンダーに開発を依頼しつつ、同時にその繋ぎの一部を自らプログラミングしていたのですが、その室長が言っていた「俺たちが作ってる」という言葉に当初違和感を覚えてました。いや、作っているのはベンダーさんや自分も含めた開発者じゃないかと。
 でも、しばらくしてその考えは間違いである事に気が付きました。何を作るべきかを決めた人は確かに作った人と言っていい、最重要人物です。大阪城を作ったのは秀吉で、Windowsを作ったのはビル・ゲイツ、iPhoneを作ったのはスティーブ・ジョブスなんです。でも、それを作るにあたってたくさんの人が携わった事は事実であり、それを忘れてはいけませんね。
 県立美術館の方はルーシー・リー展を見てきました。そちらで思ったのは、美術品と工業製品の境目はどこにあるんだろうという点なんですが、美術品とされるものは芸術家という個人名義のものしか美術品とされないような気がします。著名な漫画家には大勢のアシスタントがいるけど基本的に漫画家名義の作品なので美術品と同じように感じられますが、一方で文学とか音楽とかはゴーストライター的な存在が判明すれば即叩かれてますよね。某ゴーストライター騒ぎがあったクラシック音楽を騒ぎになる前に生で聴いた事がありますが、それは感動したものです。あれだけメディアに叩かれては、その後あの音楽を聴いた人はどう感じているのでしょう?製品の場合は、強いリーダーシップが見えない企業が作った製品は、どんなに素晴らしいモノであっても、個人的な誰かの強い思いとかが見えないと、いいモノ以上には成らないように思います。とは言え、ソフトウエアは美術品には成りえませんね。例えば、iPhoneを美術館が展示したとしてもハードの方がメインにしかならず、ソフトの部分を一般的な人々に説明する事は不可能としか思えません。

作らないで済むなら作らない方がいい

 社内ネットワーク内で使う研修用の動画サイト作れないかな?と相談されたので、最初は作る前提でいろいろ調べていました。
 Javascript系のvideo.jsやMediaElement.jsとかで単純に動画を表示する所まではやってみましたが、動画のアップロードやメディア管理、認証等まで考えると結構な時間が掛かかりそうだと実感。。
 で、結局の所、WordPressを立ち上げてプラグインを入れる方がよいと伝えました。
 下手に作ると使う側にもこちらにもコストが掛かるし、使う側も何か問題があったら何も出来ずに問い合わせしてくるしかありません。WordPressなら情報量が豊富なので使う側も多少の勉強が必要とはいえググれば大抵の対処が可能だし、WordPressを理解していく過程で、別要件もこれで実現できそうだというのも結構ありそうです。
 作らなくて済むなら作らない方がいいというケースは、オープンソースのライブラリとかを使用するのも同じです。しかし、その見極めが結構難しくて、「定番」みたいなものなら別ですが、情報量が少ないものは使うと決めるまでに調べたり試してみたりの時間が掛かってしまうものです。

データの意味

 先日、セミナーにちょっと行ってきました。
アプリケーションセキュリティに関するセミナーでしたが、印象に残ったのが、扱うデータの意味を理解して対策を立てるのは、どんなセキュリティ対策のツールを使っても扱うのが相当困難だという点でした。
 企業内で扱うデータの意味を知っているのは、基本的に企業内SEもしくはその位置付けにある人達です。何を知っているかと言えば、具体的にはテーブルとカラム、データ項目、インターフェース設計なんだと思います。前職で一時的にホストを担当した時は、VSAMのレコードレイアウト図として紙でしか資料が残っていなかったので、エクセルのテーブル設計書に落として、把握している範囲で項目の備考欄を埋めていきました。
 備考欄に殆ど何も書かれていないテーブル設計書をたまに見かけますが、項目の備考欄こそデータの意味を記載する箇所ではないかと思います。項目名だけでデータの意味を想定するのは間違いが生まれる元ですので、どういう意味の項目であるか、どういう値が入りえるのか、他とどういう関係を持っているか、出来る限り備考欄を埋める事が、データ設計をする人としてのそのデータを扱う他者への優しさではないでしょうかね?

兵馬俑は事実を可視化したもの

 先日、上野の国立博物館に「始皇帝と大兵馬俑」を見に行きました。混んでる事を見込んで平日水曜日に行きましたが、平日でも結構混んでます。こういうのはじっくり見たいので、混んでると途端に気持ちがダウンしちゃうんですよね。。でも、展示の最後に職業柄考えさせられる一文、「永遠に皇帝であらんが為の事実を可視化する為に兵馬俑を作った」というニュアンスの事が書かれていたのに注視しました。
 システムに携わる人として可視化という言葉には、反応せざるを得ません。システムは画面以外目で見えないものなので、ドキュメントを書く事で可視化しますが、始皇帝は膨大なリソースを費やし、数千、万?のリアルな陶器を作る事で可視化したという事です。
 数年前に携わった、とある企業の基幹システムリプレイス要件定義フェーズで、一番受けが良かったと感じているのが、既存システム構成を可視化した「絵」です。中規模以上の企業ですと、複数のシステムが連携しながらその企業のビジネスの根底を担っていることが多いかと思います。でも、業務ユーザーの方々は自分の社内システムがどう構成されているかをそれほど把握していません。システム部門の方々は、どちらかというとインフラよりの観点が強いです。要件を聞き出す為に今の形が可視化された物が欲しいと思いましたが、既存資料に該当するものが無かったので、下記に気を付けて全体俯瞰図的な絵を書いてみました。
 1.1枚に収める(A4サイズにすべてを収めないとヒアリング時にすぐ見れない)
 2.サーバマシン等のインフラ単位ではなく、ユーザーが日常業務で言っているシステム名を1つの単位とする(利用部門等の境界が解る)
 3.1つのシステムが大きい場合はその中に分離できそうなものをサブシステムとして枠を引く(作業分担すべき境界が解る)
 4.重要データはどこにあるのか解るように入れておく(データ移行元とすべき場所が解る)
 5.システム間、外部、利用者との繋がりを矢印の線でつなぐ(in outが解る)
 6.完成を待たずに常に打ち合わせ時に持っていて見てもらい足りない所や間違いを指摘してもらう
こんな感じでした。
fukan

 その後、空いていた常設展示を見に行き、誰もが知ってる国宝になってる日本の埴輪を見ましたが、明らかにクオリティ的には兵馬俑の方が高いです。しかも、兵馬俑は埴輪に対し700年くらい古いものです。でも、緊張感に満ちた表情が殆どの兵馬俑よりも埴輪は「いい味」出してるなあという感じがします。これってただの自国びいきなんでしょうか?それとも強大な権力者から言われて作ったものよりも、自発的に作られたもの(真意は知りませんが)の方が共感を得やすいという事を表しているのでしょうか?

データ設計は誰でも出来るけど

先日、「Web Performer」というWebアプリ自動作成ツールを見る機会がありました。ま、AccessのWeb版といった感じです。こういう自動作成ツールは大抵、プログラムを書かずにアプリケーションが作れるというものですが、当然データ設計(ここではツールへの入力作業ですけど)をしなければ何も作れません。
 で、データ設計って誰でも出来るのかなという事を考えたのですが、基本的にそのシステムが対象とするドメインに関するナレッジが無いと設計出来ないので、どんなにスーパーなエンジニアでも、まったく知識が無いドメインを対象とするシステムを作る為のデータ設計は出来ません。作る前に業務分析とか要件定義のフェーズを設けて、それらの知識をエンジニアが得た上で設計し始めるといった手順になります。ま、そのフェーズにどのくらい時間をかける必要があるのかはまちまちですけど。。
 となるとデータ設計は確かにエンジニアがしなくてもいい範囲かも知れません。日ごろ使っているエクセルシートや紙の伝票などから大抵のデータ項目は決まってしまいますし。エンジニアがするのはそれを設計書という形に落とすだけです。
 でも、それらデータをつなぎ合わせるという感覚が一般の人ではちょっと難しいのかもしれません。データ設計をデータベース設計と言えるものにするには、最低限、データをテーブルとし複数のテーブルを定義して、それらの繋がりも明確にする必要があります。複数のデータを繋ぐにはエクセルの単一シートや紙には含まれていない可能性のある外部キー項目が必要になってきます。こうなると多少なりともRDBに関する理解が必要です。RDBなら大抵同じかも知れませんが、使用するデータベースミドルウェアの種類によっても、設計は違って当たり前です。物理設計となると完全にミドルの世界です。
 上記のような自動作成ツールを使う上では物理設計は殆ど不要みたいです。でも、データベース設計ができないとツールを使っても単一データ用の一覧・更新画面以上のものは出来上らないので、最低限RDBに関する理解は必要ですね。

e-Taxを使って感じたこと

源泉徴収手続きの期限が迫ってきたので、e-Taxでやってみました。と、言っても仕事のタイミング的に昨年中は特に払うものは無いのですが、無いなら無いとしての手続きをしなくてはなりません。。
 ルート証明書をインストールし、Webから開始届出の手続きをすると、利用者識別番号が表示されるので、その番号でログインして利用者情報の登録をしたら、各種申告の入力をするだけです。筆者の場合は、特例の申請をしているので、「給与所得・退職所得等の所得税徴収高計算書(納期特例分)」で入力して終わりです。
 ちょっと違和感を覚えたのが、開始届出を画面から入力している時点で殆どの利用者の属性情報を入力しているはずなのに、またログイン後に利用者情報を入力しなければならないという事。2重入力しなければならない理由は何なのか、職業上いろいろ想像してしまいます。ま、殆どの場合システム構成とかデータ設計上の問題でそうなっているだけだと思いますが。。
 他にも、拡張子がdoだからStrutsを使っているっぽいとか、Javaアプレットを使う必要性ってホントにあるの?ブラウザはともかく、端末環境に依存することはやっちゃダメだよね、とか、画面デザインの野暮ったい感じは開発ベンダーに丸投げしたのでは?とか、画面上の文言表記だけでなくユーザー目線で設計された感じが全くしない、とか、既存の用紙や手続フローを置き換える以外のシステム化コンセプトを少しも考えなかったんだろうな、とか、そもそも肥大化・複雑化しすぎたスキームの再設計や膨大な種類の取扱用紙の再整理をせずに表面だけシステム化したところで解りやすくなることはない、など、いろいろ示唆に富んだシステムですね。
 イータ君ってイタキャラって事かな?

フランク・ゲーリー展を見て感じたこと

 以前から、建築業界とシステム業界というのは共通点が結構あるな~と考えていました。作る対象物は違えど設計、構築といった仕事の進め方もそうだし、大手ベンダー=ゼネコン、多重請負とかの業界構造もです。で、今ミッドタウンの21-21DESIGNSIGHTでやっているフランク・ゲーリー展に行ってみようと思った訳です。
 正直、その斬新なデザインは賛否両論あるかと思いますが、筆者が驚いたのは、昔は模型を作っては壊してを繰り返して設計していたのが、今ではデザインコンセプトを模型で確認した後はコンピューターで3Dモデリングし、決められた予算範囲内でデザインを妥協することなく最適な資材構成となるようシミュレーションを繰り返して決定しているという事です。それにより、建築資材の数や搬入時期までを決める事で施工時のコストまでも最適化し、複数の施工業者が見積もっても誤差は0.5%とか。スゲエ!と思ってしまいました。ようするに、それを実現できるソフトウェアを開発した人であるということなんです。建築業界はまったく解らないですが、こういうやり方は一般的なのでしょうかね?国立競技場とかこの人に任せればよかったのにと思いますけど。。
 で、建築とシステム開発の違いについて、フランク・ゲーリー展を見た後に筆者が感じた所ですが、建築では、住宅からビルやホールとか構築対象物の規模が解りやすいという事と、建築での施工業者なる位置付けの仕事がシステム開発に存在しているか?という事です。
 システムの規模って、誰が見ても大規模なものもあれば、それ程でもないものってかなりあるように思いますが、その規模の判断が人それぞれな気がします。大抵大手ベンダーに依頼すれば大規模と見なされていませんかね?クリティカルなシステムだって、例えば5種類のデータしか扱わないのであればそれは対した複雑さは無いはずなんです。また、扱うデータ量が膨大だとしても実装されたシステムを多数のサーバに配置するだけなので、インフラ含めアプリもちゃんと設計されていれば開発自体のコストは何も変わりません。
 あと、施工業者という点では、所謂上流下流といった分け方をしている場合、プログラマーは施工業者みたいなものだという考え方を持っている人もいると思いますが、それを当てはめた方がよいケースは極少数でしかないと筆者は考えます。どちらかというとプログラマーは施工業者というより建築資材供給者の位置づけに近いと思いますが、システムでは1つの設計=1つのプログラムみたいなものです。同じものを量産するという概念がありません。すごく似ている機能が多数存在する事もありますが、それを一つまたは最小限にできないなら設計に問題があるはず。であれば、何を作るべきかを把握しているであろう設計者自身がプログラムを書く方が品質が高く、また分業する事によるコミュニケーションコストも最小化できるはずです。
 システム開発に施工業者が存在していないと考えの元では、建築家フランク・ゲーリーにとってのデザイン活動範囲は、システム開発全ての活動範囲と一致しており、構築対象物は違えど、システム開発におけるプログラミングはデザインという活動範囲に含まれているという事になります。施工業者的であるのは多数のサーバで構成された場合におけるインフラ側の仕事だけではないでしょうか?
 筆者の立場では、今は一人か極少数で開発をしているので、これは注文住宅を自身で設計・施工している工務店の大工みたいなものですかね。こういう戸建レベルの規模の開発案件って結構存在しているはずなんですが、欲しているものの実際の規模と受注側が考えているその規模のズレを注文側が感じるとる事を出来るかという所になります。でも、大規模と言われた物を小規模であると主張するのは結構タイヘンなんですよね。発言に対し全てのリスクを引き受ける気合い!がなければ、なかなか言える事では無いかもしれません。別の方法として、一つのシステムを戸建てレベルの集合体と分割することも出来ますけど、構築後の保守フェーズまで考慮するとこちらもタイヘンかなあ。。