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

今、

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

のお勉強をしています。

前回２．２をやったので、今回２．３をやります。

---

■２．３　ステークホルダー
・ステークホルダーとは、
　プロジェクトに積極的に関与しているか、または
　プロジェクトの実行あるいは完了によって、
　　　　自らの利益がプラスまたはマイナスの影響を受ける
　顧客、スポンサー、母体組織、一般大衆のような個人や組織である。

・プロジェクトマネジメントチームは、
　すべての関係者のプロジェクトへの要求事項と期待を明確にするため、
　組織の内外のステークホルダーを特定しなければならない

・プロジェクトマネージャーは、プロジェクトを確実に成功させるために、
　プロジェクトの要求事項に関する、様々なステークホルダーへの影響を
　マネジメントする必要がある。

・ステークホルダーは多様なレベルの責任と権限を持って
　　　プロジェクトに関わるが、
　この関わり方は、プロジェクトのライフサイクルが進むにつれて変化する。

・ステークホルダーの特定は、困難なこともある

・ステークホルダーを特定し、プロジェクトに対する度合いを理解することは、
　　　非常に重要である。
　この理解を誤ると、スケジュールの大幅な遅れや
　　　コストの大幅な増加をもたらすこともある

・ステークホルダーによってはプロジェクトがもたらす結果が
　　プラスであると考えるものも、
　　マイナスであると考えるものもいる
　　　　→不利益を見込むステークホルダーを見逃すと
　　　　　失敗の可能性が高まる

・プロジェクトのステークホルダーの例
　　・顧客やユーザー
　　・スポンサー
　　・ポートフォリオマネージャーや
　　　ポートフォリオ・レビュー委員会
　　・プログラムマネージャー
　　・プロジェクトマネジメントオフィス
　　・プロジェクトマネージャー
　　・プロジェクトチーム
　　・機能部門マネージャー
　　・事業マネジメント
　　・納入者やビジネスパートナー

---

次は、２．４

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

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

３章　数値
３．２　数値演算
から

---

■３．２　数値演算
・加減乗除、譲与、べき乗、符号操作などをサポート

---

■３．２．１　除算
・演算対象の値によって挙動が異なる
　　・両辺がIntegerオブジェクトだと、整除
　　・一方がＦｌｏａｔであれば、実数除算
　　・整除の場合０で割ると例外、実数除算だと、無限大などが返る

---

■３．２．２　符号操作
・単項マイナス演算子は、数値の符号を反転　
・単項プラス演算子は、なにもしない

---

■３．２．４　その他
・利用頻度の高い演算は専用の演算子
・そうでないものはメソッドの形で利用

---

■３．２．５　型と自動変換

・データ型が自動変換されることはほとんどない
　　・整数と浮動小数点の演算は例外的に自動変換
・明示的に型を変換する場合、to_i()、to_fメソッド等を使う

---

■その他の数値、第数系
・Ｒｕｂｙで標準添付されているもの
　　　　有理数（Rational)
　　　　複素数（Complex）
　　　　可変長１０進（BigDecimal)
　　　　行列（Ｍａｔｒｉｘ）、ベクトル（Ｖｅｃｔｏｒ）

---

次は３．３

オークションサイトを２日で作るための開発方法論-その２

そうそう、「オークションサイトを２日で作るための開発方法論」続きを書いていなかった。

　昔は、ソフトウエア開発は、数ヶ月、下手したら１年以上かけるのが普通にあった。
　でも、現在は２～３ヶ月かけるのでも、結構長いのかな？
　場合によっては、数時間っていうのもある。

　こういうふうになった背景には、４つあると思う。

---

■１．基本的に、同じような開発法、利用法の場合、一部だけを取り替えればよい
　　という開発法が増えた。

　まるで、パッケージソフト・・・じゃないけど、
　マッシュアップみたいなものや、基本的に動きが決まっているものについては、
　もう、使い方も運用方法も決まっているわけで、そうすると、差分だけ作ればいい
　ということになる。


■２．論理的に考えてつくるというよりかは、サービスを選んで取り入れるという
　　　カフェテリア方式とでも言うべき開発法が入ってきた

　　JQueryなんかがそう


■３．そもそも、要求仕様→設計→実装→テストという流れをとらなくてよくなった。

　　カフェテリア方式なら、あらかじめ、ロジック部分をあ～でもない、こうでもない
といっぱい作っておいて、要望が固まったら、必要なものをとってくればよい。

　この方法が進むと、将来的には、要求仕様の段階で、ビジネスロジックをいろいろ
作り上げてしまい、外部設計のときに、ビジネスロジックを取捨選択してしまうかも
しれない。


■４．テストの終わりの考え方

　利用効果に応じてテストするという考えになってきた。なんでもテストするよりかは・・・

　被災地への情報提供サイトなら、テストに時間をかけて、みんなが利用できないよりかは、テストを最小限にして、バグがあるかもしれないけれど、情報提供したほうがいい。

---

　これらは結局、いままでの開発方法論とは違った、あらたな開発方法論の必要性を暗示している。その開発方法論については、また今度・・・