2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/06

Redmineの新機能開発チケットの記事のリンク


石川さんが書かれたRedmineの新機能開発チケットの記事がとても参考になるのでリンクしておく。

【参考】
いま注目しているRedmineの新機能開発チケット - ファーエンドテクノロジー株式会社

Redmine Advent Calendar 2018 - Adventar

直近のVer4.0に入っていない機能の紹介でいくつか気になるチケットはある。

【1】「プロジェクト一覧画面の改善」は実現して欲しいチケットだ。

Patch #29482: Query system for Projects page - Redmine

Redmineの運用が長くなると、プロジェクトが100個以上に増殖するので、必要なプロジェクトのみ選定して、その内容を見たい、というニーズが多くなる。
特に、現場マネージャの一つ上の経営者層がRedmine上で、複数の案件を一覧で見たい、というニーズが多い。
上記の改善ができれば、経営者層の不満となるニーズを多少緩和してくれる。

【2】「トラッカーの日本語訳変更」は、議論が活発で読んでいて面白い。

Patch #29045: Change Japanese translation for Tracker - Redmine

Redmine初心者は、トラッカーという言葉に慣れていないので、いつもトラブルの元になりやすい。
一方、「トラッカーをなくすと、Issue Trackingという概念が消えてしまう」という意見も確かに納得する。

Redmineのトラッカーは、ワークフローそのものであり、帳票そのものでもある。
トラッカーという言葉には数多くの意味が込められているので、そのニュアンスを消さずに修正するのは本当に難しい。

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている: プログラマの思索

【3】「トラッカーの説明を追加する」チケットも確かにその通りだ。

Feature #442: Add a description for trackers - Redmine

Redmineを触ったことがないユーザには、トラッカーの意味を説明した後で、現場で定めたトラッカーという業務のワークフローを説明する場合が多い。
その時に、Redmine上で、このトラッカーはこういう意味で運用しているよ、という説明文があると、ユーザは勝手に参照してくれるので、システム管理者は楽になる。

【4】「プロジェクト毎にデフォルトのカスタムクエリを設定できるようにする」チケットもニーズが多い。

Feature #7360: Issue Custom Query: Default Query - Redmine

朝一番にプロジェクトを開いた時、メンバーに見て欲しいチケット一覧をデフォルトにしたい。
そうすれば、マネージャが逐一指示を出さなくても、メンバーは自身の残チケットに着目して作業し始めるはず。

【5】チケットにタグづけ機能は、ぜひ欲しい機能だ。

Feature #1448: Add tags to issues - Redmine

ハッシュタグのように、#をつけてタグ付けして、そのタイムラインを読むのは今は当たり前。
チケットのフィルタリングとして、カテゴリやバージョン等、数多くの方法はあるが、タグ付け機能があれば、より柔軟にチケットの分別ができるようになる。

【6】上記の記事には記載がなかったけれど、下記の機能改善も期待している。

・「@名前」でリンクする
・WikiからODTファイル出力
・マイページの画面改善
・添付ファイルの全文検索

新たな機能改善がマネージャの潜在ニーズを呼び起こし、新しい運用方法の提案や新たな機能改善につながる、という議論のやり取りが楽しい。
そこがRedmineの一番面白い点。


| | コメント (0)

2018/12/04

2018年もRedmine Advent Calendarをやってます

@yassanの発案で、2018年もRedmine Advent Calendarを今年もやってます。
まだ空きはあるので、ぜひご参加下さい。
@yassan、ありがとうございます。

【参考】
Redmine Advent Calendar 2018 - Adventar

【参考2】
Redmine Advent Calendar 2017 - Qiita

Redmine Advent Calendar jp 2011とRedmine1.3に向けての感想: プログラマの思索

お勧めの記事は、前田剛さんの下記の記事かな。
なぜ、Redmineでは「Issue」を「問題」「課題」と訳さず、「チケット」になったのか、その経緯が書かれている。

Redmineの「Issue」の日本語訳はいかにして「チケット」になったか | Redmine.JP Blog

他のチケット管理ツールでは、「チケット」という言葉ではなく「課題」「問題」と訳されている場合が多い。
しかし、Redmineでは、日本語訳がチケットになったおかげで、「チケット駆動開発」という概念が生まれて、日本特有の普及推進になったのだろうと思う。
僕も以前、色々考えていた。

チケット駆動開発の理想と現実: プログラマの思索

Redmineの背景にある「チケット駆動開発」という概念は結局何なのか、もっと考えてみたいと思っている。

チケット駆動開発の原点の記事のリンク: プログラマの思索

| | コメント (0)

2018/12/03

ソフトウェア開発に心理学や行動経済学の概念を適用した記事のリンク

ソフトウェア開発に心理学や行動経済学の概念を適用した記事がとても素晴らしいので、リンクしておく。
このアイデアを育ててみたくなった。

【参考】
ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita

ソフトウェア開発に、製造業や生産管理のベストプラクティスを適用しても、あまり有効でない。
むしろ、認知心理学や行動経済学の知見を適用して、開発者の心理や開発チームの行動に着目した方が、うまくコントロールできるのではないか。
そんな感触をずっと持ち続けてきた。

上記の記事はまさにピッタリ。
そう、こういう記事が読みたかった。

現場の開発者や開発チームは、独自の存在であり、全ての存在が同じではないけれど、それらの行動を現象として見ると、驚くほど共通的な特徴が見つかる場合も多い。
そういうバラバラな共通的な現象を、的確な概念でその本質を表現できればいいのに、と思っていた。

たとえば、認知心理学の概念として、認知的不協和、グループシンク(集団浅慮)、リスキーシフト(リスク志向の集団極性化)、コーシャス・シフト(安全志向の集団極性化)、有能性の罠(competency trap)、訓練された無能、などがある。
それらを実際にソフトウェア開発に適用してみれば、当てはまる事例は多いのではないか?

具体的には、要件定義で数多くの利害関係者の意向を取り入れると、本来は業務を刷新する革新的なシステムを導入するはずだったのに、現状の業務の焼き直しに過ぎないリプレース案件になってしまった、という事例は、コーシャス・シフトの一例ではないか、とか。

