■
今作った開発用の環境。作ろうとしている環境のバリエーション。
これで何ができるかを考えてみた。
DBと画面を完全に切り分けて開発できるこの仕組み。
「DB」−「DBのAccessor」−「画面」
DBの種類を問わず、
画面の種類を問わず、
Accessorで吸収しきる仕組み。
言語の違いがあっても、行うべき処理の流れは変わらない。
データベースの違いがあっても、構築するテーブルレイアウトは変わらない。
変わらないことがおおければそれはシステム化できる。
多くの事例に対処できるのであれば、その仕組みを利用できることになる。
言語の違いは用意するソースで乗越えられる。
データベースの違いは接続用コンポーネントをラップすることで乗越えられる。
例外ケースのような状況であっても、なんとか対処できるのであれば
この仕組みは万能となる。はず。
それもSQL文を自由に発行できることでカバーできると思われる。はず。
とりあえず、
テーブルの検索〜登録更新削除を行う画面を作成するまでの時間を
激減させようという作戦。
ついでに、そのソースは自分達の文化を踏襲した形であることが望ましい。
テーブルレイアウトからそれらを決まった手順に沿って設定すれば、素人でも1〜2時間で終わる。
中身を熟知したものが行えば10分で行える。
そういう開発環境作りを行えたとき、その開発環境そのものが売り物になるだろうか。
開発で行うべきことは、確実に分けて管理されるようになる。
画面は画面、SQL文はAccessorを作る人、
独立したテストが行え、
一覧表示が簡単に設定でき、
詳細画面へのリンクもつけれ、
検索用SQLで行うべきことはすでにソースとして
検索速度、処理効率は踏まえた形で実装されており、
もちろん、複数のSelect文にも対応できるソースである。
メモ書きの工数削減
DBのAccessorはその名の通りDBにSQL文を投げる役割を一手に担っている役割を持つクラス。
そのクラスは主にテーブル単位で作成されることを意図している。
ので。
１テーブルに対応するSQL文を作るまでの時間が削減対象になる。
どれほどの時間がかかるもんであろうか。
かつての企業で予定されていた工数は１テーブルあたり２〜３人日だった。
またある企業では画面の作成工数に含まれていた。全部で８人日とか。
めんどいからテスト込みで３人日としよう。
この３人日が１時間になる。
早ければ10分とかからない。
複雑な検索や、たくさんの検索パターンをサポートする場合にはもう少し長くなる。
３人日が５人日として予定されるものは〜どうだろう。
それでも１人日くらいでおわりだろうか。
遅れても２人日であれば工数は削減できていることには変わりないのだが。
画面はどうだろう。
一覧検索＋登録更新削除機能。
これもかつての企業で予定されていた工数は１画面あたり２人日だった。
また画面の作成工数に含まれていたある企業では全部で８人日を採用してみる。
まあ２人日としても大差あるまい。
この２人日が１時間になる。
早ければやっぱり10分とかからない。
複雑な検索である場合も、Accessorに全てを任せているので画面は変わらない。
画面制御でややこいことをやらなければ変わらない。
画面の入力項目チェックをどこまで行うか、
入力項目の入力値によって画面制御をどこまで変えるかが工数の全てとなるだろう。
ん〜ポイントはどこになるのだ？
これらの材料を持って再考してみる。
仕組みのお勧めポイントは
・『3人日＋2人日→1時間＋1時間にできる』
・『(検索処理等の)品質を安定させる』
この２点になるだろうか。
試算
さて。こんなことにいくらの値がつくだろう。
世の中は相変わらず人月の単価がお好みなのでそれでやる。
1回あたりの削減工数をそのまま価格に反映させれば
20テーブル、20画面ある場合だと、
20テーブル×3人日＝60人日
20画面×2人日＝40人日
合計100人日
これが、
20テーブル×1時間＝20時間
20画面×1時間＝20時間
20時間を人日に変換すると
20時間÷8時間(1人日)＝2.5人日となるから
合計5人日
その差は
100人日−5人日＝95人日
1人月を100万で計算すると。
100人日を人月に変換すると
100人日÷20人日(1人月)＝5人月。
合計500万。
5人日を人月に変換すると
5人日÷20人日(1人月)＝0.25人月。
合計25万。
(´-`).。oO(だいぶ顕著になるよな。)
この仕組みをそのままうっぱらおうとしているので、
開発元としては500のままでも損はないはず。
もともとの開発成果物は得られるし、
次回開発工数を削減できるための環境も手に入る。
