システム開発のタスクが分かるとプロジェクトの全体像が見えてくる【2024年最新版】

システム開発を成功させるには、発注側が自分のやりたいことについてきちんと開発側に伝え、プロジェクトが開始してからも、常に発注側主体でプロジェクト全体を管理することが重要です。

ただ、最初の要求定義や要件定義の段階では積極的にプロジェクトに関わっていこうとしていた発注側のプロジェクトチームも、開発が進行するに連れて開発側からの定期報告を待つだけ、定期報告をメールやミーティングで受けてもただ聞いているだけ、ということになりがちです。

システム開発を成功させるためにはこうした消極的な関わり方に陥らず、途中段階で開発状況に適切なチェックを入れ、必要なテストに参加し、開発側企業に自分たちの意見をフィードバックしてより良いシステム作りに反映させていく努力が必要です。

「しかし、積極的にプロジェクトに関与していくには、専門の技術的な知識がないと無理なのでは…」

そう思ってしまう発注担当者の方もいるでしょうが、そんなことはありません。
システム開発の全期間にわたって発注側が積極的に関わっていくために、特別な技術的な知識は要りません。
必要なのは、プロジェクトの全体的な流れを理解し、各プロセスでどんなタスク（達成すべき課題、チェックポイント）があるかを押さえることです。

各プロセスで必要なタスクを押さえておけば、開発側が間違いなくプロジェクトを正しい方向に動かしているか確認できますし、必要に応じてチェックしたポイントについて改善の方向性を探るための積極的なミーティングを行うこともできます。
開発側からの報告をなんとなく聞いているだけという不毛な会議はこれで解消できるでしょう。

この記事では発注側も積極的にプロジェクトに関わるために理解しておくべき、システム開発における「タスク」について解説します。

それでは実際に工程ごとのタスクを見ていきましょう。
日本のシステム開発で長く行われてきた「ウォーターフォール型開発」を例に説明します。

最初の段階は、システム開発会社に話を持ちかける前に今回のシステム開発の目的を明確化することから始めます。
開発目的とは、例えば「エクセルベースで営業マンが管理している顧客データを一元化して、キメの細かい組織的な顧客対応を行えるようにする」といった、現状の課題を解決する方向性を一言で言い表したものです。

「目的」を明確化しようとするなかで陥りやすい間違いが、目的と目標を混同してしまうことです。
「目標」とは例えば「現在行っているエクセルベースでの顧客管理の時間を半分に短縮する」などになります。
定量的な指標（半分）が入っていて分かりやすいのですが、これは「エクセルベースで営業マンが管理している顧客データを一元化して、キメの細かい組織的な顧客対応を行えるようにする」という目的を実現するための手段の１つに過ぎません。
ほかにも目標はたくさん出てきます。
開発会社に一言でプロジェクトの方向性を示すためには、目標ではなく目的を明確化することが大切です。

また、「目的」が発注窓口となっている情報システム部門や、発注担当者の周辺だけで理解されているという状況にならないように注意しましょう。
新しい顧客管理システムの導入であれば、当然マーケティング部門や営業部門とシステム開発の「目的」について方向性を共有している必要があります。
現場の顧客管理を巡る課題がどういったものであるのかを丁寧にヒアリングして、関係者全員が納得できる「目的」を見つけ出しましょう。

必要に応じて、トップマネジメント層にヒアリングをして「目的」を設定することも必要です。
マーケティング部門や営業部門からは、基本的に「現在置かれている状況を改善する」といった発想以上のことはなかなか出てきません。
もちろん現在の課題を解決することがシステム構築では欠かせませんが、より根本的に「そもそもその業務のやり方は正しいのか？」というビジネスプロセスを再構築（BPR）する視点でシステムを見直したほうがよい場合もあります。
そうしたケースでは現場の意見をヒアリングするよりも、先に経営陣と業務プロセス見直しの必要性について検討することが重要なタスクとなります。

目的が明らかになったら、今度は開発対象の範囲を決定します。
システム開発では最初に開発の範囲に線引きをしておくことが重要です。
システムが具体的になるに連れて、担当者の頭のなかもアップデートされ、次から次へと新規の「この機能も欲しい」「あの機能もあったほうがよい」といったアイデアが浮かんできて、次々と追加要求をすることがありますが、そうすると開発会社は対応できなくなってしまいます。
できるだけ初期段階でやりたいことを明確化しておいたほうが、コストも安く済むケースが多いのです。

開発範囲を決定するには、システムで実現したい機能を列挙してみるほかに、納期、予算といった制約条件も明確にしておく必要があります。
こうすることによって、現実的な開発範囲が決定できます。

もちろん、社内で検討した開発範囲は最終的な決定事項ではありません。
開発目的と開発範囲が明らかになった時点で、RFP＝Request For Proposal（提案依頼書）を作成して複数の開発会社に声をかけ、最適な提案を募ります。

RFPを作成して配布したあとは、開発会社からの提案を待ちます。
個別にコンタクトを取って提案書の詳細を確認する方法もありますが、コンペ形式で時間と場所を指定して外注先候補の会社を集めて、プレゼンテーションをしてもらうという方法もあります。
同時刻に一堂に集めてプレゼンをさせることに抵抗がある場合には、会社ごとに30分程度プレゼン時間をずらして指定し、業者同士が顔を合わせないようにするという方法もあります。

その後、提案書の詳細を検討して、開発依頼をしたい会社に連絡を取り、契約に進みます。
契約の仕方は「請負契約」「業務委託契約」「多段階契約」などがありますので、プロジェクトの案件にピッタリの方法を見つけましょう。

*案件ごとに最適な契約方法を選ぶ方法については、こちらの記事などもぜひご参照ください。

無事に契約を結ぶことができたら、さっそくその会社とプロジェクト計画の詳細を詰めていきましょう。
プロジェクト計画では発注者、開発側双方で、プロジェクトのスケジュールや方針などを具体的に詰めていきます。

いよいよプロジェクトの本格稼働です。
本格稼働にあたっては、必ず双方のキーマンとメンバーのスケジュールを調整してプロジェクトスタートのための全体会議（キックオフミーティング）を開催しましょう。
キックオフミーティングのメインの目的は、各メンバーの役割を確認しながら、プロジェクトの計画を確認することです。
各メンバーの紹介や役割を全員が認識し、各メンバーが責任を持ってプロジェクトにあたることを確認しましょう。
その他、全体スケジュールや、成果物のイメージのすり合わせなどを行い、次回以降の「要件定義」の準備をします。

要求定義においては、発注者側がどんなシステムを作りたいのかの詳細を明らかにしていきます。
システム開発でやりたいことの概要についてはすでにRFPで伝えてありますが、ここでは開発側が発注側にヒアリングを実施するなどして、開発者側の視点で発注者の要求を明確化します。

明らかになった要求定義は、要件定義に引き継がれます。

要件定義とは、発注者の要求をシステム開発に落とし込むとどんな機能になるかを明確化したものです。

■プロジェクトの目的と背景

■現状分析
　　　　1. 現状業務
　　　　2. 現状の課題
　　　　3. システム化の方針・目標
　　　　4. システム構築後の業務フォロー

■機能要件
　　　　1. システム概念図

　　　　2. システム化対象業務一覧
　　　　　　　2-1.今回対象とする業務
　　　　　　　2-2.次回のフェイズで対象とする業務

　　　　3. システム機能一覧
　　　　　　　3-1.システム画面一覧
　　　　　　　3-2.システム出力帳票一覧
　　　　　　　3-3.アクセス管理機能
　　　　　　　3-4.システムメンテナンス機能

　　　　4. システム運用例
　　　　　　　4-1.サンプルAの実現フロー
　　　　　　　 4-1-1.画面遷移図
　　　　　　　 4-1-2.メニュー構成
　　　　　　　 4-1-3.画面サンプル
　　　　　　　4-2.サンプルBの実現フロー
　　　　　　　 4-2-1.画面遷移図
　　　　　　　 4-2-2.メニュー構成
　　　　　　　 4-2-3.画面サンプル
　　　　　　　4-3.サンプルCの実現フロー
　　　　　　　 4-3-1.画面遷移図
　　　　　　　 4-3-2.メニュー構成
　　　　　　　 4-3-3.画面サンプル

　　　　5. データベース構成
　　　　　　　5-1.インフラ基盤
　　　　　　　5-2.ER図
　　　　　　　5-3.テーブル構成詳細

■非機能要件
　　　　1. 業務量の想定
　　　　　　　1-1.ユーザー数
　　　　　　　1-2.稼働時間
　　　　2. 性能要件
　　　　　　　2-1.応答
　　　　　　　2-2.キャパシティ
　　　　3. 可用性要件
　　　　　　　3-1.障害発生時対応
　　　　　　　3-2.バックアップ／リストア
　　　　4. 機密性要件
　　　　　　　4-1.想定されるリスク
　　　　　　　4-2.セキュリティ対策
　　　　5. ハードウェア構成
　　　　　　　5-1.テスト
　　　　　　　5-2.システム評価
　　　　6. ソフトウェア構成
　　　　　　　6-1.テスト
　　　　　　　6-2.システム評価
　　　　7. ネットワーク構成
　　　　　　　7-1.テスト
　　　　　　　7-2.システム評価

