デザインパターン再復習の３ー振る舞いに関するパターン

Iterator （１つ１つ数え上げる）

Template Method （具体的な処理をサブクラスにまかせる） 要注意：テンプレートですから、基本記述は全部I/Fです。

Strategy （アルゴリズムをごっそり切り替える）

Visitor （構造を渡り歩きながら仕事をする）

Chain of Responsibility （責任のたらい回し）

Mediator （相手は相談役１人だけ）

Observer （状態の変化を通知する）

Memento （状態を保存する）

State （状態をクラスとして表現する） 要注意：状態に対する各種処理はこのクラスにまとめる。

Command （命令をクラスにする）

Interpreter （文法規則をクラスで表現する）

デザインパターン再復習の２ー構造に関するパターン

Adapter （皮かぶせて再利用）　

Bridge （機能の階層と実装の階層を分ける）

Composite （容器と中身の同一視）

Decorator （飾り枠と中身の同一視）

Facade （シンプルな窓口）

Flyweight （同じものを共有して無駄をなくす） 要注意：Factoryにより同じものをSingletonで作る。

Proxy （必要になってから作る）

デザインパターン再復習の１ー生成に関するパターン

Abstract Factory （関連する部品を組み合わせて製品を作る）

Builder （複雑なインスタンスを組み立てる） 要注意：条件により必要なinstanceを作ること。

Factory Method （インスタンス作成をサブクラスにまかせる）

Prototype （コピーしてインスタンスを作る） 要注意：reflectionのような考えでもOKだと思いまっす。create instance by classname.

Singleton （たった１つのインスタンス）

◆プロジェクトマネジメントの要点―IBMの教育資料

プロジェクトマネジメントではこんな言葉で表現されています
①スコープ定義
②変更マネジメント
③リスク識別・リスク対応計画
④ステークホルダー・マネジメント（明示的／潜在的）
⑤資源見積り（前提事項、スコープの把握、お客様の期待値等の制約の考慮）
⑥契約管理（契約書・提案事項のPMとしての十分な理解）
⑦チーム育成

個人的な考えとしては、スコープ定義後、資源の見積もりを行うはず。
まずはスコープをきちんと把握しないといけないです。
それから顧客との関係はどうやってうまく管理できるのか、重要です。

プロジェクト管理―スコープ定義

スコープ定義の成果物はWBS（Work Breakdown Structure）の作成.

WBSは次の3つの観点から分解する。
①　コスト/時間/リソースを見積もれること。

②　進捗度のベースライン（初期計画に承認済の変更を加えた基準値を時系列表示）を定義できること。

③　作業の責任/権限を明確化できること。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
スコープ定義が不十分だと、調子をくずし、遅延/生産性低下/士気低下/を起こし、最終プロジェクトコストの増大を招くことになる。

個人的な経験には、大規模案件ならば、いくつのサブシステムがあるはず、各サブシステムを各PLに任せて、インタフェースを把握すればOKだと思います。各チーム内ではまたそれぞれ細かくWBSを作成すること。
細かく程度については、各タスクの責任者がどう動くか良く分かる程度であればOKだと思います。

◆プロジェクト失敗の10の理由

①　コミュニケーション不足（特にメンバー間）

②　変更管理が行われない

③　メンバーの能力不足

④　プロジェクトマネージャーの人材不足、意識と能力不足

⑤　メンバーの意識が低い（チーム感覚がない）

⑥　受注時の見積もり精度が低い

⑦　管理する余裕がない

⑧　管理基準とその評価基準がない

⑨　無理な納期（モラル低下）

⑩　問題発生の対応がうまく取れない

プロジェクト管理―概要の２

プロジェクト管理各プロセスの一言
①統合管理
　プロジェクトの多種多様な要素を、整合が取れた形で実行するのに必要なプロセス。

②スコープ管理
　プロジェクトが成功裡に完了するのに必要とする、すべての作業･物理的要素を過不足なく包含するように管理していくのに必要なプロセス。

③タイム管理
　プロジェクトが所定の期日迄に完成するように計画･管理するプロセス。

④コスト管理
　プロジェクトが所定の予算内で完成するように計画･管理するプロセス。

⑤品質管理
　プロジェクトが生成された基本的ニーズを確実に充足するためのプロセス。

