アカウント名:
パスワード:
プログラマー言うても、プログラミング言語を知っているだけの「コーダー」では、仕事を確保するという意味では、せいぜいやれることなんて限られているので年齢関係なくしんどいですけど、設計がきちんとできてコードも書けるようであれば、仕事を作り出すことも可能なので将来の仕事に関しては(己の力で切り開ける分)心配することもないんじゃないかなーと。
私の定義では、良いプログラマーとは良い設計ができる人で、設計とは物事を必要最小の仕事単位に適切に分割して再構築することで、それをするには論理的に物事を組み立てられるかどうかというセンスにかかっている割合が多いと思っています。
なので、チャンスがあるかどうかは、そういうセンスがあるかどうかですので、少しやってみて「いける」「いけない」の判断をすればよいかと。今までそういうことをせずに来てセンスを眠らせているorセンスに気づいていない人もいるかと思います。
それは典型的な依頼する方が常識だと思っているだけのことでは・・・?誰もがそういう仕事をしているわけではありませんよ。
自分の専門分野の常識は世間の常識ではないと気づいてないなら、そいつは専門家ではなくオタク。オタクとビジネスすると必ずトラブる。
何を「常識」とするかの問題ですね。発注側の「常識」は本当に常識なのか?発注者だけがそう思っている可能性はないか?よく見かける「発注側の「常識」をすべて汲み取るべき」と考える思考パターンかと思いますが、別の言葉で言えば、自他の差異に思考が及ばない状態を隠して受注側に責任をなすりつける態度とも言えます。
個々の例に関する議論(無論、どちらが正しいか?という判断も含めて)はさておき、こういう「正しいのはこっち。常識的に考えて、そっちの言い分がおかしい」というように対決姿勢をとってしまうと面倒なことになりますよね。経験豊富な諸氏の中にはこの時点で行進曲のイントロが聞こえる方もおられるのでは?
常識ではなく「業務知識」と呼ぶ方が角が立たないと思う。あらゆるプログラマが販売管理や売上管理の知識を持つべきという主張はSI屋の中では正しいかもしれないが一般化すべきではない。
逆に売上管理のシステム作るのにその辺の知識がない人があてがわれるケースも往々にしてあるだろうけど、それはご愁傷様としか。
9割が同じだとして、それが業界知識だとしてもそれを常識だから言わなくてもわかるというのは大きな問題ですね
大きなプロジェクトだと実際に会って気持ちを合わせることが不可欠なように本当にいいものは投げやりではけしてできないのです
発注側が受注側に対して行う「○○の知識を持っている」という仮定について、その検証を行なわないままプロジェクトを進めているのが問題です。
もし貴方がプロジェクトを管理する立場であれば、「受注側が○○の知識を持っていないかもしれない」という不確実性に対して、適切に対処していないということになります。「9割以上の〜」「それが、発注側の常識で、世間の常識じゃ無いと言いたいのでしょうか」といった発言から、省略可能な手順は可能な限り省略するというのが貴方の基本方針と理解しましたが、その省略がプロジェクト運営上の不確実性(リスク)を放置する結果につながるならばそれは仕事の手抜きです。そして「と、いうように、プログラムが書けても、常識が無い方が〜」からその原因を受注者の能力に求めているのが分かります。おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
貴方とはあまり仕事したくないですね……煽りではなく、本気で……
> おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
内容がカンタンなものなら、「できるかね?」という確認程度で済む場合もあります。たとえば、「○○へ行ってくる」「××から○○をもらってくる」というような内容ですね。ITの場合は、カンタンな能力テストなどを受けてもらったり、実績をみて判断するんじゃないでしょうかね。
「受注者の能力を確認」については、裁判などでは発注者側にそうした義務を認めることはほとんどないですよ。なぜなら、「できないもの」を「できる」と言って受注作業を行ったら、受発注以前の話(詐欺)になるからです。
お前外資と働いたことないだろ? 「常識コミでマニュアル化しろ」と言ってくるやつらだぞ。お前は外資ではレイオフ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
言語を知ってるだけでは意味がない (スコア:5, すばらしい洞察)
プログラマー言うても、プログラミング言語を知っているだけの「コーダー」では、仕事を確保するという意味では、せいぜいやれることなんて限られているので年齢関係なくしんどいですけど、設計がきちんとできてコードも書けるようであれば、仕事を作り出すことも可能なので将来の仕事に関しては(己の力で切り開ける分)心配することもないんじゃないかなーと。
私の定義では、良いプログラマーとは良い設計ができる人で、設計とは物事を必要最小の仕事単位に適切に分割して再構築することで、それをするには論理的に物事を組み立てられるかどうかというセンスにかかっている割合が多いと思っています。
なので、チャンスがあるかどうかは、そういうセンスがあるかどうかですので、少しやってみて「いける」「いけない」の判断をすればよいかと。今までそういうことをせずに来てセンスを眠らせているorセンスに気づいていない人もいるかと思います。
ほえほえ
Re:言語を知ってるだけでは意味がない (スコア:2)
正確には、依頼する方が常識だと思っている事はいちいち説明しないので、あとでトラブルになる事が多いです。
分割で支払われたら、領収書の金額は、その回に受け取った金額で、データベースにある、請求額と対応している入金額合計の項目から引かないで欲しいとか
領収金額の中には諸費税が含まれているとか
説明しなくても、領収書のサンプルが作れると、話していて安心できます。
昔、常識だろうと思っていて、できあがったものを見て愕然としたことが^^;
------------
惑星ケイロンまであと何マイル?
Re: (スコア:0)
それは典型的な依頼する方が常識だと思っているだけのことでは・・・?
誰もがそういう仕事をしているわけではありませんよ。
常識 (スコア:0)
自分の専門分野の常識は世間の常識ではないと気づいてないなら、そいつは専門家ではなくオタク。オタクとビジネスすると必ずトラブる。
Re: (スコア:0)
何を「常識」とするかの問題ですね。
発注側の「常識」は本当に常識なのか?発注者だけがそう思っている可能性はないか?
よく見かける「発注側の「常識」をすべて汲み取るべき」と考える思考パターンかと思いますが、
別の言葉で言えば、自他の差異に思考が及ばない状態を隠して受注側に責任をなすりつける態度とも言えます。
Re:言語を知ってるだけでは意味がない (スコア:1)
上記した事例については
日本国内で売上が上がる業種が特殊な業種と言うのでしょうか。
諸費税も非課税、不課税な費目をだけを扱う業界以外は対応していますが、そちらの方が特殊ですか。
感覚的に9割以上の業種が同じ対応をしているはずですが......
それが、発注側の常識で、世間の常識じゃ無いと言いたいのでしょうか。
と、いうように、プログラムが書けても、常識が無い方が多い業界なので、そのような知識を付けてゆくのは良いことだと思います。
------------
惑星ケイロンまであと何マイル?
Re:言語を知ってるだけでは意味がない (スコア:2, すばらしい洞察)
個々の例に関する議論(無論、どちらが正しいか?という判断も含めて)はさておき、
こういう「正しいのはこっち。常識的に考えて、そっちの言い分がおかしい」というように対決姿勢をとってしまうと面倒なことになりますよね。
経験豊富な諸氏の中にはこの時点で行進曲のイントロが聞こえる方もおられるのでは?
Re:言語を知ってるだけでは意味がない (スコア:1)
常識ではなく「業務知識」と呼ぶ方が角が立たないと思う。
あらゆるプログラマが販売管理や売上管理の知識を持つべきという主張は
SI屋の中では正しいかもしれないが一般化すべきではない。
逆に売上管理のシステム作るのにその辺の知識がない人が
あてがわれるケースも往々にしてあるだろうけど、
それはご愁傷様としか。
Re: (スコア:0)
9割が同じだとして、それが業界知識だとしても
それを常識だから言わなくてもわかるというのは大きな問題ですね
大きなプロジェクトだと実際に会って気持ちを合わせることが不可欠なように
本当にいいものは投げやりではけしてできないのです
Re: (スコア:0)
発注側が受注側に対して行う「○○の知識を持っている」という仮定について、その検証を行なわないままプロジェクトを進めているのが問題です。
もし貴方がプロジェクトを管理する立場であれば、「受注側が○○の知識を持っていないかもしれない」という不確実性に対して、適切に対処していないということになります。「9割以上の〜」「それが、発注側の常識で、世間の常識じゃ無いと言いたいのでしょうか」といった発言から、省略可能な手順は可能な限り省略するというのが貴方の基本方針と理解しましたが、その省略がプロジェクト運営上の不確実性(リスク)を放置する結果につながるならばそれは仕事の手抜きです。そして「と、いうように、プログラムが書けても、常識が無い方が〜」からその原因を受注者の能力に求めているのが分かります。おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
貴方とはあまり仕事したくないですね……煽りではなく、本気で……
Re:言語を知ってるだけでは意味がない (スコア:1)
あなたは、プロジェクト開始時に、部下や他社の人に常識力テストを行うのですか?
私もそんな方とはお仕事したくないですね
>省略可能な手順は可能な限り省略する
そんな話じゃないですよ
例えば、定型の封筒は最低料金が80円で送れる事を殆どの方が知っていると思いますが、そんなレベルの話ですよ
自分は業務で郵便出さないから、それは業務知識だよって言い切る感覚がズレてませんかと言いたいわけで......
いままでの人生で、領収書もらったことありませんか?
それでも判らなきゃ、聞き取りの席で確認しませんか。
聞かないので知ってるのだと思ってしまったのが私の敗因だとは思いますよ、無駄な時間を使ってしまったのは事実だし
この業界には、知っててもおかしくないレベルの事を知らなかったり、調べればすぐに判るのに、調べもしないで自分の非常識のまま仕事してなんの疑問も持たない方がいるという話です。
そんな方々と差別化して自分を売り込むのは難しく無いですよって言いたかっただけです。
------------
惑星ケイロンまであと何マイル?
Re: (スコア:0)
> おそらくは、貴方がプロジェクト開始前に受注者の能力を確認*しないで*、それで問題が起こった場合でも受注者のせいにするのでしょう。
内容がカンタンなものなら、「できるかね?」という確認程度で済む場合もあります。たとえば、「○○へ行ってくる」「××から○○をもらってくる」というような内容ですね。ITの場合は、カンタンな能力テストなどを受けてもらったり、実績をみて判断するんじゃないでしょうかね。
「受注者の能力を確認」については、裁判などでは発注者側にそうした義務を認めることはほとんどないですよ。なぜなら、「できないもの」を「できる」と言って受注作業を行ったら、受発注以前の話(詐欺)になるからです。
Re: (スコア:0)
お前外資と働いたことないだろ? 「常識コミでマニュアル化しろ」と言ってくるやつらだぞ。お前は外資ではレイオフ。