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
<出典> 「米国連邦政府の情報システム・ソフトウェア品質に関する取り組み」 JETRO/IPA New York，2012年5月．
参考
SEC
Software Engineering for Mo･No･Zu･Ku･Riソフトウェア開発のイニシエーション(2/2)
•反復型開発方法では、特に固定された契約（fixed contract）ベースのプロジェクトを実 施する場合、イニシエーション時に困難が発生することが多い。
•プロジェクト開始前には、フィージビリティ（実現可能性）調査が行われることが多いが、
その性質は概ね非形式的である。
•特にプロジェクト領域の策定に関して、プロジェクト計画プロセスにおける文書化の実施 状況はまちまちである。
•反復型開発方法では、プロジェクトの進行に応じてソフトウェアアーキテクチャを自然的 に発展させる方式よりも、プロジェクト開始前にソフトウェアアーキテクチャを決定する方 式が好まれる。
•リスクマネジメントの必要性は広く認識されているものの、実施状況は未完全である場 合が多い。
以上から、ソフトウェア開発のプロジェクトマネジメント方法は、ベンダ及びプロジェクトの性 質によって差異があるように見受けられる。しかし、ソフトウェア開発プロジェクトの成功を保 証するためには、プロジェクトのイニシエーション段階が重要である以上、その改善の必要 性は世界的に認識されている共通課題であり、今後イニシエーション方法の体系化に向け
、更なる研究開発が行われることが期待される。
参考
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最適にリスクを取るマネジメントの考え方
SamsungのKee Sup Kim氏による「Best-in-Class Mobile SoC」と題する講演より：
消費電力・性能と生産性のトレードオフは，設計マージンによって決まる。ここで，設計 マージンとは，プロセス・バラつき，温度，電圧変動，HCI（hot carrier injection），TDDB
（time dependent dielectric breakdown），NBTI（negative bias temperature
instability）などの信頼性に関連した各種の指標を指す。
プロセスのトレンドを考えれば，信頼性は高まる傾向にあるものの，すべての設計マージ ンを満たすことはビジネス的にはありえず，どこかでリスクを取らざるを得ない。それには，
製造サイドと設計者の協力が不可欠である。両者のコミュニケーションを円滑にすること で，37.5%の消費電力削減と17.8%のチップ面積削減が可能になった例があるという。
出典：【DAC 2011】「設計者のやる気を引き出せるマネジメント」，経営層／管理職向けの講演に涙する
（日経ＢＰ社
ＥＤＡ Ｏｎｌｉｎｅ，2011/06/10）（変化の激しい）ビジネス・ニーズに応えるためにリスクを取る
↓
どこで（誰が）リスクを取るか？
↓
顧客経営層-システム部門間，顧客-ベンダ間の緊密な協力，
円滑なコミュニケーションのもとで，最適な分担でリスクを取る
参考
SEC
Software Engineering for Mo･No･Zu･Ku･Ri明確な「行動規準」に基づく判断による行動
引用：武田斉紀「3.11もブレなかった東京ディズニーランドの優先順位」
TDRはキャストが自ら判断し、行動できる前提を用意している。「会社とし
て大切にするべきことと優先順位」＝行動規準を明確に示し、十分な研 修を実施して、一人ひとりが判断し行動することを推進している。参考
震度5強の揺れは、．．．7万人の来園者（同社ではゲストと呼ぶ）たちは、前代未聞の体 験に当然パニック状態になる。しかし揺れから40秒後には、地震発生を伝える園内アナ ウンスが流れた。．．．そしてキャストたちはパニックを起こさなかった。彼らは持ち場のゲ ストに対して、すぐさま冷静かつはっきりとした声で、分かりやすい指示を出した。
「（店舗で販売用に置いていたぬいぐるみの）ダッフィーを持ち出して、お客様に“これで頭 を守ってください”と言ってお渡ししました」。彼女は会社から、お客様の安全確保のため には、園内の使えるものは何でも使ってよいと聞いていた。そこで、ぬいぐるみを防災ずき ん代わりにしようと考えたという。
同じくキャストのIさんは、店舗で販売していたクッキーやチョコレートを無料で配り始めた。
幹部は開園以来28年間守ってきた“禁”を破る決断をした。バックヤードという従業員だ けが利用する通路にゲストを通して、より短距離で安全にシーに誘導することにしたのだ。SEC
Software Engineering for Mo･No･Zu･Ku･Riソフトウェアエンジニアリング上の主な課題（1/3）
①機能視点で開発を順次進めるため、システムのアーキテクチャ の確立に不安がある。
アジャイル型開発では、アーキテクチャは「創発」すると捉えられており、こ れは、ウォーターフォール型開発においてアーキテクチャに大きな事前コスト をかけすぎたことの反省から来ている。しかし、イテレーション毎の局所視 点とリファクタリングによる創発性のみにアーキテクチャを任せることができ るか、また、「十分な」アーキテクチャとは何か、という議論は今後必要であ ろう。
②機能間に依存性が強い場合、イテレーションに入力する機能 の順序に制約ができるケースがある。
アジャイル型開発では、依存性をなるべくなくし、細分化して機能分割す ることが求められる。また、その場合でも、リファクタリングの負荷が大きく なる場合がある。