# ウォーターフォール開発とは？
ウォーターフォール型の開発とは、システム開発のための開発方法のひとつで、非常に基本的な開発概念となります。滝のように上から下に向けて水が流れるように開発していく様子から、ウォーターフォール型という名称がつけられました。一般的には、次の手順で開発を進めていきます。

・ステップ1：開発したいシステムを決定する
・ステップ2：開発に必要な機能を決定する
・ステップ3：実際にシステムを開発する
・ステップ4：開発したシステムをテストする

最初の段階で、具体的な画面やすべての機能を決定して開発に着手するため、開発の全体像について見渡しやすいというのが大きな特徴です。

# ウォーターフォール開発のメリット
・開発するシステムが明確なので何を設計すれば良いかイメージがしやすい
・開発方法が明確なので進捗管理がしやすい
・具体的な機能や画面イメージ、データの処理方法を決めるため、品質の管理がしやすい
・開発物システムが明確に決まっているため、無駄な作業をすることがない
・要求定義から運用までの流れが明確なので予定の管理がしやすい
・設計物が明確なので具体的な見積書を作成しやすい
・システム開発の基礎ともいえる開発手法なので、多様な開発方法に対応できる

# ウォーターフォール開発のデメリット
・途中で手戻りが発生すると大幅に完成予定がずれやすい
・開発が進めば、細かな変更ができない

特別、大きな問題点はありませんが、手戻りのリスクがゼロではない以上、しっかりとした進行管理が必要となります。

# ウォーターフォール開発の進め方
ウォーターフォール型の開発は、次の手順で進めていきます。

・ステップ1：要件定義
・ステップ2：外部設計
・ステップ3：内部設計
・ステップ4：コーディング
・ステップ5：テスト
・ステップ6：運用

それぞれの開発ステップについて詳しくご説明します。

### ステップ1：要件定義
まずは、要件定義を行っていきます。要件定義では、「このようなものをシステムで公開したい」という要望を言語化していきます。たとえば、次のことを話し合います。

・どのような人が利用するシステムなのか
・どのような工程で利用するシステムなのか
・どういった情報を扱うことになるのか
・どのような機能が必要となってくるのか

上記のことをシステム開発者と依頼者でしっかりと話し合っていきます。

### ステップ2：外部設計
外部設計とは、システムの利用者が目に触れる部分を設計することです。要件定義と外部設計は、基本設計と呼ばれており、外部設計ではシステム構築のイメージを具体化していきます。たとえば、画面の操作イメージや具体的な画面のイメージの明確化を行います。

この時、画面設計書や画面遷移図なども作成されるため、システムの全体像が把握しやすくなります。

### ステップ3：内部設計
内部設計では、実際の構築に必要なシステムの詳細を決定します。たとえば、プログラムの処理の工程やプログラムで扱うデータの工程を決めます。そのため、内部設計を見れば具体的なシステムを開発できるといった情報を決定する設計だとイメージすると良いでしょう。

必須項目の記載やエラー表示の仕方、データベースの管理方法などが詳細に決められていくため、システム開発者の開発の説明書といえるものになります。

### ステップ4：コーディング
基本的な画面構成や画面におけるシステム処理の詳細が決まったため、コーディングを行っていきます。コーディングとは、システム開発者が設計書を見ながらプログラムを構築していくことをいいます。

会社によっては、設計書の作成はエンジニアが行い、コーディングについてはプログラマーが行っていることがあるため、頭の片隅に入れておきましょう。

### ステップ5：テスト
開発したプログラムが正常に作動するかテストを実施します。テストは、次の方法で行われます。

・単体テスト
・結合テスト
・システムテスト

単体テストとは、内部設計で想定される動きが正常に作動するかを調べていくことをいいます。たとえば、必須項目を記載せずに登録した場合、正しくエラー表示が行われるかをひとつずつ調べていきます。そして、結合テストでは、複数画面との連結を確認していきます。たとえば、「新規会員登録」→「登録確認画面」→「登録完了画面」→「トップ画面」→「登録データ変更画面でデータ変更」といったように、一連の画面遷移に問題がないかチェックしていきます。

そのため、複数の画面でデータが正常に更新されるのか、新規登録できるのか、削除されているか、操作性に問題がないかをチェックしていくテストといえます。そして、システムテストを実施します。

システムテストとは、要件定義で決定した水準でシステムが問題なく稼働するかを調べることをいいます。実際に、操作シナリオを考案し、その通りに作動するかをチェックします。そのため、実際の利用をイメージしながらテストを行います。

### ステップ6：運用
運用とは、システムを正常に安定的に稼働させるための仕事をいいます。運用を開始すると、エラーの解決や使い方について多数のお問い合わせがあります。それに対応することが運用の仕事となります。

アジャイル開発と組み合わせるハイブリッド開発
ハイブリッド開発とは、設計仕様や変更を前提として反復的に仕事を繰り返すアジャイル開発と開発手順をひとつずつ確認しながら工程を進めていくウォーターフォール型開発を組み合わせた開発方法をいいます。

ハイブリッド開発なら早い段階でシステム開発を行いながら、利用するユーザーの意見を反映できるため、価値あるシステムを開発しやすくなります。



システム開発の人気の開発手法のひとつにウォーターフォール型開発と呼ばれるものがあります。ウォーターフォール型の開発とは、いったいどのような開発手法なのでしょうか。また、ウォーターフォール型の開発を選ぶことで、どのような開発メリットやデメリットがあるのでしょうか。

ウォーターフォール開発の進め方とメリット・デメリット

# スパイラル開発とは？
スパイラル開発は、作成するシステムを複数のサブシステムに分割し、サブシステムごとに開発工程を繰り返しながら進める開発手法です。例えば、開発を3つのサブシステムに分割した場合、サブシステム1を開発して納品した後、サブシステム2の開発に移行する、という形で順にサブシステムを開発していく流れを取ります。

サブシステム1の納品物はプロトタイプであり、リリースはしません。顧客からのフィードバックを受けて次のサブシステム2を開発します。複数のサブシステムに分けて開発を進めることで、開発規模が大きい場合でも、早い段階で顧客に開発内容を確認してもらえます。その結果、手戻りが少なくなり、システム全体の完成度が高まるのです。

スパイラル開発では、ウォーターフォール開発のような完全な要件定義や詳細な計画を事前に策定する必要がありません。開発プロセスの途中で変更や修正を加えることができるため、柔軟性や適応性に優れています。また、工程にプロトタイプの作成を含んでいることで、さまざまなリスクを事前に洗い出し、早い段階で対策できます。

このような特徴から、スパイラル開発は、スケジュールや仕様変更への柔軟な対応が求められつつも、品質が重視されるような開発に向いています。例えば、機能要件が明確ではない新規の大型開発で、品質も重視される場合に適しています。

# スパイラル開発のメリット・デメリット
スパイラル開発のメリットを一言で言うと、仕様変更に対する柔軟性と品質の確保です。一方デメリットは、プロジェクトの全体像を把握しづらく、当初の想定よりも開発コストが高くなりがちであることが挙げられます。ここでは、スパイラル開発のメリットとデメリットを詳しく解説します。

### スパイラル開発のメリット
**仕様変更に対応しやすい** 
スパイラル開発では、顧客とのコミュニケーションが頻繁に行われます。顧客からのフィードバックは次のサブシステム開発で取り入れることができるため、仕様変更に対応しやすくなっています。 

**高品質なソフトウェア開発が可能** 
サブシステムごとにプロトタイプを使った検証および改善を繰り返し、品質要件を満たしてからリリースするため、高品質なソフトウェアに仕上がります。 

**リスクの最小化** 
スパイラル開発では開発を繰り返しながら進めていくため、問題が発生した場合にも早期に発見して修正できます。そのため、開発におけるリスクを最小限に抑えることができます。 

### スパイラル開発のデメリット
**プロジェクトの全体像を把握しづらい** 
スパイラル開発では、最初の要件定義でウォーターフォール開発ほど明確な定義をしません。その上、サブシステムごとに開発工程を進めたり仕様やスケジュールの変更に対応するため、プロジェクトの全体像を把握しづらくなります。その結果、プロジェクトの方向性がズレていることに気づかず、サブシステムの仕様変更を実施してしまうことがあります。 

**開発のコストが高くなりがち** 
スパイラル開発では品質を重視しているため、プロトタイプが求める品質を満たせない場合には、開発工程を追加で繰り返します。また、プロトタイプ自体の開発費用もかかるため、全体的に開発コストは高くなる傾向があります。 

**顧客とのコミュニケーションの影響** 
スパイラル開発は顧客とのコミュニケーションが多い開発手法であり、特に顧客からのフィードバックを元に次のサブシステムを開発するのが特徴です。そのため、顧客とのコミュニケーションが困難である場合や要求が不明確な場合には、プロジェクトの進行に影響してしまうことがあります。

また、顧客のステークホルダーが多い場合には、レビュー時間が多く掛かったり、意見が分かれて要件が定まりづらかったりと、開発期間が長引くおそれがあります。 

# スパイラル開発の進め方
スパイラル開発では、まずシステム全体の要件定義をし、システムを複数のサブシステムに分割します。システム全体の要件定義は、ウォーターフォール開発ほど細かく定義しません。一方で、サブシステムの分割と重要度付けがなされるのが特徴です。システム全体の要件定義の後、重要度順にサブシステムの開発を進めます。

### サブシステムの分割
サブシステムの分割は、プロジェクトの目的や要件に合わせて柔軟に設計できます。サブシステムの分割方法は、主に3通りあり、ここでは旅行予約サイトを例に説明します。

### 機能に基づく分割
最も主流な分割方法です。例えば、アカウント機能、予約機能、決済機能など、機能単位でサブシステムに分割します。

### 技術に基づく分割
例えば、データベース、ウェブサーバー、ネットワーク通信など、技術的な切り分けでサブシステムに分割します。

## #ビジネスプロセスに基づく分割
例えば、検索、予約受付、予約確認、決済、店舗支払いといったビジネスプロセスの流れを元に、サブシステムに分割します。

いずれの分割方法でも、サブシステムの分割では開発の柔軟性とコストのバランスを取ることが大事です。サブシステムを細かく分割しすぎると、検収の確認や事務コストがかさんでしまいます。逆に大雑把な分割では開発の柔軟性が落ち、スパイラルモデルのメリットをうまく享受できない可能性があります。

# サブシステムの開発の流れ
サブシステムの開発は、主に下記の流れで進めます。

1. 設計
2. 開発
3. テスト
4. 評価

開発の流れはウォーターフォール開発と同様ですが、開発の対象はサブシステムに限定されます。サブシステムの成果物はプロトタイプであるため、顧客やユーザーなどに操作してもらい、さまざまな角度から評価やレビューを実施します。得られたフィードバックや改善点は次のサブシステム開発にて取り入れます。

# スパイラル開発とアジャイル開発との違い
スパイラル開発と同様の反復型の開発には、アジャイル開発があります。スパイラル開発とアジャイル開発では、分割した機能ごとに開発を進める点でも共通しています。では、この2つの開発の違いはどこにあるのでしょうか。

スパイラル開発とアジャイル開発では、開発手法の目的が異なります。スパイラル開発は、仕様変更に柔軟に対応しながらも高品質なシステムの開発をめざしています。一方、アジャイル開発は迅速な価値の提供を通じてビジネス価値を最大化することにあります。
スパイラル開発とアジャイル開発は目的が異なることで、特徴にも違いが現れます。スパイラル開発とアジャイル開発の特徴の違いを紹介します。

### リリースのタイミング
スパイラル開発とアジャイル開発の最も大きな違いは、リリースのタイミングです。サブシステムの開発でできた成果物はあくまでもプロトタイプであり、リリースはしません。一方、アジャイル開発は、分割した機能が開発できた段階でリリースします。

### プロセスの柔軟性
スパイラル開発は、設計、開発、テスト、評価の各フェーズを繰り返して開発を進めますが、フェーズの順序は一定です。一方、アジャイル開発は、顧客の要望や状況に応じてプロセスの順序や内容を柔軟に変更できるようになっています。

### プロジェクトメンバーの役割分担
スパイラル開発では、開発の各フェーズに対応するチームが専門的な役割を担当するため、メンバーの役割分担が明確に別れていることが一般的です。一方、アジャイル開発では、プロジェクトメンバー全員が柔軟に役割を変更し、プロジェクトの進行状況に応じて柔軟に対応できるようになっています。

### ドキュメンテーションの重要性
スパイラル開発では、ウォーターフォール開発ほど緻密な内容ではなくとも、開発の各フェーズでのドキュメンテーションが重視されています。一方、アジャイル開発では、動作するシステム自体を開発することが最優先であり、ドキュメンテーションは必要最小限にとどめられる傾向にあります。

### 開発チームと顧客の関係性
スパイラル開発では、顧客とのコミュニケーションが重視されているものの、顧客と開発チームの関係性は比較的フォーマルです。一方、アジャイル開発では、顧客と開発チームが密接に協力して、システム開発を進めていくことが重要視されています。

このように、スパイラル開発とアジャイル開発では開発を反復する点では共通しますが、思想が異なることでリリースのタイミングや重視する点が異なります。ただし、目的は異なるものの相反するものではないため、スパイラル開発の初期にアジャイル開発を取り入れるなど、ハイブリット型の開発もあります。


スパイラル開発は、仕様変更に対する柔軟性と高品質な開発の実現が特長の開発手法です。ウォーターフォール開発では手戻りのリスクが大きい場合や、スピードよりも品質重視でアジャイル開発は向かない場合には積極的に検討してみてはいかがでしょうか。

スパイラル開発の進め方とメリット・デメリット

新しいサービスや新機能の開発場面においては、「要件はある程度決まっているものの具体的な完成イメージを持てない」「実際に製品サービスを使ってみなければわからない」というケースがしばしば発生します。このような課題を持つ開発に適した手法が、プロトタイプ開発です。

例えば、スマートフォンがこの世に登場する前、「さまざまなアプリケーションと直感的な操作で生活を変えるディスプレイのみの携帯電話」と聞いても、どのようなものかを想像するのは難しかったでしょう。この状態では、開発者は何を作ればいいのかわからず、ユーザーはどのように評価すればいいのかわかりません。

また、Webサイトやアプリケーションでは、機能は十分でも使い勝手が悪ければユーザーには受け入れてもらえません。使い勝手が良いかどうかは、実際に使ってみなければ判断が難しいところです。完成イメージの具体化や使い勝手の評価を実施したい場合、試作品であるプロトタイプの作成が適しています。この記事では、プロトタイプ開発とはどのような手法なのか、進め方やメリット・デメリットを踏まえて解説します。

# プロトタイプ開発とは？
プロトタイプとは、試作品のことを指します。プロトタイプ開発は、完成品の開発前にプロトタイプを作成し、クライアントやユーザーからのフィードバックを得ることで仕様を固めていく手法です。プロトタイプ開発の目的は、仕様変更に伴うコストを抑えることです。プロトタイプを作ることで早い段階で必要な仕様変更に対応でき、はじめから完成品の開発を進めるウォーターフォール開発と比較して手戻りを抑えられます。

>参考：モックアップやMVP開発との違い
>プロトタイプと類似の概念として、「モックアップ」という言葉があります。モックアップとは、開発するソフトウェアやアプリの完成イメージの図であり、実際に操作することはできません。そのため、プロトタイプは、モックアップに機能が付随して試用できる状態にしたもの、と言えます。
>また、MVP (Minimum Viable Product) 開発は、最小限の機能を搭載したシステムを早期にリリースし、ユーザーの反応を検証する開発手法です。プロトタイプはあくまでも試用に使うものであり、リリースはしない点がMVP開発と異なります。

# プロトタイプ開発のメリット・デメリット
プロトタイプ開発のメリットを一言で言うと、プロトタイプの評価でフィードバックを得ることで本開発の品質を高められることです。一方デメリットとして、プロトタイプ自体の開発にコストを要することが挙げられます。メリットとデメリットをそれぞれ詳しく説明します。

### プロトタイプ開発のメリット
**・完成品のイメージを共有しやすい** 
新商品や新機能の場合、ステークホルダーそれぞれが想像している完成イメージが一致しているか確認するのは難しいことです。プロトタイプを作ることで、完成イメージを共有しやすくなります。

**・機能要件を明確にできる** 
評価者であるユーザーやクライアントは、過去に使ったことのない新しい機能や製品サービスであっても、プロトタイプを使うことで具体的にフィードバックできます。フィードバックを得られることで、計画時に機能要件が不明確な場合でも、本開発に向けて機能要件を明確化しやすくなります。

**・使い勝手を検証できる** 
プロトタイプは実際に操作できるため、使い勝手の面でも評価できます。たとえ機能が要件を満たしていても、使い勝手が悪ければユーザーやクライアントの満足度は低くなってしまいます。使い勝手を向上することで、ユーザーやクライアントの満足度を高められます。

**・技術的な課題を検証できる** 
新しい技術を搭載する際など、プロトタイプに搭載してテストすることで具体的に技術面での課題を検証できます。その結果、本開発での搭載リスクを軽減できます。

### プロトタイプ開発のデメリット
**・プロトタイプ作成に時間と費用がかかる** 
プロトタイプはメインの機能に絞って開発するものの、一定の開発工数が掛かります。あくまでも検証を目的としているため、検証が実施できる状態であり、検証には不要な部分まで作り込まない工夫が求められます。特にプロトタイプを本開発に流用しようとすると、整合性をとったり拡張性を持つ必要が出てきたりと、コストが膨らみすぎる傾向があるため注意が必要です。

**・予定よりも開発コストが膨らむリスクがある** 
プロトタイプの開発時には、仮説をベースに開発を進めます。仮説の精度が低いと開発の方向転換や大幅な修正が発生し、何度もプロトタイプを作成するといったこともあります。

# プロトタイプ開発の進め方
プロトタイプ開発では明確に定義された工程があるわけではありません。案件や開発者によって異なりますが、開発の流れは主に次の6工程になります。

1. 要件定義
2. 設計
3. プロトタイプ開発
4. 評価
5. 修正
6. 本番開発
7. リリース
それぞれの工程について説明します。

### 1. 要件定義、 2. 設計
通常の要件定義では、開発するシステムの目的から機能を具体化していきます。しかし、プロトタイプ開発では完成イメージが明確ではないため、ユーザーのニーズを元に必要な機能の仮説を立てて開発を進めます。仮説を用いているため、要件定義や設計は、精度の高さや緻密さよりも、簡潔でスピーディーに進めることが重要です。

### 3. プロトタイプ開発
設計書に基づき、プロトタイプを開発します。あくまでクライアントやユーザーからのフィードバックを目的とした試作品であるため、細部にはこだわらずに開発を進めます。メインとなる機能を中心に、実際のシステムと同様の見た目を有し、操作イメージが湧くようなプロトタイプを開発します。

### 4. 評価、 5. 修正
クライアントまたはユーザーに、作成したプロトタイプを評価してもらいます。評価のフィードバックを元に、変更や修正を実施します。必要に応じて評価および修正を繰り返すことで、品質を高めていきます。

### 6. 本開発、 7. リリース
評価結果に問題がなくなった段階で、本格的な開発に移行します。プロトタイプをメイン機能に絞って開発している場合は、システムの細部についても開発を進めます。リリース後には、システムの運用および保守を実施します。

# プロトタイピングツールとは
プロトタイピングツールとは、Webサイトやアプリケーションのプロトタイプの開発および仕様の検証を目的としたUI（ユーザーインターフェース）デザインの支援ツールです。設計したUIに簡易的な動作を設定できるため、実際に使ったときのイメージを確認できます。プロトタイピングツールは、検証に必要なレベルで動作する画面をスピーディーに作れるという点で優れています。

