アイロベックスメールマガジン　携帯版

「100年に1度」、「世界恐慌」などという恐ろしい言葉が飛び交っています。
正直、マスコミの報道にはうんざりします。
一部の政治家の言葉に国民が嫌悪感を持ってしまうのも、彼等が所詮、お金に苦労しない人だということも大きいのかと思います。

最近聞いたIT業界絡みの話で、「無理して大規模システムを受注してしまったのが原因で企業が倒産してしまった」
というものがありました。

あまりにもありふれた話なので「またここに書かなければいけないようなことなのか」と思ってしまいます。
この話から理解出来るように、システム開発会社には得意とする規模があるのです。

例えば、ある会社がこれまで機能数20で500万円くらいのシステム開発を行ってきたとしましょう。
（あくまでも仮定なので、この金額から当社の見積もりを想定するのはやめてくださいね。）

この会社が機能数100のシステムを2000万円で請けるとします。

この値段を、お客様や開発会社の中で「2500万円のシステムの2割引き特価」だと考える人がいるかもしれません。

しかしこの開発はおそらく失敗します。
他でも書いてきましたが、20本のシステムの5倍が100本では無いのです。

そして、もっと大事なことがあります。

2000万円以上のシステムを納めた経験が、その会社に何回あるか？ということです。

最大1000万円で機能数40以下のシステムくらいしか経験が無いとすれば、100機能の仕事をまともに納品出来るかどうか疑わしいものです。

つまり、
(1) 工数は機能数に比例するよりも、ずっと増える
(2) 慣れていない規模の開発は難しい

という2つの高いリスクがあります。
どう考えても成功する確率は低くなってしまうのです。

一方、100の機能の仕事をやったことがあるシステム会社であれば、10機能の仕事は確実に出来ます。
ただし、一般的に少し高額な見積もりになってしまうのです。
それは、大規模システムで必要となる「万が一」のリスクへの対処がどうしても入ってしまうからなのです。

システム会社を探す場合は、そのシステム開発の規模に合った会社、経験あるプロジェクトマネージャーを選びましょう。
決して金額で選ばないように。

そしてシステム開発会社は、このような不景気な時代だからといって、背伸びをして大きな仕事を安く取ったりしないようにしたいものです。

自分の得意な規模の仕事であれば、特別値引きをしても大丈夫ですがね。

2008年も終わりに近づいています。
今年もこのメルマガをご愛読いただき、本当にありがとうございました。

このメルマガは、自分がシステム設計するときに、どういう視点でどういったことを考えて設計しているのかを主に書かせていただいています。

それは、若い技術者にとって少しでも何かヒントになればいいなという気持ちからです。

ここで何度も語ったことかもしれませんが、「業務」をシステム化するという一番よくある、それでいて一番奥が深いことについて再考してみたいと思います。

この仕事を始めた若い頃には、私にとって業務という言葉は何を意味するかわからず、ただコンピュータプログラムを作ることだけが業務システムの入り口でした。

しかし、どんなシステムを作ってきたのか？と思い返してみれば、その類似性に驚きます。
業務フロー図といわれるものがありますが、要するに業務フロー図をシステム化することがほとんどの仕事でした。

今でもシステムを作る場合には、「システムフロー図」だけでなく「業務フロー図」を作成することを自分に課しています。

それは、業務システムを構築する上で一番重要なことは「流れ」だと思っているからなのです。

どこでその情報が入力され、付加され、更新されるのか、そして、どこでその情報が出力され、参照され、削除されるのか。

しかし、技術者の中にはシステムの一番重要な箇所は入力や更新だと思っている人がいます。

なぜなら、プログラマにとって入力や更新がバグを生みやすく、難易度が高い箇所だからです。

しかし、システム設計から考えれば、一番重要な箇所はどこでもありません。
すべてです。

すべて重要と言ってしまったら身もふたもないですが、実際はそうなのです。

システム全体の流れをすべて捉えて、その一箇所一箇所のどこででも正しい情報が出力されることが重要なことだと思っています。

そのために、業務フロー図をきちんと細部まで描き、お客様とともに「ここではどんな視点で帳票が必要なのか」「どんな視点で操作しているのか」をシミュレーションしながらシステムの妥当性を問う必要があるのです。

ただ、最初の頃は主体的に業務フロー図を描くことがなかなかできませんでした。

ビジネスのことを考えたこともない、やったこともない私が他の会社の知らない人がどうやって、何を考えて業務をしているかを想像することは不可能でした。

しかし、ある時考えました。
「コンピュータが無いときに人はどうやって業務を遂行していたのか？」「コンピュータが壊れたらこの会社はどうやって業務を遂行するのか？」と。

今となっては24時間無停止のシステムが普通にあるのですから、こんなことを考える必要は無いのかもしれません。

しかし、私のシステム設計の出発時点はこれでした。

コンピュータが無かったとしたら、どうやって業務を遂行するのか？

それを解決してくれたのは―――――。
次回はそのお話です。

先週の続きです。
今回も私のシステム設計の出発地点をお話したいと思います。

「コンピュータが無いときに人はどうやって業務を遂行していたのか？」
「コンピュータが壊れたらこの会社はどうやって業務を遂行するのか？」ということを考え始めたときに、様々なことに気がつき始めました。

その1つの例が、レジのレシートです。

現在のレジの多くはオンラインでリアルタイムにサーバーにレジデータが保存されますが、中にはオフラインでサーバーに繋がっていないレジもあります。

そのようなネットワークに繋がっていないレジを使用している小さな商店やレストランを例に考えてみましょう。

