情報システム開発の世界では、情報システムの開発を請け負う企業をSI(とかSIer)と言い、それを使う企業をユーザー企業と言います。
通常、両者は協力してシステムの構築に当たるのですが、お互いの領域の線引きをどこにするかというのが非常に難しかったりします。

ユーザーはITプロフェッショナルであるべきか
ユーザー企業ができる限り，自分で取り組むことである。情報システム開発を例にとれば，要件定義，設計，プログラム開発，テスト，機種選定，システム環境の整備，データ移行，システム運用・保守，利用者教育まで，すべて自分で責任を持って実施する。ビジネスに合致した情報システムを開発し，動かしていくには，自分でやるのが一番早く，柔軟な対応が可能で，しかも安上がりなはずだ。

すべてユーザー企業側がやったほうが望ましいという意見もある一方で、ITの部分はすべてSIerが責任を負うべきとの意見もあります。

経営者がITを理解できない本当の理由
我々ユーザー企業は、ビジネスにおけるIT投資の費用対効果を考え、どんなビジネスをして、ITをどう使ったらいいかを考え抜く。できあがったシステムを使いこなしてビジネスを遂行し、所定の効果を出すところに力を注ぐ。
　一方、ITや情報システムの開発については、ITベンダーに責任をもって担当していただく。

結局のところ、企業が行うビジネスと情報システム(IT)がどの程度密接なのかで決まってきます。
すべての経営行為はシステム開発そのものだという意見さえもあります。

「IT投資」という考え方そのものが間違っている
ソフトウェアシステムの開発とは、経営行為そのものそのものであり、逆に言えば、江戸時代どころか、ローマの時代から、経営行為とは、ソフトウェアシステムの開発以外のなにものでもありませんでした。
どのようなソフトウェア機能なら、システム的ボトルネックが生じずに、かつ、ソフトウェアシステムの保守性が悪くならずに開発可能かどうかの検討がつかない経営者では、ろくな事業企画ができるわけがないのです。
なぜなら、それは、自社の経営行為そのものであり、それを外注にやってもらうのは、経営行為そのものを外注にやってもらうというような、意味不明の行為だからです。

上の記事の通り、自社のビジネスとITが密接な企業ほど、社内の人員でシステムを構築すべきです。
いわゆるIT企業はたいていそうしていると思います。はてなやライブドアなどは、ほとんどのシステムを社内で構築しているようですし、Googleにいたっては、ハードの設計まで自前でやっていると言われています。
それでは、SIerはどうすれば良いのか？その答えが、アジャイル開発だったりするのかと思っています。

アジャイルアライアンス
要件の変更は例え開発の後期であっても受け入れます。
アジャイル･プロセスは変化を味方につけることによって
お客様の競争力を引き上げます。
ビジネスをする人と開発者はプロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
ですから彼らが必要とする環境と支援を与え
仕事が無事終わるまで彼らを信頼してください。

この問題はSIerが受け取る報酬も関係してきます。
単に技術者の頭数が欲しいだけならば人月見積もりでもいいのでしょうが、
ビジネス自体を一緒に作ろうとしているパートナーに対して、
人月見積もりしてたら駄目でしょう。

人月見積もりでは生産性は上がらない、IPAが警告
「ソフトウェアのアウトプットを計るのは難しく、現状多いのはコスト積み上げ型の何人日という形での見積もり。ソフトウェア工学は進歩しているが、生産性を上げても金額が低くなってしまう。このジレンマが生産性の上がらない要因。それがまさしく浮き彫りになった調査」

よいSEにはよい報酬を，
“人月いくら”はもうやめよう
システムの価格を“原価”によって決めるのではなく，そのシステムがユーザーにもたらす“価値”によって決めよう，という機運が高まってきたことだ。

オークニーさんが出しているオープンソースのルーティングエンジンPostLBSを、Windows環境で構築してみました。
WindowsXPのSP2で試してみたところ、サンプルアプリを動かすところまでは上手くいきました。
以下はそのときのメモです。

PostLBSのセットアップ

まずはPostGISが動く環境を作ります。
PostgreSQL 8.1.4で動作確認しました。(8.1.5では上手くいきませんでした)
PostGISはインストールオプションに付属のものでOKでした。
PostLBSのダウンロードページから、pgRouting(Windows binary)をダウンロードし、中身をPostgreSQLのインストール先フォルダへコピーします。
routingを使用するDBへ対して以下のSQLを実行します。

share\contrib\routing.sql
share\contrib\routing_postgis.sql

pgAdminⅢから実行すると上手くいくのですが、psqlで実行するとエラーになりました。
「\’を使わずに、”を使え」と言ってきたので、置換してから実行する上手くいきました。
これで、pgRoutingの各ファンクションが使えるようになります。

サンプルアプリを入れる

MS4Wをセットアップします。
バージョンは2.2.1で試しました。
「pgRouting Sample Application」をダウンロードして、MS4Wのappsフォルダへコピーします。
「httpd.d」フォルダへApacheの定義ファイルを追加して、routingjアプリケーションを使えるようにします。
「routing」というDBを作り、pgRoutingを使えるようにします。

createdb -U postgres routing
psql -U postgres -d routing -f “C:\Program Files\PostgreSQL\8.1\share\contrib\routing.sql”
psql -U postgres -d routing -f “C:\Program Files\PostgreSQL\8.1\share\contrib\routing_postgis.sql”

「data\kanagawa.shp」をroutingデータベースへインポートします。
インデックスも作っておくと処理速度が速くなります。

shp2pgsql -D -c kanagawa.shp kanagawa > kanagawa.sql
psql -U postgres -f kanagawa.sql routing
psql -U postgres -d routing -c “create index k1 on kanagawa using gist (the_geom GIST_GEOMETRY_OPS);”
psql -U postgres -d routing -c “create index k2 on kanagawa( source );”
psql -U postgres -d routing -c “create index k3 on kanagawa( target );”
psql -U postgres -d routing -c “vacuum full;”

サンプルファイルはLinux用？なので、以下の修正を行います。
phtmlsフォルダ内の各「.phtml」ファイルの中身を以下のように修正します。
「php_mapscript.so」→「php_mapscript_4.10.0.dll」
「maps/routing.map」ファイル内の、
「IMAGEPATH」定義をフルパスに代える。
各「LAYER」の「CONNECTION」へPostgreSQLへ接続するための情報を設定する
これで、とりあえずは上手く動作しました。

–Sandy the best Flash 3D API
Flashには画像の変形処理を行うためのライブラリが用意されていますが、3×2のマトリックスにしか対応していないため、3次元のテクスチャ処理はとても大変な作業となります。
Sandyは、そういった3次元のレンダリング処理をラッピングしてくれるAPIです。JAVA3Dに基づいて設計されています。
ドキュメントもしっかりしています。
画像処理については、PixLibという外部ライブラリを参照しているようです。
上記以外にも、こちらのサイトにはたくさんのFlashプロジェクトが公開されています。
最近、Ajaxのサイトに紛れて、Ｆｌａｓｈを使ったＲＩＡがかなり伸びてきているように思います。
リクルートがリリースしたスゴイ地図やMash up Awardでフロムエー特別賞を受賞したFind Funなどの(うねうねな)インタフェースは、Ａｊａｘで簡単に真似出来るものではないでしょう。(がんばればできるかも？）
Googleのサービスも密かに？Flashで作られたものがいくつか紛れています。
Sandyのデモの中にこんなアプリがあるのですが、GoogleEarthのFlashバージョンも夢ではないかもしれません。