Web系のシステムの発注、その精度について

Question

Webのシステム（それほど大規模なものではなく、例えば閲覧権限を区切った自動
集計システムやMySQL、PHPなどをみ合わせたオリジナルCMSなど）についてです。

これらの発注を自分の選んだ開発会社などにお願いしているのですが、致命的
なものはほとんど無いのですが開発段階で細かなミスが起こります。

（例）※いずれも最終納品前。
・バグの修正をお願いすると、別の箇所で不具合が出る。
・インターフェイスがいつの間にか前のデザインになっている。
・進捗状況の報告をお願いしても、いつの間にかしなくなる（人的問題だけか？）。
・まったく動作確認をせずに渡してきたのでは？　というぐらい単純な間違いをしてくる。

基本的には大ブランドの冠がついているような所には発注せず、独立系の所に
お願いしています。またそれほど規模の大きな開発でも無いので、Web系の
少人数（数人～数十人程度）の会社です。
指摘をすると対応はしてくれるのですが、（自分の業者選びにミスがあるのか）
（指示出しが悪いのか）と不安に思い始めています。
※前提として明らかな仕様変更や追加の際は追加料金を支払っていますし、
極端な値引き交渉もおこなっていないつもりです。

しかし、ここで過去に携わった案件を思い出してみると既存のシステムに携わった
場合も、「このシステムは完璧に動いている」というものはまず無く、大抵は関わって
いる人が「直したいけどもう動いているから・・・」「ここがマズイんだけどね」など
溜息混じりでいるのが常でした。

そこで浮かんだ疑問なのですがWeb系のシステム開発の場合、川の水が
上から下に流れるように淀みなく（ほぼ）完璧にできるというのは、どのぐらいの
割合なのでしょうか。またそうするためにはどこに力を入れれば良いでしょうか。
基幹系システムの担当者（クライアントの場合も開発の場合も）がよく「トラブル」
にあっているのは見てきたのですが、Web系の開発はあれほどナーバスでは無い
というイメージなので、これと比較してのご意見も頂けると有難いです。

lv4u · Accepted Answer

自社開発や派遣で顧客常駐での開発プログラマとしての経験からです。

>>・バグの修正をお願いすると、別の箇所で不具合が出る。
→バグ修正後、回帰テストをやっていないのでしょうね。まあ、テストの手間が増えるから省略したくなるのは判りますが、そうすると痛い目を見ます。

>>・インターフェイスがいつの間にか前のデザインになっている。
→ソースコード版数管理にバージョン管理システムを使っていないのでしょう。それで、修正するソースを間違えて１つか２つ前の版を使っていたのでしょう。

>>・進捗状況の報告をお願いしても、いつの間にかしなくなる（人的問題だけか？）。
→進捗管理システムを使っていないのでしょう。そして、手作業で報告書を作る時間がとれない。
手作業でやると、その報告書の元データとなる進捗データをＰＧから集めるのが大変だし、報告書にするのも手間かかりますからね。

>>・まったく動作確認をせずに渡してきたのでは？　というぐらい単純な間違いをしてくる。
→推察どおり、まったく動作確認をしなかったんでしょう。

>>そこで浮かんだ疑問なのですがWeb系のシステム開発の場合、川の水が
上から下に流れるように淀みなく（ほぼ）完璧にできるというのは、どのぐらいの割合なのでしょうか。

そういう、ウォーターフォール式の開発手法を、Ｗｅｂ系の開発では使わないことが多いようです。
Ｗｅｂ系の業界は、開発予算の削減要求、短期開発、流動的な要求仕様への対応ってことで、アジャイル開発手法と称して、きっちりと仕様書を作らないで、製造工程に入る開発をやったりします。まあ、新しいツールを使う場合、「作ってみないとわからん！」っていうことが多いので、「うだうだ設計しないで、まず作ってみろ！」ってことになったりします。
まあ、そこで作ったものをプロトタイプとして捨て去って、設計からやり直せばいいのですが、予算と期間の問題で、そのまま突き進むと、いろいろと問題が発生することになります。

ちなみに、開発を請け負った会社が、自社でソフト開発を行っている場合、上記のトラブルは、自社の信用問題になりますし、開発コストは全体としてみれば増大することになります。なので、そういった問題は、自社の開発体制をサポートするソフトウエアの導入や体制の見直しにより改善されていく可能性が大ですが、下請けを使っていると、改善されないでしょうね。
また、「利益を生むのはＳＥが担当する上流工程だぜ！ＰＧ作成という下流工程なんて、旨みが少ないし、奴隷階級の下請け会社に任せるべきである！」という思想の会社だったり、開発工程を改善するような考えの社員がいないと、いつまでも、旧来の開発方法を取り続けるってことになると思えます。

ちなみに、私が、会社で「バージョン管理システム」の導入をやったとき、使い方になれてなくて、メンバーの開発中のソースコードが全て消えてしまったことがありました。それでも、工夫しながら使っていたら、それまでに時々あった「昔のソースを使って修正してしまった！」というトラブルは消えました。
まあ、「トラブルがあってもいい、導入しちゃえ！！失敗したら自分が責任とればいいだけ」って「思い切り」をする人が社内にいないと、開発工程の改善はできないでしょうね。

lv4u · Answer

>>個人的には「儲かるビジネスの仕組みを作るか？」
寄りなのでシステムの中身そのものは専門職にお任せします、
という考えなんですが、なかなか信頼が置ける所も見つからず

日本では、専門職の技術って（報酬も含めて）評価されないことが多いですよね。
それは、ずっと専門技術の向上をめざしたくとも、管理職になって、技術向上をめざすコースから外れないと出世（報酬アップ）ができないことにも現れていると思います。
そういう日本の状況が、専門面での信頼がおける会社が見つかりにくい結果となっているのだと思っています。

