システム開発の外注管理方法〜工程や注意点もあわせて解説〜
「システム開発を外注する際、どのように管理したら良いのだろう」とお悩みではありませんか?実際にシステム開発を外注してみると、意外にも発注側がすべきことが多いことがお分りいただけると思います。
つまり、システム開発における外注管理は必要不可欠です。そして、発注者側の役割は多岐に渡ります。
この記事では、システム開発を外注する際の管理方法を、工程や手法などに焦点を当て解説しました。これから外注する企業の担当者の方はぜひ最後までご覧ください。
システム開発の外注管理をするなら開発工程の理解は必須
システム開発の外注管理をスムーズに行い、外注ならではのメリットを最大限発揮するためには、開発工程を把握しておきましょう。スケジュール作成や進捗管理、途中で確認すべき箇所などの把握に役立つはずです。以下で主な工程について解説します。
要件定義
要件定義とは、本格的な開発の前段階と言える工程であり、発注者側の要望をまとめたものを元にシステム全体の方針を決めることです。機能・仕様・運用方法までをしっかり定めておく必要があります。開発の土台となる部分であるため、曖昧にせず綿密に行わなければなりません。
設計
設計は外部設計と内部設計に分けられます。外部設計ではユーザーから見える仕様を、内部設計ではシステムを円滑に動作させるための構想を、それぞれ設計する工程です。それぞれの内容を以下の表にまとめました。
外部設計 | 内部設計 |
・ユーザーから見える仕様に関するもの ・画面のレイアウトや画面遷移について細かく設計 ・システムの開発言語やフレームワーク、ハードやソフトなどについて設計 ・機能単位のデータの入出力設計 | ・外部設計したものを実現するためのもの ・各機能の処理の設計 ・データのやりとりの設計 ・外部設計で決めたデータをどう処理するかなどの設計 |
プログラミング
プログラムを設計し、プログラマーがコーディングしていきます。システムが実装されていく工程です。
テスト
プログラミングにより実装されたシステムをテストする工程です。以下のように複数の段階に分けられます。
- 単体テスト:機能ごとのテスト
- 結合テスト:機能を組み合わせたテスト
- 統合テスト:ユーザーが使用する前段階のテスト
- 運用テスト:ユーザーに作動してもらうテスト
テストはリリース前の問題発見に重要な工程であるため、何段階にも分けてテストを行なっています。
運用保守
上記のテストをクリアしたらリリースとなりますが、それで終わりではありません。
システムを安定して継続的に稼働させる「運用」と障害発生時に原因究明して復旧させる「保守」は必要不可欠といえます。
そして、運用保守と一口に言っても、セキュリティの監視・アクセス増加に対する管理・稼働状況の監視・システムの正常性の確認など、その対応範囲は幅広いものです。
システムは24時間365日稼働し続けるものが多いため、運用保守は軽視できません。
開発工程についてはこちらの記事もご覧ください。
システム開発の外注管理〜工程ごと〜
システム開発の場合では、開発工程ごとに発注側の介入の要不要が異なります。以下で、外注管理が特に必要となる工程について解説します。
要件定義
まずは、RFP(提案依頼書)に記載した内容をシステム化するため、発注者側の要望をピックアップ・整理し、要求定義を作成します。この要求定義を満たせているか発注側がチェックする必要があり、開発会社と認識の相違がないか確認・すり合わせをしなければなりません。
外部設計
外部設計では、ユーザーから見える部分を設計しており、リリース後のユーザーの使い勝手を左右する重要な工程です。そのため、実際のユーザー目線で画面のレイアウト・画面遷移・データの処理などを確認しておきましょう。
要件定義と同様に、開発会社との認識のズレがないようにする必要があります。発注者側の当初の要望とズレている、よく分からない箇所がある、などあればこの時点で慎重に確認しておきましょう。
テスト
テストはいくつかの段階に分かれますが、最終段階である運用テストは発注側が行わなければなりません。当初の要件定義に沿っているか、実用的な稼働に耐えうるかどうかなど、確認しましょう。
運用保守
リリース後に実際に稼働してみて、どのような体制で管理監視・トラブル時の復旧をしていくのか発注者側も協力する必要があります。
上記のように多数の工程で、発注側の協力は欠かせません。決して途中で丸投げすることのないようにしたいものです。
内部リンク「システム開発 丸投げ」
システム開発の外注管理〜その他〜
システム開発の各工程で外注管理とは別に、発注から完納まで通して注意しておきたいポイントがあります。いずれもトラブルを防ぐためには欠かせないものです。
契約内容の確認
トラブルを回避するためにも、契約内容は十分に確認しておきましょう。契約にも種類があり、請負契約か準委任契約かで報酬を支払う対象が異なるため注意してください。また、NDA(機密保持契約)の締結もしておくべきです。
費用面や納期はもちろんですが、納品後どこまで修正に応じるかなど明確にしていなければトラブルに発展しやすいため注意してください。
詳しくは、こちらの記事をご覧ください。(「外注化」の内部リンク)
トラブル対応
システム開発を外注する際、注意していてもトラブルを完全に回避することは難しいものです。
中でも納期や予算に関しては注意してください。納期が短すぎて質が担保されない、納期に間に合わない、要件定義が曖昧で仕様変更し予算オーバーしてしまった、プロジェクトが完成できなかったなど、様々な事例があります。
何か問題があれば冷静に原因究明し、大きなトラブルに発展しないよう対処しましょう。
要所でのチェック
システム開発を丸投げしてはいけないのは前述の通りです。そのため、必要に応じて各工程の要所でコミュニケーションをとったり、進捗を確認したりするなどのチェックが必要となります。
外注管理の詳しい解説はこちらの記事をご覧ください。
開発手法によっても進め方が異なるため注意が必要
システム開発は開発手法により、進行も異なります。代表的な手法と特徴を以下で解説します。
ウォーターフォール型開発
(図解)
ウォーターフォール型開発は、要件定義を行い細かい仕様や機能を全て決めてから設計・開発・テストと進めていく開発手法です。滝の水が流れて上に戻らないように、前の工程には戻らずに進めていくのが最大の特徴といえます。
最初に仕様が綿密に決まっていれば良いのですが、途中で変更があった際に修正が困難となるデメリットがあります。
アジャイル型開発
(図解)
アジャイル開発では、開発を素早く実行するために、小さな機能単位で実装・テストを繰り返します(イテレーション)。ウォーターフォール型開発とは異なり、機能単位で開発を独立して行うため、途中での仕様変更への対応も可能です。
イテレーションの中でテストを行うため、テストにはさほど時間をかけられません。そのため、リリース後のフィードバックが発注者側の役割となります。
プロトタイプ型開発
(図解)
プロトタイプ型開発とは、必要最小限の見た目や機能を搭載した試作品(プロトタイプ)を作成し、ユーザーに試してもらいながら仕様を固めていく開発手法のことです。製品のイメージが固まっていないものやユーザーの操作感が重視されるものなどが特に適しています。
詳しくはこちらの記事をご覧ください。
まとめ|外注管理でシステム開発を成功させよう
システム開発を外注するのであれば、開発会社に任せっきりにしてはいけません。
開発工程や手法を把握した上で、要所要所で発注者側も積極的に関わる必要があります。どの工程でどのような役割があるのか事前に把握しておくことで、発注からの流れもスムーズになるはずです。
適切な外注管理を行い、システム開発を成功させましょう。
クリーヴァでは、SucSak(サクサク)という、月額制でシステム開発チームのレンタルサービスを行なっております。CTOレベルの技術者が、やりたいことのシステム化をサポートすることも可能です。
ご興味を持たれた方は、以下URLより弊社サービスをご覧ください。