アカウント名:
パスワード:
> 業務知識がなくてはまともな設計も実装も無理なんだろうな
そうですね…それは間違いないです。ちょっと論点がずれますが、自分としては、技術はあくまで問題解決のためにある、という視点は忘れてはならないものだと思っています。客先の業務知識を有していることは、問題解決のための必須事項という事で。技術の可能性を追い求めるのも大事だとは思いますが、自分としてはそれは専門の人に任せ、その成果を取捨選択して組み合わせて使わせてもらう立場なのかな、と。
非常に抽象的な物言いになってしまいますが、われわれ SIer に限らず「目先の問題に囚われず、真の問題解決方法を探究する姿勢」はどの職種でも大事ですよね。
# ま、こういうことを言い出して場を引っ掻き回すのは、TPO を選ばないとまずいですが…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
なぜ、の連鎖 (スコア:1)
> 業務知識がなくてはまともな設計も実装も無理なんだろうな
そうですね…それは間違いないです。ちょっと論点がずれますが、自分としては、技術はあくまで問題解決のためにある、という視点は忘れてはならないものだと思っています。客先の業務知識を有していることは、問題解決のための必須事項という事で。技術の可能性を追い求めるのも大事だとは思いますが、自分としてはそれは専門の人に任せ、その成果を取捨選択して組み合わせて使わせてもらう立場なのかな、と。
非常に抽象的な物言いになってしまいますが、われわれ SIer に限らず「目先の問題に囚われず、真の問題解決方法を探究する姿勢」はどの職種でも大事ですよね。
# ま、こういうことを言い出して場を引っ掻き回すのは、TPO を選ばないとまずいですが…。
連鎖が続くとばよえーん的ですま… (スコア:1)
どちらかというとSEが書いた仕様をもとにプログラムを書けというようなトップダウンアプローチ的開発よりも、現状の実装がこうなっているからこんな感じで作ってねというボトムアップアプローチ的開発ばっかりやってきた経緯があるので、設計書を理解するよりも業務とテーブルレイアウトを理解したほうが実装が早く進むという循環になっちゃってます。
おかげさまで上下両用の視点から見れる雑用系VBプログラマーになってしまったようですが。(^-^;;
履歴書に「とーきょーで3年ほどやってました」を書いたら、転職後の配属先部署も似たような仕事をやっていたり…んがふぐ。
# ゆえに肩書きだけプログラマには仕事が回せないという悪循環も。げふんげふん。