アカウント名:
パスワード:
アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない?
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
wikipedia参照ですまないが、https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%... [wikipedia.org]
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。この場合の関係者には、少なくともプログラマと「顧客」が含まれる
これが嫌がられるのよな。
この「文書よりも顔突き合わせて話し合い」っ点からしても多重下請け構造とは相性悪いんじゃないの
つまり下請け禁止、直接契約を義務付ければアジャイルでも事故りにくいと思うよ
でも一次請けするような会社には開発者はいないのよね
今孫請けの立場にいる会社に直接発注しろってことだよ
孫請けだろうが見積要るだろうが
なんか、今までにない新しい事をしようとしている時には有効な開発手法だと思うけど、接触確認アプリのような、目的がはっきりしていて、他国でも作っているようなものにはむかない開発手法に思える。# まあ、仕事を請ける側にとっては責任範囲なんかがあいまいになって都合のいいのかもしれないが。
COCOA開発当時、どの国も接触確認アプリは開発前もしくは開発中で、まさしく今までにない新しい事をしようとしている時だったんですが、それは……
そんなことはないよ。中国や台湾はとっくにできてた。
接触確認アプリの導入に係る各国の動向等について(令和2年5月8日)新型コロナウイルス感染症対策テックチーム事務局https://cio.go.jp/sites/default/files/uploads/documents/techteam_20200... [cio.go.jp]ここに当時の状況がまとまってますけど、独自に運用開始していたのは中国、インド、イスラエル、オーストラリア、シンガポールあたりですね。GoogleとAppleのEN API利用型は各国ヨーイドンです。
中国や台湾はとっくにできてたというか、一部の国以外全くできていないが正しいような。https://www.sbbit.jp/article/cont1/39190 [sbbit.jp]
この記事は去年の8月だけど、Google Appleのあるカリフォルニア州で導入されたのは12月になってから。結局誰も使ってない。
・他国で作っていようが本邦の発注側担当者にとってもベンダーにとっても新しい内容・いくら目的がはっきりしていても、UI/UXやらDB設計などの実現・表現手段が利用者の文化によっても規模によっても千差万別なので、他国の成果物は参考程度にしかならない
アジャイルについて何か勘違いしてないか?アジャイルの利点は素早く軌道修正してリスクを最小化できることだぞ。銀行のシステム変更みたいな超大規模プロジェクトなんかには向いてないだろうが、今回みたいな規模・性質のアプリにはまさに向いているように思えるが。
アジャイルの欠点は見積り辛い事なんだよ
アジャイルだと、そもそも「全体」の見積もりをしようとするのが概念的に誤り。道幅で3ヶ月くらいの見積もりしておいて、そこからローリングしていくのでいい。
経営が「全部でいくらかかるかわからないと判断できない」というのは、経営がモダンなビジネスに対応できてないってことなので、経営を取り替えるほうがよい。
アジャイルの見積もりなんていつの時代の話してんの
モック作って即リリース、クライアントが逃げ出さないようにして、継続してイテレーション回してチューチュー吸っていく感じだよね。初期見積は最低限のモックのだけ出しておく。
いつの時代って?どんな契約してんだ?
省庁の発注ではアジャイルは無理ですね。というかまともなシステム開発は無理。
・入札なので公示までには完璧な仕様書を非エンジニアの役人が作らなければいけない・政府調達、国際入札だと準備や公示期間に開発日程が喰われる・入札なので仕様に瑕疵があろうと契約後の変更は許されない・入札で落とした業者がスキル不足だと手取り足取り教えて作りあげさせなければいけない(できませんでした、だと発注者の責任も問われる)・単年度予算なので次年度予算がつくかわからない・単年度契約なので次年度に今年度と違う業者が横取りするかもしれない、今年度の業者が次年度継続せずに逃げるかもしれない。業者と発注者が二人三脚で、育てて育てられるということが本質的に不可能。
開発案件の入札と単年度契約の制度はほんと潰れてほしい。入札でこれだけ節約できたとかいうニュースを見るたび、その背後でどれだけのプロジェクトが入札のせいで氏んでいるか知ってるのかといいたくなる。
# さすがにAC
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。運用しながらシステムを改善していくのだ。仕様は結果でしかない。
ほんとそう思う、それ自体建設業界モデルの古い日本の習慣なんじゃないかと思う。
結果よくわからないものが出来上がる
ちゃんとした要求仕様を作成できる発注側なんて日本には存在しません。基本的に「良きに計らえ」としか書いてないんだから。
そういうことなら、余計に開発手法関係ないよね。まして、接触確認アプリなんて、目的ははっきりしているし、他国でも作っているようなものだから、最低限の要件定義はできると思うんだけど。# 要するに#4029386 [srad.jp]のコメントに書いている事が真実なのか。
「接触分析プログラム」ならウォーターフォールでも良いだろうけど「接触確認アプリ」となった時点で天下り外郭団体と随契して運営するしかないだろ
求めているものは成果物の管理やら門田やらを永久無償で押し付ける相手だから。成果だけ総取りするのよ。
門田って何のことかわからない……
墾田永年私財法という言葉が頭をよぎった
#永久無償で開墾
屏風を例えにするなら、少なくとも接触確認アプリに関してアジャイルを適用するのは、屏風に虎を書いてくださいとお願いしたら、書いている途中に「虎ってこうですよね」って聞かれながら絵を描いてもらっているような感じに思える。で、最終的に書かれた虎が虎と似ても似つかないようなものになっても、「途中で確認しましたよね」ともいえて、責任範囲があいまいになるような。# でも、今回の問題は虎に似ても似つかないものが書かれていたにも関わらず、誰も確認せず、4ヶ月間もそのままだったような事なんだけど。
あいまいにはならんよ確認したんだから確認された側(顧客)の責任だから顧客の意思決定者を巻き込まなければいけないとなって日本では難しい「こうする」とかその場で一人で決められる人(っていうかその一人に権限を集中する組織?)が少ないよなっていう
アジャイルも一つではないので、それ以外にもいろいろ
Agile is Deadと言われてるようにアジャイルはとっくに時代遅れなんだよなリーン開発が台頭したけど採用できる案件は限られるし
時代遅れというか、今はもうどこもアジャイル的に開発してるのが普通だから、別に話題にならないというだけですよね。(少なくとも自分がここ10年ぐらい関わった案件は全部アジャイル。)
普通じゃないから浸透していない記事があふれてんだろうが随分狭い視野だな
> 発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいい
極論すれば指定期日は納品物が次期システムにカットオーバーして退役する日ってのがアジャイルとかモバイルアプリ運営なんじゃないの
スタッフのポストを作って関連業務を含めて委託する形じゃなきゃ回らないってわけ
開発物がモバイルアプリなのかWebサイトなのか物流システムなのか顧客管理システムなのか会計ソフトなのかで大きく変わるんじゃないの
この中だとモバイルアプリと物流以外はウォーターフォールでやったけど、アジャイルはどのあたりのジャンルだと受け入れてくれそうだろうか。
システムを「発注」するって考え方をする企業にアジャイルは無理でしょう
自社パッケージならともかく検収と納品がある以上、一般企業でも合わないでしょ
終わりのないサグラダファミリアにしかならない
行政が内製を?とんでもない馬鹿ですね
電電公社って行政の内製組織だったんですよ
時代に取り残されたクソ業者沸いてて草いまだにeclipseとか使ってそう
内製ってwどこの諸外国だよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
自分の体験のみで恐縮だけど (スコア: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]
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。この場合の関係者には、少なくともプログラマと「顧客」が含まれる
これが嫌がられるのよな。
孫受け禁止 (スコア:2, 興味深い)
この「文書よりも顔突き合わせて話し合い」っ点からしても多重下請け構造とは相性悪いんじゃないの
つまり下請け禁止、直接契約を義務付ければアジャイルでも事故りにくいと思うよ
Re: (スコア:0)
でも一次請けするような会社には開発者はいないのよね
Re: (スコア:0)
今孫請けの立場にいる会社に直接発注しろってことだよ
Re: (スコア:0)
孫請けだろうが見積要るだろうが
Re: (スコア:0)
元請けには、経験▪ネットワークがあるからね。
Re: (スコア:0)
なんか、今までにない新しい事をしようとしている時には有効な開発手法だと思うけど、接触確認アプリのような、目的がはっきりしていて、他国でも作っているようなものにはむかない開発手法に思える。
# まあ、仕事を請ける側にとっては責任範囲なんかがあいまいになって都合のいいのかもしれないが。
Re: (スコア:0)
COCOA開発当時、どの国も接触確認アプリは開発前もしくは開発中で、まさしく今までにない新しい事をしようとしている時だったんですが、それは……
Re:自分の体験のみで恐縮だけど (スコア:1)
https://cio.go.jp/sites/default/files/uploads/documents/techteam_20200509_05.pdf
2020/03/20 シンガポール
2020/04/11 インド
2020/04/26 オーストラリア
国内だと、地方自治体のQRコードベースのシステムの方が一歩早かった気が。
2020/05/29 http://www.pref.osaka.lg.jp/smart_somu/osaka_covid19/index.html
2020/06/01 https://www.city.chiba.jp/hokenfukushi/iryoeisei/seisaku/corona_tsuiseki.html
2020/06/05 https://www.city.hachinohe.aomori.jp/corona/14673.html
2020/06/19 COCOA
まぁ、アプリの承認考えれば、国内は割と横並びなのかね?
Re: (スコア:0)
そんなことはないよ。中国や台湾はとっくにできてた。
Re: (スコア:0)
接触確認アプリの導入に係る各国の動向等について(令和2年5月8日)新型コロナウイルス感染症対策テックチーム事務局
https://cio.go.jp/sites/default/files/uploads/documents/techteam_20200... [cio.go.jp]
ここに当時の状況がまとまってますけど、独自に運用開始していたのは中国、インド、イスラエル、オーストラリア、シンガポールあたりですね。
GoogleとAppleのEN API利用型は各国ヨーイドンです。
Re: (スコア:0)
中国や台湾はとっくにできてたというか、一部の国以外全くできていないが正しいような。
https://www.sbbit.jp/article/cont1/39190 [sbbit.jp]
この記事は去年の8月だけど、Google Appleのあるカリフォルニア州で導入されたのは12月になってから。
結局誰も使ってない。
Re: (スコア:0)
・他国で作っていようが本邦の発注側担当者にとってもベンダーにとっても新しい内容
・いくら目的がはっきりしていても、UI/UXやらDB設計などの実現・表現手段が利用者の文化によっても規模によっても千差万別なので、他国の成果物は参考程度にしかならない
アジャイルについて何か勘違いしてないか?
アジャイルの利点は素早く軌道修正してリスクを最小化できることだぞ。
銀行のシステム変更みたいな超大規模プロジェクトなんかには向いてないだろうが、今回みたいな規模・性質のアプリにはまさに向いているように思えるが。
Re: (スコア:0)
アジャイルの欠点は見積り辛い事なんだよ
Re:自分の体験のみで恐縮だけど (スコア:1)
アジャイルだと、そもそも「全体」の見積もりをしようとするのが概念的に誤り。
道幅で3ヶ月くらいの見積もりしておいて、そこからローリングしていくのでいい。
経営が「全部でいくらかかるかわからないと判断できない」というのは、
経営がモダンなビジネスに対応できてないってことなので、経営を取り替えるほうがよい。
Re: (スコア:0)
アジャイルの見積もりなんていつの時代の話してんの
Re: (スコア:0)
モック作って即リリース、クライアントが逃げ出さないようにして、継続してイテレーション回してチューチュー吸っていく感じだよね。
初期見積は最低限のモックのだけ出しておく。
Re: (スコア:0)
いつの時代って?どんな契約してんだ?
Re:自分の体験のみで恐縮だけど (スコア:1)
省庁の発注ではアジャイルは無理ですね。というかまともなシステム開発は無理。
・入札なので公示までには完璧な仕様書を非エンジニアの役人が作らなければいけない
・政府調達、国際入札だと準備や公示期間に開発日程が喰われる
・入札なので仕様に瑕疵があろうと契約後の変更は許されない
・入札で落とした業者がスキル不足だと手取り足取り教えて作りあげさせなければいけない(できませんでした、だと発注者の責任も問われる)
・単年度予算なので次年度予算がつくかわからない
・単年度契約なので次年度に今年度と違う業者が横取りするかもしれない、今年度の業者が次年度継続せずに逃げるかもしれない。業者と発注者が二人三脚で、育てて育てられるということが本質的に不可能。
開発案件の入札と単年度契約の制度はほんと潰れてほしい。入札でこれだけ節約できたとかいうニュースを見るたび、その背後でどれだけのプロジェクトが入札のせいで氏んでいるか知ってるのかといいたくなる。
# さすがにAC
Re:自分の体験のみで恐縮だけど (スコア:1)
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。
運用しながらシステムを改善していくのだ。
仕様は結果でしかない。
Re: (スコア:0)
ほんとそう思う、それ自体建設業界モデルの古い日本の習慣なんじゃないかと思う。
Re: (スコア:0)
結果よくわからないものが出来上がる
Re: (スコア:0)
ちゃんとした要求仕様を作成できる発注側なんて日本には存在しません。
基本的に「良きに計らえ」としか書いてないんだから。
Re: (スコア:0)
そういうことなら、余計に開発手法関係ないよね。
まして、接触確認アプリなんて、目的ははっきりしているし、他国でも作っているようなものだから、最低限の要件定義はできると思うんだけど。
# 要するに#4029386 [srad.jp]のコメントに書いている事が真実なのか。
Re:自分の体験のみで恐縮だけど (スコア:2)
あなたレベルのユーザーの認識では上手くいかないのでしょうね。
新規性の無いごく初心者向けの日曜大工といえる開発でいいから、スマホシステム開発してみたら。
Re: (スコア:0)
「接触分析プログラム」ならウォーターフォールでも良いだろうけど
「接触確認アプリ」となった時点で天下り外郭団体と随契して運営するしかないだろ
Re: (スコア:0)
求めているものは成果物の管理やら門田やらを永久無償で押し付ける相手だから。
成果だけ総取りするのよ。
Re:自分の体験のみで恐縮だけど (スコア:1)
門田って何のことかわからない……
Re:自分の体験のみで恐縮だけど (スコア:2)
墾田永年私財法という言葉が頭をよぎった
#永久無償で開墾
Re:自分の体験のみで恐縮だけど (スコア:1)
Re: (スコア:0)
ってなるでしょ。
そこをちょっとずつ屏風に絵を描いてくから見ててね、ってのがアジャイルだ。
Re: (スコア:0)
屏風を例えにするなら、少なくとも接触確認アプリに関してアジャイルを適用するのは、屏風に虎を書いてくださいとお願いしたら、書いている途中に「虎ってこうですよね」って聞かれながら絵を描いてもらっているような感じに思える。で、最終的に書かれた虎が虎と似ても似つかないようなものになっても、「途中で確認しましたよね」ともいえて、責任範囲があいまいになるような。
# でも、今回の問題は虎に似ても似つかないものが書かれていたにも関わらず、誰も確認せず、4ヶ月間もそのままだったような事なんだけど。
Re:自分の体験のみで恐縮だけど (スコア:1)
あいまいにはならんよ
確認したんだから確認された側(顧客)の責任
だから顧客の意思決定者を巻き込まなければいけないとなって日本では難しい
「こうする」とかその場で一人で決められる人(っていうかその一人に権限を集中する組織?)が少ないよなっていう
Re: (スコア:0)
アジャイルも一つではないので、それ以外にもいろいろ
Re: (スコア:0)
Agile is Deadと言われてるようにアジャイルはとっくに時代遅れなんだよな
リーン開発が台頭したけど採用できる案件は限られるし
Re:自分の体験のみで恐縮だけど (スコア:1)
時代遅れというか、今はもうどこもアジャイル的に開発してるのが普通だから、別に話題にならないというだけですよね。
(少なくとも自分がここ10年ぐらい関わった案件は全部アジャイル。)
Re: (スコア:0)
普通じゃないから浸透していない記事があふれてんだろうが
随分狭い視野だな
Re: (スコア:0)
> 発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいい
極論すれば指定期日は納品物が次期システムにカットオーバーして退役する日ってのが
アジャイルとかモバイルアプリ運営なんじゃないの
スタッフのポストを作って関連業務を含めて委託する形じゃなきゃ回らないってわけ
Re: (スコア:0)
開発物がモバイルアプリなのかWebサイトなのか物流システムなのか顧客管理システムなのか会計ソフトなのかで大きく変わるんじゃないの
Re: (スコア:0)
この中だとモバイルアプリと物流以外はウォーターフォールでやったけど、
アジャイルはどのあたりのジャンルだと受け入れてくれそうだろうか。
Re: (スコア:0)
システムを「発注」するって考え方をする企業にアジャイルは無理でしょう
Re: (スコア:0)
自社パッケージならともかく
検収と納品がある以上、一般企業でも合わないでしょ
終わりのないサグラダファミリアにしかならない
Re:自分の体験のみで恐縮だけど (スコア:1)
Re:自分の体験のみで恐縮だけど (スコア:1)
Re: (スコア:0)
行政が内製を?
とんでもない馬鹿ですね
Re: (スコア:0)
電電公社って行政の内製組織だったんですよ
Re: (スコア:0)
時代に取り残されたクソ業者沸いてて草
いまだにeclipseとか使ってそう
Re: (スコア:0)
内製ってw
どこの諸外国だよ