|
受注基準
|
|
Q1
|
どのようなビジネスプロセスを扱っていますか。
弊社のビジネスプロセスは、
- オフショア・ソフトウェア開発
- プロジェクト請負
- ラボ契約
- オンサイト・コンサルティング
|
|
Q2
|
どのアプリケーションシステムを開発しましたか。
例) バックオフィス(会計、総務、人事)フロントオフィス(販売サポート・システム、コールセンターシステムなど)など
バックオフィス：人事管理システム、日報登録システム、研修システム、グループスケジューリング管理システム、社員と給料管理システム、営業管理システム、生産性データベース管理システム、物流システムの改造
リアルタイム通信システム：自動織機リアルタイムモニターシステム、照度計管理システム、異常情報多重アクセス利用ソフトウェア、自動引張試験システム
※詳細は弊社プロフィールを参照
|
|
Q3
|
クライアントはなぜ、アプリケーションの開発をオフショア（インド）で行うのですか。
- 日本での人材不足
- インド企業はプロセスを重視する。
- インドはオフショア開発経験が長い。多くのアメリカ企業がインドで成功している。
- インド人技術者は英語が得意で、新技術の把握が速い。
- インド人技術者は数学的、論理的思考を得意とする。
- 低コスト高品質のものを提供できる。
|
|
|
仕様の伝達、レビューの方法
|
|
Q1
|
知識や要件を伝達・共有するために、どのような形の打合せを行っていますか。
- 短期出張して細かい打ち合わせを行います。
- お客様側のリーダクラスの方が訪印し、チームに説明します。
- メール・電話・チャットなどでコミュニケーションをとります。
- 説明資料、プロトタイプを作成し、お客様と確認します。
|
|
Q2
|
各開発工程でどのような形でレビューを行っていますか。
例）要件定義書のウォークスルー形式のレビュー
ソースコードの読み合わせ
- 主にウォークスルー形式のレビューを行っています。つまり、仕様書を見ながらプログラムの動きを想定し、仕様の理解を徹底的に行い、不具合を発見する方法です。
- ソースコードレビューを行います。
- 主に、トップダウンテストを行います。重要度の高い上位モジュールから下位モジュールの順に行います。
- 場合により第三者による試験を実施します。
|
|
Q3
|
上記のようなレビューをどれくらいの頻度で行っていますか。
場合によりますが、平均的に1週間に1回の頻度で行っています。
|
|
Q4
|
上記のようなレビューでの、レビューポイントは何ですか。
要件定義レビュー
- お客様の要求を誤理解していることはないか
- WHY、WHAT、WHO、WHERE、WHEN（5W）を重視する
- 変更のあるときは文書化する
外部設計レビュー
- 要求は適切に機能へ展開されているか
- HOWはこの時点では理論的
- すべての可能性がカバーされているかの確認
- 機能洗い出しは適切に行われているか
内部設計レビュー
- 機能が適切に実現されているか
- すべてのロジックパスを通るか
- プログラム構造や機能分割は適切か
コーディングレビュー
- ソースコードの妥当性、読みやすさ
- コーディング規約に従うコードになっているか
- コードウォークスルー
テスト計画レビュー
- テスト手順、テスト内容は妥当か
- テストケースのカバレッジの確認
|
|
|
開発方法論
|
|
Q1
|
御社で主に利用される開発モデル（ウォータフォールやスパイラル）は何ですか。またその理由は何ですか。
ウォータフォールモデルです。業務アプリケーションの場合、最も適していると思われます。
仕様がなかなか決定せず、仕様変更も発生し、納期も短い場合はスパイラルモデルとなります。（特にメーカーからの案件）。
プロトタイプモデルは、大きな案件、または新技術の検討などを必要とする案件の場合利用しています。
|
|
Q2
|
採用する見積もり方法について明記してください。
プロジェクトで必要となる作業の洗い出し（ワーク・ブレイクダウン・ストラクチャ（WBS）を用いる）、その作業ごとの工数を見積もります。以前のプロジェクト経験から見積もることができます。
|
|
Q3
|
開発工程での、開始基準・終了基準、成果物を説明してください。
要件定義：要件定義書に対して作業範囲記述書、見積書、工程表、QA表
外部設計：外部設計書、機能仕様書、画面レイアウト、画面一覧、外部接続概念、処理フロー、テーブル設計書（テーブル一覧、接続概念図―ER図）、入出ファイル一覧
内部設計：内部設計書、機能詳細仕様書、プログラム一覧、プログラム処理説明書、テーブル設計書（テーブル定義書、テーブル関連書）、モジュール構成図、関数一覧
単体試験成績書、問題管理シート、結合試験成績書、システムテスト成績書、取扱説明書
|
|
Q4
|
主に、どこからどこまでの開発工程を外部委託していますか。また、その理由は何ですか。
詳細設計から結合テストまでが多いです。
理由：
- 作業切り分けしやすい。
- 業務ノーハウの必要性が少ない。
- 外部設計はお客様との打ち合わせを頻繁に行う必要があり、通常オンサイトで行う。
|
|
Q5
|
クライアントからどのような設計書を受け取りますか。
要件定義書、機能仕様書
|
|
Q6
|
クライアントへどのような設計書を作成して、渡していますか。
内部設計書、機能詳細仕様書、プログラム一覧、プログラム処理説明書、テーブル設計書（テーブル定義書、テーブル関連書）、モジュール構成図、試験仕様書
|
|
Q7
|
外部委託する場合に、外部委託者へ仕様を伝達するときに何か注意していることはありますか。
- 要件定義書や他の設計書はできるだけ細かいレベルで記述する必要があります。
- 正常ケースのみでなく、異常ケースなども記入していただければ幸いです。
- 仕様伝達の再確認を行った方が確実です。
|
|
Q8
|
既存のソフトウェアを分析するためにソースコードのコメントを当てにしますか。
そうだとすれば、日本語のコメントがあるソフトウェアを理解するのは困難ですか。
- はい。コメントがあれば、大変助かります。
- 日本語のコメントでも全然問題ありません。
|
|
Q9
|
進捗報告は、プログラム単位で行いますか。
報告の期間はどれくらいですか。
進捗報告書は誰が作成しますか。
- お客様の希望によりますが、プログラム単位または工程単位で行います。
- 通常、週に1回です。
- 通常、弊社のプロジェクトマネージャー・プロジェクトリーダーが作成し、管理します。
|
|
|
保障期間・不具合対応・仕様変更対応のポリシー
|
|
Q1
|
保障期間はどれくらいですか。
仕様が変更となった場合に、クライアントへ要求する追加コストが発生する基準を説明してください。
不具合対応のポリシーは。
- 保障期間は1年です。
- 通常、5％程度までの仕様変更は請求しません。それを超えた場合、お客様に連絡します。
- 不具合対応の方針は以下の通りです。
重要度 1 重大な不具合、重要機能の動作障害、早急な対応が必要な障害 24-48時間
重要度 2 個別機能の欠陥による重大な障害、早急な対応が必要な障害 24-72時間
重要度 3 個別機能の軽微な障害、適宜修正 48-96時間
重要度 4 外見などの障害、お客様の要望に応じ適宜修正 72-120時間
|
|
|
人事管理ポリシー
|
|
Q1
|
一般的に、インドでは離職率が高い国ですが、人員を確保するためにどのような対策を行っていますか。
- 興味の持てる仕事をしてもらう
- 希望者には社員株を持ってもらう
- 適切な責任と必要な権限を与える
- 技術向上のチャンスを提供
- 業界標準の十分な給与の他に健康保険・社内ローンなども提供する
- 働きやすい環境を提供
- 日本語と日本の作業文化に慣れ、日本的な長期間働くメリットを理解してもらう
- 日本へ短期出張の機会を作る
- ハイリスク・ハイリターン方針を実施
|
|
Q2
|
社員を採用する基準は何ですか。
例)大学卒業、経験者・・・
- 大学卒業、大学院卒業と経験者です。
- 柔軟性を持って長期のビジョンを持っている人を優先的に採用します。
|
|
|
一般
|
|
Q1
|
日印ソフトウェアを使用してインドでオフショア開発するメリットは何ですか。（コスト・開発スピード、時差）
メリット：
- 人材ベースが広いため、大きいチームを作成することで開発スピードを上げることができる。
- 比較的にコストが安い
- 高品質
- 英語が得意なので新技術の把握・調査が早い
- 数学が得意で、論理的な考え方ができるため、ソフトウェア開発に適している
- 時差は3時間半で、アメリカに比べて非常に少ない
- 通常この時差を有効に利用している。
- 日本語の壁がない
- 日本の作業文化になれている
- 様々な面で柔軟性を持って対応する
|
|
Q2
|
オフショア開発を成功するために必要なことは何ですか。
- お客様側とベンダー側の体制をしっかり決める。
- オンサイトとオフショアの作業の切り分けをはっきりさせる。
- 要件定義書や他の設計書はできるだけ細かいレベルで記述する。
- お互いにリアルタイムで明確なコミュニケーションが取ることが必要。
- 定期的なフォローアップ、確認。
- 長期のパートナーシップを目指して、徐々にお互いに理解することが必要。
- お客様側のリーダや技術者が訪印し、チームメンバーと打ち合わせし、進捗の確認を行う。
|
|
