- - PR -
「開発」に携わるものとして、とってもイヤかも
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-02-09 08:28
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040205/139381/
「フリー」なので、どなたでも見られると思います。 「使われないシステムは“ただの箱”」というタイトルです。 システムを作って納品し、それにバグがあるわけではないが、「使われていない」ものが多数ある。「使ってもらう技術」を身につけよう。 という趣旨です。シダックスかな？のコマーシャルで、「お客様の『おいしい』のために」のようなナレーションが入ったコマーシャルが流れていますが、我々も直接的間接的に顧客の「使ってよかった」という声を聞くと、嬉しいしやり甲斐もでるのではないでしょうか。私は「職人気質」なので、「すごい」といわせたい、そんな欲がでるのですが、それも使ってもらってのこと。自分主体ではなく、顧客主体のシステムを作らねば、そう思いました。 | ||||
|
投稿日時: 2004-02-09 08:36
ただ、開発のときには、誰が顧客（使う人）かはちょっと難しいですね。 注文を出す人は、実際に端末を使う人でなかったりします。 | ||||
|
投稿日時: 2004-02-09 09:05
早速ありがとうございます。 うむ、確かに難しいですね。実際、それで困ったシステムがありました（私が前の会社を辞める遠因となったシステム）。また、それには原因がありまして、その原因とは「ユーザは使い方に慣れる」ということです。 簡単に書くと、ユーザは汎用機の操作になれているので、発注者は汎用機の操作を再現できるように注文した。が、PCが大量に導入され、最初はとまどったユーザもやがてPCの操作に慣れた。すると、PCのくせに汎用機の操作方法を要求するシステムに不満が出た。 システムの「寿命」と、ユーザの「環境」まで考えなければならないのかもしれませんね。 | ||||
|
投稿日時: 2004-02-10 12:24
この問題って凄く根本的で解決策を口で言うのは簡単でもとても大変な問題ですよね。 「誰が本当のユーザなのか」、「本当のユーザは何をしたいのか」ということがきちんと 把握できていないと、簡単に「使われないシステム」の出来上がりですよね。 以前実際にそういうシステムを作ってしまったことがありました・・・ 
誰が本当のユーザかを把握するのは受託側(開発側、構築側)の課題でもあることは間違い ないと思うのですが、多分に顧客側の理由(顧客側の部署の力関係や人間関係など)でこの 作業が阻害される面もあると思うんです。その時はテクニカルなスキルではなくて対人間の スキルや顧客側組織の分析のようなスキルが必要なのではないかと思えます。このような スキルを体系的に身に付けていくようなアプローチがあれば、「使われないシステム」撲滅に 一役買えるのではないかと思えるんですが、そういった仕組みって現状あるのでしょうか？ どなたかご存知ありませんか？ | ||||
|
投稿日時: 2004-02-11 01:54
略してすみませんけど、この問題ってどうするのがいいんでしょうね。
言葉をどう使うかで分かれるような気がします。 セキュリティだと ｢悪い奴に対抗しなくてもいいけど、通りがかりの人がぽろっと入れる ようなシステムは避けてほしい｣というリクエストを聞いたことがありました。この発言は、 適度な抽象化とバランスがとれているように思います。 おそらく適度な抽象化と、費用対効果の微妙なバランス感覚の部分で話しができるのが 大切なんですね。答えになっていませんけど、
| ||||
|
投稿日時: 2004-02-11 10:34
これはケースがいろいろある問題なので一言でこれというのは無いと思いますが、
一般論ではなく経験上、システムそのものの「使いにくさ」というものを別に 考えると、「システム構築前のプロセス」というのが一番要因として大きいと 思ってます。 言い換えれば「システム導入の目的や動機付けがどこまで浸透しているか」とい うことになります。具体的に思い返すと、ユーザー側のシステム部門ではなく 現場から「こんなシステムが欲しい」という動機から発足して作成されたシステム はある程度使い勝手が悪くても、結構長い間使われていますよね。（みなさん覚え があるかと．．．） でも、トップダウンやシステム部門が雑誌の記事に刺激されたり等の発想で、現場 に言わば押し付けたシステムというのは得てしてうまく運用されていなかったり、 間違った使われ方をされたり、最悪「ただの箱」状態になったりします。 で、これというのはモチベーションというか、現場の意識付けなんですよね。 「なぜこのシステムを使わないといけないのか」というのが現場の人の頭の中に 常にあるので、その回答が「システム部が使えと言ったから」「社長が使えと言った から」ではやっぱり長続きしないんですよね。「需要」「目的」というところの 意識が出ていないと．．．中には現場の需要や目的というものより、経営的な目的 の為、現場にシステム導入を強制される場合ももちろんあります。けど、その場合 でも何か「給料が上がる」とか「残業減る」とかの夢物語でも良いので、使う意義 や目的をしっかり理解してもらうことが大事でしょうね。 私は大抵、現状分析や要件分析・定義の段階の早い内に現場を回るようにしています。 回れない場合には、現状の業務のヒアリングという名目で何回か現場の人に集まって もらって、作業や問題点等を議論してもらうようにしてます。（現状業務そのものは すでにわかっていても実施します。）２〜３回実施すると思わぬ問題点とか現場の 思い等を聞くことができますよ。ただ、そこで出た要望とかは単に現場の夢物語の 場合もあるので、要件定義や設計がそれに振り回されることのないようにすることは 重要ですが。まぁ、人間対人間なので出来上がったものを「さぁ使え」と置いていか れるより、作る前にある程度意見を聞いてあげる（ひとつでも実現できればよいという 気で）と気分良く使えると思うのですね。 このベースがクリアされた状態の上に、ユーザーインタフェイスの良し悪し等、シス テムそのものの使い勝手の話が出てくると思うのですが．．． | ||||
|
投稿日時: 2004-02-12 10:19
るぱんです。
これって、コンサルティングの仕事では・・・？（汗 | ||||
|
投稿日時: 2004-02-12 10:28
すみません、おばけ＠肩書き上はITコンサルタントです。
えっと、私の認識なんですが、ITコンサルティングと要件定義まで行うシステムエンジニアの 間の切り分けって難しくありませんでしょうか。また、これら二つは顧客側からはあまり 差異が無いと思われている気がするのですが、いかがでしょうか。 皆様のご意見が伺いたいです。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。