通常、ITシステムの開発は一括請負で契約するのが一般的ですが、そこには構造的な問題も含まれております。一括請負とは依頼された要件（成果物）を納期までに作成し納品する事です。長年IT業界に従事しているわたしたちもこの「一括請負」を採用し、時には苦労してきました。 何が問題かというと、将来使おうとしているシステム（成果物）を現時点で定義している点にあります。ビジネスは成長するものです。またビジネス環境も目まぐるしく変わります。その時点で想定する事は半年後には状況が変わっている場合もあります。 せっかく作ったとしても納品するタイミングでは状況が変わり、利用されないか、仕様変更が必要となる可能性があります。また、開発側も納期が設定されているので要望された仕様を期日通りに納めるのが目的となりがちです。システムを利用して業務が改善するのが本質のはずですが、こういった構造的な問題の中で発注側と受注側で意識の相違が生まれます。 この状況に違和感を感じ、どうにかして両者とも同じゴールを共有しながらシステム開発ができないものかと考えていたのがStrution誕生のきっかけです。