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/30

第15回redmine.tokyo勉強会の見所

第15回redmine.tokyo勉強会の見所をラフなメモ。

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

第15回redmine.tokyo勉強会 - connpass

第15回redmine.tokyoの見所 マドびっ! Madosan's View

(引用開始)
redmine.tokyo の第15回勉強会を開催します。 今回のテーマは『出るぞ4.0!Redmineの活用ノウハウをみんなで共有しよう!』です。

昨年のメジャーバージョンのリリースから1年経ち、今年末頃にVer4.0がそろそろリリースされるようです。 そこで、次期バージョン4.0のリリース前祝いとして、Redmineの活用事例やより良い使い方のノウハウに関する勉強会を行います。

具体的には下記になります。

・次期バージョン4.0の機能紹介
・Redmineを利用する組織能力向上の事例
・RedmineとJiraの機能比較に関する事例
・LT枠を大幅増枠して、Redmine活用ノウハウに関する「大LT大会」

グループディスカッションでは、Redmineの初心者も気軽に質問できたり、Redmine経験者の経験談を共有できる場を設けます。 是非、参加者同士で、Redmineの疑問点を質問したり、運用ノウハウや技術ノウハウを共有してみて下さい。
(引用終了)

【1】勉強会の内容は、講演者5名、LT10本(増えるかも?)なので、Tipsやアンチパターン、運用事例、最新機能紹介など幅広くなった。
最近は参加者が多いので、多様なユーザのニーズに答えられるだろうと思う。

個人的に興味があるのは、いくつかある。

【2】@onozatyさんの講演「View customize 1.2.0 の紹介」では、ViewCustomizeプラグインのカスタマイズ事例が説明される。
Redmineの画面UIを即座にカスタマイズしたい時、ViewCustomizeプラグインは必須なので、いろんな利用事例がユーザ同士で共有されるといいな、と思う。
ちょっとした画面UIの改善は、特に、Redmine導入時や、運用の推進に大変役立つから。

【3】@MadoWindaheadさんの講演「redmine導入における効果的なヒント 組織の成長と難敵に対応する作戦と特技ついて」は、「Sqip2018 チームビルディングにおける心理的障壁の傾向と緩和策の提案」の改訂版と聞いている。

asakoyanukiさんはSEPGで標準化を推進する立場として、たぶんたくさんの苦労されていると想像する。

(引用開始)
Redmine.tokyo勉強会で行われるグループディスカッションでは、参加者同士が 現場での問題や悩みごとを話し合う。
⇒ Redmineの利用の仕方よりチームビルディングに問題あり
A:チームの成熟度の問題 B:上司が問題 C:ツールリテラシーの低さ など
⇒Redmineの利用の仕方よりチームビルディングに問題あり
(引用終了)

上記の資料を読むと、Redmineの利用推進よりも、チームビルディングに問題があった、という指摘が非常に面白いと思った。
組織構造や個人の能力が問題ではなく、チームの成熟度に真因があったわけだ。
おそらく、現場の問題がたくさんあって、Redmineを上手く使えば、それら問題はある程度解決できるはずなのだが、チームとして未成熟なため、なかなか運用が根付かない、という状況があるのだろうと推測する。
そういう問題を、チームの成熟度のレベルに合わせて、解決方法を変えて実施する、という話なのだろう、と思う。

そういう話を聞くと、リーダーシップのSL理論(状況対応型リーダーシップ)を連想させる。

SL理論 ? リーダーシップインサイト

リーダーシップのSL理論とは

つまり、プロジェクトリーダーはメンバーの成熟度に応じて、リーダーシップの発揮方法を変えるべきである、という古典的理論。
おそらく、Redmine運用の方法も、チームの成熟度に合わせて、指示的→コーチング→支援→権限委譲のようにかわっていく、いやむしろ、変えていくべき、という発想になると思っている。

【4】@forenoonMさんの「Redmine使いが注目したJIRAの機能」も興味がある。
「Redmine使いが業務でJIRAを使って注目した機能を紹介します。」という紹介がすごく興味がある。

世界的にはRedmineよりもJiraの方が有名だし、有償ツールのため、機能も豊富。
しかし、僕自身としては、RedmineにはOSSだからこそのメリットが多々あると思っている。
日本でRedmineが広がっている理由には、ネット上に数多くの情報があり、ユーザコミュニティが活発であることもあると思う。

その場合、他のチケット管理ツールのベストプラクティスやTipsをRedmineにも横展開できるはずだし、Redmineの使い方をより進化させてくれるはず。
そんな事例かな、と思っている。

【5】他にもたくさんのLTがあるので楽しみ。

なお、最後に僕もちょっとだけLTさせてもらう予定。
Redmineコミュニティを通じて、僕も、オープンソースとの関わり方、コミュニティを持続させていくのに必要な心構え、などをたくさん経験させてもらった。
そこで、東京と大阪のRedmineコミュニティに携わる一スタッフとして、今後のコミュニティはどうあるべきか、私見を述べてみたいと思った。

| | コメント (0)

2018/10/22

Redmineのバージョン機能に別の意味を与える改善に関するアイデア~バージョン機能はリズムという恩恵を利用者にもたらす

Redmineのバージョン機能に別の意味を与える改善チケットが起票されていた。
以下、ラフなメモ書き。

【参考】
機能#17907:バージョンに別の意味を与える - Redmine

