- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
!!!PM プロジェクト計画立案と変更管理
{{amazon 4798104329}}
非常に丁寧でわかりやすい。
----
!!私が携わったプロジェクトの概要
!プロジェクトの概要(400 25×16行)
*1000人規模のSI勤務
*4割が受託開発
*A社資材調達マイグレーションプロジェクト
*既存基幹フレームワークに統合
*新規機能も盛り込む
*既存の基幹Webフレームワークに統合
*新規機能もあわせて実現する
**内示精度向上(在庫削減)
**ワークフロー(内部統制)
*不要機能削減による開発工数減
**利用されていない機能の削除
**重複マスタ関連の開発不要
*複数のサブシステムに分かれる
*規模
**工数：120人月
**期間：15ヶ月
１２３４５６７８９＊１２３４５６７８９＊１２３４５
私の勤務する会社は、従業員約１０００のSIer(システムインテグレータ)である。
４割の従業員が、顧客企業からの受託開発に従事し、
私は製造業を営む顧客企業に常駐し、プロジェクト管理を行っている。
今回私が担当したのは、車の部品を製造している、
Ａ社の資材調達システムである。
現在Ａ社では、全社共通の基幹システムフレームワークが
構築されているが、現在の資材調達システムは、フレームワーク構築前に
開発運用されていたこともあり、基幹フレームワークに統合されていない。
このため、フレームワークに対応している他の基幹システムに比べ、
連携運用の作業コスト、外注への開発保守の費用が割高な状態である。
またハードウェアも独自に用意しており、この維持費用も必要となっている。
資材調達システムを基幹システムフレームワークへ移行、統合することにより、
上記、連携運用の作業・保守コスト・ハードウェア維持費用を削減する狙いがある。
また、この機会を利用し、（Ａ）機能を新規開発することにより、
（Ｂ）する。
総開発工数は、１２０人月、開発期間は１５ヶ月を見込んでいる。
!変更の可能性があると予測した業務仕様(400 25×16行)
*内部統制の要求
**必要なワークフロー要件が定まっていない
*仕入先利用機能
**300社あり、代表にしかヒアリングできない
**機能によっては、フレームワークが対応していないため、代替案を了承してもらう必要がある。
**利用する発注部署も多いが、ヒアリングするのは代表のみ
*新機能(内示精度向上)
**主管(資材調達)部でも、要件が決め切れていない
**リプレースの期限は決められている
*既存機能リプレース
**既存で実現されている機能のため、主管(資材調達)部の参画意識が薄い。
プロジェクトの立ち上げ段階では、基本的に既存のシステムの
機能を踏襲するということで、主管である資材調達部との
要件定義は行っていた。
しかし、既存のシステムの機能要件については、
議論することができたが、
!!業務仕様の変更を考慮したプロジェクトの運営方法について
!業務仕様の変更に柔軟に対応するために検討した事項(800)
!業務仕様の変更への対応(800)
!!評価と改善点
::私の評価(400)
::今後の改善点(400)
