アカウント名:
パスワード:
これからは、読み書き同様にプログラミングが出来る事は、出来て当たり前になるのでは? 数学的なセンスが不要な業務改系のプログラミングとかは、サラリーマンとしては当然のスキルになるんじゃないかと思う。
>数学的なセンスが不要な業務改系のプログラミングとかは、サラリーマンとしては当然のスキルになるんじゃないかと思う
属人化加速してカオスな現場になりませんように。
属人化してカオスになりかねないのは、今まではExcelワークシート。これからの時代はRPAだと思う。
こいつらに比べたら、合間にコメントを書き加えられるプログラムって、断然理解しやすい。ただしExcelマクロは除く。これは本当に邪悪だと思う。
Excel職人が手作業でゴニョゴニョやっていた処理を、Powershell で自動化することをやりました。学習コストは高かったけど、そこそこいいものが作れましたよ。
データ(Excel)とロジック(Powershell)の分離もできていいことづくめでした。PowershellからVBAの関数も全て使う事もできますし。ロジックは別途管理出来るので、保守性も良かったです。
ExcelとPerlの組合せでもうまくいきますよ。流行りのPythonはまどろっこく感じてしまって...
Excelマクロって、VBAが今時のプログラマ向けじゃないとか、プログラムがExcelファイルの中に入るのがプログラマ向けじゃないとか、VBEが今時のプログラマ向けじゃないとか文句が沢山思いつくけど、VSCodeでNodeでElectronアプリ作るのと比べればnpmの有無の他はそう違わない気もするけどなあ
npmが今時かって?その議論は私はしたくない
プログラム自体が操作対象データ内に格納されているという点に置いては、素人にも管理しやすい仕組みだと思うぞ。それに、実際の現場では手作業で別のファイル・シートにコピペするような作業が大量にあったりするから、簡単なマクロでそういったことが自動化できるのはとても良いことだ。
VBAは書けるけど本格的なプログラム言語は無理って言う人は結構いますが、同じ処理を書くとしたら他の言語よりVBAのほうが難しいのでは、と思いますね。というかVBEを使って書いてる時点で一周回って尊敬できますよ。たまに頼まれてVBAも弄りますが、VBEが吐き気を催すレベルで酷い。
VBAとVBEはね、ちょっと書いて回してExcelで動作確認して継ぎ足して、っていう素人開発のやり方が楽に出来るんですよ。バージョンコントロールが必要になるレベルのものはぜっっっっっっったいに書きたくないけど。
20年近く前にVBAガチ盛りのExcelベースのソリューションを受注して書かされたことがあるけど、その時はVBAのソースだけ個別にぶっこ抜いてVSSで管理してました。今やるとしたらやっぱりVBAのソースだけぶっこ抜いて……まあ、gitで管理するんでしょうね。やったね、SCMの部分は進歩してるよ!(乾いた笑い
Excelは殆どの事務用PCに入っていますが、自作プログラム・専用プログラム・開発環境は、情報部門がインストールを禁ずる事は珍しくありません。故にExcelVBAが作られ使われる面もある。
どういう地獄が発生しているか想像がつかない幸せな方のようなので解説します。※「幸せな方」というのは皮肉ではなく羨望から出る言葉です。
IT屋に限らず、多くの企業では共有フォルダからローカルにコピーしてきたExcelファイルを更新したり、そのExcelファイルをメールで同僚や別部署へ送信して入力してもらったりということが当たり前に行われています。これは中小企業だけでなく数万人を擁する大企業でも見聞きします。歴史的経緯でシート1~10は主に部署Aが、シート11~20は主に部署Bが更新するといった形に業務が収斂していっ
RPAという新たなブラックボックスは負の遺産でしか無い
ちょうど、今日、RPAが動かなくなったと問い合わせがきたわ。出力されるHTMLが少し変わっただけ何だが。
RPA使うのは勝手だが、こっちは動作保証なんかしてねーよ。
Razerの左手キーボード(Orbweaver、キーボードマクロアプリ付き)を愛用して居ます。(静音版(多分ピンク軸)がUSでしか売って居なかったので、購入はWebで日本語で出来ましたが、 送料が本体と同程度かかりました。)
1. 個人の情報を入力後、2. Ent XXXXXX Ent 20210801 Ent Ent 20991231 Ent Entを毎回入力しなければならない。(50人分)なんて時に、2.を左手キーボード1押しで終わるのが助かります。
Excelもマクロより直感的(キーボードのタブとかCtlr+DとかF2とか←とかの模倣が可能)なので、愛用して居ます。
皆がプログラミングできる前提なら他人の作ったものが弄れなくなったら自分で作り直せばいいだけじゃないの。それで少なくとも手作業のころより悪化はしないでしょ。
「皆がプログラミングできる前提」なら、手作業でできることはプログラム化し直すことはできる。しかし、「属人化」というのは、その人にしか解らなくなる、ということ。つまり、その人以外は、手作業で処理できなくなる。その場合、プログラムは書けない。
属人化されたプログラムであれば、最悪それを読むことで手作業化もしくは再プログラム化できる。けど、他人の書いたプログラムを読むのって、難しい場合も多いよね。いや、なんなら自分の書いたプログラムですら、イミフなときが…
>その人以外は、手作業で処理できなくなる。
まさに、春先から、それの対応しているところです。 関係団体から送られてくる業務データを、前任者まではExcelで処理していたんだけど、担当者個人がその関係団体から送られてくるデータ処理を一手に引き受けていた。 どういうデータが、どういうタイミングで送られてきて、どう処理するのか、簡単な箇条書きしか無くて、前任者に聞いても具体的な手順の説明はないし、関係団体に問い合わせたり、Excelファイルを調べたりして、やっとワークフローを整理して、資料と処理用データベースを作成したところ。 で、私なりの状況分析だけど、まず流れてくる業務データは、それ用のシステムがあることを前提にしている。なので、素人がExcelで手作業で何とかするようなものじゃない。データ構造自体は、プログラムをかける人だったら、なんてことは無いんだけど、素人が見たらAccessの標準機能では対応できなくて、表計算で手集計するしか思いつかないようなもの。量が少なかったら、手作業でもいいんだろうけど、使うデータの種類も多いし、データ量が何千件も毎月あるんだよね。 このため、前任者にしてみたら「業務を説明」と求められても、毎月の作業を説明するのは大変なのだろうなと(おそらく明確な流れとか意識しない)。 ただ、流れてくる業務データをデータベースに格納できたら、業務で使うデータを明示できるし、業務を論理的に説明しやすくなるので、Accessで処理用データベースを作成してます。
>他人の書いたプログラムを読むのって、難しい場合も多いよね。
これは定石に沿うことで回避するしかないと思いますね。 わかりやすい構造にする、内容がわかりやすい名前をつける、コメントで処理の説明を随時つけるとか。 特に具体的なコードは、参考書を見ればわかるレベルで書く必要がありますね。 エラー処理とか、付加機能とかで、本来の流れが見えにくくなると、自分の書いたものでもわからなくなる。
でも、業務に必要なプログラムやデータベースなら、専門家が作るべきですよね。 規模が大きい組織なら、そういうスタッフを抱えてもいいと思うんだけど。 現場でプロトタイプを作って使ってみて、ある程度経ってきたら、開発スタッフと共同で要件を整理して作り直すとかしないとブラックボックスになるだろうし、臨機応変に開発できないと時代に対応できなくなるし。 私が一番やばいと思うのは、開発経験が無い連中が、システム更新を担当すると要件のもれとか、移行作業の検討がすっぽり落ちてるとかあること。挙句に必要な業務がすっぽり抜けてたとかもあるし。 後始末をやらされて、ほんとひどい目に遭ってます・・・。
問題を一気に解決する魔法の言葉をさずけよう。
てんしょく
君は、文章が長く冗長だよ。
そう? 必要十分な内容が書かれていると思ったけど。
読む人の立場になって見られないの?
読む人の立場に立つと、「君は日本語すらw」はどう見えるの?
長さがどうこうよりも、「まず結論から話せ」って部分じゃないの。テクニカルライティングのスキルだよ。論文もそうだよね。最初にAbstractを書く。軍事や医療の世界だと、「SBAR」という会話プロトコルが規定されている。https://knowledge.nurse-senka.jp/1652/ [nurse-senka.jp]
>読む人の立場になって見られないの?>>プログラムだって、いかに簡潔に、誰が見ても保守し易いようにコード化出来るかで能力>が現れるのに、君は日本語すらw
一行目が三行目を否定しているのが素晴らしい皮肉
元コメが5スコアで、これが0スコアという時点で、どちらが有益だったか一目瞭然。恥ずかしすぎるコメだな。
伝えたいことなんて僅かなのに、その長文が必要十分だと思った?今この瞬間に死ぬ可能性もあるという人生で「絶対的な貴重資源である時間」を奪うという罪を理解しているのかな。
「君は日本語すらw」は、無駄な長文を書く愚者になるなと読む人の心へ訴えかける、正に必要十分にな嫌味だね。
今この瞬間に死ぬ可能性もあるという人生で「絶対的な貴重資源である時間」を奪うという罪
そこまで時間が貴重だとほざくような奴は、こんなぐだるような場末の雑談サイトには来ない。「君は日本語すらw」なんて無意味で間抜けな文字列を書く時間すら惜しむだろう。
お前の時間奪われすぎでしょマゾなの?
今この瞬間に死ぬ可能性もあるという人生で「絶対的な貴重資源である時間」を奪うという罪を理解しているのかな。
そう思うなら、読まないと言う自由はあると言うのに、キミには判断力が無いのか?つか、いつも瞬殺される苦情を書くキミの手間も無駄じゃね?てかキミ、そーゆー無駄が好きなんだろ? 正直になりなよ。キミがツインテールなメガネっ娘でもない限り、そんなツンデレでは嫌われるだけだぞ。
家庭ではともかく、ビジネスではタイムイズマネーだよ。職場でむやみに他人の時間を奪ってはいけない。まず結論から話せと。
スラドにコメントすることもそれを読むこともビジネスではありません。
そういうときは、タレコミツリーじゃなく、スラドの日記帳のほうを使いましょう。他人に読んでもらうmanもRFCも、フォーマットがある。
「絶対的な貴重資源である時間」を気にする奴がスラドなんか見るなよw
やっぱ、具象から抽象を導き出す能力は、全く無い、どうやっても身につかない人も沢山いるので、「それが有るタレントの邪魔をしない」程度の策しか無いのでしょうね。過去の自分の書いたイミフを何とか出来るのも、その能力だけですし、、、
程度にも寄るけど、ある程度のところでまともな所に外注して整理して貰った方が良い。
それも、「今日それが使えないと仕事が回らないツール」が無数に乱立してて、ツール間を場当たり的に繋ぐツールがまたいっぱいあって、という状態に陥ってたらもう手遅れで、それをどう整理しようとしても、みずほ銀行にしかならなくなってしまう。
あとまあ、ファイアウォールとVPNでがっちがちに固めた上で、データベースとかはちゃんと金を出してセキュアに設計した環境から始めないと死ぬ。「みんなが善意で使ってる限りはちゃんと動くツール」と安全で堅牢なソフトウェアの間の溝は年々幅が広がっていく一方で、最新の知識を追ってるその手の専門家で無いと越えられない。
外注してもいいけど、発注元の部署は一箇所に集約しないと同じことになるよ。統制が出来ていないなら同じことになる。
ローカルで動く要件が緩い短時間で書けるプログラムなら何の問題も無いと思うけどね。意図的に迷惑をかけるようなやり方ならともかく、その程度の属人化は問題視すべきではない。ただし優秀過ぎて換えが効かない場合に限る。
下手に外注に仕事をまわしてしまったらプログラムをブラックボックス化し「メンテナンス、修正はうちが続けます。だからうちにお金を払い続けてください」となる。
もちろん契約次第ではあるけど
「属人化」がなぜ起こるかを考えてみ? ・改善すべき業務の核が見えていない状態で改善に着手 ・中途半端な理解のまま例外に逐次対応して、つぎはぎだらけのコードになる
なので、サラリーマンの多くがプログラムに慣れてくれば ・業務改善をみんなに使ってもらう ・プログラムを組織で育てるとなり、属人化しにくくなるんよ。#4105506の考えてとしては。
ただし想定通りにはいかないこともあって、あんたの考えてるシナリオは ・業務改善を悪とみなすクズが跋扈しているので、広まらない ・個々が自分のプログラムを育てる。後のことなんてシラネーこんなもんだろ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
プログラミングは出来て当然になると思う。 (スコア:5, すばらしい洞察)
これからは、読み書き同様にプログラミングが出来る事は、出来て当たり前になるのでは?
数学的なセンスが不要な業務改系のプログラミングとかは、サラリーマンとしては当然のスキルになるんじゃないかと思う。
Re:プログラミングは出来て当然になると思う。 (スコア:0)
>数学的なセンスが不要な業務改系のプログラミングとかは、サラリーマンとしては当然のスキルになるんじゃないかと思う
属人化加速してカオスな現場になりませんように。
Re:プログラミングは出来て当然になると思う。 (スコア:5, すばらしい洞察)
属人化してカオスになりかねないのは、今まではExcelワークシート。
これからの時代はRPAだと思う。
こいつらに比べたら、合間にコメントを書き加えられるプログラムって、断然理解しやすい。
ただしExcelマクロは除く。これは本当に邪悪だと思う。
Re:プログラミングは出来て当然になると思う。 (スコア:2, すばらしい洞察)
Excel職人が手作業でゴニョゴニョやっていた処理を、
Powershell で自動化することをやりました。
学習コストは高かったけど、そこそこいいものが作れましたよ。
データ(Excel)とロジック(Powershell)の分離もできていいことづくめでした。
PowershellからVBAの関数も全て使う事もできますし。
ロジックは別途管理出来るので、保守性も良かったです。
Re: (スコア:0)
ExcelとPerlの組合せでもうまくいきますよ。流行りのPythonはまどろっこく感じてしまって...
Re:プログラミングは出来て当然になると思う。 (スコア:1)
Excelマクロって、VBAが今時のプログラマ向けじゃないとか、プログラムがExcelファイルの中に入るのがプログラマ向けじゃないとか、VBEが今時のプログラマ向けじゃないとか文句が沢山思いつくけど、
VSCodeでNodeでElectronアプリ作るのと比べればnpmの有無の他はそう違わない気もするけどなあ
npmが今時かって?その議論は私はしたくない
Re: (スコア:0)
プログラム自体が操作対象データ内に格納されているという点に置いては、素人にも管理しやすい仕組みだと思うぞ。
それに、実際の現場では手作業で別のファイル・シートにコピペするような作業が大量にあったりするから、
簡単なマクロでそういったことが自動化できるのはとても良いことだ。
Re: (スコア:0)
VBAは書けるけど本格的なプログラム言語は無理って言う人は結構いますが、同じ処理を書くとしたら他の言語よりVBAのほうが難しいのでは、と思いますね。
というかVBEを使って書いてる時点で一周回って尊敬できますよ。たまに頼まれてVBAも弄りますが、VBEが吐き気を催すレベルで酷い。
Re: (スコア:0)
VBAとVBEはね、ちょっと書いて回してExcelで動作確認して継ぎ足して、っていう素人開発のやり方が楽に出来るんですよ。
バージョンコントロールが必要になるレベルのものはぜっっっっっっったいに書きたくないけど。
20年近く前にVBAガチ盛りのExcelベースのソリューションを受注して書かされたことがあるけど、その時はVBAのソースだけ個別にぶっこ抜いてVSSで管理してました。
今やるとしたらやっぱりVBAのソースだけぶっこ抜いて……まあ、gitで管理するんでしょうね。やったね、SCMの部分は進歩してるよ!(乾いた笑い
Re: (スコア:0)
Excelは殆どの事務用PCに入っていますが、自作プログラム・専用プログラム・開発環境は、情報部門がインストールを禁ずる事は珍しくありません。
故にExcelVBAが作られ使われる面もある。
Re: (スコア:0)
どういう地獄が発生しているか想像がつかない幸せな方のようなので解説します。
※「幸せな方」というのは皮肉ではなく羨望から出る言葉です。
IT屋に限らず、多くの企業では共有フォルダからローカルにコピーしてきたExcelファイルを更新したり、
そのExcelファイルをメールで同僚や別部署へ送信して入力してもらったりということが当たり前に行われています。
これは中小企業だけでなく数万人を擁する大企業でも見聞きします。
歴史的経緯でシート1~10は主に部署Aが、シート11~20は主に部署Bが更新するといった形に業務が収斂していっ
Re: (スコア:0)
RPAという新たなブラックボックスは負の遺産でしか無い
Re: (スコア:0)
ちょうど、今日、RPAが動かなくなったと問い合わせがきたわ。
出力されるHTMLが少し変わっただけ何だが。
RPA使うのは勝手だが、こっちは動作保証なんかしてねーよ。
Re: (スコア:0)
Razerの左手キーボード(Orbweaver、キーボードマクロアプリ付き)を愛用して居ます。
(静音版(多分ピンク軸)がUSでしか売って居なかったので、購入はWebで日本語で出来ましたが、
送料が本体と同程度かかりました。)
1. 個人の情報を入力後、
2. Ent XXXXXX Ent 20210801 Ent Ent 20991231 Ent Ent
を毎回入力しなければならない。(50人分)
なんて時に、2.を左手キーボード1押しで終わるのが助かります。
Excelもマクロより直感的(キーボードのタブとかCtlr+DとかF2とか←とかの模倣が可能)なので、
愛用して居ます。
Re: (スコア:0)
キーボードだけじゃなくマウスもエミュレーションして(ただし座標は絶対位置指定で)画面上のボタンを押す等の自動化もしてます。
Re: (スコア:0)
皆がプログラミングできる前提なら他人の作ったものが弄れなくなったら自分で作り直せばいいだけじゃないの。
それで少なくとも手作業のころより悪化はしないでしょ。
Re:プログラミングは出来て当然になると思う。 (スコア:2)
「皆がプログラミングできる前提」なら、手作業でできることはプログラム化し直すことはできる。
しかし、「属人化」というのは、その人にしか解らなくなる、ということ。
つまり、その人以外は、手作業で処理できなくなる。
その場合、プログラムは書けない。
属人化されたプログラムであれば、最悪それを読むことで手作業化もしくは再プログラム化できる。
けど、他人の書いたプログラムを読むのって、難しい場合も多いよね。
いや、なんなら自分の書いたプログラムですら、イミフなときが…
Re:プログラミングは出来て当然になると思う。 (スコア:5, 参考になる)
>その人以外は、手作業で処理できなくなる。
まさに、春先から、それの対応しているところです。
関係団体から送られてくる業務データを、前任者まではExcelで処理していたんだけど、担当者個人がその関係団体から送られてくるデータ処理を一手に引き受けていた。
どういうデータが、どういうタイミングで送られてきて、どう処理するのか、簡単な箇条書きしか無くて、前任者に聞いても具体的な手順の説明はないし、関係団体に問い合わせたり、Excelファイルを調べたりして、やっとワークフローを整理して、資料と処理用データベースを作成したところ。
で、私なりの状況分析だけど、まず流れてくる業務データは、それ用のシステムがあることを前提にしている。なので、素人がExcelで手作業で何とかするようなものじゃない。データ構造自体は、プログラムをかける人だったら、なんてことは無いんだけど、素人が見たらAccessの標準機能では対応できなくて、表計算で手集計するしか思いつかないようなもの。量が少なかったら、手作業でもいいんだろうけど、使うデータの種類も多いし、データ量が何千件も毎月あるんだよね。
このため、前任者にしてみたら「業務を説明」と求められても、毎月の作業を説明するのは大変なのだろうなと(おそらく明確な流れとか意識しない)。
ただ、流れてくる業務データをデータベースに格納できたら、業務で使うデータを明示できるし、業務を論理的に説明しやすくなるので、Accessで処理用データベースを作成してます。
>他人の書いたプログラムを読むのって、難しい場合も多いよね。
これは定石に沿うことで回避するしかないと思いますね。
わかりやすい構造にする、内容がわかりやすい名前をつける、コメントで処理の説明を随時つけるとか。
特に具体的なコードは、参考書を見ればわかるレベルで書く必要がありますね。
エラー処理とか、付加機能とかで、本来の流れが見えにくくなると、自分の書いたものでもわからなくなる。
でも、業務に必要なプログラムやデータベースなら、専門家が作るべきですよね。
規模が大きい組織なら、そういうスタッフを抱えてもいいと思うんだけど。
現場でプロトタイプを作って使ってみて、ある程度経ってきたら、開発スタッフと共同で要件を整理して作り直すとかしないとブラックボックスになるだろうし、臨機応変に開発できないと時代に対応できなくなるし。
私が一番やばいと思うのは、開発経験が無い連中が、システム更新を担当すると要件のもれとか、移行作業の検討がすっぽり落ちてるとかあること。挙句に必要な業務がすっぽり抜けてたとかもあるし。
後始末をやらされて、ほんとひどい目に遭ってます・・・。
Re: (スコア:0)
問題を一気に解決する魔法の言葉をさずけよう。
てんしょく
Re: (スコア:0)
君は、文章が長く冗長だよ。
そう? 必要十分な内容が書かれていると思ったけど。
読む人の立場になって見られないの?
読む人の立場に立つと、「君は日本語すらw」はどう見えるの?
Re: (スコア:0)
長さがどうこうよりも、「まず結論から話せ」って部分じゃないの。テクニカルライティングのスキルだよ。
論文もそうだよね。最初にAbstractを書く。
軍事や医療の世界だと、「SBAR」という会話プロトコルが規定されている。
https://knowledge.nurse-senka.jp/1652/ [nurse-senka.jp]
Re: (スコア:0)
>読む人の立場になって見られないの?
>
>プログラムだって、いかに簡潔に、誰が見ても保守し易いようにコード化出来るかで能力
>が現れるのに、君は日本語すらw
一行目が三行目を否定しているのが素晴らしい皮肉
Re: (スコア:0)
元コメが5スコアで、これが0スコアという時点で、どちらが有益だったか一目瞭然。恥ずかしすぎるコメだな。
Re: (スコア:0)
伝えたいことなんて僅かなのに、その長文が必要十分だと思った?
今この瞬間に死ぬ可能性もあるという人生で「絶対的な貴重資源である時間」を奪うという罪を理解しているのかな。
「君は日本語すらw」は、無駄な長文を書く愚者になるなと読む人の心へ訴えかける、正に必要十分にな嫌味だね。
Re: (スコア:0)
今この瞬間に死ぬ可能性もあるという人生で「絶対的な貴重資源である時間」を奪うという罪
そこまで時間が貴重だとほざくような奴は、こんなぐだるような場末の雑談サイトには来ない。
「君は日本語すらw」なんて無意味で間抜けな文字列を書く時間すら惜しむだろう。
Re: (スコア:0)
お前の時間奪われすぎでしょ
マゾなの?
Re: (スコア:0)
今この瞬間に死ぬ可能性もあるという人生で「絶対的な貴重資源である時間」を奪うという罪を理解しているのかな。
そう思うなら、読まないと言う自由はあると言うのに、キミには判断力が無いのか?
つか、いつも瞬殺される苦情を書くキミの手間も無駄じゃね?
てかキミ、そーゆー無駄が好きなんだろ? 正直になりなよ。
キミがツインテールなメガネっ娘でもない限り、そんなツンデレでは嫌われるだけだぞ。
Re: (スコア:0)
家庭ではともかく、ビジネスではタイムイズマネーだよ。
職場でむやみに他人の時間を奪ってはいけない。まず結論から話せと。
Re: (スコア:0)
スラドにコメントすることもそれを読むこともビジネスではありません。
Re: (スコア:0)
そういうときは、タレコミツリーじゃなく、スラドの日記帳のほうを使いましょう。
他人に読んでもらうmanもRFCも、フォーマットがある。
Re: (スコア:0)
「絶対的な貴重資源である時間」を気にする奴がスラドなんか見るなよw
Re: (スコア:0)
行数あたりに換算すれば少しは意味のある数値になるかもしらんねw
Re:プログラミングは出来て当然になると思う。 (スコア:2)
やっぱ、具象から抽象を導き出す能力は、全く無い、どうやっても身につかない人も沢山いるので、
「それが有るタレントの邪魔をしない」程度の策しか無いのでしょうね。
過去の自分の書いたイミフを何とか出来るのも、その能力だけですし、、、
Re:プログラミングは出来て当然になると思う。 (スコア:1)
程度にも寄るけど、ある程度のところでまともな所に外注して整理して貰った方が良い。
それも、「今日それが使えないと仕事が回らないツール」が無数に乱立してて、
ツール間を場当たり的に繋ぐツールがまたいっぱいあって、という状態に陥ってたらもう手遅れで、
それをどう整理しようとしても、みずほ銀行にしかならなくなってしまう。
あとまあ、ファイアウォールとVPNでがっちがちに固めた上で、
データベースとかはちゃんと金を出してセキュアに設計した環境から始めないと死ぬ。
「みんなが善意で使ってる限りはちゃんと動くツール」と安全で堅牢なソフトウェアの間の溝は年々幅が広がっていく一方で、
最新の知識を追ってるその手の専門家で無いと越えられない。
Re: (スコア:0)
外注してもいいけど、発注元の部署は一箇所に集約しないと同じことになるよ。統制が出来ていないなら同じことになる。
Re: (スコア:0)
ローカルで動く要件が緩い短時間で書けるプログラムなら何の問題も無いと思うけどね。意図的に迷惑をかけるようなやり方ならともかく、その程度の属人化は問題視すべきではない。ただし優秀過ぎて換えが効かない場合に限る。
外注は簡単に仕事を手放そうとしない (スコア:0)
下手に外注に仕事をまわしてしまったらプログラムをブラックボックス化し「メンテナンス、修正はうちが続けます。だからうちにお金を払い続けてください」となる。
もちろん契約次第ではあるけど
Re: (スコア:0)
属人化を排除して人を入れ替えるのはその上司の仕事
Re: (スコア:0)
「属人化」がなぜ起こるかを考えてみ?
・改善すべき業務の核が見えていない状態で改善に着手
・中途半端な理解のまま例外に逐次対応して、つぎはぎだらけのコードになる
なので、サラリーマンの多くがプログラムに慣れてくれば
・業務改善をみんなに使ってもらう
・プログラムを組織で育てる
となり、属人化しにくくなるんよ。#4105506の考えてとしては。
ただし想定通りにはいかないこともあって、あんたの考えてるシナリオは
・業務改善を悪とみなすクズが跋扈しているので、広まらない
・個々が自分のプログラムを育てる。後のことなんてシラネー
こんなもんだろ。