例えば、プロトタイピングツールで作ったログイン画面では、ユーザー名とパスワードをテキスト入力してログインボタンを押し、次の画面を表示する、ということができます。一見、完成品のように動いているように見えますがデータベースは存在しないので、パスワードのエラーチェックなどはありません。とはいえ、コーディングの工数を省いた状態でUIデザインの評価を実施できるため、開発工数の削減につながります。

プロトタイピングツールでUIデザインを固めた後は、コーディングして実装を進めます。実装時の工数削減には、ノーコードツールの活用がおすすめです。ノーコードツールの中には、プロトタイピングツールと連携して設計したUIから自動でコードを生成できるツールもあります。プロトタイピングツールとノーコードツールをうまく組み合わせることで、開発工数の削減につながります。

参考リンク
[ノーコード開発に適したプロジェクトと進め方](https://jitera.com/ja/blogs/9)

# 他の開発手法との違い
プロトタイプ開発について説明してきましたが、他の開発手法との具体的な違いはどこにあるのでしょうか。ここでは、主流の開発手法である、ウォーターフォール開発とアジャイル開発との違いについて説明します。

### ウォーターフォール開発との違い
ウォーターフォール開発は、開発工程を上流から順に一つずつ進めていく手法です。緻密な計画と文書作成により、高品質なソフトウェア開発をめざします。

ウォーターフォール開発とプロトタイプ開発は、高品質なソフトウェア開発をめざしている点で共通しています。しかし、ウォーターフォール開発は最初に要件定義を固めるため、要件が不明確な新しい製品サービスの開発には向きません。仮説をベースに要件定義をしてしまうと、手戻りのリスクが高くなるためです。ウォーターフォール開発での手戻りは大きな損失を招きます。

そのため、手戻りのリスクが高い際には、プロトタイプを使った事前の仮説検証が適しています。プロトタイプで十分に仮説検証できれば、プロジェクト開始時に要件が不明確な場合でも要件を明確化でき、最終的に高品質なソフトウェア開発が可能になります。つまり、プロトタイプ開発は、ウォーターフォール開発での手戻りのリスクを回避するための開発手法といえます。

### アジャイル開発との違い
アジャイル開発は、ユーザーの満足度を最優先し、価値のあるソフトウェアを素早く提供することを重視した開発手法です。イテレーションと言われる機能単位の小さなサイクルで開発を繰り返し、開発が完了した機能から順にリリースしていきます。

アジャイル開発とプロトタイプ開発では、リリースのタイミングとフィードバックを得るユーザーの範囲が異なります。

アジャイル開発では、いち早く市場に正式なサービスとしてリリースし、広くユーザーからのフィードバックを得ます。そしてその後も改善とリリースを繰り返します。

一方、プロトタイプ開発で作るプロトタイプは、あくまでも試用という扱いであり特定のユーザーからフィードバックを得ます。プロトタイプの段階でリリースすることはなく、改善後である本開発のサービスでリリースするのが基本です。

アジャイル開発とプロトタイプ開発は思想が相反するものではないため、アジャイル開発の初期にプロトタイプの作成が取り入れられることもあります。しかし、歴史的にプロトタイプ開発はウォーターフォール開発の手戻り回避のために取り入れられてきた背景があるため、一般的に開発手法の文脈でプロトタイプ開発という場合には、プロトタイプ作成後の本開発がウォーターフォール型であることが多いです。

>参考：β（ベータ）版とは
>プロトタイプの中には「β版」と称して、本開発サービスと同じ市場にリリースすることもあります。正式版のリリースとは異なり品質の保証はしませんが、正式版と同じ市場にリリースすることで広くユーザーからのフィードバックを得たり、ユーザーのニーズを喚起したりする効果があります。




どのようなものを開発すればよいのか明確ではないとき、プロトタイプ開発はとても有効な手段です。また、ユーザーの使い勝手が満足度に直結するソフトウェア開発においては、どの開発手法でもUIデザイン時にプロトタイプを作るのが当たり前になっています。
プロトタイプの作成コストには注意する必要がありますが、プロトタイピングツールを使うことで低コストで検証できる内容も多くあります。早い段階で完成イメージの検証や共有が必要な開発では、プロトタイプ開発の導入を検討してみてはいかがでしょうか。

プロトタイプ開発の進め方とメリット・デメリット

システム開発が終わったら、それ以上費用が発生しないわけではありません。開発したシステムを運用するには、システム保守が必要となり、システム保守をシステム開発会社へ依頼する場合は、費用が発生します。

実際に、システム開発会社へシステム保守を依頼する場合、どのような費用が発生すると想定しておけば良いのでしょうか。そこで今回は、システム保守の費用とはいったいどのようなものなのか、それぞれの費用は、どの段階でどのように見積もり、どこに発注するべきなのかについてわかりやすく解説していきます。

# システム保守費用とは
システム保守費用とは、開発システムを問題なく稼動させるために、管理や維持、顧客、トラブル対応で発生する費用がまとまったもののことをいいます。システム保守費用は、システムを長期的に運用することによって生じるため、システム開発費用の一部として見積もりを行うことが重要です。また、システム保守費用は将来的な要件に対応できるように適切な予算を確保することも忘れてはいけません。実際のシステム保守費用は、以下のような要素から構成されます。

### ソフトウェアアップデート
ソフトウェアは、最新版へとアップデートしなければ、エラーが発生し、大きなトラブルにつながってしまうことがあります。通信障害や運用トラブルを未然に防ぐためにも、ソフトウェアアップデートの運用保守費は欠かせないものとなります。

### ハードウェアメンテナンス
システム開発後は、ハードウェアのメンテナンスも必要です。たとえば、データベースに保管されているデータのバックアップやセキュリティシステムのアップデート、セキュリティリスクへの迅速な対応などがハードウェアメンテナンスの運用保守費に含まれます。

### テクニカルサポート
開発サービスにトラブルが発生した場合、非常に頼りになるのがテクニカルサポートの存在です。テクニカルサポートとは、開発システムの故障や操作方法などの技術問題に対するお問い合わせを、メールや電話、チャットなどで解決してくれる技術サポーターのことです。専任できるテクニカルサポーターの設置には、一定の費用が必要となるため、運用保守費として考慮しておきましょう。

### インフラストラクチャの維持
インフラストラクチャとは、システムの基盤や設備の要素のことをいいます。別名、インフラとも呼ばれています。インフラストラクチャにおける基盤や設備の要素とは、インターネット通信ならインターネット回線、Webサービスを稼働させるためのサーバ、サービスを安定的に運用するための体制などのことです。

インターネット回線もサーバも運用体制も、決して主軸となるものではありませんが、どれかひとつでもなくなると、システムは正常に稼働できません。そのため、システム保守においてインフラストラクチャの維持費は、なくてはならない費用となります。

### ライセンス費用
システム開発において、特許発明や特許技術を利用する場合は、ライセンス料の支払いが必要となります。システム開発をする場合は、毎月どれくらいのライセンス費用が発生するのか、事前に見積時に確認することをおすすめします。

# システム保守で発生する費用の相場とは？
一般的にシステム開発においてのシステム保守費用の金額相場は、システム開発費用の5％から15％といわれています。非常に幅のある目安ですが、15％になるケースがもっとも多いと思っておけば良いでしょう。たとえば、100万円のシステムを開発した場合、システム保守費用は年間で15万円となります。

# サービス委託の保守費用の相場
システム開発によってECサイトを構築し、サイト運営自体を委託する場合は、サービス委託の保守費用が発生します。サービス委託の保守費用の目安は、ハードウェアやソフトウェアの費用の相場の15％に、1ヵ月20万円～50万円ほどの保守費用が発生します。これらの保守費用の目安から、開発サービスにおける基本的な保守費用の概算について考えていきます。

# 開発サービスごとの保守費用の目安
自社で開発したいサービスがある場合は、次のようなシステム保守費用が発生することを想定しておきましょう。

| サービス名 | システム開発費用 | システム保守運用費用 | 合計金額（サービス委託費を含む） |
|------------|--------------|-----------------|--------------------|
| マッチングアプリ | 2,000万円 | 300万円 | 350万円 |
| ソーシャルメディアアプリ | 1,500万円 | 225万円 | 275万円 |
| AR（拡張現実）システム | 1,200万円 | 180万円 | 230万円 |
| マッチングサイト | 1,000万円 | 150万円 | 200万円 |
| ECサイト | 800万円 | 120万円 | 170万円 |
| ポータルサイト | 600万円 | 90万円 | 140万円 |
| 日時予約システム | 500万円 | 75万円 | 125万円 |
| eラーニングシステム | 400万円 | 60万円 | 110万円 |
| CMS構築 | 300万円 | 45万円 | 95万円 |

※これらのシステム開発費用やシステム保守運用費用は、システム開発会社である弊社（株式会社Jitera）が算出した費用の目安となります。システム保守費用については、保守の範囲によっても異なりますので、詳しくは見積時にご確認ください。

# システム保守費用は、どの段階で見積もり、どこに発注するべき？
システムの保守費用は、どのような段階で、どのような特徴をもった会社に発注するべきなのでしょうか。次に、システム保守費用の発注先の考え方についてご説明します。

### システム開発前の見積でチェックする
システム保守費用は、システム開発時の最初の見積段階で事前に金額を算出しておくことをおすすめします。約15％がシステム保守費用の目安であることを知っておけば、システム開発会社から不当な金額を算出されていないかをチェックできます。

もし、早いタイミングでシステムの保守費用やサービス保守費用を知りたい場合は、システム開発会社のお問い合わせから費用の相場を聞いてみても良いでしょう。

システム保守は、開発実績が豊富な会社へ依頼しよう
システム保守は、サービスの安定的な運用において、非常に大きな役割をもっている仕事です。そのため、開発実績が豊富な会社へ依頼しましょう。たとえば、弊社である株式会社Jiteraは、東証プライム企業から中小企業まで幅広い開発実績があります。

そのため、開発に対して高い知識を有しているのはもちろん、数多くのWebサービスのシステム保守を行っております。開発事例としては、顧客管理システムや営業管理システム、ECサイト、予約管理システム、ビジネスマッチングシステムなどフロントエンドから業務管理システムまで幅広く対応しているため、安心してご相談ください。


システム開発におけるシステム保守の金額の目安は、約15％になります。株式会社Jiteraでは、システム開発が初めてのお客様にもご安心いただけるように、他社の事例や最新技術を交えて、有益な選択肢を提示しつつ、要望を形に変えていく開発コンサルティングを行っています。

システム開発の外注経験がない会社様でも、お互いに齟齬がない状態でひとつずつ仕事を進めていける体制が整っておりますので、ぜひお気軽にご相談ください。


システム開発が終わったら、それ以上費用が発生しないわけではありません。開発したシステムを運用するには、システム保守が必要となり、システム保守をシステム開発会社へ依頼する場合は、費用が発生します。

システム保守で発生する費用とは？

# GPT-4の概要と特徴
GPT-4（Generative Pre-trained Transformer 4）は、OpenAIによって開発された最先端のAI言語モデルです。自然言語処理（NLP）技術を駆使して、文章の作成・理解・翻訳・要約など、人間に代わってあらゆる言語処理を自動化することができます。

旧型モデルのGPT-3.5からさらに進化し、大量のデータセットを用いた学習により、高度な文脈理解と文章生成能力を実現しました。

# ChatGPTとGPT-4の違い
ChatGPTとは、自然言語処理で高い性能を示す「言語モデル」を用いたAIチャットボットです。一方、GPT-4とは、AIチャットボットに使用される言語モデルそのものを指します。つまり、ChatGPTの基盤となっているのがGPT-4（GPT-3.5）であると考えて間違いありません。

ただし、現行のChatGPTの一般公開については、旧型のGPT-3.5を用いており、次世代モデルのGPT-4を利用するには、有料プランである「ChatGPT Plus」に加入する必要があります。

# GPT-4とGPT-3.5の比較
|   特徴   |        GPT-3.5       |         GPT-4         |
|:--------:|:------------------:|:---------------------:|
| パラメータ数  |   13.5B             |        200B+          |
| トークン数  |   2048              |          4096         |
| モデルサイズ |   3.3 GB            |        TBA            |
| 学習データ  |   インターネット全体  |        TBA            |
| ファインチューニング  |   非常に高速    |        より高速        |
| 出力の品質  |   非常に高い        |        より高い         |
| 応答時間  |   早い              |        より早い         |


GPT-4はGPT-3.5に比べ効率的なアルゴリズムを採用し、機能性や処理能力が向上しました。これにより、より高度なタスクを処理できるようになります。

### 画像・動画入力に対応したマルチモーグルAI
GPT-3.5ではテキスト入力に限定されましたが、GPT-4は画像入力や動画入力にも対応するマルチモーダルAIになります。これにより、画像認識や動画解析を含むアプリケーションへの適用が可能になる予定ですが、2023年3月時点ではまだ非公開の機能です。

### 大きく進化した処理能力
言語モデルの処理能力は、およそ単語一つ分にあたる「トークン」の処理件数を指標とします。GPT-3.5では4,000トークン程度だった処理能力が、GPT-4では最大32,000トークンまで向上し、おおよそ10倍程度の性能アップをしました。

また、文章の機微を察して入力者の感情を読み取ったり、方言を適切に読み取ったりすることも可能です。さらに、化学式や数式の複雑な問題を解いたり、ストーリー性のある創造的な文章にも富んでおり、多様なタスクへの対応ができるようになりました。

# GPT-4は自社のアプリケーションに導入できるか？
性能が向上したことで、利用者の増加が予想されるGPT-4ですが、APIを用いて自社のアプリケーションにも導入することはできるのでしょうか？

### 2023年3月時点ではアプリケーションには導入できない
2023年3月14日に発表されたばかりのGPT-4は、一部の大企業をのぞいて現時点ではまだAPI（Application Programming Interface）として利用することはできません。そのため、ChatGPTをAPIとして利用するには現行モデルであるGPT-3.5を使う必要があります。ただし、GPT-4をAPIとして利用するための[待機リスト（waitlist）](https://openai.com/waitlist/gpt-4-api)は公開されているため、こちらに登録しておくことでいち早くGPT-4のAPIを利用できるようになる可能性は高くなります。いち早く自社開発のアプリケーションにGPT-4を導入するには、早めに待機リストへの登録を済ませておきましょう。

### 将来的にはAPIを用いて導入することができる
現時点では、GPT-4のAPI導入は一部の企業に限られていますが、待機リストに参加することで、利用可能になったタイミングで既存のアプリケーションや新開発のアプリケーションにGPT-4を組み込むことが可能です。

現行のGPT-3.5とGPT-4の性能の違いは明らかであるため、既にChatGPTを導入している企業であっても、GPT-4へのアップデートは将来的に必要とされるでしょう。

# GPT-4の将来性
GPT-4を導入することで、ビジネスシーンにおいてさまざまな進化が期待されます。その将来性について確かめましょう。

### カスタマーサポートの向上
GPT-4の高度な会話機能を利用し、AIチャットボットをカスタマーサポートに活用することで、顧客からの質問に素早く正確に回答し、まるでコンシェルジュのようなパーソナライズドされた自然な会話を楽しむ未来も予想されます。

### 画像入力や動画入力による質問
現時点では、日本で画像・動画入力の機能は公開されていませんが、写真で撮影した映像を解析してチャットボットが会話を返してくれるようになるでしょう。例えば、画像をAIに解析させて面白いところを見つけさせるといったユーモアのある使い方も可能になります。

### 翻訳機能の向上
他言語での対応を予定しているGPT-4では、翻訳機能も向上するため、外国人のお客様にも母国語でスマートに回答されることが期待されます。外国人のお客さまが多く、対応に時間がかかっていた企業にGPT-4を導入することで効率的でグローバルな接客が可能になります。

### 倫理的な問題と規制が課題である
様々な機能で進化を続けるGPT-4は、倫理的な問題や規制について議論され続けることが予想されます。プライバシーへの配慮、個人情報保護、捏造した情報の拡散など、GPT-4を含めた大規模言語モデルにはさまざまなリスクが潜んでいるからです。

そのため、企業や開発者はGPT-4の導入にあたって、社会的な責任を持ち、適切な倫理規範やガイドラインを遵守することが求められる可能性が高くなります。また、政府や業界団体による規制策や、AI技術に関する国際的な取り決めについても議論されるでしょう。

# 将来的にGPT-4を導入してビジネスは進化する
GPT-4は旧型のGPT-3.5に比べて自然言語処理の能力が飛躍的に進化しています。2023年3月時点ではGPT-4のAPIは一部の企業に限られていますが、将来的にはAPIの導入によって高機能な双方向コミュニケーションをローコストで実現させることでしょう。そのため、GPT-4の最新情報をチェックし、いち早く導入できるように準備しておくことが重要です。

一方で、技術の進化は、歴史を見ても倫理的な問題と規制が常に論じられています。GPT-4を導入する企業や開発者はその点も考慮しなくてはならないでしょう。現時点では、APIの導入は順番待ちになっていますが、いち早く取り入れた企業から劇的な成長を見せる可能性をGPT-4は秘めています。

# GPT-4を導入する手順
GPT-4をAPIで導入する手順は、以下のようになります。ただし、現時点ではGPT-4がリリースされておらず、GPT-3が利用可能です。GPT-4がリリースされた際にも、手順は類似していると予想されます。

### OpenAI APIキーの取得
まず、OpenAIのウェブサイトにアクセスし、APIキーを取得するためにアカウントを作成します。登録後、APIキーが発行されるため、それをメモしておいてください。

### 開発環境の準備
使用するプログラミング言語や開発環境に合わせて、必要なライブラリやSDKをインストールします。OpenAIはPython用のライブラリを提供していますが、他の言語を使用する場合は、適切なライブラリを見つけるか、直接HTTPリクエストを利用する必要があります。

### APIリクエストの作成
GPT-4（GPT-3の場合も同様）を利用するために、APIリクエストを作成する必要があります。以下はPythonでOpenAI APIを利用するためのコード例です。
 ```
import openai

\# APIキーの設定
openai.api_key = "your_api_key"

\# リクエストの設定
prompt = "プロンプトに入力するテキスト"
response = openai.Completion.create(
    engine="davinci-codex",  # GPT-4がリリースされた際には、適切なエンジン名に変更する
    prompt=prompt,
    max_tokens=100,
    n=1,
    stop=None,
    temperature=1,
)

\# 結果の取得
generated_text = response.choices[0].text
print(generated_text)
 ```

このコード例では、openaiライブラリをインポートし、APIキーを設定しています。リクエストに必要なパラメータ（プロンプト、最大トークン数、生成する文章の数など）を設定してAPIリクエストを送信し、結果を取得しています。

### アプリケーションへの組み込み
APIリクエストを作成したら、それをアプリケーションに組み込むことができます。例えば、WebアプリケーションでGPT-4を利用する場合は、上記のコードをバックエンドに組み込み、フロントエンドからのリクエストに応じて生成されたテキストを返すように設定します。

### テストとデバッグ
アプリケーションにGPT-4を組み込んだら、適切に機能しているかテストし、必要に応じてデバッグを行います。GPT-4の挙動を調整するために、APIリクエストのパラメータを変更することができます。例えば、temperatureパラメータを調整することで、生成されるテキストのランダム性を制御することができます。

### 本番環境へのデプロイ
テストとデバッグが完了したら、アプリケーションを本番環境にデプロイします。デプロイ方法はアプリケーションの種類や使用するインフラストラクチャによって異なりますが、一般的には、ソースコードをリポジトリにプッシュし、本番環境に適用するプロセスを経ることが一般的です。

### パフォーマンスのモニタリングと最適化
本番環境でのGPT-4のパフォーマンスをモニタリングし、必要に応じて最適化を行います。APIリクエストの数やレスポンスタイムを監視し、エラーや遅延が発生した場合は原因を特定し、改善策を実施します。また、APIのコストを抑えるために、リクエストの頻度やトークン数を調整することも検討できます。

### 継続的な改善とアップデート
アプリケーションの使用状況やユーザーフィードバックを収集し、GPT-4の利用方法やパラメータを継続的に改善していきます。また、OpenAIから新しいバージョンのGPTやAPIがリリースされた際には、アップデートを適用し、最新の機能や改善点を取り入れることが重要です。


これらの手順を経て、GPT-4（現時点ではGPT-3）をAPIを通じてアプリケーションに導入することができます。ただし、各プロジェクトやアプリケーションの要件に応じて、手順の詳細や実装方法は異なる場合がありますので、適切な対応が必要です



GPT-4（Generative Pre-trained Transformer 4）は、OpenAIによって開発された最先端のAI言語モデルです。自然言語処理（NLP）技術を駆使して、文章の作成・理解・翻訳・要約など、人間に代わってあらゆる言語処理を自動化することができます。

GPT-4とは？ 自社開発のアプリケーションに導入することはできる？

Webサービスの提供方法が変化を迎えています。スマートフォンや5G通信の普及により、場所や時間を問わず情報にアクセスできるようになりました。それによって、消費者へのアプローチもアプリケーションなどの伴走型へシフトしています。そのため、Webサービスの提供を行う上でクラウドの利用は不可欠です。

総務省が公表している「令和3年版 情報通信白書」※1によると、クラウドを利用している企業の割合は68.7%に上り、年々増加傾向にあります。これを受けて、クラウド環境で利用することを前提としたクラウドネイティブなアプリケーション開発が求められるようになりました。

本記事では、クラウドネイティブについて活用事例やメリットまでを詳しく解説します。最後まで読むことで今消費者に求められるWebサービスを提供する方法を知ることができます。

# クラウドネイティブとは？ 
クラウドネイティブとは、クラウド環境下において最適化されたシステムを提供することによって、ビジネス上の課題を解決することです。CNCF（クラウドネイティブコンピューティングファウンデーション）が定義したもので、クラウドサービスを利用することによって得られるメリットを最大限活用したシステムを開発する考え方です。そのため、クラウドリフトのような自社サーバーなどを利用したオンプレミスの状態にあるシステムを、クラウド上に移し替えるだけでは、クラウドネイティブとはいえません。

### クラウドネイティブが必要とされる背景
従来のシステム開発においては、これまで手作業で行われてきたものをシステム化し生産性を高めるものが求められていましたが、近年では買い切り型のサービスから、継続的にサービス提供を行う伴走型に移行しつつあります。さらに、クライアントのニーズが多様化し、その移り変わりも速いため、迅速にニーズに対応したシステム開発が求められています。

このような状況の変化を受け、機動性の高い開発インフラを提供するためにクラウドネイティブが注目されています。それと同時にクラウドネイティブと親和性の高い開発手法として挙げられているのが、アジャイル開発やDevOpsです。

クライアントのニーズに合わせた柔軟かつ迅速に開発工程を分割して進めるアジャイル開発や、開発サイドと運用サイドの対立構造を改善し無駄がなく素早い開発を行うDevOpsは、クラウドネイティブにおけるシステム開発では一般的です。

### 従来のクラウドファーストとの違い
クラウドサービスが登場して間もない頃に生まれた、オンプレミスよりもクラウド環境を利用したアプリケーション開発を第一とするという考え方がクラウドファーストです。クラウド環境を利用することで物理的なサーバーを利用するオンプレミスよりもコストが抑えられるため、クラウドファーストの考え方は普及していきました。行政のシステム開発においても、2018年にこのクラウドファーストを基にした「クラウド・バイ・デフォルト原則」が提唱されています。※2

その後、クラウド環境を利用したサービスが一般的となり、クラウド環境下でアプリケーションを搭載する際に最適化を図ることが追求される中で登場したのが、クラウドネイティブという考え方です。クラウドファーストやクラウド・バイ・デフォルトの延長線上にクラウドネイティブがあります。

# クラウドネイティブを取り入れるメリット 
### クライアントの要望に柔軟かつ迅速に対応することができる
クラウドネイティブでは、アプリケーションを適切に分割し、小さい単位のマイクロサービスとして開発し、コンテナ化を行います。
これによって、システム改修やアップデートを細やかに行うことが可能です。また、システム改修を行う際にもサービス全体を停止することなく実施することが可能です。

近年ではWebやスマホのアプリケーションの活用が増えており、利用者が増えるほど頻繁な更新が求められます。クラウドネイティブでは、分割されたアプリケーションから、必要な部分だけを改修することができるため、クライアントの要望に柔軟かつ迅速に対応することができます。

### スケーラビリティを最大限活用できる
クラウド環境下では使用規模に合わせたスケールアップ・ダウンを容易に行うことができます。そのため、開発したアプリケーションの利用人数の増減などといった事態にも柔軟に対応することが可能です。また、突然アプリケーションやサービスを終了することとなった場合であっても、クラウドの契約を終了するだけで対応を完了させることができます。

### 自社インフラを必要とせずコスト削減効果が期待できる
クラウドネイティブであれば、自社サーバーを準備する必要がないため、初期費用のコストカットが可能です。ハードウェアの保守切れやサーバーへの負荷を考慮する必要もありません。また、ランニングコストにおいてもクラウドサービスは従量課金制を採用していることが多く、システムを立ち上げたばかりの頃は利用量も少ないため、費用を抑えることができます。サービスを終了することとなった場合であっても、使用しなくなったサーバーを余剰資産として抱えておく必要もありません。

# クラウドネイティブの活用事例 
実際にクラウドネイティブを活用することでどのような業務改善がなされたのか、実際の活用事例を2つ紹介します。

### 事例① KYB株式会社
四輪車や二輪車のショックアブソーバーなどの製品を提供するKYB株式会社では2018年にクラウドネイティブの予知保全システムを稼働させ、オンプレミス環境と比べて97%のコストカットに成功しています。

工場などの設備機器の予知保全担当者のメンテナンス作業負担軽減を目的として、設備機器に取り付けたセンサーからデータを収集・分析し、分析データを現場の予知保全担当者に通知する仕組みを構築するにあたってクラウドの導入を行いました。工場側の端末で一次判定をする短期の故障判定と、クラウド側で最終判定を行う長期の故障判定を組み合わせた仕組みを構築し、この仕組みをクラウドのスケーラビリティを活かして他の工程にも応用しています。

また、クラウド上でのシステム開発のため耐障害性も担保することができました。

### 事例② 株式会社Quick
株式会社Quickは、1971年の創業以来、日本経済新聞社グループの金融情報サービス会社として、証券・金融市場で活用されるマーケット情報を発信しています。

同社は2018年にオンプレミス環境で構築してきた株価配信サービスをクラウドネイティブなシステムに移行。これによってサーバーコストを60%、ハードウェアおよびソフトウェアの保守コストを70%削減することに成功しました。

機密性、可用性が重要視される金融情報の特性上、同社では長らくオンプレミス環境でシステム運用を行っていました。しかし、既存のサーバーの保守契約期間が終了を迎え、リプレースに多額のコストがかかることからクラウドへの移行を開始。サーバー約1,500台分をクラウド環境へ移行し、運用コストを大きく抑えることに成功しました。

また、従来はシステム運用と開発部門を分けていたのが、運用負荷が低減したことによってシステム運用を開発部門に集約することができるようになりました。開発と運用の一体化により、DevOpsが実現され、自由度の高いシステムマネジメントが可能となっています。

# JITERAで実現するクラウドネイティブ
クラウドネイティブは既に多くの企業で導入され、ニーズに柔軟かつ迅速に対応することができ、コストを抑えることも可能であるため、クライアントが高い満足度を得ることができます。その反面、クラウドネイティブなシステム開発を行うには、クライアントのニーズや状況の変化に素早く対応する必要があります。一般的なシステム開発の速度ではスピード不足で、時機を逸してしまうことも少なくありません。

Jiteraでは、複雑なロジックが必要ないコードを自動化して書く独自の開発プラットフォームを開発。これによって、1年半かかると想定されていたシステム開発を8か月で完成させた事例※3もあります。「ソフトウェア開発の次の時代を創る」をミッションに掲げるJITERAで、消費者に求められる新しいクラウドネイティブなWebサービス開発を行ってみませんか。

＜参考＞ 
※1　総務省　「令和3年版情報通信白書」 
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/html/nd242140.html 
※2　各府省情報化統括責任者（CIO）連絡会議決定「政府情報システムにおけるクラウドサービスの活用に係る基本方針」 
https://cio.go.jp/sites/default/files/uploads/documents/cloud_policy_20210330.pdf 
※3　JITERA Works 
東急リゾーツ＆ステイ株式会社 
https://jitera.com/ja/works/1 
AWS活用事例　KYB株式会社 
https://aws.amazon.com/jp/solutions/case-studies/kyb-ctc/?did=cr_card&trk=cr_card 
AWS活用事例　株式会社Quick 
https://aws.amazon.com/jp/solutions/case-studies/quick/?did=cr_card&trk=cr_card

クラウドネイティブによる開発のメリット

令和2年4月1日から改正民法が施行されました。これによって受託開発（請負契約）における受託者の責任が瑕疵担保責任保険から、契約不適合責任に変更されました。どちらもユーザーに対して負う責任であることに変わりはないのですが、両者はどのような違いがあるのか、しっかり理解できている人は多くありません。この点をしっかり押さえておかないと、システム開発を依頼する際にトラブルが起きてしまう可能性があります。

# 瑕疵担保責任と契約不適合責任の違い
令和2年に改正民法が施行されるまでは、受託開発もSES（準委任契約）も瑕疵担保責任を負うこととなっていました。ここでは瑕疵担保責任と契約不適合責任の4つの違いと、SESでベンダーが負う責任について解説します。

# 瑕疵担保責任と契約不適合責任の4つの違い
システム開発における受託開発（請負契約）で、完成したシステムに不備があった場合、改正前民法でも次の3点が認められていました。

・修補請求権 
・損害賠償請求権 
・契約解除権 
これを踏まえ、改正民法では次の4つの権利が認められています。（民法第636条）
・ 追完請求権 
・ 代金減額請求権 
・ 債務不履行による損害賠償請求権 
・ 債務不履行による契約解除権 
また、システム開発案件における両者の違いを表にすると次の通りです。 
![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/differenceofcontract01.png)

契約不適合責任と瑕疵担保責任の責任内容を比較すると、契約不適合責任に改正されたことによって、ユーザー（買主）側の権利が拡大しています。例えば、瑕疵担保責任では納品されたシステムに隠れた瑕疵があった場合に限って、修補請求権が認められていました。

しかし、契約不適合責任では、契約内容に不適合な不備を対象として、履行の追完請求や代金の減額請求など請求できる権利の選択肢が増えました。他にも、責任追及することができる期間が、引き渡し時点からではなく不適合を知った時から1年間とユーザー側が請求しやすく拡充されています。

### SES（準委任契約）に契約不適合責任はない？
システム開発では受託開発だけでなく、SES（準委任契約）という契約類型もよく活用されます。SESは受託開発と異なり、成果物の納品ではなく委託された作業の遂行に対して報酬が支払われる契約形式です。そして、SESには請負契約とは異なり、ベンダーが負うのは契約不適合責任ではなく瑕疵担保責任です。

SESと受託開発の違いについて詳しく知りたい場合は、こちらの過去記事もチェックしてみてください。
[準委任契（SES）と受託開発（請負契約）の違いとは？システム開発に最適な契約形態](https://jitera.com/ja/blogs/4) 

SESには「成果完成型」（民法第648条の2第1項）と「履行割合型」（民法第648条第2項）の2種類があります。システム開発を目的とするSESでは作業の結果として達成された成果に対して報酬が支払われることから、多くが成果完成型に該当します。そのため、ベンダー側はSESであってもシステムを納品することで報酬が発生し、納品することができなければ、ユーザーに対して債務不履行責任を負うことが必要です。

さらに、SESには善管注意義務（民法第644条）を負い、システム開発に携わるものとして当然必要とされるスキルや知識をもって業務を遂行する義務を果たさなければなりません。SESでは契約不適合責任を負わないからという理由で、ベンダー側が果たすべき責任が実質的に軽くなるというわけではありません。 

# システム開発をめぐるトラブルの事例
契約不適合責任や瑕疵担保責任の概要について分かったところで、本章では具体的にどのような場合にその責任が認められてきたのか、2つの事例について解説します。

## 契約の目的に照らして瑕疵があると判断された事例（東京地裁平成16年12月22日判決）

### 概要
ベンダーに販売管理システムの開発を委託したが納入されたシステムには不具合があり、ユーザーは契約目的が達成できないため、契約解除と損害賠償請求をしたが、ベンダーがこれを拒否して訴訟になった

### 不具合の内容
移行データを使用した一括在庫引当て処理に30分以上の時間を要し業務が進まず、その間他端末においても受注登録処理が行えない

排他制御の問題で、商品マスタの登録データを開いていると、商品マスタを使用するすべてのプログラムの処理が止まる

### 判決
一括在庫引当て処理に時間を要することも、排他制御についても契約の内容に適合するものといえず、瑕疵に該当する

東京地裁平成16年12月22日判決では、販売管理システムの受託開発において納入されたシステムが契約の内容に適合するものといえず、契約目的を達成することができない瑕疵に該当すると判断されました。本判例では、「一括在庫引当て処理の速度」や「排他制御」については、要件定義に含まれていません。

つまり、要件定義をベースに考えれば開発されたシステムは、その内容を満たしていたことになります。しかし、判決では要件定義ではなくユーザーのシステム開発における目的に照らして、瑕疵の判断がされました。

## ユーザーの協力義務違反が認められた事例（札幌高等裁判所平成29年8月31日判決）

### 概要
病院情報システムの導入のため、入札を行い落札業者とプロジェクトを開始したが、ユーザーからの仕様追加が続いたため、納期遅延及び不具合が発生し開発は頓挫。ユーザーから契約解除を申し出、訴訟に発展

### 経緯
当初予定されていた仕様の確定日を過ぎてもユーザーからの仕様追加は続いた

仕様確定（仕様凍結）合意を行った後にも、ユーザーからの追加要求があった

### 判決
ユーザーが仕様凍結合意に反して大量の追加要望を出したことによって本件システム開発が遅延した、としてユーザーの協力義務違反を認めた

札幌高等裁判所平成29年8月31日判決では、ユーザーの協力義務違反を認め、ベンダーに対して損害賠償の支払いを命じました。
本判例では、仕様確定後に多くの追加要求が出されるなど、プロジェクトを進めるにあたってユーザーの協力義務が全うされていないと判断されています。このように、開発を行うベンダーに義務があるのは当然ですが、あくまで契約関係であるためユーザーにも一定の協力義務は存在します。

# リスク回避のために契約書に盛り込むポイント
システム開発におけるトラブルは一定数起こりますが、トラブルに巻き込まれるのは誰しも避けたいはず。そこで、本章ではトラブルに巻き込まれるリスクを回避するために記載しておくとよい内容について紹介します。

### 契約の前提条件について
瑕疵担保責任から契約不適合責任へ改正されたことで、前章で紹介した判例にもあるようにシステムに瑕疵があるかどうかよりも、成果物が契約の内容や目的に適合するかどうかがポイントとなる可能性があります。そこで、契約書には業務範囲や成果物の完成基準、納入期日、システム環境などを可能な限り詳細に記載しておくとよいでしょう。

### 仕様変更等の対応方法について
仕様を確定し開発段階に入ってから見落としが判明し、どうしても仕様変更をしなければならない場合も一定存在します。そのような場合にユーザーとベンダーでどのように対応をしていくのか予め契約書に盛り込んでおくと、その後の対応もスムーズです。仕様変更や仕様追加を行う際の進め方や費用負担などに関する規定を、可能な範囲で記載しておくとよいでしょう。

# スムーズに業務を進めるための打ち合わせ内容
ベンダーとの打ち合わせにおいて何を伝えればよいのか迷う方も多いでしょう。本章では、実際にシステム開発を行う上で、どのように打ち合わせを行えばよいのかについて解説します。

### システムを開発する目的を明確に伝える
システム開発を行う上で、ユーザー側が最も伝えるべきことはシステム開発を行う目的です。何のためにシステムを導入したいのかが不鮮明だとベンダーも提案が行いにくく、意思疎通ができないまま契約へ向かってしまいます。そのため、どのような機能を実装しどのように業務効率化を図りたいのか社内でまとめておくのがよいでしょう。RFP（見積もり提案書）を作成しておくのもおすすめです。

### 仕様変更や追加の可能性がある場合は事前に伝える
どうしても開発過程で仕様の変更や追加が発生する可能性がある場合は、事前に伝えておくことがおすすめです。この時、どの部分がどのように追加・変更される可能性があり、いつまでに固まるのかについてできるだけ詳細にベンダーに伝えるようにしましょう。
これによって、ベンダーも開発スケジュールを事前に調整して提案を行うことができるため、追加費用やトラブルが発生しにくくなります。 

今回はシステム開発における瑕疵担保責任と契約不適合責任の違いについて解説しました。株式会社Jiteraでは、SES（準委任契約）を中心にシステム開発を承っています。SESでは契約不適合責任ではなく、瑕疵担保責任が発生しますが、システム開発をするにあたって負う責任は、本記事で解説したように大きな差はありません。

問い合わせフォームに入力をいただければ、簡単な質問に答えるだけで開発したいシステムの種類や、実装する機能までをおおまかに決めた上で見積もり依頼ができます。そのため、作業範囲や納期をある程度明確にした状態で打ち合わせを開始することが可能です。Jiteraでは独自の開発自動化プラットフォームを有しており、今までにないコストと納期でシステム開発を行うことができます。今までにないシステム開発体験をしてみませんか。まずは以下のお見積もり入力フォームからお試しください。

システム開発における契約不適合責任・瑕疵担保責任との違いについて解説

システム開発のプロジェクトを進める場合、内製化・外注化でどちらにするべきかが決まらず、困っていないでしょうか？

内製化や外注化については、そのプロジェクトでどのようなシステム開発をしたいのかで決まってきます。システム開発の内製化・外注化のどちらにもメリットがあり、プロジェクトの進め方によっては失敗に終わってしまうこともあります。そこで今回は、システム開発を内製化・外注化するメリットや代表的な失敗の要因についてわかりやすく解説していきます。

# システム開発を内製するメリット
### 社内のスキルアップにつながる
システム開発を内製化すると、要件定義や開発、保守、運用をすべて自社でおこなうため、自然と社内のスキルアップにつながるメリットがあります。ヒューマンスキルやコンセプト設計スキル、テクニカルスキルなど、あらゆる方面のスキルの習得・向上が可能となり、意見を社員同士で交わしやすくなるため、新しいアイデアや発見が見つかりやすい風通しの良い環境へと変わっていくでしょう。

### プロジェクトをコントロールしやすい
システム開発を内製化する場合、プロジェクトメンバーは、社内の事情をよく知るメンバーで構成されます。そのため、会社内でどのように使われるのか、具体的なイメージをもったうえで、システム開発できるメリットがあります。また、システム開発を外注化するよりも、内製化した方が機能追加や基本的な画面構成の変更もしやすいため、プロジェクトをコントロールしやすいです。

### コスト削減
システム開発の内製化・外注化でもっとも大きいメリットは、大幅にコストを削減できることです。プログラミングに対して専門性の高い社員がいる、または比較的簡単にシステム開発できるものについては、コストの観点からシステム開発を内製化することをおすすめします。

# システム開発を内製するにあたって生じる失敗の要因
### スキル不足
システム開発メンバーの開発スキルが不足していると、開発プロジェクトが失敗に終わる可能性が高くなります。たとえば、開発メンバーに古い開発の知識や簡易的なレベルの開発経験しかない場合、スキル不足で開発が進みません。また、彼は雰囲気的に開発ができそうだからプロジェクトに入れたといった理由でチーム編成がされている場合も失敗につながる可能性が高いので注意が必要です。

### 開発時間がなかった
いつもの仕事と同時並行で開発プロジェクトを進めてしまうと、開発時間がとれずに、失敗に終わる可能性が高くなります。社内に高いスキルを有するエンジニアがいても、開発時間がなければプロジェクトは進められません。そのため、システム開発の内製化を考える会社様は、開発時間があるのかについても気にした方が良いでしょう。

### コミュニケーション不足になる
システム開発を内製化する場合、社内の人だから分かるだろうと、コミュニケーションが不足し、要件定義のレベルが非常に低くなる要因となっています。社内での会話は気が緩みやすく、プロジェクトの中心メンバーとなる人物がいないと今ひとつ有意義な会話につながらないケースが多いため、注意が必要です。

# システム開発を外注するメリット
### 複雑な開発に対応できる
システム開発会社で働くメンバーは、開発の専門家です。そのため、どれだけ要件定義や開発方法が複雑でも、過去の経験や会社独自のノウハウを使うことで、理想とするシステムを開発できるメリットがあります。もし、ハイスキルなシステム開発会社へ外注化したい場合は、開発実績の多いシニアメンバーが中心となって働く会社へ相談した方が問題なくプロジェクトを進めやすいです。

### 短期間の効率的な開発が可能になる
システム開発を外注化すれば、社内にハイレベルなエンジニアがいなくても、短時間で効率的に開発プロジェクトを進められるメリットがあります。たとえば、開発に必要な足りない言語の勉強やコードツールの基本的な使い方についてゼロから学んでいたら、どれだけ時間があっても足りません。しかし、プロジェクトのすべてを外注化してしまえば、時間の無駄が大幅になくなり、プロジェクトをスタートできます。

# システム開発を外注するにあたって生じる失敗の要因
### コミュニケーションが不足する
システム開発会社によっては、成果物が完成するまでほとんどないことがあります。この場合、成果物が想像していたものと違ったという事態になりかねません。

そのような事態にならないためには、コミュニケーションツールで気軽に質問に答えてくれる会社へ相談することで意思疎通による問題を簡単に解消できます。他にも、できる範囲で定期的に意見を述べておくと早めに失敗に気づけるため、しっかりと進捗状況を報告してもらいましょう。

### 開発物が明確に決まっていない
どのようなものを開発したいのか、開発物が明確に決まっていないと、システム開発会社も開発できません。解決したい課題や画面のイメージが明確なだけでは、システム開発を外注化したとしても、失敗に終わる可能性が高いです。実際に依頼するのなら、どのような操作性でどういったデータと連携させたいのか、必要なデータ項目や利用すべき計算式は何かといったことをしっかりと伝えましょう。

### 費用が途中で大きくなってしまう
システム開発会社によっては、仕事の途中で開発費用が大きくなってしまうことがあります。1000万円でできると聞いていたが、合計3000万円になってしまったということは決して珍しいことではありません。想像以上に開発費用を上乗せされて、費用を支払えず、大きなトラブルにつなげないためにも、予算のコントロールは徹底しましょう。

# システム開発を外注化するならJiteraへ相談しよう
社内エンジニアの組織形成が弱い場合、システム開発はどうしても外注化せざるを得ません。もし、システムを外注する際にどのような準備をしておけば、スムーズにいくかについては、弊社のコンテンツの[「システム開発に外注を取り入れる際の社内準備」](https://jitera.com/ja/blogs/10)を参考にしてください。

また、システム開発会社へ開発プロジェクトの外注化をご検討されているのなら、ハイスキルなグローバル人材が働く株式会社Jiteraへ開発について相談してみませんか。弊社は、システム開発に着手する前に、お客様目線に立った丁寧なヒアリングとデザインデータを有効利用した提案を強みとする会社です。そのため、ITに詳しくない方でも安心して開発プロジェクトを外注化できます。

プロフェッショナリズムがある開発経験の多いシニアメンバーが要件定義から運用まですべてサポートします。


システム開発のプロジェクトを進める場合、内製化・外注化でどちらにするべきかが決まらず、困っていないでしょうか？ 内製化や外注化については、そのプロジェクトでどのようなシステム開発をしたいのかで決まってきます。システム開発の内製化・外注化のどちらにもメリットがあり、プロジェクトの進め方によっては失敗に終わってしまうこともあります。そこで今回は、システム開発を内製化・外注化するメリットや代表的な失敗の要因についてわかりやすく解説していきます。

システム開発は内製？ 外注？ それぞれのメリットと失敗例

「ユーザーの利便性が高いシステムを開発して、新規顧客を増やしたい」

スマートファンの普及やインターネット環境の整備が進む中で、システムを活用して効率的に集客したいと考える方は多いでしょう。しかし、システム開発の経験が乏しいとどのようなシステムがユーザーに求められているのか、完璧に把握することは至難の業です。とはいえ、必要と思われる機能を全て実装してしまうと、コストが膨らむ上にユーザーにとって使いにくいシステムになってしまいます。その中で有用とされるのがリーン顧客開発です。

本記事では、リーン顧客開発の概要や手法とそのメリットを紹介。さらに、リーン顧客開発をさらに効果的に実行するための方法まで解説します。最後まで読むことで、新規顧客の獲得に役立つシステム開発を行うことができるようになります。

# リーン顧客開発とは
リーン顧客開発とは、「lean」にちなみ、無駄を省いた必要最小限でスタートアップを行い、市場からのフィードバックを受けて改善を重ねることで、ユーザーのニーズを満たす事業や製品を作り上げ、新規顧客の開発や利益の最大化を目指す考え方です。徹底的に無駄を省いて常に改善を続ける「トヨタ生産方式」を基に、アメリカで提唱されました。単なるコストカットを図るものではなく、最小限の経営資源で利益や顧客開発効果を最大化することを目指すものです。

システム開発においては、まずは小さくリリースしてユーザーの反応を確かめながら素早く細かな改善を加えていくことで、無駄なく利便性の高いシステムを構築する手法として活用されています。

# アジャイル開発との違い
リーン顧客開発と類似する開発手法としてアジャイル開発が挙げられます。アジャイル開発とは、システム開発の工程を小さなタスクに切り分けて、イテレーションと呼ばれる短い期間内で所定のタスクをこなし、各機能を少しずつテスト・実装していく開発手法です。

両者の違いは目的にあります。リーン顧客開発では名前の通り、「顧客開発」を目的としており、市場からのフィードバックを基に改良を加えた結果、新たな顧客・市場の開発にどのくらい貢献したか、利益をどれだけ上げることができたかに着目します。一方、アジャイル開発では「製品開発」を目的とし、短期間の開発・設計を繰り返して機能を実装しながらユーザーにとってより良いシステムを完成させるのがゴールです。ただし、両者は短いサイクルでシステムに改良を加え、リリースをするという点で親和性があります。

# リーン顧客開発のプロセス
リーン顧客開発は顧客開発モデルの一つに該当し、先に定めたターゲットに合うシステム開発をする「マーケットイン」ではなく、先に開発するシステムを決める「プロダクトアウト」に属する手法です。ただし、単に作って売るだけではなく、プロダクト開発の過程でユーザーのニーズを検証しながら進めていくのがリーン顧客開発の特徴です。リーン顧客開発を進めていく上での具体的なプロセスを紹介します。

### 1.仮説
システムを開発する前に、どのようなシステムが必要なのか仮説を立てることが必要です。プロダクトアウトといっても、誰にも求められないシステムを作って良いわけではありません。
幅広く情報収集を行い、開発したシステムによって売り上げが上がるかどうか、開発したシステムを用いた事業に拡張性があるかについて仮説を立てます。アイデアを検討し、ターゲットとする顧客のニーズを理解・確認するフェーズです。

### 2. 構築
立てた仮説を確かめるために、必要最小限の機能だけを実装した試作品としてMVPを構築します。MVPとは、「Minimum Viable product」の略で、仮説を確認するのに足る最小限の機能を搭載したものです。仮説が誤っている場合もあり、そのリカバリーが必要なことも踏まえてMVPは最小限のコストで短期間のうちに開発します。短期間で開発することで、早期に仮説検証ができるため改善を素早く行うことが可能になります。素早くサイクルを回すことで、競合他社より先に製品をリリースすることが可能です。

### 3. 検証
MVPをターゲット層として考える顧客に使用してもらい、フィードバックを得ます。ここで顧客の生の声からさらにニーズを深堀りします。フィードバックをもらう顧客は大勢いる必要はありません。顧客を増やせば多くのニーズを調査できますが、意見に優先順位をつけるのが難しくなる上に検証に要する時間が膨大になってしまうためです。そのためにも、ターゲット層を事前に明確にし、ズレのない顧客に使用してもらうよう選定することが大切です。

### 4. 学習
検証結果を踏まえMVPの改善点を探します。検証で得られた結果と最初に建てた仮説のズレなどから次の課題を洗い出し、どのように改善していくかを意思決定します。この4つのステップを繰り返すことで、顧客が求めるシステムを開発していくのがリーン顧客開発です。

# リーン顧客開発の3つの特徴
### 生産性の向上
リーン顧客開発では、無駄を省く考え方が採用されているため、生産性を高めることができます。最初から多くの機能を搭載したシステムを開発せず、仮説を実証するための最小限にとどめたMVPを開発し、顧客の声を基に次のMVPを開発していくといったステップを踏むため、作業工数や開発期間の無駄を削減することが可能です。
開発期間の短縮は、競合他社よりも先に新たなシステムを市場にリリースするために必要不可欠です。

### 新規事業の創出
リーン顧客開発は、最小限のコストで最初のMVPを開発するため、新規事業の立ち上げにも有効です。一般的なプロダクトアウトの考え方では、先に製品を完成させて市場へリリースします。そのため、製品の開発期間やコストが膨大に必要です。リリースした製品がユーザーに受け入れられなければ、そこまでにかかったコストは全て水の泡です。しかし、リーン顧客開発では、最小限のコストでMVPをリリースし、ユーザーの反応を確認することで、仮にユーザーの反応が悪くても大きなダメージを負うことはありません。その上、ユーザーの反応に合わせて改善を施せば、売れる商品へ転換することも可能です。このように、リーン顧客開発では最小限のコストからシステムや製品を試すことができるため、スタートアップに適しています。

### ユーザー満足度の上昇
リーン顧客開発は顧客満足度を向上させることにも適しています。ユーザーのフィードバックを基に製品の改良を行うため、改良が加えられる度にユーザー満足度が向上します。また、リーン顧客開発によって生産効率が上がることで、各スタッフの時間やプロジェクト予算に余裕ができるため、さらに高品質な製品を作り上げることが可能です。リーン顧客開発は、ユーザー満足度の高いシステムや製品を開発することができるため、新規顧客の獲得や売上の向上につながります。

# リーン顧客開発で外部発注を取り入れるメリット
新規顧客の獲得や売上の向上に寄与するリーン顧客開発ですが、各工程においてシステム開発会社へ外部発注を行うことで、より効率化することができます。主なメリットは次の2点です。

### MVPのリリースが早期に行える
リーン顧客開発では最初のMVPをいかに早くリリースするかが重要です。MVPを先に市場へリリースすることで競合他社に対して優位性を確保することができるためです。MVPの早期リリースにおいては、仮説と構築のステップを経る必要があります。システム開発会社とタッグを組むことで、仮説を立てる際にはシステム開発会社の豊富な実績からユーザーのニーズを素早く調査・検討することが可能です。同様に、構築のフローにおいては仮説の段階で立てられたユーザーニーズを満たすMVPを速やかに開発することができます。
システム開発会社へ依頼をすることで、MVPを競合他社に先駆けて市場へリリースすることが可能になるため、新規顧客の獲得に結び付けることができます。

### 検証から改善までのサイクルが早められる
リーン顧客開発ではMVPをリリースした後に、ユーザーからのフィードバックを踏まえた改良も重要です。フィードバックを受けて素早く改良を加えられなければ、ユーザーの満足度を高めることはできないでしょう。システム開発会社へ開発を依頼することで、積み上げたシステム開発ノウハウを活かして、ユーザーのフィードバックの裏側にある真のニーズをくみ取ることができます。また、フィードバックを踏まえたシステム改良も迅速に行い、アップデート版の早期リリースが可能になります。

# Jiteraで達成する新しいリーン顧客開発
今回はリーン顧客開発について解説をしました。リーン顧客開発はユーザーにとって必要最小限の機能を実装するところから開発が始まるため、スタートアップや新たな事業の立ち上げなどに活用されます。機能を必要最小限に絞り、MVPのリリースを早めることで競合より早くアイデアを実現することができます。また、リリース後にユーザーからのフィードバックを受け、一つずつ改善を行っていくことで、ユーザーにとって有用性の高いシステム開発が可能です。

リーン顧客開発の効果をさらに高めていくためには、MVPのリリースを素早く行うこと、ユーザーからのフィードバックを踏まえたシステム改修を迅速に行いアップデート版をリリースするまでの期間を短縮すること、より良い製品開発に余念がないことが重要です。そのためには、システム会社へ外部発注することが有用であることについても紹介しました。

Jiteraでは、独自の開発自動化プラットフォーム「JITERA」を活用し、低コストかつこれまでにないスピードでMVPのアジャイルな開発と改善が可能です。また、フルリモート体制を構築しているため、本来は物理的に依頼することができない海外の優秀なエンジニアともマッチングができます。彼らの実績や知識を基にシステム開発を進めることで、ユーザーニーズを正確に予測し、間違いのないシステム設計が行えます。過去の事例は以下のページにて公開をしていますので、Jiteraでシステム開発を行うことに意義を感じられたら、まずは見積もり依頼からご検討ください。

リーン顧客開発とは？概要や導入のメリット、より効果的に実践するためのコツについて解説

業務の効率化が求められる中で、多くの企業でシステム導入が進んでいます。本記事を読んでいる方の中にも、急にシステム導入を担当することになり、困っている方もいるのではないでしょうか。システム開発会社の数は膨大です。開発会社ごとに得意とする分野や開発手法があり、その中から自社の開発目的に合った会社を正確に見極め、発注をするのは至難の業でしょう。

そこで本記事では最適なシステム会社を見つけるための、以下の点について解説します。

- システム開発会社の探し方3選
- システム会社を選定する上での着眼点3選
- システム会社との初回打ち合わせで確認しておくべきこと

最後まで読むことでシステム開発会社探しから、初回の打ち合わせで確認すべきことまで段階を追って理解することができます。

# 1. システム開発会社の探し方3選
### インターネット
最もポピュラーなのがインターネットで検索する方法です。「システム開発会社」や開発要件、業種、目的などのキーワードで検索を行うことでシステム開発会社を探すことができます。

メリットとしては、要件に合ったシステム開発会社を即座に見つけることができる点です。特にシステム開発会社は中小企業やベンチャー企業も多いので、インターネット検索によって初めて目にする企業もたくさんあることでしょう。しかし、ホームページ上では各企業の得意分野や実際に依頼することとなった場合の流れが具体的に見えづらく、依頼先の選定が難航するデメリットもあります。選定に悩んだ挙句、知名度の高い大手に依頼をして、高価な見積もりを提出されるといったことも少なくありません。

### 過去の発注実績
自社が過去にシステム開発を行った際に発注や見積もり依頼をしたシステム開発会社の中から選定するといった方法も有効です。
この方法では、既にやり取りをしたことがある企業の中から選定するため、担当者も決まっており、やり取りがスムーズに進むのがメリットです。初めての依頼先に問い合わせをするのは億劫なもの。そういった部分を省いて本題に入ることができるので、見積もり提出までの流れもスムーズに進みます。一方で、以前に発注した際と開発要件が異なったり、内容や開発目的が違ったりすると、対応できない分野で引き受けてもらえないこともあります。

### ポータルサイト
システム開発のポータルサイトを活用してシステム開発会社を探す方法もあります。この方法では、希望する要件などを入力フォームに記載するだけで、たくさんのシステム開発会社の中から要件に適った企業を抽出することが可能です。サイトによっては、そのまま相見積もりを一斉に依頼することもできます。反面、一斉に相見積もりを依頼すれば各社からの質問事項や提出された見積もりを確認するなどといった対応に時間を取られてしまいます。また、入力フォームによる見積もり依頼のため、自社の開発要件が明確になった状態で、その要件を入力フォーム上へ的確に表現できるだけのシステムへの理解度が求められます。 

# 2. システム開発会社の選び方
システム開発会社を探したら、次はその中から委託先を選定する必要があります。システム開発においては複数社への相見積もりが基本ですが、見積金額の安さだけで委託先を選定してしまうと、失敗につながる恐れがあります。システム開発会社の選ぶ際の着眼点は、主に次の3点です。

### 開発条件や得意分野を確認する
問い合わせをしたシステム開発会社が対応可能と回答したとしても、単に開発が可能であることと、その会社の得意分野であることでは成果物のクオリティに大きな差が出る場合があります。
また、開発環境によっても得意不得意や対応の可否があります。可能な限り事前にシステム開発会社に伝え、すり合わせを行うようにしましょう。得意分野であるかどうかについては、多くのシステム会社が自社のホームページ内で開発実績を紹介しているので、わかる範囲で内容を確認し、開発したいシステムと近い内容の実績が多い会社かどうかを見ておくことがおすすめです。

### 納品後のサポート体制を確認する
納品されたシステムを運用する中で運用保守などのサポート体制が充実しているかどうかも判断基準の一つに加えるとよいでしょう。特に近年のシステム開発は、従来のような納品して終わりの買い切り型から、納品後も運用サポートを行ったり、随時必要機能を追加したりする伴走型にシフトしつつあります。システムの用途によっても買い切り型か伴走型か変わってきますが、事前にサポート体制の内容とそれに必要なコストについても見積もりに加えてもらうなど、確認を行っておくことをおすすめします。

## 担当者とのコミュニケーションが円滑にとれる
システム開発では頻繁に発注を行っていない限り、入念に下準備を行っても予測不能な事態は発生するものです。そういった場合にシステム開発会社の担当者とのコミュニケーションが重要になってきます。柔軟な対応が可能な担当者であれば、こうしたトラブル時であっても適切なアドバイスや調整を行ってもらえますが、難しい担当者だと場合によっては追加費用などを請求されてしまう可能性もあります。見積もり依頼時に窓口となる担当者を確認し、コミュニケーションが円滑にとれる相手であるか慎重に見極めるようにしましょう。 

# 3. システム開発会社との初回打ち合わせで確認しておくべきこと
システム開発の委託先を選定したら、キックオフミーティングが始まります。この初回の打ち合わせで開発における様々な要件を決定していく場合が多いです。システム開発会社との初回打ち合わせで確認しておくべきことは主に次の3点です。

### 納期などの前提条件
必ず打ち合わせで確認しておくべきことの一つに、システム開発における前提条件があります。これは納期や開発環境、システム開発会社に委託する開発作業の範囲や報酬の支払条件などが該当します。正式に契約締結を行う際に書面で明記される部分ではありますが、初回打ち合わせ時に確認をしておくと、その後の流れもスムーズに進めることができます。特にシステム開発に不慣れである場合、どこまでの内容を伝えるべきか迷うこともあるでしょう。その場合はシステム開発会社から質問を受け付けるようにすると、お互いに疑問点を解消した状態で開発工程に入ることが可能です。また、前提条件の内容については見積もり依頼時にRFP（見積もり提案書）を作成することで、明確化することができます。

### システム開発の目的
システム開発の目的を、システム開発会社と開発工程に入る前に共有しておくことをおすすめします。開発したシステムをどのように利用するのか、どのような目的を達成するためにシステムを導入したいのか、具体的な使用方法や目的をシステム開発会社に伝えることで、操作感や使用方法もそれに沿ったものを納品してもらえます。

開発要件や開発環境だけではどのようにシステムを使うのかが見えず、開発要件は満たしているけれど使いにくいシステムが納品されることを防ぐことが可能です。業務の効率化やマーケティングなどどのような目的で、誰が使うのかを打ち合わせ前にまとめておくとよいでしょう。

### トラブル対応の明確化
システム開発を進める上で、トラブルは起こらないに越したことはありません。しかし、開発工程が進む中で競合他社の動きや、法制度の改正など様々な要因による状況の変化で、開発目的に合ったシステムを作るには、要件の変更が必要な場合があります。そういった場合の対応を、あらかじめ可能な限り明確にしておくことでトラブルが発生しても計画に大きな支障が出るのを防ぐことができます。もちろん全てのトラブルについて事前に調整をすることは不可能です。例えば、先に関係法令の変更が見込まれている場合は、事前に打ち合わせの中で触れるようにしシステム開発会社にもそのことを織り込んだ費用で契約してもらうなどの対応が考えられます。こうした内容がはっきりと決まった場合には、契約書にも盛り込んでおくとよいでしょう。 

今回はシステム開発会社の選び方や探し方について解説をしました。システム開発会社選びは生活物となるシステムの質を大きく左右します。今回紹介したことを参考にシステム開発会社選びを行うことで、システム開発におけるリスクを低減することが可能です。

株式会社Jiteraでは独自の開発自動化プラットフォーム「JITERA」の導入と、エンジニアの勤務体系にフルリモートを採用することで実現した、国内外のハイエンドなエンジニアが質の高いシステム開発を短い納期と今までにないコストで行います。実績も数多くある上に、従来の開発速度より何倍も速いスピードと低いコストで開発が可能です。見積もりフォームに必要事項を入力するだけで、簡単に見積もり依頼ができますので、まずはお見積もりから始めてみるのもよいでしょう。

システム開発会社の探し方、選び方

プロジェクトが成功するかは、開発前の初回打ち合わせを含めた準備で決まるといっても過言ではありません。システム開発会社との初回打ち合わせまでに話し合うべき内容について丁寧に準備しておくことで、有益な提案やわかりやすい見積書を受け取ることができます。

そこで今回は、プロジェクトを成功させるためのシステム開発会社との初回打ち合わせの仕方についてわかりやすく解説していきます。この記事を読むことで、トラブルを防止する契約の交わし方がわかるようになりますので、ぜひ参考にしてください。

# プロジェクトが成功する初回打ち合わせ
システム開発会社との初回打ち合わせでは、次のことについてしっかりとしたコミュニケーションを行いましょう。

### 要件定義で開発目的を明確化する
要件定義とは、どのようなシステムを開発するのか、システム開発の要件や目的を明確にして、アイデアを見える形でアウトプットすることをいいます。言い換えるのであれば、依頼者の希望の実現のために、必要な機能について具体的に考えていくことともいえます。

要件定義には、システム開発会社との細かな打ち合わせが必要であり、その過程で定義内容が変わってしまうことは珍しくありません。しっかりとした要件定義をしていないと、想像以上に開発に時間を必要としたり、開発システムが役立たなかったりします。他にも、見積書以上の金額になって、予算を超えることもありますので、初回打ち合わせでは実現したいことを文章や言葉で伝えるようにしましょう。

### プロジェクトスケジュールを決定する
要件定義によって開発目的を明確化したら、システム開発のスケジュールや進捗管理に関するプロジェクトスケジュールについて話し合います。システム開発に要する時間は、開発物によりますが、一般的に2ヵ月～6ヵ月程度で完成するケースが多いです。しかし、大規模システムについては、この期間以上の時間を要するため、完成までのスケジュール把握が欠かせません。

ウォーターフォール型の開発なのか、アジャイル型の開発なのかで期間が違うのはもちろん、プロジェクトに参加するエンジニアの経験やスキル、予算によっても変わってくるため、システム開発会社とプロジェクトの依頼者が納得できる納期設定の必要があります。

### 費用と支払い方法の決定
プロジェクトスケジュールが明確に決まったら、システム開発の費用や支払い方法に関することを話し合っていきます。システム開発費用のほとんどは、エンジニアの人件費です。エンジニアの人件費は、システム開発費用の8割ともいわれています。レベル別のエンジニアの費用相場は、次のとおりです。

- 大手会社に所属しているプログラマーの場合：50〜100万円程度
- 初級レベルのシステムエンジニアの場合：60〜100万円程度
- 上級レベルのシステムエンジニアの場合：100〜160万円程度

エンジニアが開発といっても一人で開発プロジェクトを進めるわけではなく、全体管理をおこなうプロジェクトマネージャーはもちろん、仕事の補佐をするプロジェクトマネジメントオフィス、システムを構築するシステムエンジニア・プログラマーなどで開発チームを組み、ひとつのシステムを完成させます。

また支払い方法については、成果物の納品で料金を支払う請負契約とエンジニアの労働時間に対して料金が発生する準委任契約がありますので、どちらにするのか話し合いましょう。

### チーム構成について話し合う
開発費用と支払い方法を決定したら、システム開発チームの構成や役割分担に関することを話し合っていきます。主なチーム構成は次のとおりです。

・縦割りチーム 
 総合的な幅広い知識を有するジェネラリストと呼ばれる人が中心となって組織形成されるチームのことです。それぞれの開発範囲が明確なため、仕事がしやすいという特徴がありますが、一方で開発の細部までは把握しづらいという欠点があります。

・横割りチーム 
 それぞれの領域のスペシャリストが中心となって組織形成されます。スペシャリストは、非常に専門的な知識を有しているため、仕事のレベルが高いという特徴がありますが、こだわりが強く統率しづらいという欠点があります。

・混合チーム 
 縦割りチームと横割りチームの中間的な組織形成がおこなわれます。ジェネラリストはチーム全体を、スペシャリストはそれぞれの仕事が完成するようにプロジェクトを進めていきます。

### 連絡手段を決定する
チーム構成が決定したら、システム開発進捗や問題解決に関する連絡手段を確立していきます。たとえば、連絡手段が電話だけでは、気軽に質問したいことがしづらいでしょう。そのため、気軽にコミュニケーションできるように、チャットワークやLineなどのコミュニケーションアプリを決めておきます。そこにプロジェクトの開発進捗や質問に対する回答を返してもらうことで、開発納期まで安心して仕事を任せられます。

# ITエンジニアが教えるトラブルを防止する契約の交わし方
システム開発の依頼先を決めたら、将来的なトラブルを防止するため、契約書を交わします。次に、現役のITエンジニアがトラブルを防止できるおすすめの契約書の交わし方についてご説明します。

### 契約書の内容をチェックする
システム開発会社との初回打ち合わせで、本当に契約しても良いと感じたら、契約書を交わします。契約書には、基本情報として次のことが記されているため、チェックしましょう。それぞれの項目の詳細は、次のとおりです。

・目的 
 契約目的やシステム開発する内容は何か

・ 有効期限 
 契約がいつまで期限なのか

・定義 
 契約書に記載されている言葉の定義

・ 仕様 
 納品物の特徴について

・ 実施場所 
 システム開発を実施する場所はどこなのか

・ 納期 
 何をいつまでに納品するのか

・ 報酬 
 完成品の納品で発生する報酬金額や支払い方法

・ 不具合対応 
 納品物に問題が発生した場合の補償内容

・ 権利 
 納品物の権利の所在について

一般的に、システム開発の契約書は、開発契約書や業務委託契約書、開発委託契約書などの名称で契約書を交わします。初めてのことだからといって、内容を見ずに契約書を交わすと、のちに大きなトラブルにつながるため注意してください。

# 社内決済の必要性を伝える
契約書が交わされていなくても、口約束の仕方によっては過失が生じたことを理由に、損害賠償請求されるリスクが伴います。そのため、すべての契約は、社内合意が得られなければ進められないという意思を最初から伝えておきましょう。

また、社内決済の承認に多くの時間を要する場合は、システム会社によっては先行着手費として費用を請求されることがあります。そのため、事前にそういった費用の発生があるのかについて確認しておくだけでも、契約におけるトラブルを未然に防げます。

# 株式会社Jiteraなら初めての契約でも安心できる
株式会社Jiteraでは、システム会社として顧客管理システムや営業管理システム、ECサイト、予約管理システム、ビジネスマッチングシステムなどフロントエンドから業務管理システムまで幅広い開発実績がございます。

システム開発前に仕様書のドキュメントを納品するため、お互いの齟齬がなく開発がスタートできるのはもちろん、最新の技術や他社事例も交えて選択肢を提供させていただくため、初めての契約でもご安心して利用いただける体制を整えております。ぜひ、お気軽にご相談ください。

プロジェクトが成功するかは、開発前の初回打ち合わせを含めた準備で決まるといっても過言ではありません。システム開発会社との初回打ち合わせまでに話し合うべき内容について丁寧に準備しておくことで、有益な提案やわかりやすい見積書を受け取ることができます。そこで今回は、プロジェクトを成功させるためのシステム開発会社との初回打ち合わせの仕方についてわかりやすく解説していきます。この記事を読むことで、トラブルを防止する契約の交わし方がわかるようになりますので、ぜひ参考にしてください。

プロジェクトが成功するシステム開発会社との初回打ち合わせ

社会の働き方の効率化への関心の高まりによって、RPAを採用する会社が増えつつあります。RPAツールがあればビジネスプロセスを自動化することで、企業は時間と労力を節約し、生産性を向上させることができます。しかし、RPAツールを選択する際には、多くのポイントに注意する必要があります。選択を誤ると、企業にとって大きなコストと時間の浪費につながります。

そこで今回は、RPAツール選定のポイントをわかりやすく詳しく解説していきます。RPAツールの社内採用を検討している企業の方は、最適なRPAツール選びの参考にしてください。

# RPAツールを社内採用する前に！自動化ツールの特徴
RPA（Robotic Process Automation）ツールとは、ソフトウェアロボットを使用してビジネスプロセスを自動化するためのツールのことです。RPAツールは、次のような仕事を自動化できます。

- データ入力
- ファイル転送
- タスク監視
- 顧客対応
- 請求書処理
- 在庫管理
- 人事処理

これらの業務は、定型的に繰り返されることが多く、人間が行うとヒューマンエラーが生じ、多くの時間とコストを要するという課題があります。これらの定型的な業務を自動化することにより、企業は時間と労力を節約し、生産性を向上できます。

# RPAの代表的な3つのクラス
RPAツールは、クラスによって自動化のレベルが異なります。

### 【クラス1】
クラス1は、定型的な仕事を得意とする自動化レベルです。もっとも自動化レベルが低いため、決められたこと以外の仕事はできません。万が一、自動化のフローに変更があった場合は、その都度カスタマイズの必要があります。

### 【クラス2】
クラス1と比べてクラス2は、AIによる学習機能が搭載されているため、たくさんのデータを扱うことができます。そのため、クラス2なら顧客分析や情報処理などの高度な仕事を効率化できます。自動化フローに変更があった場合でも、変更内容に合わせて自動的にフローを変更できるため、定型的ではない仕事でも対応できます。

### 【クラス3】
クラス2と比べてクラス3は、顧客分析や情報処理はもちろん、その会社にとってベストな結果を出力するところまで自動化できます。クラス3は、学習能力が高く、自分で規則を作成し、意思決定できます。

クラスが上がると機能性が向上するため非常に便利ですが、それに比例してコストも上がります。そのため、事前にRPAツールで遂行する仕事の範囲を決定することで、ベストなクラスを決めやすくなります。

# RPAツールの社内採用のメリット・デメリット
### RPAツール社内採用のメリット
自動化ツールの採用は、次のようなメリットがあります。

・人間が手作業で行う作業時間を大幅に削減できる。
・人間による手作業ミスを減らすことができる。
・手作業による作業時間を減らせるため、コストを削減できる。
・自動化されたプロセスを高速で実行できるため、仕事の実行速度を向上できる。
・プライバシーやセキュリティに関する規制に対応できるため、機密情報の漏洩やセキュリティの問題を回避できる。

# RPAツール社内採用のデメリット
一方で、RPAツールによる自動化のデメリットには、次のようなものがあります。

- 複雑なタスクや判断力を必要とする仕事には向いていない。
- プロセスの変更があった場合は、ツールの再設計や再構築の手間が発生する。
- ツールによっては、複雑な設定や一定のスキルを求められる。
- 不適切な設定や変更が行われた場合、エラー対応に追われる。
- 毎月、ライセンス費用やトレーニング費用などが必要となる可能性がある。

# RPAツールの選び方
### 【ポイント1】機能性が高い
RPAツールは、自社のビジネスプロセスの自動化に役立つ機能を持っていることが重要です。そのため、事前に次のように必要な機能をまとめておきましょう。

- プロセスの自動化
- データの抽出
- データ分析
- レポーティング
- データ統合

### 【ポイント2】全社的な利用を実現しやすい
RPAツールは、社内のすべての従業員が利用できることが重要です。つまり、ユーザーインターフェースが使いやすく、ITツールの操作に慣れていない方でも利用できることが求められます。また、専門的なスキルがなくてもツールを容易に設定でき、新規機能を簡単に実装できることも重要です。

### 【ポイント3】サポートとトレーニング
RPAツールを使用する際には、自動化ツールの利用に向けてのトレーニングが必要になることがあります。また、自動化システムに問題が発生した場合には、ツールのサポートにすぐにアクセスできることも重要です。そのため、提供されるドキュメントやトレーニングの質について事前調査し、企業の状態や必要性と合ったものであることを確認する必要があります。

### 【ポイント4】予算内で必要な機能を備えている
RPAツールの契約価格は、企業によって異なります。なぜなら、会社が求めている自動化レベルが異なるからです。簡単な仕事を自動化するのなら、クラス1のRPAツールで問題ありません。しかし、膨大なデータを収集し、分析データを次のマーケティングにつなげるような高度な使い方をするのなら、クラス3のRPAツールを選ぶ必要があり、それだけコストが大きくなります。そのため、予算内で必要な機能を備えたRPAツールを選ぶことが重要です。

### 【ポイント5】セキュリティレベルが高い
RPAツールは、企業が保持する機密情報を処理するケースが多いです。そのため、契約前にツールのセキュリティレベルや機能について評価することが重要です。セキュリティが確保されていないツールを使用することは、企業のセキュリティ上の脅威となるのはもちろん、個人情報の情報漏洩によって大きな被害につながる可能性があるため、注意が必要です。

### 【ポイント6】拡張性が高い
RPAツールは、極力拡張性が高いことが望ましいです。なぜなら、企業の成長とともに、自動化すべき仕事や範囲が変わってくるからです。RPAツールには、主に拡張性の高い汎用型と経理や人事などの特定の仕事の効率化を得意とする特化型があります。

汎用型は、拡張性が高いためあらゆる仕事を自動化できますが、扱うには専門知識が必要となります。一方で、特化型は、拡張性は低いものの、専門知識がない初心者でも扱いやすいケースが多いです。

# 株式会社JiteraへRPAツールの開発を依頼する
RPAツールの特徴やクラスの違い、自動化ツールの選び方の6つのポイントについて解説しました。RPAツールといっても、その種類や特徴は会社によって大きく異なります。もし、複雑なRPAツールの採用をお考えであれば、株式会社Jiteraへご相談ください。

お客様のご要望に沿った独自のRPAツールを開発することで、社内の効率化はもちろん、生産性の向上に大きく貢献いたします。また弊社では、見積もりご依頼フォームを設けているため、速やかにお客様のご要望を把握し、ご納得いただける見積額の提示が可能となっています。他にも、簡単なRPAツールであれば、独自の開発自動化プラットフォームJITERAを使うことで、開発費を大幅に抑えて、ツールを制作できます。


RPAツール（自動化ツール）の選び方とは？ ツール採用のメリット・デメリットを解説

# オフショア開発のトレンド
オフショア開発とは、海外の開発会社に開発業務を委託することで、日本では1980年代から取り入れられてきました。当初、オフショア開発の導入目的は開発コストの削減でした。人件費の安い海外の開発会社を利用することで、国内開発と比較して開発コストを大幅に削減できるためです。しかし近年は、IT人材確保の面でオフショア開発を検討するケースが増えています。

### 近年は高い技術力を持つIT人材の確保先として注目
国内は深刻なIT人材不足により開発者の賃金が増加しており、従来と同じ開発費用をかけても国内だけで技術力の高いIT人材のリソースを確保するのは難しくなっています。そのため、IT人材のリソースの調達や高い技術力を求めてオフショア開発を検討するケースが増えています。

オフショア開発の委託先の国は、中国やインドをはじめ、ベトナムやミャンマーなどが人気です。オフショア開発が盛んな国では、IT人材は他の職業と比較して高給であり人気です。ベトナムなど、国策としてIT人材の育成に力を入れている国もあります。優秀なIT人材が多数輩出されるため、国内での開発コストと大きな差がなくとも、オフショア開発で海外エンジニアを取り入れることで企業の開発力を維持しようとする動きが高まっています。

# オフショア開発でIT人材のリソース確保する際の注意点
オフショア開発でIT人材のリソースを確保する際に、主に注意が必要なのが次の2点です。

### 1. 国家情勢と日本との外交関係
オフショア開発は政治の影響を受けやすい開発方法です。オフショア開発国として人気なのは賃金の安い国であり、中には国内でクーデターやデモが発生するなど不安定な地域もあります。また、国家情勢が安定していても、日本との外交関係が悪化すれば開発の委託は難しくなります。政治的な問題であるため検討が難しいのですが、中長期的に見て安定的な体制を確保できるかを判断する必要があります。

### 2. 海外の開発会社とのコミュニケーション
オフショア開発では、コミュニケーションが開発の大きな壁となります。市場の変化が激しい現代において、密で正確なコミュニケーションは開発を進める上で欠かせません。しかし、言語や文化の違い、品質に対する認識、時差などからコミュニケーションに齟齬が生じ、開発が失敗してしまうケースが少なくありません。

オフショア開発でのコミュニケーションのとり方は運営元の企業形態によって異なります。オフショア開発の運営元は、現地法人・日系企業・外資系企業の主に3つに分けられます。それぞれの特徴を説明します。

### 運営元が現地法人の場合
開発担当のエンジニアも日本との窓口も基本的には現地の人で、単価の安さが特長です。日本語でのコミュニケーションに対応していない会社の場合には、特に単価を安く抑えられます。

### 運営元が日系企業の場合
日本との窓口を日本人が担当し、日本での開発と同様に進められるようになっています。コミュニケーション面での不安はありませんが、現地人の運営会社よりも高めの価格設定であることが多いです。

### 運営元が外資系企業の場合
欧米企業が運営しており、コミュニケーションは英語です。技術力の高さをアピールし、高単価であることが多いです。グローバル展開を前提としたプロダクト開発に適しています。

日本語でのコミュニケーションや高い技術力を求める場合には、運営元として日系企業や外資系企業がおすすめです。ただしこの場合、オフショア開発でのコスト削減効果は少なくなる点に注意が必要です。

以上から、オフショア開発でIT人材のリソースを確保する際には、政治的側面やコミュニケーション面でのリスクを考えて委託先を検討する必要があります。オフショア開発でのリスクを考えた際におすすめなのが、日本企業によるグローバル開発です。

# IT人材の確保にはオフショア開発よりもグローバル開発がおすすめ
グローバル開発とは、開発者が複数の国籍の開発者で構成されたチームで進める開発のことです。テレワークが主流になったことで、グローバル開発は日本でも広がりを見せています。海外の開発者が開発するのであれば、オフショア開発と同じなのでは？と疑問に思われたかもしれません。

オフショア開発とグローバル開発の違いは、開発者を集める範囲です。オフショア開発は一つの国で開発を進めるため、委託時には国の特徴を踏まえて委託先の国を選択する必要があります。一方、グローバル開発は国を限定せず世界各国からIT人材を集めます。そのため、特定の国の言語や文化に依存することなく、高い技術力を持つメンバーを集めてチームを構成できます。

### グローバル開発のメリットは、次の3点です。
- 高い技術力を持つIT人材を、国内よりも安く採用できる
- 国家情勢の悪化や外交問題の影響を受けづらい
- グローバル展開に向けた開発をしやすい

グローバル開発のデメリットとしては、オフショア開発と同様にコミュニケーションの問題が挙げられます。しかし、グローバル開発の場合には一つの国に限定していないことから、メンバーはダイバーシティを理解した上で丁寧なコミュニケーションをとる文化があります。

また、国内の開発会社が実施しているグローバル開発であれば、依頼時は日本語でのコミュニケーションが可能であり、日本での開発現場を熟知しています。そのため、スムーズなやり取りや品質の確保が可能です。高い技術力を持つIT人材のリソース確保を目的としている場合には、グローバル開発を検討してみてはいかがでしょうか。ここでは、グローバル開発をしている日本企業の株式会社Jitera（以下、Jitera社）をご紹介します。

# グローバル開発を行う日本企業、Jitera社とは
Jitera社は2017年設立のソフトウェア開発を行っている日本企業です。高スピードで高品質なグローバル開発を得意としており、東証プライム企業から中小企業まで幅広く開発実績があります。Jitera社は日本企業でありながら海外エンジニアが多数在籍しています。その海外人材比率の高さから、社内公用語は英語です。Jitera社の開発者には高度な技術力が求められ、採用通過率はわずか0.1％程であることからも技術力の審査が厳しいことがうかがえます。技術力がトップレベルの開発者を世界各国から集めることでプロフェッショナルチームを構成し、グローバル開発に取り組んでいます。

開発体制はグローバルなものですが打ち合わせは日本語で実施されるため、コミュニケーションの取りやすさは国内開発と同じです。コミュニケーションに壁を感じることなく、高品質なグローバル開発が可能です。

# Jitera社で行う開発の魅力
Jitera社での開発の魅力は、開発スピード・コスト・品質・コミュニケーション面を総合的に見たときの “コストパフォーマンスの高さ” です。その秘密は、開発自動化プラットフォーム「JITERA」とスクラッチ開発を組み合わせたハイブリット型のアジャイル開発にあります。

開発自動化プラットフォーム「JITERA」とは、ソフトウェアをリリースするために必要なフロントエンドからバックエンド、インフラ、API連携まで幅広く自動化できる、Jitera社が開発したツールです。JITERAを使うことで、複雑なロジックが必要ないコードは自動で生成できます。実証実験では、平均で60〜70％の開発の自動化に成功しています。また、JITERAはスクラッチ開発に切り替えることができるため、複雑なロジックや追加機能の開発にも対応できます。

Jitera社の開発には、次のような特長があります。
### フルスクラッチ開発よりも何倍も速いソフトウェア開発
JITERAを使った開発の自動化により、フルスクラッチ開発と比較して劇的に早いスピードでの開発が可能になります。開発スピードの速さは、ユーザーへの価値提供を早めるだけでなく、コスト削減にも繋がります。
【参考リンク：[システム開発で押さえるべきポイントとコスト削減のために知っておきたい費用の相場](https://jitera.com/ja/blogs/5)】

### 高い技術力とアジャイル開発による高品質な開発
Jitera社では、世界各国から高い技術力を持った開発者を集めたグローバル開発の体制を取っています。開発の進め方はアジャイル型であるため、日々変化するビジネス環境の中でも、常に優先度の高いタスクから開発を進められます。
また、開発の一部はJITERAにより自動化されるため、開発者たちは複雑なロジックの検討や追加機能の開発に集中できます。これにより、高品質な開発を可能にしています。

### 緻密なコミュニケーションと提案力による委託しやすさ
Jitera社ではアジャイル開発を導入していますが、しっかりとドキュメンテーションも行います。正確に認識合わせをしてから開発に取り組む流れとなっており、開発前に仕様書などのドキュメントを納品します。また、ドキュメントだけではなくデザインデータを製作し、実際の画面を見ながら開発を進めていきます。お互いの認識や完成イメージを共有した上で進めるため、コミュニケーション不足による齟齬なく開発を進められます。



コスト削減を目的として始まったオフショア開発ですが、現在ではIT人材のリソース確保に目的が変わってきています。IT人材のリソース確保を目的とした場合には、オフショア開発よりも国内の開発会社でのグローバル開発がおすすめです。IT人材の確保だけでなく、市場がグローバル化している現代において、グローバル開発は今後増えていくでしょう。

また、この記事ではグローバル開発を先駆けて取り入れている国内の開発会社としてJitera社を紹介しました。Jitera社のホームページには開発事例も掲載されていますので、ぜひチェックしてみてください。


オフショア開発のトレンドとグローバル開発へのシフト

# データベース設計の基本、ER図とは？
アプリケーションを作成する場合に、避けては通れないのがデータベース設計です。データベース設計においては、様々な手法が使用されますが、その中でも基本中の基本と言えるのがER図というものです。ER図とは「エンティティ・リレーションシップ図」の略であり、英語では「Entity Relationship Diagram」と呼ばれています。その名の通り、データの構造と関係を図に表したものです。この記事では、このER図がどういうものか、そして、どのように付き合えば良いのかをわかりやすく解説します。

# ER図、いつ作り、いつ使う
まず、最初に明確にすべきことは、ER図というものをいつ作って、いつ使うかということです。そのためには、アプリケーション開発の全体のフェーズにおけるデータベース設計の工程を明確にしておく必要があります。一般的なフェーズ分けとしては以下のようになります。それぞれシステム開発のフェーズの右側にデータベース設計の工程を記述してあります。

1. 要件定義(計画、分析)：概念データ設計
2. 基本設計：論理データベース設計
3. 詳細設計：物理データベース設計
4. 開発(コーディング)
5. テスト

このうち、ER図が最初に出てくるのは、1の要件定義の中で行われる概念データ設計の工程です。ここで作成されたER図は続く論理データベース設計の基本となり、物理データベース設計時に物理	ER図として、記述し直されます。そして、その後の開発やテスト、そして保守(メンテナンス)作業においても参照され続けます。そのため、適切で有効なER図を作成することは、システム開発全体において極めて重要な作業ということになります。

そして、もうひとつ重要なのは、ここで示したものはウォーターフォール型と呼ばれる伝統的な開発手法において定義された工程であり、アジャイル型においては、同様の工程を短期間で繰り返すことになるため、ER図をどの工程で作るかに関しては別に考慮が必要です。その考慮点に関しては後述します。

# ER図の読み方
ここでは、ER図の読み方を通じて、	ER図とは何かということを明確にしてゆきます。[図1]を参照してください。この図の中に表されている各要素の意味を順番に解説します。

### エンティティ
まずは、図の中で「会員」、「注文」というボックスとして表現されている「エンティティ」という要素です。日本語では「実体」と訳されますが、この訳ではどういう意味なのかよく分かりません。簡単に言ってしまえば、名前がついたものすべてが「エンティティ」です。名前がついていれば、目に見えるものだけではなく、概念などの無形のものもすべて「エンティティ」として扱うことができます。

「エンティティ」の中には、図の「注文」に対する「注文明細」のように、相手が存在しなければ存在しえない親子関係を持つものがあります。この場合は子に当たる「エンテイティ」を角丸のボックスで表します。

### アトリビュート
そして、「エンティティ」のボックスの下側にリストされているのが「アトリビュート」つまり「属性」です。これは、「エンティティ」を形容するものと言えば分かりやすいでしょう。別の言い方をすれば、「エンティティ」が個別の「インスタンス」になるための条件と言っても良いでしょう。たとえば、「会員」が「あなた」という「インスタンス」になるためには、それがあなたの会員番号、あなたの会員名、あなたが住んでいる住所を「アトリビュート」として持っている必要があります。

### リレーションシップ
つぎは「リレーションシップ」です。「リレーションシップ」とは、「エンテイティ」間の「関係」のことです。この図では、両方の「会員番号」という「アトリビュート」が関係を持っているということがわかります。図のように「リレーションシップ」は線で表されます。

### カーディナリティ
最後に、その「リレーションシップ」の対応の多重度を示しているのが「カーディナリティ」です。この図においては、「会員」の「アトリビュート」としての「会員番号は」１つですが、その会員は複数の注文をしている可能性もあるし、一つも注文をしていない可能性もあります。したがって、「カーディナリティ」は「１対０あるいは多」という多重度になります。

それを表現しているのが「会員番号」の「リレーション」の両端の記号です。「カーディナリティ」の記述方法にはいくつかありますが、この記事ではその中で最もオーソドックスな「IE記法」を使用しています。「IE記法」では、１は縦の線、0は丸、多は鳥の足のような線で記述されます。これらの記法は細かい部分ではいくつかのオプションがあるので、読み解く場合にはどのやり方なのかを確認する必要があります。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/ER01.jpg)

# ER図の書き方
ここでは、簡単なER図の書き方を解説します。まず、最初に決めなければならないのは、どのプロセスのデータを扱うかということを決めます。

ここでは、例として、ECサイトで、購入する電池を何にするかを検索するプロセスを題材にします。このプロセスを「ユースケース」と呼びます。次に、この「電池検索ユースケース」で扱う「エンティティ」を洗い出します。まず、思いつくのは検索するものと検索されるものである「電池」と「電池検索」という「エンティティ」です。そして、「電池」の「エンティティ」における「アトリビュート」を列挙します。電池を形容する言葉です。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/ER02.jpg)

それは、[図2]にあるように、一意の「商品番号」、単１、単２などの「サイズ」、アルカリ、マンガンなどの「タイプ」、パナソニックなどの「メーカー」、「単価」、そして「名称」です。同じように、「電池検索」の「アトリビュート」に関しても洗い出してみましょう。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/ER03.jpg)

結果としては[図3]のようになります。ここまでできたところで、「電池検索」の「エンティティ」の「アトリビュート」の「サイズ」、「タイプ」、「メーカーの一部」は厳密には「電池」の「エンティティ」の中にはないことがわかります。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/ER04.jpg)

これは、[図4]のように、新しく「サイズ」、「タイプ」、「メーカー」の「エンティティ」を作ることで解決できます。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/ER05.jpg)

