アカウント名:
パスワード:
完成物を受け取る前提での契約は、バグや機能追加前提で随時修正することの多い最近の開発業態とは相性が悪いことは確かにある。でもCOCOAに関しては納品物のチェックなしに（未完成品を）完成品として受け取っていた。アジャイルだ相性だとはまったく別次元の問題だよ。
行政側に、仕様決めや完成品のテストができる人材が足りてなきゃ、ウォーターフォールだろうがアジャイルだろうが無理。
行政側に、仕様決めや完成品のテストができる人材がいなければ発注してはいけない、という認識は間違ってないか。行政は政策と国民のニーズに基づいて「こういう機能のものがほしい」と要求と予算を割り当てるプロであって、エンジニアリングの専門家ではない。その要求に基づきシステムの仕様を決め構築し要求を満たすことを確認するところまでがSIerの仕事であるべきだと思うのだが。
# まあ、現実はそうなってないよね。
中身はブラックボックスでいいんだよ。要求した仕様を満たしているかを判断する能力は業務の理解力だけ。エンジニアリング能力はまったく別の話。そこをごっちゃにして思考停止する人間があまりにも多すぎる。
業務の理解力
それを誰に求めるかというと…
発注者ですよね？今ある業務の意味を知ってるのは業務をしている側だけです。エンジニアは業務とシステム制約上のギャップにどう対処すべきかを検討することはあっても本来の業務要件を策定するのは発注者の責務ですよ。
こういう業務分掌を盾にぶっちゃけやる気のない「発注者」も「エンジニア」も消えゆく運命なんだろうと思う。
業務を知り尽くした上で、必要だと思えば必要だと思った奴が一気にプロトタイプまで書き上げて、どうしても足らない部分だけは高度なエンジニアを頼るって時代がすぐそこまで来てると思うんだけどね。規模が大きくなればその「最初に書いた奴」がそのままPMになる。
その気になればクラウド使って1人で大規模システム作れる時代なのに、「○○は担当外なので知りません」「○○はお見積りに含まれていません」とかほざく奴は生き残れない。
だから自社でエンジニア抱えて自社開発が流行りつつあったりするんだろ。あくまで外注開発の話してるのに勝手に前提置き換えてやる気が無いとか意味不明。
外注であっても同じだよ。業務システムの開発は業務知らないと話にならないし違法だと言われようが現実問題として偽装請負案件だと「発注者の社員と同じレベル」で業務を知らない者は役に立たない。
いずれ「外注」はまとめて切る時代が来るが、その時に自社採用するエンジニアをどこから採用するか？って話になれば当然「元外注先」だろう。その時に引き抜いてもらえるか、案件失った所属企業と一緒に沈むかって人生の分岐点が来る。
現在の話といずれの話をごっちゃにしてからまれても困ります。ビジネススキームが変わっても業務のやり方変えない人がいるならそりゃただの無能でしょ。議論にもならない。
今のスキームでもぐちゃぐちゃうるさい外注は担当変えてくれって営業に「相談」するな。売られた奴隷は奴隷の立場くらい理解した方がいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
それ以前の問題 (スコア:5, すばらしい洞察)
完成物を受け取る前提での契約は、バグや機能追加前提で随時修正することの多い最近の開発業態とは相性が悪いことは確かにある。
でもCOCOAに関しては納品物のチェックなしに（未完成品を）完成品として受け取っていた。アジャイルだ相性だとはまったく別次元の問題だよ。
Re: (スコア:4, すばらしい洞察)
行政側に、仕様決めや完成品のテストができる人材が足りてなきゃ、ウォーターフォールだろうがアジャイルだろうが無理。
Re: (スコア:1)
行政側に、仕様決めや完成品のテストができる人材がいなければ発注してはいけない、という認識は間違ってないか。
行政は政策と国民のニーズに基づいて「こういう機能のものがほしい」と要求と予算を割り当てるプロであって、エンジニアリングの専門家ではない。
その要求に基づきシステムの仕様を決め構築し要求を満たすことを確認するところまでがSIerの仕事であるべきだと思うのだが。
# まあ、現実はそうなってないよね。
Re:それ以前の問題 (スコア:0)
中身はブラックボックスでいいんだよ。
要求した仕様を満たしているかを判断する能力は業務の理解力だけ。
エンジニアリング能力はまったく別の話。
そこをごっちゃにして思考停止する人間があまりにも多すぎる。
Re:それ以前の問題 (スコア:1)
それを誰に求めるかというと…
Re: (スコア:0)
発注者ですよね？今ある業務の意味を知ってるのは業務をしている側だけです。
エンジニアは業務とシステム制約上のギャップにどう対処すべきかを検討することはあっても
本来の業務要件を策定するのは発注者の責務ですよ。
Re:それ以前の問題 (スコア:1)
こういう業務分掌を盾にぶっちゃけやる気のない「発注者」も「エンジニア」も消えゆく運命なんだろうと思う。
業務を知り尽くした上で、必要だと思えば必要だと思った奴が一気にプロトタイプまで書き上げて、
どうしても足らない部分だけは高度なエンジニアを頼るって時代がすぐそこまで来てると思うんだけどね。
規模が大きくなればその「最初に書いた奴」がそのままPMになる。
その気になればクラウド使って1人で大規模システム作れる時代なのに、
「○○は担当外なので知りません」「○○はお見積りに含まれていません」とかほざく奴は生き残れない。
Re: (スコア:0)
だから自社でエンジニア抱えて自社開発が流行りつつあったりするんだろ。
あくまで外注開発の話してるのに勝手に前提置き換えてやる気が無いとか意味不明。
Re: (スコア:0)
外注であっても同じだよ。業務システムの開発は業務知らないと話にならないし
違法だと言われようが現実問題として偽装請負案件だと「発注者の社員と同じレベル」で
業務を知らない者は役に立たない。
いずれ「外注」はまとめて切る時代が来るが、その時に自社採用するエンジニアをどこから
採用するか？って話になれば当然「元外注先」だろう。
その時に引き抜いてもらえるか、案件失った所属企業と一緒に沈むかって人生の分岐点が来る。
Re: (スコア:0)
現在の話といずれの話をごっちゃにしてからまれても困ります。
ビジネススキームが変わっても業務のやり方変えない人がいるならそりゃただの無能でしょ。
議論にもならない。
Re: (スコア:0)
今のスキームでもぐちゃぐちゃうるさい外注は担当変えてくれって営業に「相談」するな。
売られた奴隷は奴隷の立場くらい理解した方がいい。
Re: (スコア:0)
一般論でいうと、システムが処理をおこなう手順には本来曖昧さが無いので、業務処理を分かっている人なら、どう動いているか説明を受ければ理解はできる。
その上で業務を知っているなら想定できる複雑な組合わせでの挙動について、開発者側に質問できる。
ただ、接触アプリは、業務上接触アプリみたいな仕事をやってる人は居ないでしょうから、それ事態新規性が高い業務と思うが。 厚労省の開発窓口担当者になったとして、大して自分の知見が生かせない業務で、中途半端に関わって失敗の責任をとらされるより、事前に複雑な開発で内部検証は不能という稟議をとっておく方が、処世術的には正しいと思うのでないかな。