アカウント名:
パスワード:
入門書レベルのVBAで作った野良システムが普通に実稼働してるところかな？
危険なニオイのする話ですよね…｡システムは作ったら終わりじゃないんですよ､不具合修正はもちろんですが機能の追加変更などいろいろあるし､これらがスムーズにできなければ技術的負債一直線です｡
最初のバージョンを作るのはちゃんとシステムエンジニアリングの経験を積んだところじゃないといけない｡逆に最初にキチンと作っていれば例え一時期動作が不安定でも修正は容易ですしいずれ機能追加や次システムへの流用を考える時になれば嫌でも有り難みがわかってくるものです｡
こういう話を聞くとどうしても某動画サービスのことを思い出して不安な気持ちになります｡3日で作られたそのサービスは年月がたつうちに複雑化し､バージョンアップもまともにできなくなり､今では利用者は低迷してYoutubeに並ぶとか考える人もいなくなりました｡(一時期ホントに言ってたんですよ)
私はこの件のシステムは知りませんし､安定稼働とやらをどのレベルで実現しているのかわかりませんが視察に来るというシステム部門トップの人にはとにかく冷静な判断をしてほしいところです…｡
>視察に来るというシステム部門トップの人
原幅に不評なシステムが問題になっている時、現場で好評な自作プログラムがあったとしたら、私ならどういう機能要件なのか参考にしますね。 全社展開するとかじゃなくて、現場が必要としているものを調べるために見に行くように感じる。
それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
＞ それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
現場のいうことを丸のみすると、とんでもない高コストかつ低品質になるのよ。これ常識。
・汎用性、拡張性、ソフトウェアアーキテクチャのしっかりしたソフトウェアを作るのは時間と金とスキルが要る。だからパッケージソフトとして広く販売することで原価を回収する。・しかし、業務というのは会社それぞれであり、全く同じ業務をしている会社など存在しない。・業務をパッケージソフトに合わせるように変更する方が、結果として低コスト、高品質になる。・業務をパッケージソフトに沿うように変更する、パッケージソフトを業務に沿うようにカスタマイズする、そのベストなトレードオフ点を見つけるのが、最も大変な仕事。・だけど、業務とシステムの両方に精通する人が居ないので、だいたい破綻する。
普通の組織では業務分析やって候補のパッケージとFit&Gap分析して、合わないところをどうするか検討すると思うんだけど（情報処理技術者試験のテキストとか見るとね）、うちのところは「パッケージはこれ。あとば現場で何かしろ」とやって、密接に関連する業務システム同士のデータ連携とか、必須の業務をどうするかといったことも要件からすっぱり落ちてた。 挙げ句の果てが導入したパッケージでカバーしていないところはEUCでやれ、だって。 当然、導入計画時にはその業務をEUCでやれるかどうかの検討もしてない。 異動でそういう状況を引き継いで、今、追い詰められてる。
大企業になると業務遂行してる人は基本的に忙しく、Fit&Gap分析やるのは業務をあまり知らない情報部門が業務部門に頭下げてヒアリングしながらやるので、結果として実務に耐えないシステムが出来上がるんですよね。結局の所新システムいらねってなるけど、結果的にそれでも会社は回ってるのでほんとにいらないのかも。DXとか幻想
謎技術を生まないことは重要だけど、「初めから本格的に」という考え方が今回のような失敗を生むこともある。システムが肥大化し過ぎて、容易なはずの修正・機能追加が困難になってしまった場合だ。 最初はとにかくシンプルさを重視した作りにしておいて、重要
かなエクセルを必要な機能のプロトタイプとして、システム化やり直しが正解でしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
問題点の整理 (スコア:1)
入門書レベルのVBAで作った野良システムが普通に実稼働してるところかな？
Re:問題点の整理 (スコア:1)
危険なニオイのする話ですよね…｡
システムは作ったら終わりじゃないんですよ､不具合修正はもちろんですが
機能の追加変更などいろいろあるし､これらがスムーズにできなければ技術的負債一直線です｡
最初のバージョンを作るのはちゃんとシステムエンジニアリングの経験を積んだところじゃないといけない｡
逆に最初にキチンと作っていれば例え一時期動作が不安定でも修正は容易ですし
いずれ機能追加や次システムへの流用を考える時になれば嫌でも有り難みがわかってくるものです｡
こういう話を聞くとどうしても某動画サービスのことを思い出して不安な気持ちになります｡
3日で作られたそのサービスは年月がたつうちに複雑化し､バージョンアップもまともにできなくなり､
今では利用者は低迷してYoutubeに並ぶとか考える人もいなくなりました｡(一時期ホントに言ってたんですよ)
私はこの件のシステムは知りませんし､安定稼働とやらをどのレベルで実現しているのかわかりませんが
視察に来るというシステム部門トップの人にはとにかく冷静な判断をしてほしいところです…｡
Re:問題点の整理 (スコア:2)
>視察に来るというシステム部門トップの人
原幅に不評なシステムが問題になっている時、現場で好評な自作プログラムがあったとしたら、私ならどういう機能要件なのか参考にしますね。
全社展開するとかじゃなくて、現場が必要としているものを調べるために見に行くように感じる。
それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
Re:問題点の整理 (スコア:1)
＞ それにつけてもシステム導入計画をする部門は、業務分析とか現場の状況とかきちんと把握してから計画を立ててほしいものだ。
現場のいうことを丸のみすると、とんでもない高コストかつ低品質になるのよ。これ常識。
・汎用性、拡張性、ソフトウェアアーキテクチャのしっかりしたソフトウェアを作るのは時間と金とスキルが要る。だからパッケージソフトとして広く販売することで原価を回収する。
・しかし、業務というのは会社それぞれであり、全く同じ業務をしている会社など存在しない。
・業務をパッケージソフトに合わせるように変更する方が、結果として低コスト、高品質になる。
・業務をパッケージソフトに沿うように変更する、パッケージソフトを業務に沿うようにカスタマイズする、そのベストなトレードオフ点を見つけるのが、最も大変な仕事。
・だけど、業務とシステムの両方に精通する人が居ないので、だいたい破綻する。
Re:問題点の整理 (スコア:4, 興味深い)
普通の組織では業務分析やって候補のパッケージとFit&Gap分析して、合わないところをどうするか検討すると思うんだけど（情報処理技術者試験のテキストとか見るとね）、うちのところは「パッケージはこれ。あとば現場で何かしろ」とやって、密接に関連する業務システム同士のデータ連携とか、必須の業務をどうするかといったことも要件からすっぱり落ちてた。
挙げ句の果てが導入したパッケージでカバーしていないところはEUCでやれ、だって。
当然、導入計画時にはその業務をEUCでやれるかどうかの検討もしてない。
異動でそういう状況を引き継いで、今、追い詰められてる。
Re: (スコア:0)
大企業になると業務遂行してる人は基本的に忙しく、Fit&Gap分析やるのは業務をあまり知らない情報部門が業務部門に頭下げてヒアリングしながらやるので、結果として実務に耐えないシステムが出来上がるんですよね。
結局の所新システムいらねってなるけど、結果的にそれでも会社は回ってるのでほんとにいらないのかも。
DXとか幻想
Re: (スコア:0)
謎技術を生まないことは重要だけど、「初めから本格的に」という考え方が今回のような失敗を生むこともある。システムが肥大化し過ぎて、容易なはずの修正・機能追加が困難になってしまった場合だ。
最初はとにかくシンプルさを重視した作りにしておいて、重要
Re: (スコア:0)
かなエクセルを必要な機能のプロトタイプとして、システム化やり直しが正解でしょうね。