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

目的：全体像を把握し、今の自分の役割を正しく理解して
効率的に動ける状態をつくる

Transcript

1. 提案 要件定義 設計 実装 テスト 運用 システム開発について 前編｜全体像とプロジェクトの流れを理解する 目的：全体像を把握し、今の自分の役割を正しく理解して 効率的に動ける状態をつくる 新人・若手向け研修 1
2. 前編のゴール GOAL システム開発がどう進むかを理解し、 自分の担当業務が全体のどこに位置す るかを掴む。 AGENDA • システム開発とは何か • プロジェクトとは何か • 開発工程の全体像 • 各工程で何を決め、何を渡すのか • 自分の役割をどう見るか 講義の狙い 「自分は実装担当だから実装だけ分かればよ い」ではなく、 前工程で何が決まり、後工程へ何を渡すのか まで見えるようにする。 これが分かると、確認・相談・報告の質が上 がり、手戻りを減らせる。 2
3. 1. システム開発とは何か システム開発 = 顧客や業務の課題を、仕組みとして解決する活動 目的 便利な画面を作ること自体で はなく、 業務効率化・ミス削減・情報 共有・価値提供を実現するこ と。 誤解しやすい点 コードを書くことは一部。 提案・要件定義・設計・テス ト・運用まで含めて開発。 なぜ全体像が必要か 自分の作業の意味が分かり、 何を確認すべきか・誰に相談 すべきかが明確になる。 補足 開発規模が大きい。特定の領域しか担当していない場合にいざ自分が上に立った場合何をしたらいいかわからなくな る。 以前はうまくいったが今回のプロジェクトはうまくいかない。理由はわからないなど再現性に課題が出てくる。 3
4. 2. プロジェクトとは何か プロジェクトは「特定の目標を達成するために行う、有期性のある非定型の仕事」 プロジェクト ルーチンワーク • 始まりと終わりがある • 目的達成のために進める • 未知・変化・調整が多い • 担当者や体制が変わりうる • 予測困難でリスクが高い • 日常的に継続する • 定型作業として回す • 変化が比較的少ない • 体制や手順が固定されやすい • 予測しやすく安定運用が中心 例：新サービス立ち上げ、システム導入、業務改善PJ 例：定常監視、日常保守、月次処理、窓口運用 4
5. 3. 開発工程の全体像 システム開発は、前工程で決めたことを後工程へ受け渡しな がら進む。 提案 課題・予算・ 実現性 要件定義 何を作るか 設計 どう作るか 実装 形にする テスト 期待通りか確 認 リリース 利用開始 運用保守 安定運用・改 善 ポイント 工程は直列に並ぶが、実際は前工程への差し戻しや見直しが発生する。 それでも基本形を知っておくと、自分の仕事の前提が理解しやすい。 「自分は今、何を受け取って何を返す工程なのか」を意識する。 5
6. 4. 各工程で何を決めるのか 上流 • 提案：課題・予算・方向性を 整理 • 要件定義：必要機能・制約・ 品質を決める 下流 • 設計：画面・DB・処理・イ ンフラを具体化 • 実装：設計をコードや設定に 落とす • テスト：期待通りの動作か確 認する • リリース：本番利用へ移行す る 運用 • 監視・問い合わせ対応 • 不具合修正・改善提案 • 継続利用できる状態を保つ 6
7. 4.1 提案、プリセールス 営業活動とも。プロジェクトは無から生まれてはこない。 課題 → 課題に対する提案 → プロジェクト発足 顧客ニーズの理解: 顧客が何を求めているのか。製品やサービスがそのニーズに応えられるか。 技術的なサポート: デモンストレーションをおこなうなど、顧客に製品やサービスの機能やメ リットを伝える。 提案書・見積書の作成: 顧客の要件に基づき、提案書や見積書を作成して提示する。製品やサー ビスの詳細、導入スケジュール、コスト見積もりなどが含まれる。 プロジェクト計画の策定: 初期のプロジェクト計画を策定し、必要なリソースや時間枠を確認す る。受注したとして対応出来るか否か。 クライアントとの交渉: 契約条件の調整や価格交渉を行い、プロジェクトを受注するための最終 的な調整をおこなう。受注契約を交わす前に作業をするのはあまり良いことではない。 - 何がしたい？何が欲しい？ - 予算は？いくら出せるのか？どれだけの費用がかかるか？ Whyなぜやるのか、What何をやるのか、Whenスケジュールいつまでに、How muchいくら、Whom誰に 向けて
8. 4.2 要件定義 何を作るかを決める もう少し具体的な話になる - システムがどのように機能すべきか - どのような制約があるか - どのような品質が求められるか 出来れば要件定義から請求できるのが理想（あまり見たことはない） What何を、Who誰が何人体制で、Whenいつまでに、Howどのように、Whereど こで作業場所及びリソースの配置場所、How muchいくら
9. 4.3 設計 どのように作るか。基本設計、詳細設計と呼ばれるケースがあるが基 本的に基本設計を重視する。 • DB設計 • 画面設計 • 機能設計 • インフラ設計 How
10. 4.4 実装、テスト 要件定義、設計でどこまで具体的に出来るかが勝負。 実装(だけ)が問題になることはほぼない。 「開発能力の不足」がやり玉にあがる場合ほとんどのケースで前工程 及びマネジメントの欠如が表出したもの。 How, What, When
11. 4.5 リリース 顧客に利用、実運用してもらう。 これまでの総決算。 リリースまでの各フェーズが忙しかったらリリースも忙しい。 リリース対応で思っていたアプリケーションと全然違うとなることもある。 How, What, When
12. 4.5 保守、改善 アプリケーションが稼働し続けるためには定期的な改善と運用が必要。 What運用保守対象は Why運用の主体は How much 月額、年額いくら
13. 5. 工程を貫く共通視点 各工程で何を問うべきなのか？ Why なぜやるのか What 何を作るのか How どう作るのか Who 誰が担うか When いつまでに 提案では Why / What / How much が大きい。 要件定義では What と制約・品質が重要。 実装では How と When が中心。 工程が変わっても問いの型を持っておくと 、情報整理と確認が速くなる。 打ち合わせやレビューの場で「今この工程では何を決め るべきなのか」をこの視点で整理するとよい。 7 How much いくらか Whom 誰に向けてか Point 例えば要件定義でHow(どのように)を問うのは多くのケースで有意義ではない（XXを使いたい。手 段の目的化） 開発フェーズ以降でなぜこの機能がいるのかといった話になった場合はすでにうまくいっていない ととらえたほうが良い。
14. 6. 開発は前工程でかなり決まる 要件定義と設計の質が低いと、実装・テストで挽回するのは難しい。 • 「何を作るか」が曖昧だと、正しく実装 できない • 設計が粗いと、実装者ごとの解釈差が広 がる • テストで問題が出ても、原因が上流にあ ることが多い • だからこそ、若手でも不明点を早く表面 化する価値が高い 各工程で徐々に具体化することが重要 広げた風呂敷をたたまずに話が広がって いく場合は危険信号。 8
15. 不確実性コーン 8 不確実性コーン 高 見 低 見 の 要件定義 設計 実装・テスト リリース前 プロジェクト進行 期 ど見 の れ が大きい 具体化が進む ど が まる い方の要点 ・ の見 は粗い ・ 化で が上がる ・早期確定を めす ない 講義補足 前工程では不確実性が高い ため、変 理と 的な 見直しが重要になる 用の 。実案件では の表現や ェー は ・ により なる。
16. 7. 自分の役割をどう見るか 自分の担当を「点」でなく「前後の受け渡し」で見ると、動きが良くなる。 前工程から受け取る 要件・設計・制約・優先 自分の担当 作業・確認・相談・記録 後工程へ渡す 成果物・課題・判断材 • 着手前に：目的・期限・前提条件を確認する • 作業中に：曖昧さ・影響範囲・リスクを見つける • 相談時に：事実／解釈／提案を分けて伝える • 完了時に：後工程が困らない形で残す 9 ※後工程に先送りした課題、作業は2倍、4倍、16倍の手間がかかる
17. 8. まとめ • システム開発は、課題解決のための一連の活動であ る • プロジェクトは、期限と目的を持つ非定型の仕事で ある • 開発は提案から運用保守までつながっている • 前工程の質が、後工程の手戻りや品質に大きく影響 する • 自分の役割は、前後工程との受け渡しで捉えると動 きやすい 次回 後編 ・プロジェクト規模とコスト感 ・ステークホルダーと意思決定 ・QCDSと優先順位 ・炎上PJあるある 今の自分は、どの工程にいて、前後に何を渡しているか？ 1 0