レジの計算結果は、レシートに印刷され、お客様に手渡されます。
同時にレジの中には、計算結果のデジタルデータが保存されます。

では、このレジが突然壊れてしまったらこのお店はどうやって業務を遂行するでしょうか？

おそらく電卓などを用いて計算し、レシートは紙に書いてお客様に手渡すでしょう。

しかし、レジが復旧出来ないとしたらそれまでの細かな売上情報のデータはどうなるのでしょうか？

実は、レジのレシートは複写式になっています。
(現在のレジは、複写になっていないものが多いのかもしれませんが・・・)
お客様に手渡したレシートそのままの印字物が内部に保存されています。
つまり、デジタルと紙の両方でデータの保存を行っているのです。

そのため、最悪レジが故障して復旧不可能になっても、複写された紙からデータの復旧が出来るというわけです。

当たり前だけど、素晴らしい。

私にとっては、そんな小さな発見が業務を理解するための1つの入り口でした。

身近な所で小さな発見をすると、次から次へと見えてくるものがありました。

では、企業間の取り引き、つまり B to B の仕組み、また、社内業務ではどうなっているでしょうか?

次回に続きます。

とうとう本年最後のメルマガとなりました。
2008年も大変お世話になりました。

未曽有（この言葉、気に入ってすぐ使っちゃいます）の世界的経済危機の中、いろいろな思いで年末を迎えることになりました。

リーマン・ブラザーズが倒れ、あの「トヨタ」ですら営業赤字になる可能性が報道されています。（12月19日現在）

営業利益が2兆円を超え、我が世の春を謳歌した（？）あの3月から1年も経たないうちに…、誰がこんなことを予想したのでしょうか。

と、他社のことを憂いている場合じゃありませんね。

「なんでもあるんだ」ということがこれほど、実感できることも今までなかったわけですから、「なんでもある」→「なんでもできる」といった風に前向きにとらえていくチャンスだと思っています。

前置きは以上にして、前回はレジの話をしました。

POSレジなんてメーカーは限られているし、請負や派遣の仕事には関係無いと思っているあなた、レシートひとつをとっても、そこから学ぶことは幾つもあるということが分かっていただけましたか？

例えば、忘年会のゲームとしてこんなイベントをしてみてはいかがでしょうか？

コンビニで買った商品を3つほど見せて、ここからいかに本物のレシートに印刷されている項目を予測するかという「レシート再現コンテスト」を行うのです。

こんなことを考えるのは仕事中毒の証拠ですね。

さて、社内業務の仕組みでレシートに代わるもの。
それは、「伝票」です。

伝票という言葉がすでに「何？それ」という感じかもしれませんが、簿記を勉強された方や、販売管理システムに携わった経験をお持ちの方であればご存知のはずです。

前々回からのテーマである、「コンピュータが無いときに人はどうやって業務を遂行していたのか？」ということなのですが、コンピュータが無い時代には、売上伝票、仕入伝票、入金伝票、支払伝票、振替伝票、出荷伝票・・・という様々な種類の伝票を使っていました。

他部門や他社との関係の中で「発生した取引」を簿記では、仕訳（しわけ）という言葉を使い、伝票に記入していました。

これを「仕訳伝票」といいます。

「モノ」「カネ」が動く場合は、必ずその部門の担当者が仕訳伝票を記入し、その伝票を経理の担当者が記帳していたのです。

ただし、企業規模が大きくなり、「仕訳伝票」だけでは情報を管理することが難しくなってきました。

例えば、取引先を登録する、受注を受け付けるということは、経理の作業とは関係ありません。

それでもシステムでは取引先を登録し、受注を入力する画面を必要とします。

こういったものも仕訳とは異なりますが、「伝票」という紙に書くことはできます。

「取引先登録申請伝票」「受注申請伝票」といったものです。

例えば、新規に取引をしたい取引先が現れたとき、担当者は「取引先登録申請伝票」に記入します。

伝票に記入する理由は大きく分けて、

1)誰が、いつ、どういう理由で何を申請したのかを記載する（発生の根拠）
2)伝票を他部門（他社）に渡すことで情報を受け渡す（情報の伝達）

といったことになります。

だから日付、担当者（記載者）は伝票にとって最重要になるわけです。

取引先登録申請伝票は複写式で、1枚は自分に、そしてもう1枚は部門長に提出します。

自分が保管する伝票は「取引先登録申請伝票（控）」です。

何時その伝票を記載して部門長に渡したのかを控えとして保存することで、万が一に備えるわけです。

このように、伝票には「（控）」というコピーを保存して、

3)万が一の情報紛失に備える

という機能もあるのです。

部門長はこの申請伝票を確認し、承認欄に印を押して、取引先台帳に記載する担当者に回します。

これが部門長一人の場合もあれば、部門長→経理課員→経理部長といったルートで回ることもあるでしょう。

この場合には、伝票上にその個数だけ承認欄として日付・担当者名の捺印欄が必要となるのです。

このように、伝票の項目レイアウト設計をする場合には、業務運用の流れが頭に入っていなければなりません。

だからこそ、伝票に必要な項目がどれだけ思い浮かぶかが、業務運用フローをどれだけ理解しているかのテストになるのです。

こういうときには「5W1H（When，Where，Who，What，Why，How）」はもちろん有効ですが、コンピュータシステムを考えるとき、画面や帳票を考える前に、まず手書きの伝票で業務運用を回すということを考えてみてください。

それでは、良いお年をお迎えください。