■プロジェクト体制
　　　　1. プロジェクト体制図
　　　　2. 責任と分担
　　　　3. 全体スケジュール
　　　　　　　3-1.定例会議
　　　　　　　3-2.中間報告会
　　　　　　　3-3.議事録の作成
　　　　　　　3-4.課題管理と質問への回答
　　　　　　　3-5.変更管理
　　　　　　　 3-5-1.変更管理手順
　　　　　　　3-6.構成管理
　　　　　　　 3-6-1.構成管理DB
　　　　　　　 3-6-2.登録手順
　　　　　　　3-7.リリース管理
　　　　　　　 3-7-1.テストリリース
　　　　　　　 3-7-2.本リリース
　　　　　　　3-8.仕様の凍結
　　　　　　　3-9.完了報告会と検収
　　　　　　　　 3-9-1.テスト
　　　　　　　　 3-9-2.システム評価
　　　　　　　　 3-9-3.ユーザー評価
　　　　　　　3-10.納品物一覧
　　　　　　　　 3-10-1.文書管理手順
　　　　　　　　 3-10-2.文書体系
　　　　4. 作業環境
　　　　　　　4-1.開発環境
　　　　　　　4-2.開発場所
　　　　　　　4-3.データコンバート
　　　　5. 導入教育
　　　　6. その他付帯作業

こうしたきちんとした要件定義書を作ってもらうことがこの工程でのタスクのメインとなります。

要件定義書は開発会社がプログラミングを進めていくための指針となるばかりではありません。
詳細金額の決定、最終納品時に発注したときの条件を満たしているかの確認など、プロジェクトの重要な場面でも使いますので、妥協なく厳密なものを作成してもらってください。

「外部設計」では、要件定義書をもとにシステムのインタフェース部分を設計します。
具体的にはウェブサービスやソフトウェアの画面レイアウト、帳票レイアウト、管理画面のデザインなどがあります。

「内部設計」では、外部設計で確認したインタフェースが実際に機能するためのプログラミングを行います。

「移行計画」では、移行データを用意する担当者を決め、既存システムのなかから移行対象のデータを特定し、いつまでに用意するのかを決定します。

設計書をもとに、プログラミングをしていきます。
今日ではプログラミング作業とは、個人的な職人的技術を駆使した作業ではなく、設計書に基づきプログラミング規約に則った集団作業です。
したがって、納品してもらうソースコードは可読性（どの技術者がそのソースを読んでも解読可能であること）が求められ、必要な箇所にコメントが記載されている必要があります。

最終の受け入れテストに必要なハードウェアやデータを準備します。
また、エンドユーザーに新システム導入の目的やソフトウェアの使い方などの説明を開始します。
利用者が社外にも想定される場合には、新システム導入の案内を送ります。

この工程では「単体テスト」「結合テスト」「受け入れテスト」のそれぞれの実施項目を明確化してドキュメントにします。
単体テストと結合テストに関しては、開発会社の内部で行う作業になりますが、納品時のソースコードの品質を保証するという意味でも、どんなテストを行い、どんな結果だったのか、テストによって改善した点は何かなどもドキュメントにしてもらい、納品時に添付してもらいましょう。

受け入れテストとは、発注者側がシステムの稼働環境で実際に業務を遂行できるかどうかというレベルで行うテストです。
業務の想定シーンを何パターンも作った上で、漏れのないテストをすることが肝心です。
機能的なテストのほかにパフォーマンス・テストや負荷テスト、障害テストなども実施します。

納品完了と運用・保守体制を稼働させます。
システム開発としてのプロジェクトは一区切りつくことになりますが、納品したらすぐに開発会社との縁が切れるわけではありません。
今後の運用・保守の相談をしたり、具体的に運用保守の一部をアウトソーシングしたりといった面で開発会社との関係を大切に育てていきます。

■ ハードウェア運用・保守
　・ハードウェアの故障対応
　・ネットワーク障害対応
　・セキュリティアップデート
　・セキュリティトラブル対応
　・データバックアップ
　・データ復旧
　・ネットワーク監視
　・定期メンテナンス
　・OSアップデート
　　　など

■ ソフトウェア運用・保守
　・アプリケーションバグ対応
　・使用時トラブル対応
　・操作方法に関するお問い合わせ対応
　・OSアップデートに伴う不具合修正
　　　など

■ サービス委託
　・ECサイト運営
　・コンテンツマーケティング運用
　・インバウンドマーケティング対応
　・マーケティングオートメーション対応
　・SEO対策
　・リスティング広告代行
　・問い合わせ対応
　・顧客データベースメンテナンス
　・顧客ヘルプデスク
　　　など

