ＰＭＢＯＫのお勉強 その２５ － ５．１

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回は４．５章、今回から５章で、５．１章です

---

■５．１　要求事項収集

＜＜インプット＞＞
・プロジェクト憲章
　　４．１より

・ステークホルダー登録簿
　　１０．１より


＜＜ツールと技法＞＞
・インタビュー

・フォーカス・グループ

・ファシリテーション型ワークショップ

・グループ発想技法
　　次のようなものがある
　　　　ブレーンストーミング
　　　　ノミナル・グループ技法
　　　　デルファイ法
　　　　アイデアマップ法やマインドマップ法
　　　　親和図

・グループ意思決定技法
　　意思決定に至る方法
　　　　満場一致
　　　　過半数
　　　　相対多数
　　　　独裁

・アンケートと調査

・観察

・プロトタイプ


＜＜アウトプット＞＞

・要求事項文書

・要求事項マネジメント計画書

・要求事項トレーサビリティー・マトリックス

初めてのＲｕｂｙを読む その２４ ５．１

「初めてのRuby」を読むの続き

今日から５章。

５章　入出力
５．１　プログラムへの引数
から

---

■５章　入出力
・今までも p , print , puts　は利用

・Rubyにおける入出力において最も重要なものはIOクラス
　　→システムコールレベルやＣ言語のファイル記述子をラップ
　　　ファイルのように扱えるものへのインターフェース提供
　　　　　ソケット、パイプ、端末など・・

---

■５．１　プログラムへの引数

・起動する際に、外部から引数を渡すことが出来る
　　→組み込み定数　ARGV　を使って引数にアクセス
　　　→ARGVは引数文字列の配列
　　　→実行したソースファイル名、Ｒｕｂｙ処理系の引数は入らない

---

スティーブ・ジョブズ氏 死去（追加：１０時）

えー（＠＿＠！）
って、確かにこの前でてきた写真では、危なそうな感じだったもんなあ～

ひとつの時代が、終わってしまうんですかねえ・・・


前アップルＣＥＯ、スティーブ・ジョブズ氏死去
http://headlines.yahoo.co.jp/hl?a=20111006-00000509-san-bus_all


（追加）このサイトは、必見！
http://www.apple.com/stevejobs/

10月5日(水)のつぶやき

09:40 from goo
新iPhone(4S)、英語の音声認識対応！では、日本人が英語をしゃべったら？ #goo_xmldtp http://t.co/dKAiQYiT
by xmldtp on Twitter

「アジャイル開発を適切に採り入れるためのポイント・・・」に行ってきた！ その３

前に書いた、

IPAのセミナー
アジャイル開発を適切に採り入れるためのポイントとアジャイル開発の事例【1】
に行ってきた！メモした内容を、書いてみる。

これで最後！、一番初めの
「IPA「非ウォーターフォール方開発WG活動報告書」のポイント」

---

★IPA「非ウォーターフォール方開発WG活動報告書」のポイント

■話の趣旨（内容）
・顧客・経営層の理解促進
・アジャイル開発に必要なスキル
・アジャイル開発の契約モデル
・最近の話

■報告書
・公開中
　H21年度版　http://sec.ipa.go.jp/reports/20100330a.html

　H22年度版　http://sec.ipa.go.jp/reports/20110407.html

■ソフトウエア開発の課題
大きく３つの問題
・ビジネスニーズへの適切な対応
　　→早期サービス提供と効果確認
　　　ニーズ変化への俊敏な対応
　　→予測可能な環境変化量
　　　変化対応のシステム開発期間
　　　　　　↓
　　　　変化が進みすぎ

・ウォーターフォール（計画駆動型）の問題
　　　要件が事前にすべては決まらない
　　　要件の誤りが最後のテストまで発見されにくい
　　　時間がかかりすぎて変化への対応が遅れる

・ソフトウエア産業構造（多重下請け構造）上の課題
　　　→モチベーション向上


■アジャイルへの期待
・要求が刻々と変わる
　　→要求を固定化するリスク

　＜＜従来＞＞
　　要求が固定されない
　　　→リスク：システム開発スケジュールの遅延

　　要求を固定化
　　　→リスク：外部ビジネス環境の変化に対応できない

・技術リスク
　　→作ってみないとわからない

■アジャイル型開発の特徴
５つくらいの特徴
・顧客の参加の度合いが強い
・動くソフトウエアを成長させながら作る
・反復・漸進型
・人と人のコミュニケーション、コラボレーション重視
・開発前の要求の固定化をしない

■アジャイル宣言
・プロセスやツールよりも個人との対話
・包括的なドキュメントよりも動くソフトウエアを
・契約交渉よりも顧客との強調を
・計画に従うことよりも、変化への対応を

　　　　↓

１２の原則
・こまかいので省略

■アジャイル開発のモデル
・原則として事前に詳細な計画を作らず
・１から４週間という短い周期で要求開発テストを繰り返しながら
・動作可能なソフトをつくる

・ISO－SC7で、アジャイル開発の分析をしている
　　→ISO/IEC12207の裏づけのなかで、ガイダンスに従って
　　　やったほうがいいといっているが・・・
　　　　・・・ガイダンスが現時点で存在しない