僕は、認知心理学の概念の適用も面白いと思うが、行動経済学の概念を適用する方が面白いと思っている。
経済学の基本理念「限られた資源を有効活用する」ことは、ソフトウェア開発でもまさに同じだ。
優れた開発者、優れた開発チームという唯一無二の資源をいかに有効活用して、ビジネス価値を作り出すか、という目的と一致するからだ。

たとえば、技術的負債やリファクタリングは、時間割引や割引価値の観点で説明できるだろう。
犠牲的アーキテクチャは、埋没価値(サンクコスト)や機会原価の観点で説明できるだろう。
意固地な言動は、バイアスで説明できるかもしれない。

アドレナリンジャンキー」にあるプロジェクト管理のアンチパターンも、認知心理学や行動経済学の知見で整理して説明し直すと面白いかもしれない。

プロジェクト管理のアンチパターン集~アドレナリンジャンキー: プログラマの思索

| | コメント (0)

2018/11/25

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である

『プラットフォーム革命』を3回以上読み直した。
ようやく、昨今のGAFAのようなプラットフォーム企業が何故、収益力だけでなく、これほどまでに政治的影響力を強めているのか、何となく理解した。
以下は、自分の浅はかな理解に基づくメモ。

【参考】
『プラットフォーム革命』――プラットフォーム・ビジネスの脅威を機会に変えるために | GLOBIS 知見録

「プラットフォーム革命」を読んでAmazon、Facebook、Uberのビジネスモデルを理解する | Synapse Diary

【1】プラットフォーム企業は、独占企業そのもの

(引用開始)
Modern Monopolies――同書の原題だ。直訳すると「現代の独占」だが、このタイトルこそ、本書の特徴をよく説明していると思う。
実際、アップルやアマゾン、グーグルなど大手プラットフォーマーが世界の時価総額ランキングに名を連ね、世界を支配していると危惧する声が毎日のように聞こえてくる。
(引用終了)

ゼロ・トゥ・ワン」にも似たような話「収益の安定した企業になるなら、独占企業になって、独占利潤を取れ」があったけれど、正直分かりにくかったが、『プラットフォーム革命』を何度も読みなおして、ようやく理解した。

【2】僕が『プラットフォーム革命』が素晴らしいと思う点は、経済学の概念を用いて、プラットフォーム企業のビジネスモデルと経営戦略を徹底的に分析し、その本質を導いているからだ。
具体的には、従来の直線型企業の象徴である製造業、特に、自動車業界のビジネスモデルと、プラットフォーム企業のそれを比較対比することで、プラットフォーム企業の特徴とその利点を鮮やかに説明している、と考える。

以下、経済学の用語を中心に拾いながら、自分のメモと自分の理解を書いてみる。

【2-1】完全競争の業界、市場では、どの企業も利潤がない。
レッドオーシャンの世界。

【2-2】完全な情報がある前提では、計画経済と市場経済は、その双方ともに効率性が同じ、という理論が既にある。

しかし、現実は、市場経済の方が計画経済よりも効率的だ。
その理由は、入手される情報は不完全な場合がほとんどなので、ローカルな情報を市場でやり取りすることで、需要と供給の均衡を図るから。
この時、需要と供給が均衡する点が、取引される価格になる。
よって、市場経済は価格システムでもある。
つまり、市場経済は、価格という指標・尺度の変化を記録するシステムそのもの。

しかし、『プラットフォーム革命』のストーリーでは、プラットフォーム企業は、取引の履歴、購買履歴、個人情報などを完全に把握でき、そのビッグデータを分析することで、「完全な情報」という概念を現実化できる。
たとえば、Amazonの購買履歴、Facebookの個人情報、Appleのクレジットカード情報、Googleの検索履歴。
昨今では、Facebookの個人情報が悪用されて、トランプ大統領を生み出した現象があったから、その主張はあながち嘘とは言えないと思う。

よって、プラットフォーム企業は「中央集権的な計画経済」から成り立っており、それゆえに独占企業となり、勝者総取りの結果として、独占利潤を独り占めできる。
だから、米国のGAFA、中国のBATの企業価値は、小国のGDPくらいの大規模な価値を持つ。
(但し、自然独占の結果だよ、と『プラットフォーム革命』では言う)

【2-3】製造業のような従来の企業のビジネスモデルを経済学の観点から理解するには、二つの観点がある。
一つは、コースの定理。

市場経済では、取引費用というコストと、情報の欠乏を最小化するために、企業という組織が組織化される。
企業は、市場で取引するよりも、社内でやるほうが効率的ならば、内製化し、それ以外の活動は外部委託する。
企業は、事実上、巨大な市場経済の中に存在する小さな計画経済。

【2-4】もう一つは、ポーターのバリューチェーン。他に、規模の経済や経験曲線効果。

規模の経済は、たくさん作るほど製造原価は急激に下がる、というハード面のやり方。
経験曲線効果は、たくさん作るほど、従業員の能力も製造工程も学習されて、製造原価は急激に下がる、というソフト面の考え方。
つまり、大規模な設備投資でコスト優位性をもたらす手法。

規模の経済や経験曲線効果は、特に自動車から半導体装置に至るまでの製造業の根本思想。
外食産業のチェーン店、コンビニのフランチャイズチェーンも、同様の発想。

また、ポーターのバリューチェーンでは、企業は、研究開発→製造→販売・マーケティング→保守サービスという一連の活動から成り立ち、その活動の連鎖で付加価値を付けて、高いアウトプットを出す。
その時、コースの定理と組み合わせれば、価値連鎖における活動の結びつきの最適な組み合わせを実現し、最小限のコストで最大の価値を生み出すことが企業の競争優位上の目的になる。

よって、企業が価値連鎖に様々な活動を内製化して取り込むのは、外部委託するよりも社内の活動にした方が効率的と判断している。
特に、製造業では、さらに規模の経済と組み合わせて、大規模な設備投資でどんどん巨大化し、官僚的な組織になることで、大きな企業価値を生み出し、独占企業となってきた。