(Google翻訳開始)
Redmineはプロジェクト管理に適しています。しかし、実際のソフトウェア開発だけでなく、だから、バージョンはソフトウェア開発プロジェクトではあまり意味がありません。

私の提案:バージョンがバージョンかマイルストーン、ターゲット、フェーズ、ステージなどであるかどうかをユーザーに選択させる。

実現は非常に簡単です。'バージョン'のタイプを指定する別のフィールドを追加するだけです。ユーザーがドロップダウンで選択する必要のあるバージョンを作成する場合は、そのタイプを選択します。理想的には、いくつかのアイコンを追加して、ロードマップなどのバージョンタイプを視覚化することができます。

さらなる開発では、バージョンタイプを構成可能にすることができます。しかし、これは私の場合はそれほど重要ではありません。私は人がバージョンを使うのが好きではないことに気付くだけです。これがちょうど別の名前を持つことができるのであれば、はるかに明確になります。
(翻訳終了)

【1】僕にとって、Trac、Mantis、Jiraなどの他のITSの運用では分からず、Redmineを運用して初めて理解できた機能が「バージョン」だった。
つまり、Redmineの「バージョン」をXPのイテレーション、Scrumのスプリントとして扱う事で、タイムボックス的なアジャイル開発プロセスを簡単にRedmine上で実装できる。

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

しかし、この事実に気づいて運用して以来、10年も経つと、もっと色々考えたくなる。

【2】上記の改善チケットでは、「バージョン」の名称をユーザが選択できる機能を追加することを提案している。
理由は、ソフトウェア開発以外の場面で、タイムボックス的なプロセスを実現したいからだ。

僕自身は、ソフトウェア開発では、バージョンとマイルストーンは一致させる運用で良いと思う。
開発チームは、本番リリースの運用サイクルを起点とし、本番リリースのサイクルを自分たちの開発リズムとして捉えれば良い。
なぜなら、ソフトウェアにとって本番リリースすることが、顧客にビジネス上の価値をもたらし、開発チームに売上をもたらすので、本番リリースのタイミングを「バージョン」として名付けて、その開発リズムを大切にすることが重要だからだ。

むしろそれ以外の、たとえば、上司への月次の定期報告のようなマイルストーンは不要だと思っている。
本番リリースに直結しない報告タイミングなど、タイムボックスとして無意味だからだ。

【3】一方、ソフトウェア開発以外の利用シーンでは、バージョンという言葉が適合しにくい場面があるのは確かだ。

たとえば、「入門Redmine」に掲載されている事例として、毎年の農業の作業履歴をチケットとして記録し、四季や月ごとにバージョンを設定している事例があった。
すなわち、農業の「タイムボックス」は四季や月が相当するわけだ。
同様に、その他の業務でも、「タイムボックス」を表す名称として、マイルストーン、フェーズ、ステージなどの言葉の方がしっくり来る時もあるだろう。
そうであれば、ja.ymlで「バージョン」に該当する文言は、各業務のタイムボックスを表す名称に一括置換した方が、ユーザフレンドリーになるだろう。

【4】僕は、Redmineのようなチケット管理システムでは、「バージョン」という機能は単なるチケットを分類する機能ではなく、チケットにタグ付けする機能でもない、と思う。

チケット管理システムの「バージョン」は、利用者にチケット運用の「リズム」という恩恵をもたらす。
そのリズムがあるからこそ、チケット運用はスムーズに流れるし、そのリズムが心地よいと感じる。
そのリズムが生まれる背後には、タイムボックスという概念が隠れているからだ。

チケット駆動開発のモチーフ: プログラマの思索

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

[TiDD] 出版裏話1:没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -: ソフトウェアさかば

(引用開始)
実際、あきぴーさんとSPESの論文を書く際には「チケット駆動開発」以外の名前を検討するべく提案しました。

しかし、あきぴーさんの答えは明確で「チケット駆動開発」は譲れないとのこと。当時は、しぶしぶながら承諾しましたが、この理由は、のちに私がチケット駆動開発を実践してみて、ようやく分かたのでした。それは

  チケットがプロジェクトをテンポ良く推進してくれる

ということです。本の中では「リズム」と言う表現をしていますが、チケット駆動開発を実践していると、

 朝:チケット一覧を見て、作業計画を立てる
 昼:チケットの作業を順にこなしていく
 夕:チケットの進捗を登録する(完了チケットのクローズ)

という、開発パターンに体がなじんで、プロジェクトがリズミカルに進んでいきます。これは、体験してみないと分からない感覚でした(もし、チケット駆動開発を実践しているのに感じられないなら、備忘録のような細かなチケットをもっと発行してみてください)。

この「リズム」を感じる個人のプロセスは、チケット駆動開発のアジリティとも関係する大切なものです。ぜひ、チケット駆動開発を実践して体験してみてください。
(引用終了)

一方、そういうリズムが感じられないチケット管理システムは、単なる強制ツールに過ぎない。
タイムボックスという概念のないRedmineは、運用していてもたぶん楽しくないだろう。

上記の改善チケットが生まれる背後には、Redmineの利用シーンがソフトウェア開発以外にも広がっている事実が世界中で発生していることを示唆していると思う。
ソフトウェア開発以外で、そういうリズムが感じられるRedmineの利用事例も集めてみたいと思う。

| | コメント (0)

«組織文化はトップが作るのか、ボトムアップで作られるのか