« 2018年10月 | トップページ | 2018年12月 »

2018年11月

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)

2018/11/11

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

第15回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
また、コミッタの前田さん、数多くのプラグイン開発者・パッチ開発者の方にも感謝です。
以下は、講演を聞いて、感想をラフなメモ書き。

【参考】
第15回勉強会 - redmine.tokyo

2018/11/11 第15回勉強会 - redmine.tokyo - Togetter

日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について: プログラマの思索

Redmineでやってみた - うさぎまんじゅう - BOOTH

【1】参加者の方から、以前の勉強会では講演の数が少なくて、時間を持て余す時が多かったのに、今回の勉強会では講演の数が多すぎて盛りだくさんだった、という感想を聞いた。
確かに、大LT大会になったので、詰め込みすぎたかもしれない。

他方、それだけのコンテンツが集まる事実は、日本のRedmineコミュニティで数多くの事例やカスタマイズのノウハウが蓄積されていることを示しており、コミュニティとして成熟していることかな、と思った。

【2】今回の勉強会のテーマは「Redmineの次バージョン4.0に向けて、皆のノウハウを共有しよう」だったが、隠れたテーマは「日本のプラグイン開発者やコミッタ、パッチ貢献者にコミュニティから感謝の声をあげよう」だったと思う。
@g_maedaさん、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさん、@naitohさん、前田みのるさん他多数のプラグイン開発者に声が届けられて良かったように思う。

中村さんの講演では、現場のRedmineに15個もプラグインを入れていて、プラグイン開発者に拍手喝采を、という内容はまさにそうだった。
Discord上でRedmineコミュニティを運営しているMaxさんの講演も、Redmineのテーマ改善など機能拡張をコミュニティドリブンで開発しよう、という内容だった。

そして、僕のLTでは、Redmineコミュニティがマネージャ層とRuby開発者という二つの全く異質なターゲットから成り立っている特徴を強みとみなし、異質な特徴を持つ彼らが相互交流することで、Redmineの進化を加速させるエンジンになりうるはず、という主張を試みた。

実際、今日の参加者とグループディスカッションや懇親会で話を聞くと、マネージャ層の人達もいれば、プラグインやパッチ等の開発者も多く、多様な参加者から成り立っていた。
たぶん、こういう交差しないセグメントのターゲットが2つ以上もあるようなコミュニティは、非常に稀で、貴重な場ではないか、と思う。

普通のOSSコミュニティは、利用ユーザだけとか、実際の開発コミュニティとか、セグメントがどこかに特定されているような気がする。

【3】では、なぜ、Redmineコミュニティはそのような異質なセグメントのターゲットを2つ以上持つことができたのか?

理由は、Redmineには2つの顔があるからだ。
一つは、「ソフトウェア工学の理論を実験できるプロジェクト管理ツール」という側面で、マネージャ層に対応する。
もう一つは、「汎用的なプロジェクト管理の開発基盤」という側面で、こちらがプラグイン開発者やRuby開発者に相当する。
つまり、全く異なる出身を持つ二つの層が生まれたことで、Redmineの機能改善を相互に議論しあえる場が生まれたように思っている。

たとえば、マネージャ層は、自分達の管理作業を楽にしたいためにRedmineを使うが、Rubyの開発はおそらく殆どの人ができない。
一方、プラグイン開発者は、実際の現場のニーズを元にRedmineに不足した機能を実装し、プロセス改善に役立てる。

Ruby開発者は、マネージャを顧客に見立てて、Redmineに不足した機能を実現できる力を持つ。
一方、マネージャは、プラグインを利用することで、自分達の開発プロセスや組織文化に合わせてRedmineにカスタマイズを施し、彼らのあるべき姿にRedmineをFitさせる。
たぶん、新たなプラグインがマネージャ層の潜在ニーズを刺激し、新たな改善アイデアを生み出すだろう。

実際、今日のLTでもリソース予約プラグインを開発した話があり、タスク管理に使われるRedmineを会議予約システムとみなして使う、という事例もあった。
つまり、柔軟なRedmineのおかげで、マネージャや利用ユーザの潜在ニーズが刺激され、数多くのアイデアが生まれる、という良い意味でのらせん構造が生まれている。

【4】すると、今後のRedmineコミュニティの発展に必要な要素は2つあると思う。
一つは、Ruby開発者をRedmineコミュニティにもっと巻き込みたい、ということ。

