デジタルトランスフォーメーション(DX)の高まりを受け、企業や行政機関のシステム開発プロジェクトでアジャイル開発の導入が進んでいる。従来のウオーターフォール型ではない開発が増えたことで、ITシステム契約の在り方も変化している。契約面で失敗しないために何にどう気を付けるべきか。事例と専門家の解説からひもとく。
初めての本格アジャイル、準委任型契約で開発
東京証券取引所は2021年2月1日、アジャイル開発の手法を初めて本格的に使った新システムを稼働させた。ETF(上場投資信託)のオンライン取引システムである「CONNEQTOR(コネクター)」だ。機関投資家はCONNEQTOR上で売買したいETFの条件を入力し、マーケットメーカー(値付け業者)に対して価格の提示を依頼する。提示された価格で発注すると、証券会社経由でToSTNeT(東証立会外市場システム)に自動発注される仕組みだ。
稼働後の約5カ月間で金融機関約40社がCONNEQTOR経由で価格の提示を依頼しており、目標としていた10社以上を大きく上回った。稼働来売買代金は100億円を超え、拡大見込みという。CONNEQTORを使った金融機関からの評判は「(取引が)早く簡単だった」と上々で、東証の主要顧客ではなかった信用金庫や信用組合、地方銀行にも広がった。
東証のIT開発部は2019年11月にCONNEQTORの開発に着手した。この際、アジャイル開発を選んだ。ETFのオンライン取引は全くの新規サービスで利用者に対する知見もなく、システムの機能に不確定要素が多かったためだ。ITベンダーの富士通とは、ウオーターフォール型で結んできた「請負型」ではなく、「準委任型」でシステム開発の契約を結んだ。
一般に、システム開発の契約形態には、請負型と準委任型がある。請負型では、受注者はシステムを完成させて発注者に引き渡す義務を負う。一方、準委任型では受注者は委任事務を処理する義務は負うが、完成義務は負わない。情報処理推進機構(IPA)は2020年12月に第2版を公開した「情報システム・モデル取引・契約書」で、ウオーターフォール型は請負型で進めるものとしている。
一方、IPAは2020年3月に公開したアジャイル開発版の「情報システム・モデル取引・契約書」において、アジャイル開発を外部委託する場合は「準委任契約が前提」としている。準委任型では契約時点で最終成果物を明確に決め切れない。東証はCONNEQTOR開発で富士通と結んだ準委任契約では「甲乙協議のうえ、優先順位の高い要求項目から順に、実施期間の範囲内で選択して実現します」としている。
準委任契約でアジャイル開発を進めるには、具体的にはどこに気を付けるべきか。東証のCONNEQTOR開発事例と専門家の解説から3つのコツが浮かび上がってきた。
契約の目的を明確にする
1点目は、契約の目的をできるだけ明確にすることである。多数のシステム裁判で調停を担当し、システム開発を巡るトラブルに詳しいITコンサルタントの細川義洋氏は「目的を定量的に、なるべく具体的に書くように勧める」と話す。一方、駄目な目的の書き方は「〇〇システムをつくること」「コスト削減」といったものだという。この点、東証はCONNEQTORの開発に当たり、「システムではなく(オンラインでのETF取引という)サービスをつくることを目的とした」(近藤誠之IT 開発部課長)。
以下ソース
https://xtech.nikkei.com/atcl/nxt/column/18/01716/070800001/
2で終わってた
>>2
これ
また富士通?!としか
JVみたいなの出来ないもんかね。
うかつにも笑ってしまったw
御意
んでアジャイルなんて言う外製の言葉でマウントされちまうまで変われなかったのホンマ草
cpuを作ってる会社がなんでウォーターフォール方式でシステム作っちゃ駄目なん?
試行錯誤によるソフトウェア開発
大枠を決めて詳細はやりながら詰める開発や、短期間の開発サイクルを繰り返して目的に
近づける開発を指す場合が多い
結論が早く出ることが狙いだから
余計なことは後回しにするんだよ
あと大量のプログラマーなんか抱え込まないんだよ
ちなみに、COCOAが失敗したのは
運用工程すら請負契約でやってたのが原因としてかなりデカいと思う
想定外のことは契約に入らないから、そういう作業が発生したときに
作業の役割分担が不明確になって適当な運用になってしまったとしか思えない
何故請負契約にしたかというと
それが公共事業の慣習だったというだけでなく
請負契約だと全てを請負会社の責任にできるからだと思う
行政は自らの責任を回避するために請負契約に固執してるとしか思えない
みずほのこの手のチャレンジは評価するわ
大規模プロジェクトはそっちの方が上手くいくんじゃないかといつも思ってた
どーせエンドユーザの意見は二転三転して仕様が固まらないし
請負って形式はなんでなくならないんだろうな
結局発注者が素人でリスクが取り切れないのを守るためなんだろうが
それではよい発注者になれない
PMOにコンサル入れるか、富士通から出向者受け入れてやるパターンかもしれんけど。
>>12
仕様を作るところはウォーターフォール開発でも元々準委任契約だし
実際体制は大して変わらないと思う
責任を全部みずほが負うのは良い流れだと思うわ
むしろ今までがおかしかった
この前のトラブルのときベンダーではなく
東証の責任だと言い切るようなところだぞ
そこら辺の覚悟は出来てる会社だ
ユーザー企業側が内製するってのがベースにあるから。
ベンダー企業の割合の多い日本にはアンマッチなんだよ。
現場は、未経験者が場当たり的に開発で失敗の連続だろうね
単にアジャイル言いたいだけか
レガシーな手法にしとけ
まともな運営しろあほ
確かにそうだな。ずっと富士通のエンジニアを東証が抱え込むってのなら成り立つだろうが。
それでしかできない
それしないCOCOAはあんなに小さくても使えないだろ
いろいろヤバイものを感じる
あちこちにスパゲッティが絡まって予算ばかり食うだけのクソ開発になると思うけどガンバレ
それで中抜き出来るんなら良いんだろ。
皿がデカくなって、こんがらがったパスタがデカくなっても良い。
それが芸術的だとも言い出す。
(笑)
>>1
アジャイルなんて船頭多くして船山登るの典型なのに
ライフサイクルコスト考えたら、パッケージシステム+サブモジュールを
自社開発で内製化、それができる社員を雇う、が結果的には、一番安いのに
>>34
パッケージもいいが、業務仕様に合わせた個別のカスタマイズが問題になる。
多かれ少なかれカスタマイズは生じるが、だいたい業務側を変更して、システム側に合わせるのが現実的。
で、複数の業務システムが登場すると、その間での調停やらデータ交換でワケワカメになって、やがて寿命を迎える。
まぁどの道を行っても楽じゃないが、生存中は仕様変更を可能にするため社内エンジニアを育成した方がいいと思う。
>>35
要するに予算吊り上げるために富士通が宣伝文句として使っただけだなw
富士通「今後はアジャイルですからお高くなりますよ」
東証「ぜひアジャイルでよろしくお願いします」
横文字ばっかでわかんねーよ
管理人からひと言
楽しみではる
この記事へのコメントはありません。