パスワードを忘れた? アカウント作成
15280964 story
ソフトウェア

行政の公共調達システムが「アジャイル開発」阻むとする指摘。日経新聞 152

ストーリー by nagazou
むずかしいところ 部門より
日経新聞は、接触確認アプリ「COCOA」が4か月も機能しなかった問題の一つとして、金額や仕様に厳格すぎる日本の行政システムにも原因があるとする記事を掲載している。こうした硬直的な公共調達は、IT業界で普及しつつあるアジャイル開発との相性が悪いしており、デジタル時代に対応した行政側の対応が必要になると指摘している(日経新聞)。

記事では、公共調達は完成物を受け取る前提で契約をしており、会計法などを含めて機能変更や改修を繰り返すソフトウェアの運用などに向いていない、責任範囲がはっきりしない契約を結んでいいか分からない、また状況に応じて作業内容が変わることから、金額を確定させて契約する公共調達に見合わないなどの問題なども指摘されている。

今回のCOCOAの場合、厚労省は約1か月単位で課題に対処するとする条項を含んではいたものの、厚労省側で問題を指摘できる人材がいなかったとする点も指摘されている。
  • それ以前の問題 (スコア:5, すばらしい洞察)

    by Anonymous Coward on 2021年05月12日 18時13分 (#4029384)

    完成物を受け取る前提での契約は、バグや機能追加前提で随時修正することの多い最近の開発業態とは相性が悪いことは確かにある。
    でもCOCOAに関しては納品物のチェックなしに(未完成品を)完成品として受け取っていた。アジャイルだ相性だとはまったく別次元の問題だよ。

    ここに返信
    • Re:それ以前の問題 (スコア:4, すばらしい洞察)

      by Anonymous Coward on 2021年05月12日 18時19分 (#4029386)

      行政側に、仕様決めや完成品のテストができる人材が足りてなきゃ、ウォーターフォールだろうがアジャイルだろうが無理。

      • by Anonymous Coward on 2021年05月12日 19時48分 (#4029453)

        行政側に、仕様決めや完成品のテストができる人材がいなければ発注してはいけない、という認識は間違ってないか。
        行政は政策と国民のニーズに基づいて「こういう機能のものがほしい」と要求と予算を割り当てるプロであって、エンジニアリングの専門家ではない。
        その要求に基づきシステムの仕様を決め構築し要求を満たすことを確認するところまでがSIerの仕事であるべきだと思うのだが。

        # まあ、現実はそうなってないよね。

      • by Anonymous Coward

        行政というか、民間も含めて日本の発注側の問題点として延々と言われてることだよね。

        • つーか、発注側よりか受注側の営業の所為だと思うが。

          アジャイルでも、この時点ではここまでの機能をリリースしますってスケジュールが最終クライアント(政府)まで通ってれば問題なく通ることが多い。
          むしろ、追加要望が来た時に、数手先のリリース時に後回ししやすい。

          追加要望が来た時、それを捌けるかも、結局は受注側営業の力量。

          # 営業が不安なら、まともなプロデューサーとか進行管理を用意して営業には口出させるな。
  • by Anonymous Coward on 2021年05月12日 18時26分 (#4029391)

    明文化されてない仕様が出来がち。
    納期もよくわからない。

    ここに返信
    • Re:アジャイル大嫌い (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2021年05月12日 18時53分 (#4029408)

      アジャイルもウォーターフォールでも、無理をしているのは嫌い。生産のパフォーマンスが上がらなければ意味がない。
      アジャイルしましょうが状況を誘発しているのだとは思うけど、ドキュメントが残らないのはアジャイルではなくプロジェクトの非だと思う。

    • by Anonymous Coward

      アジャイルとは違うかもしれないけど、
      対応項目と優先度は決まってて明確な納期がない。
      こっちの切りのいいタイミングで納品していってる。

    • by Anonymous Coward

      あるある。スコープ決めて開発してるはずなのに横から口を出してきて「ここはこういう機能・デザインだと思ってた」と言い出す人が

    • by Anonymous Coward

      ドキュメントは適当でいいし(良い子は真似しちゃダメだぞ)
      優先度順に処理していけばいいし
      納期を気にしなくていいし
      サラリーとの相性がいいし
      それで毎月お金もらえるし
      アジャイル大好き

    • by Anonymous Coward

      ではア ジャイアン スタイルでどうでしょう

      # きれいなのが出てきたらSSR

  • by Anonymous Coward on 2021年05月12日 23時00分 (#4029595)

    要件と納期を決めて外部に丸投げするってやり方は、大昔に建設業界をモデルにして
    人を右から左に流すだけで儲かるとか考えた「請負会社」がアウトソーシングを喧伝して、
    内製からアウトソース(という名の人身売買)をビジネスにしたところが発端。

    確かに専門知識も必要な上に恒常的に人材確保が必ずしも必要ではないシステム開発では、条件さえ
    揃えばコストの削減に繋がる・・・ってことで正当化されてきたけど、実際にはコミュニケーション
    コストや多重請けで抜かれるマージンのせいで金額に見合った品質は怪しかったのも現実。

    その上、今や要件が時流の流れでコロコロ変わるので「納期」には「設計」が時代遅れなことも普通に
    発生してるし、特定組織の業務の一部と化してるシステムでは「開発~保守~運用」のフェーズが
    曖昧なままで恒常的にPDCAを回す必要があったりで、もはやアウトソースを正当化する余地が
    残っていないと思う。

    実際に「巨大IT」って言われるところは内製に回帰してるよね。外注化はいいことが何もない。

    ここに返信
  • by Anonymous Coward on 2021年05月12日 18時17分 (#4029385)

    アジャイルを受け入れてくれる一般企業の発注者、そもそもそんなにいなくない?

    ここに返信
    • by Anonymous Coward

      素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?
      発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいんだから、問題は要求仕様どおりの物が正しく出来ているかどうかがちゃんと確認できるかだけの問題と思うんだけど。
      もちろん途中で状況がかわって仕様変更の必要が出てくる事もあるだろうけど、その時は一旦作業を止めて、変更仕様を提示し、納期や追加費用の交渉をするんじゃないのかな。まあ、追加費用が出た場合にその費用調達が行政機関だと難しいのかもしれないが、それは開発手法に関係ないよね。

      • by Anonymous Coward on 2021年05月12日 18時50分 (#4029405)

        素人考えで申し訳ないけど、そもそもどういう開発のやり方をするかなんて、発注側には関係なくない?

        wikipedia参照ですまないが、
        https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%... [wikipedia.org]

        アジャイル開発では、たくさんの文書を書くことよりも、プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、1か所の作業場所で仕事をする。この場合の関係者には、少なくともプログラマと「顧客」が含まれる

        これが嫌がられるのよな。

        • 孫受け禁止 (スコア:2, 興味深い)

          by Anonymous Coward on 2021年05月12日 20時29分 (#4029490)

          この「文書よりも顔突き合わせて話し合い」っ点からしても多重下請け構造とは相性悪いんじゃないの

          つまり下請け禁止、直接契約を義務付ければアジャイルでも事故りにくいと思うよ

        • by Anonymous Coward

          なんか、今までにない新しい事をしようとしている時には有効な開発手法だと思うけど、接触確認アプリのような、目的がはっきりしていて、他国でも作っているようなものにはむかない開発手法に思える。
          # まあ、仕事を請ける側にとっては責任範囲なんかがあいまいになって都合のいいのかもしれないが。

          • by Anonymous Coward

            COCOA開発当時、どの国も接触確認アプリは開発前もしくは開発中で、まさしく今までにない新しい事をしようとしている時だったんですが、それは……

            • Bluetoothベースのシステムだと世界のほうが早い。
              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

              まぁ、アプリの承認考えれば、国内は割と横並びなのかね?
          • by Anonymous Coward

            ・他国で作っていようが本邦の発注側担当者にとってもベンダーにとっても新しい内容
            ・いくら目的がはっきりしていても、UI/UXやらDB設計などの実現・表現手段が利用者の文化によっても規模によっても千差万別なので、他国の成果物は参考程度にしかならない

            アジャイルについて何か勘違いしてないか?
            アジャイルの利点は素早く軌道修正してリスクを最小化できることだぞ。
            銀行のシステム変更みたいな超大規模プロジェクトなんかには向いてないだろうが、今回みたいな規模・性質のアプリにはまさに向いているように思えるが。

      • by Anonymous Coward on 2021年05月12日 20時13分 (#4029477)

        そもそも要求仕様を定めて動こうとする姿勢自体があまり良くない。
        運用しながらシステムを改善していくのだ。
        仕様は結果でしかない。

      • by Anonymous Coward

        ちゃんとした要求仕様を作成できる発注側なんて日本には存在しません。
        基本的に「良きに計らえ」としか書いてないんだから。

      • by Anonymous Coward
        じゃあ屏風から要求仕様を出してください。
        ってなるでしょ。
        そこをちょっとずつ屏風に絵を描いてくから見ててね、ってのがアジャイルだ。
        • by Anonymous Coward

          屏風を例えにするなら、少なくとも接触確認アプリに関してアジャイルを適用するのは、屏風に虎を書いてくださいとお願いしたら、書いている途中に「虎ってこうですよね」って聞かれながら絵を描いてもらっているような感じに思える。で、最終的に書かれた虎が虎と似ても似つかないようなものになっても、「途中で確認しましたよね」ともいえて、責任範囲があいまいになるような。
          # でも、今回の問題は虎に似ても似つかないものが書かれていたにも関わらず、誰も確認せず、4ヶ月間もそのままだったような事なんだけど。

          • by Anonymous Coward on 2021年05月12日 19時47分 (#4029452)

            あいまいにはならんよ
            確認したんだから確認された側(顧客)の責任
            だから顧客の意思決定者を巻き込まなければいけないとなって日本では難しい
            「こうする」とかその場で一人で決められる人(っていうかその一人に権限を集中する組織?)が少ないよなっていう

      • by Anonymous Coward

        > 発注側としては、要求仕様どおりのものを指定期日までに作ってくれればいい

        極論すれば指定期日は納品物が次期システムにカットオーバーして退役する日ってのが
        アジャイルとかモバイルアプリ運営なんじゃないの

        スタッフのポストを作って関連業務を含めて委託する形じゃなきゃ回らないってわけ

    • by Anonymous Coward

      開発物がモバイルアプリなのかWebサイトなのか物流システムなのか顧客管理システムなのか会計ソフトなのかで大きく変わるんじゃないの

      • by Anonymous Coward

        この中だとモバイルアプリと物流以外はウォーターフォールでやったけど、
        アジャイルはどのあたりのジャンルだと受け入れてくれそうだろうか。

    • by Anonymous Coward

      システムを「発注」するって考え方をする企業にアジャイルは無理でしょう

  • by Anonymous Coward on 2021年05月12日 19時17分 (#4029426)

    たいとるおんりー

    ここに返信
  • by Anonymous Coward on 2021年05月12日 19時37分 (#4029444)

    って言ってればいいんだから、楽なもんだよね
    曖昧な仕様を指摘する必要もなく、要求仕様に満たないものを1.0として納品してOK
    ろくに検収もされないし

    ここに返信
    • 一般論として「行政(の公共調達の仕組み)が悪い」という話は納得できる。
      でも少なくともCOCOAについては、アジャイルで開発が膨れてもそれも飲み込める程度の発注金額だったわけで、
      そのあたりの作業と責任も含めて委託したのだろうと思うと考えると
      COCOAについては行政が悪いというよりは一次請負先が悪い、という話に見えるなぁ。

      --
      # mishimaは本田透先生を熱烈に応援しています
    • by Anonymous Coward on 2021年05月12日 21時31分 (#4029538)

      例えば某所の公示情報だけど・・・

      > 現在のXXの欠落等を生じず、確実に継承出来るソフトウェアを利用すること。
      > 一部カスタマイズされている部分があるため、当該カスタマイズに合わせた運用が可能であること。

      こんな内容でカスタマイズ部分も明示しないまま公示されても、突っ込みどころしか無いじゃないですかー。
      特定業者しか入札に参加できませんよねー
      # 裏で話ついているんだろうなーとしか。

typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...