そして、[図5]で追加したように、これらの「エンティティ」には「電池」の「エンティティ」との「リレーションシップ」が存在し、これらの「エンティティ」を新しく作った経緯から簡単に設定できます。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/ER06.jpg)

そして、最終的には[図6]のように、「電池検索」の「エンティティ」と「電池」、「メーカー」、「タイプ」、「サイズ」の「エンティティ」との間にある「リレーションシップ」と「カーディナリティ」を定義することによって、このユースケースで使用するER図が完成します。

ここまで行ってきたように、ER図の作成にあたって重要なのは、そのプロセスで扱うデータの関係を常に意識することです。最初に作成するER図に関しては、いわゆる「正規化」を意識せずに行う方がデータの洗い出しがうまくいくことが多いのですが、物理データベース設計に使用するER図では、データの冗長さを排除し、更新の効率を考慮する必要があり、それは事前あるいはER図作成時に「正規化」を行うことによって実現できます。

# ER図のメリット・デメリット
ここまで、ER図とはどういうものか、どう読み、どう書くかに関して説明してきました。冒頭でも述べたように、データベース設計においてER図はなくてはならないものであるというのが前提ですが、実はER図を使用することにはメリットとデメリットがあります。今後、ER図と付き合ってゆくためにはその両方を知っておく必要があります。

