ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

帳票や記入用紙は、記入したものをもらってきたほうが安全

2005-08-31 17:29:13 | 開発ネタ

 帳票の分析を行ってER図を書くことがあります。
 その話題で、2つ
 1つめ。そのとき、帳票は、記入したものをもらってきたほうが安全だと思います。(2つめは、覚えていたら、いつか。。)

 理由を、はぶさんの記事を使って説明しますね。

 この記事の内容と、エンティティの導出方法自体は、問題ないです。
 これに、いちゃもん、文句をつけようなんてーことは、思ってもいません。
 はい。
 よい記事だと思いますですよ。

 情報処理試験なんかでやるやり方でも、このケースでは、結果は、同じものが出てきます。
(実は、上記の記事のように、イベントからそのリソースを割り出す方法と、帳票分析するだけのものでは、違うものが出てくることがあります。そのケースと理由については、2つめの話。実は、このケースかと思って、前のブログでは、勘違いした)

 で、今回の話は、この用紙を使って説明するというだけで、記事の内容うんぬんの話ではないです。はい(つまり、記事とは、ぜんぜん違う話。用紙だけ使わせてもらっているということ)




 で、その用紙についてなのですが、よーく考えると、ですよ、

 「お持ち帰りご注文用紙」

に、自分の電話番号って、書きます??

 具体的に考えて見ましょう。。

 お弁当屋さんで、お持ち帰りするとき。。。(ある会社で、つかいっぱの巻)

 (1)お昼、「お持ち帰りご注文用紙」をつかって、みんなの注文をとってくる
 (2)その用紙をお弁当屋さんに行ってわたす
 (3)お弁当屋さんは、その用紙を見て、お弁当を作る
 (4)で、ここでふつう、「何とか弁当の方」っていわれない??
    →名前も必要ないし、電話番号もいらない

 電話予約した人の場合、名前のほかに、電話番号があったほうが安全。
 ところが、これは、電話予約の用紙も兼ねているとすると、またまたちょっとへん。一番下に「指定の時間までに、おつくりしておきます」
 とあるけど、指定の日にち、時間を書く欄がない。。。
 まあ、そもそも、電話予約にこの用紙をつかってるかどうかわかんないけど。。




 で、実務上、こういうことがよくあって、上記の場合、たぶん、

・おなまえ、電話番号を書かないでもってくるケースもある
・電話予約も、この用紙を使っている場合、指定の日時は、空白に書いている

だと思います。

 上の書かないケースはまだしも、空白は、気づかないのよね。。欄がないから。
 ウィリアムのいたずらが引っかかったケースは、
 チェック欄があって、そこをチェックするようになっていて、「その他」がない。
 なんで、きっと、その項目から選ぶとおもって、コードにしてしまおうとして。。。翌週、記入された用紙を見てびっくり!そのチェック欄おかまいなしに、横に線を引いて、勝手に記入してるのよ。。。

 学校でセンセイに教わっただろう!
 欄外に書いたら、さいてんされないんだぞお!

 なんてはいえないし。。。




 てなこともあるので、用紙は、記入されたものでみたほうが安全。

 プログラムのアプリケーションの都合や、現場の都合(用紙の流用)とかで、記入しない不要な項目があったり、逆に、まったくない項目を勝手に作って書いたりしてるから。。

 でも、最近は、機密保護の関係で、
 くれないんだよねー、記入済み用紙って(>_<!)
 そいとか、線でいっぱい消されたのが、きたり(でも、線で消されてても、未記入よりまし。記入していなければ、そこは線で消されてないし。。)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

結局、マネージャーのお仕事の範囲は、下次第ということですかね。

2005-08-31 13:34:46 | 開発ネタ

 昨日の、マネージャーは、下の人間がやっていることを理解できる必要があるか否かに、いろいろ、コメント、トラックバックいただき、ありがとうございます。
 マネージャーは、管理だけでいいというのが、大方の意見のようにも見受けられますが、実際は、kudryavkaさんのように、それだけでは、すまないって言うのが、実情といえそうですね。

 たしかに、下請けに出す場合などは、まったく管理者がわからなくても、丸投げできるわけだし、逆に、会社の都合(作戦、計略??)で、下の人が、なーんにもわかんない場合には、マネージャーが、たぶん指導するだけでは、ぜんぜんすまないだろうし。。。

 ということで、やっぱり、マネージャーのお仕事の範囲は、下次第ということになるのでしょうね。




 でも、そうすると、状況は悪くなる一方なのかもしれません。
 というのは、現在出回っている仕様書の書き方から規定される仕事の手順内容などと、世間の本等で書かれている、いわれている手順などとは、違いがあり、その差を説明する人もいなければ、勉強する機会もない。
 ので、下の人は、自分の作業が、コンピューターサイエンスやソフトウエア工学のどこと結びついているかわからない。興味が沸かないというより、わけわなんないでこなすという状態だと思います。

 さらに、ずーっと下の人を下のままにさせておくというのは、人道上できない(初任給のまま、10年も20年も勤めさせるというのは、相手がフリーSEならさておき、社員だとできない。会社全体の士気が下がるし)ので、上に上げないといけない。そうすると、経験がある下の人が少なくなる。

 さらにさらに、下の人が上に上がった場合、フレームワークが最近頻繁に変わるので、管理ポイントが変化しているんだけど、それについていけない。
 たとえば、COBOLの場合とStrutsを使った場合では、モジュール割りから、管理方法まで、かなり変わってくる(まあ、今度覚えてたら、どこがどう違うなんてことはかきます)

 なんてかんじで、下の人に期待はできないし、自分の経験も当てにできない。。。マネージャーの仕事は難しくなるばかりかも。。。




はじめに書いていた、どうでもいいおまけについて:
(訂正:はじめに書いていた、例、まちがい。クリックすると、下のほうに、顧客エンティティのデータがあった。みえんかった。ふつうないんだけどね (^^;))

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

31日の「コピーされるほど儲かるシステム!開発日記」第22号

2005-08-31 11:02:11 | コピーされるほど儲かるシステム!

 8月31日、「コピーされるほど儲かるシステム!開発日記」第22号を出しました。
 内容は、

コピーされるほど儲かるシステムと同じ考え方の、インディーズのプロモーションサイト


YAHOOミュージックのサウンドステーションは、無料で曲がきけるらしい
の書き直しです。

 次号について、Windowsのデジタル著作権管理 (DRM)のSDKについてにしようかな、とおもったら、う、大部分が英語だ。。チュートリアルビデオも、英語だ。こまった。。。

 なので、次号の予定は、わかりません。

 ちなみに、まえの英語の話
わけあって、英語について思い出させられ(この理由は、数日後、このブログ内に書くと思います)
の理由は、上記のDRMの説明が英語だということにつながります。

ということで、あとは決り文句。




 22号のメルマガについての、感想などはここの「コメント」にどうぞ!

 メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム!開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参称してください



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする