派遣スタッフひとみの起業日記

暑中お見舞い申し上げます。

本当は梅雨明けから暑中見舞いというのは出すものらしいのですが、
このところの暑さでは、もう明けたといってもいいですよね。

暑いですね〜。甲状腺機能低下症の私としては、
今年の夏は汗をかかなくて楽、・・・なのかと
期待していたのですが、全然そんなことありません。

暑いです。毎日汗だくになっています。
なぜなんでしょ？

やっぱり、この病気を引き起こした原因となるストレスの
新システムが、私にいまだにアドレナリンを放出させるんですね(^^;

ある意味すごいシステム会社ですね。

さて、その新システムも来月説明会でいよいよ発表し（たぶん）、
９月より本稼動する運びとなりました（たぶん）。

先が見えてきたから、というわけではありませんが、
この体験を元にいたしまして

小説

を書いてしまいました！

いえ、あくまでもフィクションです。
登場人物・団体はすべて架空です。
夢物語も入っています。

・・・でも、ちょっぴり事実も入っているかもしれません。

「ケイ子さんへのメール
　　　社内ＳＥひとみのスットコドッコイな日々」

PDFファイルで販売しております。
もし、お読みくださる奇特な方がいらっしゃいましたら
こちらのページへおいでください。

　　ダウンロードページ
オフィスコロミーにて販売しております。


ちなみに、目次をチラッとお見せいたしますと

　　ケイ子さんへのメール　その１
　　ケイ子さんへのメール　その２
　　ケイ子さんへのメール　その３
　　ケイ子さんへのメール　その４
　　ケイ子さんへのメール　その５
　　ケイ子さんへのメール　その６
　　　　限りなくワープロに近いシステム
　　　　初期値を入れてない？
　　　　間違いを認めない人
　　　　有ひものデータベース
　　　　データの意味を軽んじているシステム
　　　　人に依存するシステム
　　　　顧客を不安に陥れるシステム
　　　　アナログ頭のＳＥ
　　　　振り出しに戻るシステム
　　ケイ子さんのシステム

あら、どこかで見たようなフレーズが(^^;

実を言いますと、本稼動の予定が立った今になっても
いまだに不具合が見つかっているのです。
修正すれば済むような小さいものですけど。

どうして、ひとつ直したら関連するところも全部直さないんだろう？
と思います。
それよりも、ひとつ直したら連動して関係するところは全部自動的に直るように、最初から設計すればいいのに、と思います。
それが、プロがつくるスマートなシステムというものではありませんか？

今回、さまざまな不満をこめて（結局ストレス解消だった？）
この物語を書いたのですが、
あくまでもフィクションとして、自分が全体像を眺めるつもりで
書いていきますと、「ああ、そうだったのか」と見えてくる部分も
ありました。

これこそが「俯瞰して見る」ということなのではないかと。

なんだかスッキリしたので、次に進めそうです。(^^)ｖ

７月ですねぇ。

例の新システム。テスト入力を始めてから
ちょうど１年がたちました。
いろいろな不具合が発生しましたが、
なんとか９月くらいから本稼動しそうです。
たぶん・・・ですが（笑）

でも、その予定を聞いたとたんに
在庫の数が合わないという不具合が発覚！

そろそろいいかな〜と思うと不具合が発生する。
・・・もう驚きませんけど(^^;

もしかしたらマーフィの法則のごとく
他のシステムもそういうものなのかも
しれませんし。

その不具合については、もう解決したので
笑い話としてお話しいたしましょう。

先月のことでしたが、
「売上返品」があったのです。
去年の秋にも返品伝票を立てて、その伝票を取り消したら
在庫と連動してなくて数が合わなくて難儀する、という
不具合がありました。
携帯から注文を入れても、在庫に反映されないという
不具合もあったっけ・・・。

まぁ、そんな経験がありましたので
しかも、そのときもシステム会社から
「勝手に返品伝票を立てるな」
といわれてましたので（笑止千万）
今回は、向こうから渡されたマニュアルどおりの手順で
返品伝票を立てたのです。

そのあとでした。
在庫が「６」少ないのです。
返品した数は「３」でした。

６少ない・・・返品したのは３
６は３の倍数・・・・あれぇ？？？
まさか「３の倍数がバカになるシステム」？？？？
そんなバカな(^^;）

もう、お分かりでしょう。
返品伝票の「３」は返品ですから在庫は「３」増えるはずなのに
戻っていないのです。
しかも、返品伝票だったはずなのに、むしろ「３」減っているのです。
つまり売上伝票を立てたことと同じになっているのです。

だから３の倍＝６　少なかったんですね。

返品伝票で、お金に関しては−（マイナス）表示になっていましたが、
数量は「３」となっていたので
（大丈夫かなぁ？これ？）
とは思っていました。

返品伝票なんだから、表示では「３」でも、
中の計算はちゃんとしているのだろう、と
思っていました。
いくら、限りなくワープロに近いシステムでも
それくらいの計算式はちゃんと設定しているだろうと。

・・・・甘かったです。
このシステムに関しては、信用しちゃいけなかった。

たぶん返品伝票としての計算がされていないのだろうと
思っていましたが、システム会社には「事実のみ」を
伝えてもらいました。
実際にデータの入力をした人に、
こうして、こうしたら、こうなった、と
説明してもらいました。

システム会社のＳＥは、これを聞いて
「例のない不具合なので、調査します」
と言ったそうです。

まぁ、予測はついたとしてもその場で言うことは
立場上できなかったかもしれません。
しっかし、さも「想定外の重大な不具合発生」のように
言わなくてもいいでしょうに。

結局、最初にお話ししたとおり、返品伝票なのに
数量のみ売上伝票のように計算されていた、
という結果だったのですが。

さて、私が今回思ったことです。

たぶん、その場であいまいなことを言うと
あとで言質をとられて大変なことになるかもしれないから
「調査してお返事します」
としか言えなかったのかもしれません。
が！
システム会社のＳＥが、お客さんを不安に陥れても
いいものでしょうか？
「たぶん計算式の問題だと思いますが、念のため調べて
お知らせいたします」
くらいのこと言えないんですかねぇ？？

「例のない不具合」なんて言ったりしたら、
もしシステムのことが全然わからない人なら
「何が起こったんだろう？何かヘンなことをしでかしてしまったのかしら？」
と不安になると思うんですよね。
そうなると、もうそのシステムを使うのが怖い。
何が起こるか、わからないから。
使うのは避けたい。むしろ、使いたくない。
と、なるんですよね。
まぁ、今回システム会社に電話した子は、
呆れて笑っていましたけどね。
（何が起こるかわからないから怖くて使いたくない、
というのはあるみたいです。私も同じ気持ちです。）

システム会社のＳＥの皆さん。
ご自分に理解不能なことでも、とりあえず
「大丈夫！なんとかしますから！」
くらいの気持ち（気持ち、でいいのよ）を
表してくれませんでしょうか？

そうしたら、顧客の信頼を損なわずに
ますます良好な関係を結べると思うのですが。

どう思われますか？

お久しぶりです。
更新してなくてすみません。
今、ある商材を作るべく、密かに活動中です（笑）
そのうち、お披露目させていただきますので
またご意見をいただけたら嬉しいです。

さて、その商材につきましてはまた改めて、ということで
今日は久しぶりに、あの新システムの新たに発覚した不具合について
ご報告です。

まだ、テスト中なんですよ！みなさん！
いつになったら本稼動するんでしょうねぇ・・・。
そろそろいいかな？と思うと、何か不具合がでてくるんですよね。

今回は、配送についてのデータの不具合です。
新システムでは、発注するときに商品が届く時間を指定することができます。
今はテスト中ですから、こちらが代わりにデータ入力をしていますが。

たとえば、
　　0：指定なし
　　1：午前中
　　2：12時〜14時
　　3：14時〜16時
　　4：16時〜18時
　　5：18時〜20時
　　6：20時〜22時
の中から選べるとしましょう。

Ｓ社の仕様として「特に指定がない場合は『午前着』にしています」
と、伝えていました。

さて、今回発覚したのは、この時間指定に関することです。
だいたいが「午前着」で問題はないのですが、
中には「指定なし」を選びたい、という人がいるのです。
そして、選択肢の中に「指定なし」がある以上、それを選んできますよね。

ですが、配送センターに送るデータには「午前中着」となってでてきてしまうのです。
実際にそれで送ってしまう前にこちらで気づいてデータの修正をしましたので問題は起こりませんでした。
しかし、こちらが代わりにデータ入力をしているからわかるのであって
これが本稼動になったら、注文は先方が入れますので
誰が「指定なし」を選んでいるのかわかりません。
そのまま間違った指定でデータが流れてしまいます。

それではまずいだろう、ということでシステム会社に言いました。
その回答は・・・・
「『指定なし』は『午前中着』にするのだと認識していました。」

こちらが言っていたのは「特に指定がない場合は・・・・」であって
「指定なし」を選んだのならそれは「『指定なし』を指定した」ことになるのですが。（あーややこしい）

そして、直してもらいました。

そうしたら、今度は
「指定をしなかった」とき、つまり配送時間指定の欄を空欄にしたままのとき（既定値が設定されてない！）
「指定なし」のデータが出力されるようになったのです。
空欄ということはNull値です。それは「指定の意思がない」ということです。
そういう場合は、「午前中着」なのよね・・・・。

さて、この不具合。何が原因なのでしょうか？

日本語能力の問題でしょうか？
　「特に指定がない場合は、午前中着にする」
　　　　　　　　↓
　「『指定なし』は午前中着にする」
と受け取ったシステム会社の担当者の日本語読解力の問題？
ちゃんと伝えられなかったこちら側のコミュニケーション能力の問題も含めてですが。

まぁ、これが大部分の原因なのでしょうが、
私が思うのは、もっと基本中の基本

　「0とNullの違いがわからない人がシステムを作っている」

ことも問題なのじゃないかと思うのですが、
どう思われますか？

他にもこういう不具合の事例ってあるのでしょうか？
あきれかえって口がアングリ開いてしまうのですが・・・。

こんなの、私がもし作るとしたら（Accessで、ですが）
「既定値を『1：午前中着』にしておく」
だけで済むことだと思うんですけどねぇ。
SQLって既定値の概念がないんでしょうか？
不勉強で申し訳ありませんが。

もう遅れているといわれるかもしれませんが
やはり、こういうことがありますと
「あ”〜〜〜」（にしおかすみこ風）
と叫びたくなるのでした。
誰か私にムチをください！（笑）

またまたおサボしておりましてすみません。
ほぼ１ヶ月ぶりですね。

久しぶりなんですが、例の新システムについてのご報告です。
あまりにも不具合が多いので、それを１つにまとめてみたいと思って
それで最近はあまり書かないようにしていたのですが
相変わらず「すっとこどっこい」なことをしでかしてくれてます。

昨年１１月に起きた不具合
　こちらで書いています→データが持つ意味

これは１１月５日に起こった不具合でした。
　Ａの欄の数字がWeb上で表示されるはずなのに
　Ｂの欄の数字が表示されている。
こういう間違いでした。

１１月６日には、その表示の間違いは修正されました。
それは確認しました。

普通なら、それで２度と同じ間違いはないはずですよね？

昨日、再びＢの欄が表示されていることがわかりました。
昨年１２月にプログラム修正があったのですが、
どうやらその際にWeb表示との連動が元に戻ってしまったみたいなのです。

信じられない・・・（呆）

１１月６日の修正の際に元のプログラムソースを直していなくて、
１２月のプログラム修正のときに、１１月５日以前のままのプログラムソースを修正して更新してしまった

だそうです。

今回はさすがにＳ社の役員も怒って（呆れて）
きちんと文書で原因を報告するように先方に申し入れました。
その回答が上記です。

いろいろと不具合のあった新システムですが、
そのたびにギャーギャー怒っていた私ですが、
ひとつひとつ不具合をつぶしていって完成形に近づいているのならば、
まだいいのです。

でも今回のように、
以前直したはずのものが、他の修正をしたことによって元に戻ってしまう
なんて言語道断でしょう！
毎日毎日今までにあった不具合が修正されているかどうかすべてをチェックしながら運用していく、なんて無理です。
というか、そんなシステム使い物になりません。

しかも！

こういうバカな間違いが起こったのは、これが初めてではないのです。
以前にも同じことをやっています。

学習能力なさすぎ！！

人に「間違えるな！」という前に、
自分たちのところで「間違えるなよ！」
と言ってやりたいです。

本当に本稼動の日がくるのか、疑問であることにはかわりませんが
もっと積極的に「やめたほうがいい」と思いましたね。
システム会社は、ほんとーーーーーに、よぉっっっく吟味したほうがいいですよ、みなさん。

１ヶ月もおサボしてしまいました。すみません(^^;;

今年はなるべく怒らないようにしようと思っていたのですが
相変わらず激怒の日々です（笑）

何よりも、年明けにおきた
「人に依存するシステム」事件（大げさな^^;）

激怒するというよりも呆れ果て、完全にこのシステム会社を気持ちの上で切り捨てました。

今までにも
「限りなくワープロに近いシステム」
「有ひものデータベース」
「動線を考えていないシステム」
と、新システムのことを評してきましたが
もう１つ加わりました。
「人に依存するシステム」

使う人の資質に依存するということです。

要するに「間違えるな！」ということです。
「間違えても自分たちじゃ修正できないんだから、いわれたとおりに間違えないように入力しろ！」
ということです。

この言葉どおりに言われたわけではありませんが
こういう内容のことを言われたのです（メールだけど）


こちらは、間違い入力があったのでそれを直したい
（どうして、こちらで修正することができないの？）

そして、間違いようのないようにしたい。
できれば自動化されて人間の手がかからないのが理想だが
それはできないというので（技術がないから）
せめて、「○○の入力を忘れています」とアラートがでるとか
必要な情報がないと、出力されるはずのデータが出てこないとか
その理由を表示するとか、
要所要所で間違ったデータが流れ出るのをせき止めるチェック機能がほしい。

もしくは、自動化が無理で手順どおりに作業しろというのなら
「次は○○をしてください」とか、システムを使う人が誘導されていくような（せめて）表示はできないのか？
それもだめなら、手順どおりにタブを配置することはできないのか？
さらには、言葉ひとつとってもそのシステム会社独自のものを使っていたりするのでわかりずらい。どういう処理をするボタンなのか、内容に即した名前を付けられないのか？

こういう内容を聞いたのですが
要は「手順どおり間違えなければいい」
というスタンスなのです。相手は！

やはり最初から業務フローなど考えてもいないシステム会社の弊害ですね。
動線が考えられていないのです。

さらに、昨日また大激怒してしまいました（またかいな^^;）
でももう、このシステム会社には関わりたくないので
無視することにします。

この経験を元に「こんな（システム）会社に気をつけろ！（仮題）」を書きたいですね。

そろそろ会社でも大掃除をしている方もいらっしゃるかと思います。
大掃除とまではいかなくても、自分の机の上くらいはきれいにしようかな、と思っている方もいるでしょう。

私も早く机の上の書類の山を片付けたいです・・・。
全部、新システムのテスト結果ですよ。
不具合が多かったからねぇ・・・。

さて、片付けについて今日思ったことです。
会社で、Ｓ社の社員（役員）が私に「○○の契約書を持っていてくれない？」と言ってきました。○○の契約書は私には直接関係のないものです。（支払いは関係するけど）
契約書関係は私が保存する、という役割分担にはなっていません。
そこまできちんと決まっていたら苦労はしないかも。

役員が私にそう言ってきたのは、「自分で持っていたらどこかに失くしそうだから、誰かに持っていてほしい。必要なときに出してくれれば。」という理由からなのです。

私の机の引き出しには、経理関係の書類が詰まっています。
あと、システム構築関係もあります。
その中に「パソコン関係契約書」というフォルダーがあります。
ネットワーク保守とかそういう契約関連をひとつにまとめてあるのです。
役員は「そこに入れておいて」といいます。
契約書だからそこでいいだろう、というのです。
でも○○の契約書はパソコンとはまったく関係がありません。

あの〜ただフォルダーに入れておけばそれで片付けたってことにはならないんですよ〜

ありがちな「とりあえずどこかに入れておこう」のノリですね。
でも、そういうことをやると絶対に失くしてしまいますよ！（断言してもいい）

あるものを片付ける・保存するなら、そのものがそこにある「理由」を考えて保管場所を決めましょう。
そうしないと「どこに入れたっけ？」と必ず探し回ることになります。

結局、○○の業務に関わる契約書のファイルがあったので、そこに保管することになりました。

ホントーに、ファイリングシステムについて、特に保管の基準について、基本から考えなければならないＳ社だな、と痛感しました。

ニュースで見ましたが
年金問題で大臣がなにやら弁明をしていましたね。

結局約束は守れず、３月までに全部明らかにするといったことも
できないということがわかったとか・・・。
ここまでひどい状態になっていたとは思わなかったとか。

いろいろ言ってました。

それに対してテレビのコメンテーターが
「わからない、ということがわかったからってそれが『完了』になるのか？」
と言っていました。

なんだか、どこかで聞いたような話だな〜と思ったんですが（笑）

同じじゃないですか、あのシステム会社と。

「修正対応が完了した」
というのは
「修正する用意が完了した」
という意味らしいですし。

この「もどかしさ」「イライラ」はどこから来るのだろう？と思っていましたが、
官僚的
なのかもしれない、と思いました。

絶対に自分は悪くない、という姿勢をとりますしね。
不具合は、誰かが「ヘタこいた〜」からだと、いつも言いますしね。

「ここまでひどいとは思わなかった」
というのは、こちらのセリフですけれど。

アウトソーシングするときとか、
外注に出すときとかは
相手の会社はよおっく吟味して選ばないといけません。
つくづく思います。
難しいんですけど。
営業は、いいこと言いますからねぇ。それが商売ですから。
どうやったら、見抜けるんでしょうねぇ。

まさか、「おたくでは『完了』といえば、どのレベルのことを指すのですか？」と聞くわけにもいかないし・・・。

本当に難しいですね。

さすがに年末は忙しいですね。
Ｓ社は年度末でもあるので余計に忙しいです。

しかも今年は新システムへの移行時期でもあるので
テストとして新システムにも入力し
今までどおりのAccessで作ったシステムも使っています。

新システムが十分信頼できるものだったら
もうAccessのシステムは使わなくてもいいのですが
今まで書いてきましたとおり、とても信用できるものではありません。
すっごい２度手間！

少ない人数でやっている会社ですから
なるべく無駄なことははぶき、システィマティックにしたいと
いっているのに、
そのために新システムを導入することにしたのに
なんだか逆になっていっています。

うーん、泥沼か？

そして、頼みの綱のAccessもだんだん危なくなってきました。
以前より動きが重くなっていたのですが（データが溜まっているから）
最近はエラーメッセージがでて強制終了してしまうようになりました。
２人で同時に使っていると、競合が起こってしまうようなのです。

今までだましだまし使ってきた（というか、とってもラッキーだった）のですが、とうとう限界がきたようです。
Accessも自分のお役目は終わったと思って、

老兵は死なず。ただ消え行くのみ・・・・

と、身を引いていっているようなイメージ。

でも、困るんですよ。まだ新システムができていないし・・・。

どうせ新システムになるのだから、と
AccessからSQLへのアップサイジングも棚上げしていましたが、
やはり密かに移行できるように
用意しておいたほうがいいかもしれません。

そしてまた仕事が増えていくのね・・・（涙）

新システムの在庫が合わない件

システム会社より返答がきました。
原因はほぼ予想と合っていました。
やっぱり、中が連動していないんじゃん！

それはそれで理由がわかればスッキリしていいんです。

でも、直したのは（原因がわかったのは）一部分だけ。
他にも合わない部分はあるのに、それは忘れられているようです。

いっぺんに１個ずつしか認識できないんだね。

それでも今日来たメールには
「修正及び対応完了」
とありました。

本当に？と疑問を持ちつつ、確認しました。

全然直っていないじゃん！

それなのに、訪問したいというのです。
たぶん、今回の不具合について説明（弁明）したいのでしょう。

でも、修正が全然できてないよ・・・。

それに対する答えは
「訪問時に確認していただきたかった」
だそうです。
訪問日をまず決めて、それまでにすべてを変更する予定だったのだそうです。
だから、私たちが今見ても直っていないわけです。

ここの会社はいつもそうなのですが、
私たちの目の前で会社に電話して
「更新して」と指示をするのです。
目の前で画面がパッと変わるのが「劇的！」とでも思っているのでしょうか。
それよりも、キチンと直して、テストをして、間違いないとなってから
訪問してほしいんですけどね。

たいがい、目の前で更新しても
「ここ違いますよ」
ということが起こって恥をかくのは自分たちなんだけどね。

修正が先か、何が原因で起こった不具合かを説明するのが先か。

みなさんだったらどうしますか？

システムに関わっている方なら
バックアップの重要性について
身にしみていらっしゃることでしょう。

私も、何度かデータを消してしまった経験から
バックアップは大事だな、と常々思っていました。

会社のＰＣはバックアップシステムが整備されていますからいいとして、
自分の家のＰＣのバックアップ。
これは、つい後回しになってしまいます。

やっておかなきゃな〜

と思いつつ、「今度やろう」と先延ばししていると
そういうときに限ってクラッシュしたりして
泣きます（涙）

ＰＣだけでなく、他のことでも
バックアップって大事ですね。

今日は私のバカな体験を聞いてください。

大掃除をする前に、モチベーションを高めよう！と
昨年放送された松居一代さんの「開運大掃除」の番組を
見ようと思っていました。
DVD-RAMに録画してあって、それを今年（特に前半は）
繰り返し繰り返し見ていました。
それを久しぶりにもう１度見ようと思ったんです。

そうしたら！見れないんです！
「フォーマットされていません」
と出てしまうんです。

何かおかしなことになってしまったんですね（よくわかりませんが）
フォーマットし直したら、録画してあるものは消えてしまいますよね。
もしかたしたら、ディスク自体がダメになっているのかも。

結局、松居一代さんの番組の録画はもう見れないのです。
がっかり・・・。

あまりにも繰り返し見ていたので、DVD-Rに焼いて取って置こうかな、と思ったのですが、ビデオテープと違いDVDだから劣化することもなかろうと油断していたのが敗因です。

映画だったら、レンタルでDVDを借りることもできますし
市販のものを買うこともできます。
でも、ああいうバラエティはDVDになりませんもんねぇ。

こういう録画もバックアップって大事なのです。

そして何よりも
「やっておかないとな〜」
と思ったことは
「今すぐやるべき」
なのだと実感しました。

お気をつけください。

昨日書いた新システムの不具合につきまして
今日、検証をいたしました。

いろいろな場合を想定して
ひとつひとつ確かめながら
やってみましたよ。
必要な資料を集めるのに、捨ててしまった書類をゴミ箱から拾って
ビリビリに破いていたのをセロテープで貼ってくれた人もいました。
（ありがとう！）

そして検証した結果、昨日立てた仮説が正しかった（たぶん）と
確信しました。
まさに、推理ドラマ。サスペンス劇場の世界です。
エンディングロールが見えるようだ・・・・。


あとは、システム会社に言って直してもらうだけですが
あまり詳しいことは言わないで（こちらの推測にすぎないし）
どういう調査結果を出してくるかを
楽しみにしたいと思います（←とっても意地悪！）

ただひとつ言えることは
このシステムはすべてにおいて
連動していない！
ということです。

以前より、ワープロみたいなシステムだな
とてもデータベースとは思えない
と思っていましたが
ほんとーーーに、中がつながっていないみたいです。

この会社が元々製品として持っていたシステムを
Ｓ社の業務に合うようにカスタマイズしてもらってきたわけですが
たぶん、カスタマイズするだけのスキルがないのでしょう。
全体の仕組みを理解している人がいないようです。
そうでなければ、こんなにグチャグチャになるわけがない。

営業の人は、Ｓ社側の「こういうことはできますか？」「こういうこともできますか？」という極めて抽象的な要望に対し
「できます」
「可能です」
「対処できます」
「どうとでも変えられます」
と答えていました。

あれが命とりだったねぇ（笑）

システム会社の営業のみなさん
自社の技術に自信があるならいいのですけど
安請け合いしたら大変なことになりますよ。

Ｃ社にとっての戒めにもしよう・・・。

今日もまた、２時間推理ドラマのような１日でした。

以前の記事をお読みいただいている方なら
何のことだかピンときていると思います。

はい、Ｓ社が導入（しようと）している
新システムの不具合がまた発覚しました。

ある現象が起こって、
なぜそうなるの？　と考え
過去のデータを振り返って原因を追究する。
そして、仮説を立て、それを検証してみる。
すると、その仮説しかありえないほど条件がピタリとはまる。

間違いない！（こいつが犯人だ！）
・・・ちょっと古いですかね

これだけじゃ、説明不足ですね。
また、ちゃんと検証していないので
明日確かめてみてまたご報告しましょう。
在庫管理の不具合です。
在庫管理ってそんなに難しい概念なんでしょうか？

でも、ほんっとにバッカみたいな不具合なんです。
自分がつくったシステムがこんなだったら
恥ずかしくてその場で切腹したくなるくらい。

こんなに不具合が見つかって
しかもそれを見つけるのが私達で（依頼者側で）
その原因までつきとめて、検証して。
なんでこんなことまでやらなければならないんでしょうね？

ソフトウェアテストの分の請求をしてやろうかしら、とブチブチ文句を言う毎日です。

休みの間に見つけたツールを使って
Ｓ社業務の「見える化」をやってみよう
と思っていましたが、
こまごまとした業務が立て続けにおこり
結局思うようにはできませんでした。

明日こそ！ですね。

今日、時間をとられたのは、
「判断に迷うケース」
でした。

ルールが決まっているようで決まっていない。
何が最善の策か？
を一応考えるのですが
それが本当にいい方法なのか？の決め手がありません。

何よりも、私と派遣の同僚の２人で話し合っていても
Ｓ社が考える最善の方法
かどうかは、判断がつかないのです。

やはり、判断のできる社員が１人でいいから
社内に常駐していてほしいところです。

業務の「見える化」を早急にやらなければならないところですが
ちゃんと仕組みが作られていないことを
「見える化」して、どうなるんだろうか？とも思います。

「見える化」で現れた現状を、改善しないといけない、
とＳ社の人たちが実感してくれなければ前には進みません。
どうやってそれを感じてくれるか？
どうやって私たちが感じている危機感を伝えるか？

難しいところですね。

以前よりの課題でありました
Ｓ社の業務フローの作成について。

これは、属人化している仕事のひとつひとつを明確にして
たとえどんな人にも（新入社員にも、ＰＣの苦手な人でも）
引き継げるような状態にしておきたい
という目的のためです。

でも、ＳＥ向け業務分析の本を読んでも
いまいち難しくてよくわかりません。
というか、ああいうのは大企業向けなので
零細企業に応用するにはそれなりに読み込んで
自分で考える時間が欲しいのです。

最近年齢のせいか（いや、甲状腺機能低下症のせい、だわ^^:）
本を読んでもなかなか内容が頭に入ってきません。
いやですねぇ（笑）

ＳＥとかそういう人ではなくても
実際に業務をやっている人が
自分のしていることを
簡単に、他の人が見てもわかりやすく
表せる方法がないかな〜と思っていました。


いいツールを見つけてしまいましたよ（笑）
とってもアナログな方法ですけど
シンプルでとってもわかりやすいです。

早速週明けにでも、職場で試してみます。
うまくいったら、報告しますね。

まだ本格稼動していませんが
徐々に新システムに移行したときのための準備をしています。

中身にちょっと（いや、だいぶ）不安の残るこのシステムですが
当面は使わなくてはなりません。

現在は、私がつくったAccessのシステムで業務が回っていますので
同時にデータを入力し、同じ結果が出るかどうか？をテストしています。
Accessに入力しなくなっても今までどおりの帳票が出るように
今のうちにしておかなくてはなりません。

受注業務に関しては、かなり新システムに移行できます。
問題は経理との連携です。（私は経理だ^^;）

今までは、経理は自分がやっていることでもあり
Accessのデータを自分で引き出して加工することもできたので
自動化に関してはかなり遅れてしまいました。

自分がやるからどうとでもなる

そう考えてしまうと、どんどん後回しになってしまいます。
いけませんね。

経理に関しては、ベースになる知識はどこの会社でも同じなので
なるべくシンプルな形でシステム化しておきたいですね。
経理をやる人ならシステムに詳しくなくてもすぐにピンとくるような
そんなものを残しておきたいと思います。

もう、他人に引き継ぐことを考えております（笑）

実際に引き継ぐことはなくても（それじゃ困りますが）
いつ引き継いでもいいように
誰が引き継いでもすぐにわかるように
仕組みをつくっておくことが大事だと痛感しております。

今、フジテレビのヘキサゴンを見ています。
クイズ番組ですけど、結構トンチンカンな答えがでてきて
笑えます。
真面目に答えている風なのが面白いです。（本当に、ヤラセじゃないのかな？）

さっき出た問題に思わず注目してしまいました。

Ｑ．「ＳＥ」は何の略でしょう？
Ａ．システムエンジニア

なんですけど〜。

「スペシャルエンターテイメント！」
と自信を持って答えている人がいましたね〜。

社内ＳＥ＝社内スペシャルエンターテイメント
という定義も案外いいかも。

Ｓ社では特にそういうものが求められているのですが
「このシステムを使うとワクワクして楽しいから使いたくなる」
そんな、楽しいシステムを設計できる人が
Ｓ社にとっては
社内ＳＥ
になるのかもしれません。

いろいろあった新システムですが
とりあえず形にはなったみたいです。

今までの経緯を考えると、私はとーっても不安ですけど
いまさら白紙にはできませんしね。

意外と本稼動したら、スムースになるってこと
・・・・ないよなぁ、このシステムに限って。

間違いを指摘されても、目に見える「数字」だけを
直してすませるようなとこだもんなぁ。
データベースじゃなくて、ワープロなんだもん。

先日、この本を買いました



まだ全然読んでいないのですが
最初の「本書の効能」欄だけ読んで、この言葉に大きくうなづいてしまいました。

「話がかみ合わないためユーザーが不信感を持つ」

こちらが要求していることが全然伝わらない。
こちらの説明も悪いのかもしれないけれど、
間違いを指摘されて
「認識の相違でした」
で済ませるその神経がわからない。

まさに「話がかみ合わない」状態でした。

そんなんでつくったシステムですよ。
信用できるわけないじゃないですか。
まさに
「ユーザーとＳＥの間に信頼関係がなければ、プロジェクト自体がうまくいくかどうかわかりませんし、ＳＥに自信がなければ、潜在的ユーザーニーズを充足させることはできません。」
いいこと書いてあるな、この本。


まぁ、いいです。
どちらにしても、区切りはつけなければなりませんしね。

さあ、私は（Ｃ社は）次のステージに行きますよ！

また、やらかしてくれました。例のシステム会社。
今日は、ものすごーく静かぁに怒っています。
（結局、怒っているのね^^;）

Ｓ社では、決まった取引先からの受注をWebから受け取るようにシステムを構築中です。
ある意味、会員制サイトを作っているといってもいいでしょう。
１社１社にログインしてもらって、マイページを表示してもらいます。
そこには、取引履歴も載る予定です。

今日は、その取引履歴に間違いが見つかりました。
取引金額について、いくつか種類があると思ってください。
　Ａ商品群の受注金額合計
　Ｂ商品群の受注金額合計（Ａ商品群も含む）
など
（本当はもっと複雑なんですか、説明がややこしいので単純にしました）

本当は、Ａ商品群の受注金額合計を表示するはずなんですが、
Ｂ商品群の受注金額合計が載っていたのです。

それだけなら、単に表示する箇所を間違えたのね、で済むはずなのですが・・・。

Ｓ社では、Ｂ商品群の合計金額は算出していませんでした。
必要なかったからです。
でも、新システムではデフォルトの仕様として、Ｂ商品群の合計金額も算出するようになっていました。
本当は、Ｓ社にとっては必要ない機能ですので、こういう間違いの元になるから削除してほしいのですが、将来的に使うかもしれないとの理由でそれは残しておくことになりました。

問題なのは、Ｂ商品群合計金額欄に入っている過去データです。

年月	Ａ	Ｂ
2007/10	３０	１２０
2007/09	２５	１５０
2007/08	３８	２００
2007/07	２２	２２
2007/06	３０	３０

実に簡単な例にしてみますが、こういうデータがあると
思ってください。
Ｓ社がシステム会社に渡したのは「Ａ」の列のデータだけです。
さらに、この計算が新システムでうまくいくかどうかをテストするために、2007/08から、計算の元となる売上データを渡しています。
2007/08からＢの値が桁違いになるのは、きちんと計算された結果だからです。
では、2007/07と2007/06の「Ｂ」の欄の数字は何なのでしょうか？
ご覧のとおり、「Ａ」のデータをそのまま「Ｂ」にも入れているのです。

普通だったら2007/07以前は「Ｂ」のデータが無いのですから、
そこは空欄になっていなければならないはずです。
空欄というのがデータ形式として受け付けられないなら、
2007/07以前のデータは履歴からはずすべきです。
もしくは、2007/07以前もシステムで計算して、正しい値を
「Ｂ」欄に入れるべきなのです。

いくら過去データで、これから使うことはないとはいえ、
まったく違うデータを適当に入力して平気でいるその神経！

それに対して、私は怒っているわけですね。

データには意味があります。
適当に扱っていいわけないんです。

そのデータのもつ意味は、その会社の業務を知っている人間でないと
本当にはわからないのかもしれませんが、
だったら業務を知ってからシステムをつくるべきでしょう。
業務を知ろうともしないで、よその会社のシステムをつくろうとしてはいけません。

だから、中途半端なものしかできないのよね〜。

私は、「データ入力」から派遣の仕事に入りました。
だから、データに関しては譲れないんです。
１箇所ずれただけでも全然違う結果がでてしまうんです。
だから、細心の注意を払う必要があるんです。

ただのパソコンオペレーターだってそれくらいわかるのに
なんでシステム会社の（自称）ＳＥに、それがわからないのかな？

・・・・ああ、やっぱり今日も愚痴になってしまいました。
失礼しました〜

相変わらずの報告ですみません。

先日の不具合について、システム会社の人が「その理由」についての言い訳説明をしにきました。

先日の不具合というのは、こちらです。↓
　　　有ひものデータベース


うちの取引先企業には「ランク」があり、その「ランク」によって「割引率」が決まっています。
その「割引率」によって、注文を受けたときの請求金額が決まるのです。

先日、「ランク」の表示は合っているのに、「割引率」が０になっていて、定価で計算されている取引先が２社ありました。
同じ「ランク」のほかの取引先は、正しい「割引率」になっています。

なぜか？

「ランク」と「割引率」を設定したマスターファイルはあります。

でも、なぜか顧客マスターに「割引率」の項目を設定してあったのです。
こちらから渡した顧客マスターには「ランク」のデータしかありません。
顧客マスターとランクのマスターとを渡してあれば、当然割引率を引っ張り出してくる設定をすると思ったからです。

それを、このシステム会社はわざわざ「コンバート」して、顧客マスターに「割引率」をそれぞれ入力したのです。
その際に、データの不具合で上記の２社だけ「割引率」が０で入ってしまった、と言い訳説明していました。
うちが渡したデータに不備があったということを言いたいようです。
そんなコンバートをしてくれと頼んだ覚えはないのですが・・・。

それにしてもなぜ、そんなデータの重複とも思えるような設定をしたのか？

Ｓ社では、「ランク」によってすべて「割引率」は決まります。
例外はありません。
でも、他のクライアントさんでは、「この顧客だけは、例外で○○％」ということがあるそうです。だから、こういう仕様をとっているのだそうです。

それならば、まぁいいでしょう。そういうやり方もあるでしょうから。
Ｓ社も今は例外はありえませんが、この先方針が変わることもあるかもしれませんし。

だから、今から「ランクマスターから割引率をひっぱってきて計算する」仕様に変えてもらうよりは、今のままでいくほうがいいのかもしれません。
（実際、変えるほうが大変だ、と言われてしまったし）

でも、このやり方でいくなら、確認しておかなければならないことがあります。

まず、その顧客マスターに設定してある「割引率」を見えるようにしなければなりません。
今は「ランク」だけが表示してあります。個々に設定してあるはずの「割引率」はどこにも表示されていないのです。

もし、Ｓ社がこの割引率を個別に設定することになったとき、
どうやって変更をかけるんでしょうね？データが隠れて見えないのに。
いちいち、システム会社に「変更してください」と言ってこいってことなのでしょうか？

次に、「ランク」が変更になったとき。
新しい「ランク」の「割引率」が顧客マスターの「割引率」の欄に反映されなければなりません。
→これは、ちゃんとそうなるそうです。

これが肝心です。
「ランク」の「割引率」の設定が変わったとき。
Ｓ社は、「（この場合があるので）変更できるようにしておいてほしい」と要望を出していました。
ですので、「ランクマスター」で、割引率を変更できるように、また新たなランクの設定もできるように、しておいてもらったのです。

ランク１の割引率が20％から25％に変更になった場合。
「ランクマスター」でパーセンテージの数字を変えたら、顧客マスターの該当するランクの人の「割引率」欄は自動的に変更されるのか？

→これに対する答えがこれでした。
　「そうするように、仕様を追加することはできます」

システムにあまり詳しくないＳ社の役員は
「そうしてもらいたいわ」
と、軽く流していましたが、私の目は吊り上りました（笑）

そんな機能がなかったら、このシステムは使えないだろうが！
最初っから、つくっとけ！！

データベースになっていないだろうが！


・・・・ああ、今日もまた激怒してしまいました。

先日、病院で検査し、「甲状腺機能低下症」の診断を受けました。
この病気は、全身の機能が低下するので「元気がなくなる」と先生がおっしゃっていたのですが、
職場でそれを言っても、誰も信じてくれません。（なぜ？）

「甲状腺機能低下症」の病人に、ここまでアドレナリンを放出させるこのシステム会社、恐るべし！！

・・・まぁ、ネタにコトかかないので、ありがたいですけどね（笑）

もし、もう１度最初からＳ社のシステムを作り直すとしたら・・・？

そんなことを考えてみました。

とりあえず外注には出さず、自分で作ることを想定してみます。

今度こそ、最初に設計図をつくらないと。
専門的な設計図はつくれませんが、
それよりも大切なことがあります。

「業務分析」
と言ったほうがいいのでしょうか。

データの流れなどは図にしてつくってみたことがあります。
でも、その前にやらなければならなかったことがあります。

一言でいえば
「何が必要なのか？」
です。

誰がやるとか、何人でやるとか、どんな能力を持った人がやるとか
関係なしに、業務の洗い出しをしなければなりません。
そもそもＳ社は人数が少ないので、１人がやっている業務が多岐に渡っています。自分でもどんなことをやっているのか、すべてを把握していないかもしれません。
それを全て明確にする必要があります。
そして、無駄な業務は捨てなければなりません。

その上で、システムを作っていかなければなりません。

今現在システムが複雑になり、また複雑なるがゆえになかなか完成しないのは、元々の業務が「煩雑」だからなのです。

煩雑な業務を洗い出して、整理して、無駄を切り落として、
スッキリとした形にする。

これが必要だったんですね。

これはＳ社の人がやらないとならないことです。
私はそれを目に見える形につくることしかできません。
洗い出した業務のどれを捨てて、どれを生かして、どれとどれを組み直すか？
は、その会社の人が決めることです。

でも、Ｓ社の場合まず捨てることができないんです。
物でもそうなのですが、
いつか使うかもしれない
まだ使える
という理由でとりあえず取って置く。

業務に関しても、無駄だとわかっていても万が一のためにやっておく、とか。
例えば、ＰＣに入力していることでも、平行して手書きも残しておきます。万が一ＰＣがクラッシュしたら困るから。
バックアップシステムを整備してだいぶそのリスクは軽減しているのですが、どうにも不安らしいです。
だから２重になっています。

私からすれば無駄なのですが、Ｓ社の人が必要だというのですから無くすことはできません。

結局整理できなくて煩雑なままの業務をそのままシステムにしようとしたので、今もシステム構築に苦労しているわけです。

これを改善するにはどうしたらいいんでしょうねぇ。
これがクリアできないと次に進めないかも。

でも、その問題はちょっと置いといて
次を考えるとしたら。

次に必要なのは

１人でも
誰がやっても（今日入った新人がやっても）
間違いようのないような仕組み

を考えることです。

Ｓ社は特に人数が少ないので、複数人数で分担してやる作業というのは極力避けなければなりません。
ダブルチェックといって、２人の人間の目で見直すというのも重要視されていますが、そもそも間違いようがない、間違った内容を入力しようとしたらエラーが出るような、自動的にチェックするシステムがあればいいのです。


あとは、データベースのお得意とするところ。
１度入力したデータを使いまわして結果を出す。
リレーショナルを駆使して。
つまり、人間の手になるところを極力少なくするということです。

自動的ということでいえば、マクロ機能とかタイマーも使いたいところです。
人がいなくても自動的に回っていくのが理想。

そこまで考えるのは、最終的に作り始める段階かな？

私が考える、零細企業向けシステム構築のやり方
これって難しいことなんでしょうかねぇ

まずは「業務分析」ができるようにしないといけませんね。