非ウォーターフォール型開発 WG

活動報告書

平成 23 年 3 月 31 日

平成 24 年 3 月 26 日改訂

独立行政法人情報処理推進機構

ソフトウェア・エンジニアリング・センター

改訂履歴

項

番

改訂内容

改訂箇所等

公開日付

新規公開

－

2011 年3 月31 日

平成23 年度非ウォーターフォール型開発WG／契約問題PT 活動による、契約モデル・契約書案改訂に伴う修正を実施

第四部

付録 1～5

2012 年3 月26 日

システム構築やソフトウェア開発においては、対象のシステムやソフトウェア、及びそれらが使用される社会やビジネス環境の特徴（ここでは、これらを“コンテキスト”と称する）に応じて最もふさわしい形態で行うことが望ましい。独立行政法人情報処理推進機構(IPA)/ソフトウェア・エンジニアリング・センター(SEC)では、コンテキストに適したシステム構築・ソフトウェア開発形態を選択するための考え方を整理しようとする取組みを行っている。

数年前、わが国において、ソフトウェアの不具合を主要因とする重要インフラ情報システム等の障害が頻発し、国民生活や社会経済活動に大きな影響を及ぼしたことは、いまだ記憶に新しい。その後、それらの経験に基づく教訓をもとに、上流工程における品質確保や、ソフトウェアライフサイクルプロセスに基づく開発管理の徹底等の施策が進められた。これらは、いわゆる「ウォーターフォール型」のソフトウェア開発である。その結果が功を奏し、最近ではシステム障害の報道件数が減少傾向にある。

一方、昨今、ビジネスの進展スピードの高速化は著しく、ビジネス環境の変化が激しくなっている。そのため、ビジネスに戦略的に活用されている情報システムに対しても、ビジネス環境の変化に迅速に対応することが一層求められるようになっている。このようなコンテキストにおいては、従来のウォーターフォール型のソフトウェア開発形態では十分に対応できないことが多い。こうした中で、アジャイル開発等、「非ウォーターフォール型」の開発形態が成功を収めている事例も、少なからず報告されている。

ウォーターフォール型開発形態でソフトウェア開発を経験してきた人たちにおいては、非ウォーターフォール型開発形態について十分に理解されているとは言えない。また、わが国のソフトウェア産業の仕組みに照らした非ウォーターフォール型開発の課題もいくつか指摘されている。本書は、ウォーターフォール型開発形態に馴れ親しんだそのような人たちを対象に、非ウォーターフォール型開発形態についての整理された情報を提供することを主目的とする。また、非ウォーターフォール型開発形態に馴染んでいる人たちに対しても、対象ソフトウェアのコンテキストに適しているかを今一度検証してもらうことに使用して頂きたいと考えている。本書が、これらの人たちにとって、対象ソフトウェアのコンテキストに応じた最適な開発形態を選択するためのヒントとなれば幸いである。

本報告書は 5 部から構成される。まず、第一部で、非ウォーターフォール型開発検討におけるアジャイル開発の位置づけを明らかにする。次に、第二部において、本検討の前提とするアジャイル開発のモデルを設定する。その後、非ウォーターフォール型開発における技術及びスキル、非ウォーターフォール型開発にふさわしい契約について、第xx、第四部で、それぞれ検討する。最後に、第五部で、アジャイルにまつわる開発手法体系の歴史と動向について紹介する。

第一部非ウォーターフォール型開発検討におけるアジャイル開発の位置づけ

１背景と目的

１・１非ウォーターフォール型開発に向けた検討の背景 ‌

ウォーターフォール型でないソフトウェア開発手法、すなわちアジャイル開発など「非ウォーターフォール型」の開発手法は、日本国内のソフトウェア開発においても、Web アプリケーションや Web サービス開発などを中心に広がり、競争力のある製品およびサービス開発、顧客ニーズへの迅速な対応、開発者、技術者のモチベーションxxxに成果を上げている。IPA/SEC では、「非ウォーターフォール型」開発手法の成果の源を分析し、その適用領域や適用方法について整理するための検討に取り組んでいる。

また、この検討の結果として、日本のソフトウェア産業全体が同様の成果を享受できるようになることを期待している。

この非ウォーターフォール型開発の検討は、国内におけるソフトウェア開発の状況として、以下の３つを背景としている。

①ビジネスニーズへの適切な対応

②ウォーターフォール型開発における問題

③ソフトウェア産業構造上の課題

（１）ビジネスニーズへの適切な対応

ビジネスの世界では、他社に先駆けた製品やサービスの市場投入が必須で、それにより徐々に明確となる顧客ニーズを迅速に反映し改善していくことが必要な分野が出現している。また、顧客ニーズは最初に全ては把握できず、把握できたニーズもビジネス環境の激しい変化に伴い変化するが、その状況に迅速な対応が必要となっている。

その結果、情報システム及びそれが実現するサービスに対し、早期サービス提供と効果確認、ニーズ変化への俊敏な対応が求められている。

これらに対応するために、ソフトウェア開発においてもビジネスのスピードに追いつくための開発方式が必要となっている。

（２）ウォーターフォール型開発における問題

ウォーターフォール型開発では、ソフトウェア開発の初期段階で全ての要求内容を確定することを前提とする。そのため、誤要求や要求の誤解が総合テストの段階で判明すると、手戻りやスケジュール遅延等、多大な影響を引き起こし易い。また、開発期間が長期になる大規模システムでは、外部環境変化の影響で顧客の要求そのものが変化することもあり、ウォーターフォール型開発での対応が難しくなっている。

これらのリスクを軽減するための一手法として、要求確定部分からのxx開発開始と妥当性の早期確認が、昨今、提案されている。

また、ウォーターフォール型開発で発生しやすい手戻りの防止やプロジェクトマネジメント・リスクの早期低減、顧客側と開発側のギャップ解消も、ウォーターフォール型開発の課題として指摘されている。

（３）ソフトウェア産業構造上の課題

日本のソフトウェア産業において、若年世代を中心としたソフトウェア開発技術者の元気がなく、プロジェクトへの参画意識や達成感が低いということが問題として指摘されている[1]。

また、ソフトウェア産業は多重下請構造に支えられており、その産業構造は大きな問題と指摘されている[2]。

これらの問題を解決するためには、開発の過程と各開発技術者の役割や成果を可視化する工夫が必要であり、非ウォーターフォール型開発を取り入れることにより、創造的な開発スタイルや開発者技術者のモチベーション向上、多重下請構造への対処が実現できるのではないかと期待されている。

１．２非ウォーターフォール型開発に向けた検討の目的 ‌

情報システムの開発を大別すると、要求が変化しないことを前提としたウォーターフォール型開発と、要求が日々変化することを前提とした非ウォーターフォール型開発の二つタイプがあると考えられる。

ウォーターフォール型開発は、高信頼性が求められる基幹システム等、過去のほとんどの分野で実績がある。これに対し、非ウォーターフォール型開発は、情報システムを市場へいち早く提供していくことに価値があると考えられる分野に向いている。特に、開発形態が多様化している後者において、非ウォーターフォール型開発の適用に適した領域を見定め、その活用を促進していくことを本検討の目的とする。

また、現在、非ウォーターフォール型開発があまり適用されていない領域においても、非ウォーターフォール型開発の特質を明らかにすることにより、非ウォーターフォール型開発の今後の適用を検討していく。

非ウォーターフォール型開発に向けた検討の結果、考えられるメリット例は以下の通り。

①日本のソフトウェア産業の実態に適しており、かつ世の中のパラダイム転換に対応することのできるソフトウェアの作り方の提案になる。

②グローバルな視点から見たわが国のソフトウェア産業の競争力を強化することにつながる。

③優先度の高い機能からxx提供され、提供された機能を検証、投入することで、変化が激しく、優先度も変化するビジネス環境に対応できるサービスやシステムを手に入れられる[3]。

④エンジニアが自分自身の成長を実感でき、開発したシステムが利用者の役に立っていると実感できることで、エンジニア一人ひとりが生き生きと働くことのできる環境の整備につながる。

日本のソフトウェア競争力を高める生き生きと働ける環境を作る

日本のソフトウェアの作り方

目指すべきゴール領域

特定

非ウォーターフォール開発

図表 1-1 非ウォーターフォール型開発の目指すべきゴール

また、アジャイル開発の一手法であるスクラムは、一橋大学のxxxxx・xxxxx共著による論文「The New New Product Development Game」（Harvard Business Review 1986 年 1～2 月号）にその名前の由来 1 をもっており、さらに、その起源において、リーンに大きく影響されている。

リーン生産方式は、1980 年代にトヨタ生産方式を中心とした、日本の自動車産業の強さの秘訣を体系化したものである。リーンの考え方（リーン・シンキングの応用）は、製造業から始まり建築、医療、サービス産業へと波及し、製品開発の分野でも最近、リーン・プロダクトデベロプメント、リーン・エンジニアリング、として浸透してきた。

米国で 2003 年に発表されたリーンソフトウェア開発では、ソフトウェア開発にリーン生産方式を適用する考え方が提唱された。リーンソフトウェア開発においては、「ムダの徹底的な排除」や「品質の作り込み」、「全体を最適化する」等の原則を元に、ソフトウェア製品を素早く提供することの重要性が提唱され、これらの原則に加え、現場で働く人々が考える環境の醸成、人間性尊重の概念も重要な基盤としている。

さらに、現在、米国のINCOSE2 においても、リーンをシステムズエンジニアリング分野に適用するためのLEfSE (Lean Enablers for Systems Engineering)が議論されている。

このように、日本に起源を持つリーンが世界のさまざまな産業を変えさらにソフトウェア開発にも浸透してきていることを誇らしく思うと同時に、現在の日本の産業構造に適したソフトウェア開発のあり方、開発者のワークスタイルのあり方、グローバルビジネス環境の中で国際競争力のあるソフトウェア製品やサービスについて、私たちは再度自分たちで考える契機と捉えている。

1 この論文中で、富士ゼロックスの FX-3500 の製品開発においては、開発フェーズが重なりあっている（刺身システム）ことが成功要因となっていると指摘されている。また、ホンダのシティ 1200CC の開発では、実作業を担うメンバ個々人が責任と権限を持ち、メンバ全員がxxとなって開発に取り組んだ（ラグビーシステム）ことが成功要因となっていると指摘されている。

2 INCOSE(International Council on Systems Engineering) .－ Systems Engineering Handbook v.3.2－

２アジャイルとは何か ‌

ここでは、再度、この活動で使われる「非ウォーターフォール」および「アジャイル」という言葉を定義する。

ウォーターフォール型のソフトウェア開発では、品質の高いソフトウェアを生産性高く開発するために、開発初期に要求の固定をはかり、ドキュメントの形で仕様を形式化してソフトウェア・エンジニアリング的な開発モデルに乗せようと努力してきた。

しかし、そもそも要求が刻々と変化している場面では、要求を固定すること自体が製品やサービスの販売リスクを拡大してしまう場合が多い。また、開発の中には技術リスクが大きく、実際に作ってみないとそのリスクを解消できない場合がある。このような状況においては、従来のウォーターフォール型ではない、別のソフトウェア開発モデルが必要とされてきている。

ここでは、「非ウォーターフォール」という言葉を使って、広くこの文脈を表現している。

２．１非ウォーターフォール型開発の定義 ‌

非ウォーターフォール型開発とは、仕様を開発前に固定し、それを分析、設計、テスト等のフェーズをxx踏んでいくという 1970 年の Xxxxxxx X. Xxxxx の論文「Managing the Development of Large Software Systems」でのウォーターフォール型開発 3以外の開発モデルの総称である。

非ウォーターフォール型開発の例として、

・プロトタイプ (Xxxxxxxxx X.Xxxxxx, Xx.－1975 年「人月の神話」)

・スパイラル (Xxxxx x. Xxxxx－1988 年

「A Spiral Model of Software Development and Enhancement」)4

・RAD (Xxxxx Xxxxxx－1991 年「ラピッドアプリケーションデベロップメント」)

・RUP (Xxxxxxxx Xxxxxxxx－2000 年「ラショナル統一プロセス入門」)

・アジャイル

Evo (X.Xxxx－1981 年「Evolutionary Development」)

Scrum (Xxx Xxxxxxxx－1993 年「アジャイルソフトウェア開発スクラム」) DSDM (1995 年「DSDM ver1」)

XP (Kent Beck－1996 年「XP エクストリーム・プログラミング入門」)

3 この論文では、ウォーターフォールの言葉は使われておらず、下流工程までを予備的に行って上流工程へ戻る「フィードバックループ」が推奨されている。

4 スパイラル開発は、ウォーターフォール型大規模開発でも使われており、プロトタイプ開発は、ウォーターフォール型開発の要件定義工程でも使用されている。

FDD－Feature-Driven Development

(Xxxxx Xxxx－1997 年「Java エンタープライズ・コンポーネント」)

Lean Software Development

(Xxxx Xxxxxxxxxxx, Xxx Xxxxxxxxxxx－2002 年「リーンソフトウェア開発」) Crystal Clear (Xxxxxxxx Xxxxxxxx－2004 年「アジャイルソフトウェア開発」)

EssUp－Essential UP

(Xxxx X.Xxxxxxxx－2005 年「Rational Software Development Conference」) Xxxxxx (Xxxxx Xxxxxxxx－2010 年「Kanban」)

を含む Agile Manifesto(後述)に則る手法がある。

これらの非ウォーターフォール型開発の代表例が、1990 年代後半に現れたアジャイル開発である。本資料では、アジャイル開発を非ウォーターフォール型開発の代表例として論じている 5。

5 アジャイル以前の繰り返し型開発を、IID(Incremental and Iterative Development)と総称することもある[4]。

２．２アジャイル開発の定義 ‌

アジャイル宣言 6の４つの価値と１２の原則を満たすソフトウェア開発手法をアジャイル開発とする。

要約すると、

アジャイル開発とは、不確実なビジネス環境の中で変化するニーズへの迅速な対応を目的としたソフトウェア開発手法である。

この目的を達成するために、アジャイル開発は、徐々に明確となる顧客ニーズや要件をシステムへ反映し、プロジェクトマネジメント・リスクの早期低減、顧客側と開発側のギャップを解消する。アジャイル開発の主要な特徴は以下のとおり。

アジャイル開発は、

 「顧客の参画の度合いが強い」

 「動くソフトウェアを成長させながら作る」

 「反復・漸進型である」

 「人と人のコミュニケーション、コラボレーションを重視する」

 「開発前の、要求の固定を前提としない」

という特徴をもつ。

以下に、アジャイル宣言を引用する。

・アジャイル宣言（Agile Manifesto）における４つの価値

私たちは、ソフトウェア開発の実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下のことを重視する。

①プロセスやツールよりも個人と対話を、

②包括的なドキュメントよりも動くソフトウェアを、

③契約交渉よりも顧客との協調を、

④計画に従うことよりも変化への対応を、

すなわち、①～④の各文の前者（「よりも」の前の言葉）に価値があることを認めながらも、私たちは後者（「よりも」の後の言葉）の事柄により価値をおく。

6 アジャイル宣言（Agile Manifesto）は、アジャイルな開発手法の提唱者 17 名が集まって、2001 年に発表された。

xxxx://xxxxxxxxxxxxxx.xxx/xxx/xx/xxxxxxxxx.xxxx

・アジャイル宣言（Agile Manifesto）の背後にある 12 の原則

私たちは以下の原則に従う。

①顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。

②要求の変更はたとえ開発の後期であっても歓迎する。

変化を味方につけることによって、顧客の競争力を引き上げる。

③動くソフトウェアを、２-３週間から２-３ヶ月というできるだけ短い時間間隔でリリースする。

④ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く。

⑤意欲に満ちた人々を集めてプロジェクトを構成する。

環境と支援を与え仕事が無事終わるまで彼らを信頼する。

⑥情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることである。

⑦動くソフトウェアこそが進捗の最も重要な尺度である。

⑧アジャイル･プロセスは持続可能な開発を促進する。

一定のペースを継続的に維持できるようにしなければならない。

⑨技術的卓越性と優れた設計に対する不断の注意が機敏さを高める。

⑩シンプルさ（ムダなく作れる量を最大限にすること）が本質である。

⑪最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される。

⑫チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する。

３アジャイル開発に適した領域・試行領域 ‌

本書においては、すべてのソフトウェア開発にアジャイル開発を適用できる、あるいはすべきだ、という立場ではない。ビジネスや市場、その他の開発の文脈によって、ウォーターフォール型の開発が適している場面もあれば、アジャイル型の開発が適している場面もある。ここでは、現時点で、アジャイル開発が適用されてきている領域と未だ適用されておらず、適用するにしてもアジャイルをそのままでは適用できず、さらなる拡張や工夫が必要とされる領域を特定したい。

大まかには、開発当初に要求を確定せず、ビジネス環境の変化に伴った市場や顧客ニーズの変化への対応が最優先される分野が、アジャイル開発が最も得意とする第一適用領域である。他方、基幹システム等で開発当初に要求をあるレベルで確定可能（あるいは確定すべき）な領域のシステムの開発においては、現在のアジャイル開発は試行領域となっている。

３．１アジャイル開発に適した領域 ‌

アジャイル開発は、「顧客の参画の度合いが強い」「動くソフトウェアを成長させながら作る」「反復・漸進型である」「人と人のコミュニケーション、コラボレーション重視」「開発前の、仕様の固定を前提としない」等を特徴とするため、以下の領域での開発を得意とする。

①ビジネス要求が変化する領域

・要求の変化が激しく、あらかじめ要求が固定できない領域。

②リスクの高い領域

・不確実な市場を対象としたビジネス領域（市場リスク）

・技術的な難易度が高い開発領域（技術リスク）

③市場競争領域

・他社に先駆けた製品・サービス市場投入が命題で、TTM（Time to Market）の短縮が優先となる領域（Web のサービス、パッケージ開発、新製品開発）。

３．２アジャイル開発の試行領域

アジャイル開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められているのは、以下の領域である。

①大規模開発

アジャイル開発はコミュニケーションを重視するために、開発者 10 人程度の規模が最もうまく機能する。これを超えると、システム分割、チーム分割が必要となる。この場合、サブシステムやチームの分割方法、および、そのチーム間のコミュニケーションについては課題であり、さまざまな方法が提案されている。

②分散拠点（オフショア含む）開発

アジャイル開発はコミュニケーションを重視するために、コロケーション（１つの場所に集まったチーム）が原則である。開発拠点が分散し、さらに時差によって分断される場合のコミュニケーション手法、また、それをサポートするツールの必要性が指摘されている。

③組織（会社）間をまたぐ開発チームによる開発

アジャイル開発は、共通のビジネスゴールをもったチーム、を前提とする。会社や組織をまたいだ構成のチームでは、このような体制を組むことが難しい。

特に、日本では複数の会社が契約をまたいでチームを構成することが多いため、これが大きな課題になる可能性がある。

④組込みシステム開発

ハードウェアの開発と並行してソフトウェアが開発され、高信頼性が求められる組込みシステムでは、リリース後のソフトウェアの修正が極めて困難であることからも、アジャイルの特性の一部が適用しにくく、採用には工夫を要する。

大規模、分散については、現在多くのシステム開発がこれを避けられなくなってきていることもあり、かなりの事例が出ている。さらに、開発組織全体をアジャイルに転換する企業も増えており、組織改革と同時に企業戦略としてアジャイルが採用されている例も多い。

以下、前頁のケースの現在を列挙する。

xxxxxxxxxx.xxx Co., Ltd.が全社を挙げて Web のサービス開発にアジャイルを採用した事例。

xxxx://xxx.xxxxxxxxxx.xxx/xxxxxxx/xxxxxxxxxxxxx-xxxxx-xxxxxxxxxxxxxx-xxxxx-0000-xxxxx ence

xxxx://xxx.xxxxxxxxxx.xxx/xxxx/xxxxxxxxxx-xxxxx-xxxxxxx-0000-xxxxxxxxxxxx

IBM が社内の大規模パッケージ開発にアジャイルを適用した事例。

xxxx://xxxxx.xxxxx.xxx/xxxxxx/xxx-xxxxxxxx-xxxxx-0000

モトローラの事例を含む、大規模アジャイル開発への XP を適用

Large-Scale Agile Software Development.

xxxx://xxx.xxxxxx.xxx/Xxxxx-Xxxxx-Xxxxx-Xxxxxxxx-Xxxxxxxxxxx-Xxxxxxx/xx/0000000 450

British Telecom のアジャイル組織適用事例

xxxx://xxx.xxxxxxxxxxxxxxx.xxx/xxxxxxx/xxxxxxx.xxx?xxx00

その他、アジャイルの大規模適用に関する書籍

xxxx://xxx.xxxxxx.xx.xx/xx/0000000000/

さらに、組込みについても、品質を早期に高める手法、テスト中心の手法として、逆にアジャイルのよい特性を利用する事例が出ている。

組込みでのアジャイルのレポート。豊富なメトリクスがある。

「Embedded Agile Project by the Numbers with Newbies」[Xxx Xxxxxxxxxxxxxxx] xxxx://xxx.xxxxxxxxxxxxxxxxx.xxx/xxxxxxxxxxxx.xxxx#xxxxxxx

組込みへのアジャイル適用

（Embedded Systems ConferenceBoston October 2008 資料より）

xxxx://xxx.xxxxxxxxxxxxxxxxxxx.xxx/xxxxx/xxxxxxxx/XXX-000Xxxxxx_Xxxxxxxx-x0x0.xxx

その他、組込みでのアジャイルの事例のリストがここから参照可能。

