１．
システム開発の方法論についてです。私は、この分野は大好きで、ずっと話せるかもしれませんが、ここではやめておきます。問題文のひとつひとつ話題が違いますので、ひとつひとつ説明していきましょう。
１．DevOps は、開発側と運用側とが密接に連携して、システムの導入や更新を柔軟かつ迅速に行う開発の方法論である。
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。ソフトウェアを迅速にビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻度で可能とする組織体制の構築を目指している。
概要
従来の機能別に分離された組織では、このような開発部門とIT部門の部門間統合はほとんどない。しかし、DevOpsでは、開発部門、IT運用部門、あるいは品質保証（QA）部門が協力するプロセスと方法を推進している。CI/CD が自動テストや頻繁な統合などソフトウェア開発そのものに着目するのに対して、DevOps は CI/CD のような技術的な側面に加えて、開発や運用といった組織的・文化的な側面をも内包する。
DevOpsにビジネス部門を追加したBizDevOpsや、セキュリティを融合させたDevSecOpsというワードも広がりつつある。
定義
学術的な観点から、CSIROとソフトウェア工学研究所の3人のコンピュータサイエンス研究者であるLen Bass、Ingo Weber、Liming Zhuは、DevOpsの定義を「高い品質を確保しつつ、システムへの変更をコミットしてから通常の運用に移るまでの時間を短縮することを目的とした一連のプラクティス」とすることを提案している。しかし、2015 年現在、DevOpsという用語は複数の文脈で使われている。
「DevOps」『フリー百科事典 ウィキペディア日本語版』。2023年1月31日 (火) 18:05 UTC、URL: DevOps - Wikipedia
昨今は方法論の乱立が目立ってきている気がして、実際の開発の現場は、次はあれがいいって言われているので、取り入れてみようか、アジャイルも流行っているらしい、DevOpsは？現場は、流行りに惑わされることが多いです。
DevOpsも、思想としては理解できますが、Wikiにも 書いているように、いまいちこれがDevOpsっていう立ち位置を確立していません。アジャイル開発手法もかな。思想が先行して、実際の開発プロセスにどう適用するかというのは、イメージが人により異なっていき、様々な派生を生み出してしまい最後は破綻していきます。
DevOpsもその名が表す通り、開発と運用が協力、あるいはその境を曖昧、統合して開発していくことにより、柔軟、かつ変化への対応を早くしていくことを目的としています。決して、大きな開発を、素早くできる開発プロセスだと言っているわけでは無く、変化が速いIT業界の性質から、その変化に即時対応し、細かく素早く確実にリリースするために、IT運用分問の人間も交えて、開発を進めていけばいいだろって考え方です。
アジャイルの発展形のような位置づけで語られることも多いですが、個人的には思想はよくよく分かりますが、いざその体制づくり、開発プロセスの具体化となると、イメージが沸かない、現実的ではないなど、ネガティブな印象が否めません。小規模な開発、小規模な機能にフォーカスした開発ならできるのでしょうけど。
と、いうところで、問題文に戻ると、文章は正しいですね。これが正解です。
２．XP は、開発の基幹手法としてペアプログラミングを用いる方法論であり、ウォーターフォール型開発を改善したものである。
XPはエクストリームプログラミングの略称で、昔はよく聞いたが、最近はその用語をあまり聞くことが無くなった気がする。しかし、そこまで悪い意味でもなく、良い意味では役立つプラクティスは、アジャイルの一部となり、日常的なあ開発プロセスとして染み込んでしまい、あえてXPという単語を使わなくなったのではないかなと思います。一方で、なかなかなじまない現実的ではない概念も含まれていて、XPは全てを取り込むことは難しいものであったと思います。
エクストリーム・プログラミング、XP（英: Extreme Programming）は、 ソフトウェア品質 を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。アジャイルソフトウェア開発の一つとして、短い開発サイクルで頻繁に「リリース」することを推奨することで、生産性を向上させ、新しい顧客の要求を採用するためのチェックポイントを導入することを意図している。
エクストリーム・プログラミングの他の要素には、ペアでのプログラミングや広範なコードレビューの実施、すべてのコードのユニットテスト、機能は実際に必要となるまでは追加しない、フラットな管理構造、コードのシンプルさと明快さ、時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する、顧客やプログラマーでの頻繁なコミュニケーションなどがある。この方法論は、伝統的なソフトウェアエンジニアリングのプラクティスの有益な要素を「極端な（エクストリームな）」レベルに持っていくという考えからその名前を取っている。例えば、コードレビューは有益なプラクティスと考えられており、これを極端にすれば、コードを「継続的」にレビューする、つまり、ペアプログラミングのプラクティスとなる。
「エクストリーム・プログラミング」『フリー百科事典 ウィキペディア日本語版』。2022年7月15日 (金) 08:13 UTC、URL: エクストリーム・プログラミング - Wikipedia
エクストリーム・プログラムは、以下のことが目的であり、アジャイルソフトウェア開発の一つであります。
- ソフトウェア品質を向上
- 変化する顧客の要求への対応力の向上
特に、短い開発サイクルでえ頻繁にリリースすることを推奨としているところは、アジャイルから敬称されるところで。生産性を向上して、新しい顧客の要求を柔軟に採用するために、チェックポイントを導入する仕組みなわけですね。
問題に戻りましょう。
XP は、「開発の基幹手法としてペアプログラミングを用いる方法論」というのは、やや基幹手法と言う言葉にはひっかかるところもありますが、ペアプログラミングはXPを構成する主要な要素ということで、合っていると言えるでしょう。XPといえば、ペアプロを思い起こす人も多いのではないでしょうか。
「ウォーターフォール型開発を改善したものである」
これは、明らかに違います。ウォーターフォールトは、要件定義、設計、実装、テストを滝が流れるように一方向で実施する開発手法であり、短納期で回すアジャイルの流れをくむ手法とは真逆の開発プロセスです。この文章は誤りです。
３．ウォーターフォール型開発は、全体的なモデルを作成した上で、ユーザにとって価値ある機能のまとまりを単位として、計画、設計、構築を繰り返す方法論である。
ウォーターフォール型については、前の問題でも言ったように、一連の開発の流れを滝の流れのように、一方向で実施する方法です。それに対し、繰り返しモデルは、ウォーターフォール型におけるデメリットで、要求が変化した場合の後戻りが大変といった短所を、ユーザにとって価値のある機能を単位に、小さな開発に分けて、それを繰り返すことにより、後戻りを最小限に抑えるやり方です。
繰り返しモデルの開発手法は、スパイラル、昨今ではアジャイルと呼ばれています。スパイラルとアジャイルは、観点がスパイラルのころは、ソフトウェア品質に重点が置かれ、昨今のアジャイルは、ユーザ要求に重点が置かれているなど、時代によった違いはあれど、類似していると言えるでしょう。
というわけで、問題文は繰り返しモデルの説明になり、ウォーターフォール型開発の説明ではありません。誤りです。
４．スクラムは、動いているシステムを壊さずに、ソフトウェアを高速に、着実に、自動的に機能を増幅させ、本番環境にリリース可能な状態にする方法論である。
スクラムと聞いて、ラグビーのスクラムか軽微な反則のあとに、肩を組んで相手チームとぶつかってボールを取り合うあれですね。
いえ、しかし、今はソフトウェア開発の話であり、スクラムはそれではありません。言葉の由来はこのラグビーのスクラムから来ており、これは開発手法のひとつであり、現在はアジャイル開発手法の重要なプラクティスとしてまとめられています。
プロダクト開発におけるスクラム（英: Scrum）は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すための軽量級フレームワークである。
概要
複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。
スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。
スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。
スクラムチーム
スクラムチーム（英: Scrum Team）はスクラムの基本単位となる小さなチームである。
スクラムチームはスポーツチームのように機能しなければならない。各メンバーは高い専門性を持ちながら自らのポジションに拘泥せず、1つのゴールを目指し全員が1つのチームとして協力する。つまり専門分野（例: マネジメント、エンジニアリング、デザイン）をもつ様々なプロフェッショナルが分野にとらわれず、1つのプロダクトゴールへ焦点を合わせプロダクト開発を行うチームがスクラムチームである。
スクラムチームはプロダクトゴール達成に必要な全ての活動を責務とする（必要な権限とそれを行使する責任を持つ）。すなわち開発において、どのメンバーが何（what）をいつどのように（how）行うかはスクラムチーム自身が決定し自己管理する[21]。価値ある成果物を生み出す（プロダクトゴールを達成する）ことに関して、チームとしてステークホルダーに対する説明責任を負う。
スクラムチームは適応型プロダクトを開発する。ゆえに適応に必要な速度を担保できるサイズの小ささが必要であり、1チーム10人以下が推奨される。
スクラムチームには以下の3つの明確な役割・責任が定義される。
プロダクトオーナー
プロダクトオーナー（英: Product Owner）は製品の総責任者である。 顧客の意思の代表としての役割を担う。 ビジネスの視点（ROI等）においてプロジェクトに問題がないことを保障する役割を持つ。 顧客の要望をプロダクトバックログに優先順位を付けて反映させる。
スクラムマスター
スクラムマスター（英: Scrum Master）はスクラムフレームワークが正しく適用されていることを保証する役割である。権限としては間接的である。主な作業は、チーム内外の組織間調停(ファシリテーション)と外部妨害を対処することとされる。従来のプロジェクトマネージャがこの役割を担うことが多いが、プロジェクトそのものを管理するわけではない。
開発者
開発者（英: Developer）は各スプリントにおいて、利⽤可能なインクリメントの あらゆる側⾯を作成することを確約する役割を担う。開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。
「スクラム_(ソフトウェア開発)」『フリー百科事典 ウィキペディア日本語版』。2023年1月5日 (木) 16:33 UTC、URL: スクラム (ソフトウェア開発) - Wikipedia
短納期で、さらに要求変化への柔軟な取り込みのために、小規模チームによる開発の運営を目指し、各メンバーが専門分野を持ちながらも、そのチームの中では、壁を作らず、自律的に対処をしていく適応型ソリューションを可能にするチームです。10人以下が推奨であって、そのチームの中で、ある種、開発プロジェクトが回され、ある程度の変化はそのチーム内で適応していくことができます。アジャイル手法のプラクティスのひとつであり、まさにアジャイルにおける主要な開発手法といえます。
問題文に戻りましょう。
スクラムは、
「動いているシステムを壊さずに、ソフトウェアを高速に、着実に、自動的に機能を増幅させ、本番環境にリリース可能な状態にする方法論である」。
明らかに誤りですね。スクラムの説明になっていないです。
５．フィーチャ駆動開発は、開発工程を上流工程から下流工程へと順次移行し、後戻りはシステムの完成後にのみ許される方法論である。
まず、この説明がウォーターフォール型の説明だというのがすぐに分かりますね。滝の流れのように一方向に進み、終わらないと後戻りができない開発手法です。すでに誤りですが、フィーチャー駆動開発について調べておきましょう。日本語では、ユーザ機能駆動開発となります。
ユーザー機能駆動開発（ユーザーきのうくどうかいはつ、英: Feature Driven Development, FDD）は、反復的ソフトウェア開発工程の一種。アジャイルソフトウェア開発手法の1つでもある。FDD は業界におけるいくつかのベストプラクティスを混合したものである。それらは全て、顧客にとっての機能価値（feature）という観点で駆動される。その主な目的は、実際に動作するソフトウェアを繰り返し、適切な間隔で提供することである。
「ユーザー機能駆動開発」『フリー百科事典 ウィキペディア日本語版』。2021年7月31日 (土) 02:45 UTC、URL: ユーザー機能駆動開発 - Wikipedia
ユーザ機能駆動開発についても、アジャイルソフトウェア開発手法の１つとなっており、プラクティスとしてまとめられています。特に、ユーザに対する機能価値という単位において、開発プロセスを考えた手法となります。
以上より、１が正解となります。
