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

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

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

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