### ER図作成のメリット
まずは、メリットからですが、最も大きなメリットは、やはり扱う必要のあるデータの持ち方や関係が一目でわかるため、プログラム開発やテストにおいてもデータの扱い方を決めるのに役に立ちます。そして、それはシステムのサービスイン後に長く続く保守フェーズにおいても、プログラムをどのように変更したら、どのような影響が出るかを判別するのに役に立ちます。

### ER図作成のデメリット
デメリットとして挙げられるのは、ER図が実際には図でしかないために、それをデータベースやプログラムにするためには様々な工程を経て必要があることです。これらの多くの工程において、ER図に表されているものがもし誤解されて使用されるようなことがあると、結果的には要件に合わないシステムができてしまいます。それを防ぐためには、ER図をいかに確実にデータベース化、コード化するのかということを考え、そうなっていることを検証し続けなければなりません。このデメリットに関しては、ER図自体を自動的にコード化してくれるようなツールがあれば極めて有効な対策になります。

さらに、アジャイル型の開発においてはER図に立ち戻っての変更も頻繁に必要になり、それによってリファクタリング(データベースの再構成)も必要になります。このような状況においても、自動コード化の仕組みがあれば複雑な処理が必要なリファクタリングも容易に行うことができます。



データベース設計に必須！ ER図の書き方

システム開発における契約形態には、SES（準委任契約）と受託開発（請負契約）の2つがあります。両者の特徴を知り、使い分けることで効果的にシステム開発を行うことが可能です。
しかし、両者の使い分けやどのような開発タスクに適しているか理解している人は多くありません。そこで本記事では、次の点について解説します。

- SESが適した開発タスク
- SESの開発フロー
- SESを成功させるために必要なこと

# SES(準委任契約）が適している開発タスク
SESに適している開発タスクは、開発期間が長期に及ぶものや開発途中での仕様変更や追加が発生しやすい、あるいは仕様を決定しきれない部分があるものです。受託開発（請負契約）では成果物の納品が目的となるため、買い切り型のシステム開発に適しており、要件定義から納品までの工程を順に完了していくウォーターフォール型開発と相性が良いです。

反対にSESでは、成果物の納品などを目指した作業の履行に対して報酬が支払われるため、伴走型のシステム開発に適しており、開発単位を小さく分割し1つずつ機能を実装していくアジャイル型開発に馴染みやすいとされています。

アジャイル開発を採用する場合において、契約形態はSESが馴染みやすいことについては、独立行政法人 情報処理推進機構と経済産業省が公表している「情報システム・モデル取引・契約書＜アジャイル開発版＞アジャイル開発外部委託モデル契約」※1でも述べられています。

特にモバイルアプリ開発とWebサイト開発は、アジャイル開発が適している開発タスクです。それぞれ適している理由について詳しく解説します。

### モバイルアプリ開発
モバイルアプリ開発では仕様の変更や追加といった、アップデートが容易に行えるアジャイル開発が主流です。従来のウォーターフォール開発では、最初の打ち合わせで作成される仕様設計書に基づいて開発がすすめられ、途中での仕様変更が難しく追加費用が発生することも多くあります。

アジャイル開発ではイテレーションと呼ばれる開発サイクルの中で、1つずつ開発タスクを完了し機能実装していくため、機能の追加や仕様変更にも対応が可能です。特にゲームアプリやSNSなどのユーザーからフィードバックを受けて随時更新を行う必要があるアプリ開発には、アジャイル開発が向いているといえます。

### Webサイト開発
Webサイト開発もアジャイル開発が適しています。WebサイトではUI（ユーザーインターフェース）の改善やページ間の導線の改善など、リリース後も品質向上のためにやるべきことが多いです。

また、問い合わせフォームや予約システム、ECサイトなどをサイト内に持つ場合、コンバージョンまでのデザインやシステムの利便性を高めるためにも常に改善が求められます。デザインやサイト設計、既存機能の改善など伴走型の開発が必要なWebサイト開発にも、アジャイル開発が適しているといえます。

# SES(準委任契約）のフロー
SESにおける開発フローは大きく次の4ステップです。

1. 要件定義
1. 開発
1. テスト
1. デプロイ

アジャイル開発では2から4のステップを各イテレーションで繰り返しながら、システム開発を進めていくため、一度デプロイしたらプロジェクトが完了するわけではありません。

（アジャイル開発のプロジェクトの大まかな流れについては独立行政法人 情報処理推進機構の「アジャイル開発の進め方」※2を参考としています。）

### 1. 要件定義
アジャイル開発における要件定義はプロダクトバックログを作成することが目的です。プロダクトバックログとは、ユーザーの目的を達成するために必要なタスクに優先順位をつけ、リスト化したもの。プロダクトバックログは開発工程が進む中で随時更新されます。

このプロダクトバックログを作成するために、ユーザーとの打ち合わせを行います。打ち合わせの中でユーザーストーリー（ユーザーがシステム開発によって達成したい目的やシステム導入をするに至った理由）の聞き取りを行い、ユーザーストーリーマッピングを作成します。

ユーザーストーリーマッピングとは、ユーザーストーリーから価値観を整理してプロジェクトの軸を固めるためのものです。アジャイル開発では小単位で開発を進めるため、開発過程でプロジェクトの軸がぶれてしまうリスクがあります。そのリスクを回避するために、ユーザーストーリーマッピングを作成することで、プロジェクトの大きな方向性を見失わないようにしています。

### 2. 開発
アジャイル開発では、開発からデプロイまでを1サイクルとして何度も回していきます。この1サイクルの期間をイテレーションと呼びます。イテレーションごとにチームで打ち合わせを行い実装する機能を決定。チーム内で進捗管理を行いながら機能の開発を行います。

### 3. テスト
開発された機能に対してテストを行います。内部のコードに対するチェックやユーザーストーリーに照らしたテスト、手動で行う探索テスト、安定性やセキュリティ面などのパフォーマンスに関するテストといった過程を経て機能実装へ向かいます。

テストを行う際にもユーザーストーリーを満たす機能となっているか確認が必要です。そのためにも要件定義の際にしっかりとユーザーへヒアリングをしなければなりません。また、アジャイル開発では開発単位が小さいため、問題が起こった際の原因特定が早い傾向にあるのも特徴です。

### 4. デプロイ
テストが完了すれば機能を実装しデプロイを行うことができます。この際、ユーザーからのフィードバックをもらい改善点や方向の修正などを必要に応じて行います。デプロイまで終われば、次のイテレーションです。プロダクトバックログを確認し、次に実装すべき機能を検討。チーム内でタスクの分担を決めて開発にかかります。開発からデプロイまでのサイクルを繰り返してシステム開発を進めていきます。

# SES(準委任契約）を成功させるために必要なこと
SESによるシステム開発タスクを成功させるために必要なことは事前の準備とベンダーとのコミュニケーションです。その理由は大きく次の2点です。

### プロダクトバックログに影響する
SESと親和性の高いアジャイル開発では、要件定義を行うキックオフミーティングの際にユーザーストーリーを聞き取り、プロダクトバックログを作成します。キックオフミーティングでは、ユーザーがシステムを導入するに至った理由やシステム開発によって達成したい目的などの聞き取りが必要です。もちろんアジャイル開発では細かな要件や機能を当初から定める必要はないため、目的がはっきりとしていなくても問題はありません。

しかし、目的や問題意識が事前に定まっている方が、ベンダーのヒアリングも円滑に行えるうえに、その後の開発工程もスムーズに進むことは間違いないでしょう。

### アジャイルソフトウェア宣言でも提唱されている
アジャイル開発の概念が生まれたアメリカでまとめられた「アジャイルソフトウェア開発宣言」※3の中でもコミュニケーションの大切さに触れられています。

プロセスやツールよりも個人との対話を優先し、契約交渉よりも顧客との協調を大切にするといった内容を宣言に盛り込んでおり、原則の中でも情報を伝えるもっとも効率的かつ効果的な方法は面と向かって話をすることと記載がありコミュニケーションを重視する内容が多いです。

アジャイル開発においては顧客とベンダーのコミュニケーションを大切にしていることが分かります。アジャイル開発では、プロダクトバックログの作成や機能実装に係るフィードバックなど多くの場面でユーザーとの対話が必要です。

# Jiteraでの開発に準委任契約が適している理由
今回解説したようにSESはモバイルアプリやWebサイトなどの随時機能追加が必要であったり、開発途中の仕様変更が行われたりする開発タスクに適しています。SESはアジャイル開発と親和性が高く、公的機関の開発モデルにも取り入れられています。

アジャイル開発のフローは要件定義によって、ユーザーの開発目的や求める機能などのユーザーストーリーを念入りに確認し、開発・テスト・デプロイの工程をイテレーションごとに回していく流れです。この開発・テスト・デプロイの工程を短期間で回すことで、次々と必要な機能を実装することができます。

株式会社Jiteraでは開発自動化プラットフォーム「JITERA」を独自で構築し、これまでにない速度で開発から機能実装までを行うことが可能です。開発速度を上げることで、ユーザーのニーズに即応し、取りこぼしを防ぐことができます。また、JITERAを活用することでこれまで人間が書いていたコードを一部自動化できるため、開発コストも抑えることが可能です。まずはお見積もりや問い合わせフォームからのご連絡から検討ください。
 
＜参考＞ 
※1　独立行政法人 情報処理推進機構・経済産業省「情報システム・モデル取引・契約書＜アジャイル開発版＞アジャイル開発外部委託モデル契約」 
https://www.ipa.go.jp/files/000081484.pdf 
※2　独立行政法人 情報処理推進機構「アジャイル領域へのスキル変革の指針　アジャイル開発の進め方」 
https://www.ipa.go.jp/files/000065606.pdf 
※3　アジャイルソフトウェア開発宣言 
https://agilemanifesto.org/iso/ja/principles.html

SES（準委任契約）に適しているシステム開発のプロジェクトとは？

初めてシステム開発を外注化する場合は、丁寧な社内準備をしておくことで開発会社と認識にズレのない有意義なコミュニケーションが可能となります。しかし、システム開発のプロジェクト外注化の社内準備に関する情報は少なく、仮にあったとしてもエンジニア向けで内容がよくわからないと思っていないでしょうか。

そこで今回は、システム開発のプロジェクトで外注を取り入れる際の社内準備として基本的な知識をわかりやすく解説していきます。この記事を読むことでシステム開発における具体的な組織編成やプロジェクトの進行中のコミュニケーションの仕方、納品物の確認方法がわかりますので、ぜひ参考にしてください。

# システム開発で会社の抱える課題を解決する
システム開発では、企業のバックエンドシステムやERPシステム、CRMシステムなどのシステムを開発することであり、システムやアプリを通して会社の課題を解決することをいいます。たとえば、営業の長時間労働の問題を改善したいという課題があった場合、顧客管理システムを開発し、営業効率化によって働く人の負担を減らしていきます。そのほとんどが複数のパーツや要素を組み合わせて実現することが多く、あらゆる問題を解決に導いていきます。

# 基本的な開発の種類
システム開発といっても、その種類は大きく4つに分類できます。それぞれ、システム開発の種類は次のとおりです。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/whenoutsource01.png) 

# システム開発における組織編成
システム開発では、プロジェクトに多くの人が関係しているため、どのような関係性があるのか、必要な社内準備として事前に理解しておくことをおすすめします。システム開発では、次のようなメンバーが集まって組織編成がおこなわれています。

### プロジェクトマネージャー
システム開発においてプロジェクトマネージャーは、開発の全体管理を担う責任者で、PMと呼ばれています。プロジェクトの全体的な指揮監督役として予算や開発期間、納期までの調整を率先しておこないます。

### プロジェクトリーダー
プロジェクトリーダーとは、開発プロジェクトを進めるにあたって、開発現場の監督を担う責任者でPLと呼ばれています。プロジェクトリーダーの仕事は、要件定義や基本設計などの開発工程で滞りなく進んでいるか、テスト・チェックし、納品までの開発現場を管理します。

### プロトタイピングチーム
プロトタイピングチームとは、正式に開発するシステムの簡易版の設計や開発、テストを実施し、その詳細を社内メンバーに伝える役割を担った開発チームメンバーです。このとき、試作品に問題点や改善点が見つかった場合は、その解決策を頭に入れながら正式な開発を進めていきます。

### 開発チーム
開発チームでは、システムエンジニアやプログラマーが協力して、クライアントの要望通りのシステムを開発していいます。プログラマーは、プログラミングが仕事の中心となりますが、システムエンジニアはクライアントの要望をどのような手段で形にしていくかを目標として、プロジェクト全体を俯瞰し、開発を進めていきます。

### テストチーム
テストチームには、テストエンジニアと呼ばれる人が働いています。テストエンジニアとは、テスト計画から改善提案を行う工程を請け負う仕事をする人のことです。今まで開発プロジェクトにおけるテストは、システム開発経験の浅いプログラマーがおこなっていることがほとんどでした。しかし、最近は高いセキュリティを有するシステム開発が求められるケースが増えているため、レベルの高いテストを実施できるテストエンジニアの助けを求める声が増えています。

### ドキュメンテーションチーム
システム開発では、ドキュメントと呼ばれるシステム仕様書や使用方法がまとまった説明書・資料をもとにして、プロジェクトを進めていきます。たとえば、要件定義書や基本設計書、詳細設計書などがドキュメントとなります。長期的なシステム改善をおこなっていくのなら、丁寧なドキュメントが必要となるため、ドキュメンテーションチームで作成します。

# プロジェクト進行中のコミュニケーションについて
システム開発会社と依頼者でお互いに信頼関係を築くには、有益なコミュニケーションが必要不可欠です。

- 不明点について自ら積極的にコミュニケーションしていく
- システム開発という仕事に関心をもって、聞きたいことを聞いてみる
- いきなり相手の意見を否定しない

一般的なことではありますが、上記のポイントを意識できていると、お互いの立場を尊重しながら有益なシステムを開発できる可能性が高くなります。

# 納品物の確認方法
システム開発では、検収と呼ばれる受け入れテストをおこなって納品物の状態を確認します。検収では、次のようなテストを実施し、システムが設定された仕様を満たしているか調べます。

