まとめておきたいこと。
マクロな観点で見ると、今後ソフトウェア構築の専門分化はどんどんすすんでいくはず。つい最近までは、ソフトウェア構築の分野は医療や建築に比べて専門分化が遅れていて、追いつくまでには100年単位の時間がかかると言われていた。だけど、予想よりはずっと早い。おそらく10年単位…早ければ数年ではっきりと見て取れるような変化がある気がする。
てなわけで、まずは設計者なのか実装者なのかプロジェクト管理者なのかよくわからない自分の立ち位置と、将来目指す方向、そこへ至るためのロードマップを考えておく必要がある。
これらを考える際に参考にしたいのが、プロジェクト内でのロールの割り当て方とそれぞれのロールがチーム内でどのように動いていくかのメカニズムの整理。色んなパターンがあると思うけどね。
おまけに、一番立ち位置が近い（ほんとかよ）「アーキテクト」が持っておくべき知識は整理しておく。こんなところだろうか。
あぁ、そうだ。そもそも自分が所属している業界が今どうなっていて、これからどうなるのか。これも…重要だ。というより、これが一番重要なのかもしれない。ネタを集めつつ、ぼちぼち考えていこう。
- アーキテクチャパターン一揃え
- チーム分割/ロール割り当ての再整理。チーム運営のメカニズム。
- 受託開発ビジネスの今後
ハウルの動く城
昨日、新宿文化シネマに「ハウルの動く城」を見に行ってきた。千と千尋〜よりはおもしろかったけど、設定の叩きがアマいところが目立ったのは少し残念。きいちご賞で言われてたような声優の未熟さって点ではあまり気にならなかった。老婆になったソフィの老化具合が、ソフィの心情や状況で若くなったり年老いたりしているのは表現としてとてもおもしろかった。
入場待ちで並んでいる時、後ろに並んでた男の人が「ソフトウェア企業の競争戦略」を読んでいるのを見て軽く苦笑してしまった…自分もよくやるんだけど、人がやってるのを見るとなんとも言えない気分になるもんだ。実際、中小企業診断士の概要説明本持ち込んでて、映画館に置き忘れてきてしまった。残念。
業務システムのための上流工程入門―要件定義から分析・設計まで
BPMは、具体的にどんな業務に適用できるのか？
http://www.atmarkit.co.jp/fbiz/cinvest/serial/bpm/04/01.html
BPMを適用するにあたっては社内業務の可視化（特に、誰が何をする権限を持っているのかが明確になっていること）が不可欠だろうが、実際にこのレベルで業務の可視化がなされているケースはとても少ないと感じる。ある程度は決められているが、各個人の役割と責任範囲が明確でなく、どの部分が代替可能なのかが明確に切り分けられない。
これはBPMに限った問題じゃなくシステム開発全般に関連する問題で、これが業務のリストラクチャリングを困難にしている。昔から言われていることだけど。
これは、企業文化を通り越して国の文化とも言うべきものに影響されている気がする。
RFID時代のDB
http://www.atmarkit.co.jp/fdb/single/01_rfid_database/rfid_database01.html
Object StoreがAmazonに採用されたと宣伝しても、こんなハイエンドに特化した実績では採用する企業も少ないだろうと思っていました。Amazonほどのトランザクションをさばかなければいけないシステムというのは世界中にそうはないでしょうから。いや、あるのかもしれませんが、少なくとも自分が関わることは滅多になさそう…と思っていたんですが、上記の記事を読んでにわかに身近に感じられはじめました。RFID絡みの物流システムだと既存のRDMSの使い方では破綻するかもしれない（本当かどうかはまだわかりませんが）。そういう場合の解決策の一つとして、Object Storeのようなやり方が既に実績をあげている（とみなしてよい）というのは結構デカい。
…とはいえ、最後のDB技術者にせまられる変更というのはいまいちピンとこない。入力クエリではなくイベントになるといってるけど、DB技術者側からすれば、フィルタされたイベントはクエリの形でとんでくることになるだろうし、DBレベルではあまりかわらないのでは？そもそもAmazonではバックエンドのDBは変更していないみたいだし。
日本人ITエンジニア
http://jibun.atmarkit.co.jp/ljibun01/rensai/noeinjp08/noeinjp01.html
うーむ…耳が痛い。自立心は確かに少ないかもしれない。さらに、技術オタク化しやすいというのもその通りかもしれない。わかりやすいし裏切らないから楽なんですよね。
いい加減、ビジネスに寄っていかないといけないな…。
