どんな仕事でもそうだけど、事前に見積をするのは極めて難しいこともある。プロジェクトXで取り上げられたものには事前計画もへったくれもないのが少なくなかったように思う。
横山真一郎。中谷多哉子。ソフトウェア開発計画と見積もり。ソフトウェアの規模の拡張。技術の発展。保守面などで様々な問題。固定業務対応。柔軟性に欠ける。未だに標準化が遅れていて拡張が難しく。製造技術の向上。プロジェクトと考えて管理的問題として解決。システム的アプローチは日本人にとり苦手？ソフトウェア工学。プロジェクトを成功に導くプロジェクトマネジメント。ソフトウェアのライフサイクル。プロジェクトの立ち上げ時に。
プロジェクトという用語の定義。独自の製品やサービスを生み出す有機性のある。成果物。始まりと終わり。独自性。プロジェクトは一般的に。不可能に挑戦する？前代未聞の計画。ピラミッドの建設。61年からのアポロ計画。特徴。成果物。最終結果。人類初の月面着陸。国家の威信を回復するという目的と目標。始まりと終わり。開始宣言。月面着陸。独自性はハッキリしている。プロジェクトの4つの要素。
ソフトウェア開発計画はライフサイクルの最初のフェーズ。立ち上げプロセス。プロジェクト憲章を作る。プロジェクトチームを作る。ステークホルダーを決める。日本企業は契約に対する対応を苦手に。思いの外時間がかかる、曖昧な点が理由。日本人は阿吽の呼吸や忖度。微妙な約束。明確なマニュアルが無くても進むから？
プロジェクト憲章について。重い感じのする言葉。それだけ重要。プロジェクトの所有者の許可証。プロジェクトマネジャーに資源を使用する権限が。目的は開始の宣言。運用する上で必要な基本事項。要素となる基本事項の考え方。作成の基本資料。ビジネスケース。作業範囲記述書。作業工程や作業内容や分担権限。中長期計画などにおける。dataに基づいて。事前に充分に検討されていれば難しくはない。検討されていないことが多い。発注者の思いがまとめきれていないことが。目的と目標。予算の概要。主要なリスク。取り巻く環境。ステークホルダーとプロジェクトチーム。実現可能性。スケジュール内容。成果物実現方法。スコープの概要。およそのスケジュールを。プロジェクトスコープ。範囲。目標や全体を規定。立ち上げフェーズで決める。具体的でない可能性がある？期待のようなもので良い？明示されているのは重要。実行しつつある作業の変更を要する場合の判断の基準になる。不具合や矛盾。プロジェクト憲章に立ち戻る。立ち上げフェーズでは他に？検討する際にmemberの検討。依頼されるソフトウェアの要望。計画に沿って進める。目標の次。作業全体のスコープを確定。コストや人的資源、リスクなどを検討。プロジェクトマネジメント計画書。作業計画においては憲章、プロセス。ニーズを抽出。要望に対して要件などが使われる。開発者の側からの言葉としての要件。要求定義。発注者の予見をステークホルダー毎に。プロジェクト憲章の関係としてのスコープ。計画段階ではスコープ定義。構成要素に分解。プロジェクト憲章には目的目標制約条件前提条件が明文化。要求文書。あらゆる要求事項が。スコープの検証を。顧客満足度。スケジュール、コスト。計画をどれだけ練り上げるか。制約条件が何であるのか、成功かどうかの判断基準は？スコープ定義が重要。プロジェクト要素や成果物。作業内容を分かりやすく。構成要素を細かく分類。作業分割。カレーライスを作る。カレーのルーだけでは無理。お米や具、何人分を？時間や予算は？それぞれについて細かく検討。どのようなプロジェクトも作業内容を大きな作業から小さな作業へ分割して。最初に分かるなら明確に。作業の分割手法。作業分割図。WBS。プロジェクトの成果物をブレークダウン。ワークパッケージ。プロジェクトを進めるために落とし込む。具体的作業内容。WBS。コストや所要時間の見積もり。
後はそれぞれの作業の時間やコストの予想を。計画段階での見積もり。WBSで洗い出された作業。要員やコストを検討。計画フェーズの段階。要望が曖昧だったり不確定な様子だったり。アクティビティを見積もるのは難しい？概算の見積もりで。プロジェクトは計画重視？計画は変更できない？間違っている。独自性はあるので予定通りに進むのは稀。約束に間に合うように出かけたのに遅れそうになったり。交通の復旧状況が分からないが外出計画を。段階的に詳細化を。デッドラインを。マネジメント。制約条件である人的資源やコストなど様々な事態を織り込む。品質管理。検査や消費者危険を少なく。品質計画は重要な役割。品質という側面。プロジェクトについては品質管理のプロセス。品質計画。要求事項を定めて方法を文書化して。品質計画からチェックリストなどを。第三者的観点から。品質管理のプロセス。手直しや予防は適宜。品質内容はステークホルダーが何を期待するか、スコープは何か。物のInternet。networkを通じてnetにつながる。便利になった反面、要求が多様化。品質への対応に不備があった場合に社会への影響が大きく。利害対立を考える必要。様々な立場の人が関わる。ステークホルダー。計画する上で。品質機能展開。設計の意図を。品質の大切さや作り込み。予算との兼ね合い。人的資源計画。進めるのは人。memberのスキル。役割と責任を明文化。個人の役割。意思決定。承認の権利を誰が持つか。コンピテンシー。プロジェクトの組織図。上下関係。WBSを関連付けた。ワークパッケージの担当者。階層上に。要員マネジメント計画。要求事項を満たす。役割と責任を明文化。マトリックス型の。RAM。memberの役割を4つに。作業を担当する実行責任。作業全般に責任。アドバイスを提供。情報を共有する情報提供。RACI。memberが各タスクを担当。チャート図に。ボトルネックの手がかりに。コスト計画。コストを見積もり予算を検討。コスト見積もりは概算金額を算定して見積もり根拠を。コストの考え方。あくまで見積もられる金額。それを基本としてコストの目標値が決まる。スコープとの関係のトレードオフ。ステークホルダーを考えて要求を把握して。コスト見積もりの手法。各資源の単価を。類推見積もり。過去のプロジェクトを参考に。アクティビティのコストを積み上げて。ケース見積もり。変数との関係を統計処理。過去の類似例を。内容によっては係数見積もりを。規模への対応。量の相違でなく質の相違を。見積もりを行うには個々のアクティビティを積み上げる。細分化して単純化することで。計画段階での見積もり。2つ以上の異なる方法で比較。大枠見積もり、検証など。大枠見積もり。検証用の見積もり。ファンクションポイント法など。開発規模で数十倍にも。規模が大きくなると能力は平準化。ソフトウェア開発規模。計算式。生産性指数。欠陥の発生に。工数は様々な条件から計算。難易度を元にしたファンクションポイント法。集計した値。開発規模を見積もる。開発初期段階での概算が可能。エンドユーザが認識可能。特定のツールに依存しない。標準化されている。プロジェクトの複雑性は反映されないが。非機能について反映しづらい。尺度が荒いなど。開発規模工数の見積もり。近年はdataの蓄積が簡単に。見積もりだけでなく。ボトムアップ見積もり。実際に積み上げ式なので、細かいものを積み重ねると多めに出る。個々の作業の見積もり。活用の際に成功不成功についての原因も整理できる。
