Purpose（存在意義）

ソフトウェアの価値は、画面に見える機能だけではありません。

要求の明確さ、内部品質、保守性、ドキュメントの整備といった見えにくい部分にこそ、開発の信頼性は宿ります。

私たちは、そうした誠実な仕事を見える形に整え、顧客も技術者も納得できる開発のあり方を広げていきます。

 

以下のような経験はありませんか？

• 開発をお任せしたら、欲しいものと違うものが出てきた。
• 修正や機能追加を依頼すると、予想をはるかに超える見積りが出てきた。
• 或いは、修正や機能追加がもうできないと言われた。
• 保守対応が高額であったり、対応に時間がかかる。
• 基幹システムの開発元が倒産してしまい、システムの維持が困難になった。

 

我々の業務で、動くソフトウェアを作る（コーディング）部分は本当に一部です。

作業工程	成果物
要求定義	要求定義書（要求仕様書）
基本設計	基本設計書
詳細設計	詳細設計書
開発環境整備	開発環境
コーディング	ソースコード
単体テスト	単体テスト結果
機能テスト	機能テスト結果
総合テスト	総合テスト結果
運用テスト	運用テスト結果
その他のテスト	その他のテスト結果 ※必要に応じて実施
保守環境整備	保守マニュアル
運用環境整備	運用マニュアル

上記のうち、お客様が目にするのはコードによる実際のソフトウェアの動作と、せいぜい運用マニュアル程度だと思います。

 

要求定義が曖昧だと、欲しいものと違うものが出てきます。 基本設計が悪いと、修正や機能追加時に余分な工数がかかります。 基本設計書や詳細設計書が残っていなかったり質が悪かったりすると、修正そのものができない事があります。 要求定義、基本設計時に保守・運用のことが盛り込まれていないと、保守がままならない事があります。 上記のようなドキュメントに不備があると、ソースコードだけがあってもシステムの改修ができないことがあります。

 

保守、改修等を考えた場合、ソースコードのみで運用を開始することはありえません。 逆に、すべてのドキュメントを整備するのは、コスト的に負担が大きくなります。 お客様の業務規模によって、最適なシステム規模・開発プロセス規模があります。 私たちは、ソフトウェア開発の業界の価値がより正しく伝わるように努力いたします。