システム開発の委託で失敗しないためのポイント

皆さんこんにちは！㈱スクラムソフトウェアの製造業DX担当.Aです。今回は月２回の当社で実施している「製造業DX勉強会」で触れた「工場におけるカメラ監視」についてお伝えしたいと思います。

記事を書いた人…

システム開発で失敗しないための３つのポイント

今回はシステム開発を業者に委託する上で、失敗しないためのポイントを次の３つに絞って、お伝えします。

• ポイント１：仕様で失敗しないために
• ポイント２：スケジュールで失敗しないために
• ポイント３：金銭面で失敗しないために

それでは、順を追って見ていきましょう。

ポイント１：システム仕様で失敗しないために

あなたの会社が、必要としているシステムの開発を実現させるためには、システム開発業者に対して必要とする機能を十分に伝え、それをシステム開発業者に理解させる必要があります。

必要とする機能をシステム業者に伝えるためには、1. 契約前にやること、2. 開発前にやること、3. 開発中にやること、というように各開発フェーズでそれぞれ、実施する必要があります。

それでは、各フェーズでやるべきことについて、それぞれ見ていきましょう。

1. 契約前にやること：「RFPを作る」

RFPは「リクエスト・フォー・プロポーザル」と言い、システム開発を依頼する側（あなたの会社）が作成し、委託するシステム開発業者に渡すものです。

RFPでは、概ね次のことを文章で作成します。

• 会社概要
• システム導入計画の背景
• システム導入の目的
• 希望するスケジュール
• 自社の体制
• 希望するシステムの機能一覧
• 機能に関する要望
• 運用場面での要望
• 教育面での要望
• その他の要望

このRFPを、委託したいと考えるシステム開発事業者に渡し、この書類をもとに、提案書と見積書を作成してもらう様にしましょう。その後提出される見積もりについては、RFPで記した項目がきちんと反映された明細を提出するようにお願いしましょう。これにより、委託側がRFPの内容を十分に理解し、見積もりにも反映していることを確認できます。

2. 契約後にやること：要件定義書を作ってもらう

次に、契約後でかつ本格的な開発作業に入る前に、委託するシステム開発業者に対して行う作業について説明します。

契約後、システム開発業者は多くの場合、要件定義書の作成を行います。

要件定義書とは・・・委託側のシステム開発業者が、システム開発プロジェクトの初期段階に、開発予定のシステム要件や仕様を正確に定義した書類になります。RFPがシステム開発を依頼する側が作成するのに対して、要件定義書はRFPをもとにシステム開発の委託側が専門家として正確に作る書類です。そのため、RFPでは少々曖昧な表現だった箇所も、要件定義書ではシステム面から正確に表現されます。

例えば、RFPで次のような文面で表現したとします。

• RFPの文面例：「たくさんの従業員が同時に使用することのできる機能」

これに対して、要件定義書では例えば次のように数値に置き換え正確に定義されます

• 要件定義書による文面例：「３０人のユーザーが同時接続しても、待機時間５秒以内で処理を実現させる」

以上の観点から、「あなたの会社で作ったRFPが、要件定義書ではシステム面から正確に定義されているか？」をチェックすることが、仕様面で失敗しないためのポイントとなります。

3. 開発中にやること：プロトタイプを作ってもらう

開発中は、基本的には委託されたシステム事業者がどんどんプロジェクトを進めていくフェーズですが、委託した側も何もしないわけではありません。場合によっては、システム事業者に開発中の製品をプロトタイプとして、ユーザーが利用できる形で作ってもらい、実際に目で見て使ってみることで、仕様通りか、思い描いていたイメージ通りかをチェックすることも重要です。

また、業者によってはプロトタイプの作成に難色を示すこともあるかもしれませんが、この点も契約前にしっかりとプロトタイプの製作についてもチェックすることが重要ですね。

ポイント２：スケジュールで失敗しないため

スケジュール面で失敗しないためには次の点が重要です。

実現可能なスケジュールの提出を依頼する

システムの納品は早いに越したことはありませんが、委託されたシステム開発事業者が非現実的なスケジュールを作ってしまっては意味がありません。スケジュールについては、必ず順守できる期間で制作してもらうよう、あらためて依頼しておきましょう。

マイルストーンの提出を依頼する

マイルストーンとは、成果物の完成という大きな目標に対して、節目となるそれぞれの小目標に分解したものであり、チェックポイントとして機能するものです。このチェックポイントとなる小目標がスケジュール通りに達成されていることで、全体のスケジュールの進み具合も評価することができます。

定期的なミーティングを依頼する

先述のマイルストーンは全体のスケジュールにおいてチェックポイントとして機能することを説明しました。長い開発期間において、節目節目となるチェックポイントで、定期的にユーザーが成果物について評価できるようなミーティングの開催を、委託するシステム開発事業者に依頼するといいでしょう。また、チェックに当たっては、先述のプロトタイプによる評価ができれば、ユーザーも評価がスムーズにいきますね。

ポイント３：金銭面で失敗しないために

金銭面で失敗しないためについて説明します。

見積書と明細について

まず、見積書についてです。業者によっては見積書はざっくりとした項目しか作らない場合が多いですが、そのようなざっくりとした見積書では、最終的に「言った、言わない」ということが起こり得ます。そのため、必ず、RFPで提出した機能が実現できることがわかる形式で、明細を添付してもらうようにしましょう。

システムの見積については当サイトのこちらにも詳しく解説しています

変更管理について

また、変更管理についての取り決めも契約前に事前に協議しましょう。どの程度の変更であれば予算内で可能か、どの時点までであればスケジュール内で開発可能かなども事前に協議しておくことが重要です。

保守と運用について

システムは開発して全てが完了ではありません。むしろ開発後の運用や保守が本番です。そして、運用や保守については、サーバー費用、アップデート費用、セキュリティ管理など、さまざまな費用や作業が発生します。この点についても事前に協議し、見積もりを作ってもらうことがが重要です。

システム開発における当社のポイント

当社ではシステム開発に、アジャイル的なアプローチを取り入れて実施しています。一度、使用を決めれたら完成までその仕様書に沿って一気に作り上げるウォーターフォール的なアプローチと対比される手法です。

具体的には、開発プロジェクト全体を、複数の「スプリント」と呼ばれる単位に区切り、スプリントを繰り返して実務運用レベルにまで作っていくきます。ポイントとしては、以下となります。

• 必要最低限の機能から進める。
• 機能単位で見積もりを行う。
• スプリントごとに発注を受ける

アジャイル的なアプローチのメリットはいくつかありますが、最も大きなメリットは、顧客満足度の向上になります。なぜなら、ウォーターフォールのようにプロジェクトの初めに仕様書を作り込み、一気に開発すした場合、どうしても、仕様書の作成段階で考察できなかった機能や仕様のモレが発生しても、それを吸収できないからです。

一方、アジャイル的なアプローチでは、スプリントの段階で、お客様からの仕様追加や変更についても、柔軟に対応可能となります。ここが、お客さまからの満足度向上につながる要因となっています。

また、当社でも無料のIT相談もお受けし、開発のご依頼も全国にてお受けしております。お気軽に、ご相談ください。