アカウント名:
パスワード:
アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない?
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。
素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
wikipedia参照ですまないが、https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%... [wikipedia.org]
アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。この場合の関係者には、少なくともプログラマと「顧客」が含まれる
これが嫌がられるのよな。
この「文書よりも顔突き合わせて話し合い」っ点からしても多重下請け構造とは相性悪いんじゃないの
つまり下請け禁止、直接契約を義務付ければアジャイルでも事故りにくいと思うよ
でも一次請けするような会社には開発者はいないのよね
今孫請けの立場にいる会社に直接発注しろってことだよ
孫請けだろうが見積要るだろうが
二次受けを禁止すれば、開発者を囲うでしょ。それができないなら、開発力のあるところが一次受けとして表に出てきて競争に負けるだけだ。まず、そこから。
だからいくらでいつまで囲うんだよ?バイトか?
省庁ともなれば通年でそこそこ人数が必要でしょうが。だから本質的に中の人になるように公務員待遇で雇って内製すれば良かろう。海外じゃそれが普通。案件毎に不要になったってまたすぐに次の案件が来るんだよ。
しかし下請け構造じゃなきゃ人数用意できないんですよね。規模にもよりますが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
大変だね。
アジャイルは開発手法だから、現行制度でとりあえず発注できてその後に問題が露見するんだろうけど、より後発のDevOpsは開発者と運用者が一体じゃないといけなくてその制度じゃ発注しようがないっぽいから、DevOpsがナウなヤングにバカウケと大臣説得して社会制度を変えるしかなさそう
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。運用しながらシステムを改善していくのだ。仕様は結果でしかない。
ほんとそう思う、それ自体建設業界モデルの古い日本の習慣なんじゃないかと思う。
結果よくわからないものが出来上がる
建設業界モデルを古いというのはちょと違うな。ウォーターフォールは、建設のように手戻りのペナルティが極めて大きい業態には良く合った優れた手法。それは今でもそう。その手法を、ソフトウェア開発という手直しが建設より遥かに容易な業態に適用してるから問題なのよ。
問題なのは要求仕様を定めてから動くことじゃなく「完成品」と言うものが納品されるという前提がダメなんだと思う。基本的にソフトウェアって更新しなくなったら死んだも同然な訳でずっと作り改善し続けるものであるべきですよね。そうやってプロジェクトがずっと続くから絶えず変更し続けるアジャイルが合うんですよ。でも官公庁や大企業のプロジェクトってそう言う予算の取り方せず開発終わったらあとは保守、何か改修したければまたプロジェクト立ち上げて、という考えだからウォーターフォールしか合わないんです。
その官公庁向けシステムもローリングリリースモデルに移行してる環境で開発するので、開発終わって保守フェーズに入ろうかって時にプラットフォームのサポート期限が終わるって話になるんだけどね。
合う合わないじゃなくて、合わせないと仕事ができない時代に来てる。
ちゃんとした要求仕様を作成できる発注側なんて日本には存在しません。基本的に「良きに計らえ」としか書いてないんだから。
そういうことなら、余計に開発手法関係ないよね。まして、接触確認アプリなんて、目的ははっきりしているし、他国でも作っているようなものだから、最低限の要件定義はできると思うんだけど。# 要するに#4029386 [srad.jp]のコメントに書いている事が真実なのか。
プロトタイプからのウォーターフォールなら大規模開発では大昔からよくある手法スマホ程度なら同時でもよいのだろうけど
「接触分析プログラム」ならウォーターフォールでも良いだろうけど「接触確認アプリ」となった時点で天下り外郭団体と随契して運営するしかないだろ
求めているものは成果物の管理やら門田やらを永久無償で押し付ける相手だから。成果だけ総取りするのよ。
門田って何のことかわからない……
墾田永年私財法という言葉が頭をよぎった
#永久無償で開墾
屏風を例えにするなら、少なくとも接触確認アプリに関してアジャイルを適用するのは、屏風に虎を書いてくださいとお願いしたら、書いている途中に「虎ってこうですよね」って聞かれながら絵を描いてもらっているような感じに思える。で、最終的に書かれた虎が虎と似ても似つかないようなものになっても、「途中で確認しましたよね」ともいえて、責任範囲があいまいになるような。# でも、今回の問題は虎に似ても似つかないものが書かれていたにも関わらず、誰も確認せず、4ヶ月間もそのままだったような事なんだけど。
あいまいにはならんよ確認したんだから確認された側(顧客)の責任だから顧客の意思決定者を巻き込まなければいけないとなって日本では難しい「こうする」とかその場で一人で決められる人(っていうかその一人に権限を集中する組織?)が少ないよなっていう
アジャイルも一つではないので、それ以外にもいろいろ
Agile is Deadと言われてるようにアジャイルはとっくに時代遅れなんだよなリーン開発が台頭したけど採用できる案件は限られるし
時代遅れというか、今はもうどこもアジャイル的に開発してるのが普通だから、別に話題にならないというだけですよね。(少なくとも自分がここ10年ぐらい関わった案件は全部アジャイル。)
普通じゃないから浸透していない記事があふれてんだろうが随分狭い視野だな
> 発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいい
極論すれば指定期日は納品物が次期システムにカットオーバーして退役する日ってのがアジャイルとかモバイルアプリ運営なんじゃないの
スタッフのポストを作って関連業務を含めて委託する形じゃなきゃ回らないってわけ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
自分の体験のみで恐縮だけど (スコア: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)
だからいくらでいつまで囲うんだよ?バイトか?
Re: (スコア:0)
省庁ともなれば通年でそこそこ人数が必要でしょうが。
だから本質的に中の人になるように公務員待遇で雇って内製すれば良かろう。海外じゃそれが普通。
案件毎に不要になったってまたすぐに次の案件が来るんだよ。
Re: (スコア:0)
しかし下請け構造じゃなきゃ人数用意できないんですよね。
規模にもよりますが1社だけでプロジェクトに必要な役割の人材とその人数とを全て都合つけられる会社なんてそうそうないので。
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: (スコア:0)
見積無しで発注は、さすがにヤバい。
発注側、受注先双方ヤバい。
Re:自分の体験のみで恐縮だけど (スコア:1)
省庁の発注ではアジャイルは無理ですね。というかまともなシステム開発は無理。
・入札なので公示までには完璧な仕様書を非エンジニアの役人が作らなければいけない
・政府調達、国際入札だと準備や公示期間に開発日程が喰われる
・入札なので仕様に瑕疵があろうと契約後の変更は許されない
・入札で落とした業者がスキル不足だと手取り足取り教えて作りあげさせなければいけない(できませんでした、だと発注者の責任も問われる)
・単年度予算なので次年度予算がつくかわからない
・単年度契約なので次年度に今年度と違う業者が横取りするかもしれない、今年度の業者が次年度継続せずに逃げるかもしれない。業者と発注者が二人三脚で、育てて育てられるということが本質的に不可能。
開発案件の入札と単年度契約の制度はほんと潰れてほしい。入札でこれだけ節約できたとかいうニュースを見るたび、その背後でどれだけのプロジェクトが入札のせいで氏んでいるか知ってるのかといいたくなる。
# さすがにAC
Re: (スコア:0)
大変だね。
アジャイルは開発手法だから、現行制度でとりあえず発注できてその後に問題が露見するんだろうけど、
より後発のDevOpsは開発者と運用者が一体じゃないといけなくてその制度じゃ発注しようがないっぽいから、
DevOpsがナウなヤングにバカウケと大臣説得して社会制度を変えるしかなさそう
Re:自分の体験のみで恐縮だけど (スコア:1)
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。
運用しながらシステムを改善していくのだ。
仕様は結果でしかない。
Re: (スコア:0)
ほんとそう思う、それ自体建設業界モデルの古い日本の習慣なんじゃないかと思う。
Re: (スコア:0)
結果よくわからないものが出来上がる
Re: (スコア:0)
建設業界モデルを古いというのはちょと違うな。
ウォーターフォールは、建設のように手戻りのペナルティが極めて大きい業態には良く合った優れた手法。それは今でもそう。
その手法を、ソフトウェア開発という手直しが建設より遥かに容易な業態に適用してるから問題なのよ。
Re: (スコア:0)
問題なのは要求仕様を定めてから動くことじゃなく「完成品」と言うものが納品されるという前提がダメなんだと思う。
基本的にソフトウェアって更新しなくなったら死んだも同然な訳でずっと作り改善し続けるものであるべきですよね。そうやってプロジェクトがずっと続くから絶えず変更し続けるアジャイルが合うんですよ。
でも官公庁や大企業のプロジェクトってそう言う予算の取り方せず開発終わったらあとは保守、何か改修したければまたプロジェクト立ち上げて、という考えだからウォーターフォールしか合わないんです。
Re: (スコア:0)
その官公庁向けシステムもローリングリリースモデルに移行してる環境で開発するので、開発終わって保守フェーズに入ろうかって時に
プラットフォームのサポート期限が終わるって話になるんだけどね。
合う合わないじゃなくて、合わせないと仕事ができない時代に来てる。
Re: (スコア:0)
ちゃんとした要求仕様を作成できる発注側なんて日本には存在しません。
基本的に「良きに計らえ」としか書いてないんだから。
Re: (スコア:0)
そういうことなら、余計に開発手法関係ないよね。
まして、接触確認アプリなんて、目的ははっきりしているし、他国でも作っているようなものだから、最低限の要件定義はできると思うんだけど。
# 要するに#4029386 [srad.jp]のコメントに書いている事が真実なのか。
Re:自分の体験のみで恐縮だけど (スコア:2)
あなたレベルのユーザーの認識では上手くいかないのでしょうね。
新規性の無いごく初心者向けの日曜大工といえる開発でいいから、スマホシステム開発してみたら。
Re: (スコア:0)
プロトタイプからのウォーターフォールなら大規模開発では大昔からよくある手法
スマホ程度なら同時でもよいのだろうけど
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)
> 発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいい
極論すれば指定期日は納品物が次期システムにカットオーバーして退役する日ってのが
アジャイルとかモバイルアプリ運営なんじゃないの
スタッフのポストを作って関連業務を含めて委託する形じゃなきゃ回らないってわけ