ユーザは、ベンダに「やりたい事」を伝える。
ベンダは、ユーザに「やれる／やれない」を回答する。
さて、ユーザは期待している内容を得ているのか？
ほとんどは想定できる内容（過去のドキュメントの使いまわし？）を、
専門用語で難解にし、体裁をキレイに整えたレポートなのでは・・・・
ユーザが求めているのは、
理解不能な専門用語で構成された「やれない」理由や言い訳
根拠のない「やれる」アピールではなく・・・
単純明快な「やれない」理由
あるいは、根拠のある「やれる」説明
それと、、、
「あえてやる」や「あえてやらない」の提案を期待していると思う。
プロジェクトで管理すべきは、この６つ。
・工程管理
・進捗管理
・品質管理
・課題管理
・変更管理
・リスク管理
管理する目的は、円滑なプロジェクトの進行と最終的な品質の担保である。
それぞれの管理方法は、プロジェクト計画書に方針および概要が記されるが
プロジェクト毎に管理方法が違うということもないので、会社としてのガイドラインを定め準拠するのが一般的と思う。
フロント要件が進化して複雑化している。
インターネット初期（ホームページ時代）は、HTMLとデザインといったシンプルな要件だった。
web2.0なんて呼んだ時期には、CSSやSEO、CMSといったシステム的要素が加わってきた。
今やスマホ・タブレット対応も含め軽量化や高速化の要件もフロント要件に加わってきている。
その要件にあわせてレスポンシブデザインやJavaScript、APIといった知識もフロント要件に必要になってきている。
これって、システム要件となにが違うの？ な状態である。
ちょっと前ならHTMLを知っていれば多少は通用していたが、今ではシステムエンジニア的な要素が必要になってきている。
それを、フロントエンジニアと呼んでいるようだ。
いまや システムエンジニア ≒ フロントエンジニア である。
案件によっては、システムエンジニア（＝SE）の仕事ではなく、フロントエンジニアの仕事がほとんど、、というのが現実になりつつある。
システム開発の開発手法には、大きく３つの手法がある。
・ウォーターフォール型
・プロトタイピング型
・アジャイル型
また、それぞれを組み合わせたハイブリッド型も最近のトレンドである。
全ての基本（基礎）は、ウォーターフォール型開発である。
ウォーターフォール型開発が理解できてこそ、プロトタイピング手法であり、アジャイル手法である。
未熟な（悪質な？）開発ベンダは、ウォーターフォールの簡易版（プロセスを省略したり、成果物を省略する＝つまりは手抜きである）をアジャイル手法と呼称する傾向にある。
いわゆる、安かろう悪かろうの炎上プロジェクトの典型である。
※何かを省略するのがアジャイル開発ではない。
■ウォーターフォール型開発
ウォーターフォール＝滝のように、上流から下流へプロセスが連なる開発手法である。
具体的には、企画→要件定義→設計→開発→テスト→受け入れといったシステム開発のV字モデルに準拠する。
■プロトタイピング型開発
ウォーターフォール型開発の発展系であるが、上流工程（要件定義～設計）の段階でプロトタイプ（＝モック）を作成し、UI/UXを優先に設計を進める手法である。
■アジャイル型開発
アジャイル型とイテレーション型と大別される。
どちらも反復開発なのだが、目的が異なる。
・アジャイル＝結果・成果重視
・イテレーション＝プロセス重視
プロセス重視のイテレーションは、超短期型ウォーターフォールとも言える。
ウォーターフォールは、プロジェクト全体を半年や１年２年といった比較的長期で考える。
アジャイルやイテレーションは、プロジェクトを細分化し１ピースを１週間や１ヶ月といった短期間のサイクルで考え、反復する事を前提としている。
有名なキャッチフレーズ「うまい、やすい、はやい」は
創業当時は「うまい、はやい」だった
1970年頃に「はやい、うまい、やすい」になった
1980年頃に「うまい、はやい、やすい」に変わった
2000年頃に「うまい、やすい、はやい」となり現在に至る
と、変わったそうだ。
話はそれたが、プロマネ＝プロジェクトマネジメントとは
「うまい、やすい、はやい」が極意なんだと思う。
つまり、QCD（Quality,Cost,Delivery）だ。
・うまい：Quality＝品質が担保されていること
・やすい：Cost＝適正価格であること
・はやい：Delivery＝納期を守って納品すること
「うまい、やすい、はやい」の３つが成り立って満足度が満たされる（マネジメントが成功する）のであって、どれか１つでも欠けてしまっては成功とは言えない。
美味しくなかったり、値段が高かったり、いろいろと遅かったりしてはダメってこと。
つまり、品質を保って、見積り金額から上ぶれせず、納期通りにリリースする事である。
予定通りに、苦労もなく、何事もなかったように平然とリリースする事が成功なハズなのだが、、、
得てしてユーザは、困難を何とか乗り越えたり、一緒に徹夜したり、納期が守れないので追加で１００人投入します！を即決で決めたり、その費用を３０％減額したり、といった事を成功（定性評価＞定量評価）と勘違いする傾向にある。
すくなくとも、とにかくリリースすることを目的に、当初期待された品質とは程遠い代物を、ジャブジャブと要員（＝金）をつぎ込んで、やっとの思いでリリースしたプロジェクトを成功とは呼ばない。
プロジェクト体制は、大きくはユーザ側体制とベンダ側体制になる。
基本体制は、ユーザ側もベンダ側もPM・PL・担当・メンバの構成となる。
その上位にシステムオーナとステコミ（ステアリング・コミッティー）が存在する。（明確ではない場合もあるが、相当する役割は必ずあるハズ）
ステコミは、開発規模が大きい時に必要な組織で「運営委員会」を示す。
目的は、ほぼPMOと同じだが、より上流思考（経営、マーケティングなど）の判断となる。
システム開発の体制は、既に PM・PL・SE・PG が画一化されている。
※そうでない場合は、革新的か原始的かのどちらかだろう。
フロント体制は、比較的トレンドがあり、最近は細分化される傾向にある。
兼務することも多く、プロデューサ兼ディレクタ兼デザイナも珍しくない。
最近はフロント要件とシステム要件の境界が曖昧になり、フロントエンジニアがシステム要件を担うシーンが多くなっている。
UI/UXを重視する場合は、アートディレクタを別途たてる場合もある。
都市伝説かもしれないが、フロント体制はいろいろな意味で比較的「ゆるい」感じは否めない。
デミングプラスとは、社名の由来とは・・・
『デミング』は、PDCAサイクルの発端になった、W・エドワーズ・デミング博士のデミングサイクルからの由来になる。
・デミングサイクルは、設計→製造→販売→調査・サービス
・PDCAサイクルは、Plan-Do-Check-Action
共通点は、ゴールに向かう無限ループ。
失敗を恐れず、常に成長し続ける姿勢。
つまり、それがデミングプラス。
PMOとは、Project Management Office（プロジェクトマネジメントオフィス）
Officeって事は、支援者ではなく、支援を行う部門,構造,仕組みである。
一般的なPMOの役割とは・・・
・マネジメントの標準化
・マネジメント業務の支援
・プロジェクト間の各種調整
・プロジェクト環境の整備
・その他付随する管理業務
さて、PMOに期待することは（３分類）・・・
（A）コンサルティング
・スケジュール策定、WBSの作成
・プロジェクトマネジメント分析、レポーティング
・各工程の準備およびクロージング支援
・横断的調整、課題解決促進、コミュニケーション支援
・リスク検知、事前予防策の策定・実施
・各種リカバリー対応支援
（B）プロジェクト管理支援
・進捗管理、課題管理、リスク管理、変更管理
・各種ルール・プロセスの整理・策定・実施
・品質管理・評価
・会議体のファシリテーション
（C）プロジェクト事務支援
・管理資料の更新（進捗、課題、スケジュールなど）
・成果物管理
・メンバ管理、環境管理
・会議体設定、議事録作成
・煩雑な業務の支援、メンバの負荷低減
つまり、一概にPMOといっても
・事務支援（＝作業要員）
・マネジメント支援（＝PM補佐）
・コンサルティング（＝業務改善）
レベルは様々だ。
要件とは、ユーザが本来やりとげたい目的（ゴール）であり
仕様とは、それを実現するための仕組み（プロセス）である。
システム開発のプロジェクトを進めていくと
ある時期、要件と仕様が混乱する時期がある。
それは、システム要件定義ー＞基本設計ー＞詳細設計の時期である。
ユーザ主導から開発ベンダ主導に移る工程において
ユーザがみずからの要件に自信が持てなくなってくる。
つまり、開発ベンダが言っていることが正しく思えてきて
結果的に、仕様＞要件（要件が仕様にのみ込まれる）となってしまう事がある。
あたりまえだが、ユーザはゴールの妄想はできるが
ゴールまでのプロセスを詳細に想定はできない。
それはベンダに相談せざるを得ないが
ベンダはユーザの気持ちになって回答したりしない。
ベンダはベンダの気持ちでユーザの相談に答える。
とにかく、ユーザにとって 仕様＞要件 というのは本末転倒である。
あくまでも 要件＞仕様 で、あるべき。
どんなに優秀なベンダであっても、ユーザ要件を実現する為の仕様であり
ベンダの仕様（ベンダがやりたいこと、やれること）にユーザ要件が左右されるべきではない。
※ASPやパッケージ製品などはこの限りではないが・・・
システム開発のV字モデルとは、
ウォーターフォール型開発手法をモデル化したもので
・上流工程（設計・開発）とテスト工程の関係性
・ユーザ主幹のプロセスと開発ベンダ主幹のプロセス
が理解できる。
V字モデルでは、各工程での納品物定義も表されており
・システム要件定義工程では、受け入れテスト計画および仕様書
・基本設計工程では、システムテスト計画および仕様書
・詳細設計工程では、結合テスト計画および仕様書
が、必要（＝準備できる）と理解できる。
V字モデルを意識してプロジェクトマネジメントを実践することによって
目先の工程管理ばかりにとらわれず
後工程も含めたマネジメントを計画・実行できる。
