Webのシステム(それほど大規模なものではなく、例えば閲覧権限を区切った自動
集計システムやMySQL、PHPなどをみ合わせたオリジナルCMSなど)についてです。
これらの発注を自分の選んだ開発会社などにお願いしているのですが、致命的
なものはほとんど無いのですが開発段階で細かなミスが起こります。
(例)※いずれも最終納品前。
・バグの修正をお願いすると、別の箇所で不具合が出る。
・インターフェイスがいつの間にか前のデザインになっている。
・進捗状況の報告をお願いしても、いつの間にかしなくなる(人的問題だけか?)。
・まったく動作確認をせずに渡してきたのでは? というぐらい単純な間違いをしてくる。
基本的には大ブランドの冠がついているような所には発注せず、独立系の所に
お願いしています。またそれほど規模の大きな開発でも無いので、Web系の
少人数(数人~数十人程度)の会社です。
指摘をすると対応はしてくれるのですが、(自分の業者選びにミスがあるのか)
(指示出しが悪いのか)と不安に思い始めています。
※前提として明らかな仕様変更や追加の際は追加料金を支払っていますし、
極端な値引き交渉もおこなっていないつもりです。
しかし、ここで過去に携わった案件を思い出してみると既存のシステムに携わった
場合も、「このシステムは完璧に動いている」というものはまず無く、大抵は関わって
いる人が「直したいけどもう動いているから・・・」「ここがマズイんだけどね」など
溜息混じりでいるのが常でした。
そこで浮かんだ疑問なのですがWeb系のシステム開発の場合、川の水が
上から下に流れるように淀みなく(ほぼ)完璧にできるというのは、どのぐらいの
割合なのでしょうか。またそうするためにはどこに力を入れれば良いでしょうか。
基幹系システムの担当者(クライアントの場合も開発の場合も)がよく「トラブル」
にあっているのは見てきたのですが、Web系の開発はあれほどナーバスでは無い
というイメージなので、これと比較してのご意見も頂けると有難いです。
No.2ベストアンサー
- 回答日時:
自社開発や派遣で顧客常駐での開発プログラマとしての経験からです。
>>・バグの修正をお願いすると、別の箇所で不具合が出る。
→バグ修正後、回帰テストをやっていないのでしょうね。まあ、テストの手間が増えるから省略したくなるのは判りますが、そうすると痛い目を見ます。
>>・インターフェイスがいつの間にか前のデザインになっている。
→ソースコード版数管理にバージョン管理システムを使っていないのでしょう。それで、修正するソースを間違えて1つか2つ前の版を使っていたのでしょう。
>>・進捗状況の報告をお願いしても、いつの間にかしなくなる(人的問題だけか?)。
→進捗管理システムを使っていないのでしょう。そして、手作業で報告書を作る時間がとれない。
手作業でやると、その報告書の元データとなる進捗データをPGから集めるのが大変だし、報告書にするのも手間かかりますからね。
>>・まったく動作確認をせずに渡してきたのでは? というぐらい単純な間違いをしてくる。
→推察どおり、まったく動作確認をしなかったんでしょう。
>>そこで浮かんだ疑問なのですがWeb系のシステム開発の場合、川の水が
上から下に流れるように淀みなく(ほぼ)完璧にできるというのは、どのぐらいの割合なのでしょうか。
そういう、ウォーターフォール式の開発手法を、Web系の開発では使わないことが多いようです。
Web系の業界は、開発予算の削減要求、短期開発、流動的な要求仕様への対応ってことで、アジャイル開発手法と称して、きっちりと仕様書を作らないで、製造工程に入る開発をやったりします。まあ、新しいツールを使う場合、「作ってみないとわからん!」っていうことが多いので、「うだうだ設計しないで、まず作ってみろ!」ってことになったりします。
まあ、そこで作ったものをプロトタイプとして捨て去って、設計からやり直せばいいのですが、予算と期間の問題で、そのまま突き進むと、いろいろと問題が発生することになります。
ちなみに、開発を請け負った会社が、自社でソフト開発を行っている場合、上記のトラブルは、自社の信用問題になりますし、開発コストは全体としてみれば増大することになります。なので、そういった問題は、自社の開発体制をサポートするソフトウエアの導入や体制の見直しにより改善されていく可能性が大ですが、下請けを使っていると、改善されないでしょうね。
また、「利益を生むのはSEが担当する上流工程だぜ!PG作成という下流工程なんて、旨みが少ないし、奴隷階級の下請け会社に任せるべきである!」という思想の会社だったり、開発工程を改善するような考えの社員がいないと、いつまでも、旧来の開発方法を取り続けるってことになると思えます。
ちなみに、私が、会社で「バージョン管理システム」の導入をやったとき、使い方になれてなくて、メンバーの開発中のソースコードが全て消えてしまったことがありました。それでも、工夫しながら使っていたら、それまでに時々あった「昔のソースを使って修正してしまった!」というトラブルは消えました。
まあ、「トラブルがあってもいい、導入しちゃえ!!失敗したら自分が責任とればいいだけ」って「思い切り」をする人が社内にいないと、開発工程の改善はできないでしょうね。
回答ありがとうございます。
アジャイル開発というのがあるのですね。
私は大昔に「システムはきっちり仕様を決めて。仕様変更や開発後
のトラブルは、甚大なコストがかかってしまう」といった仕事を
手伝ったのがキッカケなので、そのイメージでずっとやってきました。
システムの人間でも無いしWeb系の小規模システムなので精緻では
全くない詰め方ですが、(システムの場合は、最初にしっかり固めて
おかないと)という意識はありました。
しかし少しこの認識自体を改める必要も感じました。
ちなみに「開発はウォーターフォールです」と発注書に注記があった
ので結構気を使って仕様の詰め(ベンダー側が要件定義書を出して
来ないので、こちらがメモレベルの確認書を渡した)をおこなった
案件もあったのですが、いつの間にか納品されて不具合がたくさん。
でも指摘すると(明らかな仕様変更以外は)すぐに直してくる、
というのもありました。
なんか・・・技術だけでなく手法もいろいろ変わるみたいで、
発注側も混乱してしまいます。
No.4
- 回答日時:
>>個人的には「儲かるビジネスの仕組みを作るか?」
寄りなのでシステムの中身そのものは専門職にお任せします、
という考えなんですが、なかなか信頼が置ける所も見つからず
日本では、専門職の技術って(報酬も含めて)評価されないことが多いですよね。
それは、ずっと専門技術の向上をめざしたくとも、管理職になって、技術向上をめざすコースから外れないと出世(報酬アップ)ができないことにも現れていると思います。
そういう日本の状況が、専門面での信頼がおける会社が見つかりにくい結果となっているのだと思っています。
>>また(企画もやってシステム導入もやってマーケティングもやって、
細かな運用とか制作も)という企業やクライアントの要求もあって、
一体どこまで要求してくるのやら・・・
まあ、それも日本ではよくあることですよね。がんばっている社員がいれば、どんどん仕事を押し付けていくってパターンですね。
もちろん、余力があれば、それらの要求に対応すればいいと思います。
でも、仕事を受けるとき、その範囲を決めて、しっかりとそれぞれに対して報酬を受ける契約をしておけば、愚痴も出ないのではないでしょうか?
>>大手もこっちに向かう動きなのですね。
しかしどうも、ブランドの看板頼りのビジネスが続いているような気はします。
まあ、上記に書いたように、技術追求では評価されにくいってことで、ブランドの看板頼りになるしかないのかもしれません。
>>おっしゃるように日本が異なるバックボーンや文化の上でマネても、
製造業と同じように下降線を辿るのでは・・・。
まあ、その可能性はあると思います。
P.S.
先日、ひさしぶりに修理に使うパーツ購入の為、秋葉に行きました。その店の主人は、東京大空襲で大田から杉並へと逃げた話をしてくださいましたが、それ以外に店主の方は「日本人は、修理の技術に対してお金を出さない。でも、海外の方は、仕事の結果を見て、技術にしっかりとお金を払ってくださる。」なんて言われていましたね。
それから、通りで出あったメイドカフェ?で働いていると思える女性が疲れぎみの顔で、しかも洋服が薄汚れている感じがして、「お店は儲かっていないのかな?」なんて感じてしまいました。
技術職><管理職の関係など、こういう箇所はあまり変わらず
技術や手法だけ急激に変わるので、大変な時代です。
”アジャイル”など見知らぬ開発手法などを教えて
いただいたので、最初の回答をベストアンサーに
させていただきます。ありがとうございました。
No.3
- 回答日時:
>>私は大昔に「システムはきっちり仕様を決めて。
仕様変更や開発後のトラブルは、甚大なコストがかかってしまう」といった仕事を手伝ったのがキッカケなので、そのイメージでずっとやってきました。
そのイメージは正しいと思います。
ただ、Web系に限らず、要求仕様を固めるのが難しい案件の場合、仕様をきっちり固めて進めるやり方だと、かえってコスト増になりうる可能性があるので、仕様を固めず、開発を先に進めるほうがいいという流れになってきました。
さらに、大昔の開発に比較して、顧客からの短期開発、低予算開発の要求や開発ツールの改善もその流れを後押ししたと思います。
また、パソコンやワークステーションの開発が「ダウンサイジング」という合言葉で広まり、OSとアプリなどがさまざまなメーカを組み合わせる時代になると、障害が発生しても、その原因を突き止めることは困難になりました。そしていつの日か、「バグがあってもいい。完成が遅れるよりは。」という考え方も正当化されました。
(Windowsの時代になり、バグがあっても、「それは仕様です」なんて強弁される風景を見たとき、山のような16進ダンプリストを何日も費やして追いかけ、バグ退治をしていた汎用機のプログラマは衝撃を受けたと思いますね。)
>>ちなみに「開発はウォーターフォールです」と発注書に注記があった
そうすると開発手法は、ウォーターフォールでやっていたのかもしれませんね。でも、仕様が固まり、次の製造・テストのフェーズにおいて、先の回答に書いたようなツールを使わないでいると、質問にあるような問題が発生する可能性は大です。
>>なんか・・・技術だけでなく手法もいろいろ変わるみたいで、
発注側も混乱してしまいます。
最新の日経コンピュータを見ますと、クラウドや仮想化、オープンソースの広がりにより、大きく変動しつつあるようですよ。
米国では、システムを造らず、クラウドなど開発がほぼ不要なやり方で、いかに「儲かるビジネスの仕組みを作るか?」ということを主眼にしているようです。
CIOではなくCEOがシステムを考えているとのことで、「クラウド第2フェーズ」と書かれていました。
ただし、米国は今まで大きな投資をITにやってきたので、そういう実績があるから、第2フェーズに行くことが可能なのかも?と思えたりしますが・・・。
ちなみに某F社の開発担当に話を聞くと、オープンソースに力を入れて売上げを伸ばしたいらしいのですが、「おい、その戦略でうまくいくのかい?この前も失敗したんじゃあないか?」と思うことがあります。
発注側だけでなく、受注側も時代の急速な流れに混乱しているのかもしれません。
続けて回答ありがとうございます。
いろいろと興味深い内容です。
ただ・・・やっぱりいろんな変化や膨大な情報に、
目眩がしますね。
個人的には「儲かるビジネスの仕組みを作るか?」
寄りなのでシステムの中身そのものは専門職にお任せします、
という考えなんですが、なかなか信頼が置ける所も見つからず
・・・(その意味でこの質問は、自分の眼力を疑い始めて出した
ものです)。
また(企画もやってシステム導入もやってマーケティングもやって、
細かな運用とか制作も)という企業やクライアントの要求もあって、
一体どこまで要求してくるのやら・・・と最近はまた新たな悩みも出る
日々です(ここは愚痴です。すいません)。
閑話休題。
>クラウドや仮想化、オープンソース
大手もこっちに向かう動きなのですね。
しかしどうも、ブランドの看板頼りのビジネスが続いているような気は
します。
>米国は今まで大きな投資をITにやってきたので、そういう実績があるから
おっしゃるように日本が異なるバックボーンや文化の上でマネても、
製造業と同じように下降線を辿るのでは・・・。
No.1
- 回答日時:
大ブランドの冠がついているような所でSEをしていたことがあります。
でも、例にあるのと同じようなミスを繰り返していました。
さすがに、進捗報告はしますし、顧客から指摘された不良に対する対策、同件見直しも、進捗報告の場で説明します。
人間がやることですから、ミスは必ず起こります。
それに対する、対策をきちんと行い、同じミスは起こさない再発防止策をとり、顧客にも報告する。
そういうことをするか、しないかは、その会社の文化でしょう。
システム開発の上流工程からカットオーバーまで、完璧にできること、無かったですね。
納期や開発コストを守れたとしても、必ず潜在不良が残っていました。
工程のなかで、一番重要視していたのは、上流の設計工程です。
ここで、いかに仕様を詳細に詰め切れるかで、カットオーバーするシステムの品質が決まります。
テスト段階で、あれこれ仕様変更するパターンは、不良を作り込んでいるようなものです。
回答ありがとうございます。
>そういうことをするか、しないかは、その会社の文化でしょう。
技術とコストだけではなく、こういった点も合わせて業者さんは選ばない
といけないのですね(しかし営業段階と態度が違ったり実開発の際は
担当者が変わるなどもあって、難しいところです)。
>工程のなかで、一番重要視していたのは、上流の設計工程です。
やはりそこなのですね。
最近(質問にあるような規模の開発)では、「要件定義書」もメモ書き
みたいなものが多いです。中には「要件定義書」無しに(あの程度の
打ち合わせでもう作ってるの?)という事もあります。
ところがそこそこのモノが出て来て、バグや細かな仕様の行き違いも
指摘すればすぐに対応するのである意味凄いな・・・大手の立派な
要件定義書はコストの上乗せなんじゃないの? と思う事もしばしばです。
しかし渡す前に確認したりデータが一部昔に戻っていたりなど細かな
ミスも目立つので、どうしたものか・・・と悩んでいるところです。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
おすすめ情報
- ・漫画をレンタルでお得に読める!
- ・ゆるやかでぃべーと タイムマシンを破壊すべきか。
- ・「I love you」 をかっこよく翻訳してみてください
- ・歩いた自慢大会
- ・許せない心理テスト
- ・字面がカッコいい英単語
- ・昔のあなたへのアドバイス
- ・かっこよく答えてください!!
- ・あなたが好きな本屋さんを教えてください
- ・スタッフと宿泊客が全員斜め上を行くホテルのレビュー
- ・【大喜利】【投稿~8/27】 こんなガソリンスタンド二度と来るか!なぜそう思った?
- ・これ何て呼びますか Part2
- ・人生で一番思い出に残ってる靴
- ・【お題】動物のキャッチフレーズ
- ・【お題】甲子園での思い出の残し方
- ・ゆるやかでぃべーと すべての高校生はアルバイトをするべきだ。
- ・「それ、メッセージ花火でわざわざ伝えること?」
- ・自分用のお土産
- ・人生で一番お金がなかったとき
- ・一番好きなみそ汁の具材は?
- ・泣きながら食べたご飯の思い出
- ・ちょっと先の未来クイズ第1問
- ・ゴリラ向け動画サイト「ウホウホ動画」にありがちなこと
- ・初めて自分の家と他人の家が違う、と意識した時
- ・単二電池
- ・チョコミントアイス
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
製薬会社,臨床開発職と研究職...
-
ソフトウェアの開発金額って?
-
商売は競合企業に嫌がらせをす...
-
翻訳お願いします(契約書一文)
-
労働組合が会社の株を購入する...
-
ARって何の略でどういう意味で...
-
戸塚宏が「リベラルは悪」と言...
-
ソープとヘルス「デリヘルも含...
-
地区音響と保守地区音響の違い...
-
社内で1番激務な部署の課に異動...
-
外資は業務引き継ぎをしない?
-
気象庁と日本気象協会の違い
-
高校生探偵は実在しますか?
-
システム開発外注費の源泉徴収
-
定型業務・非定型業務とは?
-
雇用後の業務範囲の拡大と業務内容
-
営業所の整理について「名前を...
-
仕様書の見本等参考になるもの...
-
運用・保守について
-
PG⇒SEへ昇進する段階・時期につ...
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
システム開発を一次開発と二次...
-
「研究開発」というのは間接部...
-
ActiveX Data Objectsについて...
-
メーカーに入ったら、基本的に...
-
ラツーダ発売から4年くらいた...
-
EIAJ-EDI標準
-
ソフトウェアの開発金額って?
-
職務経歴書・面接で開発会社の...
-
労働組合が会社の株を購入する...
-
理系修士が研究開発職以外の技術職
-
商売は競合企業に嫌がらせをす...
-
Lotus Notesの習得方法を教えて...
-
CADとVBAによるプログラミング...
-
開発費を支払った商品の継続販...
-
リニアモーターカーに関する仕事
-
個人でWebサービスを作りたいで...
-
ERPの開発を独学したいのですが...
-
「開発ステップ数」とは?
-
企業の商品開発の仕事の内容と...
-
プログラミングで在宅で副業を...
おすすめ情報