なぜなら、他の競合のチケット管理ツールに対し、Redmineが競争優位性を保つには、もっとRedmineの進化の速度を上げたいからだ。
現状のRedmineには、いくつかの課題があると思う。

僕が感じている課題については、以前書いた。

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

また、Maxさんも同じく、Redmineの画面UIをもっと今風に改善したい、と思われている。

換言すれば、次の3つに課題が集約されるのではないか。

1・シングルページアプリケーション化などの画面UIの改善
2・プルリク実装などのGit連携の機能強化
3・プラグインのGem化、RedmineのVerUpの自動化などの、VerUp自動更新機能

おそらくそれらの課題の解決は、そう簡単なものではない。
だが、多くのRuby開発者をRedmineコミュニティに巻き込めば、実現のハードルは下がるだろう、と思う。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【5】もう一つは、Redmine運用に関する数多くの知見を一つの体系にまとめ上げて、誰もが再利用できるようなプラクティスや知識を提供すること。

なぜなら、大阪や東京のRedmine勉強会で参加者から要望されるニーズは、Redmineの運用事例が知りたい、という内容が多いからだ。

実際、Redmineが生まれて10年以上経った今、障害管理だけでなく、タスク管理、会議の管理、資産管理、ヘルプデスクなど数多くの事例がRedmineで実現されている。

たとえば、今日のグループディスカッションでは、ITILのプロセスをRedmineで完全に実装した事例を持つ参加者がいた。
具体的には、Zabbixで検知したエラーメールはRedmineにチケットで自動登録され、インシデントとして認識される。それらチケットを精査して、修正対応すべきと判断されたチケットは、問題管理へエスカレーションされ、対応策の検討後、リリース管理で開発・リリースされる、という流れ。
つまり、この参加者の方は、システム保守・運用の立場の人なのだろう。

この話は僕も以前経験していて、ITILとRedmineは非常に相性が良いと思っている。
しかし、インシデント管理・問題管理・リリース管理などの各プロセスをRedmineにどのようにFitさせるか、については、運用してみると理論通りにうまく行かない部分がある、というのも経験している。

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事: プログラマの思索

エスカレーションをRedmineで運用する方法: プログラマの思索

そういうアンチパターンやプラクティスなどのノウハウを、利用シーンごとにまとめて、体系化してみたい。
おそらく、そういう知見を集めて体系化して、その知識を普及させる役割が、Redmineエバンジェリストであり、Redmine警察に相当する人達だろうと思う。

【6】今日の勉強会の中で、ツイートしながら生み出せた考え方は、「Redmine運用の4原則」のようなものがあるのではないか、ということ。
Redmine運用の4原則とは、Redmineがチームに馴染むには、プロセス・ツール・スキル・マインドの4つの要素がいるのではないか、ということ。

この考え方の発端は、Jiraのような多機能なチケット管理ツールの場合、プロセスを実装した経験がない管理者がJiraを使って運用させようとすると、失敗しやすいのでは、という話から生まれた。

ツールを使いこなすには、プロセスを知っておくことが大前提。
そして、ツールを使いこなしたり、プロセスをテーラリングできるスキルも重要。
また、プロセスやツールを受け入れるマインドもいるね、と話が広がった。

しかし、本当にこの4つで十分なのか、MECEに整合性が取れているのか、この4原則でアンチパターンの事象を演繹的に説明できるか、については検証が必要、と思っている。
でも、この4原則を検証してみるのは価値がある、と思う。

【7】最近の僕が個人的に持っているRedmineのテーマは「組織とRedmineは相互にどんな影響を与えているか」だ。

具体的には、組織構造がRedmineにどんな影響を与えて、Redmineをどんな方向に複雑化させるのか。
一方、Redmineを導入し運用することで、組織文化にどんな影響を与えて、組織にどんなメリットを与えてくれるのか。

例えば、縦割りのガチガチの組織構造は、単一の標準Redmineのワークフロー設定、トラッカー設定を複雑化させる。
その複雑化に現場が対応できなくなると、各事業部や各チームごとにRedmineインスタンスが乱立し、野良Redmineが生まれ、IT統制が効かない状態になりうる。
つまり、組織のやり方にRedmineをカスタマイズしてフィットさせて、プロセスをテーラリングしたいが、実際は理論通りにテーラリングはうまくいかない場合が多い。

