|
|
| ■HOME ｜ | |||||||||||||||||||||||
 使えないシステムが作られてしまう 導入してから使えないことが発覚発注者の立場から考えると開発者の立場から考えると一方的に相手が悪いと責めてもソフト開発の見積りの"困った”ソフト会社の選び方は？当社の優秀な技術者？不満を整理すると（依頼側）不満を整理すると（開発側）使えないシステムを運用すると改造すると決定したら？改造する価値の決め手とは新規開発と改造の要件使えないシステム開発の原因契約の内容・範囲が大雑把担当SEの能力の分野が不一致導入側の社内体制創りが不十分より良いシステム開発をするには理想化から現実化へ進める業務のシステム化をプロデュース業務システムからブレークダウン提案：業務システムの設計経営者の「思い考え」を展開成功要素を洗い出す成功要素を組み立てる仕事をＯＳとアプリで考えるオープンシステムの開発体制
|
具体的には．．． ●大きいソフト会社だと、担当者が何回も替わる 業務内容の取材の途中でその専門の担当ＳＥに替わり、そして部下のＳＥに替わるんです そして、そのたびに全く同じ説明をしないといけない場合が本当にあるんです 社名を言えば誰でも知っている外資系のメーカーでもそういう体験がありました 販売管理と言うと．．販売管理の担当がやってきて そこで、打ち合わせの中で、通販があると言うと．．．通販の担当ＳＥが来ます でも、全く社内での引継ぎや打ち合わせをしていないんでしょうか？ 中小企業のシステム開発を安易に考えているのでしょうか？ 何の、引継ぎも無しなのでしょうか？ その会社の業務内容すら理解しないで替わることがありました そのたびに、ゼロから説明しなおしです その間、３週間はまったく進展なしとなりました 新規事業で業務が立ち上がっていて手作業で対処していました でも、それが限界でした 開発費が捻出できる予測できたので開発を進めることになった時点で 全く進展の無い、３週間は大きな遅れです ●小さなソフト会社だと、担当者が仕事を掛け持ちしている 打ち合わせ予定を突然変更されたり、一緒にきている部下のＳＥ一人できたりする 徹夜明けの、疲れ切った顔で打ち合わせに来る場合もある 大丈夫ですと言うが．．．数社の内容が混在しているようだ 小さな会社に多いのが、ＳＥとして業務分析からプロジェクト管理までできる人が少なく いつも、同じ人がユーザーとの打ち合わせに参加している場合があります その人が、業務分析をして設計して、プログラマーに渡します それができないとプログラムが開発できない．．．となります 『優秀な技術者がたくさんいます』と営業マンが言っても プログラマーがたくさんいるが、ＳＥが少ない会社だと このような不安な掛け持ちが起こります 全てのプロジェクトが順調なら何も問題ないのですが．．． ●コンピュータの専門用語で話しをしてくる 自分の理解できないことは、相手の説明能力がないと考える傾向がある 始からコンピュータありきで考えている もっと解かりやすく説明してくれないだろうか ＳＥとは言っても、プログラマー感覚の人だとこうなります 本当に優秀な人は、相手の知識経験にあわせて言葉を選んで話してくれます どうしても、専門用語で話す必要のある場合は その言葉の意味や定義を説明して話します そこも、開発を依頼しても良い相手か？判断する基準になるのではないでしょうか ●契約の範囲外だと親身に聞いてくれない 営業は「何でもできます・やります」と言ったのに、ＳＥに替わると追加見積をしてくる 自分の仕事はコンピュータのプログラムを作ること、それ以外は興味対象外のようだ 全体を理解しないで進めて大丈夫なんだろうか？ 営業マンが提案書を出して受注が決まりＳＥの登場となります そこでは、システムの範囲や価格が決まっています 営業場面にＳＥが同席して、一緒に提案・見積りをする場合もあります ですが、詳細に業務を突き詰めて見積もられた場合は少なく そのソフト会社の、それまでの経験から概算を出している場合が多いのです それに、ＳＥもコスト以上の開発をするな．．．と上司から言われています ですので、できるだけ手間のかからないようにと考えています 仕様追加がどんどんでてくる．．と、開発側は感じています それを止めたいと思っています ●業務の全体を理解できない 業務を理解する社会経験が浅く、業務を体系として理解できない、する気が無い コンピュータ技術の精通と「企業の業務」に精通していることは違う 仕事の全体を把握しないでシステムを作って大丈夫だろうか？ 多くのＳＥは社会人になってからコンピュータの仕事をしています 自分で営業した、商品を納品した、在庫から出庫した、伝票を整理した．．． などとい言う、具体的な業務の体験のある人は非常に少ないのが現実です （アルバイト程度はあるでしょうが） 理屈で知っていることと、実際に体験したことの差は大きいんです 仕事の全体を、具体的な作業に落とし込んで．．． それを正しく頭の中にイメージできるか？！ それが、システムのの設計の基本だと思います 
| |
|||||||||||||||||||||
|
|||||||||
|
|
|||||||||
|
|||||||||
詳しいプロフィール
開発作業時の不満を整理すると（依頼側）
ソフト開発時の依頼側の不満と不安は
テオリア
仕事の図解