システム開発について_後編_新人若手向け研修

規模・コスト・契約・失敗例から現場での動き方を理解する

Transcript

1. システム開発について 後編 規模・コスト・契約・失敗例から 現場での動き方を理解する 新人 若手向け研修 1
2. 前回のおさらい • 前回はシステム開発の工程について説明 • 提案 → 要件定義 → 設計 → 実装 → テスト → 運用保守 Point システム開発の かむこ で いまの自分 の役割 把握して効率的に動け 状態 作 。 前編とのつながり 2
3. 後編のゴール • プロジェクトの規模感・費用感をつかむ • 関係者、優先順位、契約形態の違いを理解する • 現場で起こりやすい失敗を知り、早めに防ぐ視点を 持つ • 自分が効率的に動くための基本動作を整理する 講義の軸 後編は「どう進むか」よりも 「どううま 進め か」 扱います。 調整 記録 の重要性 伝え 回です。 前編とのつながり 前編で学んだ工程 前提に 後編では規模 コスト 契約 失敗例 通じて 現場感覚 けます。 2
4. プロジェク の をつかむ 区分 人数の目安 期間の目安 金額の目安 小規模 1〜数人 数週間〜1か月 数十万〜 中規模 〜8人程度 〜半年 数百万〜 大規模 10〜100人程度 1年以上 数千万〜億 超大規模 100人〜 数年 数十億規模も Point 規模 大き ほど 関係者 増え 意思決定 遅 変更の影響範囲 広 ため 難易度 上 ります。 ただしシステム開発 してや こ は大き 変わりません。 3
5. シ テム開発にはいくらかかるのか 考えてみよう • 5人6ヶ月のプロジェクト • 1人月 ≒ 20人日 • 1人が1ヶ月間作業したときの作業内容 • 単価： 作業時間あたりの金額。大体1人月あたりいくらか。 4
6. シ テム開発にはいくらかかるのか 保守料金について 年額として総開発費用の10〜20%が相場 36,300,000 * 15% / 12か月 ≒ 450,000/月 大体月あたりの稼働が0.5人(9,10日)程度。このラインを超えると赤字 というより月当たりの稼働が1,2日程度でないと危険信号。 4
7. シ テム開発にはいくらかかるのか インフラ料金について 5人×6カ月規模の業務系Webシステム 超概算で月￥5万〜20万程度 EC, RDB * dev, stg, prod環境 ※構成によって大きく変わる。冗長化、大量アクセス、大容量通信等 ※人件費と比較したら比較的金額は小さい ※運用も含まれる場合は￥100万を超えてくる 4
8. シ テム開発にはいくらかかるのか 基本の考え • 1人月 ≒ 1人が1か月働く作業量 • 概算は「人数 × 月数 × 単価」で考える • ソフトウェア開発は人件費の比率が高い • IT企業とそれ以外の企業では人件費の占める割合が圧 倒的に異なるので、人が動くことの費用感が噛み合わ ないことが多々ある。 1人×1か月 100万円 3人×3か月 900万円 5人×6か月 3000万円 10人×1年 1.2億円 保守費の考え 導入後は運用保守費も発生します。 年額で総開発費の10〜20%程度 目安に考え こ あります。 現場 覚 見積は単 数字では 人の時間 調整コスト レビュー 検証 環境準備 管理費用まで含めて考え 必要 あり ます。 Point 「少しだけだから簡単」 は限りません。 小さ 変更でも 確認 調査 テスト 説明で 工数 膨らむこ あります。 4
9. 関係者と優先順位を押さえる 主な テークホルダー 営業 PM / PL 実装者 インフラ担当 意思決定者 シ テム部門 現場利用者 協力会社 誰が決めるか、誰に影響が出るか、誰に確認が必 要かを 曖昧にしないことが重要 QCDSで考える 品質（Quality） コスト（Cost） 納期（Delivery / Schedule） スコープ（Scope） て 最大化す のは難し どこ 優先す かの合意 必要です。 品質 納期 ープ 5
10. 形態の違いを知る 請負 成果物に対して契約す 形 • 成果物 納品物に責任 負う • リスク 高い分 見積は保守的に りやす い • 仕様変更の影響管理 重要 SES / 準委任 時間や稼働に対して契約す 形 • 時間当たり 月額での対価 中心 • 成果物責任は比較的軽い 適切に働 義 務はあ • 指示系統や責任範囲の確認 重要 なぜ知る必要があるか 同じ「開発現場」でも 契約形態で 責任の置き方 進め方 見積の考え方 変わります。 仕事の違和感 理解す 助けに ります。 7
11. 失敗プロジェク の特徴 ― 9つの分類 8 失敗は特別 事故では 日常の小さ 見落 しの積み重ねから起きます。 よ あ 失敗 9 の型で押さえ 早めに気づいて手 打て 状態 ります。 1 目的・ゴールが曖昧 2 意思決定の失敗 3 人・組織の問題 4 ミュニケーションの失敗 5 進捗管理の失敗 6 体制・役割分担の失敗 7 ドキュメン 管理の失敗 8 品質管理の失敗 9 ・営業・見積の失敗 → 多くは「目的の曖昧さ・意思決定・共有・変更管理」の不足に行 着く
12. 失敗パターン① 目的・ゴールが曖昧 8 特徴（こんな兆候が出ていたら注意） • 実業務の確認 せず 担当者の経験則や一般論で仕様 決め ため 実際の運用 合わ い機能 作られ 。 • 例外ケース 後回しにす 。検討し い • 実現性 軽視され • 非機能要件 軽視され • 要件 現行踏襲 っていて 開発コスト 見積れ い • 目的 ゴール MTG 開催され 対応 針 問題提起のみでは動か い。方向性 示す ころから始め 。 防衛策 前提条件 書面で残す。防衛線 張 。
13. 失敗パターン② 意思決定の失敗 8 特徴（こんな兆候が出ていたら注意） • 現場の同意 取れてい い。実際に使う現場の同意 いため リ リース直前や受入テストで大量の課題 発生す 。 • 意思決定 おこ われ い。長期間かか 。先送り 後回しにす 。 • 近視眼的 場当たり的で軽率 意思決定 おこ われ 。 • 要件の変更管理 されてい い • 「要件定義完了」 言い 未決事項だらけ ってい 。後工程 に先送りし続けどこかで爆発す 。 対応 針 少 も内部では管理してお 。必要 場 合は仮置きで進め 本決定 ってもいい ように厳密に決めてお 。 防衛策 影響範囲 期日は事前に具 的に提示す 。 〇月〇日までにxxxx 決まってい い 後続 に影響あり。何日ずれ込む。
14. 失敗パターン③ 人・組織の問題 8 特徴（こんな兆候が出ていたら注意） • 決め 人 責任 取 人 異 • 意思決定者 最終決定者 会議に出てこ い • 他責志向で責任 押し付けあってい 対応 針 制図 意思決定者 最終責任者 明文化す 防衛策 組織文化に起因す ため短期的 改善は困難。 記録に残し 個別チャット等個人間の連絡は 控え 。
15. 失敗パターン④ ミュニケーションの失敗 8 特徴（こんな兆候が出ていたら注意） • 雰囲気で合意してい 。口頭では合意したように見えても 議事 録 決定事項 宿題 期限 残ってい いため 後から「そん もりでは かった」 。 • 課題 遅延 不具合 仕様変更 早めに共有し いため 問題 見 えた時点ではすでに手遅れに ってい 。 • 悪い しに い。課題 発見した人 対応し い いけ いた め無視す 最適解 ってい 。 • 必要 情 秘匿されてい 。理由は不明。 • MTG中無限に話 逸れてい 。人の話 聞かず自分の言いたいこ だけ いう人 い 。 • 連絡 のみ ってい 。「こう りました」から 手戻り リカバリ 多 発生す • 情 分 されてい 。意思決定 作業者まで降りてこ い。 • 仕様や経緯 文書化されず個人の頭の中やどこかのチャット にしか い 対応 針 会議ではファシリテーター(進行役) 用意し 決定事項 未決事項 担当 期限 明文化す 。情 共有事項は一元管理 系化す 。 防衛策 組織文化に起因す ため短期的 改善は困難。 事前共有 頭出しは意識してお 。
16. 失敗パターン⑤ 進捗管理の失敗 8 特徴（こんな兆候が出ていたら注意） • QCDS(Quality, Cost, Delivery, Scope)のどれ 優先す かの できてい い。 • すべてのタスク 優先度高 ってい 。すべて優先度低 同じ意 味。 • はや ASAP いう言葉 出て 。誰 い 何 す のか できてい い。 • 進捗 時に開発者原因で遅延してい いう理由に 。戦略の 失敗は戦術で取り返すこ はでき い。 • 進捗率 雰囲気で され 。進捗率90%から動か い • 作業 増えてい のに完了日は変わら い • 開始遅延 仕様未決 あ 状態で工程の完了日は変わら い • クリティカルパス 見えてい い。どの作業 遅れ 遅延に か把握できてい い 対応 針 進捗は%管理せず未完了/完了で管理してタス ク 細分化す 。基本的にScope 削ってい 。優先順位 対応時期 こちらで明文化し て提示す 。上の上の人間 担当入れ替えも 視野に入れて調整す 。 防衛策 管理系作業 社内 品質分析 エビデン スキャプチャ等システム品質に影響し い部 分のQualityから削 。進捗に影響 出 要因 は一覧で整理してお
17. 失敗パターン⑥ 体制・役割分担の失敗 8 特徴（こんな兆候が出ていたら注意） • 誰 何 担当す のか曖昧 ままに ってい • 責任の押し付け合い 抜け漏れ 起き • 兼務過多で一人に負荷 集中す • 指示系統 二重化し 混乱す • 協力会社 の責任境界 不明確 対応 針 役割 責任範囲 明文化し 抜け漏れ 埋め 。 防衛策 制図 担当表 共有し 変更時は必ず更新 す 。
18. 失敗パターン⑦ ドキュメン 管理の失敗 8 特徴（こんな兆候が出ていたら注意） • 最新版 分から い。「設計書.xlsx」「設計書_修正版.xlsx」「設 計書_最終版.xlsx」 乱立してい ため どれ 正 して開発 テス トすればよいか分から い。 • 決定事項 資料に反映され い。会議で決まった内容 設計書 課 題表 仕様書に反映され いため 口頭合意 成果物の内容 ズレ 。 • 資料 メンテされてい い • Excel方眼紙で情 分 され • 作業者宛てに直接変更依頼 かか • メール 口頭 チャット 会議 課題表 どからバラバラに変更 入 ため 正式 変更かどうか でき い。 対応 針 ドキュメントの正本 決め 。一旦手 止め て整理す 。変更要求は入り口 一本化し作 業者の で対応し い 受け付け いよう にす 防衛策 不明瞭 状態での作業 控え 。どうしても 不明瞭 状態での作業 必要 場合は情 源 明示す 。一人で抱え込まず広 連携す 。
19. 失敗パターン⑧ 品質管理の失敗 8 特徴（こんな兆候が出ていたら注意） • 要件定義や設計段階でテスト観点 考えてい いため 実装後に仕 様漏れや設計矛盾 発覚す 。 • レビュー実施済み いう事実だけ 重視され 観点 指摘 対応確 認 弱いため 欠陥 後工程に流出す 。 • 課題 クローズさせ こ 優先して具 的 方針 解決されてい い。何度も再オープンす 。 対応 針 内部で検討は進めてお 。未決事項等は繰り 返し明示してお 。 防衛策 品質 守れ い条件 あ 場合は 早めに品 質リスク して明示す 。品質 確保す た めに必要だった条件 満たされていたか 重 要。
20. 失敗パターン⑨ ・営業・見積の失敗 8 特徴（こんな兆候が出ていたら注意） • 受注優先で納期 金額 スコープ 楽観的に提示してい ため 開 始時点から実現困難 計画に ってい 。 • 何 含み 何 含ま いか 曖昧 ため 顧客は当然含まれ 思 い 開発側は追加作業だ 考え 。 • ちょっ だけの変更 → 積み重 ってい の間にか大き 改修に っ て 対応 針 スコープ 明確にす 。やら いこ 明確 にす 。軽微 変更も一覧で管理す 。 見積根拠 前提条件 書面で残し 変更は追 加見積で合意す 。 防衛策 追加請求は交渉困難 ので最初に見積もり 盛れ だけ盛 。例え減額されていても後か ら交渉しやす 。
21. 共通の対応 針 8 問題を指摘するだけでは かない。必ず「案・期限・影響」とセッ で提示する。 例：問題提起に添える • A案 B案 C案 提示す • 推奨案 明示す • 期限 明示す • 未決の場合の影響 明示す • 後続工程への影響 明示す 根本改善が難しい場合は必ず残す 前提条件 未決事項 決定事項 判断者 期限 影響範囲 リ ク 追加作業 顧客確認待ち 自組織の懸念表明 → かせないことほど「残して可視化」しておくことが防衛策になる
22. 守るべ 防衛ラインを意識する 8 すべて 理想どおりに進ま ても どこまで守 かの優先順位 ってお 。 上の理想から一段ず 後退し 最後は必ず「自分」 守 の 最終防衛ライン。 理想 守れないと は下へ後退 最終 防衛ライン 顧客と自社のWinWinの関係 ★ 理想 会社の利益を守る 組織・チームの利益を守る 自身を守る ★ 最終防衛ライン → 「自分を守る」とは、記録・報告・前提の明示で身を守ること
23. まとめ • 規模 大き ほど 調整 意思決定 変更管理の 難易度 上 • 開発コストは「人の時間」 中心であり 小さ 変更 でも工数は発生す • QCDSや契約形態 知 現場で何 重視され か理 解しやすい • 失敗の多 は 共有不足 意思決定不足 変更管理不 足から起き • 把握して 整理して でき だけで 大き 戦力に 講義の締め 次の活用 9