![slide2](https://corpsite-backend-staging-retool.s3.ap-northeast-1.amazonaws.com/whenoutsource02.png) 

上記のテストを実施し、成果物に問題がなければ検収書に押印をおこない、システム開発会社に提出します。

# 株式会社Jiteraへシステム開発を依頼する
外注だと気になるのが、発注者としての自社と、開発会社という、立場の違いによるプロダクトやサービスへの熱量の差です。発注側としては、開発という立場から課題解決のために伴走してくれるパートナーであってほしいものですよね。株式会社Jiteraでは、プロダクトマネージャーやエンジニア、デザイナーなどのグローバルでハイレベルなスキルを有するITスタッフがクライアントのビジネスの課題解決に全力で取り組みます。

大企業の中核事業はもちろん、新規サービスの立ち上げ、スタートアップのプロダクト開発などを推進してきた豊富な実績がございます。プロダクトの開発では、弊社独自の開発自動化プラットフォームを利用し、これまでにない早いスピードで開発していきます。本格的な仮説検証を素早くスタートできることが弊社の強みですので、ぜひご相談ください。

初めてシステム開発を外注化する場合は、丁寧な社内準備をしておくことで開発会社と認識にズレのない有意義なコミュニケーションが可能となります。しかし、システム開発のプロジェクト外注化の社内準備に関する情報は少なく、仮にあったとしてもエンジニア向けで内容がよくわからないと思っていないでしょうか。この記事を読むことでシステム開発における具体的な組織編成やプロジェクトの進行中のコミュニケーションの仕方、納品物の確認方法がわかりますので、ぜひ参考にしてください。

システム開発に外注を取り入れる際の社内準備

ローコード（Low-code）およびノーコード（No-code）は、プログラミングスキルのない非開発者でも、アプリケーションを開発することができるツールです。これらのプラットフォームは、コーディングスキルがなくてもアプリケーション開発ができます。そのため、ビジネスプロセスの自動化やカスタマーエクスペリエンスの向上など、多くの効果を期待できるでしょう。

また、アプリケーション開発に時間を費やすことができない企業にとって、最適な開発環境を提供します。

# ノーコードとはなにか？
ノーコードは、ドラッグ&ドロップのビジュアルインターフェイスを使用して、アプリケーションの作成やプログラムの実行を組み立てるプラットフォームです。名前のとおり一切のコーディングが必要なく、開発経験のない方であっても手軽に開発を進めることができます。

# ローコードとは何か？
ローコードとは、ノーコードと同じくビジュアルインターフェイスを使用してアプリケーションを開発できるプラットフォームです。手軽に開発を進められる点は共通していますが、ある程度のコーディングスキルが求められる点が異なります。必要に応じてコードを使用することで、高度なカスタマイズや機能を実装することが可能です。そのため、企業で主に用いられ、工数削減やエラー削減に役立てることができます。

# ローコードとノーコードの違い
どちらも、プログラミングの深い知識がなくてもアプリケーションを開発できる点は同じですが、それぞれに異なる点があります。

ノーコードは、プログラムコードを一切書く必要がなく、ローコードはアプリケーション開発に必要なコード量を最小限に抑えた手法です。主にビジネス用途でローコードが用いられ、ノーコードは簡単なアプリケーションを作成するために用いられます。

アプリケーション開発が簡単に行える点で両者は共通していますが、手軽さではノーコードが優れており、汎用性の高さではローコードが優れていると言えます。

また、ノーコードやローコードの対比として、従来の一般的な開発は「プロコード」と呼ばれます。

# ローコードとノーコードに共通する機能
プラットフォームに搭載される機能は、選択した製品によって異なりますが、ノーコードとローコードに実装される機能には一般的に共通点があります。以下にその共通機能について紹介します。

### 直感的に操作できるビジュアルインターフェース
ビジュアルインターフェイスとは、直感的で分かりやすいデザインを用いた操作方法です。視覚的な機能を活用することで、開発者はプログラムコードを書くことなく、アプリケーションの要素を簡単に作成し、構成を組み立てることができます。

### UI開発を効率化するコンポーネントライブラリ
コンポーネントライブラリとは、主にUI（ユーザーインターフェース）を作成するための機能であり、開発者は効率的にUIを構築することができます。

### 生産性を向上するワークフロー自動化
ワークフローエンジンを搭載することで、タスクの割り当てを自動化することができます。これにより、開発プロセスをより効率的にし、エラーを削減することができます。その結果、生産性の向上に役立てることができます。

### 一本化したデータベースおよびAPI統合
API統合とは、異なるシステムやアプリケーションのデータを連携するための機能です。ERPシステムやクラウドアプリケーションなど、アプリケーションは様々なシステムと連携することで効果を発揮します。API統合によって、開発者は容易にアプリケーションに必要な機能を追加できます。

### シンプルなモバイルアプリ開発
ローコードプラットフォームには、モバイル開発に適したビジュアルなデザインツールが備わっています。ドラッグ＆ドロップを使用したインターフェースやUIコンポーネントを簡素化することで、モバイルアプリ開発に必要なコーディングを最小限に抑えることが可能です。

### アプリを簡単に配置するワンクリックデプロイメント
ワンクリックデプロイメントとは、アプリケーションのソースコードをアップロードするだけで、プラットフォームが自動的にアプリケーションを構築・デプロイ（実行ファイルの配置）することができる機能です。ローコードプラットフォームによって、開発者は簡単にアプリケーションを作成し、デプロイすることができます。

# ローコードとノーコードの選び方
基本的には、ローコードもノーコードもプラットフォームの機能はよく似ています。しかし、実際に選ぶ際にはどちらを選ぶか迷うことがあるかもしれません。ここではプロジェクトの要件や目的、スキルレベル、予算、開発スピードなどに応じたアプリケーション開発の選び方について解説します。

### 予算に応じた選び方
自社で必要とする機能を自作できるローコードツールは、一般的にノーコードツールよりも高度な機能が必要になるため、高価になりがちです。価格で選ぶ際は、オリジナリティのある機能拡張を諦めて、ノーコードプラットフォームを選ぶことをおすすめします。

### スキルレベルに応じた選び方
ローコードツールはある程度の開発スキルが求められます。そのため、個人で利用する場合はノーコードツールが扱いやすいでしょう。エンジニアが常駐していたり人材育成の時間を取れたりできる場合は、ローコードプラットフォームを選ぶのが良いでしょう。

### プロジェクトの要件や目的に応じた選び方
基本的には、ノーコードで実現できる機能については、ローコードを選ぶ必要はありません。ただし、将来的な機能の拡張が必要な場合は、ノーコードでは対応できないことがあるため注意が必要です。高度な機能の拡張を計画している場合は、ローコードを選ぶのが良いでしょう。

# ローコードとノーコードの将来性
ローコードおよびノーコードの市場規模は急速に成長しており、今後も拡大することが予想されています。米Gartnerによると、2024年までに、ローコード市場は319億ドルに達すると発表されました。企業が効率的にアプリケーションを開発し、生産性を向上させる必要性が高まっているためです。IT部門でないユーザーの利用率も2021年の60%から2026年には80%まで達すると予想しています。今後はIT企業だけでなく、自社のシステム開発に予算を組む企業も増えてくることでしょう。

ただし、ローコードおよびノーコードがすべてのアプリケーション開発の問題を解決できるわけではない点には注意が必要です。複雑なシステムを構成するには、コーディングスキルが必要になることもあります。また、セキュリティ上の問題やプラットフォームの柔軟性の問題もあるでしょう。システム開発者を育成するなど、人的資源の確保が求められる点に変わりはありません。

# ローコードやノーコードで自社開発に挑戦しよう
先に説明した通り、ローコードやノーコードを使用することで、システム開発を効率化し、開発スキルのない企業でも独自のアプリケーションを作成できるようになりました。

将来的には、中小企業でもシステム開発者を採用して独自のアプリケーション開発を進める場合があるかもしれません。今までは予算の問題で外注できなかったシステム開発も、ローコードやノーコードを使えば自社開発を進められることでしょう。

関連記事 
[ノーコード開発に適したプロジェクトと進め方](https://jitera.com/ja/blogs/9) 
[ローコード開発に適したプロジェクトと進め方](https://jitera.com/ja/blogs/8)

ローコードとノーコードの違いと選び方

現在、多くの開発現場で採用されている方法としてノーコード開発と呼ばれるものがあります。ご存じのように、コードを書かない、すなわちプログラミングを行わない開発方法です。IT部門や業務サポートの現場の方々は、ノーコード開発とは何かということに関してはある程度の知識を持っているのですが、うまくいっていないプロジェクトも多いのが現状です。この記事ではノーコード開発を行うことをオプションとして検討している方に有益な情報をご紹介します。 
ノーコードと比較されることの多いローコード開発についてはこちら
👉[ローコード開発に適したプロジェクトと進め方](https://jitera.com/ja/blogs/8)

# そもそもノーコードツールにはどのようなものがある？
- Webflow 
Webデザインと開発をノーコードで行うことができるプラットフォームです。

- Zapier 
異なるアプリケーションやサービスを接続し、ワークフローを自動化するためのツールです。

- Airtable 
スプレッドシートとデータベースを組み合わせた、柔軟なデータ管理ツールです。

- Bubble 
カスタムWebアプリケーションを作成するためのプラットフォームで、コーディング不要でアプリを作成できます。

- Glide 
Googleスプレッドシートからモバイルアプリを作成することができるプラットフォームです。

- Notion 
ノート、タスク管理、データベース、ドキュメント作成など、多くの機能を組み合わせたプラットフォームです。

- Coda 
ドキュメントとスプレッドシートを統合したプラットフォームで、ワークフローを自動化することができます。

- Glide Apps 
Googleスプレッドシートからモバイルアプリを作成することができるプラットフォームで、Glideの派生版です。

- Adalo 
モバイルアプリを作成するためのプラットフォームで、コーディング不要でアプリを作成できます。

- AppSheet 
スプレッドシートからモバイルアプリを作成するためのプラットフォームで、コーディング不要でアプリを作成できます。 

# ノーコード開発のメリット 
### コードを書く必要がない
これによって、設計者がプログラム仕様書を作る必要が無くなり、専任のプログラマーも不要になることによって、そのためのコストが大幅に削減されます。さらに、仕様の変更やバグ修正もコード上では行われないために、変更管理や変更自体の工数も削減されます。これはとりもなおさず、アプリケーションのクオリティを保つことにもつながります。

### 開発にアプリケーション開発の専門家のスキルが必要ない
これによって、IT部門で高度なスキルを持つ設計担当のデザイナーなどの専門家の介在が必要なくなり、そのためのコストが削減され、場合によってはユーザー部門の担当者自身が開発を行うこともできます。これによって、ユーザーの知識や希望がダイレクトにアプリケーションに反映され、結果としてシステムのクオリティも上がります。さらに、開発が個人のスキルに依存するというジレンマも無くなります。 

# ノーコード開発の注意点 
### ノーコード開発の適用可能範囲を明確にすること
ノーコード開発は画期的な方法ですが、いまのところ適用できる範囲は限られています。それは各ツールによって違うのですが、できることとできないことをまず明確にしておかなければ、開発を行うことはできません。適用範囲外の部分の大きさや、重要度によっては、通常開発よりもかえってコストがかかってしまうこともあり得ます。

### ツールの使用方法に精通すること
ノーコード開発において、少ない工数で効果的なアプリケーションを作るためには、使用するツールの操作方法と構造などを理解する必要があります。ここは、何を行う場合であっても必須となるので、時間をかけるべきです。しかし、そもそもそのツールのGUIが直感的でなく、操作方法が独特であるとその習得に時間がかかってしまいます。したがって、最も効果的なのは、まず使いやすいツールを選択することです。また、可能な場合には、ツールの提供ベンダーに開発に参加してもらうことによって、時間がかかる教育と本来の開発を同時に行うという選択肢もあります。

### 実行環境の制限を理解すること
ノーコード開発で使用されるツールの多くは、実行環境を限定します。実行環境に前提となるソフトウェアの導入が必要になり、ツールによってはベンダーロックインを招くこともあります。そうなると、既存の仕組みが動かなくなるという理由で、環境のアップグレード時に高額な費用やライセンス料を請求されることもあり、場合によってはサービスの中止という事態によって、現有資産が無駄になるということもあり得ます。

それを防ぐためには、特殊な環境を前提としていないか、ベンダーロックインの可能性があるかどうかなどを事前に十分に調査する必要があります。多くのベンダーのホームページ上などには、そのあたりの情報が記載されていないこともあるので、契約前に明示的に確認するのが安心です。 

# ノーコード開発の進め方
ノーコード開発には、それに適した進め方というものが存在します。逆に言えば、適していないやり方で進めると、コストの増加や開発の成果物のクオリティの低下を招くとも言えます。ここでは、ノーコード開発に適した開発のやり方に関して説明します。

1. 開発手法 
そもそも、ノーコード開発と相性が良いのは、要件定義や概要設計の比重が高いウォーターフォール型の開発よりも、短いスパンで改良を重ねてゆくアジャイル開発の方です。特に、フットワークの軽さや、設計変更への対応の容易さがノーコード開発のメリットなので、そのメリットを生かすやりかたを選択することが重要です。

1. 要件定義や概要設計 
ノーコード開発においては、ユーザーの要件を目に見える形にしながら同時に開発を行うことができます。したがって、要件定義や概要設計のフェーズは、ヒアリングとフィードバックに時間をかけるべきでしょう。特に簡単に作ることができる画面の構成やサンプルのデータなどを見せることによって、本来の要件が明確になるという部分はそのあとのフェーズにも生かされます。

1. 詳細設計とコーディング 
ノーコード開発の基本はコードを書かないことなので、プログラム仕様書レベルの詳細設計は通常は必要ありません。ここで重要なのは、処理イメージの共有です。特に処理に使われるデータの見える可によって、イメージも明確になります。

1. テスト 
ノーコード開発におけるテストそのもののやり方は、コーディングを行う開発と大きな変わりはありません。テスト環境を作って、様々なテストデータを用意することによってアプリケーションのテストを行います。ノーコード開発に特有な点としては、テストでうまくいかなかった部分の再テストがすぐにできるということで、それによってテストのリトライの場合の検証も簡単に行うことができます。

1. メンテナンス 
アプリケーションの不具合対応や小規模な機能拡張のフェーズにおいても。ノーコード開発のフットワークの軽さと変更の容易さによって、短い時間で実現することができます。ここで重要なのは、変更情報をチーム間で共有することです。ツールによってはその機能を持っている場合もありますが、ツール外に仕組みを構築する必要がある場合もあります。 

# ノーコードツールの選び方
ここまで、ノーコード開発を行うにあたって重要だと思われることを説明してきました。そのなかの多くの部分で記述したように。ノーコード開発を成功に導くキーポイントは、どのノーコードツールを選択するかということです。逆に言えば、適切なツールを選択すれば、何かあってもある程度の修正はできるとも言えます。それでは、ツールを選ぶ際に重要となる基準を見ておきましょう。

### ツールの使いやすさ
重要なポイントはやはり使いやすさと修得の容易さです。これはすでに「ノーコード開発の注意点」で述べたように、使いやすさが継続して使用するための最も重要なファクターだからです。多くの場合はツールの使いやすさよりも機能的な面に目が行きがちですが、実際にはいくら豊富な機能を持っていても、使いやすくなければ作業ははかどりませんし、開発自体できません。さらに、前述のように、ツールのサービスプロバイダーが開発に参加できるようなスキームを持っていることも大きなアドバンテージになります。また、多くの海外製のツールの日本語化の状況も考慮する必要があります。

### ベンダーロックインの回避
いかに優れたツールが提供されていたとしてもベンダーロックインを前提とする仕組みは、特に開発後のフェーズにおいては大きな足かせになります。前述したように、特殊な実行環境やベンダーロックインを要求するようなツールは後々コストがかかることを考慮すべきでしょう。

### 使用状況にフィットする料金体系
機能や使いやすさだけではなく、やはりコストも重要なファクターであることは言うまでもありません。しかし、その基準は絶対的な価格ではなく、どのような料金体系であり、それが自分の使用方法にフィットしているのかということです。単純な例でいえば、使用するユーザー数が多いという状況では、ユーザー数をベースにしたものより、機能やサーバーのサイズでの課金などが適しています。また、そもそもサブスクリプションなのか、ワンタイムの支払いなのかも、後々のメンテナンスや継続開発の予定を考慮する必要があります。 

ここまで、ノーコード開発に関して、そのメリットや注意する点、ツールの選択ポイントなどを解説してきました。実際にノーコード開発を行ってきた人たちの共通の感想としては、思っていたのとは違うということです。これは、事前に必要な調査を十分に行わないでツールややり方を決定したことに起因すると思われます。それを回避するために最も重要なのはツールに対する理解でしょう。この記事の内容を検討して、失敗のない開発を実現していただければ幸いです。

 ノーコード開発に適したプロジェクトと進め方

ローコード開発とは、必要最小限のコードを記述しながら開発を進めていく開発手法、またはサービスのことです。類似するものとしてノーコード開発と呼ばれるものがありますが、こちらは全くコードの記述を行いません。コードの知識がなくても操作できますが、開発の自由度がフルスタック開発などに比べると低いことが大きな特徴です。 

ローコードと比較されることの多いノーコード開発については 
[ノーコード開発に適したプロジェクトと進め方](https://jitera.com/ja/blogs/9)

ローコード開発は、開発効率を上げられるのはもちろん、開発コストを下げられる魅力的な開発方法ですが、どのようなことにでも対応可能な開発手法ではありません。 初めてのローコード開発ならどのようにツールを選びプロジェクトを進めていけば良いかもわからないというのが本音でしょう。

実際、使ったことのあるエンジニアも3割 < Jitera調べ：[ローコードツールに関する調査結果発表](https://jitera.com/ja/news/7) >。少なく感じませんか？ その数字にとどまってしまう理由を探っていきましょう。 

# ローコード開発のメリット
### 技術スキルの要求が低い 
ローコード開発では、高度な技術スキルが必要ないため、開発者が手軽にアプリケーションを作成できます。このため、開発に伴うハードルが低くなり、気軽に開発に参加できます。 

### 初心者でも使いこなすための学習環境が整っている 
ローコード開発には、様々な学習環境があります。ローコード開発書籍はもちろん、動画学習チャ ンネル、専用コミュニティなど、学習者に合った学習方法がそろっています。そのため、プログラミング初心者でも学習障壁を感じることなく着実に理解を深められます。
 
### 短時間でアプリケーションを作成できる 
ローコード開発は、プログラミングへの深い知識がなくても、直感的な操作と基礎的なコードの知識で、素晴らしいアプリケーションを作成できます。ノーコード開発ではないため、もし社内にプログラミング経験者がいる場合は、プロジェクトのレベルを上げていける可能性があります。
 
### 設計の見える化により低リスクで開発ができる 
ローコード開発は高度な技術スキルが不要であり、視覚的なインタフェースを採用しているため、「設計の見える化」によって低リスクで開発できるメリットがあります。仮に開発ミスがあったとしても、視覚の要素から問題のある箇所を素早く見つけ、修正することができます。また、設計情報に対応するプログラムを自動的に作成する機能も搭載されているため、開発時間の大幅な短縮はもちろん、エラーの発生を手軽に防げます。 

# ローコード開発の注意点 
ローコード開発は、少しのプログラミングの知識でサービスを開発できるため非常に魅力的ではありますが、次のような注意点もあります。 

### 開発ツールの能力に依存している 
ローコード開発は、最低限のコードの知識ですぐれたサービスを開発できますが、次のような開発には利用をおすすめできません。

- 会社の規定によって、独特な開発方法でプロジェクトを進めなければいけない 
- 決まったデザインで開発しなければいけない 
- あらゆることをシステムで実現したい 

上記のような場合、開発ツールの能力に依存してしまうローコード開発は、その能力を発揮しづらくなります。高度なアプリケーション開発を行いたいという場合は、フルスタック開発か、自動化ツールとエンジニアリングをハイブリッドで組み合わせるJITERAで開発していくことをおすすめします。 

### 利用方法を覚えるための学習が必要となる 
ローコード開発で開発プロジェクトを進めるには、ツールの利用方法を覚える必要があります。 様々な機能を利用して、複雑なアプリケーションを設定していく場合、操作方法を覚えるのに数日程度必要となるため、開発に着手するまでに少しだけ時間を必要とします。 

### 複雑な開発は苦手
ローコード開発の開発ツールは、基本的な開発を得意としていることが主な特徴となります。一方 で、複雑な開発については、非常に不得意であり、動的なアプリケーションの開発には向いていません。 たとえば、視覚的要素で顧客にアピールしたいコンテンツやリアルタイムで変更なるチャートの実 装などが開発要件に含まれる場合は、一般的な開発をおすすめします。 

# ローコード開発の進め方 
ローコード開発のプロジェクトの進め方は次のとおりです。
 
### 1. 要件定義を行う
ローコード開発を使って、どのような開発を行いたいのか、その仕様を要件定義していきます。 しっかりとした要件定義を行っておけば、開発期間のズレやコスト増加による問題を防ぎやすくなります。

### 2. ローコード開発ツールを選ぶ
検索エンジンで「ローコード開発ツール」と検索すると、たくさんのツール紹介記事が公開されてい ます。先程、作成した要件定義をもとに、機能性や値段、制限の範囲などを見比べて、自社開発 にぴったりなローコード開発ツールを見つけていきます。

### 3. 使い方を学習する
自社で利用するローコード開発ツールが決まったら、利用方法について学習していきます。ツールによって固有の利用方法があるため、ローコード開発に必要な知識を深めていきましょう。

### 4. 試作品を開発する
ローコード開発ツールの利用法がわかったら、最低限のコードを使ってシステムの試作品を作成します。要件定義と見比べながら、ユーザーの合ったシステムを構築していきます。

### 5. 正式開発後にテストを実施し、運用を開始する
試作品によって具体的な全体像が決まったら、正式な開発を進めてきます。実際に開発が完了したら、動きに問題がないかテストを行います。テスト後は、ユーザーの反響に耳を傾けながら、メン テナンスを繰り返すことで、優れたサービスを提供していきます。

# ローコードツールの選び方 
### 機能性から選ぶ 
ローコード開発ツールといっても、ツールによって機能性が異なります。この場合、開発要件と照らし合わせながら、どのツールならほとんどノーコードで開発できるかを考え、選定を行っていきます。ローコード開発に伴う工数を抑えるためにも、複数のツールから機能を見比べましょう。 

### 拡張性から選ぶ 
ローコード開発ツールは、開発が終われば、その役割を終えるわけではありません。開発後にも利用することをイメージして、ツール選びをしなければいけません。なぜなら、「こういった機能を追 加してください」といった顧客の要望に対応できなくては、困るからです。 そのため、どの程度までなら拡張できるのか、外部機能との連携範囲や拡張の自由度も合わせて見比べていきましょう。 

### セキュリティレベルから選ぶ 
機能性や拡張性が高くてもセキュリティレベルが著しく低ければ、そのローコード開発ツールは利用できません。特に顧客の個人情報を扱うようなウェブサービスを開発する場合は、ツールのセキュリティレベルも選定の基準となるため、安全性の高いツール選びを行いましょう。 

ローコード開発ツールを利用したプロジェクトならJiteraへお任せください。Jiteraは、他社と比べて開発効率はもちろん、スピード、クオリティ、自由度が高いことが特徴です。お問合せ、見積もりはこちらまでお願いします。

ローコード開発に適したプロジェクトと進め方

システム開発会社の見積もりが想像していたよりも高かったという思いは、開発見積もりをおこなう方なら、だれしも一度は経験があるかもしれません。

そこで、今回は高いシステム開発会社からの見積もりが高いと思った際に、どのようなポイントをチェックするべきなのか、相見積もりを価格だけで判断してはいけない理由や開発会社との交渉のポイントについてわかりやすく解説していきます。

システム開発会社の実績や信頼性、開発の品質やスピード、コストパフォーマンスなど、重要な要素を確認し、最適な判断を下すためのポイントをご紹介しますので、高い見積もりに困っている方は、ぜひこの記事を参考にして、安心してシステム開発を進めていただければと思います。 

# 見積もりが想定より高い場合のチェックポイント
システム開発会社の見積もりが高い場合には、次のポイントをチェックしてみましょう。

### 要件定義の明確化
開発要件が明確でない場合、システム開発会社はさまざまな予測をおこない、その分コストが上がるケースがあります。そのため、要件を明確化し、納得できる見積もりが提示されるまで再度話し合いをおこなってみましょう。

### 開発期間の見直し
開発期間が長期化、または納期までの期間が短いと開発費用が高くなる傾向があります。見積もりが高い場合は、開発期間が現実的であるか確認し、余裕をもった見積もりを提示してもらうようにすることで費用を抑えられる可能性があります。

### 開発手法を確認する
システム開発には、ウォーターフォール型やアジャイル型など様々な開発手法があります。開発手法によって、見積もりが異なることがありますので、どのような開発手法を採用するのか確認することが大切です。

### 開発担当者の技術レベルを確認する
システム開発会社によっては、開発担当者の技術レベルに差がある場合があります。開発担当者の技術レベルを確認し、必要に応じて開発担当者の人数や役割を見直してもらうことで費用を抑えやすくなります。

### 製品の品質や保守・運用にかかる費用を見直す
開発費用の見積もりには、開発だけでなく製品の品質や保守・運用にかかる費用も含まれることがあります。これらの費用が高い場合、製品の品質や保守・運用のクオリティが高いといえる場合があります。

これらのチェックポイントを確認したうえで見積もりが高い場合は再度話し合いをおこない、見積もりを調整するようにしましょう。 

# 相見積もりを価格だけで判断してはいけない理由
システム開発をアイミツの価格だけで判断することは、次のような理由からやめておきましょう。

### 必要な機能への対応力がない
システム開発では、必要な機能をすべて実装し、正しく動作することが求められます。そのため、アイミツの価格で提供されるサービスは、必要な機能を実現できるかどうかを確認する必要があります。低価格であっても、必要な機能への対応力が不足している場合は、結果として開発期間や運用期間において無駄なコストにつながります。

### 品質と信頼性が低い
システム開発においては、品質と信頼性が重要な要素となります。アイミツの価格で提供されるシステムの品質が低く、信頼性が低い場合、そのシステムを使用することによって大きな被害を受けることがあるため、それらの要素にも十分に配慮する必要があります。

### サポートとメンテナンスが不明確
システムの開発後には、運用やメンテナンスが必要になります。アイミツの価格で提供されるサービスが運用やメンテナンスに対して十分なサポートを提供していない場合、サービス公開後やトラブル発生時に困ることになります。

### 将来的な拡張性がない
システム開発では、将来的な拡張性を考慮して会社選びをおこないましょう。なぜなら、ユーザーからの満足度を上げるには、システムに機能を追加して、次々と要望に応えていく必要があるからです。そのため、アイミツの価格で提供されるシステムが将来的に追加の機能や拡張性をサポートできるかどうかを確認する必要があります。

以上の理由から、システム開発を相見積もりの価格だけで判断せずに、価格以外の要素を総合的に判断しましょう。 

# システム会社への発注をする際に重要視するべき要素

### 評判や実績の高さを優先する
システム会社の評判や実績は、その信頼性や技術力を測る上で非常に重要です。具体的には、過去にどのようなプロジェクトをおこない、その成果物がどの程度の品質で納品されたかを確認することが必要です。

また、顧客からの評価や評判が高いかどうかも確認しましょう。これらの情報は、インターネット上で検索したり、システム会社のホームページやSNSでの発信内容をチェックしたりすることで具体的な情報を見つけられます。

### 要件への対応力や性能の高さを優先する
要件への対応力やシステム性能の高さを求める場合、どのようなシステムやソフトウェアを提供しているのか、それらがどのような機能や性能を持っているのかを把握しましょう。そして、提供されるサービスや製品が将来的にも継続的にサポートされることが保証されているかを確認することも大切です。

### プロジェクトマネジメント能力を優先する
プロジェクトマネジメントには、スケジュールや予算の管理、品質管理、リスクマネジメント、コミュニケーション能力などが含まれます。事前にどのような能力を持っているかを確認し、信頼できるプロジェクトマネージャーが担当してくれるかどうかを確認しましょう。

### 技術力を優先する
システム会社が必要な技術力を持っているかどうかも、プロジェクトの成功に影響を与える重要な要素です。必要な技術が何かを明確にし、それを実装できるスキルを持っているかどうかを確認しましょう。また、最新の技術やトレンドにも詳しいかどうかも重要です。プロジェクトの成功には、常に最新の技術やトレンドに沿ったサービスの提供が欠かせません。

### 契約条件を優先する
システム会社との契約条件は、発注者にとって非常に重要な要素です。具体的には、納期や価格、サポート体制、保証、契約違反時の罰則、プロジェクトの進捗状況を報告する頻度や報告書の内容などを明確にしておきましょう。また、契約条件には、著作権や知的財産権に関する条項も含まれます。必要に応じて、法的アドバイスを受けることをおすすめします。

### サポート体制を優先する
システム会社が提供するサポート体制も、プロジェクトの成功に重要な要素の一つです。システムの保守やサポートが必要になった際、迅速で適切な対応ができるかどうかを確認しましょう。また、システムトラブル発生時の緊急対応についても確認しておくことをおすすめします。

### 価格を優先する
システム会社が提供するサービスや製品の価格は、プロジェクトの予算にも大きな影響を与えます。ただし、単純に価格が安いからといって、必ずしもそのシステム会社が最適な選択肢とは限りません。必要なサービスや品質に対して、適切な価格が設定されているかを確認し、コストパフォーマンスを検討しましょう。

### 目的と要件を明確にする
最初に何を達成したいか、必要な要件は何か、目的と要件を明確にすることが重要です。会社として、どのようなシステムが必要か、どのような機能が必要か、予算はどの程度かなど、可能な限り具体的に決定しておくとシステム会社との交渉がしやすくなります。

### 交渉の席で自分の立場を明確にする
交渉の席では、自分の立場をはっきりと伝えることが重要です。予算や期限に関する制限がある場合は、そのことを開発会社に伝え、可能な範囲で最適な提案をしてもらうようにしましょう。

### 良好な関係を築く
システム開発会社との交渉は、長期的なパートナーシップを築くことで有利な条件を提示してもらいやすくなります。そのため、できる限り開発会社との良好な関係を築き、信頼関係を構築しましょう。

# 見積もりが高いと思ったら株式会社Jiteraへ相談しよう
株式会社Jiteraは、システム開発のプロフェッショナル集団としてビジネス上の課題を解決するためのベストな技術やサービスを提供しています。弊社は、システム開発をご依頼になられる会社様へサービスを提供するために、グローバルでハイレベルな技術者や経験豊富なプロジェクトマネージャーを含めた強力なチームを結成しています。

最新の技術を駆使して高品質なシステム開発をおこない、高機能でコストパフォーマンスに優れたシステムをご提供しておりますので、見積もりが高いと思われた方は、ぜひ弊社へご相談ください。

関連記事 
[システム開発で押さえるべきポイントとコスト削減のために知っておきたい費用の相場](https://jitera.com/ja/blogs/5) 
[システム保守で発生する費用とは？](https://jitera.com/ja/blogs/23)

システム開発会社の見積もりが想像していたよりも高かったという思いは、開発見積もりをおこなう方なら、だれしも一度は経験があるかもしれません。そこで、今回は高いシステム開発会社からの見積もりが高いと思った際に、どのようなポイントをチェックするべきなのか、相見積もりを価格だけで判断してはいけない理由や開発会社との交渉のポイントについてわかりやすく解説していきます。

ブログ