ロードマップ
本項は書きたての記事です。正確な情報は公式サイト、公式ドキュメント、記載の参照サイトでご確認ください。
目次
ロードマップ
期間
まず標準サポート期間は、OS(Windows、Linux)が5年間。OSSは2~2.5年間が多い。
これを考慮するとロードマップの対象期間は
がベターと考える。
目的
自社製品を開発/製造、販売するにおいて、ビジネスにおける方向性を持たせるため。
メジャーバージョンを基軸に、マイナーバージョンを計画し、四半期ごとのマイルストーンを置きビジネスにリズム感を持た、営業、技術共に同じゴール意識を共有するため。
営業、技術ともに新入社員や途中参画者の人材育成を計画的にすすめるため。
経営計画を明確にし経営陣のモチベーション向上のため。
*
受注開発期間は、文字通り現行メジャー版の自社製品や受注製品の対応期間。
研究期間は、次期バージョンを見越した自社製品開発に充てる期間。
|
受注開発期間 |
研究期間 |
1期 |
2期 |
3期 |
R&D1期 |
R&D2期 |
R&D3期 |
R&D4期 |
R&D5期 |
|
(現在) |
|
|
|
|
|
|
自社製品 |
Currentバージョン品を用いた商品開発を行う期間 |
次期バージョンの設計、製造を行う期間 |
次々期バージョンの企画、要件定義、POC |
マーケティングを含む研究開発 |
技術背景 |
直近の最新版LTSを用いていること |
次期LTS、最新版を用いていること |
インフラ、サーバ等も含め次々期を見据えた開発 |
|
受注開発期間・メジャーバージョン販売期間
次期版のリリース日
自社の決算月や株主総会開催日の翌月にリリース日(発売日)を設定する。
オウンドメディア(Youtuber,Vtuberなど)の場合は、自身のチャンネルでメンバーシップのメンバーを株主として考えて色々工夫してもよい。
メジャーバージョンの発売期間3年間は崩さないこと
メジャーバージョンは基軸となるアーキテクチャ、ライブラリ等を変えずに生産スピードを落とさないための対策。
受注開発期間中(現メジャーバージョン発売中)は、ビジネスロジックだけの開発、製造に注力できるようにして負荷を減らすことに注力する。
それでも年2~4回はマイナーバージョンを更新
ロードマップ設定は、マイナーバージョンを計画するため。
3年間の機能を要求高⇒中⇒中/高に設定して要件や設計を行う。3年目はユーザーからのフィードバックを中心に機能追加、改善を行う。
特にWEBアプリ、スマホアプリ系かつエンターテイメント系だと飽きをこさせないように極力マイナーバージョンアップの頻度は6~12週間に1度は更新を心掛ける。
製品のロングテールは考えない
製品寿命は5~6年と考えたほうが良い。
後発製品には先発製品のデータ互換性を担保し、ユーザデータ移行機能があればよい。
どうして5~6年スパンで新製品を出すのかというと、それは売上げのため。
ビジネスモデルが売切り、サブスク(月極)によって異なるが、マイナーバージョンアップだけでは売上げがどうしても小さくなる。それこそエンタメ系で超絶的にヒットしていれば別だろうがそういうことは殆どないので考えるべきではない。
新製品は新しく時代に合ったデザイン、UXを提供し、基本データ移行機能以外は継承させないでおく。ゲームならストーリーやキャラは全く別物に。ビジネス系アプリなら拡張性を追加する。
ビジネス系アプリ(WEBアプリ含む)
エンタメ系と異なりある軌道に乗れば5~6年で新製品を出すことをせず10年20年リセールしても良い気はする。
しかし常に他社から新製品があふれてくる中でインパクトが落ちる。
ビジネス系アプリだと販路確保も大事なのでそこは営業部門と調整しつつといったところになるだろう。
最終更新:2023年01月02日 04:11