xxxx://xxx.xxxxx.xxx/xx/xxxx/0000/00/xxxxxxx-xxxxxxxx-xxxxx

③は、日本では産業構造から、契約の課題が避けられないケースが多い。その中でも、挑戦的な例として、リクルートが契約をまたぐプロジェクトチームでアジャイルを適用した事例がある（アジャイルジャパン 2009 より）。xxxx://xxx.xxxxxxxxxx.xxx/xxxxxxx/XX_Xxxxxxx.xxx

４アジャイルのメリットと今後の課題 ‌

アジャイル開発を様々なコンテキストの開発で利用するにあたり、いろいろな立場や背景の方にそのメリットを理解して頂く必要がある。ここでは、顧客 7の視点とシステムの開発者の視点、それぞれから見たアジャイル開発のメリットとソフトウェア・エンジニアリング上の主な課題をまとめた。

①顧客から見たメリット

・動くソフトウェアで、気になる点が早く確認できる。

・最初からすべての要求が出揃わなくても開発を始めることができる。

・要求の優先順位や、要求そのものの変更に柔軟に対応できる。

・リスクを早期に軽減できる。

・無駄なものを作りださない。

顧客から見た場合、開発の早期に実際に動くものが見える、という安心感がある。最終のテストまでリスクが除去できないウォーターフォール型開発とはこの点が大きく異なる。また、全要求をあらかじめ揃える必要がなく、要求の優先順位を変えることができるので、ビジネスの状況をみながら最終的に最も ROI の高い成果に近づけることが可能となる。最初に要求を固めないので、要求が開発中に劣化してしまうリスクも回避していることになる。

②システムの開発者から見たメリット

・システム利用者の価値と対応させながら仕事を進められる。

・短いサイクルで経験を積み上げ、チームとして成長できる。

・達成感によるモチベーションを維持できる。

これらによって、開発者は責任感とプロ意識を持って生き生きと仕事ができる。

開発者から見た場合、「指示された要求を満たす」だけではなく、利用者の立場でシステムの価値と自身の仕事の価値を結びつけるよう、考えることができる。また、繰り返し開発の中で、技術的な学習、業務の学習をしながら成長し、リリースの都度、顧客とともに達成感を得ることができる。プロフェッショナルとしての仕事のやりがいを、アジャイル開発によって取り戻すことができる。

ただし、上記のようなアジャイル開発のメリットを享受するためには、以下のような意

7 「顧客」という言葉は広い意味を持っているが、開発プロジェクトごとに異なる意味で使われている。本書で使用されている「顧客」は、「顧客企業」および「エンドユーザ」という開発者（作る人）以外の関係者（ステークホルダー）として使用されている。

組込みソフトウェアや製品開発、Web サービス開発などの領域も含めて、「顧客」や「ステークホルダー」の意味をコンテキストごとに捉え直すことや、それらに対しての価値を示すことがアジャイル開発ではより重要になる。

識と行動が前提となっている。

・開発者が顧客のビジネスを理解している。

・顧客がチームの一員として参画し、タイムリーな意思決定を行う。

・顧客および開発者が、スコープの変更を許容する。

このように、顧客も開発者も、アジャイル開発においてはゴールを１つにした意識が必要である。このため、日本では契約のあり方が１つの課題となる。

コラム

システムインテグレーションとアジャイル開発（1/3）

アジャイル開発の適用例・成功例のリストを眺めていると、アプリケーションの自社開発、開発ツールや業務パッケージ自体の開発などが多いことに気がつく。一方で、欧米においてはパッケージ導入と、アプリケーションの自社開発の比率が高く、日本においてはユーザ企業とシステムインテグレーターとの受委託によるアプリケーションのスクラッチ開発の比率が高い点は良く指摘される。したがって、受委託によるスクラッチ開発が多いことは、日本においてのアジャイル開発の適用比率が低い原因の一つではないかと思われる。

また、日本においては、ネットあるいは携帯電話などを対象とした比較的新しいビジネス領域においてのアプリケーションの自社開発の比率が高いようであり、アジャイル開発の適用例も他のビジネス領域に比べると多く見られる。このような領域においては他社との競合も激しく、サービスインまでの時間との勝負になること、またビジネスの変化への迅速な対応が必要とされるために、アジャイル開発のメリットを享受できる可能性が高いことが理由の一つであろう。

もう一つの理由はビジネスの成長期においては積極的に雇用増が図れるからではないだろうか。企業の成長期においては、システム開発に必要な良質な人的リソースをいかに調達するかが課題である。成長期においては、積極的に雇用を増やすことができるので、雇用が流動的である欧米の国々と同様に自社開発の形態が取りやすい状況と考えられる。一方で、その対象となる産業領域が成熟・安定期に入ると、雇用の流動性が低い場合には情報システムの拡大につれて増強してきた人的リソースをどう有効活用するかを考えねばならない。

つまり、アジャイル開発の適用、自社開発の比率、雇用の流動性の３つは互いに大きく関連していて、アジャイル開発の適不適には、対象となるビジネス領域が直接的に影響を与えているのではなく、そのビジネス領域が成長期にあるかどうかがポイントではないかと考えられる。その辺りについて製鉄業を題材に以下に論じてみたい。

コラム

システムインテグレーションとアジャイル開発（2/3）

製鉄会社は比較的早期にコンピュータを生産現場に導入したことで知られている。たとえば新日鉄の八幡製鉄所には 1961 年に IBM 7070&1401 が導入された。当時アプリケーション開発はユーザ企業側が担当し、OS、コンパイラ、TP モニターなどのシステムソフトウェアの供給を汎用機ベンダが担当していたようである。実際、国鉄の MARS の開発などもそのような役割分担であったようで、当時には珍しくなかったようである[5]。また、アプリケーションの領域においては現在のアジャイル開発に近い形態でのユーザ企業自身による開発も多かったようで、保守・運用はユーザ企業が自前で実施していた。

コンピュータの生産現場への導入が早かった一方で、80 年代後半の円高不況によって本業すなわち製鉄業の成長に大きく期待できない状況が比較的早期に到来した。そこで、多角化経営、すなわち様々な業種にビジネスを広げることに注力し始めた。これには、他にも様々な目的があったと思われるものの、先に挙げた人的リソースの有効活用も主要な動機の一つであったであろう。リソースの有効活用の観点からは、情報システム部門をアウトソーシングするやり方もあるが、たとえば新日鉄の場合はシステムインテグレーターとして新日鉄以外の顧客に対するビジネスを狙うことになった。当時としては、システムエンジニアなどのコンピュータ関連技術者が著しく不足するであろうとの予測が立てられていたことも、システムインテグレーターとしてのビジネスに乗り出すことを後押ししたと思われる。

このようにユーザ系と呼ばれるシステムインテグレーターには、企業の成長期から安定期に入るなどによる情報システムの開発リソースの所要量の変化に対応するために生まれたものも多くあったであろう。これには雇用の流動性が大きく関わっている。雇用の流動性が低く、開発の所要量の変化が大きい、もしくは見通しが不明確であると、本来不必要な固定費用が増大する恐れがあるために、「保有よりも利用」の方向性が高まることになる。実際、個別の業種あるいは企業を見ると、ビジネスが拡大するところ、停滞するところ、縮小するところ、と様々な局面にあるだろう。よって、社会全体としては、縮小あるいは停滞するところから拡大するところに IT 人材のリソースを回せるような流動性を確保することが期待される。その中で、ユーザ系企業が自社開発のリソースを活用してシステムインテグレーターとしての子会社を作ることは、雇用の流動性の低さを補ってリソースの最適活用を図る一つの有力な方法であったはずである。

コラム

システムインテグレーションとアジャイル開発（3/3）

クラウド時代に入って、ビジネスからの情報システムに対するアジリティやフレキシビリティへの要求が、一層強まってきている。新しいビジネス領域のみならず、既存のビジネス領域においてもクラウドのリソースを活用してビジネス上の価値を創造するタイプのシステムが今後重要となる。そのようなシステム開発においては、スコープや仕様などをあらかじめ確定させるのは困難であるので、アジャイル開発が活用できるだろう。一方で、企業として何を保有し、何を利用すべきかを見直す機運も高まりつつある。大部分の産業においては成長の度合いが不透明な時代となってきているので、自社開発に必要なリソースを保有するリスクも相対的に高くなっている。

そこで、雇用の流動性が現状と変わらない（もしくは固定化が進む）ことを前提とするのであれば、アジャイル開発の促進のためには、受委託あるいはそれに準じる形をベースにしつつも、アジャイル開発に適した役割モデル、コストとリスクの負担の構造、それらに応じたモデル契約などを明確化・整備することによって、自社開発に近い状況を作り出す方向性があり得る。自社開発においては、開発者と利用者（提供者）が一体化している、もしくは開発者と利用者（提供者）に共通的な意志決定者（責任者）がいる、といった特徴がある。これらによって、受委託によるものに比べて、開発スコープのコントロールや、何か問題が起きたときの対処が容易になると思われる。これらと同様な状況が契約や第三者機関などの仕組みによって作り出すことができれば、受委託においてもアジャイル開発の適用が進むことが期待される。

アジャイル開発を実現するための人的リソースに目を移してみると、SE、すなわち IT技術者の不足が叫ばれた当時と異なって、現在は頭数としてはオフショア開発などの拡大もあって余剰感が感じられるが、一方でハイスキルな技術者は不足していると言われる。アジャイル開発を実行できるリソースとしては、現状ではおそらくハイスキルな技術者が必要であろう。したがってアジャイル開発に耐えうる開発リソースが不足する可能性がある。この課題に対しては、ハイスキルな技術者の流動性を高める、アジャイル開発が可能であるような技術者を育成する手段を整備する、それほどスキルを必要としない開発形態を確立する、などの方策が必要である。システムインテグレーターとしても、現有の開発リソースをアジャイル開発でいかに活用できるようにするかを考えねばならない。

（非ウォーターフォール開発 XX x xx 記）

５経営層にとっての価値 ‌

非ウォーターフォール型開発は、ソフトウェア開発手法ではあるが、従来のように、プロジェクトチームだけが関与すべきものではない。とりわけ利用企業の経営者は、開発手法の採用決定から開発成果の確認にxxxまで、関与することが不可欠である。しかしながら、この点に関する理解は必ずしも高くない。技術的な問題であり経営上の問題であるとは認識されていないからである。

不確実な経営環境であればあるほど、グローバルなオペレーションが進めば進むほど、さらに、企業同士の吸収合併、分離など、変化が激しいほど、従来型の開発手法は適合しない。そのため、非ウォ－ターフォール型開発の必要性が増大し、早急な取組みが、ユーザ企業のみならず、IT ベンダを含む IT 産業における大きな課題となっている。

５．１経営層にとっての情報システム開発のパラダイムシフトの意義 ‌

企業や組織における情報システムの位置付けの大きな変化を述べ、それに対応するための新しい情報システムの構築プロセスを提案し、発注側の経営者（CEO）、現業部門の要求責任者（COO）、情報システム役員（CIO）の主体的で濃密な関与が必須であることを述べる。

従来のソフトウェア開発において、CEO、COO、CIO など企業の経営層は、開発費用と効果目標を設定した後は、情報システムの実現をプロジェクトチームに、いわば、丸投げ、してきたケースが多い。つまり開発プロセスに経営層が自ら関与する必要がないと考えていたのである。しかし、日々発生する経営環境の変化、戦略の変更、業務改革の進展などの不確実な事態によって、経営層は情報システムのあり方と無関係ではいられなくなっている。

企業ガバナンスの重要性を提起したOECDコーポレートガバナンス原則によれば、企業会計基準、ITガバナンス、IT統制、ITプロジェクト統制などの遵守、とりわけ、企業ガバナンスとITガバナンスが価値連鎖によって結ばれているとして、まさしくITの諸課題は、経営層自身の問題として取り組むことを経営者に求めている。また、日本においても経済産業省が主導して、ITガバナンスに関する具体的なガイダンスが公表されている 8。

実際に、大きな情報サービスの品質トラブルの背景には、経営者の不作為を問われかねない事例 9も少なくない。経営者がシステム開発にどのようにかかわるべきか、どのような要求を実現し、どのような開発手法を採用すべきか、などは、開発チームの問題だけではなく経営者の問題でもある。非ウォーターフォール型開発の啓発は、まず、経営者にとっての意義と価値を理解することから取り掛からねばならない。

本報告書で検討される非ウォーターフォール開発とは、このような企業ガバナンスとITガバナンス、いいかえると企業統制と内部統制に、少なからぬ影響を与えるものである。また、非ウォーターフォール型開発が、エンドユーザコンピューティング、ITリスク評価、開発・保守に関する手続き策定と保守、システムテスト、システム運用・管理、プロジェ

8 「IT 経営ポータル：IT ガバナンス」、「IT 経営憲章」、「企業の IT ガバナンス向上に向けて」など、いずれも経済産業省のサイト(xxxx://xxx.xxxx.xx.xx/)xxxxxx

9 近年多発する金融機関におけるシステム障害も経営者の責任が大きいといわれている。

クト管理、外部委託管理 10などに深く関係することはいうまでもない。

（１）情報システムとは

ISOとIECは 2002 年に「システムライフサイクルプロセス」（ISO/IEC15288）という

国際標準を発行した。これは 2004 年にX 0170 として日本工業規格（JIS）になっている。これによるとソフトウェアライフサイクルプロセス（図表 1-2： ISO/IEC 12207、JIS X 0160）は、システムライフサイクルプロセスの実装部分に当たるとされる 11。ここでいうシステムとソフトウェアの違いとは何か。

図表 1-2 システムライフサイクルプロセス

正面から「システムとは何か」を問うことはあまりなく、一般には、システムとはソフトウェアの集まりであるくらいにしか考えていないかもしれない。システム論は、1950年代中頃に起こった認識論の一つで、さまざまな分野を超えて見られる現象を、「システム」と呼ぶ共通な概念で解釈しようとするものである。システム論は本質的に全体論

（Holonism：ホロニズム）を基礎とし 12、システムを構成する要素の相互作用によって、要素の総和以上のパフォーマンス（創発特性）を示し、要素間の通信を効率化するための自己組織化やフラクタル性などの特性をもつ。また、システム論では、問題の原因を特定

10 経済産業省「システム管理基準追補版「財務報告に係る IT 統制ガイダンス（平成 19 年

3 月 30 日）」」に記載

11 その後 2008 年に、ISO 15288 と 12207 は改訂されて、ソフトウェアライフサイルプロセスは、ソフトウェアを対象とするシステムライフサイクルプロセスであるとされた。この説明は、システムの特性であるフラクタル性（自己相似性、つまり、ソフトウェア自体もシステムと見ることができる）を理解していないと非常に奇妙なものと感じる。

12 [6][7][8]を参照

のシステム要素に還元するのではなく、発現している問題自体をもシステムが創発した結果と見る。したがって問題解決のためには、システムそのものを変える必要があると考えている。

システムはその性質から、ハードシステムとソフトシステムに大別される[8]。ハードシステムはその要素が複雑に相互作用するものの、理論的にその振る舞いが予測されるものである。たとえば、太陽系（the solar system）では、いつ地球で日食が起きるかを予測できる。一方、ソフトシステムは、人が要素に加わっており、合目的的であるが、その振る舞いの予測は困難である。たとえば、政治システムがその典型で、その施策の正しさは理論的に証明されない。情報システムもソフトシステムの一つと考えるべきで、一群のソフトウェアと、それを所有する人、それを使って仕事をする人、ソフトウェアを作る人などから成る。それは情報を扱い、それによって何らかの目的を達成しようとするシステムである。

あえてこのようなシステム論の議論を紹介したのは、ここで問題にしようとしている良い情報システムを作るためのプロセスとその評価基準をあらためて、問い直したいためである。

（２）情報システムサイクル

上で述べたような情報システムを構築するにあたって、標準の「システムライフサイクルプロセス」には明記されていない重要な前提がある。それは、このシステムライフサイクルを回していく主体は誰かという問いである。その主体は、「利用段階」において情報システムが効果を生み出すよう促し、さらに効果を高めるために、情報システムそのものを変えていく責任を持つ。この主体も含め、情報システムの構築に関し、「情報システムサイクル」（図表 1-3）が提案され、その中で、情報システムの Owner の役割と責任について詳述された。ここで、Owner とは発注側の経営者（CEO）、現業部門の要求責任者（COO）を指す。

図表 1-3 情報システムサイクル 13

13 xx[9]は、Owner、Designer、Constructor を、それぞれ「施主」、「設計者」、「施工者」と訳している。Enterprise Architecture の基礎になったと言われる Bachman[15]も、情報システム開発と建築との類似点に基づいて論じているが、日本では建築のメタファー（比喩）に少なからず抵抗感もあるとの配慮から、本報告では大文字で始まる英単語とした。表記上は単数だが、概念上はロールであり、それぞれ 1 人以上の要員からなる。

情報システムの Owner は出来上がったソフトウェアを利用者に使わせることで、企業にとっての効果を生み出すように努めなければならず、そのために小さな保守（現場合わせ）を繰り返し、問題を再認識することで情報システムを作り替えるということを長期にわたって続けなければならない。こうして情報システムは、長い時間をかけて変化し価値を生み続けるか、価値を生まなくなることで廃棄される。長い時間生き延びた情報システムは、それ自体その企業の文化を反映していると同時に、その企業の仕事の仕方を規定していることが多い。

さて、企業情報システムは個々の情報システムから構成される大きなシステムである。これは、歴史的に個々のシステムが少しずつ作られ、それらが相互に連携するように調整され、さらにまた新しいシステムと連携するというように徐々に統合され、拡大してきたという経緯にある[11]。この過程は都市が形成される過程になぞらえることができる[12]。すなわち、ある程度の大きさの企業情報システムができてしまえば、勝手に個々の情報システムができてしまわないように、そして企業情報システム全体がより最適な状態に近づくようにコントロールする行政機構が必要となり、その長である情報担当役員（CIO）が行政機構を所掌する必要が生ずる。企業情報システムのあり方を（都市計画のように）中長期的に設定し、それに向けてインフラを整備する。この中長期計画のための枠組みこそがEnterprise Architecture（EA）であり、CIO の重要な武器である。

CIO が率いる組織は、一般に「情報システム部門」と呼ばれる。情報システムの構築に関わる資源の配置とプロジェクト遂行の支援を行うとともに、開発が完了するとシステムと要員を現場に配備して業務の執行に使用する。これが効果的に稼働しているかをモニターして、業務執行の長と常に対話することで情報システムサイクルをコントロールする。このイメージを図表 1-4 に示す。

図表 1-4 企業情報システムの構築プロセスと業務執行プロセス

このことは、企業のビジネスにとって、情報システムが必要不可欠な道具となっていることを示唆する。ただし、ビジネスは止まらないので、その道具は、例えば航海しながら船を増築しているような危うい状況にある。これが現代の企業情報システムを巡る問題状況であると考える。

（３）情報システムの開発プロセス

このような現代的な情報システム観に立って、これまでの開発プロセスを再評価してみたい。

まず 1970 年に発表された Royce[13]が提起したプロセスを見てみよう。図表 1-5 はその一例である。これは後にウォーターフォールモデルの提案と誤読された図である。Royceはこの論文の中で、一つずつ前のステップに逆戻りすることを認めているし、二度作れ

（Build Twice!）とさえ述べている。「ウォーターフォール」という言葉さえ使っていない。

図表 1-5 Royce のソフトウェアプロセス[13]

Royceの主張は、現在広く知られている「ウォーターフォール」と呼ばれる手戻りなしの一度きりのプロセスモデルではない。決められた作業を順に行うことで目標の製品が出来上がるという、工場の生産ラインのようなプロセスは単純でわかりやすく、理想的に見えるが、情報システムは量産品ではない。その都度、個別に異なる問題状況を分析して構想・設計・試作を繰り返す新製品の開発プロセスに近い。だから現実の情報システム開発では、当然手戻りが発生する（もし発生していないとすれば、それは問題を後工程に押しつけているだけか、量産品を作っているかのどちらかである）。いつどこで、このような「ウォーターフォール」の誤読が始まったのだろうか 14。

さらに、Xxxxxのスパイラルモデル[14]を見てみよう。図表 1-6 に示すように、宣言、リスク対策、実施、次の計画を行う四つの象限があり、プロセスはこの中を右回りにらせんを描くように進む。最初の 1 周目は業務構想書（Concept of Operation）を作成する目的で回す。業務構想書が承認されると、ソフトウェア要求定義 15 のサイクルに進むかどう

14 米国国防総省のソフトウェア開発及び調達に関する標準 DOD-STD-2167 で用いられたと言われる。これにより失敗プロジェクトが頻繁に発生し、改訂文書が出されたものの、徹底されなかった模様である[16]。

15 システムライフサイクルプロセスが定義されている現代では、このソフトウェア要求定義はシステム要求定義と読み替えるべきだろう。

かを判断する。進むとなれば、まずその旨を宣言し、要求定義のリスクを減少させるためのプロトタイピングを行った上で要求定義書を作成する。同様に、次のサイクルでソフトウェア製品設計書を作成し、次のサイクルで一気に詳細設計からコーディング、単体テスト、統合テスト、受入れテスト、配備へと進む。つまり 1 周ごとに次の周回へ進むかどうかを判定し、4 周で情報システムを開発し終わるようになっている。注目すべきは、作業の実施前に毎回プロトタイピングを行う点である。

図表 1-6 Boehm のスパイラルモデル

図表 1-7 スパイラルモデルとシステムライフサイクルプロセスとの対応

このスパイラルを、横軸に時間を割り当てて書き直したのが図表 1-7 である。ここから Rational Unified Process（RUP）への影響や、その後の反復型プロセスや、システムライフサイクルプロセスへの影響が感じられないだろうか。この論文が発表されたのは、実に 1989 年のことなのであり、Royce やXxxxx などの先人の成果が正しく理解されていないのではないだろうか。

（４）情報システム開発の環境の変化

このスパイラルモデルと Royce のモデルとの大きな違いは、「上流」工程での頻繁なプロトタイピングの実施にある。このことは、Royce の頃（1970 年代前半）に比べて、Xxxxxの頃（1980 年代後半）には、情報システムの開発により大きなリスクを伴うようになったことを意味する。

実際、経験的にも 1970 年代のソフトウェアは、帳票作成が中心 16 だったことは明らか

である。この頃は、ソフトウェアそのものがほぼ情報システムと同意であった。それが 1980年代の後半からは、ソフトウェアの適用業務領域が拡大し、それに連れてOwnerの要求は複雑となり、前もって明確に記述できないものとなった。言い換えると、情報システムはソフトウェアで構成されるとは言えなくなったのである。その大きな原因は、システムが対顧客業務の中で使われる（オンサイト）ものとなり、マーケットがシステムの構成要素になったことである。

このような変化は、ハードウェアや OS、DBMS、ネットワークなどのプラットフォームでも見られ、メインフレーム中心からネットワークで有機的に接続されたサーバ群が主流となり、“クラウド”と一括りにされる多様なコンピュータ資源の活用技術が現れた。開発手法もオブジェクト指向言語、モデリング言語、開発ツールや開発方法論が急激に整備されてきた。ここ 10 年で、情報システムの開発に対する要請が大きく変わったと感じる。

（５）情報システムの評価基準

さて、以上の議論を基に、もう一つのテーマである情報システムの良さの基準をどこに置くかを考えてみよう。われわれは、既にソフトウェアと情報システムは別の見方であることを理解した。情報システムをソフトウェア、つまり“もの”として見るとき、その開発努力は QCD、つまり、品質、コスト、納期を目標どおりに達成するために費やされる。これは「ものづくり」では当たり前のことである。ただし、ここでいう品質は仕様どおりできていること、バグが少ないこと程度を指す。そして、これはあくまでも Constructor側の論理である。

情報システムをシステム、つまり“こと”として見るとき、その開発努力は EEE を高めるために費やされる。EEE とは Efficacy, Efficiency, Effectiveness で、それぞれ、正しい答えが出せること、効率がいいこと、意図どおりに動くことなどと訳せるが、これらの厳密な違いよりも、システムが目的に対して効果的であることの重要性を説いている。 EEE の指標は経営指標でもあり、ビジネスの性格によって個別に選択される。例えばサービスの平均応答時間や在庫回転率などである。これは、Constructor の価値観とは大きく異なる。

図表 1-8 は、価値の基準が Owner と Constructor とで異なることのイメージを示している。両者の論理が重なるのは「プロジェクト」と呼ばれる実装段階だけで、それが終わ

16 当時のコンピュータはまるで印刷機だったといわれている。

るとそれぞれ異なる道を行く。

図表 1-8 Owner とConstructor の価値観の違いのイメージ

このように、良い情報システムを作るためには、Constructor の論理だけではなく、Ownerの価値観を明示的に導入する必要がある。

（６）発注者との濃密なコミュニケーション

本節の冒頭に述べたように、情報システム開発に対する要請が変わったにもかかわらず、発注側の経営者たちは相変わらず、情報システムの実現をプロジェクトチームに、そしてプロジェクトチームは Constructor に、いわば丸投げしてきたケースが多い。ウォーターフォール型プロセスモデルは、それを可能とするプロセスになっているからである。このプロセスは、前工程の成果が常に正しいという幻想を前提にしており、明示的、暗黙的にかかわらず問題を後工程に順送りにして、テスト工程でカバーするという事実上不可能な仕組みになっている。そのため、建前上は手戻りがないことにして、後工程で前工程をやり直すことも多い。実際、そのような問題指摘は、以前からあり、Brooxx[00]は明確に「ウォーターフォールモデルは間違いだ」とさえ述べる。ここに日本的な下請け構造が重なることで、様々な不合理な問題に対する異議申し立ては封じ込められてきた。

一方、Constructor 側もなぜ「ウォーターフォール」を採用し続けるのか。その最大の理由は、現役でなくなった、かつての開発者が、管理者になって効率的に「管理」するために、プロジェクトに一律で横並び的な「工程」が必要だったからであろう。

ウォーターフォールの問題を否定しきれなくなってきた現在では、非ウォーターフォール型プロセスが強制するソフトウェアプロセスへのOwnerの濃密な参加という過大な負担を問題視することで、新しいプロセスの採用を拒否しようとしてきた 17 。実際、アジャイルプロセスでは、それが大規模になるほどOwnerの負担は大きくなる。それでも、効果的な情報システムを作るには、これらの負担は必要不可欠であると考えられる。

このような発注者との濃密なコミュニケーションのあり方について、近年の建築の世界でのパラダイムシフトのいくつかの取組み（コラム「建築の知見の情報システム学への適用」を参照）が参考になるだろう。

17 笑えない事実であるが、インタビューで、「やったことがないから」という理由を告げられたこともあった。

（７）非ウォーターフォールモデルの課題

しかし、実際に大規模な基幹システムの再構築をアジャイル（例えばスクラム）で実施してみると、Ownerとの濃密なコミュニケーションは、大規模になるほど難しいと感じる。 Constructor側は複数のチームを作ってOwner側の担当者の参加を要請するが、チーム体制に見合った人数の担当者を参加させられないし、担当者間での意思統一も難しい。単に、複数のスクラムチームをまとめるチーム 18 を用意すればいいというものでもない。

ある例では、このような課題が予想されたため、あらかじめ基本的な情報システムアーキテクチャを開発して提供してきた。対象業務の予想以上の複雑さに、アーキテクチャ改訂が追いつかず、Constructor 側の要員も機能要求を十分に理解できないままスプリントを繰り返し、顧客価値が得られないという課題も噴出した。大規模アジャイルでの開発は、小規模プロジェクトの単純な延長や拡大ではない。しかし、ではウォーターフォール型開発が適しているということでは必ずしもない。ウォーターフォールで実施したとすれば、このような課題は、さらに後の工程で噴出し、取り戻すことが難しい状況になってしまうだろう。問題の早期可視化こそが大きな価値なのである。

経験的にいえば、大規模システム開発のリファレンスモデルとして、Boehx xスパイラルモデルの採用が妥当と思われる。そして、各周回のリスク減少と実施フェーズではタイムボックスを設け、アジャイルに行う。例えば、システム設計プロセス、すなわちスパイラルの第２周目では、開発規模を Owner 側の要員が Designer と濃密にコミュニケーションがとれるサイズに切り出して、模型を何度も作り直してアーキテクチャを安定させながら、機能要求と方式設計をまとめ上げる。まさしく、これがウォーターフォール（工学主義）とアジャイル（反工学主義）とを止揚した新しいパラダイム[21]（批判的工学主義）といえるであろう。

本節では、アジャイル開発が、日本のソフトウェア競争力を高めるための重要な開発手法として位置づけられるとともに、現代の不確実性の高いビジネス環境において、日々その役割が増大していると考えてきた。そのためにも、経営層への理解浸透が、次の一歩のために極めて重要であり、大きな課題であると認識し、企業情報システム開発における考え方のパラダイムシフトの意義を検討した。今後、非ウォーターフォール開発の導入に際しての企業ガバナンスと IT ガバナンスに対するさまざまな影響について、今後、具体的な実証作業を行う必要があるだろう。

18 大規模開発では、スクラムチームを複数設定しそれぞれに開発を進めるのと並行して、代表者からなる“Scrum of Scrums”チームを設定することがある[22]。さらに Ownerグループが要求定義レベルで Scrum を行う“メタ Scrum”チームを設けることがある。

コラム

建築の知見の情報システム学への適用

建築の知見を情報システム学も手本とすべきであろう。建築の世界では、現在、注目すべきパラダイムシフトが起こっている。1970 年代半ば、日本では「組織・ゼネコン」建築家と「アトリエ」建築家の対立があった。

前者は、高層ビルや巨大建築を量産するための技術を優先させ、「工学主義」19 と呼ばれた。後者は、組織に従属するか、都市建築から撤退せざるを得なかった。これはちょうど、米国で、より人間的な都市建設をめざして、Alexxxxxxx「パタン・ランゲージ」[17]を提案した頃である。そうして、都市には表層的に、短工期、建築費の削減、人間工学的なユーザ快適性が得られたが、深層では都市全体の景観を損ね、運用維持費の増大、環境への悪影響という問題を抱えるに至った。真鶴町が、1993 年にパタン・ランゲージに基づく景観保護に関する条例[18]を制定したのは、この対立問題が表面化しやすい、都市と地方の境目にあったからだろう。

2000 年代に入って、両者の対決を止揚しようとする動きが出てきた。「批判的工学主義」を掲げるxxxxxxx践がそれだ。一般に、建築の設計では施主の要求を探索するために、要所ごとに複数の案を作って一つを選択させて枝分かれさせ、徐々に精緻化していく。この手順は後戻りすることもあるので、設計作業の軌跡は、ループのあるツリー状になる。工学主義ではこのような手間を嫌って、周辺環境との調和を半ば無視して既成の設計を押しつけてしまう。

これを避けるために、批判的工学主義では、スピードを重視しつつ、建築に対する施主の与条件を深読みして、社会の要求に応えようとする。xxxx唱する「超線形プロセス」 [19]では、設計プロセスにおいて、「ジャンプしない」、「枝分かれしない」、「後戻りしない」という三原則を貫く。それゆえ、設計作業の軌跡は線形となる。彼は設計検討のたびに模型を作って保存する。設計を改善するときは改善点を一つに絞る。このようないわば「ログ」があるからこそ、上の三原則が可能となり、一定のスピードが得られるという。

このようなプロセスは、施主との濃密なコミュニケーションを必要とする。このコミュニケーションの存在ゆえに、xxウォーターフォール型に見える線形プロセスも、顧客価値を生むのである。xx[00]は、この設計プロセスと情報システムのアジャイルプロセスとの類似を指摘している。筆者も、この模型を媒介にした Owner との濃密なコミュニケーションの存在こそ、非ウォーターフォールプロセスが成立する要件と考える。

（非ウォーターフォール開発 WG xx xx 記）

19 アトリエ建築家は工学的でないという意味ではない。工学主義は、社会工学や人間工学を無批判に取り入れ、建築を工業化し、Alexxxxxx xいう Quality without a name を忘れてしまったという意味だろう。

５．２経営層にとっての情報システム開発手法の選択と価値 ‌

情報システム開発のパラダイムシフトの意義に賛同し、発注者との濃密なコミュニケーションを含むアジャイル開発へチャレンジしていく企業が増えることを期待する。

一方、アジャイル開発を採用することによって、開発上の課題が全て自然に解決するわけではない。ウォーターフォール型開発ではなかった課題が発生することもあるし、どちらにも共通する課題もある。よって、生半可な覚悟でアジャイル開発に取り組むと、それらの課題につきあたり、「そんなはずではなかった」となり、元のウォーターフォール型開発へ戻ることにもなりかねない。

ウォーターフォール型開発へ戻らない覚悟を持つためには、アジャイル開発でしかビジネス上の成功を得ることができない、ウォーターフォール型開発でも開発は完了するだろうけどビジネス上の成功を得ることができない、という裏づけが一番強いと考える。逆に言うと、アジャイル開発でしかビジネス上の成功を得ることができない、というプロジェクトへアジャイル開発を導入していく。

本節では、そういう観点から、アジャイル開発、ウォーターフォール型開発の採用の考え方についての一例を示す。あくまでも一例であり、大切なのは、アジャイル開発でしかビジネス上の成功を得ることができないかどうかを自らのプロジェクトに問いかけることである。

なお、本節では、情報システム開発における役割として、下記を定義する。

①顧客（利用部門）

情報システム開発・運用など情報システムサービスにかかわる費用を負担し、そのサービスを利用することにより、ビジネスを効率的に推進する部門。

②IT 部門

顧客に対して、情報システムの開発によりサービスを提供する部門。顧客と同一企業の部門であるが、自社内のみでは閉じず多くの外部リソースを活用しているのが一般的である。中小規模の企業では、「部門」というほどの組織はなく、担当者と外部アウトソースの場合もある。

（１）顧客（利用部門）視点の情報システム

顧客からみた情報システム価値の分類の一つとして、図表 1-9 を示す。

情報システム価値分類

説明

高信頼性、高スループット、整合性に価値をおく情報システム 20

（信頼性重視システム）

 システム要求が長期固定的であり、寿命も長いシステムである。

 あらかじめ設計されたビジネスプロセスにしたがって、高信頼で高スループットを実現し、そのデータ整合性を常に保つことに最大の価値がある。

 ユーザの固定度は高く、システムの使い勝手によりユーザ数が大きく変動してしまうということはないので、一般的には高度な使い勝手までは求められない。

 典型的には、財務・調達などバックオフィスシステム、

銀行オンラインシステムがこれにあてはまる。

要求へのスピーディな対応、使い勝手に価値をおく情報システム 21

（俊敏性重視システム）

 システム要求が次々に変更・追加され、寿命の短いシステムである。

 ビジネス上の理由 22により、あらかじめ情報システムへの要求を出し尽くすというアプローチをとるよりも、開発した情報システムを評価しながら要求を追加・変更していくというアプローチをとった方が合理的な情報システムである。

 多くは、新たなユーザ獲得を目指すビジネスで求められ、高度な使い勝手が求められる。

 典型的には、新たなインターネットサービス、グローバ

ル市場向け新ソフトウェア製品がこれにあてはまる。

図表 1-9 情報システム価値からみた分類

「信頼性重視システム」は、ERP など業務パッケージ活用、SaaS による業務サービス提供により、開発量は減少方向であり、また、企業価値向上への寄与度は小さくなる傾向と考えられる。

「俊敏性重視システム」は、インターネット、モバイルデバイスの普及により、新ビジネス開拓には必須となりつつある。

20 基幹系システムなどのように、最初から十分な完成度を要求されるシステムを意味する。

21 Web ビジネス、インターネット系システムなどのように、高信頼性、高スループット、整合性を網羅した十分なシステムの完成度よりも、要求へのスピーディな対応や他社に先駆けた製品・サービスへの対応、使い勝手が要求されるシステムを意味する。

22「ビジネス上の理由」というのは大切なキーワードである。「あらかじめ情報システムへ

の要求を出し尽くせない」ということが、否定的なことではなく、ビジネス上のチャレンジから必然的にそうなる、という肯定的な文脈であることが重要である。

（２）IT 部門にとっての情報システム開発

システム開発手法の採否には、IT 部門の文化が深くかかわっている。まず、図表 1-10のように２種類に分けて考えてみよう。おそらく実際には、２種類の間のどこかに位置付けられることが多いと思われる。

IT 部門の文化

説明

ウォーターフォール型開発への親和性が高い

かなり以前から(多くはメインフレーム時代から）システム開発を行っており、ウォーターフォール型開発を基にする独自開発方法が根付いている。プロジェクト管理体制・ノウハウ、人材確保方法などが、その開発方法に最適化されており、その IT 部門の開発文化となっている。

長期間、開発を継続していること自体が、ある程度の成功を物語っており、ウォーターフォール型開発を基にする独自開

発方法を肯定的にとらえている。

ウォーターフォール型開発への親和性が低い

インターネット文化が根づいた頃からビジネスを開始した企業の IT 部門。その企業では、インターネットに関わるサービスビジネスを自ら行っている場合もある。

ユーザの反応をみてシステムを漸次改善していく、という

「永遠の β 版」という考え方に慣れ親しんでいる。

図表 1-10 IT 部門の文化

アジャイル開発には多様な技法・プロセスがあり、その中から自プロジェクトにあったものを採用することが特徴であるが、短期(２W～４W)の反復(イテレーション)開発は共通の特徴といえる。よって、反復開発期間毎に、動作しているソフトウェアを確認することができる。これにより、機能内容・使い勝手などを検証し、早くフィードバックすることができる。また、情報システムへの要求が不十分な段階から開発に入ることができ、できあがってくる機能を動作させながら、要求追加・変更を繰り返していくことができる。

その他にも、開発スピード、生産効率、品質、人材スキルが向上すると言われている。しかし、それは、どのようなプロジェクトにおいても達成できるというものではなく、

プロジェクトの特徴をみて、その効果をめざしてアジャイル開発を導入するかどうか個別に判断すべきものと考える。

以上で述べてきた情報システム価値とそれを開発する IT 部門の文化によるウォーターフォール型開発、アジャイル開発の推奨パターンを図表 1-11 に示す。

文化

情報システム価値

ウォーターフォール型開発

への親和性が高い文化

ウォーターフォール型開発

への親和性が低い文化

信頼性重視システム

①ウォーターフォール型開発

を推奨

②推奨なし

俊敏性重視システム

③弱いアジャイル開発を

推奨

④アジャイル開発を推奨

図表 1-11 ウォーターフォール型開発、アジャイル開発の推奨パターン

①信頼性重視システム/ウォーターフォール型開発への親和性が高い IT 部門にはウォーターフォール型開発が推奨される。情報システムへの要求の多くは、論理的には開発当初の要求定義フェーズで確定すべきものであり、ウォーターフォール型開発への親和性が高い IT 部門では、過去、そのために多くの改善投資をしてきており、一定の効果がでている。短期でのシステム動作と要件へのフィードバックは、このパターンでは必須とはならない。よって、文化として定着している、ウォーターフォール型開発を基にする独自開発方式を継続して採用することが妥当と考える。

②信頼性重視システム/ウォーターフォール型開発への親和性が低い IT 部門には特に推奨するものがない。情報システムへの要求の多くは、論理的には開発当初の要求定義フェーズで確定すべきものであるが、ウォーターフォール型開発への親和性が低い IT部門では、そのための体制・ノウハウが不十分な場合が多い。その場合、改善投資によりウォーターフォール型開発へ持っていく、または、アジャイル開発を取り入れてそれを補う、という選択肢がある。その選択は、個々のプロジェクト状況によって、または、IT 部門内文化のあり様によって、選択していくべきことと考える。

③俊敏性重視システム/ウォーターフォール型開発への親和性が高い IT 部門には、アジャイル開発を弱く推奨する。本情報システムの特徴としては、アジャイル開発のメリットと合致するものである。本情報システムを、フェーズ分けなどウォーターフォール型開発で開発できるかどうか検討した上で、ウォーターフォール型開発では無理と判断した場合に、アジャイル開発を採用すべきである。ウォーターフォール型開発に慣れ親しんでいる IT 部門では、アジャイル開発に「変更」すること自体、いろいろなデメリットが生じる。それを、ウォーターフォール型開発では本情報システム開発はそもそも無理で、アジャイル開発(短期の反復開発)が必須である、という意識で乗り越えることが重要となる。

④俊敏性重視システム/ウォーターフォール型xxxへの親和性が低い IT 部門には、アジャイル開発を推奨する。本情報システムの特徴としては、アジャイル開発のメリットと合致するものであり、ウォーターフォール型開発のノウハウが薄い IT 部門では、わざわざウォーターフォール型開発を採用する理由はない。

ウォーターフォールに基づく開発を採用するか、アジャイル開発を採用するかは、ビジネス上の成功の観点で考えるべきことである。ウォーターフォールに基づく開発を採用し

ていて、ビジネス上成功を獲得していて、将来もそれが続きそうであれば、アジャイル開発へ変更する必要はないかもしれない。

しかし、俊敏性重視システム開発において初期段階で要求定義が固まらないことによるコストオーバランが多くなっていたり、信頼性重視システム開発案件が減少し俊敏性重視システム開発案件が増加していたりする場合には、上記の推奨パターンを考慮して、経営的観点でアジャイル開発導入を検討すべきと、考える。

５．３経営層にとっての懸念事項 ‌

ウォーターフォール型開発の諸問題とそれに対する非ウォーターフォール型開発の利点や優位性について、どれだけ説明しても、利用企業の経営層を十分に納得できるとは限らない。いくつかの懸念が解消しないからである。経営者から、信頼できる見積り手法、品質保証、進捗管理の見える化などが要求される。

従来のウォーターフォール型開発では、全体を見通し、あいまいであっても要求仕様を確定することで、工数と費用が見積もられ、経営者にとっては、どの程度の資源が必要となるかが比較的、理解しやすかった。それに対して非ウォーターフォール型開発は、要求仕様があいまいなままプロジェクトを進めるため、経営者は、必要資源についての情報が提供されないことに対して、フラストレーションを感じるのは当然ともいえる。

また、非ウォーターフォール型開発では、あえて先の設計はせずに、直近のイテレーションサイクルのみの見積りを行うのが普通である。したがって、見積りが常に概算となり、ウォーターフォール型開発と比べ、不正確であるとの懸念が生じるのもやむを得ない。

しかし、従来のウォーターフォール型開発でさえ、プロジェクトの失敗要因の多くが要求仕様確定後の変更のxxx要求仕様のあいまいさ、意味の共有不足にあることはよく知られている。したがって、要求仕様で見積もっても不正確であって、非ウォーターフォール型開発で要求仕様があいまいであるから見積もれないとはいえない。つまり、ウォーターフォール型での要求仕様確定から見積りという流れ自体が、もはや適合しないことを示している。

見積りは当初は不確実性が高く、プロジェクトが進捗するにつれて正確さが増大することは知られている。その際に、２つの点を考慮したい。まず、当初のあいまいな時期に要求仕様を確定することが困難であるにも関わらず、工数や費用を確定することによって、この見積りに制約され、プロジェクトの失敗を助長してしまう可能性がある。要求仕様に基づいて正確に見積もることに精力を費やすよりも、現実的には、過去のデータから、どの程度の工数だったのか、あるいは、期待効果から、投入可能な予算を推定する方が現実的であろう。これは製品の価格を、原価を積み上げるのではなく、市場で受け入れ可能な価格を参照して設定することと同じ方法である。そしてプロジェクトの進捗に応じて仕様が明確になるにつれて実現可能性を考慮しながら、工数、費用を見直すのが、まさしく非ウォーターフォール型開発にふさわしい見積り方法といえるだろう。

避けなければならないのは、従来のように要求仕様があいまいかつ変更の可能性があるにもかかわらず、IT ベンダに見積り依頼を行い、契約を締結してしまい、その費用に拘束されてしまうことである。もし、あいまいな時期に契約をする必要があるならば、それは確定一括発注方式をとるべきではなく、変更可能な出来高方式、単価方式など、状況に応じた柔軟な契約方式をとるべきである。この点は、調達部門の理解が不可欠であり、部門

横断的であるがゆえに、経営者の理解が必要となる。

品質についても、非ウォーターフォール型開発によって向上するのかどうか、検討してみよう。基本的には、２週間から１ヶ月の期間を開発単位として、要件定義、設計、実装、テスト、リリースを繰り返し、システム構築するのが典型的なアジャイルソフトウェア開発のプロセスである。ここでは、全期間にわたるユーザの関与によって品質の向上が期待される。プログラムは、ユーザが指定したテストに合格するように作成され、ユーザは、短期間で結果のフィードバックが得られ、再度、要望を挙げることができる。結局、品質はユーザが決め、ユーザが納得しなければならないため、このプロセスを経てユーザの納得感にかなった品質を保証しようとする。

さらに、コードレビュー、単体テストなど実装時にバグを混入させないことが期待される。実装時に行うコードレビューが、バグの低減に有効であることはよく知られているが、これまで、開発期間が長くなるとの理由からあまり実施されることはなかった。さらに、コードの書き換えのたびに、何回も回帰テストを行っていては、ユーザの要望に迅速に対応できないとも考えられていた。しかし、ペアプログラミングを行う過程で、コードレビューを組み込むことで生産的なコードレビューが可能となる。また、テスト駆動開発やテストの自動化によって、システム変更後の品質保証が容易になるとともに、わかりやすいプログラムコードへとリファクタリングすることによって、バクが発生しにくい構造へと改善することができる。これは品質向上に寄与するであろう。

ウォーターフォール型開発が、工程の最後に大規模にテストを行い、統計的に品質を確保しようとするのに対し、アジャイルソフトウェア開発は「工程で品質を作りこむ」ことを基本としている。これは、トヨタ生産方式をソフトウェア開発の領域へと応用することを意味する。現在のソフトウェア品質の課題は、開発から稼働までの間でいかに作り込むかだけではなく、本番稼働後の経営環境や戦略の変更、ユーザの期待品質の変化などに対応して、いかに保守しやすく品質向上させやすくするかの方が大きな問題である。その点でも、非ウォーターフォール型開発の利便性は極めて高いばかりでなく、改善可能性こそ経営管理面での大きな利点である。

進捗管理についても、疑問が生じるかもしれない。どこまで進捗したかがわかりにくいと述べるかもしれない。しかし、パッケージソフトやミドルウェアの採用、開発済みモジュールの再利用など、従来のウォーターフォール型開発型であっても、もはや、現在の開発現場での現状ではコード数だけで管理することは困難となっている。さらに、ファンクションポイントを、進捗を管理する指標とすることは困難である。むしろ、WBS で工程を追いかけるのが通常となっている。その意味で、両者の相違はないといえる。むしろ数字だけで進捗を把握するのではなく、テストを頻繁に実施することで、経営層も進捗を理解することは容易である。

また、近年のツールの発達は、非ウォーターフォール型開発で有効活用されている。たとえば、品質プロセス（統合支援）を管理するツールとしての HP Quality Center Software、開発ツールとしての Eclipse、ユニットテストツールの JUnit、XP 管理ツールの XPlanner、XpTrackerPlugin などは生産性向上のみならず、進捗の可視化に有用である。プロジェクト管理ツールとしての Redmine は情報共有のためにも活用できる。テスティングフレームワーク、デプロイツール、バージョン管理ツールや、Vim や Emacs などの高機能にカスタマイズできる簡易なエディタ、インスタントメッセンジャーなどの汎用的

ツールも活用され、ログデータの活用などによって、進捗管理上も有用である。

これらのツールは、本質的に、アジャイルかどうかではなく、開発者としては、常に、自分の仕事の生産性向上、仕事の品質向上に向け、情報収集し、試行すべきものかもしれない。ウォーターフォール型開発よりも非ウォーターフォール型開発の技術者にそういう姿勢が備わっているということかもしれない。

しかし、日頃から、利用企業も IT 企業でも、「開発の連中の言葉は、さっぱり分からない」と述べる経営者が多いため、いかに論理的に説明しても理解を得るのは容易ではない。機能単位で見積もったとしても、結局、人月や費用という経営陣のわかる言葉に変換する方が効果的であり、現場にとっても生産的である。したがって、ツールを活用することで、経営層にもわかるグラフや数字に置き換えて表示することは効果的である。これらは単にツールを導入すれば効果的な進捗管理ができるというよりは、可視化を図ることで管理しやすくなっているからこそツールが有効であることを示している。

経営層の懸念は、非ウォーターフォール型開発に特有というよりも、現在のウォーターフォール型開発においても、すでに発生している問題である。それを解決するためにこそ、非ウォーターフォール型開発が有効であることについて、経営層の理解を得るべきであろう。アジャイルの価値を一言で述べるとすれば、利用者に実物を見せて進捗を報告できるからからこそ、“ごまかしがきかない”、ということに違いない。経営層にはその価値、つまり見える化の価値を十分にアピールする必要があるだろう。

コラム

顧客・経営層に対する進捗の見える化（1/3）

システム構築のマネジメント上、顧客や経営層から進捗状況に関する報告を求められることが多い。これに適切に応えることにより、顧客・経営層と開発プロジェクトチームとの間のコミュニケーションが円滑化され、プロジェクトそしてビジネスの成功に結び付く。

このような QCD の「見える化」は、ウォーターフォール型開発においては、概ね確立されたプロジェクトマネジメントの技法に基づいて行われる。すなわち、組織やプロジェクトによりあらかじめ定められたメトリクスと手順にしたがって、開発データが随時収集され、分析される。そして、開発のどの時点においても、顧客・経営層からの求めに応じて、あるいは、開発プロジェクトが必要と判断した場合に、（コスト等への）所定の換算を行った後、進捗状況を適切に報告することができる。

これに対して、アジャイル開発においては、QCD の見える化が一般に確立しているとは言い難い状況にある。たとえば、テスト駆動型開発やペアプログラミング、リファクタリング等、採用するプラクティスによっては、ウォーターフォール型開発において用いられるメトリクスでは進捗状況を適切に評価できないケースがある。また、進捗等の管理のためのデータ収集・分析作業そのものが、アジャイル開発のメリットを大きく損なうオーバーヘッドになるという考え方もある。したがって、反復やリリースの途中では、顧客・経営層に対して適切な進捗状況を報告できないことがある。このような状況は、顧客・経営層がアジャイル開発の採用を躊躇する理由の一つともなっている。

ただし、アジャイル開発では、もともと顧客の参画を前提とするため、顧客に対しては、開発進捗状況の「見える化」についての特段の対応は不要とも考えられる。しかし、考え方としてはその通りであるが、現実には、顧客の参画の内容と度合いによっては、全く報告が不要ということにはならないケースも少なくないと思われる。

一方、マクロな視点で見ると、ウォーターフォール型開発では、システムに要求される全ての機能が完成して初めて、顧客・経営層が知る（安心する）ことができることが基本であるのに対し、アジャイル開発では、たとえば、機能単位にリリースすることにより、顧客・経営層は、開発途中での完成状況を知ることができる。これにより、顧客・経営層は、ビジネス上のアクションを素早く採ることも可能となる。

このことについて、図表 C-1 に示す簡単な例を用いて説明する。

同図は、D 社が、ビジネス上の必要から 5 個のメニュー項目が想定されるサービスの早期提供を迫られている状況を表す。同社は、要求の確定したメニュー項目の機能からxx開発・サービス提供を行うため、アジャイル開発の適用を決断したものとする。

図表 C-2 は、この開発プロジェクトの進捗状況のイメージを表す。左側がアジャイル開発、右側がウォーターフォール型開発の場合であり、下段が開発プロジェクトにおける実際の進捗度を、上段が顧客・経営層に見えるソフトウェアの完成度を、それぞれ表す。アジャイル開発においては、サービスメニューの完成ごとに、xxリリースするものとする。

コラム

顧客・経営層に対する進捗の見える化（2/3）

図表 C-1 顧客・経営層によるアジャイル開発手法の採用判断の例

図表 C-2 に示すように、ウォーターフォール型開発のプロジェクトでは、求めに応じていつでもその時点での進捗度を明確に報告することができる。しかし、顧客・経営層がプロダクトの完成を実際に目にするのは、全ての機能の開発が完了した後となる。これに対して、アジャイル開発のプロジェクトでは、一般に、反復/リリース内では、明確な進捗度を報告しにくいことが多い。しかし、顧客・経営層は、一つの機能が完成する度に、それを実際に確認することができる。

図表 C-2 アジャイル型とウォーターフォール型における開発進捗度の見え方の特徴

コラム

顧客・経営層に対する進捗の見える化（3/3）

このように、アジャイル開発には開発進捗状況の見える化に関する得失がある。よって、重要なことは、開発形態の特徴に応じた見える化ということになる。

アジャイル開発の最大の特徴の一つは、ビジネス環境変化への俊敏な対応であるから、それが確実に実現できているか、またはできそうであるかの確認という観点での、開発進捗状況の見える化が求められる。たとえば、反復の単位で予定した機能の開発が完了せず、次の反復に持ち越しとなるケースがあり得るが、このようなケースの連続する回数や累積数は、ビジネス戦略上の予定時期までに所定の機能がリリースできるように開発が順調に進んでいるか否かを判断する材料の一つとなる。

また、アジャイル開発においては、一般に、反復の都度、コードを書き変えていくスタイルが採られるが、コードの整備のためにリファクタリングを繰り返す。このような状況が続くことにより、プロダクトの品質に重大な悪影響が及んでいるか、または及ぶ可能性があるかの早期見極めという観点での、プロダクト品質の見える化が求められる。たとえば、コードのエントロピー（乱雑さ、無秩序さ）増大状況は、プロダクト品質を見通す材料の一つとなる。

以上のことから、顧客・経営層は、アジャイル開発の採用を決断した時点で、開発プロジェクトの進捗状況の把握に関する十分な理解と覚悟が必要となる。また、アジャイル開発の特徴に応じた「見える化」項目を用いて開発プロジェクトとの円滑なコミュニケーションを図り、アジャイル開発採用の本来の目的が損なわれないように努める必要がある。

（IPA/SEC x x x x 記）

６平成 22 年度の検討課題‌

IPA/SEC で平成 21 年度に実施した「非ウォーターフォール型開発の調査研究」では、国内における非ウォーターフォール型開発の採用に際して、次の５つの重点課題を指摘した。（図表 1-12 参照）

①契約：契約のあり方、調達の制度設計

②価値評価：経営層やユーザ企業へのアピール

③環境整備：管理手法や技術面の整備

④普及：コンサルタント等の役割の整備、人材育成

⑤調査：欧米の競争力（ビジネスドライバ、産業構造）などの調査

今年度（平成 22 年度）の活動では、特に、①、②、③、④について取り組んだ。

昨年度（平成 21 年度）の事例収集をもとに、非ウォーターフォール型開発のモデル化

（プロセスモデル、ビジネス構造モデル）を最初に行い、それを基に、①の契約、②の経営層へのアピール、③のスキル定義、④の人材育成につての論議を行い、本報告書をまとめた。

日本のソフトウェア競争力を高める生き生きと働ける環境を作る

日本のソフトウェアの作り方

目指すべきゴール

非ウォーターホール型開発における

重点課題

契

約契約のあり方、調達、制度設計

値経営層やユーザ企業への理解促進

価

契約のあり方、調達、制度設計

約

価値経営層やユーザ企業への理解促進

評価

x 管理手法や技術面の整備

備

環境管理手法や技術面の整備

整備

コンサルタント等の役割の整備

及人 x x 成

コンサルタント等の役割の整備

欧米の競争力（ビジネスドライバ、

査産業構造など）の調査

欧米の競争力（ビジネスドライバ、

産業構造など）の調査

普及人 x x 成

査

調

図表 1-12 非ウォーターフォール型開発の課題と目指すべきゴール

今年度はこれらの課題について検討するため、非ウォーターフォール型開発WG23で前年度の課題全体について討議を行った後、開発モデルPT24、技術スキルPT、契約問題 PTの三つのPTを設置した。

（１）開発モデル PT の目的

①この活動におけるアジャイルの定義を行う。

②開発モデル（プロセスモデル、ビジネス構造モデル）を作成し、契約問題 PT、技術スキル PT への入力とする。

（２）技術スキル PT の目的

①課題－顧客・経営層へのアピールへの対応

・顧客・経営層が考慮すべき点とその検討。

②課題－非ウォーターフォール型開発に必要な技術の明確化－への対応

・エンジニアリング手法の検討

顧客側と開発側に必要な包括的エンジニアリング技術・プロジェクト運営技術・スキルの明確化。

③人材スキル・人材育成方法の明確化

・非ウォーターフォール型開発に必要な技術の明確化を受けての人材育成方法の検討

必要な技術・スキルの獲得方法の検討（人材像・スキル体系・人材育成方法）の検討。

・UISS、ITSS、ETSS への対応は、来年度以降、検討の予定とする。

（３）契約問題 PT の目的

①非ウォーターフォール型開発に適した契約モデルの検討

・（日本における）非ウォーターフォール型開発に適した契約モデルの検討。

②非ウォーターフォール型開発に適した契約のひな型の検討

・非ウォーターフォール型開発に適した契約モデルに沿った契約のひな型の作成。

アジャイル開発は変化への対応を重視するため、開発開始時点では仕様を固定せず、ユーザとのコミュニケーションにより状況に応じて開発途中で仕様を決めていく。その結果、契約時点で成果物が不明確なため、「仕事の完成」に対して報酬を支払う請負

23 WG（Working Group）

SEC（ソフトウェア・エンジニアリング・センター）では、WG をソフトウェア問題や課題が発生した際に、その対応のため特別かつ一時的に組織された作業グループと定義している。

24 PT（Project Team）

SEC（ソフトウェア・エンジニアリング・センター）では、PT を特定テーマの目的遂行のために、特別かつ一時的に成された WG 配下の組織と定義している。

契約はなじみにくい。

■開発モデルPT

基本プロセスモデル昨年度の報告書のビジネス構造の検討事例調査

基本プロセスモデル派生プ派生プロロセセスモスモデデ派生プロセルスモルデル

■契約問題PT

アジャイル契約のアジャイル契約雛形の

アジャイルに対するアジャイル契約の検討アジャイ雛形ル契約の

共通認識を持つ雛形

10のアジャイル契約 {23}

開発モデル PT、技術スキル PT、契約問題 PT 間の関係と各 PT の対象領域について、それぞれ図表 1-13、図表 1-14 に概要を示す。

各PTの進め方概要

情報の流れ

作業の流れ

基本プロセスモデルの検討

昨年度の報告書の事例調査

ビジネス構造

基本プロセスモデル

派生プロセルスルモデル

派派生生ププロロセセススモモデデ

2011年度予定

■契約問題PT

アジャイルに対する共通認識を持つ

アジャイル契約の検討

アジャイ雛ル形契約の雛形

アジャイル雛契形約の

アジャイル契約の

実証実験

・モデル契約

・管理技術

・開発技術等

10のアジャイル

契約 {23}

■技術・スキルPT

アジャイル認定制度

CI Agile {23}

アジャイルの管理手法、技法等の検討

アジャイル開発ガイド

（管理手法、技法、スキル等）

■開発モデルPT

■技術・スキルPT

アジャイル開発ガイドアジャイル認定制度アジャイルの管理（管理手法、技法、

CI Agile {23} 手法、技法等の検討スキル等）

図表 1-13 ３つのＰＴの関係

開発モデルPT

プロセスモデル

ビジネス構造モデル

技術スキルPT

・顧客アピール

・技術

・人材スキル

・人材育成

契約問題PT

契約モデル

契約ひな型

コンサル

成功支援

ニーズ

データ

ソリューション

調達

ビジネス構造

法律

具体化

実証プロジェクト

平成22年度

↑

↓

平成23年度

開発

顧客

実ビジネス

図表 1-14 ３つのＰＴの対象領域

７まとめ ‌

第一部では、本ＷＧ発足の背景、目的を述べ、そのコンテキストの中で「非ウォーターフォール型開発」および「アジャイル開発」を定義した。この活動の中では、現在の日本の産業構造の問題点を認識した上で、日本のソフトウェア競争力を高めるために、および、エンジニアがいきいきと働ける環境を作るために、これらの新しい開発手法を位置づけたいと考えている。

また、本検討ではアジャイル開発はすべての領域で最も優れた手法である、という立場をとっていないことに注意して欲しい。アジャイル開発には得意領域があり、その領域が現代の不確実性の高いビジネス環境の中で日々に拡大しているという認識である。

さらに、経営層への理解浸透が、次の一歩への大きな要素であるという認識から、企業情報システム開発における考え方のパラダイムシフトの意義を考察し、アジャイルへの懸念事項とともにまとめた。

参考文献

[1] IPA/SEC，「IT 人材白書 2010」，IPA/SEC，pp.143-154，2010

[2] 経済産業省産業構造審議会情報経済分科会情報サービス・ソフトウェア小委員会，「情報サービス・ソフトウェア産業維新～魅力ある情報サービス・ソフトウェア産業の実現に向けて～」，経済産業省，2006

[3] Mary Xxxxxxxxxxx& Xxx Xxxxxxxxxxx，“Lean Software Development”，

Addixxx-Xxxxxx，0003，訳: xxxx/xxxx/xxxx，「リーンソフトウェア開発~アジャイル開発を実践する 22 の方法」，日経 BP 社，2004

[4] Craix Xxxxxx， Agile and Iterative Development A Manager's Guide,

Addixxx-Xxxxxx Xxxfessional，2003，訳: xxxxxx，「初めてのアジャイル開発 ~

スクラム、XP、UP、Evo で学ぶ反復型開発の進め方~」，日経 BP 社，2004

[5] 「情報技術の革新とシステムインテグレーション事業の変容」, 産業研究（高崎経済大学附属研究所紀要）,第 44 巻第 1 号

xxxx://xxx0.xxxx.xx.xx/xxxx0/xxxxxx/xxx/00-0/00-0xxxxxxxxxxxxxxxx.xxx

[6] Bertxxxxxxx, X. Xxx, “General Systems Theory,” Georxx Xxxxxxxxx, 0068. xxx・xxxx（x）「一般システム理論」，みすず書房，1973.

[7] Weinxxxx, X. X., “An Introduction to General Systems Thinking,” John Wiley & Sons, 1975. xxxx（x訳）「一般システム思考入門」，紀伊國屋書店，1979.

[8] Checxxxxx, X. B., “Systems Thinking, Systems Practice,”John Wiley & Sons, 1981.

xxxxxx（監訳）「新しいシステムアプローチ」，オーム社，1985.

[9] xxxx，「情報システムサイクルと原要求の記述」，日本情報経営学会誌，Vol. 28(2), pp. 77-87, 2007.

[10] Zachxxx, X. X., “A framework for information systems architecture”, IBM Systems Journal, Vol. 26(3), pp. 276-292, 1987.

[11] 経営情報学会システム統合特設研究部会（編）「成功に導くシステム統合の論点—ビジネスシステムと整合した情報システムが成否の鍵を握る」，日科技連出版社，2005.

[12] xxxx，「企業情報システムアーキテクチャ」，翔泳社，2009.

[13] Roycx, X. X., “Managing the Development of Large Systems,” Proceedings of IEEE WESCON, pp. 1-9, 1970.

[14] Boehx, X. X., “A Spiral Model of Software Development and Enhancement,” ACM SIGSOFT Software Engineering Notes, Vol.11 (4), pp.14-24, 1989.

[15] Larmxx, X., “Agile and Iterative Development: A Manager's Guide,” Reading, Addison-Wesley, 2003. ウルシステムズ（訳）「初めてのアジャイル開発—スクラム，XP， UP，Evo で学ぶ反復型開発の進め方」，日経 BP，2004.

[16] Brooxx Xx., X. P., “The Mythical man-month: essays on software engineering,” Anniversary edition, Addison-Wesley, 1995. xxxxx（訳）「人月の神話—狼人間を打つ銀の弾はない」原著発行 20 周年記念増訂版，アジソン・xxxxx・パブリッシャーズ・ジャパン，pp. 256-258，1996.

[17] Alexxxxxx, X., xx al. “A Pattern Language,” Oxford Univ. Press, 1977. xxxx

（訳）｢パタン・ランゲージ｣，鹿島出版，1984.

[18] 真鶴町，｢美の基準―デザインコード｣，真鶴町まちづくり条例，1993.

[19] xxxx，「グーグル的建築家像をめざして—［批判的工学主義］の可能性」，in xxx・xxxx（x）「特集アーキテクチャ」，思想地図，Vol. 3，日本放送出版協会，2009.

[20] xxxx，「xxxxx『超線形設計プロセス』の限界とその突破」，Art and Architecture Review, Feb. 2010.

[21] Kuhn, X. X.,“The Structure of Scientific Revolutions,” The University of

Chicago Press, 1962. xxx（x）「科学革命の構造」，みすず書房，1971.

[22] Schixx, X., “Enterprise-Scale Agile Software Development” CRC Press, 2009.

[23] 「10 のアジャイル契約」

Petex Xxxxxxx，00 Contracts for your next Agile Software Project，2009 xxxx://xxxxxxxxxxxxxxxxxxxxxxxx.xxx/xxxx/xxxxxxxxx/00-xxxxx-xxxxxxxxx

「アジャイル認定制度」（CI Agile） xxxx://xxx.xxxxxxx.xxx

第二部アジャイル開発のモデル

１アジャイル開発の標準モデル ‌

アジャイル開発は、顧客の要求にしたがって優先度の高い機能を、要求・開発・テスト・リリースを 25短い期間で繰り返しながらシステム全体を構築していくことが標準となっている。

原則として、事前に開発の詳細な計画は作らず、１週間から４週間といった一定の短い周期で要求・開発・テストを繰り返しながら、動作可能なソフトを作り上げる。開発の繰り返し単位を「反復」と呼ぶ。

要求

開発

時間

スコープ

要求
開発
テスト

テスト

反復

ウォーターフォール型アジャイル型

図表 2-1 アジャイル開発を単純化した標準モデル

25 ここでの「要求、開発、テスト」等の用語は、イメージを持って頂くことを主目的に曖昧なまま使用している。SLCP やアジャイルの用語との対応については後述。

２アジャイル開発の開発モデル ‌

非ウォーターフォール型開発に適した契約モデル等を検討するにあたって、今後の課題を明確にすることを目的に、IPA/SEC で昨年度（平成 21 年度）実施した「非ウォーターフォール型開発の調査研究」において調査した非ウォーターフォール型開発の 17 社 22 事例をベースに、アジャイル開発の実績を調査しモデル化した。

このモデルは、以下の２つからなる。

①プロセスモデル

②ビジネス構造モデル

２．１アジャイル開発のプロセスモデル ‌

非ウォーターフォール型開発に適した契約モデルの検討にあたっては、開発プロセスをモデル化し、それに沿って契約形態を考える必要がある。

IPA/SEC で昨年度（平成 21 年度）に実施した「非ウォーターフォール型開発の調査研究」で調査した非ウォーターフォール型開発の 17 社 22 事例をもとに以下に示す３つのプロセスモデルにまとめた。

モデル１を基本プロセスモデルとし、モデル２、モデル３はその派生プロセスモデルとした。

第１反復

第ｎ反復

テスト

開発要求

テスト

開発要求

（１）プロセスモデル１（図表 2-2）

企画

第１反復

第ｎ反復

第１反復

第ｎ反復

システム運用

・・・

第ｎ反復

第１反復

・・・

第ｎ反復

第１反復

・・・

第ｎ反復

第１反復

テスト

開発要求

テスト

開発要求

テスト

開発要求

テスト

開発要求

第1リリース

• n=1のケースもあり。

第2リリース

第mリリース

図表 2-2 アジャイル開発のプロセスモデル１

システム全体の要求・アーキテクチャ設計・基盤開発を行わずに、直ぐに第１リリースの開発に取りかかるモデル。

調査事例では、11 事例がこのプロセスモデルであった。

（２）プロセスモデル２（図表 2-3）

第１反復

第ｎ反復

第１反復

第ｎ反復

システム運用

企画

要求・アーキ

テクチャ設計

・基盤開発

・・・

第ｎ反復

第１反復

第ｎ反復

第１反復

テスト

開発要求

テスト

開発要求

テスト

開発要求

テスト

開発要求

第 1 リリース第 m リリース

• 比較的大規模システム／新規開発で全体のシステム構造が不明確なケースなど

図表 2-3 アジャイル開発のプロセスモデル２

第１反復/第１リリースの前に、システム全体の大まかな要求定義・アーキテクチャ設計・基盤開発を行った後に、反復開発に着手するモデル。

調査事例では、3 事例がこのプロセスモデルであった。

（３）プロセスモデル３（図表 2-4）

第１反復

第ｎ反復

第１反復

第ｎ反復

第１反復

第ｎ反復

・・・

リリース前

テスト

第１反復

システム運用

企画

・・・・・・

第ｎ反復

第１反復

リリース前

テスト

・・・

第ｎ反復

テスト

開発要求

テスト

開発要求

テスト

開発要求

テスト

開発要求

第1リリース

第mリリース

・アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが、各リリース工程前に行う重点的なテストを実施することがある。

・リリースは複数回繰り返される

図表 2-4 アジャイル開発のプロセスモデル３

アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが、各リリース前に、品質を担保するために、重点的なテストを実施するモデル。

調査事例では、8 事例がこのプロセスモデルであった。

以上の 3 プロセスモデルは、現実のプロジェクトを抽象化したものである。実際の

各事例とプロセスモデルとの対応を付録 1 に示す。

（４）アジャイル開発のプロセスモデルで使用されている用語の説明

Agile開発の用語

用語の解説

アジャイル開発のプロセスモデルで使用されている用語の説明を図表 2-5 に示す。

Agile開発の用語

用語の解説

企画

ウォーターフォール型開発の「企画プロセス」と「要求定義プロセス」と同様の内容。

ビジネスゴールをもとに、プロダクト／プロジェクトのコンセプト、システム化の目的や目標となるゴール、ビジネス要求に紐付けされたシステム要求と主要な機能について立案し、ステークホルダー間で合意を形成する。

反復

1～4週間の連続した期間で行う要求・開発・テストの繰り返しの単位を反復と呼ぶ。この要求・開発・テストを繰り返す固定された時間枠を「タイム・ボックス」（時間枠）と呼ぶ。作業が時間的に間に合わない場合でもタイム・ボックス自体の延長はしない。

反復を繰り返すことで、部分的に稼働する最終システムが作り出され、連続する反復は直前の反復の作業に基づいて最終製品が完成するまでシステムを進化／洗練させていく。

Scrumでは「スプリント」、 XPでは、「イテレーション」と呼ぶ。

リリース

動作するソフトウェアを顧客（理想的にはシステムの利用者）に提供することをリースと呼ぶ。

顧客は、リリースされたソフトウェアを検証することで、開発の実際の進捗度を確認することができ、要求仕様が正確に成果物に反映していることを確認でき、実際に機能の一部を使ってみることで、要求仕様そのものの検証が行える。

要求

各反復の最初に、顧客（理想的にはシステムの利用者）と開発者は、対話・協調しながら今回の反復で何を開発し、何を開発しないのかについての意思決定を行う。そこで決定された今回の反復で開発するx xを指す。

顧客と開発者は要求の中から、今回の反復で、開発・実装する機能を選択する。

通常、顧客は、最も必要な優先度の高い機能から順に選択し、開発者は、選択された機能を優先度順に実装していく。

開発

要求で決定された機能の設計、プログラミング（実装）、単体テスト、レビュー、ふりかえり等の一連の作業を指す。アジャイル開発では、不要なドキュメントは作らず、動作するソフトウェアを重視する。

レビューには、コードレビューやテストレビュー、顧客（理想的にはシステムの利用者）も参加したプロダクトのレビューなどがあり、設計や実装に対するフィードバックを目的に行う。

ふりかえりとは、反復の最後にチームメンバーが集まり、チームのやり方やチームワークを点検し、改善する特別なミーティングのことで、次の反復に役立たせて成果へとつなげる。

XPにおける主なプラクティスとして、「シンプルデザイン」、「テスト駆動開発」、「頻繁なリファクタリング」、「ペアプログラミング」、「共同所有権」、「継続的インテグレーション」、「コーディング規約」等が上げられる。Scrumにおける主なプラクティスとして、「スプリント計画」、「スプリントバックロググラフの作成」、「自律的な組織化チーム」、「スクラムミーティング」、「日次ビルド」、「スプリントレビュー」等が上げられる。

テスト

反復で作成されたプログラムによって要求で合意した機能が実現しているか、確認するための受入れテストを指す。受入れテストの内容は、顧客（理想的にはシステムの利用者）が定義する。

顧客はこのテストにより、成果物の確認と進捗の確認を行う。

受入れテストでは、単体テスト後に検証される機能より、粒度は大きくなる。

開発を始めるまえに、最低限のシステム全体の大まかな要求定義・アーキテクチャ設計・基盤開発を行う

アーキテクチャ

作業を指す。

設計・基盤開発

(全体の基盤設計・開発を第一反復／リリースとして行う場合もある。)

反復に入る前に、変更のコストが大きい意志決定（アーキテクチャ設計など）を行うことがある。

リリース前テスト

アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが、各リリース工程前に重点的なテストを実施することがある。

納品や次のリリースの製造に向け、各反復の最後に行うテストの最後に追加して、品質保証の観点でテ

ストを行う。

システム運用

システムを実際に運用する

図表 2-5 アジャイル開発のプロセスモデルで使用されている用語の説明

２．２アジャイル開発のビジネス構造モデル ‌

平成 21 年度の「非ウォーターフォール型開発に関する調査」において実施した 17 社、

22 事例の調査結果から導きだした、アジャイル開発のビジネス構造モデルの基本パターン

（ソフトウェア開発に関わる役割と契約の起こる位置）を図表 2-6 に示す。

契

提供する人

使う人

作る人2

作る人

保守する人

xxする人

xで、契約の起こる可能性がある場所を示す。同一の組織内の場合は、契約はない。

契約には、請負契約や準委任契約等の種類がある。

図表 2-6 ビジネス構造モデルの基本パターン例

・使う人	⇒	システムを実際に使用する人（システムの利用者、エンドユーザ）。
・提供する人	⇒	開発されたシステムやサービスを、使う人に提供する人。
・作る人	⇒	システムの開発者
・作る人２	⇒	作る人の会社と契約している、作る人と一緒に開発する人。

（作る人の会社とは別会社が多い）

・保守する人 ⇒ リリースされたシステムを保守する人。

（作る人と重なることが多い）

・補佐する人 ⇒ アジャイル開発の進め方等で、開発プロジェクトを支援する人。

（コンサルタントやファシリテーターが多い）

図表 2-6 から、アジャイル開発を行う際に契約の起こり得る箇所を抽出できる。上記の四角で囲まれた役割間で契約が起こり得るが、役割が同じ会社内の場合には契約は起こらない。また、現時点で契約形態としてよく知られているのは、「請負契約」や「準委任契約」である。

上記基本パターンをもとに、各事例を分析した結果を付録２に示す。

３アジャイル開発プロセスの SLCP へのマッピング‌

本来、アジャイル開発は、システム開発に関する既存の価値観、原則を大きく置き換える考え方である。よって、既存のフレームワークと言葉をマッピングすることは、誤解を招きかねない作業である。しかしながら、既存の用語に馴染んだ方にもアジャイル開発を理解して頂けるためのガイドとして、この章を設けた。

ウォーターフォール型開発プロセスの視点からアジャイル開発プロセスを俯瞰するために、共通フレーム 2007 をベースとし、SLCP（software life cycle process）に沿ったシステム開発に関連する作業とアジャイル開発プロセスとのマッピングを行った。

３．１共通フレーム 2007 体系抜粋 ‌

SLCP を表す主要な図として、「共通フレーム 2007 体系抜粋」を図表 2-7 に、「適格性確認要求事項と適格性確認テストとの関係」を図表 2-8 に示す。

出典：「共通フレーム 2007 第 2 版」（IPA/XXX, 0000）図表 2-7 共通フレーム 2007 体系抜粋

システム要件定義

（システム適格性確認要求事項）

詳細設計・作成

利害関係者要件

（要件定義）

システム結合

運用テスト

（運用）

ソフトウェア要件定義

ソフトウェア適格性確認要求事項

ソフトウェア適格性確認テスト

投資効果，業務効果

（運用）

システム化構想，計画

（企画）

システム適格性確認テスト

システム方式設計

ソフト方式設計

ソフトウェア結合

システム化構想，計画投資効果，業務効果

（企画）（運用）

利害関係者要件運用テスト

（要件定義）（運用）

システム要件定義

（システム適格性確認要求事項）システム適格性確認テスト事

業

システム方式設計システム結合層

業

務層

ソフトウェア要件定義ソフトウェア適格性確認テストＩ

（（ソフトウェア適格性確認要求事項））Ｔ

シ

ソフト方式設計ソフトウェア結合ソス

フテ

トム

ウ層

詳細設計・ x x ェ

ア

層

システム要件定義

（システム適格性確認要求事項）

詳細設計・作成

利害関係者要件

（要件定義）

システム結合

運用テスト

（運用）

ソフトウェア要件定義

ソフトウェア適格性確認要求事項

ソフトウェア適格性確認テスト

投資効果，業務効果

（運用）

システム化構想，計画

（企画）

システム適格性確認テスト

システム方式設計

ソフト方式設計

ソフトウェア結合

システム化構想，計画

（企画）

投資効果，業務効果

（運用）

利害関係者要件

（要件定義）

運用テスト

（運用）

システム要件定義

（システム適格性確認要求事項）

システム方式設計

ソフトウェア要件定義ソフトウェア適格性確認テスト

（ソフトウェア適格性確認要求事項））

ソフト方式設計

詳細設計・作成

ソフトウェア結合

システム結合

システム適格性確認テスト

事業層

業務層

ＩＴシステム層

ソフトウェア層

出典：「共通フレーム 2007 第 2 版」（IPA/XXX, 0000）図表 2-8 適格性確認要求事項と適格性確認テストとの関係

３．２ SLCP とデータ白書 2009 で使用されている開発工程のマッピング ‌

データ白書 2009 で使用されている開発工程の名称と、SLCP‒共通フレーム 2007 との

対応関係を図表 2-9 に示す。

「工程」列には、データ白書 2009 で使用している工程名称を示している。「SLCP プロセス/ アクティビティ」と「SLCP の定義」列で SLCP との対応で工程の定義を示している。

工程

SLCP プロセス/ アクティビティ

SLCP の定義

システム化計画

システム化計画の立案

企画者は、システム計画の基本要件の確認を行い、対象業務の確認、システムが実現している機能等の確認と整理によ

り、システム課題を定義、業務機能をモデル化する。モデルからシステム化機能の整理、システム方式とシステム選定方針の策定、付帯機能・設備やサービスレベル及び品質の基本方針の明確化、プロジェクトの目標設定、実現可能性の検討、全体開発スケジュールの作成、費用とシステム投資効果の予測を行い、具体化したシステムに対する前提条件を整理し、システム化計画として文書化し承認する。複数プロジェクト

がある場合はプロジェクト計画の作成と承認を得る。

要件定義

システム要件定義

ソフトウェア要件定義

開発者は、システム及びソフトウェアに関する要件について技術的に実現可能であるかを検証し、システム設計が可能な技術要件に変換し、システム要求仕様と確立したソフトウェア要件を文書化する。また、設定した基準を考慮して、システム要件、ソフトウェア要件を評価し文書化する。さらに、

共同レビューを行う。

基本設計

システム方式設計

ソフトウェア方式設計

開発者は、ハードウェア構成品目、ソフトウェア構成品目及び手作業を明確にし、システム方式及び各品目に割り振ったシステム要件を文書化する。また、ソフトウェア品目に対する要件をソフトウェア方式に変換する。最上位レベルの構造とソフトウェアコンポーネントを明らかにし、データベース

の最上位レベルでの設計、利用者文書の暫定版の作成、ソフトウェア結合のための暫定的なテスト要求事項及び予定等

を明らかにする。方式設計の評価と共同レビューを実施する。

詳細設計

ソフトウェア詳細設計

開発者は、ソフトウェア品目の各ソフトウェアコンポーネントに対して詳細設計を行う。ソフトウェアコンポーネント

は、コーディング、コンパイル及びテストを実施するユニットレベルに詳細化する。また、ソフトウェアインターフェイス、データベースの詳細設計、必要に応じて利用者文書を

更新し、ユニットテスト、結合テストのためのテスト要求事項及び予定を定義する。評価及び共同レビューを実施する。

製作

ソフトウェアコード作成及びテスト

開発者は、ソフトウェアユニット及びデータベースを開発する。また、それらのためのテスト手順及びデータを設定する。さらに、テストを実施し、要求事項を満足することを確認する。これらに基づいて、必要に応じて利用者文書等の更新を行う。また、ソフトウェアコード及びテスト結果を評価する。

出典：「データ白書 2009－工程の呼称と SLCP マッピング－」（IPA/XXX, 0000）

図表 2-9 SLCP とデータ白書 2009 で使用されている開発工程のマッピング(1/2)

工程	SLCP プロセス/ アクティビティ	SLCP の定義
		開発者は、ソフトウェアユニット及びソフトウェアコンポー
		ネントを結合して、ソフトウェア品目にするための計画を作
		成し、ソフトウェア品目を完成させる。また、結合及びテス
結合テスト	ソフトウェア結合システム結合	トを行う。完成したソフトウェア品目と合わせてハードウェア品目、手作業や他システム等とあわせてシステムに結合、要件を満たしているかをテスト、システム適格性確認テスト
		実施可能状態であることを確認する。必要に応じて利用者文
		書等の更新を行う。テストの評価と共同レビューを実施す
		る。
		開発者は、ソフトウェア品目の適格性確認要求事項及びシス
総合テスト	ソフトウェア適格性確認テスト	テムに関して指定された適格性確認要求事項に従って、適格
（ベンダ確認）	システム適格性確認テスト	性確認テスト及び評価を行う。必要に応じて利用者文書等の
		更新を行う。また、監査の実施と支援をする。
		開発者は、契約の中で指定された実環境にソフトウェア製品
総合テスト（ユーザ確認）	ソフトウェア導入支援ソフトウェア受け入れ支援	を導入するための計画を作成し、導入する。開発者は、取得者によるソフトウェア製品の受け入れレビュー及びテストを支援する。また、契約で指定するとおりに、
		取得者に対し初期の継続的な教育訓練及び支援を提供する。
		ソフトウェア製品の運用及び利用者に対する運用支援を行
フォロー（運用）	運用プロセス	う。運用者は、このプロセスを管理するために具体化したx xプロセスに従って、運用プロセスの基盤となる環境を確立する、など。

出典：「データ白書 2009－工程の呼称と SLCP マッピング－」（IPA/XXX, 0000）図表 2-9 SLCP とデータ白書 2009 で使用されている開発工程のマッピング(2/2)

３．３ SLCP とアジャイル開発プラクティスとのマッピング‌

アジャイル開発を理解しやすくするためのガイドとして、敢えて、SLCP26のプロセス、アクティビティとアジャイル開発のプロセス、プラクティスのマッピングを示すと、図表 2-10 のようになる。

SLCP		データ白書2009	アジャイル開発
プロセス	アクティビティ	開発工程	プロセス		プラクティス
企画プロセス	・プロセス開始の準備・システム化構想の立案・システム化計画の立案	システム化計画	企画		Scrum ・ゲーム前計画
要件定義プロセス	・プロセス開始の準備・利害関係者要件の定義・利害関係者要件の確認				XP ・リリース計画ゲーム・イテレーション計画ゲーム Scrum ・スプリント計画
	・プロセス開始の準備・システム要件定義・ソフトウェア要件定義	要件定義		要求
	・システム方式設計・ソフトウェア方式設計	基本設計
開発プロセス	・ソフトウェア詳細設計・ソフトウェアコード作成及びテスト	詳細設計	反復		XP ・システムのメタファ・シンプルデザイン・テスト駆動開発・頻繁なリファクタリング・ペアプログラミング・共同所有権・コーディング規約・受け入れテスト
		製作
				開発/テスト

	・ソフトウェア結合（ソフトウェア）・システム結合（ソフトウェア）・ソフトウェア結合（テスト）・システム結合（テスト）・ソフトウェア適格性確認テスト・システム適格性確認テスト	結合テスト			Scrum ・スプリントバックロググラフの作成・自律的な組織化チーム・スクラムミーティング・1日以内の障害除去・共通の部屋・日次ビルド・スプリントレビュー
		総合テスト（ベンダ確認）

	・ソフトウェア受入れ支援	総合テスト（ユーザ確認）
	・ソフトウェア導入
運用プロセス		フォロー（運用）	運用

出典：・SLCP 「共通フレーム 2007 第 2 版」（IPA/SEC, 2009）

・開発工程「データ白書 2009－工程の呼称と SLCP マッピング－」

（IPA/SEC, 2009）

・アジャイル開発プラクティス

「非ウォーターフォール型開発に関する調査報告書」（IPA/XXX, 0000）図表 2-10 SLCP とアジャイル開発プラクティスとのマッピング

26 SLCP におけるアクティビティ、さらにそれを細分化した「タスク」は何をすべきか

（What to do）を表す。これに対して、アジャイル開発におけるプラクティスは主に、どのようにするか（How to do）を表す。このように、両者は全く異なる考え方に基づいており、ここで示すマッピングは参考でしかない。

４まとめ ‌

第一部では、国内の事例を基に、アジャイル開発の「プロセスモデル」および「ビジネス構造モデル」を作成した。さらに、その際に理解の助けとなるよう、ウォーターフォール型開発で使われている言葉の定義とのマッピングを行った。

また、アジャイル開発に馴染みのない方にもイメージを持ってもらえ、契約問題や技術スキルの検討の前提となる共通コンセプトが示せるように留意したつもりである。

前年度の収集事例について、プロセスモデルおよびビジネス構造モデルの観点による分析を、付録１、付録２に添付する。

付録１調査事例とプロセスモデルの対応一覧 ‌

モデル名

調査事例

調査事例とプロセスモデルの対応一覧 27を付図表 1-1 に示す。

モデル名	調査事例
モデル１	小売業・ユニケージ、社内版SNS、OSS版SNS、サプラチェーンマネジメントシステム、携帯ソーシャルゲーム、携帯向けブログ、パッケージ、教育機関向け統合業務PKG、株取引Webアプリ、共通EDI、開発案件管理、製造業向けプロトタイプシステム
モデル２	研修運営システム、プロジェクト管理システム、アプリPF開発
モデル３	共通認証システム、教務Webシステム、ミドルウェア開発、生産管理システム、Webメディア開発、アジャイル開発支援、検索エンジン開発、プラント監視制御計算機システム

出典：「非ウォーターフォール型開発に関する調査報告書」（IPA/XXX, 0000）」付図表 1-1 事例とモデルの対応一覧

27 調査したのは 17 社 22 事例であるが、モデル 1 の SNS 事例が２つに分かれているためここでは 17 社 23 事例となっている。

付録２ビジネス構造モデルによるアジャイル開発事例の分析例 ‌

平成 21 年度の「非ウォーターフォール型開発に関する調査」において実施した 17 社、

22 事例の調査結果に基づくアジャイル開発のビジネス構造を分析した結果、10 パターンに分類された。

（１）ビジネス構造モデルパターン１（６事例）

同じ会社の範囲

x委任契約

事例(a)，(b-2)，(s)，(t) 請負契約

事例(j)，(k)

作る人

提供する人

使う人

付図表 2-1 ビジネス構造モデルパターン１

（２）ビジネス構造モデルパターン２（２事例）

x委任契約(推敲フェーズまで)

＋請負契約(作成フェーズ以降) 事例(d)

一括作成契約事例(m)

x委任契約事例(d)

請負契約事例(m)

作る人2

作る人

提供する人

使う人

付図表 2-2 ビジネス構造モデルパターン２

（３）ビジネス構造モデルパターン３（３事例）

社内開発のため契約なし事例(b-1)，(e)，(u)

作る人

提供する人

使う人

付図表 2-3 ビジネス構造モデルパターン３

（４）ビジネス構造モデルパターン４（１事例）

準委任契約事例(l)

契

社内開発のため契約なし事例(l)

作る人

使う人

補佐する人

提供する人

付図表 2-4 ビジネス構造モデルパターン４

（５）ビジネス構造モデルパターン５（１事例）

契

サービスの利用料金がビジネスの基本単位となるASP契約(ASPのためのSI)

事例(c)

作る人

提供する人

使う人

付図表 2-5 ビジネス構造モデルパターン５

（６）ビジネス構造モデルパターン６（２事例）

社内開発のため契約なし事例(n) ，(o)

作る人

提供する人

使う人

付図表 2-6 ビジネス構造モデルパターン６

（７）ビジネス構造モデルパターン７（２事例）

社内開発のため契約なし事例(g)

不明

事例(i)

契

不明

事例(g)

四半期単位での準委任契約事例(i)

作る人2

作る人

提供する人

使う人

付図表 2-7 ビジネス構造モデルパターン７

（８）ビジネス構造モデルパターン８（１事例）

アジャイル経験が豊富なコンサルタントの支援

事例(v)

x委任契約事例(v)

契

作る人2

作る人

使う人

補佐する人

提供する人

付図表 2-8 ビジネス構造モデルパターン８

（９）ビジネス構造モデルパターン９（４事例）

契

請負契約

事例(p)，(q)，(r) 請負契約(毎月更新)

事例(h)

作る人

提供する人

使う人

付図表 2-9 ビジネス構造モデルパターン９

（10）ビジネス構造モデルパターン 10 （１事例）

使う人

契約不明

(f)

作る人

提供する人

付図表 2-10 ビジネス構造モデルパターン 10

基本パターンによるアジャイル開発事例の分析における、調査事例と契約の対応一覧 28

契約方式

調査事例

を付図表 2-11 に示す。

契約方式	調査事例
請負契約	(h)携帯向けブログシステム※毎月更新、(j)共通認証システム、(k)プロジェクト管理システム、(m)教務Webシステム※パートナー契約有り、(p)ミドルウェア開発、(q)株取引Webアプリ、 (r)プラント監視制御計算機システム
準委任契約	(i)パッケージ※四半期単位、(l)アプリPF開発、(s)生産管理システム、(a)小売業・ユニケージ、 (b-1)社内版SNS、(b-2)OSS版SNS、(t)Webメディア開発、 (v)共通EDI
準委任契約(推敲フェーズまで) ＋請負契約(作成フェーズ以降)	(d)研修運営システム
派遣契約	(o)検索エンジン開発
サービスの利用料金がビジネスの基本単位となる、ASP契約	(c)サプラチェーンマネジメントシステム
契約なし	(g)携帯ソーシャルゲーム※パートナー契約有り、 (n)教育機関向け統合業務PKG、(e)開発案件管理、 (u)アジャイル開発支援
不明	(f)製造業向けプロトタイプシステム

出典：「非ウォーターフォール型開発に関する調査報告書」（IPA/XXX, 0000）」付図表 2-11 事例と契約の対応一覧

分類された 10 パターンは、平成 21 年度に実施した「非ウォーターフォール型開発に関する調査」から分析したものであり、一般的なアジャイル開発を網羅している訳ではない。

28 調査したのは 17 社 22 事例であるが、準委任契約の SNS 事例が 2 つに分かれているため、ここでは 17 社 23 事例となっている。

第xx 非ウォーターフォール型開発における技術及びスキル

１非ウォーターフォール型開発における技術スキル検討の趣旨‌

１．１検討の背景 ‌

IPA/SEC では、昨年度（平成 21 年度）に実施した「非ウォーターフォール型開発の調査研究」に引き続き、本年度は、国内における非ウォーターフォール型開発の採用に際しての課題として、次の５つの重点テーマについて検討してきた。

①契約：契約のあり方、調達の制度設計

②価値評価：経営層やユーザ企業へのアピール

③環境整備：管理手法や技術面の整備

④普及：コンサルタント等の役割の整備、人材育成

⑤調査：欧米の競争力（ビジネスドライバ、産業構造）などの調査

第xxでは、これらの重点課題の中から、本年度（平成 22 年度）技術スキル PT が検討を行ってきた、②価値評価：経営層やユーザ企業へのアピール、③環境整備：管理手法や技術面の整備、④普及：人材育成について記述する。

１・２非ウォーターフォール型開発における技術スキル検討の目的 ‌

本 PT では、次の３つのサブテーマの検討内容を次のように設定した。

（１）経営層にとっての価値

従来のソフトウェア開発においては、多くの企業の経営者は開発費用と効果目標を設定した後は、プロジェクトチームに任せっきりであった。そして、そのような企業においては、作業の多くは発注担当者に丸投げされ、いわば経営者自身の関与は極めて少なかったといえる。しかし、経営環境の激変、戦略変更、業務改革などといった経営の不確実性は一段とに増大しており、もはや、経営層としては放置できなくなっている。

実際にソフトウェアにおける大きな品質トラブルの背景には、経営層の意思決定の遅れや、理解不足、さらに関係部門との経営上の調整不足などが見られ、経営者自体の能力不足の結果として責任を問われかねないケースも少なくない。経営層がどのようにシステム開発にかかわっていくべきかの議論なくして、今後の情報システム開発はあり得ない。こうした中で、どのような開発手法を採用するかも、開発チームだけではなく、経営層の問題となってきた。したがって、非ウォーターフォール型開発についても十分に理解を深める必要がある。とりわけ、経営層にとっての意義と価値を理解することが不可欠であろう。このような状況を踏まえ、新しいマネジメント手法、適切な開発形態の選択、見積り、品質評価、進捗管理、顧客側と開発側のロール（役割）の明確化、及びこれらの顧客・経営層への可視化などについて検討を行い、第一部５章にまとめた。

（２）非ウォーターフォール型開発に必要な技術の明確化

新しい開発手法についてはもはや議論すべき時期は終わった、いかに実践し実務に取り入れていくのかという現実的なテーマに取り込むべきであるともいわれる。そのためには、顧客側と開発側に必要な包括的な技術、プロジェクト運営技術、スキルを明確にしておか

ねばならないだろう。かつては、ソフトウェア開発技術者には適性が必要であるとされ、適性試験が実施された。では、今、非ウォーターフォール型開発に求められているのも適性なのか、あるいはもっと個人的な素質なのか、そうではなく、育成可能なスキルなのか、大きな問題として、十分、検討されなければならない。

（３）人材スキル・人材育成方法の明確化

本 PT では、育成可能性のある、“スキル”を議論する。それは講義形式の教育やカリキュラムで十分とは誰も考えないであろう。非ウォーターフォール型開発に必要なスキルを身につけるための人材育成方法、さらに、人材像、スキル体系について、実際に非ウォーターフォール型開発でビジネス展開している企業の人材育成方法を事例として取り上げ、検討する。また、現在の開発手法の課題を解決するために、企業内における改善活動の役割について議論する。

２非ウォーターフォール型開発に必要な開発技術・スキルの明確化 ‌

特にビジネス環境の変化が激しい領域のビジネスに戦略的に活用されている情報システムにおいて、ビジネス環境の変化に迅速に対応することが一層求められるようになっている。このようなコンテキストにおいては、従来のウォーターフォール型のソフトウェア開発形態では十分に対応できないことが多い。それは、数多くのプロジェクトの失敗、動かないシステムの存在、IT業界がもつ３Kイメージ 1 などの様々な事象が発生していることからも明らかである。

今は、もはや、非ウォーターフォール型開発を、いかに実践し実務に取り入れていくのか、という現実的なテーマに取り組むべきである。したがって、顧客側と開発側（事業側・業務側と開発側）に必要な包括的な技術、プロジェクト運営技術、スキルを明確にする必要がある。

なお、非ウォーターフォール型開発に関する技術（例：ペアプログラミング、カンバン等）やスキルの詳細については本報告書の対象外とする。

また、検討の方法として、ウォーターフォール型開発と、非ウォーターフォール型開発の代表格であるアジャイル開発の違いに着目することとし、そこで重視される技術、スキルの違いを浮かび上がらせるという方法を採ることにする。

２．１アジャイル開発における“スキル”の基本的考察 ‌

（１）スキルと価値観の違い

様々な定義、表現方法があると思われるが、本報告では、以下の様にスキルと価値観とを区別し定義する。また、本章ではスキルをクローズアップするため、価値観について、今回は考察しないものとする。

① スキル

プロジェクトに参加するメンバの役割に応じた、もしくは他の役割を支援するための能力。「～～が出来る、～～が作れる」と表現し、一般的な教育、育成によって成長が可能。プロジェクトのアウトプットに直接的に作用しやすい。

② 価値観

非ウォーターフォール型開発に求められる大事なものを理解し、それに沿って活動する心構え。「～～を優先する、～～を大事にする」と表現し、教育、育成による成長というよりも、気付き、自立心により磨かれていくものである。プロジェクトのアウトプットには間接的に作用し、チームビルド、コミュニケーション、自己実現といった要素には大きな影響をもたらす。

1 IT 業界がもつ３K イメージと実態とは合致していない。「給与」「労働時間の長さ」「職場の雰囲気」が要因となる就業満足度への影響は影を潜めつつある。

（「IT 人材白書 2010」(IPA IT 人材育成本部,pp.142,2010) xxxx://xxx.xxx.xx.xx/xxxxxx/xxxxxx/xxxxx.xxxx

（２）アジャイル開発における中核的な価値と基本原則

アジャイル開発で言われる中核的な価値の一部を紹介する。ただし、これは価値であり、それを理解し実現するのは適性と定義する。したがって、この価値を実現出来る能力をスキルとは呼ばないことにする。また、これらの価値は、ウォーターフォール型開発においても必要とされる。

①コミュニケーション

ペアプログラミング、コーディング標準、リファクタリング、顧客との近しい関係などの主要なコミュニケーションに焦点をあてる。

②シンプルさ

必要なことだけを行い、それ以上は何も行わない、最もシンプルな設計が実装され、複雑な実装はリファクタリングされる。

③フィードバック

振る舞いを理解し、コーディングし、テスト（顧客の受入れテストも含む）する活動を時間・日単位で実行する。すばやいフィードバックによってチームと顧客の理解とビジネスの目的を継続的に一致させる。

④xx

コードよりも先にテストを書くxx、シンプルな方法を選択するxx、早い時期に納品しフィードバックを素早く受けるxx、リファクタリングするxxがまさしく求められている。

⑤尊重

チームメンバの相互の尊重の上に成り立つ。仲間を勇気づけ、くじかせない。

さらに、アジャイル開発における基本原則を紹介したい。これらは原則であり、それを理解し実現するものを適性と定義する。つまり、技術、スキルを挙げているのではない。これらはウォーターフォール型開発においても同様に必要とされる[1]。

①人間性

ソフトウェアは人によって人のために書かれる。人に焦点をあて、人に力を与え、利益を与える、エンパワーメント(自己の権利や自尊心を取り戻すとともに、自主的な意思決定や行動を促すとともに支援を行う)など。

②考察

なぜ、どのように行っているかを考える、チーム自身による調整、プロセスにおける反省、結果に対する反省、人に対する反省、チームをよりよく動かすための反省。

③質

生まれつき備わっているもの、品質・スケジュール（コスト）は固定され、スコープが可変であることを大原則とする。

④赤ちゃんの歩幅で前進

インクリメンタル思想、小さなサイズの機能性を実装した新しいインクリメントを反復する、「与えられた時間内で A とB を改善するために私たちに何ができるか、を重視する、すなわち、予算が決まっているときは、優先度を付けて、出来るものから少しずつ開発を積み重ねていく。

２．２多元的観点による“スキル”の明確化 ‌

（１）役割によるスキルの違い

検討の前提に従い、ウォーターフォール型開発と、非ウォーターフォール型開発の代表格であるアジャイル開発において、プロジェクトに参加するメンバの期待役割を提示し、両者の違いによって表現した非ウォーターフォール型開発に必要とされる作業例を図表

3-1 に示す。

アジャイル型開発

ウォーターフォール型開発

プロダクトオーナー

システムのための要件を定義し伝達する役割、優先順位を設定

ユーザー

事業、顧客側

スクラムマスター

ファシリテーティング

※調整役であって意思決定をする役割ではないアジャイルプロセスのルールを施行する

プロジェクトマネージャプロジェクトリーダー、ＳＥ

人モノ金の判断をする

仕様、スケジュール、要員の管理報告、変更の管理

開発者メンバー

要求定義を行う

コードを書きながらプロダクトオーナーやテスターと協力してコードが開発されていることを確認する

コードのための単体テストを書く

受け入れテストをサポートするテストを書き、テストの自動化を行う毎日コードを共有リポジトリにチェックインする

開発者、ＳＥ、ＰＧ要求定義を行うコードを書く

単体テストを書く

テストの自動化を行うコードを管理する

開発者メンバー（テスターを含む）

機能の理解を確認し、要望されている機能と紐付けられているか確認する。

コードが書かれている間に、受け入れテストのテストケースを書く。受け入れテストの際にコードをテストする

毎日、共有リポジトリにテストケースをチェックインする

受け入れテストやコンポーネントテストを、継続的なテスト環境に統合するためにテストの自動化を開発する

テスター

機能理解、要望機能との紐付け確認テストケースを書く

テストをする

テストコードを管理する

図表 3-1 アジャイル型/ウォーターフォール型開発に必要とされる作業例（1/2）

アジャイル型開発

ウォーターフォール型開発

プロダクトオーナー

システムのための要件を定義し伝達する役割、優先順位を設定

ユーザー

事業、顧客側

アーキテクト（プロジェクト外）

多くのアジャイルチームはアーキテクトという言葉が役職に就く人々を含んでいない。

アーキテクチャはアジャイルチームにとって非常に重要である。チームの活動を通して「アーキテクチャは出現する」と言われているが、システムレベルでは、アーキテクチャはシステムの

全体の構造を決定する責任を持つシステムアーキテクト、ビジネスアナリストによって調整されるものである。

アジャイルチームはチームの外側に存在する複数のアーキテクトと話す窓口を持つ

アーキテクト

設計初期に登場

システム全体の構造を決定する責任あり

プロジェクトチームは、複数のアーキテクトと話す窓口を持つことになる。

インフラ（プロジェクト外）

マシン、ネットワーク環境を提供する

インフラ

マシン、ネットワーク環境を提供する

QA・品質保証（プロジェクト外）

多くの場合、品質保証のための主な責任は、開発者やテスターに移行されることになる。

QA担当者は全体の品質を監督するという、本来意図されていた役割（レビューと品質の監視）に戻る。

QA部門にいたリソースの多くをプロジェクトチームと一緒に仕事できるように派遣してリアルタイムに品質を確認させることになる。システムレベルのテスト開発（負荷試験等）に関わるようになる。

QA・品質保証

品質保証部門として社内検査を行う出荷時の最終チェック的な役割

非機能試験は行わない、形式チェック

※上記の “プロジェクト外” とは、個々のプロジェクトに終始配属されるのではなく、専門の部隊として存在し、適宜プロジェクトをサポートするという意味。

図表 3-1 アジャイル型/ウォーターフォール型開発に必要とされる作業例（2/2）ウォーターフォール型開発とアジャイル開発の大きな相違点として、

①ファシリテーターが存在する。

②毎日コードをチェックインしている。

③品質検証、保証の機能は、プロジェクトの普段の活動に組み込まれていく。

という差分がある。②③は役割の違いによる差であり、スキルの差ではない。①に関しても役割の差とも言え、アジャイル開発に求められる新たな役割もあり、それ自体がスキルの相違と言える可能性がある。

（２）進め方（プロセス）によるスキルの違い

同様に、プロジェクトの進め方（プロセス）における作業例を提示し、両者の違いから非ウォーターフォール型開発に必要とされるスキルを検討する（図表 3-2）。

アジャイル型開発

ウォーターフォール型開発

仕様検討

大まかなやりたい事のヒアリング

仕様検討

契約の元となる確定条件の整理

イテレーション計画策定

やりたい事の優先度を決め、どれくらいの期間で、どの程度の機能（シナリオ）を作るかを決める

プロジェクト計画策定

ウォーターフォール型のストレートな計画策定基本、やりたい事は全部やる、全部設計してみる

反復

イテレーション（設計、開発、テスト）

小さな単位にしてドキュメント、コードをセットで作るテストコードも作る、毎日テストをする

基本設計

ドキュメントベースの設計

この時点で再度レビューをして再見積もりもあり

契約によっては、ここから先が別会社ということもあり

イテレーション（提供・デモ、評価）

２週間程度の周期で、動くコードを見せる実際に触ってもらう

その場でフィードバックをもらう

詳細設計、開発、テスト

ドキュメント、もしくはビルダーベースの設計開発

開発が終わってから、まとめてテスト

納品

ある程度の単位、決まった期日になったら、本番環境にデプロイする

品質監査、納品

プロジェクトとは別部門による品質監査、形式チェック

納品

図表 3-2 プロジェクトの進め方（プロセス）において必要とされる作業例上記により、ウォーターフォール型開発と違いアジャイル開発には、

①全部やろうとしない

②ドキュメントだけで設計はしない

③２週間程度で実際に動くものを見せる

④繰り返し型のプロセスがある

という違いがある。従来のウォーターフォール型開発に必要なものとは大きく異なっている。ただし、①②の違いはあるものの、技術、スキルの相違は生じないと考えられる。①はスコープ管理、契約処理に依存する。③④を実施するためには、個々のスキルの違いというよりも、IT スキルのみでなくドメイン領域の知識、幅広い言語知識等のように、知識、スキルの広さを求められる可能性は高い。

ウォーターフォール型開発においては、特に設計とコーディングを別のメンバが担当することがよくあり、場合によっては担当する企業、組織が違う場合もある。それに比べて、アジャイル開発では、繰り返し型のプロセスであるため設計、コーディング、テストコード作成を含むテストが、同じメンバで一貫して実施される。アジャイル開発のメンバは、設計、コーディング、テストを一貫して実施出来るスキルがあると言える。これは、大きな差分になり得る。

（３）ユーザ側に必要とされるスキル

プロダクトオーナー、ユーザと言われる側のスキルについても考察してみたい。ウォーターフォール型開発におけるユーザは、開発の方法について言及する必要はなく、実現するシステム、アプリケーションの業務仕様についての責任を負うことになる。ただし、仕様の決定が、開発工程の先頭にあり、かつ反復型のプロセスを採用していないため、仕様が間違った、決めきれなかった状態を作り出す恐れがあり、かつ、それはほとんどの開発プロジェクトで起きている。さらに、必要になる能力は、決めた機能、スケジュール通りにプロジェクトが進行しているか、進行していない場合、その原因は何か、その対応策は何か、対応策を取る際に発生する差分（追加投資、追加発注等）を管理する能力になる。アジャイル開発においては、明確な仕様を決めなくても良いとはいうものの、定期的なサイクルで実物を見てフィードバックのポイントを増やすことにより、実際のシステムを目で確認しながら、積み上げる様に仕様を決定していくことになる。ゆえに、全ての機能の仕様を洗い出す能力よりも、コアとなる機能を見定め、優先度を図りながら開発プロジ

ェクトの運営を指揮していく能力が問われることになる。

２．３本章のまとめ

これまで、役割と進め方（プロセス）という観点からの相違によって、アジャイル開発に必要なスキルの明確化に関し検討してきた。一般的に、従来のウォーターフォール型開発よりも高スキルが求められるという通説があるが、開発における難易度の高い作業が出来るスキルというよりも、以下の３点が、非ウォーターフォール型開発にとって重要なスキルと考えられる。

①プロジェクトのアウトプットに関わる判断ではなく、アジャイル開発の進め方を踏襲させるためのファシリテーションスキル

②反復活動の中で、実際に動くものを作りながら、小規模に、かつトータルにプロジェクトのアウトプットを積み重ねていくスキル

③設計、コーディング、テストを一貫して実施出来るスキル

その他のスキルについては、従来のウォーターフォール型開発でも求められるスキルであり、必ずしも非ウォーターフォール型開発だから必要とされるというものではない。

むしろ、プロジェクトの運営、採用、普段からの育成、契約といった他の影響により、本来、蓄積、発揮されるべきであるスキルが、十分に育成されていないという問題があるのではないだろうか。

追記事項：

アジャイルに必要なスキルとして、リファクタリングスキル、テスト駆動開発スキル等が挙げられるが、これらについては今後の課題としたい。

コラム

欧米のプロダクト開発における開発チーム・技術者のあり方（1/2）

プロダクト開発において、欧米ではかなりアジャイル開発が浸透しているようである。それを参考にする際、そもそもの開発チームのあり方、技術者のあり方が日本とは異なり、アジャイル開発スタイルに影響を及ぼしていることを留意しておく必要がある。下記に、筆者がこれまでいろいろな機会で得た欧米での開発チームのあり方、技術者のあり方について記述する。

【開発チームのあり方】

基本的には、開発者とテスタの２つの役割がある。開発者は、通常、要求仕様作成からユニットテスト/スモークテスト(いくつかの正常ケースのプログラムテスト)までを担当する。テスタは、テスト計画、テストプログラム作成、プログラム/システムテスト実行を担当する。

大切なのはその役割の中では、技術者は対等であるということである。一つの機能やユーザーストーリーの開発、テストを、一人で、または複数人で担う。日本でみられるように、リーダーが設計して、それに従ってメンバがプログラミング、テストを実施する、というような階層構造は通常存在しない。

また、マーケティングサイドにプロダクトマネージャが存在し、プロダクトのあり方、開発機能セットとその内容などの最終責任者となる。具体的には、プロダクトマネージャと開発チームでレビューを繰り返しながら開発機能セットとその内容を決めていくが、最終決定者はプロダクトマネージャ個人となる。その代わり、そのプロダクトの損益責任も負う。

コラム

欧米のプロダクト開発における開発チーム・技術者のあり方（2/2）

【技術者のあり方】

上記のように、開発者は、要求仕様作成からユニットテスト/スモークテストまでを担当することになるため、広範囲のスキルが求められる。開発者は、ユーザ要求を推測して外部仕様を作成し、定められたアーキテクチャに基づく設計を行い、コードを作成し、ユニットテスト、スモークテストを実施できなければならない。もちろん、経験や能力によってパフォーマンスに違いが出てくると思われるが、その一部のみ(例えばユーザ要求仕様から設計までのみ)を担うというあり方は、通常ない。

また、技術者は、基本的には社員(オフショア拠点の社員も含む)である。付加価値の小さなコンポーネントを外部にアウトソースする場合はあるが、プロダクトの基本部分は社員である技術者で開発する。技術者は、要求されるスキル定義に基づいて社内外から採用され、初心者を職場で育成するという文化はない。

日本では、プログラマから始めて設計者になり、プロジェクトマネージャを経て管理者になるのが成功パターンとみなされ、優秀な技術者であればあるほどプログラミングから早く遠ざかってしまう傾向がある。欧米では、ハイレベルのアーキテクチャ設計を担う立場になっても、その設計結果を設計文書よりもプログラムコードで表す技術者も多いと聞く。

【考察と提言】

まとめると、欧米ではプロダクトマネージャ、開発者、テスタなどの役割が明確であり、その役割の中では技術者はほぼ対等である。開発者は日本に比べると広範囲な開発フェーズを担い、日本のように優秀な技術者ほど早くプログラミングから遠ざかるというようなことはない。

アジャイル開発の具体論は、このような欧米の開発スタイルを暗黙的に前提としている面が多い。よって、日本でアジャイル開発を導入する際、プラクティスを機械的に導入してもうまく実行できないという危険性がある。単にプラクティスを導入するだけではなく、開発チームや技術者のあり方、文化のあり方をどう変えていく、または変えていかない、ということを考えながら、具体的なアジャイル・プラクティスの導入とその成功見通しを検討する必要がある。

本コラムの筆者は、本来のアジャイル開発の効果をだしていくためには、日本の開発スタイルを欧米スタイルに近づけることが必須と考えている。これは、日本の IT 企業の多重請負構造、日本の雇用のあり方などとも関連があり、一筋縄ではいかない。今後の検討会には、これを乗り越えていくためのxxと工夫の検討を期待したい。

（非ウォーターフォール開発 WG xx x x）

３人材育成方法の明確化 ‌

“スキル”は育成可能性があるからこそ議論できるはずである。素質や適性、と考えれば、育成が困難であるとして、育成を放棄することにつながりやすい。しかし、スキルが育成可能であるとして、講義形式の教育やカリキュラムの議論だけで十分とは誰も考えないであろう。非ウォーターフォール型開発に必要なスキルを身につけるためには、知識だけではなく、人材の育成が不可欠である。さらにいえば、システム開発を実施する人の人材像、そしてその人が持つべきスキルの体系について、個別に明らかにする必要があるだろう。

実際に非ウォーターフォール型開発でビジネス展開している企業の人材育成方法を事例として取り上げ、さまざまな観点から分析したい。その過程で、非ウォーターフォール型開発で不可欠な積極的に改善活動に関われる人材の意義について議論する。

３．１人材スキル・育成方法の基本的課題 ‌

これまで、アジャイル開発を実践する上での必要な開発技術・スキルについて検討してきた。では、そのスキルを習得するのにはどうしたらよいか、さらに、技術者を育成するためにはどうすればよいのか。そして、修得すれば誰でもアジャイル開発が実践出来るのだろうか。誰がどのようにアジャイル開発に必要なスキルを習得すれば良いのだろうか、について検討し、効果的な育成方法について考察を深めたい。

（１）育成方法の課題

まず、アジャイル開発を実践するためには、様々な方法論・数あるプラクティスから、プロジェクトや組織に適したものを取捨選択し、カスタマイズすることが必要である。例えば、現在の日本の商慣習では、一括請負契約がほとんどであり、この場合は IT ベンダへのリスクが大きい。ウォーターフォール型開発では、事前に全ての要件を洗い出し、確定させることで、なるべく要件変更を抑え、リスクを軽減させてきた。しかしながら、一括請負契約でアジャイル開発を実践した場合、要件が変更される度に、IT ベンダには負担がかかり、上手くマネジメントできなければ、たちまち赤字プロジェクトとなってしまう。さらに、イテレーション計画は当然のこと、顧客と頻繁にコミュニケーション出来るためのプラクティス、環境が非常に重要となってくる。また、不具合の瑕疵担保責任を全て開発側が負うため、テストやシステムの保守容易性に関するプラクティスを整備しておくべきである。

しかしながら、今までアジャイル開発を実践した経験がない開発チームや技術者にとってプラクティスのカスタマイズは容易ではない。何故ならば、あらゆるプラクティスは他のプラクティスと相互作用するからである[2]。アジャイルプロセスの価値・原則も理解しなければならない。アジャイル開発を初めて実施するチームであれば、まずは全てのプラクティスを適用し、模範に従ってxxに実践することが大事である。相互作用を十分に理解した上で、次に、プラクティスをカスタマイズし、自分のプロジェクトで上手くいくかどうかを検証する。そこまで実践できれば、他のカスタマイズが必要なプロジェクトでも、影響が予測でき、新しいプラクティスを創造して対処出来るようになる。まさしく武道に

おける守・破・離 2のプロセスが必要なのである。

どのようにして全てのプラクティスを適用して実践したらよいのだろうか。二つの方法が考えられる。効果的な方法の第一は、社外的に影響しない自社用のシステム開発プロジェクトにアジャイル開発を適用することである。企業によっては、新人研修のために利用される社内プロジェクトではあるが、現役エンジニア、マネージャ、顧客役を演じる人も参画することで、実際のプロジェクトを試みている企業もある。第二は、社内プロジェクトへの適用が困難な場合、アジャイル開発研修を行うことである。これは約１ヶ月から３ヶ月程度の仮想プロジェクトとしてアジャイル実践経験者を講師に迎えることで、効率良く習得出来る。

このような研修は、教育予算が確保できる大企業向けの方法と言える。では、教育に時間や費用が掛けられない中小企業ではどうしたらよいだろうか。時間や費用が多少でも掛けられるのであれば、２、３日の短期間の研修でも効果は得られるだろう。この場合、チームプラクティスをメインとした内容が望ましい。一人で出来るプラクティスは研修後、各自で習得することが出来る（図表 3-3）。

チームプラクティス	個人プラクティス
チームビルディング	テスト駆動開発
計画ゲーム	リファクタリング
ふりかえり	タスクかんばん
コードの共同所有	継続的インテグレーション
ペアプログラミング	最適なペース

図表 3-3 チームと個人のプラクティス

また近年はアジャイルプロセスに関連する勉強会やイベントが増加している。無料で参加でき、アジャイル実践経験者の生の声が聞ける場所でもあるため、積極的な参加が効果的である。

ある会社では、資金面から OJT として一人で出来るプラクティスを実際の業務に適用し、自信をつけてからリーダー役が可能なプロジェクトでエクストリーム・プログラミングを適用し、トップダウンアプローチで実践するようにしている。

2 剣道居合で修行する上での、心・技・気の進むべき各段階を示した３つの教えとされる。

「守」とは、師に教えられたことを正しく守りつつ修行し、それをしっかりと身につけることをいい、「破」とは、師に教えられしっかり身につけたことを自らの特性に合うように修行し、自らの境地を見つけることをいう。また、「離」とは、それらの段階を通過し、何物にもとらわれない境地をいう。

（２）学習カリキュラムの課題

では、何を学ぶことが効果的なのか。昨今、様々なアジャイルプロセス方法論が提唱されているが、アジャイルソフトウェア開発宣言とアジャイルソフトウェアの 12 の原則 3、そして、図表 3-4 に示すXPの価値とプラクティスを最も基本とすべきであろう[3]。

5 つの価値

コミュニケーション

シンプル

フィードバック

尊重

13 のプラクティス

全員同席

計画ゲーム

短期リリース

受入れテスト

シンプルデザイン

ペアプログラミング

テスト駆動開発

リファクタリング

継続的インテグレーション

コードの共同所有

コーディング規約

メタファ

最適なペース

図表 3-4 XP の価値とプラクティス

この XP の 5 つの価値は特に重要であり、これに理解があり、身に付いている技術者であれば、全てのプラクティスを理解し、既存のプラクティスで対応出来ない課題に対しても新しいプラクティスを創造して対処出来るであろう。しかし、この 5 つの価値を身に付けるのは必ずしも容易でない。これらの一部は、人間の生まれ持った性質に関わる部分であり、身に付けるというより備わっているかどうかが問題だからである。アジャイル開発において、コミュニケーション能力が必須であるとしばしば言われるが、それは事実なのだろうか。プログラミングが得意な人は、集中力はあるけれども、パソコンに没頭するあまり、人との関わりが苦手でコニュニケーション能力が不足するといわれる。アジャイルは人を大事にするという思想が根底にあり、個々人の特性を尊重するのがまさしくアジャ

3 「第一部２．２アジャイル開発の定義」参照。

イルなのである。したがって、コミュニケーションをサポートするコーチが必要である。 5 つの価値全てが身に付いている技術者がいれば理想だが、チームの中で能力が補え合えれば良い。ただし、役割によって必要な適性も異なる。チームリーダーはコミュニケーション能力やxxが備わっている必要があるし、技術への関心が乏しいプログラマは、動きさえすれば良いと考え、オブジェクト指向プログラミングを面倒に感じてしまかもしれ

ない。

コーチやスクラムマスターは外部から調達することも可能であるが、チームメンバこそ価値とプラクティスについて理解しなければならない。価値とプラクティスの関係、プラクティスの相互作用を理解していないまま中途半端に実践すると、途中で変化を吸収出来なくなり、失敗してしまう恐れがあるからだ。価値においては、１日で理解出来るようなことではなく、プロジェクトを通じて徐々に理解していく必要があるだろう。

役割と適性 4/スキルの有無、理解すべき項目について図表 3-5 に示す。

役割

適性/スキル

メンバー

チームリーダー

コーチ

スクラムマスター

コミュニケーション

○

★

シンプル

○

フィードバック

○

★

尊重

★

技術への関心

★

○

★

○

技術的プラクティス

○

－

★ ・・・適性としてプロジェクト開始時に備わっている必要がある

○ ・・・トレーニングにより理解する必要がある図表 3-5 役割と適性/スキルの対応

4 適性とは、価値を理解し実現するための適応力を指す。

「第xx ２．１アジャイル開発における“スキル”の基本的考察」参照。

（３）課題

アジャイル開発を学ぶことで、今まで正しいと教えてきた企業文化に対し、180 度異なる課題も出てくる。一例を以下に示す。

① 今まではいかに先を見越して設計し、要件を抽出出来るかが大事とされてきたが、アジャイル開発では、シシンプルであることに価値があり、将来必要になるかもしれないような機能を実装しようとしてはならない。

② 顧客が無駄に汎用的な要件をシステムに求めてきても、開発会社は、本当に必要なものは何かを顧客に問いかける必要がある。

③ 他の人の仕事を邪魔しないために、メールでのコミュニケーションを進めてきたが、Face to Face を重視し、できる限り顔を合わせてコミュニケーションを取ることが重要となる。

④ 異なる部門同士が同じフロアで仕事することで、ペアプログラミングでのコミュニケーションが活発になるが、うるさいとの苦情も多いので、チーム毎に会議室などの部屋を設置する等の対策を立てる。

⑤ 上下関係が重要視されている組織では、コミュニケーションに支障をきたすことがある。

また、人事評価基準についても、今までと同じやり方では上手くいかないケースが出てくる。チームと個人の組み合わせで評価出来ると良い。

① チームリーダーを最も評価するだけでなく、プログラマの評価を上げる

② 個人評価を強めると、競争原理が働いてしまい、オープンなコミュニケーションや他人の不具合の修正に消極的になる

③ 組織評価を強めると、80 対 20 の法則が働き、アジャイル開発で優れた人の負担が増える

そして、顧客がアジャイル開発に対し協力的かどうかは極めて重要になる。したがって、プロジェクトを始めるに当たって以下のことを理解する必要がある。

① 顧客の責務・役割

② アジャイル開発の価値・原則の理解

③ コミュニケーション手段・方法

④ Face to Face の価値

⑤ リリース計画、イテレーション計画

⑥ シンプルな要件定義

⑦ 優先順位の付け方

⑧ 受入れテスト

アジャイル開発では、プログラマが主体となる。今まで業務系 SE を主に務めてきた技術者にも、プログラマへの転換を促すことになるが、抵抗があれば、次のような別の役割として活動出来るようにする。

① スクラムマスター、トラッカー 5

② 顧客プロキシ（プログラマと顧客の架け橋的役割）

③ 業務コンサルタント

④ オブジェクト指向設計支援

⑤ テスタ（受入れテスト作成・実施）

以上の課題はあらゆる組織に存在するし、顧客の理解も困難な場合も多い。解決に至らなくても、これらの課題を理解しているかどうかで、状況は改善するはずである。

5 タスクやストーリーの進捗状況、ソフトウェアのバグ状況を定期的に収集する人。

３．２人材育成方法のあり方 ‌

アジャイル開発では、管理面での人材育成が重要であることが、あまり知られていない。アジャイル開発を担う人材は、常に「本質」を考え、今、どうすべきかを判断できる能力が不可欠である。そのために、常に「なぜ」を問い、「本質」を考える習慣を心がけることが重要である。このような人材の育成検討が、今、求められているのである。

（１）人材育成の狙い

従来のプロジェクトでは、経営環境や仕様変更などによってプロジェクトの状況は大きく変化し、そのためにマネージャやリーダーが週単位や日々の進捗管理に追われてしまっているのが現状である。そのため、本来の仕事である「新たな顧客価値創造」を行う余裕がなくなっている。この状況が慢性化すれば、マネージャやリーダー自身が「進捗管理」を自分の仕事と思い込み、真剣に「進捗管理」に取り組み、メンバは言われたことを行うだけの「指示待ち」状態になってしまうのである。

マネージャ、リーダー、メンバなど、プロジェクトに関わる人たちを、それぞれの管理役割のレベルアップし、全員が、顧客の新たな価値創造に向かえるように意識転換を図る必要がある（図表 3-6）。

役割	従来の役割分担	目標とする役割分担
お客様への価値提案	マネージャ	新たな
仕様検討/定義		価値創造
週単位の進捗管理
異常検知と対策	リーダー	自律的な
作業指示と日々の管理		進捗管理
作業	メンバ

図表 3-6 管理レベルを底上げし価値創造に向かう

そこにアジャイル開発の考え方が有用である。とりわけ、「見える化」は、「今」の状況をメンバが把握し、進捗状況に関する問題に対して素早く対策をうつこと、すなわち「自律的な進捗管理」の能力を高めることを支援する。自律的な進捗管理が定着することによって、自然に、プロジェクトに不足しているスキルが明確になり、技術教育を促進する動機となるだろう。

（２）人材育成の課題と活動方針

アジャイル開発の考え方を現場に理解/定着させ、管理レベルを底上げするためには様々な課題を解決する必要がある。

ソフトウェア開発の現場にアジャイル開発を定着させたいというニーズは多いが、実践が形骸化し成果につながらず失敗するケースが多い。主な原因として、現場の実践が「手法（プラクティス）」中心となってしまい、背景にある「本質」を理解できずやらされ感が生まれ、形骸化してしまう。アジャイル開発では、書籍や他の事例から得た知識を実践し、その実践から学んだ「実践知」を人に伝え続けることで「本質」への理解が深まる。アジャイル開発の指導者は、現場が形骸化せず実践知を大切にするよう指導し、成果に結びつける必要がある。ここでいう指導者とは、現場で指導の役割を担う人（例：スクラムマスター）や、現場を定期的に訪問する推進組織の担当者を指す。まず、アジャイル開発の「本質」について説明し、その後に指導者がアジャイル開発を指導する際の課題と解決策を以下に列挙する。

ⅰ）課題の解決方針

課題の解決方針を検討してみよう。アジャイルソフトウェア開発宣言（アジャイルマニフェスト）に掲げられた「価値」と「原則」が現場に伝えるべき「本質」であり、この本質を現場に伝えるための道具として「手法（プラクティス）」がある。指導ではそれぞれを次のように取り扱う。

また、「価値」は、アジャイル開発の中心となる考え方であり、変えない。「原則」は、価値に照らし合わせて現場で洗練する。「手法」は、原則に照らし合わせ現場の状況に合わせて常に変化させる。

価値

原則

手法

図表 3-7 価値、原則、手法の関係

ⅱ）課題とその解決策

図表 3-7 のような関係のもと、次の３つの課題とその解決策を提示する。

①形骸化させないため、現場の様々な状況（開発方法、チーム体制、問題点）などを考慮してアジャイル開発の指導を行う必要がある。そのためには、施策として、原則と照らし合わせて現状を把握し自責表現を通して現場に考えさせる。問題を他責と捉え

るのではなく、自責と捉えることで、効果的、かつ現実的な解決方法を導くことができる。

②指導のＰＤＣＡサイクル、すなわち今回の指導内容とその結果から次回に向けての指導内容を洗練していく必要がある。施策として、実践結果を原則に照らし合わせて原則を洗練する能力を向上させる。

③指導内容がどの程度相手に伝わっているかを効果的に評価する必要がある。しかし、ある状況で指導した内容は状況が変化すれば異なった形での相手の言動として返ってくるため、指導に失敗したのか、指導は成功したが状況が変わって言動が変化したのかがわからず、評価が不明確になってしまう。施策として、言動を常に価値観と比較して評価する、言い換えると、価値観と比較する能力を育成する。

ⅲ）施策

次のような３つの施策を提案する。第１に、本質と照らし合わせて現状を把握し自責表現を通して現場に考えさせる。

自責表現とは、例えば「チームメンバがなかなか発言してくれない」（他責表現）と嘆いているリーダーに対して、「あなた（リーダー）が普段からメンバの発言を妨げる言動をしてしまっているのではないですか？」（自責表現）という問いかけをし、新たな観点で考えてみるきっかけを与えることである。

手法は状況に応じて変化させるものであるが、書籍や事例の通りでは、現場で解決すべき課題の的を射ることができなかったり、チームが持つ課題解決能力を十分に活用できていなかったりすることが多い。

現場の状況に合わせ、現場が原則に沿って手法を常に変化させることができるよう指導を行う。通常は手法をそのまま使用した方が効率的と考えがちだが、アジャイル開発を現場で実践するにあたって大切なことは「手法を変化させる能力」であると考え、現場が常に手法を変化させることにチャレンジするよう指導する。具体的には、現場に考えるきっかけを与え、次の行動を見つけ出す手助けをする。現場が訓練を積み、未経験の状況に遭遇した時でもその場に合わせて的確に手法を選択したり、従来の手法を変化させたりすることができることを目指す。

指導内容としては、第１に、現場が意識していない観点からの質問を行うことで、現場が原則に立ち戻って考えるきっかけを作りだし、結果として原則に沿った次の手法の変化を生み出す。例えば、アジャイル開発でよく言われている「実装されていない設計書、テストされていないコードはムダである（在庫のムダ）」という指摘は、知識としては知っていても他人事で実感が湧いていないことが多い。現地で現物を指差して指摘することで問題が他責から自責に変わり、原則に立ち戻って考えることを始めるきっかけとなる。また、普段の会話の中からでも現場に考えるきっかけを与えることができる。

第２に、実践結果からのフィードバックを原則に反映させる。実践した手法の成功/失敗を分析し、価値に沿って原則を追加/修正する訓練を行わせる。通常は手法へフィードバックする方が効率的と考えがちだが、現場では常に状況が変化することから、常に瞬時に実践手法を導き出すことが求められる。そのため、現場にとって大切なことは、手法は今、その場でしか役立つものでしかないことを理解し、大切なのは「原則を洗練させる能力」であると捉え、結果を常に原則にフィードバックすることにある。原則が洗練すれば、状

況に応じて更に多くの手法を導き出すことができるようになる。

レゴでのものづくりを題材としたゲームのワークショップは大変盛り上がる。現場のリーダーやメンバは子供に戻ったように熱くなる。ゲームが終わり、ゲームが自分を熱くさせてくれた要因を抽出してもらうと、次のようなことが挙がる。隣のチームと競い合える、得点がリアルタイムにわかる、すぐ達成感が味わえる、チームで喜べる、途中の状況がすぐにわかるので何をすればいいかが判断できる、手や体を動かす、など。ここで指導者から「この感動を仕事に活かすにはどうするか」と問いかけると、とたんに、皆、暗い顔になる。

図表 3-8 レゴワーク実習事例

図表 3-8 に示すようなレゴブロックを使用したふりかえり体験ワークのようなゲームから気付いた要因をノウハウとして仕事に取り込むことができれば、仕事をゲームのように楽しむことができる。異分野から積極的にxxを取り込もうと意識することができれば、ゲーム以外からも多くのことを取り込むことができ、仕事のやり方を良くし続けることができる。例えば、自分と異なる職種（営業職、ＳＥ職、スタッフ職）、異なる業種（工場などの製造業）、他企業などからもノウハウを取り込むことができる。取り込むきっかけは「なぜ」と自問自答することである。なぜ楽しそうなのだろう、なぜ儲かっているのだろう、なぜあのようなことができるのだろう、と考える。積極的に取り込もうとする意欲を高めることで、仕事のやり方を変え続けることができる。異なる分野から学ぶものはないと思った瞬間に個人/チームの成長は止まる。広い意味でプログラミング作業は、このようなゲームのような楽しさを伴う仕事であることを気付く場となることが期待される(図表 3-9)。

図表 3-9 学ぼうとする意欲が大切

第３に、日々の言動が常に価値に沿っているかを比較して自己評価する。相手の言動を状況に応じて分析し、常に価値と比較することを訓練する。本質は抽象的概念であるため、価値や、それに従った原則を言葉だけで伝えても相手に本質が伝わらず、結果として相手の言動に表れない。指導する際に価値と原則に基づいた手法を選択し、手法を通して本質を伝える。本質が相手に伝わったかどうかは、相手の言動が本質につながっているかどうかで評価する。

訓練を積むと様々な場面での評価が可能となる。相手に伝えたことを相手がそのままの形で実践していなかったとしても、状況の変化と照らし合わせて言動を本質と比較し育成状況を評価することができる。例えば、上記で挙げた「在庫のムダ」以外のムダを現場が自発的に見つけ始めた時は、本質を現場が理解し、実践に反映し始めた時である。指導者はこのタイミングを逃さず、褒めるなどの意思表示をする必要がある。

アジャイル開発においては、管理面における人材育成が非常に重要である。プロジェクトが顧客への新たな価値創造に向け成功し始めると、不足がちなスキルが明らかにされ、技術を学ぶ動機につながる。

アジャイル開発を担う人材には、常に「本質」を考え、今どうすべきかを判断できる能力が重要である。そのためには、指導者は常に「なぜ」を問い、「本質」を考える習慣を心がけることが重要である。

３．３人材育成カリキュラムの実例 ‌

ここでは、あるプロジェクトでアジャイル開発を導入した際に開発したカリキュラム事例を紹介する。

（１）育成カリキュラムの概要

育成カリキュラムのステージを説明しよう。これからアジャイル開発を適用しようと思い立って、実際にプロジェクトに適用するまでの育成カリキュラムは、大きく 3 つのステージに分けて検討する。

① 導入前

② 立上時

③ OJT

アジャイル開発の導入時に、多くの場合、導入の責任を持った個人、もしくはチームが結成されることが多い。カリキュラムの作成は、このような先行的なチームと相談を行いながら進める。この時に、先行チームにアジャイル開発の概要的な研修を行うなどして、共通の用語で話せるようになっていることが必要である。

また、事前にプロジェクトに参画するメンバが決まっている場合は、その開発スキルをチェックし、必要であればプロジェクトの開始に先立ち、必要な開発スキルを身につけるための教育を実施する。

次のプロジェクト立上時に、アジャイル開発を行うために必要な基礎教育を重点的に行う。プロジェクトには、より多くの人が関わるので、会話をスムーズにするためにも用語を統一する必要がある。事前に、基礎教育を行うことが望ましいが、通常は他の業務を行っているので、立上時にまとめて実施するのが効率的である。

しかし、座学で学習するには限界があるので、基礎教育では詰め込みすぎずに、実践的な内容などについては、OJT を活かして地道に育成を行う。

さらに、OJT として、立上時の基礎教育では説明しきれない知識、技能や、実践知が伴わないと理解できないような内容について、プロジェクトを進めていく中で育成を行う。

図表 3-10 育成スケジュールの概要

上記の育成カリキュラムのスケジュールを図表 3-10 として図示する。プロジェクトの開始に先立ち、開発メンバ候補のスキル診断を行う、もし、開発スキルが低い場合は、必要なスキルを身につけるための育成を行う。プロジェクト立上時には、プロジェクトキックオフを行い、プロジェクトのゴールを関係者で共有する。また、２～３日間のルーキーズセミナーと称した、プロジェクト固有のルールや知識(開発標準や、業務知識)などを身につける教育を行う。

その後は、サブチームごとに模擬開発を行い、開発に必要な知識を身につける。この時に、作成した成果物は、プロジェクトに即したものではあるが、実際のプロジェクトには流用せずに、捨てることにする。開発環境などに慣れていない中で作成したものはどうしてもこなれておらず、その成果物をうまく活かそうとするとどうしてもその後の開発がしにくくなることが多いので、ここでは捨てることにしている。

そして、実際のプロジェクトを進めながら、その時の経験や、必要な知識を考慮して教育を OJT として実施する。

（２）育成の対象とカリキュラム

育成の対象は主に開発チームメンバではあるが、実際のプロジェクトを成功させるためには、その他のプロジェクト関係者も適切な知識を身につける必要がある。

図表 3-11 は、アジャイル開発を組織的に導入するにあたり、外部の育成機関の援助を受けて組織内の対象者別に育成を行った際のカリキュラムの例である。「＊」と記された領域については、カリキュラムの開発を個別に検討すべきである。例えば、業務知識を身につける責務は開発チームや先行チームであるが、どのような内容をカリキュラムとして用意するかは顧客やプロダクトオーナーの検討事項である。

	開発チーム	スクラムマスター	顧客／プロダクトオーナー	先行チーム	リーダー	PM	経営者層／購買担当など
アジャイル概要	○	○	○	○	○	○	○
アジャイル基礎知識	○	○	○	○	○	○
アジャイル擬似体験	○	○	○
業務知識	○		＊	○
開発環境	○			＊
基本アーキテクチャ	○			＊
業務分析／モデリング	△		△
開発技術	△			＊
ファシリテーション概要	○	○	○	○	○	○
ファシリテーション演習		○			○	○

○：立上げ前後の必須教育の領域

△：事前に準備が困難で OJT が必要な領域

＊：内容を組織内で個別に検討する必要がある領域

図表 3-11 対象別育成カリキュラム

名称

概要

アジャイル概要

アジャイル開発に携わる方向けの基礎知識

アジャイル基礎知識

一般的なプラクティスについての紹介

アジャイル擬似体験

アジャイル開発のプロセスを体験を通して理解する

チームビルディング的な狙いもある

業務知識

開発対象の業務を理解する(内容は先行チームと検討)

各カリキュラムの概要を図表 3-12 に示す。

名称	概要
アジャイル概要	アジャイル開発に携わる方向けの基礎知識
アジャイル基礎知識	一般的なプラクティスについての紹介
アジャイル擬似体験	アジャイル開発のプロセスを体験を通して理解するチームビルディング的な狙いもある
業務知識	開発対象の業務を理解する(内容は先行チームと検討)
基本アーキテクチャ	開発対象のシステム構成や、利用するフレームワークなどを理解する(内容は先行チームと検討)
業務分析／モデリング	業務を整理し、開発側に伝えるための手法を理解する
開発技術	開発に必要な技術を身につける（必要に応じて）
ファシリテーション概要	ファシリテーションに関する知識を理解する
ファシリテーション演習	ファシリテーションに関する知識を体験を通して理解する

基本アーキテクチャ

開発対象のシステム構成や、利用するフレームワークなどを理解する(内容は先行チームと検討)

業務分析／モデリング

業務を整理し、開発側に伝えるための手法を理解する

開発技術

開発に必要な技術を身につける（必要に応じて）

ファシリテーション概要

ファシリテーションに関する知識を理解する

ファシリテーション演習

ファシリテーションに関する知識を体験を通して理解する

図表 3-12 各カリキュラムの概要

（３）教育スケジュール例（3 カ月のパイロットプロジェクト）

アジャイル開発の効果を得るべく、パイロットプロジェクトを設定し、そこにアジャイル開発を導入した。図表 3-13 に初期教育スケジュールの例を示す。

1日目(火)	2日目(水)	3日目(木)	4日目(金)	5日目(月)
	朝会
	Java言語教育・Hello World ・コンパイルエラーの読み方・変数と型･演算子	Java言語教育・参照型変数・可視性(private、public) ・カプセル化	Java言語教育・クラススコープとインスタンススコープ・継承・抽象クラス・インタフェース	UML基礎教育・クラス図・オブジェクト図
キックオフミーティング
ふりかえり体験

昼休憩
タスク進行シミュレーション	Java言語教育・配列・制御構文(if、for、while)	Java言語教育・APIドキュメントの読み方・JavaDoc ・配列とArrayList	Java言語教育・アクセス制御詳細・パッケージ	ふりかえり
アジャイル開発の基礎知識				プランニング

	Java言語教育・クラス・コンストラクタ・メソッド	Java言語教育・HashMap ・TreeMap ・ポリモフィズム	Java言語教育・例外処理
開発環境設定				作戦会議
	夕会

8:45

9:00

9:30

10:00

10:30

11:00

11:30

12:00

12:30

13:00

13:30

14:00

14:30

15:00

15:30

16:00

16:30

17:00

17:30

18:00

図表 3-13 初期教育スケジュールの例

開発メンバは、新人研修以来、ほとんど Java による開発経験がなかったため、スキルの高い育成担当をプロジェクトの支援メンバに任命した。その中で、3 日間の研修期間を設けて研修を進めていったが、3 日間では開発に十分なレベルには達しなかったため、さらに 4 日間の Java 言語研修を追加した。図表 3-14 に、OJT のスケジュールの例を示す。

場面	期間	育成テーマ	コンテンツ／指導ポイント
初期教育	1～2週目	開発の基礎知識を身に付ける	アジャイル開発の基礎
			Java言語の基礎
			UMLの基礎
			開発環境の使い方

週のふりかえり	毎週月曜日	チームの改善	付箋を使ったふりかえりの進め方
			Tryの実施と、その効果の確認
			Problemを挙げて失敗に気づかせる
月のふりかえり	毎最終月曜日	アジャイルなチーム	アジャイル度評価

スプリント#1	3～4週目	ストーリを実装する	計画ゲームの進行
			顧客要求の管理
			・ストーリによる管理
			・相対規模見積もり／ストーリポイント
			・見積もりポーカー
			作業の計画と管理
			・タスクボード
			・週のリズム設計／時間割
			バーンダウンチャート
			アプリケーションフレームワークの使い方
			・ドメインのインスタンスの生成
			・テストデータの投入方法
スプリント#2	5～6週目	チーム運営をチームに任せる	リファクタリング
			・Viewを中心に実施
			デザインパターン
			・Factory Methodパターン
			タスク管理について
			・日を跨ぐタスクの扱い方
			コーディング標準
			・クラスやメソッドの命名規則
スプリント#3	7～8週目	保守しやすいプログラム	マルチスキルについて
			ファシリテーションについて
			デザインパターン
			・Null Objectパターン
			オブジェクト指向の設計原則
			・単一責任の原則
			プロダクトバックログ
			追加の要求の受け方
			Subversionの使い方
			・コンフリクトの解消の仕方

スプリント#4	9～10週目	設計力向上	オブジェクト指向の設計原則
			・開放閉鎖の原則
			・依存関係逆転の原則
			リファクタリング
			・不吉な匂い
			Eclipse
			・リファクタリング機能
チャレンジスプリント	11週目	特に設定しない

クロージング	12週目	育成効果のふりかえり	学んだスキルのたな卸し

状況に応じて	実施時期未定	アジャイル開発の特徴(スクラム、XP以外)
		・リーンソフトウェア開発
		・FDD
		オブジェクト指向の設計原則(紹介していないもの)
		デザインパターン(紹介していないもの)
		GRASPパターン
		ソフトウェア品質の保守性の考え方

図表 3-14 OJT スケジュールの例

スプリントごとにテーマを設定し、それに沿う内容を育成担当から適宜指導を行った。前半では、アジャイル開発のリズムを作るためのスキルの向上に時間を割いている。

（４）育成カリキュラムの例（50 名規模のアジャイル開発）

約 50 名が開発メンバとして参加するようなやや大規模のプロジェクトにおいて、アジャイル開発を行う際のカリキュラムを検討してみよう。このプロジェクトでは、プロジェクト運営にスクラムをベースとした手法を用いている。図表 3-15 に開発メンバの役割とその概要例を示す。

役割	説明
プロジェクトマネージャ	複数チームを束ねる。
スクラムマスター	アジャイルでの開発が滞りなく進むように必要な準備や調整を行う。中立かつ第３者的に開発側/ストーリーオーナー側を調整する。開発チーム毎に専属のスクラムマスターがいるのが望ましい。
テクニカルコーチ	技術的な支援を行う。例えば、開発手法や、ツールの指導を行う。１つのチームに属するのではなく、複数のチームを担当する。
アジャイルコーチ	技術的な支援を行う。例えば、アジャイル・プラクティスの導入・指導を行う。スクラムマスターに対して指導を行う。１つのチームに属するのではなく、複数のチームを担当する。
プロダクトオーナー	プロダクトバックログの管理について責任を持つ。原則、１人である。
ストーリーオーナー	ビジネス側の要求をストーリーとして、開発側(主にアプリケーション開発チーム)に伝える。開発側の成果物を確認する。
ビジネスアーキテクト	対象とするビジネスの全体像を把握し、必要なレベルに抽象化する。ドメイン開発チームのストーリーオーナー的な位置付けである。
開発チーム代表	開発チームの代表となって、他チームと連携する。他のチームと仕様の調整などを行うので、それにふさわしい技術レベルを持つ。プロパーだから、代表になるということは考えない。パートナーでも、代表になる。チーム内で役割を持ち回りしても良い。リーダーではないので、決定権を持って、チームを牽引する役割ではない。
開発メンバ	主体的に開発を行う。ストーリーオーナーと仕様を確認し、それに適合した開発を行う。

図表 3-15 役割の一覧例

各サブチームには「リーダー」ではなく、「開発チーム代表」を設けている。リーダーがいると、リーダーが様々な決定を行ってしまい、メンバが思考停止になり、その結果、メンバのスキル向上が阻害される危険性が高い。それを防ぐために、このような役割を設定した。

このようなプロジェクトにおける人材育成のために、プロジェクトでの進め方を見据え

必要な役割やスキルを洗い出す。図表 3-16 にその例を示す。

役割

�

ェ

プステアプロククジロジラニダムカイク

スビ x x トジ発発ネチメ

ー

ーー

リスン

ー

クマルルトアムバ

ー

ーーー

トスコマタ

コオオ

代

(

キ x x

ー

ネチチナナテ欄開発メンバ

�

)

ク	参	F/Wチーム	■	■	■	■	■	■
ト	照	ドメインチーム			■	■
		アプリチーム	■	■	■
		QAチーム	■	■	■	■	■	■

ジ

◎ ◎ ◎ ◎ ◎ ○ ○ ◎

◎ ◎ ◎ ◎ ◎ ◎ ○ ◎

プロジェクト運営

ー

運ムチスクラム一般

UI層

◎

AP層

◎

SV層

◎

DM層

○

PS層

△

運用基盤層

△

○ ◎ ◎ ◎ ◎ ◎ ○ ◎ 営

スクラム PJ 固有 ◎ ◎ ◎ ○ △ △

△ －－－ ○ ◎ ○ ○

△ －－－ ○ ○ ◎ ◎

－－ ○ ◎ △ ○ ◎ ○

識業実務

務ドメインモデル

術

知モデリング

◎ ◎ ○ ○ △ ？

△ ○ ◎ ◎ △ ？

－ ○ ◎ ◎ ○ ？

－－ ◎ ◎ －－－ ○

－－ ◎ ◎ －－ ◎ ○

－－ ◎ ◎ －－－ ○

－－ ◎ △ －－－ ○

－－ ◎ △ － ○ － ○

－－ ◎ △ － △ － ○

－－ ◎ △ － ○ － ○

－－ ◎ △ －－－ ○

－－ ◎ ◎ －－－ ○

－－ ◎ △ －－－ ○

Java ◎ ◎ ◎ ◎ ◎ ？技 OOプログラミング ○ ◎ ◎ ◎ ◎ ？ OO設計 ○ ○ ◎ ◎ ◎ ？

UML ○ ◎ ◎ ◎ ◎ ？

リファクタリング ○ ◎ ◎ ◎ ◎ ？ TDD ○ ◎ ◎ ◎ ◎ ？単体・結合テスト ○ ◎ ◎ ◎ ◎ ？システムテスト ◎ ◎ ◎ ◎ ◎ ？ HTML/CSS ◎ ○ －－－？ JavaScript ◎ －－－－？ WebUIテスト ◎ ○ －－－？ SQL － ○ ○ ○ ◎ ？ DB物理設計－－－－ ◎ ？ DBチューニング－－－－ ◎ ？

開 Eclipse ◎

発 Subversion ◎

環 Trac ◎

境 Hudson △ ◎ ◎ ◎ ◎ ？フレームワーク ◎

ステージング環境 ◎

図表 3-16 役割とスキルの対応例

アジャイル開発ではクロスファンクショナルにチームを分けるのが基本である。しかし、チーム数が増えると、基盤に近い部分の整合性を取るのがオーバーヘッドとなってくる。そこで、事前にどのようにサブチームを分けるかを検討し、それに必要なスキルと役割を決める。図表 3-16 では、チームをフレームワーク（F/W）開発チーム、ドメイン開発チー

ム、アプリケーション開発チーム、品質保証（QA）チームの 4 つのタイプに分けている。この中で、アプリチームは複数のチームに分かれ、他のチームは１つである。

４まとめ ‌

非ウォーターフォ－ル型開発手法は、単に開発手法の問題だけではない。本報告書では、その取組みは、日本における IT 化への取組みが先進諸外国のみならず韓国はじめ新興の IT 先進国に対してのキャッチアップのために不可欠であり、さらに日本における IT 産業の後進性を克服するための重要な施策につながるものであると考えている。

しかしながら、その認識は、政策当局はおろか IT 産業、広く IT を道具として活用してきた多くの企業においてさえ決して高くない。したがって、本報告書では、昨年度に取りまとめたシステム開発の現状とあり方から進んで、実際にどう取り組むか、とりわけ企業やＩＴベンダの経営者にとっての価値に始まり、具体的に技術者をどのように育成するのかについて、基本構想からカリキュラムの考察までxxな検討を行ってきた。今後の更なる議論の発展と取組みが期待される。

Document Metadata

Table of Contents

非ウォーターフォール型開発 WG

Document Metadata

非ウォーターフォール型開発 WG

平成 23 年 3 月 31 日

平成 24 年 3 月 26 日 改訂

独立行政法人 情報処理推進機構

ソフトウェア・エンジニアリング・センター

目次

第一部 非ウォーターフォール型開発検討におけるアジャイル開発の位置づけ

第二部 アジャイル開発のモデル

ウ ォ ー タ ー フ ォ ー ル 型 ア ジ ャ イ ル 型

モデル名

調査事例

第xx 非ウォーターフォール型開発における技術及びスキル

Document Metadata

平成 24 年 3 月 26 日改訂

独立行政法人情報処理推進機構

第一部非ウォーターフォール型開発検討におけるアジャイル開発の位置づけ

第二部アジャイル開発のモデル

ウォーターフォール型アジャイル型