初めて書き込みさせて頂きます。
仕事としてFileMaker DB開発をしています。
今回受けている仕事は、クライアントがシステム設計したものをFileMaker Pro Advancedで組み立てるという一見やりやすそうな仕事でした。しかし、そこには落とし穴がありました。システム設計したという設計図は何を基準に組み立てられているのか、全体的にピントがぼけたものでした。こちらから矛盾点を指摘しても聞き入れてもらえない状態です。
そこで質問です。
「ファイルベース」と「データベース」の違いというのはどのように説明すればわかりやすいでしょうか。
データの流れをフローチャートにしても理解して頂けませんでした。
「データを情報のカテゴリ別に分ける」この時点で理解していただけません。システム設計図・レイアウト共に情報盛りだくさんで、「目的」を失っています。
「カテゴリ別に分ける」という事をいろいろなたとえ話も織り交ぜながら先方に説明しましたが、まず、データが見えない状態でも格納されているということも理解されていないようです。
いい説明方法があったら是非教えて頂けませんでしょうか。
よろしくお願いします。
仕事としてFileMaker DB開発をしています。
今回受けている仕事は、クライアントがシステム設計したものをFileMaker Pro Advancedで組み立てるという一見やりやすそうな仕事でした。しかし、そこには落とし穴がありました。システム設計したという設計図は何を基準に組み立てられているのか、全体的にピントがぼけたものでした。こちらから矛盾点を指摘しても聞き入れてもらえない状態です。
そこで質問です。
「ファイルベース」と「データベース」の違いというのはどのように説明すればわかりやすいでしょうか。
データの流れをフローチャートにしても理解して頂けませんでした。
「データを情報のカテゴリ別に分ける」この時点で理解していただけません。システム設計図・レイアウト共に情報盛りだくさんで、「目的」を失っています。
「カテゴリ別に分ける」という事をいろいろなたとえ話も織り交ぜながら先方に説明しましたが、まず、データが見えない状態でも格納されているということも理解されていないようです。
いい説明方法があったら是非教えて頂けませんでしょうか。
よろしくお願いします。
|
|
|
|
コメント(22)
すいませんが、ご質問の内容を見るに設計に入る前の段階のことが気になりました。
その辺を教えていただければと思います。
１．開発者であるYaeGonさんは、クライアントの業務を大体は理解しているか？
２．クライアントでシステム設計を担当している（おそらくはYaeGonさんと直接やり取りをされている）方はそもそも、業務を理解しており業務を把握しているのか？
３．システム化の目的をクライアントとYaeGonさんは共有できているのか？
といったあたりがわかると話も見えてくるように思うのですが。
「システム設計したという設計図は何を基準に組み立てられているのか、全体的にピントがぼけたもの」と書いておられますが、そのピントのぼけ方がはっきりわからないのです。
お互いに業務が見えていればデータの流れは相互に理解することができると思います。
上記条件が揃っていてデータフローは共有できているが、クライアントさんが単純にDBに疎くその先の設計が進まないということなのでしょうか？
あるいはクライアントがシステムの詳細に踏み込みすぎていて混乱しているのでしょうか？
その辺を教えていただければと思います。
１．開発者であるYaeGonさんは、クライアントの業務を大体は理解しているか？
２．クライアントでシステム設計を担当している（おそらくはYaeGonさんと直接やり取りをされている）方はそもそも、業務を理解しており業務を把握しているのか？
３．システム化の目的をクライアントとYaeGonさんは共有できているのか？
といったあたりがわかると話も見えてくるように思うのですが。
「システム設計したという設計図は何を基準に組み立てられているのか、全体的にピントがぼけたもの」と書いておられますが、そのピントのぼけ方がはっきりわからないのです。
お互いに業務が見えていればデータの流れは相互に理解することができると思います。
上記条件が揃っていてデータフローは共有できているが、クライアントさんが単純にDBに疎くその先の設計が進まないということなのでしょうか？
あるいはクライアントがシステムの詳細に踏み込みすぎていて混乱しているのでしょうか？
たなｂさん、ありがとうございます。
>クライアントがシステムの詳細に踏み込みすぎていて混乱しているのでしょうか？
クライアントが「データの流れ」を理解できず、情報を盛り込みすぎて混乱していると思います。
業務は今まで「紙ベース」です。
業務の内容は見えていますが、設計図の段階でスマートにはなっていません。私たちが１から設計した場合はなるべくスリムに設計していますが、それができていない状態です。
例え話ですが、見積書の中に納品書もあり、請求書も混在している上に、過去のそれらの伝票も混ざっているかのような状態です。
すみません、直接の業務でたとえることができなくて、うまく説明ができませんが、あれもこれもゴチャゴチャで「カテゴリーで分ける」「データの性質で分ける」これらの提案を却下されてしまっている状態です。
データにはそれぞれカテゴリーが存在する・目的が存在する、それらをどんなに説明しても分かってもらえなくて困っています。
申し訳ありあせん、的確な説明方法を教えていただけませんでしょうか。
>クライアントがシステムの詳細に踏み込みすぎていて混乱しているのでしょうか？
クライアントが「データの流れ」を理解できず、情報を盛り込みすぎて混乱していると思います。
業務は今まで「紙ベース」です。
業務の内容は見えていますが、設計図の段階でスマートにはなっていません。私たちが１から設計した場合はなるべくスリムに設計していますが、それができていない状態です。
例え話ですが、見積書の中に納品書もあり、請求書も混在している上に、過去のそれらの伝票も混ざっているかのような状態です。
すみません、直接の業務でたとえることができなくて、うまく説明ができませんが、あれもこれもゴチャゴチャで「カテゴリーで分ける」「データの性質で分ける」これらの提案を却下されてしまっている状態です。
データにはそれぞれカテゴリーが存在する・目的が存在する、それらをどんなに説明しても分かってもらえなくて困っています。
申し訳ありあせん、的確な説明方法を教えていただけませんでしょうか。
>「レイアウト主義」
というコメントまで読ませていただきました。
レイアウト主義というのは利用者であれば当たり前のことなんですが、文章から察するに、クライアントとユーザが別々でしかも、どうもクライアントがユーザ寄りでキチンとシステムとユーザ間の折衝をしていないようにも思えてきました。それどころかDBをあまり知らないまま設計しているみたいな。
ここに来て、要するにもしかして納期とか開発費という現実的な問題があるような気がしてきたのですが、思い過ごしであることを祈ります。DB再設計をするには工数が必要→開発費がかさむということですよね。そこを理解いただくことに苦慮されているのでしょうか？
曲りなりにもユーザと開発者の間を取り持つ仕事をする人間がデータベース設計の基本を理解できないことは考えにくいのです。
というコメントまで読ませていただきました。
レイアウト主義というのは利用者であれば当たり前のことなんですが、文章から察するに、クライアントとユーザが別々でしかも、どうもクライアントがユーザ寄りでキチンとシステムとユーザ間の折衝をしていないようにも思えてきました。それどころかDBをあまり知らないまま設計しているみたいな。
ここに来て、要するにもしかして納期とか開発費という現実的な問題があるような気がしてきたのですが、思い過ごしであることを祈ります。DB再設計をするには工数が必要→開発費がかさむということですよね。そこを理解いただくことに苦慮されているのでしょうか？
曲りなりにもユーザと開発者の間を取り持つ仕事をする人間がデータベース設計の基本を理解できないことは考えにくいのです。
たくさん書き込みありがとうございます。
たなｂさん、玉茶Fb@('A`･∵.さん、たかさん、おっしゃる通りです。
たなｂさんの
>曲りなりにもユーザと開発者の間を取り持つ仕事をする人間がデータベース設計の基本を理解できないことは考えにくいのです。
私も認めたくなかった事実ですが、これが根本の原因です。
納期・開発費の件もそのものずばりです。データの流れができていないことによって生じることが予想できる箇所の「バグつぶし」で２週間ほど費やしてしまい、その間の「成果物」ができてこないことに対する説明。いくら説明しても理解されていないという事実。これは、先方が「データベース設計の基本を理解できない」という一言だったんですね。「理解しない」のではなく「理解できない」考えたくないことです…。
たかさんのおっしゃるような説明は３ヶ月ほど続けてきましたが、もう一度、噛み砕いて説明しようと思います。
再度、今日がんばってみます。
いろいろありがとうございました。
またご報告させていただきます。
たなｂさん、玉茶Fb@('A`･∵.さん、たかさん、おっしゃる通りです。
たなｂさんの
>曲りなりにもユーザと開発者の間を取り持つ仕事をする人間がデータベース設計の基本を理解できないことは考えにくいのです。
私も認めたくなかった事実ですが、これが根本の原因です。
納期・開発費の件もそのものずばりです。データの流れができていないことによって生じることが予想できる箇所の「バグつぶし」で２週間ほど費やしてしまい、その間の「成果物」ができてこないことに対する説明。いくら説明しても理解されていないという事実。これは、先方が「データベース設計の基本を理解できない」という一言だったんですね。「理解しない」のではなく「理解できない」考えたくないことです…。
たかさんのおっしゃるような説明は３ヶ月ほど続けてきましたが、もう一度、噛み砕いて説明しようと思います。
再度、今日がんばってみます。
いろいろありがとうございました。
またご報告させていただきます。
皆様ありがとうございます。
今日のご報告をさせて頂きます。
システム設計図のファイルの流れがおかしいことをクライアントに説明しました。
たかさんのおっしゃる通り、データを分解しての説明もしてみました。でも、結局はたなｂさんのおっしゃる通り、「理解しない」のではなく「理解できない」ようです。
データを分解しての説明も、「それを知ってどうするの？」って状態です。
クライアント側は「FileMakerだからできない」と思っているようです。FileMakerの問題ではなく、データベースとしての設計の問題で、どのプログラムで作っても同じ結果だと説明しました。
逆にFileMakerだからできてしまった部分もあって、それがいけなかったのかと反省しています。
yamamotoさんのおっしゃる「No」といえる時期「あきらめさせる」時期を過ぎてしまっていて、たなｂが心配してくださった納期のみが迫っている状態です。
現状では、データの根本の流れが間違っている、脆弱なプログラムである、それだけ伝えるのみが精一杯でした。クライアントが理解する・できない・しない...それは別の問題と思うことにしました。
FileMakerはもっと可能性のあるソフトだと思っています。今までも「不可能を可能に」することが楽しくて仕事をしてきました。破綻が見えている今回の仕事は残念で悔しくてたまりません。
また、後日先方とデータの流れに関しての説明をしなければいけないので、もし、なにか先方に伝えるいい方法をご存じでしたら教えて頂けませんでしょうか。
たちきさんもご意見ありがとうございました。
今日のご報告をさせて頂きます。
システム設計図のファイルの流れがおかしいことをクライアントに説明しました。
たかさんのおっしゃる通り、データを分解しての説明もしてみました。でも、結局はたなｂさんのおっしゃる通り、「理解しない」のではなく「理解できない」ようです。
データを分解しての説明も、「それを知ってどうするの？」って状態です。
クライアント側は「FileMakerだからできない」と思っているようです。FileMakerの問題ではなく、データベースとしての設計の問題で、どのプログラムで作っても同じ結果だと説明しました。
逆にFileMakerだからできてしまった部分もあって、それがいけなかったのかと反省しています。
yamamotoさんのおっしゃる「No」といえる時期「あきらめさせる」時期を過ぎてしまっていて、たなｂが心配してくださった納期のみが迫っている状態です。
現状では、データの根本の流れが間違っている、脆弱なプログラムである、それだけ伝えるのみが精一杯でした。クライアントが理解する・できない・しない...それは別の問題と思うことにしました。
FileMakerはもっと可能性のあるソフトだと思っています。今までも「不可能を可能に」することが楽しくて仕事をしてきました。破綻が見えている今回の仕事は残念で悔しくてたまりません。
また、後日先方とデータの流れに関しての説明をしなければいけないので、もし、なにか先方に伝えるいい方法をご存じでしたら教えて頂けませんでしょうか。
たちきさんもご意見ありがとうございました。
＜蛇足＞
プログラマーはどうしても「ソフト用語」で説明をしてしまいますが
これは「最も避けるべきこと」と思います。
プログラマーが「開発したシステムを実務の用語で説明出来る時」
これが要求仕様を満たした事であり、プログラムとしても第一ステップに
入ったと御考え下さい。
＜蛇足の蛇足＞
第二ステップ ： 開発したプログラムから実務の矛盾や非効率差を
（プログラマーでは無く）実務に携わる人が発見
できるものに仕上げる
第三ステップ ： 実務を効率や合理性から改善出来るフローやルール
を実務者とプログラマーが協力して創造する
まずは第一ステップがスムーズに受け入れられる事が重要と思います。
プログラマーはどうしても「ソフト用語」で説明をしてしまいますが
これは「最も避けるべきこと」と思います。
プログラマーが「開発したシステムを実務の用語で説明出来る時」
これが要求仕様を満たした事であり、プログラムとしても第一ステップに
入ったと御考え下さい。
＜蛇足の蛇足＞
第二ステップ ： 開発したプログラムから実務の矛盾や非効率差を
（プログラマーでは無く）実務に携わる人が発見
できるものに仕上げる
第三ステップ ： 実務を効率や合理性から改善出来るフローやルール
を実務者とプログラマーが協力して創造する
まずは第一ステップがスムーズに受け入れられる事が重要と思います。
YaeGonさん、かなり切羽詰っておられるようですね。
なんと申し上げて良いやら慰めの言葉もありません。
以下、詳しい事情がわかりませんので多分に想像も入ってしまいますが、もし参考になれば幸いです。参考にならなければ捨て置いてください（笑）
>データを分解しての説明も、「それを知ってどうするの？」って状態です。
曲りなりにも一度は設計した方ということですので、理解できないというのはちょっとアレなんですが、事ここに至っては「要は品質が悪いのね。」みたいな落しどころを考えてる場合もあります。自分の非を見ないようにする人もおられます。この辺、クライアントさんの意図だけは把握しておく必要はあると思います。でないと、ユーザへの説明がチグハグになってしまいます。
私も使われる立場の時は罪を被せられて我慢する局面もありました。
>後日先方とデータの流れに関しての説明をしなければいけないので
ということですが、この打ち合わせは、見積工数が不足していることと遅延の原因を説明し納期延期をお願いする場なのでしょうか？
そうであれば、ユーザの立場に立った専門用語を用いな報告を定量的にする必要がありますね。
YaeGonさんと仲介者であるクライアントさんの意識を合わせて臨みたいところですが、その辺ちょっと心配です。場合によっては上記のように罪を被る覚悟が必要な場合もあります。
かなり厳しい局面と想像してますが、この局面を乗り越えたときYaeGonさんは必ず一回り以上成長されると思います。既に悔しい思いや苦しい思いを多々されているとは思いますが、精神面、実生活面で我慢が可能であればなんとか乗り切って欲しいです。ユーザへの誠意が根本にあれば、なんとかなる場合もありますから。
どうか頑張ってください。
なんと申し上げて良いやら慰めの言葉もありません。
以下、詳しい事情がわかりませんので多分に想像も入ってしまいますが、もし参考になれば幸いです。参考にならなければ捨て置いてください（笑）
>データを分解しての説明も、「それを知ってどうするの？」って状態です。
曲りなりにも一度は設計した方ということですので、理解できないというのはちょっとアレなんですが、事ここに至っては「要は品質が悪いのね。」みたいな落しどころを考えてる場合もあります。自分の非を見ないようにする人もおられます。この辺、クライアントさんの意図だけは把握しておく必要はあると思います。でないと、ユーザへの説明がチグハグになってしまいます。
私も使われる立場の時は罪を被せられて我慢する局面もありました。
>後日先方とデータの流れに関しての説明をしなければいけないので
ということですが、この打ち合わせは、見積工数が不足していることと遅延の原因を説明し納期延期をお願いする場なのでしょうか？
そうであれば、ユーザの立場に立った専門用語を用いな報告を定量的にする必要がありますね。
YaeGonさんと仲介者であるクライアントさんの意識を合わせて臨みたいところですが、その辺ちょっと心配です。場合によっては上記のように罪を被る覚悟が必要な場合もあります。
かなり厳しい局面と想像してますが、この局面を乗り越えたときYaeGonさんは必ず一回り以上成長されると思います。既に悔しい思いや苦しい思いを多々されているとは思いますが、精神面、実生活面で我慢が可能であればなんとか乗り切って欲しいです。ユーザへの誠意が根本にあれば、なんとかなる場合もありますから。
どうか頑張ってください。
YaeGon さん
shintan さん、たなｂ さんが貴重なアドバイスをされておられますが、
一度すっかり忘れて、「ユーザーと言うのは我がままで知識が無く、かつ
気が違っている」と言うところから始められたら如何でしょうか？
誤解されると申し訳ないので別の言い方をしますと、 YaeGon さんの
知織や経験から見ると精々中学生レベルと考える事です。
（しかし YaeGon さんとは違う世界で先輩と考えることと合わせて）
食事かお茶にでも社外に誘って、仕事を離れた趣味などの話題をして
その後、打ち合わせに戻ると言うのも一つの手かも知れません。
相手の方々も、 YaeGon さんも要は目的を一つにしたお仲間であり、
ただ知識や経験の接点が少ないと言うだけと思いますので。
たなｂさんも言われるように・・
＞ユーザへの誠意が根本にあれば、なんとかなる場合もあります
というのは全く同感です。 というより「なんとか」ではなく「必ず」
とも思います。 誠意とは自分が起点では無く相手であるということを
お守りになれば．．．
同じ言葉ですが、頑張って下さい。
ソフト開発とはシステム（しくみとルール）の開発と考えますので
ある意味では、その世界での伝道師か先駆者でも有るかもしれないという
プライドもお忘れなく。 これを支えにすれば多少のことは我慢出来る
というくらいの意味で御理解下さい。
追伸
先のコメントは多少事務的だったかも知れません。
お気に触ったらお許し下さい。
本音はこちらですので．．．
shintan さん、たなｂ さんが貴重なアドバイスをされておられますが、
一度すっかり忘れて、「ユーザーと言うのは我がままで知識が無く、かつ
気が違っている」と言うところから始められたら如何でしょうか？
誤解されると申し訳ないので別の言い方をしますと、 YaeGon さんの
知織や経験から見ると精々中学生レベルと考える事です。
（しかし YaeGon さんとは違う世界で先輩と考えることと合わせて）
食事かお茶にでも社外に誘って、仕事を離れた趣味などの話題をして
その後、打ち合わせに戻ると言うのも一つの手かも知れません。
相手の方々も、 YaeGon さんも要は目的を一つにしたお仲間であり、
ただ知識や経験の接点が少ないと言うだけと思いますので。
たなｂさんも言われるように・・
＞ユーザへの誠意が根本にあれば、なんとかなる場合もあります
というのは全く同感です。 というより「なんとか」ではなく「必ず」
とも思います。 誠意とは自分が起点では無く相手であるということを
お守りになれば．．．
同じ言葉ですが、頑張って下さい。
ソフト開発とはシステム（しくみとルール）の開発と考えますので
ある意味では、その世界での伝道師か先駆者でも有るかもしれないという
プライドもお忘れなく。 これを支えにすれば多少のことは我慢出来る
というくらいの意味で御理解下さい。
追伸
先のコメントは多少事務的だったかも知れません。
お気に触ったらお許し下さい。
本音はこちらですので．．．
YaeGonさん。
はじめまして。
開発よりも開発を管理するほうになることが多い者なのですが、問題解決について、根本から説明の切り口を変えたほうが、あるいは楽かもしれないと思い、思うところを述べさせていただきます。
何人かの方がすでに書いておられるように、「専門用語を使わないほうがよい」というのは、「データベースとはこうである」というところを説明してから、事態を理解していただこうとすると、逆に落とし穴にはまるような気がするからだと思います。
専門用語というよりも、データベースの概念が理解できないため、クライアントさんもおそらく困っているんだと思います。
ややこしいアドバイスかもしれませんが、クライアントさんと中間の方に「できない理由」を説明しても、「理解できない」で終わってしまいますので、逆に「今回の目的」を確認して、そのために必要な手順を説明する、という、おそらくいちばん最初に通常ならば踏むであろう説明を行なうのが、迂遠に見えて、いちばん近道かもしれないと考えます。
絶対にこの方法がいい、とは言えません。クライアントさんの性格などは、私はわかりません。現場にいるわけではありませんので、私がこれ以上の具体的な方法の提案は、かえってYaeGonさんが混乱してしまうと思います。
ので、具体的な方法としては、「普通ならこうデータベースを説明したら理解できるだろう」という「常識」を取っ払って、シンプルに「どうデータベースが動くといいのか」だけに注目して説明されたほうが、よいかと思います。
データの最終段階で新規データをいきなり作る、というのを読んで、ふと業務フローがどうなっているんだろうと思ったので、書き込んでしまいました。
業務フロー的には最終段階での新規レコード作成は、十分に「データベースでなくただの業務」として考えれば、ありえることなんですけど、最初の設計段階では説明がされていなかったんだろうなぁ、と想像しております。
私も、データベースをよくわかっていない頃に、業務フローの監査をしたことがあり、理解できるまでに何度も聞きなおして、頭の中をリフレッシュして、ようやく、ということがありましたので、「つまりこれがあればいいんですね？」まで辿りつくのにずいぶん回り道をした覚えがあります。
大変かと思いますが、頑張ってください。
私のアドバイスというより、見当違いの発言の可能性もありますので、もし、状況に合致しているようでしたら、お試しいただくのもひとつの手かと。
それでは、失礼いたします。
はじめまして。
開発よりも開発を管理するほうになることが多い者なのですが、問題解決について、根本から説明の切り口を変えたほうが、あるいは楽かもしれないと思い、思うところを述べさせていただきます。
何人かの方がすでに書いておられるように、「専門用語を使わないほうがよい」というのは、「データベースとはこうである」というところを説明してから、事態を理解していただこうとすると、逆に落とし穴にはまるような気がするからだと思います。
専門用語というよりも、データベースの概念が理解できないため、クライアントさんもおそらく困っているんだと思います。
ややこしいアドバイスかもしれませんが、クライアントさんと中間の方に「できない理由」を説明しても、「理解できない」で終わってしまいますので、逆に「今回の目的」を確認して、そのために必要な手順を説明する、という、おそらくいちばん最初に通常ならば踏むであろう説明を行なうのが、迂遠に見えて、いちばん近道かもしれないと考えます。
絶対にこの方法がいい、とは言えません。クライアントさんの性格などは、私はわかりません。現場にいるわけではありませんので、私がこれ以上の具体的な方法の提案は、かえってYaeGonさんが混乱してしまうと思います。
ので、具体的な方法としては、「普通ならこうデータベースを説明したら理解できるだろう」という「常識」を取っ払って、シンプルに「どうデータベースが動くといいのか」だけに注目して説明されたほうが、よいかと思います。
データの最終段階で新規データをいきなり作る、というのを読んで、ふと業務フローがどうなっているんだろうと思ったので、書き込んでしまいました。
業務フロー的には最終段階での新規レコード作成は、十分に「データベースでなくただの業務」として考えれば、ありえることなんですけど、最初の設計段階では説明がされていなかったんだろうなぁ、と想像しております。
私も、データベースをよくわかっていない頃に、業務フローの監査をしたことがあり、理解できるまでに何度も聞きなおして、頭の中をリフレッシュして、ようやく、ということがありましたので、「つまりこれがあればいいんですね？」まで辿りつくのにずいぶん回り道をした覚えがあります。
大変かと思いますが、頑張ってください。
私のアドバイスというより、見当違いの発言の可能性もありますので、もし、状況に合致しているようでしたら、お試しいただくのもひとつの手かと。
それでは、失礼いたします。
Ｄ介さん、ありがとうございます。
これまで先方に提出した資料には、これはのレイアウトは何を作成し、最終的にはどこに転用・集計したいデータを格納するか…。それも含めて書いていましたが、書き方が悪いのか、その文章をスルーされていました（さら〜っと読み流されていました）。
その箇所だけ、もっとかみ砕いて説明すれば分かって頂ける可能性があるかも…ですね。先方は業務フローは理解しているようですが、システムフローはただ「見た」程度だと思われます。
レコードを作る時点で最終の目的まで見据えてフィールドの準備もしてきましたが、最終の目的のみの確認を、もっともっとわかりやすい言葉で説明しなければいけないのですね。
ありがとうございます。
これまで先方に提出した資料には、これはのレイアウトは何を作成し、最終的にはどこに転用・集計したいデータを格納するか…。それも含めて書いていましたが、書き方が悪いのか、その文章をスルーされていました（さら〜っと読み流されていました）。
その箇所だけ、もっとかみ砕いて説明すれば分かって頂ける可能性があるかも…ですね。先方は業務フローは理解しているようですが、システムフローはただ「見た」程度だと思われます。
レコードを作る時点で最終の目的まで見据えてフィールドの準備もしてきましたが、最終の目的のみの確認を、もっともっとわかりやすい言葉で説明しなければいけないのですね。
ありがとうございます。
YaeGon さん
色々な試しをされる前に、追加をして混乱されるかも知れませんが、
もう一つの考えも（実行されなくても良いので）可能性として頭に置いて
これからの試みをされることをお試し下さい。
Ｄ介 さんが言われておられる事と非常に近いのですが．．．
＜逆説的な考え方＞
１．ユーザーが求めているのは業務の支援ツールあるいは効率化の
ソリューションであって、データベースであるか書類作成＋データ
管理システムであるかには興味が無い。
従ってデータベースの構造やルール、禁止事項には興味が無く
むしろ、自動的にルールを教えてくれ、禁止されている事は警告を
してくれるようなものを求めている。
この為に、データベースの設計は「業務のルールに反する事を
画面で表示して見直しを促す」とともに「深刻な違反は排除する」
機能を組み込む。
これには、アクセスするユーザーの階層と権利を定義して、
これに添ったルールとアクセス権を設定する事は最低でも必要と
思いますし、また（上位者を騙るユーザーもいると考えて）どの
ＰＣから（出来れば誰がアクセスしたかを「新規レコードの作成」
「レコード内容の修正」を記録する機能もあれば良いと思います。
プルダウンメニューを使用出来ないようにして必要な操作は全て
スクリプトの組み込まれたボタンにするという方法が有ります。
２．（ユーザーさんがどういう要求をしているか判りませんが．．）
新しい用語や概念を好まず、今までの用語や概念で使えてその上で
良い仕事を楽にできるものを望んでいる。
従って、マニュアルを作られるでしょうが、これはデータベースの
用語で作らず、今までの業務の用語と概念で作る事が必要かと
思います。
＝＝＝＝＝＝＝＝＝
以上、２点を可能性として御考え下さい。
こういう考え方で作ると、まず抵抗なく使ってくれるとともに、その内
「こういう苦労をして作られたもの」であることを少数の人は気がつき、
むしろ開発者以上にデータベースのルールの教育や開発への取り組みを
してくれる人が生まれて来ます。
その時点では、本当にデータベースとしての本質と特徴を生かした
ものの開発を共同でできるようになると言う経験です。
どうぞお独りで悩まず、お仲間をつくることも工夫なさって下さい。
色々な試しをされる前に、追加をして混乱されるかも知れませんが、
もう一つの考えも（実行されなくても良いので）可能性として頭に置いて
これからの試みをされることをお試し下さい。
Ｄ介 さんが言われておられる事と非常に近いのですが．．．
＜逆説的な考え方＞
１．ユーザーが求めているのは業務の支援ツールあるいは効率化の
ソリューションであって、データベースであるか書類作成＋データ
管理システムであるかには興味が無い。
従ってデータベースの構造やルール、禁止事項には興味が無く
むしろ、自動的にルールを教えてくれ、禁止されている事は警告を
してくれるようなものを求めている。
この為に、データベースの設計は「業務のルールに反する事を
画面で表示して見直しを促す」とともに「深刻な違反は排除する」
機能を組み込む。
これには、アクセスするユーザーの階層と権利を定義して、
これに添ったルールとアクセス権を設定する事は最低でも必要と
思いますし、また（上位者を騙るユーザーもいると考えて）どの
ＰＣから（出来れば誰がアクセスしたかを「新規レコードの作成」
「レコード内容の修正」を記録する機能もあれば良いと思います。
プルダウンメニューを使用出来ないようにして必要な操作は全て
スクリプトの組み込まれたボタンにするという方法が有ります。
２．（ユーザーさんがどういう要求をしているか判りませんが．．）
新しい用語や概念を好まず、今までの用語や概念で使えてその上で
良い仕事を楽にできるものを望んでいる。
従って、マニュアルを作られるでしょうが、これはデータベースの
用語で作らず、今までの業務の用語と概念で作る事が必要かと
思います。
＝＝＝＝＝＝＝＝＝
以上、２点を可能性として御考え下さい。
こういう考え方で作ると、まず抵抗なく使ってくれるとともに、その内
「こういう苦労をして作られたもの」であることを少数の人は気がつき、
むしろ開発者以上にデータベースのルールの教育や開発への取り組みを
してくれる人が生まれて来ます。
その時点では、本当にデータベースとしての本質と特徴を生かした
ものの開発を共同でできるようになると言う経験です。
どうぞお独りで悩まず、お仲間をつくることも工夫なさって下さい。
非常に苦労されている様子で、なんとも。どちらかというと私の立場はユーザーではなくクライアントなので、お力になれそうにありません。ただ、何年か前、業務システムを構築したとき、ユーザーの「不可能な」要望にあきれたことがあります。
例：８時４５分締めの日報を８時３０分に欲しい
１５分未来を予想しろと！
対応策：帳票が未来予測をしなければならないときは、帳票タイトルに「暫定」の文字と作成時間を印字
例：受付前の情報も取り込め！
受付作業をしていない状態で、前の受付のデータなのか、未来の受付のデータなのか自動で区別しろ！
対応策：前後の受付状況などを分析し、未来に受付が強く予想される場合は、裏で受付番号を発券しておき、表示させず受付が実施されたらおもむろに表示。このとき先付けデータもとりこんでおくという仕組みを作成。
例；入力ミスを自動で補正しろ
二重に受け付けた場合を、ミスとミスでない場合を自動判定しろ。とか曜日や正月によって受付方法が微妙にことなる２３の診療科を、診療科ごとに微妙にミスったのを自動で補正をかけて、しかもユーザーに知らせる。とか。
ワープロ入力してしまった誤字病名をただしく正確な病名コードに差し替えろ。とか。
ユーザー（クライアント）は本当に好き勝手を言います。しかし、結果的に欲するデータは入力されていなければ出てきません。ちょっと自動入力機能のあるワープロが欲しいのであれば、割り切って作ってあげればよいのかもしません。ただし、そうしたものは後から、あれが欲しいとかこれが欲しいと言われがちなので、最初に「ここまでしか結果がでない仕組み」であることを相手に示しておく必要があるとおもいます。破綻してまで面倒をみていたら、それこそこちらが破綻しますものね。
例：８時４５分締めの日報を８時３０分に欲しい
１５分未来を予想しろと！
対応策：帳票が未来予測をしなければならないときは、帳票タイトルに「暫定」の文字と作成時間を印字
例：受付前の情報も取り込め！
受付作業をしていない状態で、前の受付のデータなのか、未来の受付のデータなのか自動で区別しろ！
対応策：前後の受付状況などを分析し、未来に受付が強く予想される場合は、裏で受付番号を発券しておき、表示させず受付が実施されたらおもむろに表示。このとき先付けデータもとりこんでおくという仕組みを作成。
例；入力ミスを自動で補正しろ
二重に受け付けた場合を、ミスとミスでない場合を自動判定しろ。とか曜日や正月によって受付方法が微妙にことなる２３の診療科を、診療科ごとに微妙にミスったのを自動で補正をかけて、しかもユーザーに知らせる。とか。
ワープロ入力してしまった誤字病名をただしく正確な病名コードに差し替えろ。とか。
ユーザー（クライアント）は本当に好き勝手を言います。しかし、結果的に欲するデータは入力されていなければ出てきません。ちょっと自動入力機能のあるワープロが欲しいのであれば、割り切って作ってあげればよいのかもしません。ただし、そうしたものは後から、あれが欲しいとかこれが欲しいと言われがちなので、最初に「ここまでしか結果がでない仕組み」であることを相手に示しておく必要があるとおもいます。破綻してまで面倒をみていたら、それこそこちらが破綻しますものね。
スーさん、ありがとうございます。
現行の仕様書自体がクライアントが作成したものなので、この次に（もしあれば）改訂版を作成するときには試させていただきます。
>これには、アクセスするユーザーの階層と権利を定義して、これに添ったルールとアクセス権を設定する事は最低でも必要
これに対して、現在もかなりの範囲で行動を制限させていますが、やはり、ルールをちゃんと設けないと現状では破綻が見えてしまっています。
>「深刻な違反は排除する」
これをしてしまったためにクライアントから「動かないソフト」扱いされてしまいました。
その前提には、アクセス権を設定するということも存在しているので、アクセス権の無いユーザーがアクセス権のない動作をした場合クライアントから指示のあった文章で、ウィンドウを出させていましたが、ウィンドウの内容を全然読んでないのか、意味が分からないと言われてしまいました…。
ご心配いただいて、ありがとうございます。
チームで仕事をしているので、孤立はしていませんが、どちらかと言うと、チームで凹んでます…。
yamamotoさん、ありがとうございます。
病院のシステム、難しそうですね。
私も以前真証性に関してかなり作り込みました。
ただ、私の作った真証性自体は、あったこと、したこと、全部残しておく（どのユーザーがどのページの何を、どう書き換えた。その後、どの帳票を見て、何をどう書き換えたか）などの作業で、予想される事を作り込むことはしませんでしたが…。
予想されることを予想させるのは、予言者のようですね。
>最初に「ここまでしか結果がでない仕組み」であることを相手に示しておく必要があるとおもいます。破綻してまで面倒をみていたら、それこそこちらが破綻します
本当にそうです。「仕様書以外のことはしません」と最初に宣言してあるはずなのに、今やっているのは、仕様書に無いことに対してのバグつぶしです。
もう破綻寸前です。
それを先方に理解してもらうのも、不可能かと諦め始めています。
なぜ、バグがでるのか。
それは、ファイルメーカーだからなのか。
クライアントからそう思われている現状はとても辛いです。
ファイルメーカーの性にされるのはとても悔しいです。
スーさんのおっしゃる通り、最低限のルールだけでも取り入れてもらえたら...
と、その方法が見つけられない毎日です。
現行の仕様書自体がクライアントが作成したものなので、この次に（もしあれば）改訂版を作成するときには試させていただきます。
>これには、アクセスするユーザーの階層と権利を定義して、これに添ったルールとアクセス権を設定する事は最低でも必要
これに対して、現在もかなりの範囲で行動を制限させていますが、やはり、ルールをちゃんと設けないと現状では破綻が見えてしまっています。
>「深刻な違反は排除する」
これをしてしまったためにクライアントから「動かないソフト」扱いされてしまいました。
その前提には、アクセス権を設定するということも存在しているので、アクセス権の無いユーザーがアクセス権のない動作をした場合クライアントから指示のあった文章で、ウィンドウを出させていましたが、ウィンドウの内容を全然読んでないのか、意味が分からないと言われてしまいました…。
ご心配いただいて、ありがとうございます。
チームで仕事をしているので、孤立はしていませんが、どちらかと言うと、チームで凹んでます…。
yamamotoさん、ありがとうございます。
病院のシステム、難しそうですね。
私も以前真証性に関してかなり作り込みました。
ただ、私の作った真証性自体は、あったこと、したこと、全部残しておく（どのユーザーがどのページの何を、どう書き換えた。その後、どの帳票を見て、何をどう書き換えたか）などの作業で、予想される事を作り込むことはしませんでしたが…。
予想されることを予想させるのは、予言者のようですね。
>最初に「ここまでしか結果がでない仕組み」であることを相手に示しておく必要があるとおもいます。破綻してまで面倒をみていたら、それこそこちらが破綻します
本当にそうです。「仕様書以外のことはしません」と最初に宣言してあるはずなのに、今やっているのは、仕様書に無いことに対してのバグつぶしです。
もう破綻寸前です。
それを先方に理解してもらうのも、不可能かと諦め始めています。
なぜ、バグがでるのか。
それは、ファイルメーカーだからなのか。
クライアントからそう思われている現状はとても辛いです。
ファイルメーカーの性にされるのはとても悔しいです。
スーさんのおっしゃる通り、最低限のルールだけでも取り入れてもらえたら...
と、その方法が見つけられない毎日です。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
ファイルメーカー 更新情報
-
最新のアンケート
