top / index / prev / next / target / source

2005-05-12 diary: パイプ式ファイル(キングファイル)指向方式設計／破綻プロジェクト対応指向方式設計

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

パイプ式ファイル(キングファイル)指向方式設計／破綻プロジェクト対応指向方式設計

ユーティリティなどを設計・製造する場合に、そのユーティリティが利用するメタ情報についてもキングファイル指向という観点が必要な場合があります。メタ情報は 適切に紙ファイリングにつなげていくのだ、という観点がどうしても必要なのです。 , ExcelResourceBundle, , 大阪道頓堀・大和屋本店に宿泊

パイプ式ファイル(キングファイル)指向プログラム設計という観点

私は仕事がら ミドルウェアを作成する立場にあることが多いです。かねてより気にしているのですが、今日はっきりわかったことは開発するターゲットのミドルウェアは、利用する各種メタ情報について最終的にパイプ式ファイル(キングファイル)にファイリングされることを常に意識しなくては、全体的な生産性向上にはつながらない、ということです。 XMLやHTMLは 現状のソフトウェア環境においては、パイプ式ファイル(キングファイル)への紙ファイリングには不適である場合が多いのです。これは残念なことではあります (無料XMLツールなどが一般に普及したら状況は変わるのでしょうけれども)。紙ファイリングには Excelブック形式のような 印刷用ソフトウェアや閲覧用ソフトウェアが普及したファイル形式でメタ情報を格納しておかないと、パイプ式ファイル(キングファイル)へとつなげることが難しいのです。これは難しい命題ですね…。

この日記へのツッコミ

2005.05.15追記 ここからいがぴょん刺激満載のツッコミを、どうもありがとうございます。2005.05.16追記 ExcelResourceBundle が楽しみです。(tidusさんが試作中とのこと)

とりあえず 私なりに ResourceBundleを勉強開始…

2005.05.20追記 tidusさんがExcelMessageResourceのファーストリリースを行われました。

2005.06.14追記 パイプ式ファイル指向方式設計を オレンジニュースさんで取り上げていただきました q(^o^)P

ちなみに blanco Frameworkの構成要素である blancoDbやblancoStrutsはパイプ式ファイル指向方式設計 と親和性があります。(というよりも その基本思想をもとに設計されています) 加えて、私はパイプ式ファイル指向が強い案件においては、生産性・保守性向上のために開発プロセスについても パイプ式ファイル指向にフォーカスしてカスタマイズしていく必要があるとという経験上の結論を持っています。

破綻プロジェクト対応指向方式設計

同じように、破綻プロジェクトへの対応を観点に入れた方式設計という観点も存在するかと思います。終末工程においてインパクトあふれる仕様変更が多く入る可能性のあるプロジェクトや、終末工程で大量の人員が短期で投入される可能性のあるプロジェクトにおいては、きわめて単純なクラス設計・構造によるフレームワークの設計・提供、そして開発標準が必要であるのではないかと考えます。終末工程で破綻している場合には、とにかく構造を簡単にしておいて、常識で対応できる仕組みにしておいて初期教育コストを極小化しておくのです。、、、いまどきの開発プロジェクトの経験とソフトウェア工学やプロジェクトマネージメントの知識があれば、この結論は 比較的誰にでも導出できそうな、そんな気持ちがしました。

破綻したプロジェクトでは オブジェクト指向は 障害になることが多い…

「破綻プロジェクト対応指向なにがし…」を書いていて、ようやく気がつきました。私の経験からなのですが、破綻したプロジェクトでは オブジェクト指向で実現されたプログラム構造がリカバリの障害になることが多いのです。私は 火消しというか リカバリに従事することが そこそこあります (望んでやっているわけではありません…)。いくつかの破綻した現場に共通される経験則として、オブジェクト指向とかデザインパターンとかがリカバリ作業の障害になっています。それはオブジェクト指向やデザインパターンに罪があるわけではなく、適用されたプロジェクトで 運にめぐまれないだけなのかも知れませんけれどもね。

破綻したプロジェクトのリカバリという観点からは、プログラムの構造が「構造化」されていないことが、ほんとうにリカバリの障害になってしまうのです。リカバリ工数が適切に破綻リカバリに反映しにくいのです。これは規模とか基幹系具合とも関連あります。そんなに規模が大きくない時には、オブジェクト指向は障害にはなりません。というか規模が小さければ、どんな手法をもって開発しても、なんとか なんとでもなります。私は昔は小規模のプロジェクトを多く手がけていました。3-4で1-3ヶ月程度 (10人月以下が目安) の小規模システムである場合には、オブジェクト指向を導入した方が生産性は高いです。ところが そんな小規模ではなくって 規模がずどんと大きい中規模以上の基幹系システム開発においては、作業分担とか試験方法とかのからみもあり、そもそも意味のある単位での構造というものが、どうしても必要になります。それが破綻しているときには 特に重要です。

私も本当は オブジェクト指向とかデザインパターンとか 携わってみたいし 興味があるのですけれども…。若かったころは、いろいろ取り組んだものです (そして昔は小規模プロジェクトを多く手がけていましたから まあ何とか回ったのですが)。そういった どろどろの経験が オブジェクト指向やデザインパターンを駆逐したい気持ちを抱かせてしまうのでしょうか。オブジェクト指向とプロジェクト遂行との相関関係を、現状の開発現場で見ていると、どうしてもオブジェクト指向を採用するとハイリスク・ローリターンになってしまいがちです。特に破綻後のプロジェクトでは、たとえば末期状態に半ダースの単位でスタックトレースの読み方を知らないプログラマが急遽投入されて、これで何とか2-3週間のあいだに結果を出せ、のような過酷な現場においては、システムを単純な構造にとどめておかないと、もう、どうにもこうにも なりませんです。クラスの構造とかを説明をしている間に期間が終わってしまいますから…。まあ、さすがに半ダース単位で要員投入という破綻プロジェクトの経験は そんなに多くは持っていませんですけれどもね。

こんなことを書いていたら、「破綻プロジェクト・リカバリのコンサルティング業務」が得意かと思われてしまうかも知れませんね… (苦笑)破綻が発生しにくいように方式技術の設計業務を行うことができる、そういうコンサルティング技術者に 私はなりたい、と考えていますです。

大阪 道頓堀 大和屋本店

今回の出張シリーズでは、大阪で私が泊まったことのないホテルを転々としています。今回は いつもの宿が連泊予約ができなかったからです。そんなことで毎晩違うホテルに泊まっていたところ、大阪 道頓堀 大和屋本店という 私好みなホテルと出会うことができました。

和室ホテル愛好家として、次も泊まりたいホテルとして 心に深く刻み込まれました。私が普段働く職場からは離れていますし、大阪を代表する歓楽街のすぐそばである上に大きな通りに面しているという立地条件なので私にはにぎやかすぎます。でも宿泊する部屋として、また連続した出張時の疲労をいやすための施設として、私の希望仕様を満たしていました。私が今後 大阪に出張する際に優先してリストアップするホテルにしようと思いました。

とにかく出張が長期化すると、私は和室＋布団でないと 疲れがとれません。大浴場も かなり重要な施設です。そういえば、東京に長期出張していた時と同様、和室ホテルは私にとってはかなり重要なポイントなのでしょう。

2005.06.02後日談 その後 ある方に 大阪事業所の付近にある和室ホテル ひし富 を教えていただきました。大阪事業所の近く＋和室ホテル ということで、私の大阪での定宿は ひし富 で運用されるような雰囲気です。

この日記について