上流工程では
特徴的なこと（他社にはないもの）
ユーザー要件を視覚的に分かりやすい資料にとりまとめます。これは要件定義の段階でユーザーと開発者の間で「どのようなシステムをつくるのか？」という認識を共有するうえでとても重要です。
エモーションソフトでは「どういう動きをするアプリケーションなのか？」ということを具体的な画面イメージのフローで示し、それを元にユーザーと一緒に検討しながら仕様を固めていく方法を採用しています。
業務フロー全体の中でアプリケーションが使用される場面を説明する資料と合わせてご覧いただくと、システムの全体像を直ぐにご理解いただくことが出来ます。
１０の説明文よりも１つの図の方が、より多くの情報をユーザーと共有可能。そういう説明資料をお客様に提供することで多くのユーザーに喜ばれています。
当たり前のことでも
- 機能説明書や概念スキーマ設計書（E/R)等の標準的な外部設計書においても、ユーザーに分かり易い資料を作成することを目指しています。
- 応答速度やデータストアの容量、障害耐性／セキュリティー対策などの非機能要件を細かくチェックして、必要なシステムリソースのサイジングまたはクラウドの使用を提案します。コストとの兼ね合いを見たキャパシティープラニングを実施します。
- 実際にプログラムを作る立場からアプリケーション機能の難易度や開発コストを測定し、最適な機能設計を行います。
下流工程では
開発環境におけるコーディングと単体テストから、結合テスト／システムテストをストレスなく往復する手法を採用しています。アプリケーションを作りながら同時に単体テストプログラムも同時並行で作成します。
これは熟練した開発者なら当然採用する開発スタイルです。ただし一般的な単体テストプログラムはMSTestやXUnitを使用してビジネスロジックやバックエンドロジックをテストする方法が主です。エモーションソフトはここを一歩進めて、画面機能そのものもテスト出来るようにしています。またHttpリクエストやレスポンスもモックを使うのではなく、アプリケーションと同じ実際に動いているものを使用するため、より精度の高いテストを行うことが出来ます。
加えてエモーションソフトでは技術的な強みであるSeleniumを使用した自動テストをプログラムの製造段階から並行して作り始めます。こうして作られた自動テストはその後の結合テストやシステムテスト環境でもそのまま使用できるため、全体的なテスト工数の削減につながります。
一般的に開発フェーズ毎の工数比率は、（設計：製造（単体テストを含む）：テスト）＝（３：２：５）といわれていますが、エモーションソフトではこのうちのテスト工数の割合を網羅性を損なうことなく大きく下げることを実現しています。
こうした特徴は製品の品質を上げるだけではなく、プログラムに何らかの修正を行った場合の回帰テストの負荷を減らすことができ、結果として仕様変更への耐性が強い＝仕様変更に迅速に対応できるアプリケーションを作ることが出来ます。
また万一障害が見つかった場合でも、原因の特定や対応をスムーズに行うことが出来ます。「障害対応によるプログラムを修正した結果その障害は治っても別の個所で副作用が出る」という悪循環が起きないような仕組みを開発スタイルとして定着させています。
