- PR -

仕様書に記述できない「事情」をシステム化するには？

«前のページへ 1|2
投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-12-24 22:03
いろいろ企業文化もありますから、
他の部署に格好悪い部分を見せたくないという人もいらっしゃるでしょうね。
今まで紙で運用していた業務をそのままシステム化するという要件もあると思います。

「紙に書く」から「画面で入力する」に変化するだけでは、
結局何のためのシステム化かよくわからないですし、何も効率化されないでしょう。
設計を担当する人間としては、非常にもどかしく感じると思います。

その事を顧客の担当者にどう伝えるのかが、一番難しいですね。
コミュニケーション力が要求される場面でもあると思います。
orangeful
常連さん
会議室デビュー日: 2004/09/01
投稿数: 23
投稿日時: 2005-12-25 14:51
引用:
atmarkitmaniaさんの書き込み (2005-12-24 13:11) より:
「ぼかしてコードを書いてくれ」という指示・・・・・・・
その指示がどういう“要件”なのかという点について、よく話が見えませんが・・・。

『ソースコードに』載っていても、通常はそれを見るユーザはいないと思います。
それを見る可能性がある人は、
(1)コードを保守しようとするプログラマ
(2)コードを監査して不正を暴こうとする人
くらいでしょうか？

(1)については、特に防御を考える必要はないでしょう。
一方、(2)に本気で対抗しようとすると大変です。
隠しコマンドを、それこそトロイの木馬として実装しなければならなくなります。
例えばVBのフォームに、かつのりさんの言う項目Cのテキストボックスがあれば、
それはフォームをテキストエディタで開けばすぐ分かりますよね。
だから項目Cのボックスは、デザインモードではなくコードで、
しかも何をやっているコードか分からないようなコードで生成しなければならない、という具合に。

でも、隠しコマンドだからといって、試験しないわけにはいきませんよね。
いや、隠しているから尚更です。
バグによってその機能の存在が周知のものとなってしまっては元も子もありませんから。

そして、その隠しコマンドを毎日の業務で使う方も大変です。
項目Cを入力するためにいちいち「↑↑↓↓←→←→ＢＡ」とかやっていたら日が暮れちゃいます。

まずはその機能をどの程度隠さなければならないのか、
そして開発側としてそれをどの程度隠すのにどの程度の工数が要るのか、
そこら辺を明確にしないと、先へ進めませんね。
（要件を明確にすることと、ドキュメント化することとは違います。今回のケースに限っては。）
権兵衛
ベテラン
会議室デビュー日: 2002/09/24
投稿数: 50
投稿日時: 2005-12-25 21:00
これからはSOX法対策で２とかありそうでやだなぁ
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）