アカウント名:
パスワード:
ローコード・ノーコードツールや分析ツールを導入するのはいいし、簡単な機能のものなら確かにサクッと作れる問題は「何を、何のために作るか」と「どういう運用にするのか」をちゃんと分析できる人がいるかどうか
今の業務を見直して、どれが自動化されたりWebアプリ化したら便利になるのかを切り出して、運用体型とメンテナンス体制を整えるこっちのほうが遥かに大変
そのツールがどこまでの問題をカバーするかの程度問題かと自分は考えますね
「個人が自分の抱えている問題を自分だけのために解決するツール」ということをこの「市民開発」が意味しているのなら運用・メンテナンス体制の困難さは考えるほどのものではなくなるかもしれません
ただしそのツールを同僚や上司部下にも使わせるとなると問題は雪だるま式に膨らみます自分の使い方では発生しないバグ､ズルをしているという冷たい目(信じられないかもしれないですが実際あります…)､予想もしていなかった追加機能の要望等など個人開発の成果物を他人に渡す怖いところは､最悪の場合これらの対応をすべて自分自身がなんのサポートも得られずに実施しなければならなくなるところです短縮したはずの工数はそれらの対応に食いつぶされて､上長からの評価も「なんかおもしろいやつ」になれば上々のほうで「妙な問題を持ち込む厄介者」になるかもわかりません
脈絡なく書いてしまいましたが､要は企業内での「個人開発」ならともかく「市民開発」(これはたぶん複数人でのつながりを意識しているのではないかと勝手に思うのですが)は極めて大きな困難を伴うということです全体的な問題を把握していて､それを解決する意思決定が可能で､その決定に責任を持てるような上長からの明確な指示がない限り自分はこのような開発には不安に感じてしまう､というのが正直な感想です
ある程度の量産やってる工場だと、工程の効率化とか変更で何か導入するとき、その影響範囲（数量とか出荷額とか）でレビューの範囲変えたり、FMEAの範囲決めてるでしょう。
ソフトウェアでも同じだと思うのだけど、なぜか影響範囲ではなく開発量でレビューのコスト決めてるように見えてしまう。簡単なソフトでも適用範囲広げるときには、別物として検討する必要があるよね。
ソフトウェアはそういう正式なエンジニアリングをアポロ計画くらいの時代に捨てたまんま取り戻してないから…
ソフトウェアは複雑度と影響波及でいえば簡単にロケットを超えるような代物で、大多数の組織はそもそも扱えるはずがないのです。
なのでまあ、元コメが考える正式なエンジニアリングとやらでなんとかなる、という認識がまずソフトウェア舐めてますね。
ソフトウェアだけ特別とか、ソフトウェアは別枠みたいな考え方の方が工学をなめてると思うけどね。
工場の大量生産とソフトウエアは股来の別物。ソフトウエア「だけ」別物ってわけでもないけど。
工学を嘗めてるというよりは、区別の付かない人の目が節穴なだけ。
現状がそうなのは分かるが、今後は市民開発者が80%とか主流になるということなんだから。そういう流れに逆らう会社は、競争力を失っていく運命にあるってことでしょう。余談だけど。派遣の給与テーブルを見ると、プログラミングできると時給が1.5倍ぐらいになるよね。ただし「できる」というレベル感が良く分からなかったが。
A「時給が上がったんだって､よかったなぁ今度焼き肉でもおごってくれよ」B「ありがとう､教えてもらったVBAのおかげで1日かかってた作業が5分で終わるようになったよ」A「教えた自分もうれしいよ､それで年収はいくらになったんだい？」B「おかげで5割増えて､年に手取りで150万円さ！年末には親と一緒に富山に旅行に行こうと思ってるんだ」
お後がよろしいようで
全然ジョークに見えない。日本はこんなにも貧しい。https://www.newsweekjapan.jp/stories/world/2021/10/post-97356.php [newsweekjapan.jp]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
本当に必要なのは業務分析の知識と経験 (スコア:1)
ローコード・ノーコードツールや分析ツールを導入するのはいいし、簡単な機能のものなら確かにサクッと作れる
問題は「何を、何のために作るか」と「どういう運用にするのか」をちゃんと分析できる人がいるかどうか
今の業務を見直して、どれが自動化されたりWebアプリ化したら便利になるのかを切り出して、運用体型とメンテナンス体制を整える
こっちのほうが遥かに大変
Re:本当に必要なのは業務分析の知識と経験 (スコア:1)
そのツールがどこまでの問題をカバーするかの程度問題かと自分は考えますね
「個人が自分の抱えている問題を自分だけのために解決するツール」ということをこの「市民開発」が意味しているのなら運用・メンテナンス体制の困難さは考えるほどのものではなくなるかもしれません
ただしそのツールを同僚や上司部下にも使わせるとなると問題は雪だるま式に膨らみます
自分の使い方では発生しないバグ､ズルをしているという冷たい目(信じられないかもしれないですが実際あります…)､予想もしていなかった追加機能の要望等など
個人開発の成果物を他人に渡す怖いところは､最悪の場合これらの対応をすべて自分自身がなんのサポートも得られずに実施しなければならなくなるところです
短縮したはずの工数はそれらの対応に食いつぶされて､上長からの評価も「なんかおもしろいやつ」になれば上々のほうで「妙な問題を持ち込む厄介者」になるかもわかりません
脈絡なく書いてしまいましたが､要は企業内での「個人開発」ならともかく「市民開発」(これはたぶん複数人でのつながりを意識しているのではないかと勝手に思うのですが)は極めて大きな困難を伴うということです
全体的な問題を把握していて､それを解決する意思決定が可能で､その決定に責任を持てるような上長からの明確な指示がない限り自分はこのような開発には不安に感じてしまう､というのが正直な感想です
Re: (スコア:0)
ある程度の量産やってる工場だと、工程の効率化とか変更で何か導入するとき、その影響範囲（数量とか出荷額とか）でレビューの範囲変えたり、FMEAの範囲決めてるでしょう。
ソフトウェアでも同じだと思うのだけど、なぜか影響範囲ではなく開発量でレビューのコスト決めてるように見えてしまう。
簡単なソフトでも適用範囲広げるときには、別物として検討する必要があるよね。
Re: (スコア:0)
ソフトウェアはそういう正式なエンジニアリングをアポロ計画くらいの時代に捨てたまんま取り戻してないから…
Re: (スコア:0)
ソフトウェアは複雑度と影響波及でいえば簡単にロケットを超えるような代物で、大多数の組織はそもそも扱えるはずがないのです。
なのでまあ、元コメが考える正式なエンジニアリングとやらでなんとかなる、という認識がまずソフトウェア舐めてますね。
Re: (スコア:0)
ソフトウェアだけ特別とか、ソフトウェアは別枠みたいな考え方の方が工学をなめてると思うけどね。
Re: (スコア:0)
工場の大量生産とソフトウエアは股来の別物。
ソフトウエア「だけ」別物ってわけでもないけど。
工学を嘗めてるというよりは、区別の付かない人の目が節穴なだけ。
Re: (スコア:0)
現状がそうなのは分かるが、今後は市民開発者が80%とか主流になるということなんだから。
そういう流れに逆らう会社は、競争力を失っていく運命にあるってことでしょう。
余談だけど。
派遣の給与テーブルを見ると、プログラミングできると時給が1.5倍ぐらいになるよね。
ただし「できる」というレベル感が良く分からなかったが。
Re: (スコア:0)
A「時給が上がったんだって､よかったなぁ今度焼き肉でもおごってくれよ」
B「ありがとう､教えてもらったVBAのおかげで1日かかってた作業が5分で終わるようになったよ」
A「教えた自分もうれしいよ､それで年収はいくらになったんだい？」
B「おかげで5割増えて､年に手取りで150万円さ！年末には親と一緒に富山に旅行に行こうと思ってるんだ」
お後がよろしいようで
Re: (スコア:0)
全然ジョークに見えない。
日本はこんなにも貧しい。
https://www.newsweekjapan.jp/stories/world/2021/10/post-97356.php [newsweekjapan.jp]