しかし、こうした大組織であっても、ある一定の規模を超えると、組織内で情報流通のコストが大きくなり、独占を下回る水準で成長の天井にぶち当たる。

【2-5】コースの定理、ポーターのバリューチェーンが発生する問題意識は、市場が効率的ならば、なぜ会社という企業は存在するのか、企業は市場にどんな価値をもたらすのか、ということ。
つまり、経済学の観点では、企業の存在価値とは何か。

コースの定理では、企業は自社の内部に活動を取り込んで内製化する方が効率的だから、存在する、と。
たとえば、大手製造業が数多くの子会社として、ソフトウェア開発、金融保険、食事サービス、果ては従業員の娯楽サービスに至るまで抱えている理由は、内製化して、連結企業グループ内でお金をやり取りする方が、売上も利益も増えるから。

しかし、『プラットフォーム革命』のストーリーでは、20世紀のこの前提は、プラットフォーム企業の出現で崩れた、と言う。

【2-6】プラットフォーム企業は「自然独占」の結果である。
つまり、市場経済の熾烈な競争を経た結果で生まれた「独占」であり、悪い事象ではない。

普通、独占・寡占の企業と言えば、電気・ガスのような固定費が大きい企業とか、法規制で縛られた業界が多いが、プラットフォーム企業は自由な競争の結果の独占企業。

プラットフォーム企業は、今までになかった市場を作り出すことで、新しい価値を生み出してきた。
たとえば、Facebookの個人情報の取扱いを嫌う人は多いかもしれないが、Facebookが自社の利益以上に、人々に多くの経済的・社会的価値をもたらしてきたことは否定出来ないはずだ。

プラットフォーム企業のインパクトは、経済インフラが確立されていない国ほど、強力に感じられる。
たとえば、アリババは中国のデジタル経済の誕生にかなり貢献し、おかげで最辺境の人も自由に商品を購入できるようになった。
一方、日本ではATMが普及しているおかげで、キャッシュレスやカード払いが浸透せず、プラットフォームの恩恵が少ない。

丁度、IT技術は、先行者利益ではなく、後発者利益の方が大きい、という考えに似ている。
特に日本は、プラットフォームビジネスのような新しいビジネスに設備投資すべきなのに、古いレガシーな基幹系システムを数多く抱えているために、IT予算はシステム保守のほうが圧倒的に多い。

【2-7】インターネットとコネクテッド革命は、規模の経済と価値連鎖の概念を根底から覆した。
「計画経済の立案者は大規模な経済活動を効率的に調整できない」というハイエクの主張を無効にした。

昔と今の唯一の違いは、計画立案者が政府の官僚ではなく、プラットフォーム企業が持つアルゴリズムやソフトウェア(検索エンジン、協調フィルタリングなど)になったこと。

面白い点は、共産主義の計画経済では、市民は権力者に反抗していた一方、GoogleやAppleの利用者は、自分がエンパワーされた気持ちになり、彼らの信者になっている。

だから、FacebookやAmazonなどのプラットフォーム企業は、自分達が生み出したマーケット内のルールや規制に相当な労力を費やして、質を高めようとしている。
その努力は、政府の公共政策に似ている、と感じる。

【2-8】プラットフォーム企業の経済活動は貿易利益。
Amazonもアリババも、何もない所から莫大な利益を生み出している。

丁度それは、江戸時代の紀伊国屋文左衛門が、紀州のみかんを江戸で売り、江戸では鮭を買って大阪で売って巨額の利益を得た、という話と同じ。
つまり、貿易という交換作業をプラットフォーム上で大規模に取引することで、莫大な利益を生み出している。

【2-9】従来のビジネスは、限界費用はゼロにはならない。
20世紀の製造業では、ビジネスをスケールするには、需要を喚起する費用と供給コストをどれだけ下げられるか否かにかかっていた。
つまり、製造原価を低減するために、規模の経済を活かすし、価値連鎖の概念を用いて内製化された活動を効率化する。
たとえば、フォードの大量生産、トヨタのJIT、マクドナルドのフランチャイズチェーンなど。

つまり、このビジネスモデルでは、生産工程を管理することで価値を生み出すので、商品をもっと売るには、莫大な設備投資を行い、生産能力を高めなくてはならない。
だが、物理的な資産と人員はスケールしにくい。

しかし、インターネットの普及、スマホの普及で大きく変わった。
現代の情報商品を流通させるには、コピー代はほぼ0円なので、限界費用は基本的にゼロ。

インターネットを使った低コスト流通を早い段階から活用し始めたのがSaaS企業。
しかし、ソフトウェア開発という初期費用、固定費はまだかかる。

一方、プラットフォーム企業では、生産も在庫も必要ない。
自社のプラットフォームで生産者と消費者という二つの顧客を抱えるので、最初にプラットフォームというシステムを作る固定費さえかければ、その後は、生産者と消費者の取引量が増えて貿易利益が指数関数的に増えるので、サプライサイドは生産者がどんどん取引できる商品やサービスを提供してくれるようになるから、サプライサイドの供給コストも限界費用をほぼゼロにできる。

つまり、プラットフォーム企業の費用構造では、保有する資本は非常に少なく、製造業よりもはるかに投資利益率ROICが高い。
このロジックのおかげで、プラットフォーム企業は理論的には市場そのものと同規模まで拡大できる。
だから、GAFAやBATの企業価値は、小国のGDPをはるかに凌ぐまでの大規模な経済になっているわけだ。

【2-10】プラットフォーム企業では、規模の経済ではなく、ネットワークの経済が根底にある。
生産者と消費者という二つの顧客を抱えて、彼らが取引することで貿易利益を得る。
だから、彼らの取引量を増やすことが重要になってくる。

プラットフォームとは、取引の生産工場。

【2-11】プラットフォームビジネスの構築の最初の問題は、クリティカルマスをいかに増やすか?

プラットフォームでは、生産者と消費者の合計参加者であるクリティカルマス(最小必要人数)をいち早く超過することが最初の重要な問題になってくる。
生産者を先に増やすのか、消費者を先に増やすのか?

一度、クリティカルマスを超えれば、プラットフォームビジネスの潜在的スケールは非常に大きい。
なぜなら、クリティカルマスに到達すれば、供給側が費用の制約を受けなくなるから。
よって、プラットフォーム企業が成功する最初の課題は、生産者と消費者の双方を増やすことにある。

【2-12】プラットフォームビジネスの構築の2番目の問題は、流動性をどうやって確保するか?
つまり、プラットフォーム内の生産者と消費者の人数が十分に増えたら、彼らの取引量をいかに増やすか?

需要を満たせる十分な供給があり、ほとんどの取引がすぐに成立する市場(プラットフォーム)は、流動性があるとみなされる。
流動性、つまり取引量が増えれば、ネットワーク効果を大きくさせられる。

流動性がないと、需要と供給はアンバランスになりがち。
需要がたくさんあるのに、供給が少なければ、価格が高騰し、消費者は不便になる。
一方、供給がたくさんあるのに、需要が少なければ、価格は暴落し、生産者が不幸になる。

金融市場における流動性の確保は、各国の中央銀行の使命。
一方、プラットフォーム企業では、自社のプラットフォームの流動性の確保が使命になる。

【2-13】プラットフォームの流動性の確保のためのアルゴリズムは、マッチメーキングそのもの。
たとえば、ウーバーなら、ドライバーと利用客のマッチメーキングは、巡回セールスマン問題と同じ。
Amazonなら、消費者と出店者のマッチメーキングは、協調フィルタリングによる関連購買と同じ。

つまり、流動性を確保するために、システムが自動的にユーザ同士のマッチメーキングを行い、取引を円滑にさせる。
すなわち、プラットフォーム内の需要と供給の均衡は、取引トランザクションから得られたビッグデータの解析を元に、巡回セールスマン問題や協調フィルタリングなどのアルゴリズムで解決させる。

但し、ウーバーは、ピーク料金で需要と供給の均衡を取っている。
つまり、利用者の需要が高まると運賃を上昇させて、少ないドライバーの供給とバランスを取る政策を実行している。
なぜなら、ウーバーではドライバーと乗客の比率は1対10なので、需要と供給のバランスは元々悪い。

よって、プラットフォーム企業は、消費者よりも生産者(ウーバーならドライバー)の獲得に相当な力を入れている。
そのやり方は、法を犯す手前の危ない手法に近い時もあるらしい。
つまり、ウーバーのようなプラットフォーム企業は、流動性の確保が何よりも重要である、と理解していることを意味している。
GAFA、BATも同様で、たとえば、AppleはiOSプラットフォーム上のアプリ開発者を増やすために、SDKを提供し、AppleStoreで販売できるようにした。

そう言えば、「データ分析の力」にも、ウーバーが持つビッグデータを元に、タクシー利用者の需要曲線をリアルに作成した事例があったけれど、そういうタクシー利用者の需要曲線がなぜ必要なのか、は、まさに需要と供給のマッチメーキングの問題解決のために使うからだろう。

【2-14】流動性確保の問題は、経済学の調整問題と同じ。
つまり、需要と供給の均衡をいかに効率的に行うか?

従来の経済学では、市場経済の価格システムが、需要と供給を均衡させる。
その調整が失敗したら、市場経済は効率的な取引が行えなくなり、自壊する。
昔の大恐慌がそれかな。

現代は、プラットフォーム企業自身が、需要と供給の均衡をソフトウェアとアルゴリズムによって、自動調整させている。

従来の市場経済における調整は「神の手」が行う。
現代のプラットフォームでは、ソフトウェアとアルゴリズム、人工知能がその調整問題を解決するように代替している。

【2-15】プラットフォームビジネスの構築の3番目の問題は、流動性の質をいかに維持するか。
つまり、プラットフォーム内で、消費者と生産者の間で、最善な行動(取引)を促す政策(ポリシー)を作ったり、最悪の行動(騙すとか)をさせない政策を行うことだ。

具体的には、消費者と生産者の双方に取引のメリットが得られるように、コミュニティ統治をプラットフォーム企業自らが行う。
そのために、プラットフォーム企業は、消費者と生産者の双方に、最善な行動を促すために、色んな形のインセンティブを付与するし、最悪の行動をさせないために、逆インセンティブを与える。
つまり、特定の行動を促すための経済的インセンティブという飴を付与したり、好ましくない行動を控えさせるように逆インセンティブという罰を与える。

たとえば、AmazonやYoutubeのユーザ評価システム。
消費者が生産者にだまされないようにする。
他方、生産者は消費者から確実に売上を確保できるようにする。
Facebookのザッカーバーグ氏も、コミュニティ統治やポリシー策定を相当考えているらしい。

よって、プラットフォーム設計は、従来の工業的な生産工程の設計ではなく、社会学や行動経済学に基づく人々の行動設計を行なっているのと同じ。
つまり、プラットフォームビジネスでは、コミュニティ統治が重要であり、それを行うには、生産管理手法ではなく、人間や社会の行動の原理原則を研究している学問、たとえば、行動経済学が重要である、という事実を示唆しているのだろう。

実際、人にどんな経済的インセンティブを付与すれば、最善な行動を促すことができるか?
人にどんな規制や法律、罰則を付与すれば、最悪な行動を避けるように促すことができるか?
という問題への解決は、行動経済学がまさにピッタリだ。

生産者や消費者のプラットフォームへの参加を動機づけるような政策を行う事、それがインセンティブになる。
『プラットフォーム革命』では「ユーザグループへの参加を促す補助」と呼んでいるが、それと同じ。
その補助には、金銭、機能、ユーザの優先順位付け、がある。

【2-16】プラットフォームの成長、つまりネットワークの成長には、経路依存性がある。
すなわち、初期ユーザのプラットフォームにおける使い方、そこからの歴史が重要。

他のSNSとの競争を経て、FacebookがSNSの勝者になったのは、質の高いユーザを初期に集めて、その信用を維持してきたから。
Facebookは、現実の人間関係の地図をネット上に実現するという目的のもと、ユーザは実名で人間関係を構築する政策をずっと維持し続けてきた。
そういう歴史と信用があったから、Facebookが勝ち抜いてきた。

【2-17】ネットワーク経済のはしご

ネットワーク効果を生むには、5つの段階がある。

コネクション
コミュニティ内で起こる相互作用の理論価値
つまり、生産者と消費者の最初の接触

コミュニケーション
プラットフォーム上のユーザ間で実際に相互作用が起きる
つまり、生産者と消費者の間の取引
流動性の開始

キュレーション
プラットフォーム場の情報をまとめて整理する
つまり、初対面の生産者や消費者のための、ルールの告知
流動性を増やす

コラボレーション
参加者は互いに与えるために協力する
つまり、流動性の質を参加者自身が維持する

コミュニティ
このエコシステムにおける行動を統治する規範を作り、執行する
つまり、流動性の質を、プラットフォームの参加者達、そしてプラットフォーム企業が規範を定め維持する

【2-18】スーパープラットフォーム

プラットフォームの中のプラットフォームは存在するのか?
プラットフォーム企業が独占企業ならば、それら独占企業が集まる業界では、さらに独占への競争が激化し、最終的には唯一のプラットフォームが全てを支配するのではないか?

たとえば、中国のウィーチャットは、ある意味で最強のプラットフォーム。
あらゆるプラットフォームを制するプラットフォーム。
メッセージング以外に幅広いプラットフォームやサービスのエコシステムをサポートしているから。

ウィーチャットの成功を受けて、一部の専門家や起業家は、オンデマンド経済では、APIによって唯一のスーパープラットフォームに統合される、という考え方を提示した。

しかし、米国では、GAFA以外にも数多くのプラットフォーム企業がひしめいていて、スーパープラットフォームは生まれていない。
競争関係にあるプラットフォームが、従順な姿勢を示すことは考えられないから。

むしろ、今後の流れで最も実現性が高いのは、各プラットフォームのエコシステムの多角化、つまり、プラットフォームのコングロマリット版だろう。

【2-19】プラットフォームは法規制と軋轢が多い

プラットフォーム企業には華やかでプラス面が多いように見えるが、最大のリスクは現行の法令との衝突だろう。
現在の法体系は、20世紀の直線的なビジネスモデル、つまり大規模な製造業を主体とした市場経済を前提としているため、プラットフォームのビジネスモデルと合わない。
よって、業界初の本格的プラットフォームは、法的なグレーエリアで活動する事が多く、法的な問題になりやすい。

たとえば、Youtubeは著作権侵害。
ウーバーは、ドライバーを社内労働者ではなく請負契約業者とみなすので、ドライバーの保険や年金制度などの法的地位を意図的に無視している。
エアビーアンドビーは、宿泊規制や安全基準を適用しているか否か分かりにくく、グレーなゾーンで取引している。
イーベイなど、数多くのネット販売業者は、クーリングオフや不正取引の責任について、消費者から訴えられた。
ペイパルは、商業銀行と同じ機能と見なされ、金融規制が必要ではないか、と訴えられた。

Facebookも個人情報の取扱に疑念がある。
EUのGPDRもそういう背景から生まれたのだろう。

一般的に、プラットフォームのビジネスモデルは、スケールしやすいという大きな利点がある反面、深刻な法規制上のリスクを抱えている。
つまり、多くのプラットフォームビジネスは規制についての先物買い。
法廷闘争に負ければ、ウーバーもエアビーアンドビーも、その企業価値はすぐに失われる。

むしろ、プラットフォームビジネスに合うような法体系も必要ではないか、とも思う。

【2-20】プラットフォームビジネスの機会の探し方は主に3つある。

取引コストが高く、高コストを生むボトルネックがある業界。
たとえば、ウーバーが、ドライバーと乗客を結びつけたプラットフォーム。

未活用の資源やアナログのネットワークが既にある業界。
たとえば、Facebookは、ハーバード大学がいつまで経ってもアナログの学生名簿を作らなかったことがきっかけだった。つまり、現実の人間関係の地図をFacebook上の友達関係という関係マップにマッピングさせたこと。
エアビーアンドビーは、使っていない家やアパート、ソファーでさえ貸出しさせることで、供給者と利用者の双方に価値をもたらした。
アップルのiOSプラットフォームでは、アプリ開発者と消費者を結びつけるネットワーク環境を構築し、開発者にSDKを提供することで、アプリ開発者と消費者の双方に価値をもたらした。

大規模で分散した資源がある業界。
たとえば、中国のアリババは、中国の無数の中小製造業が大手商社につながる流通経路を持っていない現状に対し、デジタル経済のプラットフォームを提供することで、中国の巨大な、しかしバラバラな小企業市場を統合し、中国のeコマースを育てた。
その規模は、米国のプラットフォーム企業と引けを取らないし、今後の成長を考えると、米国よりも巨大になるだろう。

【3】『プラットフォーム革命』を読んだ後で、日本のプラットフォーム企業の現状を考えてみる。

楽天はたぶん、日本最大のプラットフォーム企業なのだろう。
その本質は、ショッピングモールのWeb版。
楽天市場を核として、数多くのWebサービスを展開して、多角化を図っている。

最近なら、メルカリもプラットフォーム企業を目指しているように思える。
楽天がBtoBなら、メルカリはCtoC。
楽天もメルカリも、クーリングオフや不正取引、個人情報保護など、数多くの法規制の疑いがかけられ、そのたびに解決して成長してきている。

とは言え、日本最大の企業であるトヨタにかなわないので、日本のプラットフォーム企業はまだ成長の余地があるのだろう。

【4】この本は、経済学の概念を用いて、従来のメーカーとプラットフォーム企業の違いを鮮やかに説明している点が素晴らしい。
大規模な独占的な製造業でも、独占的なプラットフォーム企業でも、経済学の論理がその市場や業界の制約の配下にあり、その制約の配下で収益の高い企業行動へ最適化した結果、現在の独占的な結果になっている。

従来と現代のプラットフォーム企業における経済学の原理原則の違いは、規模の経済や価値連鎖によるコスト削減効果ではなく、ネットワーク効果による売上の指数関数的効果。

また、従来と現代のプラットフォーム企業における品質管理手法の違いは、生産工程の生産管理の効率化ではなく、流動性の確保と流動性の質の維持。

さらに、従来と現代のプラットフォーム企業における使用する専門知識の違いは、JIT等に代表される統計的品質管理ではなく、人々を最善の行動へ促すためにインセンティブを付与するなどのコミュニティ統治という行動経済学。

【追記】
下記の記事の内容も秀逸。

Modern Monopolies a Review – Sam – Medium

| | コメント (0)

2018/11/18

IOT時代の製造業の戦略と変化についてポーターの考え方

IoTの衝撃―――競合が変わる、ビジネスモデルが変わる (Harvard Business Review)」の感想をメモ。
浅はかな理解で、ラフなメモ書き。

【1】読んだ感想
ポーターが書いた第2章・第3章の内容が秀逸と思う。
「製造業は全てソフトウェア企業に変わる」というGEトップの主張の理由がよく分かる。
IoTによる、外部環境の側面と内部環境、そして組織構造への影響の話が非常に面白い、と思った。

IOTのバズワードがなぜ、これだけ広まっているのか、その理由が何となく分かった気がした。

自分のメモと自分の考えを適当に書いておく。

【2】IOT時代の競争戦略

【2-1】スマート製品の特徴:
データ収集・分析・活用

モニタリング(例:アクセスログから挙動不審を検知)
→制御(例:オートホームメーション)
→最適化(例:予防保全)
→自律性(例:RPA)

【2-2】5フォースの観点:
・買い手の脅威:
例:製品故障の予防データの提供で、メーカーの方が買い手よりも強くなる

・同業他社の脅威:
スマート製品によるデータ収集・分析・活用で、差別化できる
一方、製品へソフトウェアの組込み、クラウド基盤の構築・運用など、固定費が増加する

・新規参入の脅威:
スマート製品とデータ収集・活用基盤のプラットフォーム化で、参入障壁を高められる
一方、GAFAなどの巨大IT企業が参入してくる

・代替品の脅威:
製品のサービス化の進展により、ハード製品の重要性が下がる
例:ホームオートメーションにより、エアコン・家電製品・住宅等のメーカーが参入してくる

さらには、製品の共有サービスへ発展する
最近のライドシェア、ホームシェア、自転車のシェアサービスなど

・供給者の脅威:
ハードウェア業者よりもソフトウェア業者の方が強くなる
ソフトウェアで製品の機能が代替されて、物理的部品が減少する
巨大IT企業が組込みソフトウェア、クラウド基盤、データ収集基盤を使ってくるので、脅威が強くなる

(メモ)むしろ、メーカーは、巨大IT企業からのハードウェア製品のOEM委託の立場に追いやられるのでは?

【2-3】ポーターの考えでは、競争優位の源泉は、コスト削減か差別化の2つしか無い
どちらを採用する?

【2-4】スマート製品の機能:
例:給湯器メーカーのIOT基盤によるデータ収集・活用事業では、個人向けよりも法人向けサービスの方が需要が多く、重要
 機能追加でコスト削減でき、どんどんコストが低減していく

【2-5】製品開発とクラウド基盤構築の配分
クラウドへ機能・データ・UIなどを置く方向へ進化している
そうすれば、頻繁なVerUpがやりやすいので、顧客価値も上がる
その分、ハードウェア製品の重要性は下がる

【2-6】システムのオープン化
他社製品の提供を許し、逆に参入を促す戦略もあれば、
自社製品を他者のプラットフォームに組み込んでもらう戦略もある

【2-7】内製・外部委託の是非
内製化で先行者利益を獲得できる
内製化で自社に知見を蓄積できる
外部委託は、自社製品の差別化をなくすリスクもある

【2-8】データ確保・分析
製品へセンサー装置とソフトウェアを埋め込むため、コストは増える
性能維持・料金回収の目的なら、即効性のあるデータが必要
プラットフォーム化ならば、広範なデータが必要

【2-9】製品データの使用権とアクセス権
鍵は、データの帰属先
データの所有権は、メーカー? 使用者? サプライヤ? それとも、関係者が共有?
完全な帰属権、NDA保持、利用権、共有権、販売権など

最近は顧客がデータ共有に強い意欲を持つケースがある
例えば、顧客が自信のフィットネス情報をSNS共有
むしろ、メーカーがデータの活用方法を価値提案して、差別化していく戦略もある

データの利用許諾について、クリックスルー形式の規約承認が多い
初回使用時にデータ収集の同意を使用者から得る
しかし、法制度が追いついていない

【2-10】流通チャネル
従来の自動車業界では、代理店を通じた販売が多いので、メーカーは顧客と直接の接点はなかった
しかし、IOTでデータ収集により、顧客と接点を持てる
例えば、テスラは直販により、顧客から直接、データ収集して、顧客のフィードバックを得られる

テスラの場合、
顧客からデータ収集
→顧客関係性の強化
→収益向上
→ブランド認知の向上
→顧客満足へ貢献

但し、顧客との物理的距離に依存するので、制約条件はある
例:配送、物流、販売、在庫

【2-11】ビジネスモデルの手直し
従来は、製品売り切り型
販売後に、所有権を使用者へ移転した

一方、製品のサービス化で、所有権はメーカーが持ち、使用料を継続徴収というビジネスもあり
しかし、ジレンマは、消耗品販売・サポート保守ビジネスで既に稼いでいる企業は、IOTのメリットがない

製品の共有サービスまで発展している
例:ライドシェア・サービス

【2-12】製品データを第三者へ販売
他者には価値あるデータ
例:車両、交通インフラ

(メモ)そういえば、JR東日本の事例もあったね

しかし、プライバシーのリスクあり

【2-13】事業範囲の拡大

関連製品の多角化
製品設計よりシステムエンジニアの方が重要
ハード設計より、組み込みソフトウェアやクラウド基盤の構築の方が重要

ソフトウェアを含むプラットフォーム化
自社製品は変えず、他者も自由に接続できるようにする

製品の最適化に進むのか、製品以外の最適化を進めるのか?

【3】IOT時代の製造業

【3-1】IOTによって、バリューチェーン上の活動は、スマート製品の影響を受けるだろう
真因は、データ資源にある

従来は、部門同士の情報連携に過ぎなかった
一方、IOT時代は、製品自体がデータ資源になる
例:サービス履歴、在庫、稼働率、物流、修理保守の予防、顧客データなどが全て収集できる

【3-2】製品開発部門
ハードウェア製品の研究開発を担当
しかし、ソフトウェア開発が主体になる
製品の内蔵ソフトウェアよりも、クラウド基盤上にソフトウェアがたくさんある

製品の可変性はソフトウェアが担うようになる
部品削減によるコスト削減、VerUpのし易さ、出荷後も新機能をリリース可能になる

品質管理が強化される
アクセスログから、事故の状況を再現しやすくなる
例:テスラのバッテリ発火事故から、自己の状況を再現させて、品質管理を強化したソフトウェアを全製品へリリースした

新規ビジネスモデルを支援する
製品のサービス化、利用状況データ収集による課金サービスなど

【3-3】製造・物流部門
機械や生産工程の稼働率向上
在庫削減

【3-4】マーケティングと販売部門
顧客のセグメントを精緻化できる
製品を通じて、顧客と対話できるようになる
利用時間に応じたサービス事業へ発展する
長期にわたって、顧客を支援する

【3-5】アフターサービス部門
耐用期間の長い製品メーカーはとても重要

遠隔サービスの実現
保守のワンストップサービス
事前に診断し、修理回数を減らせる

予防サービスを強化
AR機能を使って、サービス担当者が遠隔サービスで修理する
(メモ)ARはゲーム業界の技術の一つと思っていたが、メーカーにとっては重要な技術要素の一つなわけだ

しかし、データ維持のセキュリティはまだ問題がある
DoS攻撃を受けやすい
組込みソフトウェアの脆弱性が大きい

【3-6】メーカーの組織形態へ影響

「メーカーは全てソフトウェア企業になる」主張とは、ソフトウェアが製品の根幹をなす、ということ
メーカーは、今後、ソフトウェア企業以上の変化を受けるだろう
なぜなら、メーカーは、既に沢山のバリューチェーンを持ち、既存の部門が多いので、影響を受けやすいし、変化を受け入れざるを得ない

従来のメーカーは、職能別組織が多い
バリューチェーンの単位で、R&D部門、製造部門、生産管理部門、販売部門、保守サービス部門、IT部門などに分かれていた
それらの部署は自律性が高い

しかし、設計・オペレーション・販売・サービス・IT部門同士の役割が重複してきた
理由は、製品のサービス化により、顧客関係性をより重視するし、クラウド基盤上でデータをやり取りするから

すると、新旧組織の併存となり、組織構造が複雑化してきている

【3-7】メーカーの組織構造への重要な変化とは
4つの変化が見られる

IT部門とR&D部門の協働・連携
統合データ部門の新設
開発運用部門(DevOps)の新設
顧客成功管理部門の新設

【3-8】IT部門とR&D部門の協働・連携

従来のIT部門は、社内インフラ、CAD、ERP、CRMなどの管理と運用がメイン
しかし、製品・他部門スタッフもIT化が必要
すると、誰がその役割、責任を持つのか?
ITのスキルを持つIT部門しか担えないでしょう

一方、R&D部門はハードの開発が専門で、製品へのソフトウェア埋め込みにも関わる
しかし、クラウド基盤のサービス運用のスキルまではない
製品の定期的なVerUpや頻繁なリリースが必要になるので、R&D部門では対処しきれない

そういう変化があるので、最近は、IT部門とR&D部門の区別がなくなってきている
つまり、マトリクス組織になっている
IT部門の人は、R&D部門にも所属し、クラウド基盤の運用にも携わる
逆も然り

【3-9】統合データ部門の新設

データ専門の部署
CDO(データ部門の最高責任者)を設ける

データ管理、データのセキュリティ維持等に関わる
データ資源の戦略的重要さから、専門性を発揮するために新設される
製品データの活用、教育、権利の管理、アクセス監視、データ活用によるマーケティング策定など、仕事は幅広い

【3-10】開発運用部門(DevOps)の新設

従来の製品開発部(Devs)のIT技術者と製品保守・サービス部のスタッフが結集して、開発運用部門(DevOps)が新設される場合が多い
IT企業のDevOpsのメーカー版
但し、IT企業のDevOpsよりも、活動範囲は広い

製品提供のライフサイクルを一元管理している
クラウド基盤上へリリースして、不具合修正の頻繁な更新とか

【3-11】顧客成功管理部門の新設

顧客経験を管理する、というソフトウェア企業の機能をメーカーに置き換えた
従来の販売・サービス部門が行わない業務、インセンティブ外の業務を担当する
例:コールセンターへの顧客クレームの前に、顧客のログから検知し、事前に予防する、など

【3-12】しかし、セキュリティ管理部門はない
今は方針が定まっていない
ソフトウェアはIT部門、ハードウェアはR&D部門や開発運用部門が担当している

【4】個人的な感想としては、メーカーは大変だな、と思う。

メーカーは従来のビジネスのやり方、従来の部門があるために、ソフトウェアを重視した組織構造や組織文化と併存せざるを得ず、混乱するのではないか。
ソフトウェアを重視した組織構造や組織文化では、アジャイル開発のベストプラクティスをベースに置くために、従業員の自由度が高く、勤務体系や報酬制度もかなり違ってくる。
ハードの文化とソフトの文化は水と油と思う。
結局は、別会社にするとか、別事業部にするだろうが、連携が大変そう。

メーカーにおける開発運用部門(DevOps)という発想は面白いと思った。
結局、製造業でもDevOpsという発想が必要になってくるわけだ。
しかし、その範囲はソフトウェア開発・運用だけでなく、ハードウェアの企画開発・保守サービスも含んでくるので、より複雑になっているのだろう。
ハードとソフトの両方の知識と経験がなければ、相当難しいのではないか。

統合データ部門という発想も面白い。
アリババの馬CEOは「データはビジネスの副産物として採取される」と言ったが、メーカーにとって、製品がデータ資源そのものになる。
すると、大量のデータをいかに活用するか、ということが重要になってくる。

その時の留意点の一つは、データの権利関係だろう。
個人情報が含まれるために、そのデータの所有権、利用権、販売権の管理は慎重にならざるを得ない。
一方、データを上手く活用できれば、新たなビジネスモデルを構築できる。

そういう一連の戦略を策定し、実際のデータ収集・活用を管理する部門を設置することで、専門性を発揮させるわけだ。
昨今、データサイエンティストというバズワードが流行しているのは、そういう背景があるからなのだろう。

では、メーカーは、製品のIOT化によって、自社でプラットフォーム化できるか?
メーカーが自社のプラットフォーム基盤を構築するあるべき姿は、アップルのビジネスモデルになるのだろう。
しかし、純粋なメーカーが高度なソフトウェア開発力を持てるようになるのは難しいだろう。

個人的な感想では、たぶん、メーカー自身では無理と思う。
自社にソフトウェア開発の組織文化がないので、外部のソフトウェア企業の力を借りるしかないと思う。
つまり、ソフトウェアの内製化は結構ハードルが高いのではないか。

すると、大手IT企業のプラットフォーム基盤上で、メーカーは彼らのハードウェアOEM生産という委託の立場に追いやられるのではないか。
アップルのように、自社で製品の企画、ソフトウェア開発は行い、ハード生産は外注委託する分業スタイルに落ち着けば、メーカー自身の強みであるハード製造の部分を捨てざるを得ないから。

| | コメント (0)

2018/11/16

ポーターの競争戦略の考え方

ポーターの競争戦略の考え方がようやく分かったのでメモしておく。
自分だけのメモ書き。

【参考】
外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 1ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 2ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 3ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 4ページ

外部環境分析:ポーターのファイブ・フォース分析から考える | 経営戦略を読み解く?実務と理論の狭間から?|DIAMOND ハーバード・ビジネス・レビュー 5ページ

戦略論の復習②…ポジショニングアプローチ | 田舎者の受験日記

【1】ポーターの競争戦略の基本構想はこんな感じ。

経済学の分野の中で、産業組織論がある。
産業組織論では、ある業界(市場)の制約条件が企業行動を制約し、結果として企業の収益率を決定する。
いわゆるSCPモデルでは、売上と収益率の分布図を書くと、V字モデルで表現される。
つまり、高収益企業は、売上は小さいがニッチ市場に特化した中小企業か、売上が大きく規模の経済を活かした大企業のいずれかになる。

V字カーブ

この考え方を逆手に取って、企業は、業界内で収益率の高いポジションへ移動すべき、というポジショニングアプローチを取る。
つまり、ポジショニングアプローチとは、①外部環境を分析して機会のある産業を発見し、②当該産業へ進出して参入障壁を築き持続的競争優位を確立する、という考え方で、産業分析→基本戦略の決定の順に行う。

すると、課題は「収益率の高い産業をどのように発見するのか」になる。

一般的な手順としては、
①PPM分析や5フォース分析を行い、収益率の高い産業を探す
②進出すべき産業が見つかったら、ポーターの基本戦略に基づき、業界のターゲットの幅と競争優位の源泉の2軸による分析で、コストリーダーシップ・差別化・集中戦略のいずれかを採用する
③基本戦略が決まったら、最後にその実施による参入障壁の形成と、持続的競争優位を確立し維持する
④さらに、自社の経営資源をバリューチェーン分析し、強みである経営資源の差別化を図る

価値連鎖(バリュー・チェーン)と活用方法

【2】ポーターの競争戦略で面白い、と思った点は2つ。

一つは、産業組織論という経済学の理論を背景にしているので、実証データがあり、経営学という曖昧な学問にも論理的な枠組みを提供して、思想を整理できること。

もう一つは、「プラットフォーム革命」を読んでみて、ポーターの競争戦略やコースの定理という経済学の基本思想を元にGAFAのような大手プラットフォーム・ビジネスを分析してみると、非常に分かりやすい、と思ったこと。
ゼロ・トゥ・ワン」を読んで、プラットフォーム企業は独占利潤を得るから安定している、みたいな主張がよく分からなかったけれど、「プラットフォーム革命」を読んで何となく分かった気がした。
the four GAFA 四騎士が創り変えた世界」の内容も、ポーターの競争戦略の基本思想「ポジショニング」「バリューチェーン」から考えると分かりやすくなると思う。

経営理論は、経営者という人に依存した理論と思っていたけれど、経済学の発想を適用すれば、政治的力を持つ人の恣意的な意思決定に無関係に決定する内容が多い、ということが分かった。
また、大手プラットフォーム・ビジネスも、従来の製造業の仕組みとは異なるビジネスモデルであったとしても、経済学の理論や制約条件に依存しているし、そこから離れられない。

【3】僕の理解では、プラットフォームビジネスとは、経済学の言う「貿易利益」で儲けている。

そのプラットフォームは、自由競争のない計画経済の基盤から成り立っているので、事実上の独占状態であるから、独占利潤を独り占めできる故に、史上最大の企業価値を持つに至った。

たとえば、GAFAやアリババは、何もない所から貿易利益によって莫大な独占利潤を得ていて、その利潤は、小国のGDPをはるかに凌駕するくらいの価値を生み出す。
しかし、Facebookの影響力が大きすぎるがゆえにトランプ大統領を生み出したように、プラットフォーム企業は民主主義制度を破壊するくらいの政治的影響力を持つという側面も出てきた。
この辺りの理論と現実は、現在進行中みたいな感じなのだろう。

この辺りの理解した内容も後でまとめる。

| | コメント (0)

«第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT