908
回編集
差分
ナビゲーションに移動
検索に移動
210行目:
210行目: + + + + + + + + + + + + + + + + + + + +
→第6回(R3-02-25)
*https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/seicho/20210225/agenda.html
*https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/seicho/20210225/agenda.html
*https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/seicho/20210225/gijiroku0225.pdf
*https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/seicho/20210225/gijiroku0225.pdf
<blockquote>
○日本電子計算株式会社(高山部長) 共有しながら進めさせていただきたいと思います。
「アジャイル型システム開発の事例」ということで、御説明させていただきたいと思い ます。弊社は、システム開発の受託会社の位置づけでお話し申し上げたいと思います。
アジャイル型開発の前に、一般的な従来型のシステム開発の特徴をお話し申し上げたい と思います。こちらは、ウォーターフォール型と申しまして、システム開発の工程を順々 に重ねながら進めていく形のものでございます。一般的なシステム開発は非常に開発規模 が大きいことが多くございます。数百人月、数千人月といった規模、開発期間も半年や数 年に及ぶものが多いところでございます。ですので、物を作ってテストをした後に、そこ で仕様が間違っています、仕様が変更になりますと言いますと、大きな手戻りが発生しま して、それまでの作業がある意味で無駄となるということがございます。そのために、一 個一個の工程で品質評価をしながら進んでいくというのが一般的でございます。中でも、 最初の外部仕様を固める、お客様の要件を固める上流工程と呼ばれているポイントが非常 に重要でございまして、ここで仕様を固めて、その仕様に基づいて作業をしていくことに なります。逆に申し上げますと、この最初の上流工程につきましては、まさに仕様が不明 確というところがございますので、一般的に、受託会社としますと、成果物責任を負うよ うな請負型の契約はあまりいたしません。準委任型の契約で上流工程を進めていきます。 この上流工程で仕様が固まったところで、下流工程の物を作るといったところで成果物責 任ありの請負契約としていくのが一般的でございます。
今日の御議論、アジャイル型の開発でございます。こちらに特徴的な話としますと、言 わば新規の業務を実験的にやるような開発が多くございます。ですので、開発規模も小さ くて、開発期間も短く、数か月や場合によっては1日や週単位で納期となるような開発が発生いたします。そういうことを求める開発に適しているのがこのアジャイル型開発と御 理解いただければと思います。こういった新しいものは、仕様が不明確でございます。ま た、急な仕様変更や案件外の要因の割り込みも随時発生してまいります。ですので、優先 順位が変わることが非常に多く発生するということで、まさに作りながら仕様を確定する、 プロトタイプを作って見える化をして仕様を固めて作っていくということになります。そ の点、途中でこの仕様はやめましょうとか、順番を変えましょう、場合によっては打ち切 りますといったことも、ある意味、日常的に行われる可能性があるということでございま す。ですので、受託者側からしますと、いわゆる請負型、成果物責任で行うのは難しいと いうところでございます。課題はあるものの準委任型の契約で最初から終わりまでいくこ とが多いと思っております。こういった開発につきましては、委託者側と受託者側がチー ム一丸となって同じ場所で一緒に働いてフラットなコミュニケーションを行うことが必要 であり、そういう特徴を持っているとお考えいただければと思います。
このアジャイル型の契約の課題でございますが、先ほど大臣からお話もございましたよ うに、偽装請負が鍵といいますか、ネックになってございます。チーム一丸となって同じ 場所で一緒に働いてフラットなコミュニケーションを行うことと準委任における作業指示 を遵守することを、ある意味、両手で話を進めていくことが必要になってくるところが課 題となっているところでございます。
弊社としても、このアジャイル型に関してもやっていかなければいけないというところ でございますが、まず、いわゆるお客様との受託契約という前に、社内システム、社内で 作っていくシステムにつきましてこうやっていこうということで、アジャイル型開発も管 理ガイドラインを整えながらまずは社内でやってみようとしてございます。その話を申し 上げたいと思いますが、先ほど申し上げましたように、下の段のようないわゆるフォーマ ルな指示系統は、受託契約がされている場合は、実際に開発される前に委託者から受託者 に対して開発スコープの指示がされます。細かい一個一個の開発の束、スプリントといい ますけれども、そのスプリント計画のところで詳細化して合意するという作業がされます。 実際にスプリントと呼ばれる開発の束になりましたら、現場の中で、お客様と受託者側、 さらには私どもから再委託するメンバーもございます。そういったメンバーが一体となっ て日常的に会話をして進めていきます。そのときに、システムを使うときもございますし、 ツールを使うこともございます。先ほど申し上げましたプロトタイプを作ってみるといっ たこともございます。その結果、試行錯誤をして、朝令暮改といいますか、やめたり変更 するといったことがリアルタイムで行われてまいります。先ほど申し上げました指示系統 という話とコミュニケーションの間でそごが出てきますと、偽装請負が懸念される場合が 出てきます。ある意味、切り分けてそごのないようにすることは現場に負荷がかかってい るところかと思っております。弊社としましては、まず、社内システム、この辺をシミュ レーションして、今後、お客様に向けて受託契約を進めていきたいと思っているところで ございます。
今日は、こういった開発に携わっているエンジニアがおりますので、現場で働いている エンジニアの感想を少しお話しさせていただきたいと思っております。
伊藤さん、内海さん、忌憚のない御感想をお話しいただけますでしょうか。 ○日本電子計算株式会社(伊藤担当) 日本電子計算の伊藤と申します。よろしくお願い いたします。
まず、先ほどからお話に挙がっておりますとおり、仕様変更などによる作業追加はウォ ーターフォールと比較して多いですけれども、仕様変更などが発生しても手戻りが限定的 で、手戻りに伴う修正規模が非常に小さくなったので、アジャイル型開発になって仕様変 更などの負担が減ったと感じております。
また、プロダクトオーナー、発注元がステークホルダーの意見を集約してバックログ化 しており、また、外部から開発者への直接の指示があった場合には、スクラムマスターが 制御・ブロックをするために、外部から開発者への直接の作業指示がなくなり、開発者は 作業に集中しやすくなったと感じております。
</blockquote>
{{:特別:リンク元/成長戦略ワーキング・グループ}}
{{:特別:リンク元/成長戦略ワーキング・グループ}}
{{DEFAULTSORT:せいちようせんりやくわきんくくるふ}}
{{DEFAULTSORT:せいちようせんりやくわきんくくるふ}}
[[Category:規制改革推進会議]]
[[Category:規制改革推進会議]]