一方、縦割りの組織にRedmineを導入すると、Redmineの機能に埋め込まれたベストプラクティスをメンバーが自然に受け入れることで、チームの作業が効率化されることもあるだろう。
また、Redmineがメンバー間のコミュニケーションを活発化させ、より良いプロセス改善がもっとできるのでは、というメンバーの貢献意欲を引き出す場面もあるだろう。
つまり、Redmineはチームの文化を変容させる力を持っている。

そんな経験を踏まえて、「Redmineは組織構造に従う」「Redmineは新たな組織文化を生み出す」という二つの双方向な事象を整理したいと思っている。
実際、Redmineを利用しているマネージャは大企業の方が多いので、組織構造や組織文化とRedmineのバランスを見出すことに苦労しているのではないか、と思うからだ。

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

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

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

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

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

グループディスカッションでも、懇親会でも、参加者が持つRedmine運用の問題意識にはこれらが関係しているような気がした。

以前「Redmineによるタスクマネジメント実践技法」で当時の自分が考えていたアイデアは全て書いたけれど、上記のテーマでまた新たに書いてきたくなるなあ、と思った。




| | コメント (0)

2018/11/09

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について

第15回redmine.tokyo勉強会のLT資料を事前公開しておく。

【参考】
日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回勉強会 - redmine.tokyo

【1】Redmineには2つの顔がある。

一つは、ソフトウェア工学の理論を実験できるメトリクス収集集計基盤/開発プロセスの運用基盤である顔。
Agile開発もWF型開発も運用可能であり、ワークフロー設定できるならば、全ての開発プロセスをRedmineで一元管理できる。
そこから、Redmineは開発プロセスの運用基盤になり、ソフトウェア工学やプロジェクト管理に関するメトリクス収集・集計基盤になりうる。
つまり、定量的なプロジェクト管理の手段をRedmineによってようやく手に入れられることになる。

もう一つは、汎用的なプロジェクト管理ツールの開発基盤である顔。
RubyとRailsの基盤のおかげで、機能のカスタマイズがやりやすい。
REST APIやrakeなどの外部接続I/Fもあるので、システム連携もやりやすい。

そのおかげで、Redmineに不足する機能をプラグインで実現できるので、プラグイン開発者が多い。
特に日本では、ガチガチの縦割りの組織や自社の開発プロセスに合うように、Redmineをカスタマイズしやすいので、ニーズが多い。

また、Redmineが柔軟な開発基盤を持つおかげで、Redmineコミュニティ自体が活発化している事象もある。
柔軟なソフトウェア設計は、OSSコミュニティを活発化させるメリットがある。
他方、OSSコミュニティの活発化は、ソフトウェアをさらに進化させる、という双方向のメリットがある。
その考察は以下に書いた。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

【2】言いたいことは2つ。

Redmineコミュニティの参加者の多様化を図ること。
もう一つは、Redmineのエコシステムを作ること。

Redmineコミュニティの参加者層は2種類あると思う。
一つは、プロジェクトマネージャなどのマネージャ層。
もう一つは、プラグイン開発者などのRuby開発者層。

つまり、プロジェクトマネージャかつRuby開発者である層は非常に少ないだろうから、コミュニティで相互の交流を図ることで、斬新なアイデアが出てきて、Redmineを更に進化させる余地がたくさんあるだろう。

マネージャのニーズはRuby開発者にとって、新たなプログラミング体験のチャンス。
Ruby開発者が提供するRedmineの新機能やプラグインは、マネージャのニーズをさらに刺激して、より良いものへ発展させるだろう。

その場合、Redmineベンダーも実はコミュニティのステークホルダーの一人なのだ。
彼らも有償ツールではあるが、Redmineのマーケット拡大に寄与している部分がある。
最終的には、彼らも含めて、Redmineコミュニティが熱気を維持し続ける方向へ持っていきたい。

そういう活発な議論を提供する場をコミュニティで実現したいと思う。

| | コメント (0)

2018/11/06

ネット小説「悪の組織の原価計算」のリンク

商工会議所がネット小説「悪の組織の原価計算」を公開しているのでリンク。

【参考】
ネット小説「悪の組織の原価計算」の連載を開始しました | 商工会議所の検定試験

簿記でもこういう小説が公開されるとは、時代の流れを感じる笑。

| | コメント (0)

« 2018年10月 | トップページ | 2018年12月 »