行政の公共調達システムが「アジャイル開発」阻むとする指摘。日経新聞 152
ストーリー by nagazou
むずかしいところ 部門より
むずかしいところ 部門より
日経新聞は、接触確認アプリ「COCOA」が4か月も機能しなかった問題の一つとして、金額や仕様に厳格すぎる日本の行政システムにも原因があるとする記事を掲載している。こうした硬直的な公共調達は、IT業界で普及しつつあるアジャイル開発との相性が悪いしており、デジタル時代に対応した行政側の対応が必要になると指摘している（日経新聞）。
記事では、公共調達は完成物を受け取る前提で契約をしており、会計法などを含めて機能変更や改修を繰り返すソフトウェアの運用などに向いていない、責任範囲がはっきりしない契約を結んでいいか分からない、また状況に応じて作業内容が変わることから、金額を確定させて契約する公共調達に見合わないなどの問題なども指摘されている。
今回のCOCOAの場合、厚労省は約1か月単位で課題に対処するとする条項を含んではいたものの、厚労省側で問題を指摘できる人材がいなかったとする点も指摘されている。
記事では、公共調達は完成物を受け取る前提で契約をしており、会計法などを含めて機能変更や改修を繰り返すソフトウェアの運用などに向いていない、責任範囲がはっきりしない契約を結んでいいか分からない、また状況に応じて作業内容が変わることから、金額を確定させて契約する公共調達に見合わないなどの問題なども指摘されている。
今回のCOCOAの場合、厚労省は約1か月単位で課題に対処するとする条項を含んではいたものの、厚労省側で問題を指摘できる人材がいなかったとする点も指摘されている。
それ以前の問題 (スコア:5, すばらしい洞察)
完成物を受け取る前提での契約は、バグや機能追加前提で随時修正することの多い最近の開発業態とは相性が悪いことは確かにある。
でもCOCOAに関しては納品物のチェックなしに（未完成品を）完成品として受け取っていた。アジャイルだ相性だとはまったく別次元の問題だよ。
Re:それ以前の問題 (スコア:4, すばらしい洞察)
行政側に、仕様決めや完成品のテストができる人材が足りてなきゃ、ウォーターフォールだろうがアジャイルだろうが無理。
Re:それ以前の問題 (スコア:1)
行政側に、仕様決めや完成品のテストができる人材がいなければ発注してはいけない、という認識は間違ってないか。
行政は政策と国民のニーズに基づいて「こういう機能のものがほしい」と要求と予算を割り当てるプロであって、エンジニアリングの専門家ではない。
その要求に基づきシステムの仕様を決め構築し要求を満たすことを確認するところまでがSIerの仕事であるべきだと思うのだが。
# まあ、現実はそうなってないよね。
Re:それ以前の問題 (スコア:1)
別物なんですよね。
Re:それ以前の問題 (スコア:1)
それを誰に求めるかというと…
Re:それ以前の問題 (スコア:1)
こういう業務分掌を盾にぶっちゃけやる気のない「発注者」も「エンジニア」も消えゆく運命なんだろうと思う。
業務を知り尽くした上で、必要だと思えば必要だと思った奴が一気にプロトタイプまで書き上げて、
どうしても足らない部分だけは高度なエンジニアを頼るって時代がすぐそこまで来てると思うんだけどね。
規模が大きくなればその「最初に書いた奴」がそのままPMになる。
その気になればクラウド使って1人で大規模システム作れる時代なのに、
「○○は担当外なので知りません」「○○はお見積りに含まれていません」とかほざく奴は生き残れない。
Re: (スコア:0)
行政というか、民間も含めて日本の発注側の問題点として延々と言われてることだよね。
Re:それ以前の問題 (スコア:1)
アジャイルでも、この時点ではここまでの機能をリリースしますってスケジュールが最終クライアント(政府)まで通ってれば問題なく通ることが多い。
むしろ、追加要望が来た時に、数手先のリリース時に後回ししやすい。
追加要望が来た時、それを捌けるかも、結局は受注側営業の力量。
# 営業が不安なら、まともなプロデューサーとか進行管理を用意して営業には口出させるな。
Re:それ以前の問題 (スコア:3, すばらしい洞察)
さらに開発が3次孫とかの案件だと、発注側がいくら優秀でも、
開発知らない人間が数人障壁になるので実際の開発陣まで意図が伝わらない。
発注側にそれを打ち破れる性能求めるのは酷ってもんよ。
悲しいかな、発注側に必要なのは検証能力よりは座組ガチャで当たり引く運。
#直接 backlog できれば、全てが解決してるやんとかザラ。
Re:それ以前の問題 (スコア:1)
いや、検証なり評価なりする工程を一次請けが工程に入れるべきって話では？
一次受けがスルーして丸投げしたからcocoaが酷い状態になったのかと
アジャイル大嫌い (スコア:1)
明文化されてない仕様が出来がち。
納期もよくわからない。
Re:アジャイル大嫌い (スコア:2, すばらしい洞察)
アジャイルもウォーターフォールでも、無理をしているのは嫌い。生産のパフォーマンスが上がらなければ意味がない。
アジャイルしましょうが状況を誘発しているのだとは思うけど、ドキュメントが残らないのはアジャイルではなくプロジェクトの非だと思う。
Re: (スコア:0)
アジャイルとは違うかもしれないけど、
対応項目と優先度は決まってて明確な納期がない。
こっちの切りのいいタイミングで納品していってる。
Re: (スコア:0)
あるある。スコープ決めて開発してるはずなのに横から口を出してきて「ここはこういう機能・デザインだと思ってた」と言い出す人が
Re:アジャイル大嫌い (スコア:1)
追加・修正に関して金出してくれたり、ちゃんとリスケを考慮してくれるならラッキーなんですがね
実際は「いますぐ直せ！金は出さん！」とか発注側にとって都合のいいアジャイルだったりするんですよ
ウォーターフォールなら仕様書が前提なので後出しに対して強気に対応できるけど、なんちゃってアジャイルだと立場の弱いほうが泣くしかない
Re: (スコア:0)
ドキュメントは適当でいいし（良い子は真似しちゃダメだぞ）
優先度順に処理していけばいいし
納期を気にしなくていいし
サラリーとの相性がいいし
それで毎月お金もらえるし
アジャイル大好き
Re: (スコア:0)
ではア ジャイアン スタイルでどうでしょう
# きれいなのが出てきたらSSR
システムを一括発注するという慣習が時代遅れ (スコア:1)
要件と納期を決めて外部に丸投げするってやり方は、大昔に建設業界をモデルにして
人を右から左に流すだけで儲かるとか考えた「請負会社」がアウトソーシングを喧伝して、
内製からアウトソース(という名の人身売買)をビジネスにしたところが発端。
確かに専門知識も必要な上に恒常的に人材確保が必ずしも必要ではないシステム開発では、条件さえ
揃えばコストの削減に繋がる・・・ってことで正当化されてきたけど、実際にはコミュニケーション
コストや多重請けで抜かれるマージンのせいで金額に見合った品質は怪しかったのも現実。
その上、今や要件が時流の流れでコロコロ変わるので「納期」には「設計」が時代遅れなことも普通に
発生してるし、特定組織の業務の一部と化してるシステムでは「開発～保守～運用」のフェーズが
曖昧なままで恒常的にPDCAを回す必要があったりで、もはやアウトソースを正当化する余地が
残っていないと思う。
実際に「巨大IT」って言われるところは内製に回帰してるよね。外注化はいいことが何もない。
自分の体験のみで恐縮だけど (スコア: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)
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)
・他国で作っていようが本邦の発注側担当者にとってもベンダーにとっても新しい内容
・いくら目的がはっきりしていても、UI/UXやらDB設計などの実現・表現手段が利用者の文化によっても規模によっても千差万別なので、他国の成果物は参考程度にしかならない
アジャイルについて何か勘違いしてないか？
アジャイルの利点は素早く軌道修正してリスクを最小化できることだぞ。
銀行のシステム変更みたいな超大規模プロジェクトなんかには向いてないだろうが、今回みたいな規模・性質のアプリにはまさに向いているように思えるが。
Re:自分の体験のみで恐縮だけど (スコア:1)
アジャイルだと、そもそも「全体」の見積もりをしようとするのが概念的に誤り。
道幅で3ヶ月くらいの見積もりしておいて、そこからローリングしていくのでいい。
経営が「全部でいくらかかるかわからないと判断できない」というのは、
経営がモダンなビジネスに対応できてないってことなので、経営を取り替えるほうがよい。
Re:自分の体験のみで恐縮だけど (スコア:1)
省庁の発注ではアジャイルは無理ですね。というかまともなシステム開発は無理。
・入札なので公示までには完璧な仕様書を非エンジニアの役人が作らなければいけない
・政府調達、国際入札だと準備や公示期間に開発日程が喰われる
・入札なので仕様に瑕疵があろうと契約後の変更は許されない
・入札で落とした業者がスキル不足だと手取り足取り教えて作りあげさせなければいけない（できませんでした、だと発注者の責任も問われる）
・単年度予算なので次年度予算がつくかわからない
・単年度契約なので次年度に今年度と違う業者が横取りするかもしれない、今年度の業者が次年度継続せずに逃げるかもしれない。業者と発注者が二人三脚で、育てて育てられるということが本質的に不可能。
開発案件の入札と単年度契約の制度はほんと潰れてほしい。入札でこれだけ節約できたとかいうニュースを見るたび、その背後でどれだけのプロジェクトが入札のせいで氏んでいるか知ってるのかといいたくなる。
# さすがにAC
Re:自分の体験のみで恐縮だけど (スコア:1)
そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。
運用しながらシステムを改善していくのだ。
仕様は結果でしかない。
Re: (スコア:0)
ちゃんとした要求仕様を作成できる発注側なんて日本には存在しません。
基本的に「良きに計らえ」としか書いてないんだから。
Re: (スコア:0)
そういうことなら、余計に開発手法関係ないよね。
まして、接触確認アプリなんて、目的ははっきりしているし、他国でも作っているようなものだから、最低限の要件定義はできると思うんだけど。
# 要するに#4029386 [srad.jp]のコメントに書いている事が真実なのか。
Re:自分の体験のみで恐縮だけど (スコア:2)
あなたレベルのユーザーの認識では上手くいかないのでしょうね。
新規性の無いごく初心者向けの日曜大工といえる開発でいいから、スマホシステム開発してみたら。
Re:自分の体験のみで恐縮だけど (スコア:1)
門田って何のことかわからない……
Re:自分の体験のみで恐縮だけど (スコア:2)
墾田永年私財法という言葉が頭をよぎった
#永久無償で開墾
Re:自分の体験のみで恐縮だけど (スコア:1)
Re: (スコア:0)
ってなるでしょ。
そこをちょっとずつ屏風に絵を描いてくから見ててね、ってのがアジャイルだ。
Re: (スコア:0)
屏風を例えにするなら、少なくとも接触確認アプリに関してアジャイルを適用するのは、屏風に虎を書いてくださいとお願いしたら、書いている途中に「虎ってこうですよね」って聞かれながら絵を描いてもらっているような感じに思える。で、最終的に書かれた虎が虎と似ても似つかないようなものになっても、「途中で確認しましたよね」ともいえて、責任範囲があいまいになるような。
# でも、今回の問題は虎に似ても似つかないものが書かれていたにも関わらず、誰も確認せず、4ヶ月間もそのままだったような事なんだけど。
Re:自分の体験のみで恐縮だけど (スコア:1)
あいまいにはならんよ
確認したんだから確認された側(顧客)の責任
だから顧客の意思決定者を巻き込まなければいけないとなって日本では難しい
「こうする」とかその場で一人で決められる人(っていうかその一人に権限を集中する組織?)が少ないよなっていう
Re:自分の体験のみで恐縮だけど (スコア:1)
時代遅れというか、今はもうどこもアジャイル的に開発してるのが普通だから、別に話題にならないというだけですよね。
（少なくとも自分がここ10年ぐらい関わった案件は全部アジャイル。）
Re: (スコア:0)
> 発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいい
極論すれば指定期日は納品物が次期システムにカットオーバーして退役する日ってのが
アジャイルとかモバイルアプリ運営なんじゃないの
スタッフのポストを作って関連業務を含めて委託する形じゃなきゃ回らないってわけ
Re: (スコア:0)
開発物がモバイルアプリなのかWebサイトなのか物流システムなのか顧客管理システムなのか会計ソフトなのかで大きく変わるんじゃないの
Re: (スコア:0)
この中だとモバイルアプリと物流以外はウォーターフォールでやったけど、
アジャイルはどのあたりのジャンルだと受け入れてくれそうだろうか。
Re: (スコア:0)
システムを「発注」するって考え方をする企業にアジャイルは無理でしょう
Re:自分の体験のみで恐縮だけど (スコア:1)
Re:自分の体験のみで恐縮だけど (スコア:1)
相性が悪いしており (スコア:0)
たいとるおんりー
行政が悪い (スコア:0)
って言ってればいいんだから、楽なもんだよね
曖昧な仕様を指摘する必要もなく、要求仕様に満たないものを１．０として納品してOK
ろくに検収もされないし
Re:行政が悪い (スコア:2)
一般論として「行政（の公共調達の仕組み）が悪い」という話は納得できる。
でも少なくともCOCOAについては、アジャイルで開発が膨れてもそれも飲み込める程度の発注金額だったわけで、
そのあたりの作業と責任も含めて委託したのだろうと思うと考えると
COCOAについては行政が悪いというよりは一次請負先が悪い、という話に見えるなぁ。
# mishimaは本田透先生を熱烈に応援しています
Re:行政が悪い (スコア:1)
例えば某所の公示情報だけど・・・
> 現在のXXの欠落等を生じず、確実に継承出来るソフトウェアを利用すること。
> 一部カスタマイズされている部分があるため、当該カスタマイズに合わせた運用が可能であること。
こんな内容でカスタマイズ部分も明示しないまま公示されても、突っ込みどころしか無いじゃないですかー。
特定業者しか入札に参加できませんよねー
# 裏で話ついているんだろうなーとしか。
Re:行政が悪い (スコア:1)
欲しい物が何か分からないんだから、「成果が得られなければ打ち切り」も判定不可能
ダミーデータを食わされて「成果はあった事になっているが、訳が分からない。追加投資が必要」という判断になる
業者側のモラルにも限度があり、やがて組織が発注する全てのプロジェクトがそういう結果になる