- ベストアンサー
Web系のシステムの発注、精度や問題点について
- Web系のシステムの発注において、細かなミスや問題が起こることがあります。バグの修正を依頼すると別の箇所で問題が発生したり、インターフェイスが前のデザインに戻っていたり、進捗報告がなくなったりすることがあります。発注先の選定や指示出しの方法に問題があるのか、自身に不安を抱くこともあります。
- Web系のシステム開発では、完璧に動くシステムをつくるのは難しい場合が多いです。関わっている人が満足しているケースは少なく、常に改善の余地があると感じています。そのため、Web系のシステムを上手く開発するためにはどのような取り組みが必要なのか、考える必要があります。
- 基幹系システムと比較して、Web系のシステム開発は比較的緊張感が少ないと言えます。しかし、発注者や開発者は依然としてトラブルに直面することがあります。Web系の開発においても、問題を最小限に抑えるためにはどのようなアプローチが有効なのか、意見を聞きたいと思います。
- Moonsan
- お礼率84% (33/39)
- SE・インフラ・Webエンジニア
- 回答数4
- ありがとう数4
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
自社開発や派遣で顧客常駐での開発プログラマとしての経験からです。 >>・バグの修正をお願いすると、別の箇所で不具合が出る。 →バグ修正後、回帰テストをやっていないのでしょうね。まあ、テストの手間が増えるから省略したくなるのは判りますが、そうすると痛い目を見ます。 >>・インターフェイスがいつの間にか前のデザインになっている。 →ソースコード版数管理にバージョン管理システムを使っていないのでしょう。それで、修正するソースを間違えて１つか２つ前の版を使っていたのでしょう。 >>・進捗状況の報告をお願いしても、いつの間にかしなくなる（人的問題だけか？）。 →進捗管理システムを使っていないのでしょう。そして、手作業で報告書を作る時間がとれない。 手作業でやると、その報告書の元データとなる進捗データをＰＧから集めるのが大変だし、報告書にするのも手間かかりますからね。 >>・まったく動作確認をせずに渡してきたのでは？ というぐらい単純な間違いをしてくる。 →推察どおり、まったく動作確認をしなかったんでしょう。 >>そこで浮かんだ疑問なのですがWeb系のシステム開発の場合、川の水が 上から下に流れるように淀みなく（ほぼ）完璧にできるというのは、どのぐらいの割合なのでしょうか。 そういう、ウォーターフォール式の開発手法を、Ｗｅｂ系の開発では使わないことが多いようです。 Ｗｅｂ系の業界は、開発予算の削減要求、短期開発、流動的な要求仕様への対応ってことで、アジャイル開発手法と称して、きっちりと仕様書を作らないで、製造工程に入る開発をやったりします。まあ、新しいツールを使う場合、「作ってみないとわからん！」っていうことが多いので、「うだうだ設計しないで、まず作ってみろ！」ってことになったりします。 まあ、そこで作ったものをプロトタイプとして捨て去って、設計からやり直せばいいのですが、予算と期間の問題で、そのまま突き進むと、いろいろと問題が発生することになります。 ちなみに、開発を請け負った会社が、自社でソフト開発を行っている場合、上記のトラブルは、自社の信用問題になりますし、開発コストは全体としてみれば増大することになります。なので、そういった問題は、自社の開発体制をサポートするソフトウエアの導入や体制の見直しにより改善されていく可能性が大ですが、下請けを使っていると、改善されないでしょうね。 また、「利益を生むのはＳＥが担当する上流工程だぜ！ＰＧ作成という下流工程なんて、旨みが少ないし、奴隷階級の下請け会社に任せるべきである！」という思想の会社だったり、開発工程を改善するような考えの社員がいないと、いつまでも、旧来の開発方法を取り続けるってことになると思えます。 ちなみに、私が、会社で「バージョン管理システム」の導入をやったとき、使い方になれてなくて、メンバーの開発中のソースコードが全て消えてしまったことがありました。それでも、工夫しながら使っていたら、それまでに時々あった「昔のソースを使って修正してしまった！」というトラブルは消えました。 まあ、「トラブルがあってもいい、導入しちゃえ！！失敗したら自分が責任とればいいだけ」って「思い切り」をする人が社内にいないと、開発工程の改善はできないでしょうね。
その他の回答 (3)
- lv4u
- ベストアンサー率27% (1862/6715)
>>個人的には「儲かるビジネスの仕組みを作るか？」 寄りなのでシステムの中身そのものは専門職にお任せします、 という考えなんですが、なかなか信頼が置ける所も見つからず 日本では、専門職の技術って（報酬も含めて）評価されないことが多いですよね。 それは、ずっと専門技術の向上をめざしたくとも、管理職になって、技術向上をめざすコースから外れないと出世（報酬アップ）ができないことにも現れていると思います。 そういう日本の状況が、専門面での信頼がおける会社が見つかりにくい結果となっているのだと思っています。 >>また（企画もやってシステム導入もやってマーケティングもやって、 細かな運用とか制作も）という企業やクライアントの要求もあって、 一体どこまで要求してくるのやら・・・ まあ、それも日本ではよくあることですよね。がんばっている社員がいれば、どんどん仕事を押し付けていくってパターンですね。 もちろん、余力があれば、それらの要求に対応すればいいと思います。 でも、仕事を受けるとき、その範囲を決めて、しっかりとそれぞれに対して報酬を受ける契約をしておけば、愚痴も出ないのではないでしょうか？ >>大手もこっちに向かう動きなのですね。 しかしどうも、ブランドの看板頼りのビジネスが続いているような気はします。 まあ、上記に書いたように、技術追求では評価されにくいってことで、ブランドの看板頼りになるしかないのかもしれません。 >>おっしゃるように日本が異なるバックボーンや文化の上でマネても、 製造業と同じように下降線を辿るのでは・・・。 まあ、その可能性はあると思います。 P.S. 先日、ひさしぶりに修理に使うパーツ購入の為、秋葉に行きました。その店の主人は、東京大空襲で大田から杉並へと逃げた話をしてくださいましたが、それ以外に店主の方は「日本人は、修理の技術に対してお金を出さない。でも、海外の方は、仕事の結果を見て、技術にしっかりとお金を払ってくださる。」なんて言われていましたね。 それから、通りで出あったメイドカフェ？で働いていると思える女性が疲れぎみの顔で、しかも洋服が薄汚れている感じがして、「お店は儲かっていないのかな？」なんて感じてしまいました。
お礼
技術職＞＜管理職の関係など、こういう箇所はあまり変わらず 技術や手法だけ急激に変わるので、大変な時代です。 ”アジャイル”など見知らぬ開発手法などを教えて いただいたので、最初の回答をベストアンサーに させていただきます。ありがとうございました。
- lv4u
- ベストアンサー率27% (1862/6715)
>>私は大昔に「システムはきっちり仕様を決めて。仕様変更や開発後 のトラブルは、甚大なコストがかかってしまう」といった仕事を手伝ったのがキッカケなので、そのイメージでずっとやってきました。 そのイメージは正しいと思います。 ただ、Ｗｅｂ系に限らず、要求仕様を固めるのが難しい案件の場合、仕様をきっちり固めて進めるやり方だと、かえってコスト増になりうる可能性があるので、仕様を固めず、開発を先に進めるほうがいいという流れになってきました。 さらに、大昔の開発に比較して、顧客からの短期開発、低予算開発の要求や開発ツールの改善もその流れを後押ししたと思います。 また、パソコンやワークステーションの開発が「ダウンサイジング」という合言葉で広まり、ＯＳとアプリなどがさまざまなメーカを組み合わせる時代になると、障害が発生しても、その原因を突き止めることは困難になりました。そしていつの日か、「バグがあってもいい。完成が遅れるよりは。」という考え方も正当化されました。 （Windowsの時代になり、バグがあっても、「それは仕様です」なんて強弁される風景を見たとき、山のような１６進ダンプリストを何日も費やして追いかけ、バグ退治をしていた汎用機のプログラマは衝撃を受けたと思いますね。） >>ちなみに「開発はウォーターフォールです」と発注書に注記があった そうすると開発手法は、ウォーターフォールでやっていたのかもしれませんね。でも、仕様が固まり、次の製造・テストのフェーズにおいて、先の回答に書いたようなツールを使わないでいると、質問にあるような問題が発生する可能性は大です。 >>なんか・・・技術だけでなく手法もいろいろ変わるみたいで、 発注側も混乱してしまいます。 最新の日経コンピュータを見ますと、クラウドや仮想化、オープンソースの広がりにより、大きく変動しつつあるようですよ。 米国では、システムを造らず、クラウドなど開発がほぼ不要なやり方で、いかに「儲かるビジネスの仕組みを作るか？」ということを主眼にしているようです。 ＣＩＯではなくＣＥＯがシステムを考えているとのことで、「クラウド第２フェーズ」と書かれていました。 ただし、米国は今まで大きな投資をＩＴにやってきたので、そういう実績があるから、第２フェーズに行くことが可能なのかも？と思えたりしますが・・・。 ちなみに某Ｆ社の開発担当に話を聞くと、オープンソースに力を入れて売上げを伸ばしたいらしいのですが、「おい、その戦略でうまくいくのかい？この前も失敗したんじゃあないか？」と思うことがあります。 発注側だけでなく、受注側も時代の急速な流れに混乱しているのかもしれません。
お礼
続けて回答ありがとうございます。 いろいろと興味深い内容です。 ただ・・・やっぱりいろんな変化や膨大な情報に、 目眩がしますね。 個人的には「儲かるビジネスの仕組みを作るか？」 寄りなのでシステムの中身そのものは専門職にお任せします、 という考えなんですが、なかなか信頼が置ける所も見つからず ・・・（その意味でこの質問は、自分の眼力を疑い始めて出した ものです）。 また（企画もやってシステム導入もやってマーケティングもやって、 細かな運用とか制作も）という企業やクライアントの要求もあって、 一体どこまで要求してくるのやら・・・と最近はまた新たな悩みも出る 日々です（ここは愚痴です。すいません）。 閑話休題。 >クラウドや仮想化、オープンソース 大手もこっちに向かう動きなのですね。 しかしどうも、ブランドの看板頼りのビジネスが続いているような気は します。 >米国は今まで大きな投資をＩＴにやってきたので、そういう実績があるから おっしゃるように日本が異なるバックボーンや文化の上でマネても、 製造業と同じように下降線を辿るのでは・・・。
- itou2618
- ベストアンサー率26% (319/1208)
大ブランドの冠がついているような所でＳＥをしていたことがあります。 でも、例にあるのと同じようなミスを繰り返していました。 さすがに、進捗報告はしますし、顧客から指摘された不良に対する対策、同件見直しも、進捗報告の場で説明します。 人間がやることですから、ミスは必ず起こります。 それに対する、対策をきちんと行い、同じミスは起こさない再発防止策をとり、顧客にも報告する。 そういうことをするか、しないかは、その会社の文化でしょう。 システム開発の上流工程からカットオーバーまで、完璧にできること、無かったですね。 納期や開発コストを守れたとしても、必ず潜在不良が残っていました。 工程のなかで、一番重要視していたのは、上流の設計工程です。 ここで、いかに仕様を詳細に詰め切れるかで、カットオーバーするシステムの品質が決まります。 テスト段階で、あれこれ仕様変更するパターンは、不良を作り込んでいるようなものです。
お礼
回答ありがとうございます。 >そういうことをするか、しないかは、その会社の文化でしょう。 技術とコストだけではなく、こういった点も合わせて業者さんは選ばない といけないのですね（しかし営業段階と態度が違ったり実開発の際は 担当者が変わるなどもあって、難しいところです）。 >工程のなかで、一番重要視していたのは、上流の設計工程です。 やはりそこなのですね。 最近（質問にあるような規模の開発）では、「要件定義書」もメモ書き みたいなものが多いです。中には「要件定義書」無しに（あの程度の 打ち合わせでもう作ってるの？）という事もあります。 ところがそこそこのモノが出て来て、バグや細かな仕様の行き違いも 指摘すればすぐに対応するのである意味凄いな・・・大手の立派な 要件定義書はコストの上乗せなんじゃないの？ と思う事もしばしばです。 しかし渡す前に確認したりデータが一部昔に戻っていたりなど細かな ミスも目立つので、どうしたものか・・・と悩んでいるところです。
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/spn/images/related_qa/c205_4_thumbnail_img_sm.png)
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/spn/images/related_qa/c205_2_thumbnail_img_sm.png)
お礼
回答ありがとうございます。 アジャイル開発というのがあるのですね。 私は大昔に「システムはきっちり仕様を決めて。仕様変更や開発後 のトラブルは、甚大なコストがかかってしまう」といった仕事を 手伝ったのがキッカケなので、そのイメージでずっとやってきました。 システムの人間でも無いしWeb系の小規模システムなので精緻では 全くない詰め方ですが、（システムの場合は、最初にしっかり固めて おかないと）という意識はありました。 しかし少しこの認識自体を改める必要も感じました。 ちなみに「開発はウォーターフォールです」と発注書に注記があった ので結構気を使って仕様の詰め（ベンダー側が要件定義書を出して 来ないので、こちらがメモレベルの確認書を渡した）をおこなった 案件もあったのですが、いつの間にか納品されて不具合がたくさん。 でも指摘すると（明らかな仕様変更以外は）すぐに直してくる、 というのもありました。 なんか・・・技術だけでなく手法もいろいろ変わるみたいで、 発注側も混乱してしまいます。