アカウント名:
パスワード:
完成物を受け取る前提での契約は、バグや機能追加前提で随時修正することの多い最近の開発業態とは相性が悪いことは確かにある。でもCOCOAに関しては納品物のチェックなしに（未完成品を）完成品として受け取っていた。アジャイルだ相性だとはまったく別次元の問題だよ。
行政側に、仕様決めや完成品のテストができる人材が足りてなきゃ、ウォーターフォールだろうがアジャイルだろうが無理。
行政側に、仕様決めや完成品のテストができる人材がいなければ発注してはいけない、という認識は間違ってないか。行政は政策と国民のニーズに基づいて「こういう機能のものがほしい」と要求と予算を割り当てるプロであって、エンジニアリングの専門家ではない。その要求に基づきシステムの仕様を決め構築し要求を満たすことを確認するところまでがSIerの仕事であるべきだと思うのだが。
# まあ、現実はそうなってないよね。
「こういう機能のものがほしい」と要求する能力とは「仕様決めや完成品のテスト」をする能力に他ならない
アジャイル開発は、ユーザー側の当事者意識の低さを徐々に高めていくという性質もあるのでよい手法だと思うのです。
ちゃんと辛抱強く付き合っていく気があるならそうなのかもしれないが……。できる？
お金さえ貰えばね。
道路工事とかはできるのに？
まあこういう反論が来るだろうなとは思ってました。できる人がいない、できないからやってはいけないわけではない。いやできないならやらないほうがいいが。だができないからできるようになっていけないわけではない。実際道路工事の背景にはいわゆる都市計画がありここは行政がやってる。あなたが行政の仕事ではないと主張することをやってるわけだ。そういう意味での道路工事はやってるのにというコメント。
黒部ダムとか青函トンネル作るときの日本てそんなんだっけ？システム一般の話をしていたつもりがココア限定の話だった？ああ言えば上祐も死語か。
中身はブラックボックスでいいんだよ。要求した仕様を満たしているかを判断する能力は業務の理解力だけ。エンジニアリング能力はまったく別の話。そこをごっちゃにして思考停止する人間があまりにも多すぎる。
業務の理解力
それを誰に求めるかというと…
発注者ですよね？今ある業務の意味を知ってるのは業務をしている側だけです。エンジニアは業務とシステム制約上のギャップにどう対処すべきかを検討することはあっても本来の業務要件を策定するのは発注者の責務ですよ。
こういう業務分掌を盾にぶっちゃけやる気のない「発注者」も「エンジニア」も消えゆく運命なんだろうと思う。
業務を知り尽くした上で、必要だと思えば必要だと思った奴が一気にプロトタイプまで書き上げて、どうしても足らない部分だけは高度なエンジニアを頼るって時代がすぐそこまで来てると思うんだけどね。規模が大きくなればその「最初に書いた奴」がそのままPMになる。
その気になればクラウド使って1人で大規模システム作れる時代なのに、「○○は担当外なので知りません」「○○はお見積りに含まれていません」とかほざく奴は生き残れない。
だから自社でエンジニア抱えて自社開発が流行りつつあったりするんだろ。あくまで外注開発の話してるのに勝手に前提置き換えてやる気が無いとか意味不明。
外注であっても同じだよ。業務システムの開発は業務知らないと話にならないし違法だと言われようが現実問題として偽装請負案件だと「発注者の社員と同じレベル」で業務を知らない者は役に立たない。
いずれ「外注」はまとめて切る時代が来るが、その時に自社採用するエンジニアをどこから採用するか？って話になれば当然「元外注先」だろう。その時に引き抜いてもらえるか、案件失った所属企業と一緒に沈むかって人生の分岐点が来る。
現在の話といずれの話をごっちゃにしてからまれても困ります。ビジネススキームが変わっても業務のやり方変えない人がいるならそりゃただの無能でしょ。議論にもならない。
今のスキームでもぐちゃぐちゃうるさい外注は担当変えてくれって営業に「相談」するな。売られた奴隷は奴隷の立場くらい理解した方がいい。
予算を決めるにはエンジニアリングもある程度わかってないとできないのでは？
間違っていない。自分は専門家ではない、なんて堂々と言うのは日本くらい。海外の行政側には皆ITのプロがいて、しっかりチェックしている。自ら開発すらしている。
ちなみに民間の企業においても、海外ではITのプロが在籍している場所はIT企業ではなく実業の企業の方が多い。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
それ以前の問題 (スコア:5, すばらしい洞察)
完成物を受け取る前提での契約は、バグや機能追加前提で随時修正することの多い最近の開発業態とは相性が悪いことは確かにある。
でもCOCOAに関しては納品物のチェックなしに（未完成品を）完成品として受け取っていた。アジャイルだ相性だとはまったく別次元の問題だよ。
Re: (スコア:4, すばらしい洞察)
行政側に、仕様決めや完成品のテストができる人材が足りてなきゃ、ウォーターフォールだろうがアジャイルだろうが無理。
Re:それ以前の問題 (スコア:1)
行政側に、仕様決めや完成品のテストができる人材がいなければ発注してはいけない、という認識は間違ってないか。
行政は政策と国民のニーズに基づいて「こういう機能のものがほしい」と要求と予算を割り当てるプロであって、エンジニアリングの専門家ではない。
その要求に基づきシステムの仕様を決め構築し要求を満たすことを確認するところまでがSIerの仕事であるべきだと思うのだが。
# まあ、現実はそうなってないよね。
Re: (スコア:0)
「こういう機能のものがほしい」と要求する能力とは「仕様決めや完成品のテスト」をする能力に他ならない
Re: (スコア:0)
ユーザー側の当事者意識の低さと、リテラシーの低さがネックだと思っている。
丸投げ体質ではうまくいかない分野なんだよね。
ユーザーが幼稚園生では上手く回らないんですよ。
アジャイル開発の利点 (スコア:0)
アジャイル開発は、ユーザー側の当事者意識の低さを徐々に高めていくという性質もあるのでよい手法だと思うのです。
Re: (スコア:0)
ちゃんと辛抱強く付き合っていく気があるならそうなのかもしれないが……。
できる？
Re: (スコア:0)
お金さえ貰えばね。
Re: (スコア:0)
道路工事とかはできるのに？
Re:それ以前の問題 (スコア:1)
別物なんですよね。
Re: (スコア:0)
まあこういう反論が来るだろうなとは思ってました。
できる人がいない、できないからやってはいけないわけではない。いやできないならやらないほうがいいが。
だができないからできるようになっていけないわけではない。実際道路工事の背景にはいわゆる都市計画がありここは行政がやってる。あなたが行政の仕事ではないと主張することをやってるわけだ。そういう意味での道路工事はやってるのにというコメント。
Re: (スコア:0)
それに対して接触アプリの専門家は大して居ないと思う。
工事の検査ができる技官は、市町村にいるけど、接触アプリの技官は、少なくとも開発時点では居なかった。
同じに捉えるのは乱暴と思うよ。
Re: (スコア:0)
黒部ダムとか青函トンネル作るときの日本てそんなんだっけ？システム一般の話をしていたつもりがココア限定の話だった？
ああ言えば上祐も死語か。
Re: (スコア:0)
巨大土木プロジェクトがあったとして、技術的に新規性が有り、ブレークスルーが必要な項目は全体共有できそうだが、ソフトウェアの場合、そういう専門的なことは言われても困るって対応されることが多い気がする。
抽象的な世界で、わずかな人数で構築可能なソフトウェアと、労働集約的な土木工事では、リテラシー教育をきちっとしないと認知できる範囲が異なるんだと思う。
アルジャイルな開発は知識共有的な意味でも有効じゃないのかな。
Re: (スコア:0)
中身はブラックボックスでいいんだよ。
要求した仕様を満たしているかを判断する能力は業務の理解力だけ。
エンジニアリング能力はまったく別の話。
そこをごっちゃにして思考停止する人間があまりにも多すぎる。
Re:それ以前の問題 (スコア:1)
それを誰に求めるかというと…
Re: (スコア:0)
発注者ですよね？今ある業務の意味を知ってるのは業務をしている側だけです。
エンジニアは業務とシステム制約上のギャップにどう対処すべきかを検討することはあっても
本来の業務要件を策定するのは発注者の責務ですよ。
Re:それ以前の問題 (スコア:1)
こういう業務分掌を盾にぶっちゃけやる気のない「発注者」も「エンジニア」も消えゆく運命なんだろうと思う。
業務を知り尽くした上で、必要だと思えば必要だと思った奴が一気にプロトタイプまで書き上げて、
どうしても足らない部分だけは高度なエンジニアを頼るって時代がすぐそこまで来てると思うんだけどね。
規模が大きくなればその「最初に書いた奴」がそのままPMになる。
その気になればクラウド使って1人で大規模システム作れる時代なのに、
「○○は担当外なので知りません」「○○はお見積りに含まれていません」とかほざく奴は生き残れない。
Re: (スコア:0)
だから自社でエンジニア抱えて自社開発が流行りつつあったりするんだろ。
あくまで外注開発の話してるのに勝手に前提置き換えてやる気が無いとか意味不明。
Re: (スコア:0)
外注であっても同じだよ。業務システムの開発は業務知らないと話にならないし
違法だと言われようが現実問題として偽装請負案件だと「発注者の社員と同じレベル」で
業務を知らない者は役に立たない。
いずれ「外注」はまとめて切る時代が来るが、その時に自社採用するエンジニアをどこから
採用するか？って話になれば当然「元外注先」だろう。
その時に引き抜いてもらえるか、案件失った所属企業と一緒に沈むかって人生の分岐点が来る。
Re: (スコア:0)
現在の話といずれの話をごっちゃにしてからまれても困ります。
ビジネススキームが変わっても業務のやり方変えない人がいるならそりゃただの無能でしょ。
議論にもならない。
Re: (スコア:0)
今のスキームでもぐちゃぐちゃうるさい外注は担当変えてくれって営業に「相談」するな。
売られた奴隷は奴隷の立場くらい理解した方がいい。
Re: (スコア:0)
一般論でいうと、システムが処理をおこなう手順には本来曖昧さが無いので、業務処理を分かっている人なら、どう動いているか説明を受ければ理解はできる。
その上で業務を知っているなら想定できる複雑な組合わせでの挙動について、開発者側に質問できる。
ただ、接触アプリは、業務上接触アプリみたいな仕事をやってる人は居ないでしょうから、それ事態新規性が高い業務と思うが。 厚労省の開発窓口担当者になったとして、大して自分の知見が生かせない業務で、中途半端に関わって失敗の責任をとらされるより、事前に複雑な開発で内部検証は不能という稟議をとっておく方が、処世術的には正しいと思うのでないかな。
Re: (スコア:0)
予算を決めるにはエンジニアリングもある程度わかってないとできないのでは？
Re: (スコア:0)
間違っていない。自分は専門家ではない、なんて堂々と言うのは日本くらい。海外の行政側には皆ITのプロがいて、しっかりチェックしている。自ら開発すらしている。
ちなみに民間の企業においても、海外ではITのプロが在籍している場所はIT企業ではなく実業の企業の方が多い。