どんなシステム（アプリ然りＤＢ然り）を作るにしても、
何のために、どんな運用の仕方で、という情報が先にないと作成はできないものだ。
経験上、具体案がなく何となく作成してしまったモノは
使いにくいものとなり、敬遠され、おのずと使われなくなる。
なんらかの機能を実装するにしても、
ただ「こうしたい」という情報だけでは１つの実装案しか出てこないし、
その実装方法が本当は回り道をしている機能とは気がつかないケースがある。
他にも、実際実装してみたら元々欲しい機能とちょっと違かったとかもある。
「何のために、どんな運用で」の情報があるだけで
その結果を取り出すための実装案は色々出てくるし、
其の中で最適な実装方法を選択することにより処理の負荷が軽くなったりもする。
他にも、何らかの影響でその一つの方法論が実装不可の場合にでも、
他の実装案で組合せ・応用・代替をすることが可能だろう。
システムとは、人間の手作業による運用部分も含めてシステムというのである。
結局のところ
コンピュータで処理されたデータを情報に読み変えて判断するのは
実際システムを使う人間だからだ。
人によっては何でもかんでも自動化しようとする方がいるが、
どう見ても効率が良くなってるようには思えない場合が多々ある。
自動処理化するところが得意なところだけを
コンピュータ側に処理を分離してやればいいだけだ。
あとは、作り手の自己満足で、見た目だけ豪華で、
結果実のないシステムで使いづらくなってたという場合もあるだろう。
確かに見た目を整えればカッコよく、一度は使って見たいという気持ちになるが、
毎回ウザい操作が実行されてしまう場合には、
それを待っている時間がもったいないと思い、やはり敬遠されてしまうだろう。
以上は、昔初級シスアドを受験するために勉強した内容が元だが、
自分自身の経験則からでもある。
実際のところ、周りの要望を押さえながらのシステム作りは
色々と難しいことがあるが、
やはり、少しでもいい物を提供するために、少しでも長く使ってもらうために、
今後もこの辺を考慮しながらシステムを作成して行きたい。。。
[0回]
PR
COMMENT
その通りなんですけどねえ・・・・・。
NotesDBは早く簡単に出来てしまうというイメージがあるために、依頼者が無茶な開発納期をゴリ押しで通す場合があり。
上記のような情報をよく確認しないまま開発が進んでしまうケースがあります。
NotesDBの特にワークフロー開発でそういった状況にハマると後々保守とかで苦しみますよね。
上流工程をキチッと抑えないと先に進まないような開発をやりたい所ですが職階上の人だと上司もゴリ押しの用件をそのまま聞いてしまうこともあり、
外注開発だと｢その用件を聞くにはお金がもっとかかるよ～｣と突っぱねれば(ある程度)防波堤になるとは思いますが、部内開発だとモロにこの無茶のダメージが来る所が辛い所です。
ﾜｰｸﾌﾛｰは苦労しますね。。
今では要件定義がはっきりしないものは
何度でも打合せをやるようにしています。
相手側の求めてるものはメールだけだと拾い出せませんし、
この辺はFace TO Faceのコミュニケーションにより
探りだすしかないですよね。
（無茶・我侭が多いけど、客先納品でない分
社内のことなので多少時間の融通は効きますし。）
あとはプロトタイプの作成ですかねぇ。。。
今まで積み上げてきたワークフローの形が色々あるので、
其の中から用途に合ったものを選択して
プロトタイプを組み上げるようにしてますね。
ただ、それでも運用開始してある程度時間が経った後に、
組織が変わったりすると
ワークフローの考え方も微妙に変わったりする場合があり
その場合の設計変更に泣いたりします･ﾟ･(ﾉД`)･ﾟ･｡