ソフトウェア会社とは、営利目的で設立された国営または民間の組織であり、主な製品はさまざまな形式のソフトウェア、ソフトウェア技術、流通、ソフトウェア製品開発です。[1]これらの会社がソフトウェア産業を構成しています。
種類
ソフトウェア会社にはさまざまな種類があります。
- 市販の既製品(COTS)を販売している企業もあります。
- 多くの企業がソフトウェア開発サービスを提供しており、他の企業や事業向けにカスタムソフトウェアを開発する体制を整えています。
- 専門的な市販ソフトウェアを製造している企業。
- ソフトウェアをサービスとして提供する企業 ( SaaS )。
- IT インフラストラクチャ サービスやクラウド コンピューティング サービスを提供する企業の他の種類の SaaS 製品もあります。
- サードパーティの開発者が企業のソフトウェアと対話できるようにする API as a Service。
- ソフトウェアコンポーネントを製造している企業。
- アプリケーション サービス プロバイダー。
- 垂直産業または特定の地域向けに特注のソフトウェアを生産する企業。
- エンドユーザーが使用するコンシューマー向けまたはエンタープライズ向けのソフトウェアを構築、開発、販売する独立系ソフトウェアベンダー (ISV)。
ソフトウェア会社における一般的な役割
ソフトウェア会社の組織化は非常に特殊なタイプの管理スキルであり、経験豊富な人材が組織上の問題を独自の利点に変えることができます。たとえば、チーム、システム、および手順が適切に確立されていれば、サブチームを異なるタイムゾーンに分散させることで、会社の 1 日を 24 時間稼働させることができます。良い例としては、開発チームより 8 時間早いまたは遅いタイムゾーンにいて、テスターが見つけた ソフトウェアのバグを修正するテスト チームがあります。
プロフェッショナル ソフトウェア会社は通常、少なくとも 3 つの専任サブチームで構成されています。
- 市場のビジネスニーズを定義するビジネスアナリスト
- 技術仕様を作成し、ソフトウェアを書くソフトウェア開発者
- 品質管理の全プロセスを担当するソフトウェアテスター
大規模なソフトウェア企業では、より高度な専門性が採用されており、次のようなこともよくあります。
- ユーザーガイドなどのすべてのドキュメントを作成するテクニカルライター
- 製品全体の構築とソフトウェアのバージョン管理を担当するリリーススペシャリスト
- ビジネス要件、ユーザー調査、ユーザビリティの専門知識に基づいて設計アーキテクチャを作成するユーザーエクスペリエンスデザイナー
- 通常、グラフィカル ユーザー インターフェイスの設計を担当するグラフィック デザイナー。
- 2つ、3つ、またはそれ以上のサポートラインを担当するメンテナンスエンジニア
- コンサルタントは、特に専門知識が必要な場合、ソリューションを運用可能にする責任があります。この例としては、ビジネス インテリジェンス ソフトウェアでの多次元キューブの構築、既存のソリューションとの統合、ビジネス プロセス管理ソフトウェアでのビジネス シナリオの実装などがあります。
構造
ソフトウェア会社のマネージャーは通常、開発責任者(HOD)[2]と呼ばれ、利害関係者に報告します。組織の規模に応じて、マネージャーはサブチームを直接またはマネージャー/リーダーを介して率います。通常、10人までのチームが最も機能しています。大規模な組織では、一般に2つの階層モデルがあります。

すべてのチームは完全に独立しており、異なるプロジェクトで別々に作業しています。構造は非常にシンプルで、すべての従業員が 1 人の人物に報告するため、状況は非常に明確ですが、知識の交換や人材の最適な使用という点では良い解決策ではありません。

このモデルでは、各主要専門分野に専任のマネージャー/リーダーがおり、製品/プロジェクト マネージャーが率いる特定のプロジェクトに人材を「レンタル」します。製品/プロジェクト マネージャーは、正式または非公式に人材を購入し、その時間に対して支払います。これにより、各個人従業員には、製品/プロジェクト マネージャーと専門の「リソース」マネージャーの 2 人の上司がいます。一方では、人的資源の使用が最適化されますが、他方では、構造内でどのマネージャーが優先されるかについて対立が生じる可能性があります。
これらの構造にはさまざまなバリエーションがあり、多くの組織ではこの構造がさまざまな部門やユニット内に分散され、分割されています。
方法論
ソフトウェア会社は、コードを作成するためにさまざまな方法論を使用します。これには次のようなものがあります。
- ウォーターフォールモデル(PRINCE2 [3]やPMBoK [4]などのプロジェクト管理方法論を含む)
- アジャイルソフトウェア開発、エクストリームプログラミング[5]やSCRUM [6]など
スパイラルモデル、ラショナル統一プロセス(RUP)[7]、MSF [8]など、両方を組み合わせた方法論もいくつかあります。
製品ライフサイクル
使用される方法論に関係なく、製品ライフサイクルは常に少なくとも次の 3 つの段階で構成されます。
- 設計 – ビジネス仕様と技術仕様の両方を含む
- コーディング – 開発そのもの
- テスト – 品質管理
理想的には、各ステージに合計時間の 30% を費やし、残りの 10% は予備として残します。
これらのグループ間の相互作用のUML シーケンス図は次のようになります。

