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