アカウント名:
パスワード:
ちょっと考えてみましたが、そのプログラムで何をするかによるかもしれません。ちょっとお題から外れてしまうかもしれませんが…。
お堅い業務システムであれば、システム目的の実現が第一であることと、保守性に重点を置いた言い回しになるでしょう。個人の趣味や勉強なら、実装の仕方は拙くても良いので、パッションが導くままにとにかく形にすることに重点を置く言い方になるでしょう。
ただ、いずれにせよ使用する言語やフレームワークから少々離れた視点で、そのプログラムでは結局何を実現したいのかや、そのプログラムはどう動くべきかをコーディング前にしっかり把握して理解するように、とは言うと思います。
実現しなければならないこと・やりたいことが先にあって、特定のプログラミング言語やフレームワークは目的の実現に向けた一手段でしかないことはしっかりと意識させたいです。問題にぶつかった時に、自分が使っているプログラミング言語・フレームワークの範囲内でしか解決策を考えられないと、たこつぼ的なはまり方をするようになってしまうかもしれませんし。
どーも！ この前、職歴30年にして初めてトレーナーをやれと言われて、思いついたことを書きました。
＞特定のプログラミング言語やフレームワークは目的の実現に向けた一手段でしかないですが、手段の対義語たる目的を起点とした開発手法はどれもはかばかしくない様に思えてならないのです。シーズの無い所に芽を出そうとさすのが土台無理に見えてなりません。目的だー言っている人間は無能を糊塗しているだけにも見えます。 なにか、自然現象に準ずる論理の限界が有るのかも知れないと疑っています。 ですので、自分が初めてゆうことは、「手段」を起点とする事になります。もちろん「目的」は見据えないといけないですが、そんな意図です。
私も最近プログラミング初心者への社内講義をするようになったので、このお題にあるようなことは考えるようになりました。私としてはやはり目的重視です。まあ、お互いの立ち位置というか信念というか、その辺りは当然異なりますので、SIer出身で今もシステム構築・運用保守を生業とする私としては、そう考えるということです。
目的と言ってもレベルの高低はあります。情報システムの構築を例に取れば、高いレベルではシステムで達成すべき業務改善なり新しいビジネスの成功ですし、低い(というのは少々語弊がありますが)レベルでは特定モジュールで実装すべき機能の
SIerこそ、手段・プログラミング擁護のチャンピオンの様に思うのですが、逆なのでしょうか？（そしてSEは低レベル手段・プログラミング擁護のチャンピオン）そして、Antiプログラミングの多い日本だからこそ、擁護者が必要でSIer・SEは根深く、なかなかに無くならないのだと思うのですが。 中の人が逆に言っているがゆえにプログラマー志望者に伝わらないのでは無いでしょうか？
作ってみないと（手段）何をするものなのか（目的）語れないがゆえに、プログラミングの場合は手段は目的に先行するという主張です。SIerの方は、散々手段を作りためて「目的」だーと言っているだけに思えてならないのです。
間違っていますかね？
結論から言うと間違いです。正確に言うならば、SIer/SEと荒く話をされても正直言って困ってしまうのです。その人の置かれている状況によりますので。だから私は「立ち位置や信念は異なるが」と最初に書きました。以下も、かつてのSIerとしての立場で書きます。
SIerがSEに提示するシステム構築の手段には様々なものがあり、SEの視点からは「こんなもの使っていられるか」というのもあります。実際、私もSIerとしての制約の中で、システム構築の最前線で実際に設計・コーディング・テストをする立場でもありましたから、そういうことは良く分かりますし、SEの皆さんへは申し訳なく感じてもいました。
それでも、私が長年携わってきたシステム構築・運用保守において、手段が目的に先行してはならないというのが「私の」信念です。エンドユーザーがシステムに期待する目的が達成できなければ、技術的・審美的に優れたいかなる手段を用いたとしても失敗PJであり、「SIerとしては」ここは譲れません。
私の認識では、誤解を恐れず言ってしまえばプログラミングはシステムの目的を実現するための一手段・一工程でしかなく、その工程に参加するSE(≒プログラマー)にはシステムの目的をまず理解してもらわなければなりません。その理解がなければ、自分が担当する機能がなぜあるのか、どう動くべきなのかが本質的に理解できないままとなり、悪く言えば「仕様どおりに私は作りました。ほう、障害が発生したのですか? でも私は悪くありません」となります。
ですが、システム構築に参加していただく上では、それでは困るのです。SEにはプログラミングのスペシャリストとしてのアウトプットを当然求めますが、それは直接的なアウトプットであるコードそのものだけではなく、私が前のコメントで記述した視点も当然含まれるのです。
だから、私は相手がプログラマー志望者であっても、常に目的を忘れず、目的からずれることなくSEとしての自分のミッションを果たしてもらうべく、最初に高いレベル・低いレベルの両視点での目的の大切さを伝えたいのです。スペシャリストである以上は相手が期待するアウトプットを出せることは当然ですし、さらに高い付加価値を付けられる能力・視点がその人の財産になる、と「私は」思っています。
＞スペシャリストである以上は相手が期待するアウトプットを出せることは当然ですし、＞さらに高い付加価値を付けられる能力・視点がその人の財産になる、と「私は」＞思っています。本当にSIerはこう思っているのでしょうか？ プログラミングはそれほど豊潤な世界だとは思えません。出来る事が非常に限られているのです。 ＞「仕様どおりに私は作りました。ほう、障害が発生したのですか? でも私は悪くありません」この様な事にならない為には、出来ない事（シーズの無い事）は受けるべきでは有りません。 ＞システムの目的をまず理解してもらわなければなりません。だから目的を理解したら実現できるのかと言えば、その様な事は有り得ません。目的はいくらでも膨らませる事が可能でしょうけれど、それとプログラミングとは無関係です。その様に「自分は」思い、それに即した「初めに言う事」を考えました。 もちろん顧客の思いつくすべての目的を実現できる手段が有るというのなら最高ですが、無いと「自分は」思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
うーん (スコア:2)
ちょっと考えてみましたが、そのプログラムで何をするかによるかもしれません。ちょっとお題から外れてしまうかもしれませんが…。
お堅い業務システムであれば、システム目的の実現が第一であることと、保守性に重点を置いた言い回しになるでしょう。個人の趣味や勉強なら、実装の仕方は拙くても良いので、パッションが導くままにとにかく形にすることに重点を置く言い方になるでしょう。
ただ、いずれにせよ使用する言語やフレームワークから少々離れた視点で、そのプログラムでは結局何を実現したいのかや、そのプログラムはどう動くべきかをコーディング前にしっかり把握して理解するように、とは言うと思います。
実現しなければならないこと・やりたいことが先にあって、特定のプログラミング言語やフレームワークは目的の実現に向けた一手段でしかないことはしっかりと意識させたいです。問題にぶつかった時に、自分が使っているプログラミング言語・フレームワークの範囲内でしか解決策を考えられないと、たこつぼ的なはまり方をするようになってしまうかもしれませんし。
Re: (スコア:1)
どーも！
この前、職歴30年にして初めてトレーナーをやれと言われて、思いついたことを書きました。
＞特定のプログラミング言語やフレームワークは目的の実現に向けた一手段でしかない
ですが、手段の対義語たる目的を起点とした開発手法はどれもはかばかしくない様に
思えてならないのです。シーズの無い所に芽を出そうとさすのが土台無理に見えて
なりません。目的だー言っている人間は無能を糊塗しているだけにも見えます。
なにか、自然現象に準ずる論理の限界が有るのかも知れないと疑っています。
ですので、自分が初めてゆうことは、「手段」を起点とする事になります。
もちろん「目的」は見据えないといけないですが、そんな意図です。
Re: (スコア:1)
私も最近プログラミング初心者への社内講義をするようになったので、このお題にあるようなことは考えるようになりました。私としてはやはり目的重視です。まあ、お互いの立ち位置というか信念というか、その辺りは当然異なりますので、SIer出身で今もシステム構築・運用保守を生業とする私としては、そう考えるということです。
目的と言ってもレベルの高低はあります。情報システムの構築を例に取れば、高いレベルではシステムで達成すべき業務改善なり新しいビジネスの成功ですし、低い(というのは少々語弊がありますが)レベルでは特定モジュールで実装すべき機能の
Re: (スコア:1)
SIerこそ、手段・プログラミング擁護のチャンピオンの様に思うのですが、
逆なのでしょうか？
（そしてSEは低レベル手段・プログラミング擁護のチャンピオン）
そして、Antiプログラミングの多い日本だからこそ、擁護者が必要で
SIer・SEは根深く、なかなかに無くならないのだと思うのですが。
中の人が逆に言っているがゆえにプログラマー志望者に伝わらないのでは
無いでしょうか？
作ってみないと（手段）何をするものなのか（目的）語れないがゆえに、
プログラミングの場合は手段は目的に先行するという主張です。
SIerの方は、散々手段を作りためて「目的」だーと言っているだけ
に思えてならないのです。
間違っていますかね？
Re:うーん (スコア:1)
結論から言うと間違いです。正確に言うならば、SIer/SEと荒く話をされても正直言って困ってしまうのです。その人の置かれている状況によりますので。だから私は「立ち位置や信念は異なるが」と最初に書きました。以下も、かつてのSIerとしての立場で書きます。
SIerがSEに提示するシステム構築の手段には様々なものがあり、SEの視点からは「こんなもの使っていられるか」というのもあります。実際、私もSIerとしての制約の中で、システム構築の最前線で実際に設計・コーディング・テストをする立場でもありましたから、そういうことは良く分かりますし、SEの皆さんへは申し訳なく感じてもいました。
それでも、私が長年携わってきたシステム構築・運用保守において、手段が目的に先行してはならないというのが「私の」信念です。エンドユーザーがシステムに期待する目的が達成できなければ、技術的・審美的に優れたいかなる手段を用いたとしても失敗PJであり、「SIerとしては」ここは譲れません。
私の認識では、誤解を恐れず言ってしまえばプログラミングはシステムの目的を実現するための一手段・一工程でしかなく、その工程に参加するSE(≒プログラマー)にはシステムの目的をまず理解してもらわなければなりません。その理解がなければ、自分が担当する機能がなぜあるのか、どう動くべきなのかが本質的に理解できないままとなり、悪く言えば「仕様どおりに私は作りました。ほう、障害が発生したのですか? でも私は悪くありません」となります。
ですが、システム構築に参加していただく上では、それでは困るのです。SEにはプログラミングのスペシャリストとしてのアウトプットを当然求めますが、それは直接的なアウトプットであるコードそのものだけではなく、私が前のコメントで記述した視点も当然含まれるのです。
だから、私は相手がプログラマー志望者であっても、常に目的を忘れず、目的からずれることなくSEとしての自分のミッションを果たしてもらうべく、最初に高いレベル・低いレベルの両視点での目的の大切さを伝えたいのです。スペシャリストである以上は相手が期待するアウトプットを出せることは当然ですし、さらに高い付加価値を付けられる能力・視点がその人の財産になる、と「私は」思っています。
Re:うーん (スコア:1)
＞スペシャリストである以上は相手が期待するアウトプットを出せることは当然ですし、
＞さらに高い付加価値を付けられる能力・視点がその人の財産になる、と「私は」
＞思っています。
本当にSIerはこう思っているのでしょうか？ プログラミングはそれほど豊潤な世界だ
とは思えません。出来る事が非常に限られているのです。
＞「仕様どおりに私は作りました。ほう、障害が発生したのですか? でも私は悪くありません」
この様な事にならない為には、出来ない事（シーズの無い事）は受けるべきでは有りません。
＞システムの目的をまず理解してもらわなければなりません。
だから目的を理解したら実現できるのかと言えば、その様な事は有り得ません。
目的はいくらでも膨らませる事が可能でしょうけれど、それとプログラミングとは
無関係です。
その様に「自分は」思い、それに即した「初めに言う事」を考えました。
もちろん顧客の思いつくすべての目的を実現できる手段が有るというのなら最高ですが、
無いと「自分は」思います。