>>また（企画もやってシステム導入もやってマーケティングもやって、
細かな運用とか制作も）という企業やクライアントの要求もあって、
一体どこまで要求してくるのやら・・・

まあ、それも日本ではよくあることですよね。がんばっている社員がいれば、どんどん仕事を押し付けていくってパターンですね。
もちろん、余力があれば、それらの要求に対応すればいいと思います。
でも、仕事を受けるとき、その範囲を決めて、しっかりとそれぞれに対して報酬を受ける契約をしておけば、愚痴も出ないのではないでしょうか？

>>大手もこっちに向かう動きなのですね。
しかしどうも、ブランドの看板頼りのビジネスが続いているような気はします。

まあ、上記に書いたように、技術追求では評価されにくいってことで、ブランドの看板頼りになるしかないのかもしれません。

>>おっしゃるように日本が異なるバックボーンや文化の上でマネても、
製造業と同じように下降線を辿るのでは・・・。

まあ、その可能性はあると思います。

P.S.
先日、ひさしぶりに修理に使うパーツ購入の為、秋葉に行きました。その店の主人は、東京大空襲で大田から杉並へと逃げた話をしてくださいましたが、それ以外に店主の方は「日本人は、修理の技術に対してお金を出さない。でも、海外の方は、仕事の結果を見て、技術にしっかりとお金を払ってくださる。」なんて言われていましたね。
それから、通りで出あったメイドカフェ？で働いていると思える女性が疲れぎみの顔で、しかも洋服が薄汚れている感じがして、「お店は儲かっていないのかな？」なんて感じてしまいました。

lv4u · Answer

>>私は大昔に「システムはきっちり仕様を決めて。仕様変更や開発後
のトラブルは、甚大なコストがかかってしまう」といった仕事を手伝ったのがキッカケなので、そのイメージでずっとやってきました。

そのイメージは正しいと思います。
ただ、Ｗｅｂ系に限らず、要求仕様を固めるのが難しい案件の場合、仕様をきっちり固めて進めるやり方だと、かえってコスト増になりうる可能性があるので、仕様を固めず、開発を先に進めるほうがいいという流れになってきました。
さらに、大昔の開発に比較して、顧客からの短期開発、低予算開発の要求や開発ツールの改善もその流れを後押ししたと思います。
また、パソコンやワークステーションの開発が「ダウンサイジング」という合言葉で広まり、ＯＳとアプリなどがさまざまなメーカを組み合わせる時代になると、障害が発生しても、その原因を突き止めることは困難になりました。そしていつの日か、「バグがあってもいい。完成が遅れるよりは。」という考え方も正当化されました。
（Windowsの時代になり、バグがあっても、「それは仕様です」なんて強弁される風景を見たとき、山のような１６進ダンプリストを何日も費やして追いかけ、バグ退治をしていた汎用機のプログラマは衝撃を受けたと思いますね。）

>>ちなみに「開発はウォーターフォールです」と発注書に注記があった

そうすると開発手法は、ウォーターフォールでやっていたのかもしれませんね。でも、仕様が固まり、次の製造・テストのフェーズにおいて、先の回答に書いたようなツールを使わないでいると、質問にあるような問題が発生する可能性は大です。

>>なんか・・・技術だけでなく手法もいろいろ変わるみたいで、
発注側も混乱してしまいます。

最新の日経コンピュータを見ますと、クラウドや仮想化、オープンソースの広がりにより、大きく変動しつつあるようですよ。
米国では、システムを造らず、クラウドなど開発がほぼ不要なやり方で、いかに「儲かるビジネスの仕組みを作るか？」ということを主眼にしているようです。
ＣＩＯではなくＣＥＯがシステムを考えているとのことで、「クラウド第２フェーズ」と書かれていました。
ただし、米国は今まで大きな投資をＩＴにやってきたので、そういう実績があるから、第２フェーズに行くことが可能なのかも？と思えたりしますが・・・。

ちなみに某Ｆ社の開発担当に話を聞くと、オープンソースに力を入れて売上げを伸ばしたいらしいのですが、「おい、その戦略でうまくいくのかい？この前も失敗したんじゃあないか？」と思うことがあります。
発注側だけでなく、受注側も時代の急速な流れに混乱しているのかもしれません。

itou2618 · Answer

大ブランドの冠がついているような所でＳＥをしていたことがあります。
でも、例にあるのと同じようなミスを繰り返していました。
さすがに、進捗報告はしますし、顧客から指摘された不良に対する対策、同件見直しも、進捗報告の場で説明します。
人間がやることですから、ミスは必ず起こります。
それに対する、対策をきちんと行い、同じミスは起こさない再発防止策をとり、顧客にも報告する。
そういうことをするか、しないかは、その会社の文化でしょう。

システム開発の上流工程からカットオーバーまで、完璧にできること、無かったですね。
納期や開発コストを守れたとしても、必ず潜在不良が残っていました。
工程のなかで、一番重要視していたのは、上流の設計工程です。
ここで、いかに仕様を詳細に詰め切れるかで、カットオーバーするシステムの品質が決まります。
テスト段階で、あれこれ仕様変更するパターンは、不良を作り込んでいるようなものです。

Web系のシステムの発注、その精度について

自社開発や派遣で顧客常駐での開発プログラマとしての経験からです。

>>個人的には「儲かるビジネスの仕組みを作るか？」

>>私は大昔に「システムはきっちり仕様を決めて。

大ブランドの冠がついているような所でＳＥをしていたことがあります。

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング