ブログ

サイト管理人のブログです。
このエントリーをはてなブックマークに追加

ブログ一覧

ビジネスモデルを左右する、たった2つの要素とは?

8b78540ca6c3d6d850957f533be1b2dd_s

ビジネスモデルを左右するたった2つの要素とは?

どんな事業であれ、共通して大切なことはビジネスモデルであると言えます。ただビジネスモデルというとやや幅広いイメージがあり、重要なポイントがぼやけてしまいます。よって私はビジネスモデルの要点を2つだけに絞っています。

要素の1つが、事業の「コスト構造」であり、

もう1つが事業の「収益構造」です。

コストと収益の構造はそれぞれ大きく2パターンに分かれます。

コスト構造の2パターン

事業のコスト構造は大きく、固定費型と変動費型の2種類に分けることができます。
 
固定費型とは、初期投資が大きかったり、毎月の固定費が大きい事業構造のことです。例えば、私が属する「情報サービス業」は基本的に固定費型のビジネスです。受託したシステムを開発するのは「人」ですから、人を雇わないといけません。「人件費」つまり給料は、仕事があろうがなかろうが基本的には一定額の支払いが求められるので、営業量にはあまり左右されない費用、つまり固定費となります。
 

変動費型は小売業をイメージするとよいでしょう。商品を仕入れて販売する形態です。もし需要が少なくなれば、仕入を少なくすることで仕入れコストを変動させることができます。このように、販売をするために必要なコストを需要に応じて変動できるのが変動費型のビジネスです。
 
 
この両者の結論を言うと、固定費型ビジネスはハイリスク・ハイリターン型で、変動費型ビジネスはローリスク・ローリターン型です。固定費型は月々の固定費が大きいので、売上が少ないと赤字になりやすいのですが、一旦黒字化すると、その利幅も大きくなり、急激に利益を獲得できる構造になっています。
 
ビジネスをするうえでは、固定費型なのか変動費型なのかを把握しておき、事業構造に応じた事業計画を策定することが大切です。
 
 

収益構造の2パターン

次に収益の構造です。これにも大きく2つあり、フロー型ビジネスと、ストック型ビジネスがあります。
 
フロー型とは、商品やサービスを販売した時点で売り切るタイプの事業です。販売時点で大きな売上を獲得できますが、常に次の顧客を探して仕事を継続的に獲得することが必要になるので、営業力が求められます。
 
ストック型とは、携帯電話の料金プランやクラウドサービスのように、一度契約すると契約期間は継続して収益が上がるビジネスです。継続利用を前提としているので、月々(または年々)の売上はフロー型よりも低くなります。
 
 
同じ商品やサービスでも、売り方によってフロー型にもストック型にもできます。フロー型は一時期に大きな売上高を獲得できるメリットがありますし、ストック型は継続的な収益を獲得でき経営が安定するメリットがあります。

資金的に厳しい時期はフロー型の事業するとか、将来的な経営の安定を目指してストック型ビジネスをゆっくりと立ち上げるなど、これも企業の状況に応じて戦略的に決めていく必要があります。
 
 

情報処理サービス業のビジネスモデルは?

 
私が以前に従事していた「情報処理サービス業」は、固定費型かつフロー型のビジネスです。仕事があろうが無かろうが固定費が発生するという点でリスクがある事業です。かつ安定した収益は上げにくく、受託していくら、という売り切り型の事業です。なので営業力の有無が事業に与える影響はかなり大きいです。仕事がなくなるとすぐに赤字になるので、どんな仕事でも受けようと思い、あまり面白みのない仕事や、低単価の仕事も受けるような誘因が働きます。
 

仕事量が下火になると急にカツカツになります。仕事があって利益を確保できている時期に、ストック型ビジネスを立ち上げるなどしないと、経営が安定しません。年がら年中仕事に追われる事業になりやすいです。このあたりの特徴はビジネスを始める前から「自明」なほどはっきりしています。
 

こうしたビジネスの特徴を前提条件として営業戦略、人的資源戦略を策定しないと、「全員が忙しくがんばっているのに誰も幸せになれず疲弊する事業」を作ってしまいかねません。
 
 
皆様も自社事業のビジネスモデルを考えてみると、新たな課題や機会がみつかるかもしれません。

派生開発プロセスの工夫(その17)

品質確保に効果のあった派生開発プロセスの工夫#17

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3
   ⇒part4
   ⇒part5
   ⇒part6(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群

(2)派生開発プロセスの内容

1.対処検討プロセス群(part6)

対処検討プロセスを順に解説していく。今回は最後のプロセスである「1.5 対処決定」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定

※プロセスの全体像を参照したい場合はこちら

1.5 対処決定

1.5.1 プロセスの目的・概要

対処決定プロセスの目的は、「1.4対処案の検証」プロセスの結果を関係者間で協議し、決定することである。
採用された対処案が決定することで、本プロセスは終了となるが、次の「2.開発プロセス群」の実施に先立って、要求事項トレーサビリティ・マトリクスを作成する。本資料の作成によって、次工程の開発箇所を明確にすると共に開発量の見積りを行うことができる。
(さらに…)

派生開発プロセスの工夫(その16)

品質確保に効果のあった派生開発プロセスの工夫#16

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3
   ⇒part4
   ⇒part5(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群

(2)派生開発プロセスの内容

1.対処検討プロセス群(part5)

対処検討プロセスを順に解説していく。今回は「1.4 対処案の検証」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定

※プロセスの全体像を参照したい場合はこちら

1.4 対処案の検証

1.4.1 プロセスの目的・概要

対処案の検証プロセスは、特定された対処案の調査アイテムに従って、ソースコードやドキュメントを調査し、必要に応じてスペックアウトを行いながら、対処案が正常に動作することを検証するプロセスである。

対処案をリストアップした時点では、設計情報やソースコードの詳細までを確認しているわけではない。そのため、詳細な調査を行った結果、当初検討した対処案では要求仕様を満足できないことが判明する場合もある。

対処案の検証では、対処案が要求仕様を満足していることを徹底的に調査する。対処案の正常性を確認するのではなく、対処案が要求仕様を満たしていない事項がないかを検証していく。
(さらに…)

派生開発プロセスの工夫(その15)

品質確保に効果のあった派生開発プロセスの工夫#15

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3
   ⇒part4(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群

(2)派生開発プロセスの内容

1.対処検討プロセス群(part4)

対処検討プロセスを順に解説していく。今回は「1.3 対処案の特定」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定

※プロセスの全体像を参照したい場合はこちら

1.3 対処案の特定

1.3.1 プロセスの目的・概要

対処案の特定プロセスの目的は、要求仕様を満足する対処案を複数検討し、対処案を実現するために明らかにしなければならない調査事項(調査アイテム)を洗い出すことである。

本プロセスでは、必要であれば要求仕様を更に要素分解して、設計書やソースコードの調査を行う。調査の過程で、要素分解、バリエーション検討、マトリクス表記の3手法を活用しながら、対処案を検討する。
(さらに…)

派生開発プロセスの工夫(その14)

前回エントリから1ヵ月以上空いてしまいました。
多忙と試験勉強が言い訳なのですが。。
このシリーズエントリは先が長すぎて、No.50とか平気でいきそうなので、きりのいいところでpdf化した内容を一括ダウンロードで終わりにしたいかな、、と考えているこの頃です。

ではプロセス改善のNo.14をどうぞ。

品質確保に効果のあった派生開発プロセスの工夫#14

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群

(2)派生開発プロセスの内容

1.対処検討プロセス群(part3)

対処検討プロセスを順に解説していく。今回は「1.2.2 要求仕様の特定」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定

※プロセスの全体像を参照したい場合はこちら

1.2.2 要求仕様の特定

1.2.2.1 プロセスの目的・概要

要求仕様の特定プロセスの目的は、システムやソフトウェアの構成要素が特定できる形まで、要求コンセプトをブレイクダウンし、適切な作業スコープを設定することである

要求コンセプトは、「トランザクションの同時受付数を5000まで拡張する」とか「機器の障害発生時に、アクティブ系の機器が存在しない状態を30秒以上継続させない」などといった、システムの構成要素や設計・プログラム構成要素を特定しにくい表現になっている。

この表現を、「A機器管理処理ブロックにおいて、○○通知を受信した場合は、□□の動作を行う」といったシステムやソフトウェアの構成要素の振る舞いがわかる程度の詳細度にブレイクダウンしていく。このブレイクダウンされたものを要求仕様と呼ぶ。
(さらに…)