・小規模企業向けのソフトウエアライフサイクル
　　VSEsの中でアジャイル開発の適用

・ISO/IEC 26515アジャイル開発のドキュメント

■プロセスとプラクティス

・従来
　　プロセス（→アクティビティ→タスク）
　　　　→（What）何をするかをあらわす

・アジャイル
　　プラクティス
　　　　→(How to)どのようにするかをあらわす

■実績
・日本ではアジャイルが少ない
・アメリカ多い

＜＜理由＞＞
・日本とアメリカの調達モデルの違い
　　日本：SIerが入る　アメリカ：直接発注

・行われた事例分析
　　チーム人数１０人以下
　　　→アメリカは１７人
　　イテレーション１～２週、ながくて４週
　　プラクティスはさまざま

■アジャイル型開発への課題
　・開発モデル
　・顧客経営層への理解
　・スキル・人材
　・契約


■開発モデルについて

モデル１：一般的アジャイル
企画→（要求・開発・テスト）→（要求・開発・テスト）・・・


モデル２：はじめに共通部開発
企画→基盤共通部開発→（要求・開発・テスト）→（要求・開発・テスト）・・・


モデル３：リリース時、リリース前テストする
企画→（要求・開発・テスト）→（要求・開発・テスト）→リリース前テスト・・・


■顧客・経営層への理解

・アジャイル開発の導入理由（アメリカ）
　　Time to marketの加速
　　変化する優先順位管理
　→すべての開発にアジャイル型開発という立場ではない
　　向いている領域
　　　１．ビジネス要求が変化する領域
　　　２．リスクの高い領域
　　　３．市場競争領域

　　ちょっと課題ありそうな分野
　　　１．大規模開発
　　　２．分散拠点（オフショア含む）開発
　　　３．組織（会社）間をまたぐ開発チームによる開発
　　　４．組み込みシステム開発

・顧客、経営層は開発への一層の関与が必要

　ユーザー経営層
　　開発携帯にも深く関与する必要
　　　　アジャイルやクラウドの利用

　ベンダ経営者
　　アジャイルの体制作り必要　

・顧客経営層はチームの一員として参画
　　→プロダクト品質の見える化

　円滑なコミュニケーション

■技術・スキルに関する検討

・アジャイルとウォーターフォールの違い
　　　→ファシリテーターの存在
　　　　２週間程度で実際に動くものを見せる
　　　　１人で設計、製造、テスト
　　　　　　→全メンバにマルチのスキル

　コアとなる機能を見極める

・このような人材を育てるには？
　　ある程度、一通りのプラクティスを理解するのが必要
　　価値・原則の理解

　→自社用のシステム開発に導入
　　チームプラクティス

　まとめると
　　　アジャイル開発の価値・原則の理解
　　　すべてを完全に身に着けるより、
　　　　　　価値に従って行動する習慣を
　　　人材の見極めと適切な配置が必要

・PMIが新しいアジャイル認証（PMI－ACP)を
　開始（２００１１年３四半期：ただしアメリカで）

・CMMIバージョン１．３でも
・PMBOKではアジャイルコミニュティー
・BABOKはアジャイル拡張版

■契約

・現在：請負と準委託
　　　　→派遣契約にしてしまえば問題ないんだけど・・・

・インセンティブ契約：おもしろいが、ちょっと・・・
　開発費不要の受託契約：おもしろいけど・・・

・そもそも契約は・・・
　　合意内容を固定し、法的に拘束
　　アジャイル：当事者を拘束しない
　　　　→相容れない

・請負と準委任
　　請負：契約時点で完成すべき仕事の内容を明確にする必要
　　準委任：完成するかユーザーは不安

・提案する契約１：基本／個別契約モデル
　　・全体を基本契約で結ぶ
　　・単位ごと（１リリース）に個別契約
　　　　　個別契約の決定事項は別紙に集約
　　　　　変更協議

・提案する契約２：組合モデル
　　→ユーザーとベンダーのジョイントベンチャー
　　　　　：民法６６７条　組合契約
　　→実際の開発は、基本／個別モデル

・IPAで公開しているよ！
　　http://sec.ipa.go.jp/reports/20110407.htmlのダウンロード
　　→経産省の「モデル取引契約書」に提案

■アジャイル開発手法の導入に向けて

・開発対象の性質　X　開発組織の環境条件
　　で利用するかどうかきめる

・テーラリングの適用

・アジャイル開発のスイートスポット
　　システム　　１２人・・・など

・アジャイル開発の障壁
　　組織文化への変化能力
　　変化への一般的な抵抗
　　アジャイル経験者不足

・失敗理由
　　企業哲学・文化との愛称
　　手法への不慣れ

・アジャイルむけのソフトウエアアーキテクチャ
　　　ビジネスアーキテクチャ
　　　　ビジネスプロセス＋ビジネスルール

　　　　　　　↓写像できる

　　　ITシステムアーキテクチャ：
　　　　ビジネスプロセス：固定的、汎用的：変更不要：エンジン
　　　　ビジネスルール：流動的：変更対象：パラメータ

BABOKの概要と最新動向
ビジネスアナリシス最前線
～北米のビジネスアナリシスを取り巻く最新技術動向解説～
http://sec.ipa.go.jp/seminar/2011/20110712.htmlより