各段階では異なるグループが重要な役割を果たしますが、開発プロセス全体を通じてそれぞれの役割が関与する必要があります。
- アナリストは、ビジネス仕様を完成した後、変化するビジネス状況を管理し、時間の経過とともに変化する可能性を最小限に抑えます。また、開発プロセス全体を通じてプログラマーとテスターの両方をサポートし、最終製品が最初に指定されたビジネス ニーズを満たすようにします。このプロセスでは、ビジネス アナリストが、最適なビジネス レイヤーを提供するのに最適な立場にあるため、ソリューションを顧客に最終的に提供する際の主要プレーヤーとして理想的に配置されます。
- プログラマーは設計段階で技術仕様を作成するため、プログラマー/デザイナーと呼ばれ、テスト段階ではバグを修正します。
- テスターは設計フェーズでテストシナリオを完成させ、コーディングフェーズで評価します。
システムと手順
ソフトウェア企業には、すべてのサブチームにわたって社内で実装され、機能しているさまざまなシステムと手順があります。これには次のものが含まれます。
ビジネスアナリスト
- Sparx Systems Enterprise ArchitectやIBM Rational Roseなどのモデリングツール
プログラマー
- バージョン管理システムとソフトウェアのバージョン管理手順
- コード分析ツールとコーディング標準、手動または自動で検証
- 展開メカニズム
テスター
プロジェクト/製品マネージャー
- エンタープライズ プロジェクト管理(EPM) システムと手順
- 製品ポートフォリオ管理(PPM)
- 変更管理システムと手順
また、これらの機能の一部を 1 つのパッケージに組み込み、グループ全体で使用されるアプリケーション ライフサイクル管理(ALM)もあります。これらは、 Borland、ECM、Compuwareなどのさまざまなベンダーから提供されています。
効率監査
確立されたソフトウェア企業は通常、自社の効率性を測定する何らかの方法を持っています。これは通常、次のような 一連の主要業績評価指標(KPI)を定義することによって行われます。
- 開発者が時間単位またはソースコード行数あたりに修正したバグの平均数
- テストサイクルごとにテスターが発見したバグの数
- ゼロバグバウンス(ZBB)までの平均テストサイクル数
- テストサイクルの平均時間
- タスクの実際の時間と比較したタスクの推定時間(計画の正確さ)
- ベースラインの修正回数

多くの組織は、能力成熟度モデル(CMM) の最適レベルに到達することに重点を置いていますが、ここでの「最適」は必ずしも最高レベルを意味するわけではありません。カーネギーメロン大学のSEMAや特定のISO標準などの他のシステムもあります。小規模なソフトウェア企業は、形式化されているかどうかにかかわらず、プロセスに対して軽量なアプローチを使用することがよくあります。各組織は、完全なテクノクラシー (すべてが数字で定義される) と完全な無政府状態 (数字がまったくない) の間のどこかで独自のスタイルを確立しています。組織がどちらの方向に進むにせよ、すでに開始されている開発プロセスに変更を導入するコストとリスクを説明するピラミッドを、変更を管理するための真のモデルと見なしています。
参照
参考文献
- ^ 「今日のソフトウェア企業とは何か?」 RedMonk. 2014年。 2017年6月2日閲覧。
- ^ Greenlit: コンセプトからピッチまでの事実/リアリティ TV のアイデアの開発 p.12
- ^ PRINCE2 によるプロジェクトの成功管理
- ^ PMBOKガイドのユーザーズマニュアル
- ^ エクストリームプログラミングの計画
- ^ スクラムによるアジャイルプロジェクト管理
- ^ 合理的統一プロセスを簡単に:RUP 実践ガイド
- ^ Microsoft ソリューション フレームワーク (MSF): ポケット ガイド
