2005年11月アーカイブ
このまえ、久々に体重計にのったらなんと、ビックリするほどふくよかになっていました。やっぱり夜中にアイスクリームを毎日食べていたのがいけなかったのかもしれません。いくらストレスの溜まる仕事だからといって、一日おきに箱買いしていたのが、体重増加の原因でしょう・・・。
で、2週間前からダイエット始めました。
昔の僕のダイエットは「カロリー摂取激減型」で、2ヶ月で5～7kg痩せるというパターンでした。今回それをやって会社の経営に支障がでてはいけないので、3ヶ月半で、7～8kg痩せるという予定です。徐々に、運動量を増加させながら、食事量を減少させていき2月の終わりには目標体重に到達します！
そこで、まず第一歩として体重計買いました。OMRONの体脂肪率まで計れる優れものです。お値段はたかが体重計のくせにお高くとまっていて13,000円もします。
今朝の僕のステータス：
体重 ： 73kg
体脂肪率 ： 18％
現在3週目に突入したところで、-2kgってところです。
68kg、体脂肪率15％くらいが目標にしています。
もっともSPEC上の数値なぞ所詮飾りです。このたるんだわき腹の贅肉をすべてそぎ落としてやらねば・・・。
三洋が総合家電から撤退することを、中期経営計画で明らかにしました。
実はワタクシ、相当な三洋ファンです。
掃除機や洗濯機などの白物家電ではデザインセンスと斬新性がありますし、半導体部門ではデジカメのマイコン(含むマイコンボード)や、プロジェクタのMEMSモジュールなど、他社の一歩先をいく製品をつくりだしています。また、エコロジーに目をやれば、高効率の太陽パネル、高性能の二次電池などエコの基幹技術を保持しております。
もう数年前から株価は低迷し、業績はさらに低迷していたのですが、「これからは三洋の時代だよ！」って本気で思っていました。その証拠になけなしの資金で株を買い、2年ほど塩漬けにしておりました。(もう売っちゃったけどさ)
実家の近くの工場ではいまでも携帯電話のモジュールを作っているはずです。
もともと、日本には総合家電メーカが(消費者にとってはうれしいですが)多すぎなんです。
車と違って洗濯機、テレビ、アイロン、携帯プレイヤー・・・と全ラインナップをそろえる必要がどこにあるのでしょうか。
ものづくり会社としては良い会社なのですから、これを契機によい経営ができるようになって、ほしいものです。
決算まで2週間切りました！
やっと10月までの経理処理が終わりました。
いやー、死ぬかと思った。
先週末に、開業11ヶ月目にしてはじめてどのくら利益・損失がでているのか調べるために、出納調査をおこなおうとしました。
・・・その結果・・・。
黒字っぽいけどいくら黒字かわからない！（´・ω・｀)ｼｮﾎﾞｰﾝ
と、とんでもない状況でした。
10月に税理士とお話したときは、「まあ、OKOK、俺に任せておけ」みたいなことを言っているので安心してたのですが、正直これではいくら税金にとられるかわかりません。
そこで、経理と税務に詳しい友人に相談してみました。
友「金庫の現金はあっている？」
僕「金庫買ってないYO」
友「・・・。銀行通帳残高は確認してある？」
僕「通帳残高って、記帳してあるYO」
友「・・・。も、もしかして伝票も仕訳帳もないの？」
僕「伝票ってなに？ 仕訳帳ってなに？」
友「借方 預金 100万円 貸方 売掛 100万円・・・ってやつ」
僕「借方とか貸方はきいた事がある、それって簿記ででてくるやつだよね♪」
友「お前の会社おわってる！決算できない」
といわれました。
そんな僕も今では、経理が立派(?)にできるようになりました。
「複式簿記 東京大学 岡部 洋一」
こちらのサイトがオススメです。
もちろん弥生会計などの会計ソフトを利用するのが大前提ですが、それらのソフトも知識無しには使うことができません。2日間勉強すれば簿記3級程度の知識は身につきます。
さて今回のことで改めて思い知らされましたが、経理は経営戦略意思決定をするための財務上の重要な情報元です。自社の事業に応じて勘定科目を適切に設計し、金銭の流れがすべて集約できる仕組みです。
でも、決算や税務のために義務的な作業として経理を捉えている、経理責任者もいるのではなないでしょうか？ うちみたいな零細企業では(やもえず）経理と経営が一体化していますが、50～500人規模の会社では経理部門は存在しても、経理情報が経営にどれだけ生かされているのか、と思いました。
来期は会社の方向性が定まってくる時期なので、来期の様子をみて、3期目に経理の設計をしなおし、4期目くらいから自社の業務に適した勘定科目の設計ができるようにしたいです。
・・・ともあれ、これで夢でも伝票処理する日々から開放されます。
昨今「トロイの木馬」などと称してスパイウェアが話題になっております。
スパイウェアをつかって他人のネット口座番号とIDを盗み取り自分の口座に振込みさせていた人が逮捕されました。
この事件、普通の人には「へー怖い世の中になったねー。よくわからないけど気をつけなくちゃね」なんて感想がでてくるのでしょう。
私は少なからず驚きを覚えております。
平山容疑者が犯行を企画し、指名手配中の男がスパイウエアの作成やメール送付、不正送金の操作などを担当していた、とみられる。平山容疑者らは痕跡を残さないよう、不正アクセスやメール送付には他人の無線ＬＡＮを使っていたほか、都内で男がパソコンで不正送金の操作をした直後に、平山容疑者が静岡市内のコンビニエンスストアで現金を引き出し、連絡にはプリペイド携帯電話を使っていたという。
警察すごいよ！よくこの人捕まえましたよ！
ネット犯罪の捜査の基本はアクセスした端末の特定です。
これは、インターネット接続をしたISPのログを調べればすぐにわかります。特に最近はDHCPでもIPの割り当て時間が長くなっていますので、まず間違いなく接続端末は特定できます。
平山容疑者はそのことは熟知しており、インターネットへのアクセスは他人の無線LANを拝借して利用しています。この方法をとられたら、端末から犯人の絞込みは著しく困難になります。(仮に容疑者を絞り込めて、令状をとるだけの証拠にならない・・・。ま、日本なら軽く別件逮捕ですけどねｗ)
甘い点をあえて指摘するならば、口座に利用したのが日本の銀行だという点ですね。日本の銀行はどこいっても必ずカメラがついています。また、操作も機動的におこなえます。日本の口座からそのまま引き落としてしまったのが、逮捕の原因でしょう。おそらくは2回以上同じ犯行を試みているのでしょう。
しかし、1度で犯行を完結させるとなると、目標金額を1日で動かす必要があります。たとえば1万口座から100万円ずつ、100億円を動かす事自体は可能です。問題はそのオカネの引き出しマネーロンダリングです。さすがに1口座に100億円も詰め込むことはできませんから、100～口座に分散してオカネをあつめ、そのオカネを海外送金しなくてはいけません。
この段階でアラートがなるように日本の送金システムはできているので、まず捕まえることが可能なのです。
でもこの手の犯罪は証拠を全く残さずに実行することが可能なので、犯人の特定・逮捕ができたとしても、データの完全消去されていると裁判で有罪を勝ち取るのは相当困難かもしれません。
東証ダウン、原因は東証と富士通の連絡ミス (ITMedia)
東京証券取引所は11月7日、全銘柄の取引が半日に渡って停止した1日のシステムダウンについて、システム開発の委託先であった富士通の担当者が東証側に送付した資料に記載漏れがあったことが原因だったと発表した
いたたたた・・・
痛すぎです！
「記載漏れをした富士通に全ての原因がある！」・・・と東証は圧したいところです。
しかし、先日も述べましたが、「体制」の責任は発注者側に帰するものです。
「ミスを発生させない体制」には、そのための時間と費用が必要になります。たとえば、今回のミスを防ぐためには、プログラム開発を担当する富士通と、システム運用する東証コンピュータシステムの、各々で新規プログラムの動作検証をおこなうようにしていれば良かったわけです。
しかし、コストダウンを至上課題とし(その結果RASを2の次とし）たために、東証コンピューターシステムは富士通のヒューマンエラーを検出することができませんでした。
組織(and/or会社)が異なれば、当然ながらコミュニケーションの壁が作られます。たとえ、富士通の社員が毎日常駐していたとしても、すべての担当者が常駐しているわけではないのです。プログラムのテスト思考からいえば、モジュール単位のテスト工程を抜きに、システム統合してしまっているようなものです。
ええ、私もよくモジュール単位のテストをサボります。それは納期と予算が限られている場合には、当然の防衛策なのです。発注する側に立った場合には、納期と予算をケチることは絶対にやめましょう。どちらか選ぶとしたら、納期はきっちりとりましょう。納期を厳しくすると(たとえ予算を潤沢にしたとしても)青果物のクオリティは低いものしかでてきません。
もし、納期と予算をギリギリまできりつめたシステムが動いているとしたら・・・それは偶然だと肝に銘じておきましょう。
今朝まで開発で死にそうだったのですが、本日はのんびりしているので東証について調べてみました。
基本的にネット検索で探せる公開情報に基づいています。
東証のシステムについては、「東証ITマスタープラン」をみると概要を捉える事ができます。
図からわかるように大きくわけると、「売買システム」、「相場報道システム」、「清算システム」、「オープン系(HPなどの公開情報)」となっています。今回のシステム障害では、この4つのうちの1つ「売買システム」が全く動作しなくなってしまいました。
売買システムは能力増強のために、昨年から本年5月にかけて祖ストウェアのチューニングとシステムリプレースをしています。そして、10月11日に今回の障害の元となる緊急対応をおこなってしまいました。
システムの開発を行ったのは、報道されているように富士通です。
日経コンピュータの記事によれば、障害原因は証券会社の端末コードを記載した「会員情報テーブル」の読み込みにあります。東証のシステムが復旧、障害原因は10月上旬に更新したプログラム (日経コンピューター)
今回のトラブルに影響した月次バッチ処理は、毎月、ディスクのフラグメンテーションを解消し空き容量を回復するために行われているもの。この処理により月末にディスク上のデータの配置場所が変わるが、新しいプログラムは何らかの理由でこの変更を認識せず、以前の場所にデータを読みに行ったと見られる。読み込めなくなったのは、市場に参加している証券会社とその端末のコードを登録した「会員情報テーブル」である。
記事中には、債権(CB)は影響をうけたが、先物には影響がなかったと書かれていることから、CBと株式で共通利用しているテーブルで影響があったのでしょう。実装プラットフォーム、実装言語が不明なのでどの程度のプログラムミスなのか断定することができませんが、バッチ処理のフラグメンテーションでテーブルの参照ができなくなるということは、一般のDBソフトウェアでは考えにくいです。
売買システムとは別個の、オープン系システムはNTTデータがOracle10gを使って実装していますが、わざわざ「オープン系」と呼称していることから、同様のプラットフォームではないでしょう。カスタムモデルの機器とソフトを使っているはずです。おそらく、DASDの物理データを直接指定するタイプの基幹系なんでしょう。
とにかく、カスタムした機器とソフトのため、通常の10～50倍の費用を富士通から請求されているはずです。
さて、
テストを必要な期間、必要な回数おこなった(天野氏）
ああ、もう気持ちはよくわかる。ほんとよくわかる。
テストってなにも生産しないから、量的にお互いに納得するおとしどころですませてしまいがちです。僕の会社でも基本的には、テスト工数はプログラム工数の30%と定義しています(一人のプログラマが20日で開発したシステムだったら、テスター2人で3日間)。
本当はテストは期間でなくて質の担保をする必要があるのですが、発注者やマネージャ視点からは質の担保をすることがなかなか難しく、そのためテストは量でカバーすることになります。特にシステムの規模が大きくなると、モジュール相互関係は指数的に増大するため、テスト量も指数的増大をしていきます。
量的に網羅性を担保しようとするならば、東証レベルのシステムですと感覚論になりますが、フトウェア開発費用の70~80％は検証費用にあてるべきです。(´・ω・｀ ) ﾃﾞﾓ ｿﾝﾅ ｵｶﾈ ﾊﾗｯﾃｸﾚﾅｲ
また、量的アプローチだけでテスト品質をおざなりにするとテストの価値がなくなります。実際、JASDAQのシステムではテストの質的担保ができてなかったために障害が発生(8月29日)しています。
テスト・検証費用を惜しむのであれば、設計段階から肥大化したテスト工程を必要としないシステム開発を目指す必要があります。
しかし、
「コスト削減」が最重要課題 10年で50％のコスト削減を目指す
この記事にあるように、東証はシステムコストを下げるための戦略として「オープンプラットフォームへの移行」をとっています。もちろん、ハードウェア、ソフトウェアをカスタムメイドからオープンプラットフォームに移行すれば現在ベンダーから請求されている費用の大項目が削れるように思えます。
ですが・・・本当にこれでトータルコストが削減できるでしょうか？
答え ： 東証のトータルコストは下がっても、システムに必要なコストは変わりません。
なぜならば、東証のシステムを開発・保守するための各種ベンダーの目標売上げと利益率がかわらないからです。むしろ、「トータルコストを削減するために390億円の先行投資をする！」などと宣言すれば、現状以上に東証のIT支出を期待して、擦り寄ってくるベンダーが増えるだけです。
にもかかわらず、「俺達はこれしか払わない」という強気の交渉をすれば、ベンダーはありとあらゆるところで人手を省き、目標利益を確保しようとします。(売上げが減った分、利益率を高めようとする)
SIの利益率は一般に30～50％程度はありますので、売上げが半分に減ったら・・・当然利益率は60～100％が目標値となります。
・・・その結果は月次処理のテストもおこなわないチンプな運用で、システム停止に至るわけです。
これで賠償請求をされるようでは富士通もかわいそうです。仮に、障害の原因が単純なケアレスミスであったとしても、障害を出さないための検証開発体制・運用体制を整えていない東証にすべての責任が因するところでしょう。
「ソフトのバックアップを整えることは、現実的には不可能」（天野富夫常務取締役）
現実的には倍のソフトウェア開発代金と保守代金を払えば可能です。
システム開発の費用内訳ですが、多くの案件で(請求書上の)代金はソフトウェアの比率は10~30%くらいです。さらに、ソフトウェア代金も既存のパッケージ代金と新規ソフトウェア開発代金に按分されます。
このように費用面とだけを考えるとソフトウェアの2重化は可能なように思えます。
同じ仕様を2つの開発・保守チームに与えてクリーンルーム開発を行うことで、費用は倍になりますが、全体コストからみると10~30％コストアップするだけで、2倍安全なソフトウェアが開発できそうです。
・・・・
もし、自分のまわりでこんな理論を振りかざす人(特に偉い人)がいた場合、すぐにでも落とし穴を掘って埋めてしまってください。
・システム開発上の費用内訳は、請求書上と実質では全くことなります
・外注先システム会社を管理する社内担当者も2倍必要です
・システムのプログラムを安全に切り替えるためのハードウェア・ソフトウェアの費用が必要です
まあ、こんなこと言わなくてもわかってるだろうけどな！
でもなんとか多重化するソフトウェア開発手法を考えてやろうじゃないか！って思う。この気持ちを大切にしたいです。
