見積もり
見積もりに関する社内教育を受けろと言われたので、この前受けてきた。
画面やバッチ等の機能の新規開発における高精度の見積もり手法の紹介と
その基本知識を身に着けることを目的とした教育であった。
で、その中の事例で↓のような画面が挙げられていた
社外秘的扱いになっているから数値は言わないけど、
一般的な感覚でいうとこの程度の画面ですら
相当高額での見積もりを標準的に行うよう”教育”された。
システムのことを知らない人がこの画面分だけ切り出されて見積もり見たら
「なんでこんなかかるの？？」って開口一番言いたくなるであろう価格であった
（俺ですらそう思うんだから当然であろう）
内部ロジック（初期表示項目のDBアクセス、チェック処理や更新ロジック）の複雑さもあるんだろうけど、
それにしたってこの程度の画面でそりゃねえだろうと思ってしまった。
通常、新規にシステムを構築する場合、
当然１画面だけを作成するようなシステム開発案件はなく、
様々な画面やバッチ、CSVダウンロード等を含め多種多様の機能があり、
それら全体で●●円、というような見積もりを出すのが普通だ。
全体価格を機能数で割れば１機能あたりの平均単価は出るのだろうが、
機能によって「処理の複雑さ（業務仕様の難易度）」が違うから、
必ずしも平均単価＝１機能の開発コストではない。
そうした背景もあり明細レベルでの見積金額は注目されないことが多いのだが、
１機能毎に見ると驚くような価格が計上されていることもある。
この画面はそう感じるその最たる例だろう。
まあ、とはいえ、
メール系は情報流出に関するリスクが伴うし、
インターネット経由でメール送受信をする場合はインフラ環境の整備等を終えた後でないと正確にはできず
そこでテストして発覚する課題などもあるので、
機能にかかわる体力は通常のDBアクセスのみが発生する画面機能に比べると多少大きいだろう。
（これは見積もりの手法を学ぶための題材として用意された仮想的な画面であるので
その辺の考慮は入っていない）
メール送信にしたって、たとえば現時点で手作業での運用が確立しているなら
わざわざ高いお金を払って「システム化」する方が現場サイドからするとリスクが高いものと感じるだろう。
（長期的に見るとコスト減になるのかもしれないが）
システム化における現行業務の課題に上述したメール送信ならではの課題（誤送信等）があり、
それを機械的にチェックする仕組みの構築が会社として求められているならともかく、
そうでないならシステムにするのももったいないのではと思う。
個人的な、開発する立場からしても、メールとかいう危なっかしいものは出来ればあまり触れたくない。
５～６年前に担当した業務システムでは、
当初「当月売上一覧」みたいなのをCSVファイルでDLして、マクロで取り込む運用を想定していたが、
実際にシステムとして構築・運用してみたところ
システムの仕様上「当月売上一覧」に載ってこない数字が出てきて、
システム改修をするかどうかという議論になり（当然仕様を変更するので「仕様変更」＝改造のために費用が掛かる）、
結局”CSVをDLした後手で内容を修正してからマクロ”という流れに変更された
－と、１年くらいたってから「そういえばあの課題どうなったんですか？」と質問したら言われた－
ことがある。
当初のシステム化の想定は「当月売上一覧CSV」と「マクロ」の間にステップが入ることはなく、
せいぜい作業者のローカル端末に一度DLファイルを落とすくらいだったが、
現時点の運用ではそこに一度「手修正」というシステム外の作業が入るようになってしまっている。
システムを改修すればそれを除外できたが、
「お金をかけてまでその改修をすることもない」という判断だったのだろう。
それは顧客予算や見積金額に左右されるところでもあったのだろうが
その中でも「見積金額」の内容によってどこまで左右されたものなのかは今となってはわからない。
ただ開発する立場からして、
左右できる要素の一つである「見積金額」のほうをコントロールすることでそれがかなったのなら、
もしかしたらお互い幸せになれた機会を逃したのかもしれない。
これはお金とかそういうのを抜きのビジネスにおける充足度（満足度）の話だ。
そう考えると「見積金額」という要素でそれを逃したことは勿体ないなと感じてしまうこともある。
会社の方針が、今回挙げたような（俺ですらそう感じる）高額の見積をする方向に動いているんだとすると
今後こういうことは増えていくのかもしれない…
自分の裁量でできる範囲を広げていくことで、少しは金額面を還元することができるのだろうか？
これはSEに限らずサラリーマンが皆考えることであろうが難しいところである。