⑥組織管理
　プロジェクトに参加する人材（ヒューマンリソース）が最も有効に活用されるような組織を作り、これを維持するプロセス。

⑦コミュニケーション管理
　プロジェクトの諸情報をタイムリーな生成、収集、配布、保管そして廃棄に必要なプロセス。

⑧リスク管理
　プロジェクトに内在するリスクを特定し、定量化し、その対応策を案画するプロセス。

⑨調達管理
　プロジェクトの遂行主体の外部から製品又は役務を調達するためのプロセス。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
PMBOKにおけるプロジェクトマネジメントのプロセスは以下の5つのグループに大別されている。
①　立ち上げのプロセス
　　プロジェクト開始に当たっては、プロジェクトあるいはフェーズ着手の必要性を認識して、プロジェクトをコミットする。

②　計画のプロセス
　　ビジネス上の要求を完遂するために、作業可能な計画を立案（プロジェクト計画書）し、それを維持する。

③　遂行のプロセス
　　計画で定義した作業を、プロジェクト組織内に割り当て実行する。

④　コントロールのプロセス
　　プロジェクトの目的（定量化された目標値）の達成を保証するために、プロジェクト進捗を監視・策定し、必要に応じて改善策を実施する。

⑤　終結のプロセス
　　プロジェクトやフェーズの検収を完了し、プロジェクトを終結にたどり着かせる。

この5つのプロセスグループは計画からコントロールの間は繰り返して動いている形に成っている。
監視、策定の結果により、改善必須であれば、改善策を出して、改善を行う。

プロジェクト管理―概要

PMBOKによりプロジェクト管理の基本知識体系を以下に示す。
①統合管理
　・プロジェクト計画の策定
　・プロジェクト計画の実施
　・変更管理

②スコープ管理（開発範囲）
　・プロジェクトの立ち上げ
　・スコープの計画
　・スコープの定義
　・プロジェクト成果物の検証
　・スコープ変更管理

③タイム管理
　・作業定義
　・作業順序設定
　・作業所要時間の見積もり
　・スケジュール作成
　・スケジュール管理

④コスト管理（予算、実績）
　・資源計画
　・コスト積算
　・予算設定
　・コスト管理

⑤品質管理
　・品質計画
　・品質保証
　・品質管理

⑥組織管理（人、リソース）
　・プロジェクト組織計画
　・要員の調達
　・チーム育成

⑦コミュニケーション管理
　・コミュニケーション計画
　・情報の配布
　・進捗報告
　・プロジェクト完了手続き

⑧リスク管理
　・リスクの特定
　・リスクの定量化
　・対応策の策定
　・リスク管理

⑨調達管理（契約）
　・調達計画
　・引き合い計画
　・引き合い
　・発注先選定
　・契約管理
　・契約完了
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
各項目の内容：
プロセス⇒基礎（入力）情報⇒ツールと技法⇒成果物
つまり、各プロセスに対してそれぞれINPUT、OUTPUTがあります。
INPUTは基礎（入力）情報、OUTPUTは成果物。
INPUTよりOUTPUTを作成するのは、ツールと技法によりである。

【勉強の気持ち】いつまで経っても勉強し続く

どんなに不景気でも毎日の勉強は止まらず、興味を持って勉強するのは興味のためですから。

【設計方法】経験の一言：インタフェース指向設計

機能＝インタフェース＋インタフェースマネージャー。

インタフェース＝入力＋出力。
インタフェースマネージャー＝インタフェース間のつながり管理。

設計に対して、インタフェースとインタフェース間の関係をよく理解できたら、設計の成功になるはずです。
　　　

【プロジェクト管理】経験者の一言

今週月曜日のチーム内会議上にチーム責任者が良い一言を言われました。
途中代わりのPMには
①状況を理解してから、すぐ対策を出せるべきです。
②客要求不明、スケジュールどんどん後ろに伸ばしいく、こういう状況であれば、どうする。
答えは
A、仕様の責任者を決めなければならないです。一番仕様を理解している方がいなければプロジェクトが進めないです。
B、仕様理解できても、技術の確保ができなければ、検証しなければ、成功するわけがないです。
③PMの自信がなければ、成功するわけがないです。無理やりすると、失敗のリスクが非常に高いです。