Improvement (Product, Process, People)
日本に設立すること 13 IT産業に技術と知識を流通させる、アジャイル型開発のコーチを育成・増加する環境
16
ガイドラインやTips集を作成し、世間に広く 伝えること3
アジャイル型開発を実践し、顧客のビジネスの成功率が高 いことを実感し、定着・伝播する環境12
技術や経験が組織や人に蓄積される仕組み17
アジャイル型開発を調達する際の要件として、開発チームに有資格者をふくめること
13 IT産業に技術と知識を流通させる、アジャイル型開発の
コーチを育成・増加する環境海外普及要因調査
SEC
Software Engineering for Mo･No･Zu･Ku･Riソフトウェア開発のイニシエーション(1/2)
近年では、IT技術の発展に伴いソフトウェアも複雑化しており、特に膨大な人件 費が発生する大規模なソフトウェアの開発プロジェクトでは、プロジェクトの成功 率が低いことが問題視されている。例えば、Standish Group社が2011年に発行 したレポート「CHAOS Report 2011」によると、2008年以降に開始された約
5,000件のプロジェクトのうち、3割程度が失敗に終わっていたという。
とは言え、現在プロジェクトマネジメント方法についての普遍的な標準規格は存 在しておらず、開発者は通常、これまでの経験や慣例によるベストプラクティスに 基づいてプロジェクトを準備（イニシエーション）することがほとんどのようである
[1]
。例として、英国Queens大学Belfast校のGreer教授、ノルウェー・Norwegian工科 大学のConradi教授が、ノルウェーのソフトウェア開発企業14社によるソフトウェ アプロジェクトのイニシエーション及び計画について調査し、2009年に発表した 論文によると、以下のような所見が得られたという
[2]
。[1] http://books.google.com/books?id=BPD5Czu-HH8C&lpg=PP1&pg=PA50#v=onepage&q&f=false [2] http://www.idi.ntnu.no/grupper/su/publ/reidar/iet-sw-greer-preproj-14apr09.pdf
参考
SEC
Software Engineering for Mo･No･Zu･Ku･Riソフトウェア開発のイニシエーション(2/2)
•反復型開発方法では、特に固定された契約（fixed contract）ベースのプロジェクトを実 施する場合、イニシエーション時に困難が発生することが多い。
•プロジェクト開始前には、フィージビリティ（実現可能性）調査が行われることが多いが、
その性質は概ね非形式的である。
•特にプロジェクト領域の策定に関して、プロジェクト計画プロセスにおける文書化の実施 状況はまちまちである。
•反復型開発方法では、プロジェクトの進行に応じてソフトウェアアーキテクチャを自然的 に発展させる方式よりも、プロジェクト開始前にソフトウェアアーキテクチャを決定する方 式が好まれる。
•リスクマネジメントの必要性は広く認識されているものの、実施状況は未完全である場 合が多い。
以上から、ソフトウェア開発のプロジェクトマネジメント方法は、ベンダ及びプロジェクトの性 質によって差異があるように見受けられる。しかし、ソフトウェア開発プロジェクトの成功を保 証するためには、プロジェクトのイニシエーション段階が重要である以上、その改善の必要 性は世界的に認識されている共通課題であり、今後イニシエーション方法の体系化に向け
、更なる研究開発が行われることが期待される。
<出典> 「米国連邦政府の情報システム・ソフトウェア品質に関する取り組み」 JETRO/IPA New York，2012年5月．
参考
SEC
Software Engineering for Mo･No･Zu･Ku･Ri システム規模 ・ 0．．１２．．３００ （開発メンバー数）
深刻度 ・ シンプル、経済被害、．．．人身事故
システムの成熟度 ・ 新規開発、レガシー保守
要件の変化率 ・ 低、中、高
ビジネスモデル ・ 自社開発、オープンソース、．．．
アーキテクチャ ・ 安定、変化した、新しい
チームの分散 ・ 一か所、．．、オフショア、外部委託
統制 ・ 単純なルール、．．．、SOX、．．．
フィリップ・クルーシュテン （Philippe Kruchten） の講演(2009.12)より
参考
アジャイル型開発のスイートスポット（例）
SEC
Software Engineering for Mo･No･Zu･Ku･Riアジャイル型開発のスイートスポット（２）
通常は，JavaまたはC#の環境で，組込みではなくウェブアプリケーショ ンを，最終的なエンドユーザや実際の顧客とかなり近い環境で開発する ところ．
チームの大きさはふつう，かなり小さく，すべてで12人にも満たない．し かし，大きなチームでの経験も蓄積され続けている．チームの中には他 の場所にいるメンバもいるかもしれないが，チームの中核はエンドユー ザのかなり近くで仕事をする．
まだ開発が始まっていないプロジェクトよりも，既存のシステムの方が簡 単にアジャイル型開発を適用できる．重要なのは，新しいプロジェクトで も既存のシステムでもアジャイル型で開発するための十分な経験が蓄 積されているということ．
アジャイル型開発のスイートスポットには好循環が存在し，多くの経験 が多くの成功をもたらし，その成功がまた経験を得る機会を生み出す．出典 「アジャイルの限界」(作者:Alan Kelly, 翻訳者:徳武 聡, 投稿日;2010年8月17日)
http://www.infoq.com/jp/articles/limits-of-agile
参考
SEC
Software Engineering for Mo･No･Zu･Ku･Ri組合せモデルの例
仕様や設計の （場合によっては大幅な） 変更が当然あるものという前 提で、最初から厳密な仕様を抽出しようとせず、大まかな仕様だけで細 かいイテレーション （反復） 開発を始め、すぐに実装・テストを行って仕様 や設計の妥当性を検証するというアプローチを採る
要件定義 コア開発 システム
運用
テスト
開発
要求
第一反復 第二反復 第三反復 第四反復 イテレーション
テスト
開発
要求 テスト
開発
要求 テスト
開発
要求
IPAグローバルシンポジウム2010
児島プレス 兼子邦彦氏講演より“AHAA-Agile, Hybrid Assessment Method for Automotive,
Safety Critical SMEs （Small-to-medium sized enterprises）”,ICSE’08
アイルランドやフィンランドにおける中小ソフトウェア企業 （SMEｓ） が、車 載ソフト開発を開発するとき、旧来の計画駆動型 （plan-driven
software development） とアジャイル型開発手法とを組み合せた手法を
用いている（この論文は、そのプロセス評価の方法について述べたもの）SEC
Software Engineering for Mo･No･Zu･Ku･Riソフトウェアエンジニアリング上の主な課題（1/3）
①機能視点で開発を順次進めるため、システムのアーキテクチャ の確立に不安がある。
アジャイル型開発では、アーキテクチャは「創発」すると捉えられており、こ れは、ウォーターフォール型開発においてアーキテクチャに大きな事前コスト をかけすぎたことの反省から来ている。しかし、イテレーション毎の局所視 点とリファクタリングによる創発性のみにアーキテクチャを任せることができ るか、また、「十分な」アーキテクチャとは何か、という議論は今後必要であ ろう。
②機能間に依存性が強い場合、イテレーションに入力する機能 の順序に制約ができるケースがある。
アジャイル型開発では、依存性をなるべくなくし、細分化して機能分割す ることが求められる。また、その場合でも、リファクタリングの負荷が大きく なる場合がある。