数億円で中国に外注したシステムより、本を2冊読んで作ったVBAシステムの方が安定してた 69
ストーリー by nagazou
顧客が本当に必要だったもの 部門より
顧客が本当に必要だったもの 部門より
ゆうせいさんのツイートによると、勤めている企業の東京本社が数億円かけて外注した中国製のシステムに問題が起きているという。一方でゆうせいさんが『アプリ作成で学ぶ Excel VBA』と『パーフェクトVBA』を読んで作成したシステムが北海道で安定稼働していることから、東京本社システム部門トップが、同氏の元にGW明けに視察に来ることになったとする内容が話題となっている。同氏によると中国に発注したシステムは同業他社も使えるように、汎用性の高いシステムにしたものの、逆に使い勝手が悪いものとなってしまい、結果として他の企業の採用もなかったとのこと（ゆうせいさんのツイート、Togetter）。
nemui4 曰く、
nemui4 曰く、
外注担当者の要件定義とかが雑やったのか、中華SIerが雑やったのか
問題点の整理 (スコア:1)
入門書レベルのVBAで作った野良システムが普通に実稼働してるところかな？
Re:問題点の整理 (スコア:2, 興味深い)
いかにもこれから「VBAの情報商材をやります」ってプロフィールの人の「俺SUGEEEEEEE、VBAもSUGEEEEEEE」を真に受けちゃってるところでは。＜問題点
事実無根とまでは言わないが、盛ってたり色々してないと、不自然な部分が多い。
Re:問題点の整理 (スコア:1)
危険なニオイのする話ですよね…｡
システムは作ったら終わりじゃないんですよ､不具合修正はもちろんですが
機能の追加変更などいろいろあるし､これらがスムーズにできなければ技術的負債一直線です｡
最初のバージョンを作るのはちゃんとシステムエンジニアリングの経験を積んだところじゃないといけない｡
逆に最初にキチンと作っていれば例え一時期動作が不安定でも修正は容易ですし
いずれ機能追加や次システムへの流用を考える時になれば嫌でも有り難みがわかってくるものです｡
こういう話を聞くとどうしても某動画サービスのことを思い出して不安な気持ちになります｡
3日で作られたそのサービスは年月がたつうちに複雑化し､バージョンアップもまともにできなくなり､
今では利用者は低迷してYoutubeに並ぶとか考える人もいなくなりました｡(一時期ホントに言ってたんですよ)
私はこの件のシステムは知りませんし､安定稼働とやらをどのレベルで実現しているのかわかりませんが
視察に来るというシステム部門トップの人にはとにかく冷静な判断をしてほしいところです…｡
Re:問題点の整理 (スコア:2)
>視察に来るというシステム部門トップの人
原幅に不評なシステムが問題になっている時、現場で好評な自作プログラムがあったとしたら、私ならどういう機能要件なのか参考にしますね。
全社展開するとかじゃなくて、現場が必要としているものを調べるために見に行くように感じる。
それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
Re:問題点の整理 (スコア:1)
＞ それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
現場のいうことを丸のみすると、とんでもない高コストかつ低品質になるのよ。これ常識。
・汎用性、拡張性、ソフトウェアアーキテクチャのしっかりしたソフトウェアを作るのは時間と金とスキルが要る。だからパッケージソフトとして広く販売することで原価を回収する。
・しかし、業務というのは会社それぞれであり、全く同じ業務をしている会社など存在しない。
・業務をパッケージソフトに合わせるように変更する方が、結果として低コスト、高品質になる。
・業務をパッケージソフトに沿うように変更する、パッケージソフトを業務に沿うようにカスタマイズする、そのベストなトレードオフ点を見つけるのが、最も大変な仕事。
・だけど、業務とシステムの両方に精通する人が居ないので、だいたい破綻する。
Re:問題点の整理 (スコア:4, 興味深い)
普通の組織では業務分析やって候補のパッケージとFit&Gap分析して、合わないところをどうするか検討すると思うんだけど（情報処理技術者試験のテキストとか見るとね）、うちのところは「パッケージはこれ。あとば現場で何かしろ」とやって、密接に関連する業務システム同士のデータ連携とか、必須の業務をどうするかといったことも要件からすっぱり落ちてた。
挙げ句の果てが導入したパッケージでカバーしていないところはEUCでやれ、だって。
当然、導入計画時にはその業務をEUCでやれるかどうかの検討もしてない。
異動でそういう状況を引き継いで、今、追い詰められてる。
Re: (スコア:0)
謎技術を生まないことは重要だけど、「初めから本格的に」という考え方が今回のような失敗を生むこともある。システムが肥大化し過ぎて、容易なはずの修正・機能追加が困難になってしまった場合だ。
最初はとにかくシンプルさを重視した作りにしておいて、重要
Re: (スコア:0)
かなエクセルを必要な機能のプロトタイプとして、システム化やり直しが正解でしょうね。
Re: (スコア:0)
最悪言語のVBAよりクソな言語で書かれたのか？とか
Re: (スコア:0)
視察に来たシステム担当部署が引き取ればいいけど、社員個人が作ったソフトを業務に組み込むとロクなことにならなさそう。
色々な部署の奴が自分の業務部署に特化したVBAを構築して、人づてに他部署に展開されて同じようなことをするExcel VBAが複数系統出回るとか。
あと業者のシステムが駄目だったのかもしれないけれど、業務をソフトに合わせずソフトを業務に合わせようとして末端の社員が「つかえねー」と言っているのかもしれない（まあフロー改訂してない管理部署やマネージャー層が悪いけど）
Re: (スコア:0)
リンク先でツイ主がコメントしてるけど、「その場のノリで作った」と言う一方で「システムを内製すること自体が課せられた仕事」らしいから
課内で仕様決めやら試験やらしてるかもしれませんよ
……知らんけど
Re: (スコア:0)
VBAで作れるようなシステムを数億円の予算をつけて外注してしまったことでは？
# お役所仕事かな
Re: (スコア:0)
他社でも使えるような汎用性を持たせたシステム、という点から数億かけて作ったのはEXCELに当たる部分だと思われ。
会社ごとの業務要件定義はその汎用システム上でもすぐ作成できる。ただし、EXCELのVBAほど粒度のこまかいカスタマイズはできませんでしたという感じがするが。
そんなにその汎用システムを作ったのが愚かなことかという点に疑問が残るな。
Re: (スコア:0)
F35 「汎用性を持たせて高価になるのは当然だぞ」
Re: (スコア:0)
規模が違うであろうシステムを並べて安定性を比較してるところ。
Re: (スコア:0)
公表されている情報が少なく、問題を分析するのは難しいね。
言語周辺のテクノロジよりも全体のシステム設計の方が重要度が高いのは確かだが、かといってVBAは厄介だ。
なんか既視感 (スコア:1)
それ、ウチのあれか？北海道から九州まで支店あるのに、サーバーにデータベースアクセスしたら全件とってきてから手元でフィルターかける（ような動作をしているように見える）からメチャクチャ遅くて使いものにならないあれか？
Re: (スコア:0)
全件クライアントで取得するやつ以前良く見かけました。
感心したのは更新処理でクライアントで１件ずつ取得して更新するロジックです。
最近、導入した生産管理システムパッケージは、販売本数が多いらしいのですが
DBが正規化されていなくてトランザクションもまともでないので、びっくりしましたよ。
Re: (スコア:0)
#4241487です。
わかりにくく書いてしまったので補足します。
全件取得、１件ずつ更新の話と生産管理システムは別のシステムです。
このように意図したとおりに相手に情報を伝えるのは難しいのである。 (スコア:0)
たぶん日本人同士、スラドのあれゲはシステムに精通している。にもかかわらずこの通りズレて伝わる。
Re: (スコア:0)
モグリも多いよな。
外注担当者の要件定義とかが雑やったのか、中華SIerが雑やったのか (スコア:1)
実際に、うちの会社は中国にも事務所を構えて 中国の人に業務パッケージを作成いただいているが
そりゃ数億も人がいるんだから一定の割合で雑な人もいるだろうが
少なくとも会社でお願いしたプログラム作成業務については、中国
人が雑だという事はいちどもないな。
敢えて言うとすると、クライアント（日本企業）の要件事項が雑すぎて
明確でない場合は、明確でない雑なものが出来上がるのは確かである。
つまりPJがタコなら、タコな物が出来上がる。
Re:外注担当者の要件定義とかが雑やったのか、中華SIerが雑やったのか (スコア:1)
彼らはドキュメントに書いてある通りにしか作らない。
書いてあることが矛盾していようが、書いてあることが足りなかろうがそれについて指摘や調整は一切しない。
でもオフショアのリスクヘッジとしてはそれが妥当だし、別に中国の業者だからという話じゃないんだよね。
進めながらアジャストしていかなきゃいけないような案件で丸投げしてる時点でマネジメント側が終わってる。
下請けの失敗は発注の失敗 (スコア:0)
下請けに発注する奴って、だいたい自分で作り方を思い付かないものを言う通り作れって発注するじゃん
そりゃ「発注したアホが言う通り」と「現実に存在可能な物体」と「予算の範囲」の共通部分しか出来ないんじゃね?
Re: (スコア:0)
日本のベンダー相手の時のように、朝令暮改依頼しまくったんじゃないかと。
Re: (スコア:0)
シンプルなエクセルファイル1個で完結するものを、外部発注や大袈裟なデータベースの管理システムを作ろうとするアホコンサルに予算の無駄遣いをさせるほうがアホ
ほとんどの顧客は自分が本当に欲しいものがわかっていない (スコア:0)
なので顧客が言うことだけを信じてシステムを作ると大抵は失敗する。
これテストにでるよ。
Re: (スコア:0)
顧客というのがある企業の立場のことなら、
他所でも使えるように仕様を膨らませて数億も稼いだSIは非常にうまくやったと思うが。
Re: (スコア:0)
どうだろうか？
SIerはその場での稼ぎはあったかもしれないが、評判は地に落ちるよね。
出来上がったシステムが入門レベルに負ける出来だったとなると、将来的に受注が減るからマイナスじゃないかな？
Re: (スコア:0)
なんで？
外販できるようなシステムを作ると最終決定したのはエンドだろ？だからこそちゃんとかね払ったんだし。
そしてその販路を開拓できなかったのもエンドの責任だよね。
SIにはなんの問題もないじゃん。変な誹謗中傷流そうものなら訴訟起こされると思われ。
そうだ！みずほ銀行も (スコア:0)
VBAとMS-ACCESDの銀行システムとかキャパオーバーじゃなくても嫌だなぁ
本質はコミュニケーション難易度の予感 (スコア:0)
中国がというよりもコミュニケーション難易度の高い所への依頼はこうゆう事になりがち。
逆に日本が中国の仕事を受注しても同様な事が起こりがちになる。
Re: (スコア:0)
ゆ…か
どうあがいたところで (スコア:0)
現場のヒアリングはするだろうけれど、現場から離れたシステム担当部門がプロジェクトを主導し上層部にプレゼン、更に現場から離れた下手をすると現場経験のない外部から来た管理職がGoへ修正指示
少し気の利いたプロジェクトだと現場の人間がプロジェクトに参加するけれど呼ばれる現場担当者は殆どの場合優秀、悪くてもそこそこ使えるレベルの人材で標準より劣る人や新人の事は考慮しているつもりでも実際は置いてけぼり
もっと最悪なのは外部コンサルなどの言いなりで「現在は誤っており現場はこうあるべき」という思想で過渡期も何も考慮されないプロジェクト
まともなシステムが出来上がる以前にまともなRFPが出る方がレアなんてケースはあるあるかと
数億は無駄になるけれど、別な開発ベンダーで現場が作ったVBAのシステムをRFPとして発注すればいいんじゃないかな
そらまあ (スコア:0)
> 中国に発注したシステムは同業他社も使えるように、汎用性の高いシステムにしたものの、
> 逆に使い勝手が悪いものとなってしまい、結果として他の企業の採用もなかったとのこと
極端な話、専用に作るなら、「ボタン一つ押せばすべて完了」的なシステムを作れるんで、
一つ一つあれこれ選択したり設定したりしなければならず、自分達では使わない機能盛りだくさんな重い(そして不安定な)
汎用システムは、使い勝手の点で太刀打ちできんだろう。
Re: (スコア:0)
まさに「顧客が必要としていたもの」の風刺漫画の話で
これを理解していない顧客や上層部が多い事が根本的な問題ですよね
部分最適化は悪です (スコア:0)
顧客をユーザと定義して顧客が求めるものを作ると同じシステム例えばある会社の勤怠システムでも部署ごとに別のシステムと見紛うレベルのカスタムが入ったり…
そりゃ製造現場と総務を分けろというのはわかるが総務部一課と二課はぎょうむもしゅうぎょうきそくもおなじなのになー。
カチョーのこのちぇっく入れてねをそのまま入れたりブチョーのあのカチョーはアホだから
あの課はこのチェック追加でとか。
Re: (スコア:0)
短期的には現状の業務プロセスに合わせてガチガチに作り込めばそりゃ効率上がるよ。
でも外部環境の変化についていけずに長期的には負債化するってのがみずほを持ち出すまでもなくこの国の多くのシステムの行き着くところ。
大体最初の成功したガチガチシステムをつくった奴は成果扱いされてこれでなにが不満なんだと作り直しとかやりたがらないから余計それが加速する。
良くあるパターンのやつかな (スコア:0)
「汎用性を持たせる」といって、隠蔽化するべきところも全部さらけ出したUIにして
ユーザーが「許されない設定パターンを覚える必要」があったり
ユーザーが気にする必要の無いパラメータをしっかり設定しないとイケないというUIになってたのかもしれんねw
「中国に発注したシステムは同業他社も使えるように、汎用性の高いシステムにした」 (スコア:0)
その汎用システムを売るより、この開発者を同業他社に短期リースして、
それぞれに合ったシンプルな専用システムを構築させるという商売で稼いではどうか？ｗ
はっ！？もしかしてその宣伝のためのステマなのか？
あれもやりたい、これもやりたい→破綻 (スコア:0)
ゴールを明確にせずに色んな部署のあれもやりたいこれもやりたいを盛り込もうとしてクソ使いにくいシステムになったという話なのでは？
で、それと比較して1部署のシンプルな作業の自動化をVBAで組んだものはシンプルが故に安定動作してますよという話だと思うけど
// Accessを使った入力フォームの集計とかなんじゃないかな
Re: (スコア:0)
仕様の異なるシステムを比較しても意味ないよね……
「同じ仕様のものをVBAで自作した方が安定してる」って話ならともかく。
Re: (スコア:0)
要するに取捨選択というか要件をどう取りまとめて展開したかってところを視察したいんじゃね。
VBAなんてゴミにはさすがに興味はないでしょう。
プログラムとシステムをごっちゃにしてる奴大杉。
＞東京本社システム部門トップが、同氏の元にGW明けに視察に来る (スコア:0)
システム部門が無能って話だなｗ
それに”『アプリ作成で学ぶ Excel VBA』と『パーフェクトVBA』を読んで作成”
この程度で作れるシステムなんって大したシステムでもないのに
「オレすげー、部門トップのおえらいさんが来るんだってよｗ」
ってかｗ
Re: (スコア:0)
大きい企業でも社内のシステム部門なんて事務方のちょっと詳しい人の寄せ集めだったりするからなあ。
Re: (スコア:0)
まあそれで本人もびっくりしてるんだろう
本を2冊も読むの凄い (スコア:0)
そこらのIT土方とか零細社内SEなんかは、ネット上のリファレンスとかコード例くらいしか読んでない人も少なくないのでは
Re: (スコア:0)
どんなかな
広く浅く全体を網羅した書籍より、必要な機能に関するリファレンスやコード例を沢山見た方が上の場合も多いし
業務を知り尽くした人間がコード書くのが一番優秀なものができる (スコア:0)
結構お約束みたいな話だと思うけど、低賃金でも済む業務作業者として高賃金のプログラマーを採用する気がないので、
素人が書いて数年後にはメンテ不能なものに陥るのがお約束。
まぁ、時給900円で済む仕事に1500円も払えるかってドケチな発想なんだが。
そんなことやってるから指し値オペまでやって物価高騰させても賃金上がらないんだが。
悲劇 (スコア:0)
たまたまEXCELで出来ることをEXCEL以外で作ると起こり得る話というだけでは？