開発対象とする機能を厳選することで、無駄な費用を省き、トータルコストを抑えます。
「開発対象が少なくなるなら、費用が安くなるのは当たり前でしょ？従来型と何が違うの？」と思われるかもしれません。
しかし、従来型のシステム開発では、無駄な機能も開発対象になってしまう事情があるのです。
私たちはこの問題を、アジャイル開発手法の導入により解決いたします。

最初に取り決めた仕様に従って開発し、納品したらさようなら。
このような従来型の開発では、依頼者である皆さまと開発会社とで目指すゴールがすれ違ってしまうことが多々あります。
これでは皆さまにご満足いただけるシステムにはなりません。
そこで私たちは、最後まで責任をもってご支援させていただくため、あえて月額固定契約を選択しました。

システム開発会社に開発を頼んで出来上がりを楽しみにしていたのに、いざ納品されてきたものが思っていたものと違っていた。
これも従来型のシステム開発では頻繁に発生する問題です。
最初に仕様を固めて一気に開発を進めてもらい、納品したら一括で費用を支払う、という作業フローがその原因となっています。
アジャイル開発手法を使えば、短期間のうちに動作するシステムを確認できるため、このような問題が起きにくいのです。

「ウォーターフォール（Waterfall）」とは「滝」のことです。
ウォーターフォール開発についてはよく、「水が滝を流れ落ちるように、上流から下流へ向かって逆流することなくプロセスを進めていく開発手法」という感じで説明されます。
ここでいう「上流」とは、何を作るかを決める「要件定義」と、どのように作るかを決める「設計」のフェーズを指します。
「下流」は、実際にシステムを実装する「プログラミング」と、それが正しく動作するかを確認する「テスト」のフェーズです。
厳密にいうと、フェーズはより細かく分かれますし、「逆流」も絶対にダメという話ではないのですが、大枠としては上記のような流れで開発することを「ウォーターフォール開発」と呼びます。

「請負契約」とは、仕事を発注する「注文者」と、その仕事を担当する「請負人」の間で交わされる契約です。
請負人には、契約に定義された内容の仕事を、指定された期間までに完了させる義務が発生します。
一方、注文者は、完了した仕事に対して、契約時に定められた報酬を支払う義務があります。
こうした契約の特性上、システム開発を請負契約でおこなうときには、契約締結前に仕様と納期を確定し、報酬について両者が合意する必要があります。

ウォーターフォール開発で注文者がプロジェクトにかかわるのは主に最初の「要件定義」と最後の「テスト」の工程です。 つまり、最初に何を作るか決めてしまえば、あとは納品されてくるのをじっと待っていればよいのです。
納品されたものに不具合があったとしても、請負人には作業の完成義務があるため、契約時に約束した費用の中で不具合も修正してくれます。 ですから、注文者にとっては、お金を払ったのに頼んだものが出来上がらないというリスクを最小化することができるのです。

請負契約では、スコープ（作業範囲）、コスト、納期が最初に決まっているため、計画が立てやすく、プロジェクトの状況把握（当初計画と実績の差分追跡）もしやすいという特徴があります。
また、作業が順番に流れていくため、各フェーズで必要とされるリソース（人材、場所、機器など）を効率よく確保し、不要になったらすぐにリリースすることができます。
このように、請負人にとってプロジェクトの管理がしやいのが、ウォーターフォール開発と請負開発の組み合わせなのです。

上述のメリットはいずれも、契約時点で仕様が決まっていることが前提に生まれるものでした。
問題は、そもそも最初にすべての仕様を確定させることが可能か？ということです。
既存業務の効率化が目的というプロジェクトであれば可能かもしれません。 しかし、多くの企業ではそのようなプロジェクトはすでに実施済みで、今は新規ビジネスの立ち上げなど、本業の業績に直接影響するような性質のプロジェクトが主流となってきています。
このようなプロジェクトでは、正解が最初から分かっているわけではありません。仮説をもとに戦略をたてて実行し、結果を検証して方向を修正する、といった、「ライトパス」を探す試行錯誤が不可欠です。
このようなとき、「最初に仕様を決められないと開発プロジェクトに入れない」という従来型の開発では太刀打ちできません。

請負開発はその性質上、プロジェクトの開始時点で仕様を確定させなければなりません。
契約締結後に「あ、あの機能も必要だった」と気が付いた場合、もちろん追加費用を支払えば開発会社は対応してくれるケースがほとんどです。
ですが、発注のご担当者様にとってみれば、また社内で決裁を取らなければならず、そのための工数はなかなかバカにならないでしょう。
そうした事態を避けるため、プロジェクト初期段階では、抜け漏れがないよう関係各所からたくさんの希望を聞き、あれもこれも仕様に詰め込んでしまいがちです。
結果として、「作ったはいいけど誰も使わない」機能が出来上がり、あとから「あの機能を付けなければもっとコストを抑えられたのに」と後悔するケースが出てくるのです。

システム開発プロジェクトには時間がかかります。構築対象システムの規模によりますが、数か月、場合によっては数年をかけて実施することもあります。
それだけの時間が経過すると、ビジネス環境には多かれ少なかれ変化が起きます。 プロジェクト開始時点では不要と思った機能、あるいは想定もしていなかった要件が、時間の経過とともに必須の機能になることも十分に考えられることです。
ですが、請負契約では原則として、契約時点で定められた要件を満たすシステムを作って納めるのが開発会社の責務です。
仮に、開発会社に変更要求を受け入れてもらえず、当初予定の作業を終えてから仕切り直しということになっても、契約上は文句が言えません。

プロジェクトの初期段階で希望する仕様（要件）をシステム開発会社に伝えた後、実際にシステムが出来上がるまでの間、お客様が目にするのは書類（要件定義書、基本設計書）だけ、というのがウォーターフォール開発の典型的なパターンです。
この間、その書類を読み解くこと以外に、開発会社が理解した仕様がお客様自身が思い描いた内容とずれていないかを確認する手段がありません。
結果として、開発会社が一通りの作業を終えて納品してきたものをチェックしたときに初めて双方の認識の食い違いが発覚する、ということが多発します。
開発会社の明らかな誤認やミスであれば修正してもらうことが可能ですが、最終納品とシステムの稼働が予定より遅れてしまいかねません。
さらには、お客様がいったん確認した書類どおりに作られていた（どちらとも解釈できるような書き方であった、お客様が間違いを見逃した）ということになると、修正をしてもらうのに追加費用を支払うなどの譲歩が必要になる可能性もあります。

アジャイル開発の場合、おおむね2～4週間を一区切りとして、開発作業と納品を繰り返していきます。
プロジェクト開始時点でおおよその全体像を決めておくことは、お客様と開発者の共通理解を深めるうえで有意義ですが、具体的な仕様は次の区切りで開発する機能についてだけ詰めておけばよいとされます。
ですから、新規ビジネスの立ち上げなど、正解のわからないシステムの開発であっても、プロジェクトが開始できないということは起きないのです。

アジャイル開発では、システムを実際に使用するシーンを想定して利用者とシステムとのインタラクションを考え、それを今後開発するリストにどんどんと追加していきます。
2～4週間の開発期間の最初に、今回はどの部分を開発するか、リストから最重要と思われるものから順にピックアップして決めます。
このような進め方をすることで、最初は入れておいたほうがいいかもと思ってリストに入れたものの、実際に誰がいつ使うのかあいまいな機能はどんどんと後回しにされるため、不要な機能を作りこむ危険を避けることができます。

開発対象のリストは、お客様がいつでも好きなように変更することができます。
システム利用者により大きな価値をもたらす機能を思いついたとき、法改正等の外的環境変化があって当初は必要と思った機能が不要になったとき、いつでもリストの追加や変更、削除をしていただいてかまいません。
追加した機能が、以前からリストのあった機能よりも重要だと判断されれば、次の開発期間にはその機能を実装します。
開発する順番と対象をプロジェクト期間中はいつでも自由に変えられるというアジャイル開発の特徴が、必要な機能を必要なタイミングでご提供できるというメリットにつながっています。

1回の開発期間を2～4週間に区切ることで、お客様に頻繁に出来上がったシステムをご確認いただくことができます。
また、お客様と開発者との間のコミュニケーションを重視するアジャイル開発では、双方から頻繁に仕様の確認が行われるため、認識の差異を最小限に食い止め、また差異の発生に素早く気が付くことが可能です。
万が一、双方の食い違いに気が付かずに1回の開発期間が終了してしまった場合でも、その違いの解消が重要だと判断されれば、次の開発期間でその調整をすることが可能です。

従来型の請負契約では、契約締結時点での作業範囲と成果物の定義が欠かせません。
しかし、これらを最初に決めてしまうことは、いつでも仕様の再検討が可能というアジャイル開発の特長を消してしまうことにつながります。
そのためライトパスでは、いわゆる請負契約という形はとりません。かわって、以下のような内容で契約を締結させていただきます。

• お客様が定めたビジネス目標を達成するために不可欠なシステムの開発と運用保守を作業範囲とする。
• 開発成果物は、2～4週間の開発期間の都度取り決めることとする。
• 上記に対する費用は、月額定額制とする。

成果物の納品に力点の置かれる請負契約より、役務の提供に力点を置いた準委任契約に近い内容となっています。
ただし、アジャイル開発の基本理念に従い、動作するシステムの提供を何より重要と考えています。2～4週間の開発期間の最後には、新たな価値を提供するシステムを必ずご利用いただけるようにすることをお約束いたします。
とはいえ、開発会社側に完成責任を負わせないこの契約では、お客様側にもリスクが発生することは否めません。
会社の規定上、あるいはリスク・マネジメントの観点からこのリスクは受け入れられない、という場合は、従来型のシステム開発サービスをご検討ください。

従来型の開発であれば、お客様はプロジェクトの最初に仕様を決め、最後に納品物をチェックするだけで済みます（実際はプロジェクト中盤でも、システム開発会社からの質問に答える必要はありますが）。
しかしアジャイル開発では、いつでも仕様を変更できる、こまめに出来上がりをチェックできるというメリットの裏返しとして、契約期間を通してお客様も密に作業に参加をしていただく必要があります。
また、その名の通り「アジリティ」（俊敏性）が成功のカギを握るため、単なる中継役ではなく、仕様に関して決定権のある方に作業に加わっていただく必要があります。
これはお客様にとって、相当の業務負担になることが想定されますが、お客様のビジネスの成功に本当に寄与するシステムを作るためには不可欠な要素です。
開発者との協業時間を長期にわたって確保することが困難な場合は、関与の時期を限定できる従来型のシステム開発サービスのほうが適しています。

ウォーターフォール開発では、「逆流」防止のために、各フェーズの完了を判定するレビューが実施されます。 レビューの対象はドキュメント（要件定義書、設計書、テスト仕様書、テスト結果確認書など）となることがほとんどです。 そして、このレビュー済みドキュメントを成果物として納品することが請負契約書に定義されることとなります。
しかし残念なことに、フェーズ完了基準を満たすかをチェックすることより、納品物としての体裁を整えることが目的になってしまったうことがあります。 不要なドキュメントまで作成されてしまったり、体裁を整えるために余計な手間をかけてしまったりすることも少なくありません。もちろん、それにかかる時間も契約金額に上乗せされます。
いっぽうアジャイル開発では、納品のためのドキュメント作成よりも、実際に価値を生み出すシステムの提供を重視します。
作業に必要不可欠なドキュメントは作成しますが、それは単なる手書きメモであったり、メールやチャットのログであったりします。
監査等の関係で整備された仕様書が一そろい必須といったケースでは、それに対応しやすい従来型システム開発サービスをお勧めいたします。