中小企業のシステムの中には、今の流行の技術を使うと失敗するものもある

　ちょっと、興味深いブログを見たんで、話は脱線してしまうんだけど、自分の経験したおはなしを１つ。

　中小企業（大企業でも、部署によってはこういうことがあるんだけど）では、今はやりのＩＴ技術を使うと、失敗しやすいケース（＝自爆ですな）があります。

　っていうのも、最近のはやり(Strutsにしろ、JavaBeansにしろ、PHPにしろ）のＩＴ技術って、データベースにRDBを使います。大体（Oracleか、PosgreSQLか、SQLServerかMySQLかの違いがあるが）。

　で、このＲＤＢですが、ＲＤＢを設計する場合、データ構造が決まってないと、作るのが、難しいんです。あとから、適当に追加すると、矛盾をきたしてしまったり。。

　また、ＲＤＢの場合、
　　　　この人のケースでは、この形、
　　　　あの人のケースでは、あの形。。。
　と、ケースによって、データ構造が変わるのも、苦手です
　（情報処理試験お勉強中の方へ；そういう場合、正規化を崩せばできるけど、
　　もし、崩さないなら、そのケースにあったテーブルをもつとか。。。
　　で、テーブルが増える＝操作たいへん。
じゃあ、XMLDBにすれば！と思うけど、そうすると、帳票の細かい出力が大変）

　こういう場合、Excelだと、データ構造をあまり意識しないで、ブック＆シートが作成できるので、簡単に開発できるケースがあります。

　たとえば、介護の顧客情報（＝介護される人の情報）を、保存するケースなどでは、
　　・介護関連法案が、頻繁に変わるので、それに対応して顧客の個人情報の構造も変わる。
　　・その場合、前の情報と、後の情報、どっちも持ってないといけない（構造は、変わるのに）
　　・お客さんの変化によって、新たなデータ構造を導入しないといけないことがありえる
　　　　たとえば、いままで、その会社では、認知症（って、いうそうです。痴呆症のこと）の人
　　　　はみてなかったけど、その人が認知症になったら。。。
　　　　介護に必要な情報は、根本的に変わってきます。
　てなかんじで、ＤＢのデータ構造を定義するということは、できないです。
　極論すれば、介護技術と法案と、会社の成長と、顧客の変化で、データ構造はちょくちょく変わる。

　そういった場合、顧客ごとのExcelファイルを持ってしまって、必要な情報を、テキトーにシート
に入れてもらい、それに検索機能を付けたり（Excelでもかなり柔軟に検索出来るし、マクロ書けば、結構使える）
　帳票を出す場合にも、Excelで、帳票の雛形を作ってもらい、Excelのマクロでデータを取ってきたほうが、簡単に出来たりする（StrutsからRDBでデータ取ってきて。。。帳票に出すのって、どーする(^^;)？FO使う？AccessにODBC接続？？）。

　データ構造が変わっても、Excelのブック内の話であれば（つまり、顧客ごとにExcelファイルを持った場合、顧客の情報が、データ構造ごと変化しても）さして操作に問題はないし。。。
　問題は、スピードと、データの一貫性と、排他制御なんだけど、その辺があんまり関係ないシステムには、Excelのほうが、向いていることもあります。

　問題は、それなのに、ＲＤＢでむりやり作ろうとした場合。。。
　データ構造が決められないのに、無理やり決めようとして、あとで、ちょくちょく修正が入ったり、
　ユーザーが仕様（＝ここではデータ構造）を決められないので、開発できないとか言ったり
　もともと、そーいう構造だから、データ構造は決まらないのに、決めようとして悩んじゃったり。。。
　と、いろんな弊害（＝できないから休日出勤とか、病人が出たりとか）が起こりますな。

業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実

　今までのブログで、ソフト開発の場合、現実的に何にも決まってない状態で、見積もりをしなくてはいけないということを書いてきました。
　で、そんな状態で、どう見積もるのか。。。です。

---

　一応、プロジェクトマネジメントの標準（になろうとしている）PMBOKに敬意を払い、PMBOKで、見積もりを、どうやって出すかについて書きます。

PMBOKでは、スケジュールと、コストを以下のように出します
（プロジェクトマネジメント知識体系ガイド
　PMBOKガイド2000年版　日本語・公式版
　プロジェクトマネジメント協会　の　３３ページの図より引用
　ただし、番号と一部の用語は、ウィリアムのいたずらが変えた）

（１）スコープ計画
（２）スコープ定義
（３）アクティビティ定義
アクティビティ順序設定
アクティビティ所要時間見積り
（４）資源計画
コスト見積もり
（５）リスクマネジメント計画
（６）スケジュール作成
（７）コストの予算化

　つまり、（１）から（３）で、作業を詳細化し、その後所要時間と、人材などの資源を見積もるということになってます。ここから、仕事を積み上げ、何人月という単位で出すので、ソフトウェア開発は、不透明だと、偉い人たち（大学の先生、一流企業のお偉いさん）は言ってます。
　

---

　でもですね、一流企業は、そうやって出してるのかもしれませんが、
　それって、幻想に近いんじゃあないかと、思うんですよ（昔は、そういういい時期もあったと思いますが）。いまどき、普通は、

・開発期間というのは、もう、ユーザーの都合で決まっちゃうことが多いと思います
　　（たとえば、法令が施行されるまえに開発しろとか、競合が販売する前に出せ！とか）。
・予算もですね、たいてい、ＭＡＸは、決まっちゃいます。
・決まってなくても、だいたい使える人材には、限度があります。
・で、さらに、開発方法は、方法論が、会社内で、おおまかに決まっていることが多いです
（特に、ＣＭＭＩっていう、ソフト開発の成熟度を示すものがあるのですが、それを気にしてる会社などは、開発方法が標準化されてるし。。。）

　ということでですね、見積もりをするときは、

　　・内容は、わかんないのに
　　・予算と期間と、作業手順は、おおまかに決まっている

　というのが、多いのが、現実だと思います。
　つまり、人月単位でだしてくれれば、まだいいんだけど、ユーザーの予算と、営業の思惑できまっちゃうっていうのが、現実では？？

---

　では、どうするか。。。ですが、PMBOKで、あと、使っていないで、できる活動っていうと、リスクマネジメントしかないですよね。実際、ウィリアムのいたずらが見積もりするとき、現実的には、こうやってます。

（あ）まず、分かっている範囲の開発内容から想像して、各種要素技術に分解し、その技術を使って、ユーザーが希望するものが、出来そうか、読みきる。
　→読みきれなければ、それがリスクとなる
（い）手順、予算、期間は大体決まっていることが多いので、それを、ならべる
（う）（あ）を（い）の中に当てはめて、大丈夫かあ？って考える。
　→ダメそうだったら、それは、リスク
（え）（あ）や（う）で起きたリスクを他のものに置き換えられないかなどの対応を考える。で、置き換え可能と読みきったら、営業に、「こーしてよー」って、哀願する。

ってな感じしか、現実的には、この状況では、出来ないと思うけど。。。