old-v2パイプ式ファイル(キングファイル)指向方式設計/破綻プロジェクト対応指向方式設計ユーティリティなどを設計・製造する場合に、そのユーティリティが利用するメタ情報についてもキングファイル指向という観点が必要な場合があります。適切に紙ファイリングにつなげていくのだ、という観点がどうしても必要なのです。ミドルウェアを作成する立場にあることが多いです。気にしているのですが、今日はっきりわかったことは開発するターゲットのミドルウェアは、利用する各種メタ情報について最終的にパイプ式ファイル(キングファイル)にファイリングされることを常に意識しなくては、全体的な生産性向上にはつながらない、ということです。現状のソフトウェア環境においては、パイプ式ファイル(キングファイル)への紙ファイリングには不適である場合が多いのです。(無料XMLツールなどが一般に普及したら状況は変わるのでしょうけれども)。印刷用ソフトウェアや閲覧用ソフトウェアが普及したファイル形式でメタ情報を格納しておかないと、パイプ式ファイル(キングファイル)へとつなげることが難しいのです。これは難しい命題ですね...。ここからいがぴょん刺激満載のツッコミを、どうもありがとうございます。tidusさんがExcelMessageResourceのファーストリリースを行われました。パイプ式ファイル指向にフォーカスしてカスタマイズしていく必要があるとという経験上の結論を持っています。じように、破綻プロジェクトへの対応を観点に入れた方式設計という観点も存在するかと思います。終末工程においてインパクトあふれる仕様変更が多く入る可能性のあるプロジェクトや、終末工程で大量の人員が短期で投入される可能性のあるプロジェクトにおいては、きわめて単純なクラス設計・構造によるフレームワークの設計・提供、そして開発標準が必要であるのではないかと考えます。終末工程で破綻している場合には、とにかく構造を簡単にしておいて、常識で対応できる仕組みにしておいて初期教育コストを極小化しておくのです。比較的誰にでも導出できそうな、そんな気持ちがしました。障害になることが多い...「破綻プロジェクト対応指向なにがし...」を書いていて、ようやく気がつきました。オブジェクト指向で実現されたプログラム構造がリカバリの障害になることが多いのです。(望んでやっているわけではありません...)。いくつかの破綻した現場に共通される経験則として、オブジェクト指向とかデザインパターンとかがリカバリ作業の障害になっています。運にめぐまれないだけなのかも知れませんけれどもね。破綻したプロジェクトのリカバリという観点からは、プログラムの構造が「構造化」されていないことが、ほんとうにリカバリの障害になってしまうのです。リカバリ工数が適切に破綻リカバリに反映しにくいのです。これは規模とか基幹系具合とも関連あります。そんなに規模が大きくない時には、オブジェクト指向は障害にはなりません。私は昔は小規模のプロジェクトを多く手がけていました。小規模システムである場合には、オブジェクト指向を導入した方が生産性は高いです。規模がずどんと大きい中規模以上の基幹系システム開発においては、作業分担とか試験方法とかのからみもあり、そもそも意味のある単位での構造というものが、どうしても必要になります。興味があるのですけれども...。何とか回ったのですが)。オブジェクト指向やデザインパターンを駆逐したい気持ちを抱かせてしまうのでしょうか。オブジェクト指向とプロジェクト遂行との相関関係を、現状の開発現場で見ていると、どうしてもオブジェクト指向を採用するとハイリスク・ローリターンになってしまいがちです。クラスの構造とかを説明をしている間に期間が終わってしまいますから...。そんなに多くは持っていませんですけれどもね。私はなりたい、と考えていますです。今回の出張シリーズでは、大阪で私が泊まったことのないホテルを転々としています。いつもの宿が連泊予約ができなかったからです。長机の上にノートパソコンや荷物を開いての作業が十分に可能です。畳の上で座布団に座って、そしてノートパソコンで作業ができるのはとてもうれしいです。部屋にはユニットバスがあります。心に深く刻み込まれました。私が普段働く職場からは離れていますし、大阪を代表する歓楽街のすぐそばである上に大きな通りに面しているという立地条件なので私にはにぎやかすぎます。宿泊する部屋として、また連続した出張時の疲労をいやすための施設として、私の希望仕様を満たしていました。大阪に出張する際に優先してリストアップするホテルにしようと思いました。