以上、ウォーターフォール型開発の流れに沿って、各工程のタスクを確認してきました。
こうしたタスクをチェックリストにしておけば、開発工程ごとに開発会社とどんなやり取りをして、どんな報告を期待すればよいのかが把握できます。
このような視点でプロジェクトに関わっていけば、プロジェクトの全体像がはっきりと見えてきます。
おざなりの報告を受けるだけでなく、発注者も積極的にプロジェクト途中の確認作業、協力作業をしていきましょう。

アジャイル型開発の特徴は、ウォーターフォール型開発のように納品前になって初めて発注者が最終テストをするのではなく、全体を細かく分けた上で、小さな最終テストと納品を繰り返していくというところにあります。

この３番目の作業の、最終「目的」を達成するために「目標」を定めてそれを納品物として完成させる、という部分がアジャイル開発の特徴です。
例えば「顧客満足度を高める」という最終目的を実現するために「優良顧客を選別するシステムを作る」とか「優良顧客に自動的にダイレクトメールを送るシステムを作る」などの小さな目標を実現していきます。

つまり、アジャイル型開発では、各「目標」の実現が、各サイクルの「タスク」となるわけです。
ウォーターフォール型開発のように、「要件定義」段階のタスクはこれ、「受け入れテスト」段階のタスクはこれ、といった明確な定義が最初からあるわけではありません。

発注担当者やエンドユーザーの評価によって、最初にリストアップしていた「目標」実現の優先順位もどんどん変わっていきます。
小さな「目標」（タスク）をその都度定義しながら、短期間で次々にタスク完了までの開発プロセスを実行していくのがアジャイル開発なので、ウォーターフォール型開発以上に、発注者がプロジェクトに積極的に関わっていくスタイルとなります。

ウォーターフォール型開発が、タスクに注目することでプロジェクト全体像がよりはっきり見えてくるという特徴を持つのに対し、アジャイル型開発とは、プロジェクトの全体像を確認しながら、次々と新しいタスクを定義していくところに特徴のある手法だと言えるでしょう。

このタスクを常に開発会社とチームで共有しながら、タスクの優先順位を組み替えていくというアジャイル型開発手法は、この記事をお読みの方には特に興味深いと思われます。
アイミツまとめのこちらの記事などもぜひご参照ください。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、代表的なシステム開発の２大スタイルである「ウォーターフォール型開発」と「アジャイル型開発」の流れに沿って、各フェイズで押さえておくべき「タスク」について整理してきました。

システム開発は、発注側企業の抱える問題点を解決することが最終目的となるプロジェクトです。
したがって、発注者が途中段階で開発の方向性を確かめたり、やむを得ず追加のリクエストをしたりといったことは、良いシステムを作るのに欠かせない作業です。

ところがシステム開発会社のなかには、発注者がシステム開発に積極的に関わろうとする態度を歓迎しないところもあるのです。
どんな開発会社なのかというと、いったんプロジェクトに入ってしまうと、こうしたタスクや課題を社内で明確にせず、腕は良いけれどノウハウが属人化したプログラマーに開発を任せてしまい、プロジェクト全体の管理をそれほど重視していないというタイプのシステム開発会社です。

こうした会社は、問題なくプロジェクトが進んでいる場合にはよいのですが、いったんプロジェクトがうまく進まなくなったときなどに、タスクの管理をきちんとやっていないツケが一気に表面化します。
納期が遅れるということだけならまだしも、納期を無理に守ろうとするために発注者とのコミュニケーションがますますおざなりになったり、強引に納期を間に合わせて仕上げた納品物は当初意図していたものとかなり違っていたりすることがあります。

システム開発の外注先として理想的なのは、現在行っているプロジェクトの各工程について、進捗状況や問題点を、クライアントときちんと共有してくれる姿勢を持った会社です。
こうした会社であれば、プロジェクトが変な方向に行ってしまうというリスクも少ないですし、プロジェクトの途中段階で発注者側の意見を開発にフィードバックしてより良いシステム作りに反映させていくといったことも可能です。

せっかく発注者側がプロジェクトの全体像を把握して、より完成度の高いシステムを構築するためにプロジェクトに積極的に関わろうという意欲を持っていても、肝心のシステム開発会社が現在進行中のタスクを明確化して説明してくれない、という場合には、プロジェクトの全体像をはっきりと把握することもできず、不安を抱えながら最終納品を待つことになってしまいます。

システム開発会社の情報を数多く蓄積している「アイミツ」に相談していただければ、開発の各プロセスのタスクをしっかり説明し、プロジェクトを一緒に成功させていくというポリシーを持った優良開発会社をご紹介できますので、ぜひお声をかけていただければと思います。