アカウント名:
パスワード:
アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない?
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
wikipedia参照ですまないが、 https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%... [wikipedia.org]
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきである
なんか、今までにない新しい事をしようとしている時には有効な開発手法だと思うけど、接触確認アプリのような、目的がはっきりしていて、他国でも作っているようなものにはむかない開発手法に思える。# まあ、仕事を請ける側にとっては責任範囲なんかがあいまいになって都合のいいのかもしれないが。
・他国で作っていようが本邦の発注側担当者にとってもベンダーにとっても新しい内容・いくら目的がはっきりしていても、UI/UXやらDB設計などの実現・表現手段が利用者の文化によっても規模によっても千差万別なので、他国の成果物は参考程度にしかならない
アジャイルについて何か勘違いしてないか?アジャイルの利点は素早く軌道修正してリスクを最小化できることだぞ。銀行のシステム変更みたいな超大規模プロジェクトなんかには向いてないだろうが、今回みたいな規模・性質のアプリにはまさに向いているように思えるが。
アジャイルの欠点は見積り辛い事なんだよ
アジャイルの見積もりなんていつの時代の話してんの
見積無しで発注は、さすがにヤバい。発注側、受注先双方ヤバい。
省庁の発注ではアジャイルは無理ですね。というかまともなシステム開発は無理。
・入札なので公示までには完璧な仕様書を非エンジニアの役人が作らなければいけない・政府調達、国際入札だと準備や公示期間に開発日程が喰われる・入札なので仕様に瑕疵があろうと契約後の変更は許されない・入札で落とした業者がスキル不足だと手取り足取り教えて作りあげさせなければいけない(できませんでした、だと発注者の責任も問われる)・単年度予算なので次年度予算がつくかわからない・単年度契約なので次年度に今年度と違う業者が横取りするかもしれない、今年度の業者が次年度継続せずに逃げるかもしれない。業者と発注者が二人三脚で、育てて育てられるということが本質的に不可能。
開発案件の入札と単年度契約の制度はほんと潰れてほしい。入札でこれだけ節約できたとかいうニュースを見るたび、その背後でどれだけのプロジェクトが入札のせいで氏んでいるか知ってるのかといいたくなる。
# さすがにAC
大変だね。
アジャイルは開発手法だから、現行制度でとりあえず発注できてその後に問題が露見するんだろうけど、より後発のDevOpsは開発者と運用者が一体じゃないといけなくてその制度じゃ発注しようがないっぽいから、DevOpsがナウなヤングにバカウケと大臣説得して社会制度を変えるしかなさそう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
自分の体験のみで恐縮だけど (スコア:0)
アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない?
Re: (スコア:0)
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。
もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。
Re: (スコア:1)
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
wikipedia参照ですまないが、
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%... [wikipedia.org]
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきである
Re: (スコア:0)
なんか、今までにない新しい事をしようとしている時には有効な開発手法だと思うけど、接触確認アプリのような、目的がはっきりしていて、他国でも作っているようなものにはむかない開発手法に思える。
# まあ、仕事を請ける側にとっては責任範囲なんかがあいまいになって都合のいいのかもしれないが。
Re: (スコア:0)
・他国で作っていようが本邦の発注側担当者にとってもベンダーにとっても新しい内容
・いくら目的がはっきりしていても、UI/UXやらDB設計などの実現・表現手段が利用者の文化によっても規模によっても千差万別なので、他国の成果物は参考程度にしかならない
アジャイルについて何か勘違いしてないか?
アジャイルの利点は素早く軌道修正してリスクを最小化できることだぞ。
銀行のシステム変更みたいな超大規模プロジェクトなんかには向いてないだろうが、今回みたいな規模・性質のアプリにはまさに向いているように思えるが。
Re: (スコア:0)
アジャイルの欠点は見積り辛い事なんだよ
Re: (スコア:0)
アジャイルの見積もりなんていつの時代の話してんの
Re:自分の体験のみで恐縮だけど (スコア:0)
見積無しで発注は、さすがにヤバい。
発注側、受注先双方ヤバい。
Re:自分の体験のみで恐縮だけど (スコア:1)
省庁の発注ではアジャイルは無理ですね。というかまともなシステム開発は無理。
・入札なので公示までには完璧な仕様書を非エンジニアの役人が作らなければいけない
・政府調達、国際入札だと準備や公示期間に開発日程が喰われる
・入札なので仕様に瑕疵があろうと契約後の変更は許されない
・入札で落とした業者がスキル不足だと手取り足取り教えて作りあげさせなければいけない(できませんでした、だと発注者の責任も問われる)
・単年度予算なので次年度予算がつくかわからない
・単年度契約なので次年度に今年度と違う業者が横取りするかもしれない、今年度の業者が次年度継続せずに逃げるかもしれない。業者と発注者が二人三脚で、育てて育てられるということが本質的に不可能。
開発案件の入札と単年度契約の制度はほんと潰れてほしい。入札でこれだけ節約できたとかいうニュースを見るたび、その背後でどれだけのプロジェクトが入札のせいで氏んでいるか知ってるのかといいたくなる。
# さすがにAC
Re: (スコア:0)
大変だね。
アジャイルは開発手法だから、現行制度でとりあえず発注できてその後に問題が露見するんだろうけど、
より後発のDevOpsは開発者と運用者が一体じゃないといけなくてその制度じゃ発注しようがないっぽいから、
DevOpsがナウなヤングにバカウケと大臣説得して社会制度を変えるしかなさそう