オリヴィアを聴きながら

2男児の母、業歴XX年のシステムエンジニアが日々のもろもろを雑記します。
コメント歓迎。

気持ち悪い・・・・

2007-04-26 20:41:06 | 最近思うこと
息子1号のチャレンジXX年生に付き合って、2号チャンも「こどもチャレンジ」のしまじろう君を定期購読している。

が、いつもこれを読まされる私は
「気持ち悪い~」
と思ってしまう。

なんかね、しまじろうの家族ってモノゴトに対する反応が常に非常に「優等生」なのよ。

こんな家族、ずえーったいに実在しないとしか思えないような・・・

それは、息子1号も感じるらしく、「にやにや」しちゃうんだよね。



が、「これが本来の姿だ」と思っちゃう子どもがいると痛いなぁ・・・と、感じます。
こんな理想の「かーさん」いないって!

帳簿をつけよう

2007-04-26 00:52:02 | 最近思うこと
今住んでいるマンションをとりあえず、不動産屋さんに委託して賃貸に出そうときめました。
(って、まだ不動産屋にすら行っていないけど。)

で、そうすると不動産賃貸の事業を行うことになるわけで、この収入には当然ながら税金がかかります。
節税のためには「会社設立か!」と先走りましたが、よくよく考えれば、会社設立すると法人税を払わなきゃいけない。法人税分も経費を使ってたら、もともと収入が少ないんだから赤ですわ。

それに、一部屋くらいの賃貸じゃ「賃貸事業」とは認められないそうで「不動産所得」として処理することに決まっているらしい。

では、青色申告して節税10万円を目指そう。帳簿つけはどうせ必要なんだし・・・と思うこのごろ。
オットが株投資で損こいてる分とかも一緒に事業として申告できるんだろうか?

そもそも、この不動産はオットとわたしの共有名義なんだけど、「青色申告」は私が一人でしてもいいの?

とまだまだなぞはつきません。
この賃貸収入が黒なら私の事業として申告したいし、赤ならオットの事業として申告したいんだけど・・・・そもそも、共有持分で按分が必要なんだろうか????

システム開発委託先選定の着眼点(規模見積)

2007-04-26 00:35:01 | お仕事情報
前回、受託元がベンダーを選定する際の着眼点についてお話しましたが、今回は、元請ベンダーが下請のソフトハウスを選定する際の着眼点をお話します。

ユーザ企業のシステム部門の方が、委託先のベンダーを選定する際の着眼点としてもご参考になるはずです。

要求定義がだいたい確定してお客様に費用見積を提出する際には、見積作成したエンジニアにはそれなりの「規模」が想定されています。

それは、画面や帳票の数だったり、メニューの数だったり、機能の数だったりするわけですが、生産性や工数を算出するために、言語を想定してプログラムの出来上がりステップ数に換算するのが一般的です。

まず、要求定義から機能をニンゲンが運用する単位くらいまでにブレークダウンして、運用する際に「動かす」単位での画面や帳票の数に落とします。
このアウトプットの難易度や項目数を加味して、だいたいの出来上がりプログラムのステップ数を予想します。

この部分は、「女の勘」です。
(見積金額が気に入らない営業担当者は「この見積根拠はなんだ?!」と詰め寄るので、必ず「女の勘」と応えることにしています。どんな根拠を述べようが、自分が売りたい金額の見積が出てくるまで、あれやこれやと説明を求めるに決まっているので、言うだけ時間の無駄です。)

さて、この「勘」ですが、「男の勘」はだめです。
「管理職の男の勘」なんてのは最低です。
邪念が入りすぎて、あたったためしがない!

そもそも、「戦略的価格設定」という言葉はあったとしても、「戦略的見積」が存在してはならない。
この辺を取り違えている営業マンのなんと多いことか・・・
見積を根拠として、工程を作成して、人員を確保する。
この見積を「売値」から逆算して作成したら、完成前に納期が来て、人がいなくなるということは明白です。
この当たり前のことがわからなくなってしまうのが『邪念』の恐ろしさです。


話はそれましたが・・・
基本設計がある程度終わって、開発を外注に委託する際の見積では、必ず、金額だけではなく予想ステップ数を出してもらいます。
(所要工数ではありません。所要工数を出すと単価がバレバレですよね。)

この予想ステップ数が、私の予想よりも大きい場合は他を探します。

同じ機能なら、より小さなプログラムを仕上げてくれる会社を選びたい!
たいていは当初の予想ステップよりも出来上がりは2割増になるものです。

出来れば、こちらの予想ステップの2割減程度の目標値を掲げる会社とお付き合いしたいです。

同じ機能なら、小さなプログラムのほうがたいていは高品質になるからです。
これは、標準化・共通化・部品化(汎化・抽象化)が適切になされて、再利用可能なモジュールを組み合わせたつくりのほうが高品質になるからです。

例えば、似たような機能の処理Aと処理A'があったとしましょう。
甲社はこれを、共通な処理を一まとめにしたプログラムCと、処理Aの独自機能のプログラムA,処理A’のプログラムBの3本で作成します。
乙社は、処理AをプログラムAとして作成し、これをコピーしたプログラムBに処理A'の独自機能部分を追加変更して2本のプログラムを作成します。

乙社の納品プログラムのほうが大きくて、乙社の生産性のほうが高く見えます。

しかし、これで共通する処理部分に不良があった場合、その修正コストは乙社のプログラムのほうは2倍になります。
設計に不良があって、ドキュメントの改修が必要なら、修正コストはもっと差が出ます。

納品時の金額が同じなら、乙社のプログラムの品質は低い。
テストの手間を考えればわかるはずです。

きちんと仕事をしている会社であれば、プログラムは可能な限り「小さく」を目指すはずです。
だから、私は自分の見積よりも「大きな」規模見積をしてくるソフトハウスには製造を依頼したくないのです。


これは、委託元が元請ベンダーを数社から選定する際にも指標として使えますね。
ただし、使用する言語によって機能実現のためのステップ数が異なりますので、使用言語が違う場合は比較できませんので念のため。