アカウント名:
パスワード:
入門書レベルのVBAで作った野良システムが普通に実稼働してるところかな?
いかにもこれから「VBAの情報商材をやります」ってプロフィールの人の「俺SUGEEEEEEE、VBAもSUGEEEEEEE」を真に受けちゃってるところでは。<問題点
事実無根とまでは言わないが、盛ってたり色々してないと、不自然な部分が多い。
「東京本社システム部門トップが同氏の元に視察に来る」あたりの香ばしさも良いね
それはさておき、公式で作ったら色々と責任が発生してしまうサービスは「あくまで現場のユーザが草の根で作って自己責任で使ってます」というほうが出来が良くなることは往々にしてあるからなあどこぞの大学の単位選択フォームみたいな感じで
I/Fさえ守られればUIはどうぞ勝手に、というWebAPIシステムは強い
危険なニオイのする話ですよね…。システムは作ったら終わりじゃないんですよ、不具合修正はもちろんですが機能の追加変更などいろいろあるし、これらがスムーズにできなければ技術的負債一直線です。
最初のバージョンを作るのはちゃんとシステムエンジニアリングの経験を積んだところじゃないといけない。逆に最初にキチンと作っていれば例え一時期動作が不安定でも修正は容易ですしいずれ機能追加や次システムへの流用を考える時になれば嫌でも有り難みがわかってくるものです。
こういう話を聞くとどうしても某動画サービスのことを思い出して不安な気持ちになります。3日で作られたそのサービスは年月がたつうちに複雑化し、バージョンアップもまともにできなくなり、今では利用者は低迷してYoutubeに並ぶとか考える人もいなくなりました。(一時期ホントに言ってたんですよ)
私はこの件のシステムは知りませんし、安定稼働とやらをどのレベルで実現しているのかわかりませんが視察に来るというシステム部門トップの人にはとにかく冷静な判断をしてほしいところです…。
>視察に来るというシステム部門トップの人
原幅に不評なシステムが問題になっている時、現場で好評な自作プログラムがあったとしたら、私ならどういう機能要件なのか参考にしますね。 全社展開するとかじゃなくて、現場が必要としているものを調べるために見に行くように感じる。
それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
> それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
現場のいうことを丸のみすると、とんでもない高コストかつ低品質になるのよ。これ常識。
・汎用性、拡張性、ソフトウェアアーキテクチャのしっかりしたソフトウェアを作るのは時間と金とスキルが要る。だからパッケージソフトとして広く販売することで原価を回収する。・しかし、業務というのは会社それぞれであり、全く同じ業務をしている会社など存在しない。・業務をパッケージソフトに合わせるように変更する方が、結果として低コスト、高品質になる。・業務をパッケージソフトに沿うように変更する、パッケージソフトを業務に沿うようにカスタマイズする、そのベストなトレードオフ点を見つけるのが、最も大変な仕事。・だけど、業務とシステムの両方に精通する人が居ないので、だいたい破綻する。
普通の組織では業務分析やって候補のパッケージとFit&Gap分析して、合わないところをどうするか検討すると思うんだけど(情報処理技術者試験のテキストとか見るとね)、うちのところは「パッケージはこれ。あとば現場で何かしろ」とやって、密接に関連する業務システム同士のデータ連携とか、必須の業務をどうするかといったことも要件からすっぱり落ちてた。 挙げ句の果てが導入したパッケージでカバーしていないところはEUCでやれ、だって。 当然、導入計画時にはその業務をEUCでやれるかどうかの検討もしてない。 異動でそういう状況を引き継いで、今、追い詰められてる。
大企業になると業務遂行してる人は基本的に忙しく、Fit&Gap分析やるのは業務をあまり知らない情報部門が業務部門に頭下げてヒアリングしながらやるので、結果として実務に耐えないシステムが出来上がるんですよね。結局の所新システムいらねってなるけど、結果的にそれでも会社は回ってるのでほんとにいらないのかも。DXとか幻想
謎技術を生まないことは重要だけど、「初めから本格的に」という考え方が今回のような失敗を生むこともある。システムが肥大化し過ぎて、容易なはずの修正・機能追加が困難になってしまった場合だ。 最初はとにかくシンプルさを重視した作りにしておいて、重要
かなエクセルを必要な機能のプロトタイプとして、システム化やり直しが正解でしょうね。
最悪言語のVBAよりクソな言語で書かれたのか?とか
視察に来たシステム担当部署が引き取ればいいけど、社員個人が作ったソフトを業務に組み込むとロクなことにならなさそう。色々な部署の奴が自分の業務部署に特化したVBAを構築して、人づてに他部署に展開されて同じようなことをするExcel VBAが複数系統出回るとか。
あと業者のシステムが駄目だったのかもしれないけれど、業務をソフトに合わせずソフトを業務に合わせようとして末端の社員が「つかえねー」と言っているのかもしれない(まあフロー改訂してない管理部署やマネージャー層が悪いけど)
リンク先でツイ主がコメントしてるけど、「その場のノリで作った」と言う一方で「システムを内製すること自体が課せられた仕事」らしいから課内で仕様決めやら試験やらしてるかもしれませんよ
……知らんけど
VBAで作れるようなシステムを数億円の予算をつけて外注してしまったことでは?
# お役所仕事かな
他社でも使えるような汎用性を持たせたシステム、という点から数億かけて作ったのはEXCELに当たる部分だと思われ。会社ごとの業務要件定義はその汎用システム上でもすぐ作成できる。ただし、EXCELのVBAほど粒度のこまかいカスタマイズはできませんでしたという感じがするが。
そんなにその汎用システムを作ったのが愚かなことかという点に疑問が残るな。
F35 「汎用性を持たせて高価になるのは当然だぞ」
実際F35はベストセラー機になりましたねぇ
他に選択肢無いですしね。
あれって一太郎とかマイクロソフトオフィスみたいな感じで遠目には同じだけど中身は全部別々みたいな状態だし…
規模が違うであろうシステムを並べて安定性を比較してるところ。
公表されている情報が少なく、問題を分析するのは難しいね。
言語周辺のテクノロジよりも全体のシステム設計の方が重要度が高いのは確かだが、かといってVBAは厄介だ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
問題点の整理 (スコア:1)
入門書レベルのVBAで作った野良システムが普通に実稼働してるところかな?
Re:問題点の整理 (スコア:2, 興味深い)
いかにもこれから「VBAの情報商材をやります」ってプロフィールの人の「俺SUGEEEEEEE、VBAもSUGEEEEEEE」を真に受けちゃってるところでは。<問題点
事実無根とまでは言わないが、盛ってたり色々してないと、不自然な部分が多い。
Re: (スコア:0)
「東京本社システム部門トップが同氏の元に視察に来る」あたりの香ばしさも良いね
それはさておき、公式で作ったら色々と責任が発生してしまうサービスは
「あくまで現場のユーザが草の根で作って自己責任で使ってます」
というほうが出来が良くなることは往々にしてあるからなあ
どこぞの大学の単位選択フォームみたいな感じで
I/Fさえ守られればUIはどうぞ勝手に、というWebAPIシステムは強い
Re:問題点の整理 (スコア:1)
危険なニオイのする話ですよね…。
システムは作ったら終わりじゃないんですよ、不具合修正はもちろんですが
機能の追加変更などいろいろあるし、これらがスムーズにできなければ技術的負債一直線です。
最初のバージョンを作るのはちゃんとシステムエンジニアリングの経験を積んだところじゃないといけない。
逆に最初にキチンと作っていれば例え一時期動作が不安定でも修正は容易ですし
いずれ機能追加や次システムへの流用を考える時になれば嫌でも有り難みがわかってくるものです。
こういう話を聞くとどうしても某動画サービスのことを思い出して不安な気持ちになります。
3日で作られたそのサービスは年月がたつうちに複雑化し、バージョンアップもまともにできなくなり、
今では利用者は低迷してYoutubeに並ぶとか考える人もいなくなりました。(一時期ホントに言ってたんですよ)
私はこの件のシステムは知りませんし、安定稼働とやらをどのレベルで実現しているのかわかりませんが
視察に来るというシステム部門トップの人にはとにかく冷静な判断をしてほしいところです…。
Re:問題点の整理 (スコア:2)
>視察に来るというシステム部門トップの人
原幅に不評なシステムが問題になっている時、現場で好評な自作プログラムがあったとしたら、私ならどういう機能要件なのか参考にしますね。
全社展開するとかじゃなくて、現場が必要としているものを調べるために見に行くように感じる。
それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
Re:問題点の整理 (スコア:1)
> それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
現場のいうことを丸のみすると、とんでもない高コストかつ低品質になるのよ。これ常識。
・汎用性、拡張性、ソフトウェアアーキテクチャのしっかりしたソフトウェアを作るのは時間と金とスキルが要る。だからパッケージソフトとして広く販売することで原価を回収する。
・しかし、業務というのは会社それぞれであり、全く同じ業務をしている会社など存在しない。
・業務をパッケージソフトに合わせるように変更する方が、結果として低コスト、高品質になる。
・業務をパッケージソフトに沿うように変更する、パッケージソフトを業務に沿うようにカスタマイズする、そのベストなトレードオフ点を見つけるのが、最も大変な仕事。
・だけど、業務とシステムの両方に精通する人が居ないので、だいたい破綻する。
Re:問題点の整理 (スコア:4, 興味深い)
普通の組織では業務分析やって候補のパッケージとFit&Gap分析して、合わないところをどうするか検討すると思うんだけど(情報処理技術者試験のテキストとか見るとね)、うちのところは「パッケージはこれ。あとば現場で何かしろ」とやって、密接に関連する業務システム同士のデータ連携とか、必須の業務をどうするかといったことも要件からすっぱり落ちてた。
挙げ句の果てが導入したパッケージでカバーしていないところはEUCでやれ、だって。
当然、導入計画時にはその業務をEUCでやれるかどうかの検討もしてない。
異動でそういう状況を引き継いで、今、追い詰められてる。
Re: (スコア:0)
大企業になると業務遂行してる人は基本的に忙しく、Fit&Gap分析やるのは業務をあまり知らない情報部門が業務部門に頭下げてヒアリングしながらやるので、結果として実務に耐えないシステムが出来上がるんですよね。
結局の所新システムいらねってなるけど、結果的にそれでも会社は回ってるのでほんとにいらないのかも。
DXとか幻想
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)
実際F35はベストセラー機になりましたねぇ
Re: (スコア:0)
他に選択肢無いですしね。
Re: (スコア:0)
あれって一太郎とかマイクロソフトオフィスみたいな感じで遠目には同じだけど中身は全部別々みたいな状態だし…
Re: (スコア:0)
規模が違うであろうシステムを並べて安定性を比較してるところ。
Re: (スコア:0)
公表されている情報が少なく、問題を分析するのは難しいね。
言語周辺のテクノロジよりも全体のシステム設計の方が重要度が高いのは確かだが、かといってVBAは厄介だ。