「失敗しない」プロダクト・サービス開発のために

IT分野で、これからプロダクト・サービスの開発を行い、非エンジニアで起業しようと思っている方などにも、知ってもらいたい内容になっている。

開発が失敗しないためにはどうした良いか？など質問されることがある。

「失敗しない」言い換えると 利用者にとって価値あるもので、プロダクト・サービスが予定通り動作する には、どうしたら良いか？という意味で聞くようにしている。

「失敗しない」ための質問の答えとして、将来的には考え方が変わったりするかもしれないが、現時点での自分自身の考え方を整理したくなったので、書くことにした。

違う視点や考え方などあれば、コメントらもらえると嬉しい。

はじめに

まず、前提として、何かプロダクト・サービスをリリースすることが、最初の具体的な目標になる。リリースさなければ、何も始まらない。リリースをするまでの全ての工程が、 リリースに向けての開発のプロセス になると考えることができる。そして、リリース後は、継続した実装開発リリースとオペレーション（運用）を行う必要がある。

そのリリースまでの開発のプロセスは、概念モデルと実装モデルの二つに整理して捉えることが可能である。例えば、何か仕事をする際に、目的と手段、方針と計画・実践と言ったりすることがあると思う。それに近い考え方になる。

つまり、抽象的な概念を考え定義する分野と、具体的に設計や実装モデルを定義する分野とに分けられるということになる。前者が、 概念モデル開発 で、 後者を 実装モデル開発 とする。

もう少し具体的に説明すると、例えば、方針を確認し、要件を定義し、設計し、実装モデルなどを考え、マイルストーンを組み、タスクを洗い出し、なるべく粒度が高くわかりやすい概要・目的、説明、工数（期限）がしっかりと明記されたチケットを発行し、実装し、デバッグ・テストをし、確認をし、リリースし、振り返りなど、きっちり管理して行うことがあるとするならば、それは一開発プロセスになるということになる。

「なぜ、きっちり管理する一プロセスがあるのか？」ということが重要になる。当然、クオリティーもプロダクト・サービスの価値の構成要素の一であり、価値そのものであるとも言える。価値 >= クオリティ という関係なると考える。クオリティの管理・向上が、「利用者にとって価値のあるもの」に繋がることになる。

このプロセスを他の言葉に置き換えると、 クオリティ向上のための技術開発管理 の分野になる。今回で言うところの、 実装モデル開発 の範囲になる。

この様に、 リリースまでの開発のプロセスを分解 し、ぞれぞれのプロセスを理解し、今、我々はどこに向かっているのか？どんな課題を抱えているか？ということをチームで理解し共有できれば、 失敗しない プロダクト・サービス開発ができると考えている。

理想として、 リリースまでの全ての工程が開発 であり、 非エンジニア含め経営者など全てのメンバーが開発チームの一員 であるということが、チームで理解共有されるこを目指し、素晴らしいプロダクト・サービスがリリースするための指針になると良いと思っている。

次に、概念モデル開発メインに整理していきたいと思う。

概念モデル開発

概要と目的

まず 開発の方針を決める ことを目指す。実際の技術開発は、その方針の上でなされることで、よりクオリティの高い開発管理を行うことができる。その為に抑えておくべきことを理解する必要がある。

組織と体制

初めに、組織と体制をチームで理解しておく。

ビジョン

社会にどんな貢献ができるか？
ビジョンを共感できるメンバーとチームを組む必要ある。

課題

• なぜ、このビジョンなのか？
• ビジョンの背景（ストーリー）は何か？

チームの運営

チームの体制と方針などをガイドラインに定め、コミュニケーションロスや決定プロセスをよりスムーズに運営できることを目指す。

課題

• チームの価値は何か？
• コアメンバー（リーダー）は誰か？
• 役割は明確か？
• 物事の決定プロセスは決まっているか？
• 情報共有手段やツールは決まっているか？
• プロジェクトの管理と実装開発の管理ツールは決まっているか？

価値分析

ここでは、最終的にどんなプロダクト・サービスを提供していこうとしているか、より具体的なイメージをチームで共有することを目指す。

ステークホルダの価値分析

ステークホルダの分類・分析し、それぞれのステークホルダの価値を想像・想定したり実際の要求を理解することで、実際に誰のためにどんな価値を提供しようとしているかチームで言葉で理解すること目指す。

課題

• ステークホルダは？
• ステークホルダへの価値は？

プロダクト・サービスの価値分析

どのステークホルダにどんな価値を提供しようとしているか、イメージを共有した後、実際に何ができるか、やるべきか、など、考えを分析整理しチームで言葉で理解すること目指す。

課題

• どんな課題が解決できるか？
• どんな満足が提供できるか？
• 何が提供できるか？

プロダクト・サービスのコンセプト

最初に満たすべき価値を明らかにし、その上で、どんなコンセプト・テイストでサービスを提案するかのイメージをチームで言葉で理解すること目指し、最終的にプロダクト・サービスのコピー文章を作成する。

課題
* 最初に（今）満たすべき価値は何か？
* プロダクト・サービスコンセプトは？
* デザインコンセプトは？
* プロダクト・サービスのコピー文章は？

事業化可能性の検証

価値分析の結果、提供しようと考えているプロダクト・サービスが実際に受け入れられる潜在的なマーケットとそのニーズを把握、事業の可能性を検証し、成長性をチームで言葉で理解しておくことを目指す。

マーケットニーズ・規模・成長性

実際に、プロダクト・サービスが世の中に受け入れられ、事業化できるかを分析し、

• 想定する利用者の属性は？
• マーケットの規模は？
• ユニークネス（独自性）はあるか？
• 競合はあるか？
• どうやってターゲットにリーチするか？
• 提供する価値、解決する課題に、対価を求めることができるか？

ビジネスモデル計画とアセット

想定するマーケットに対して、どんなビジネスモデルが成立するか分析し、そのために必要なアセットデータは何かをチームで言葉で理解することを目指す。

課題

• 想定できるビジネスモデルは何か？
• ビジネスモデルを満たすために必要なアセットは何か？
• アセットをどのように増やすか？
• アセットの価値はどれくらいあるか？

例.
広告収益モデル

• コンテンツがアセット
  • 何がコンテンツになるか？
  • キラーコンテンツは何か？
  • コンテンツのソースはどうするか？
  • コンテンツのコンシューマーは？
  • どこで（PC/モバイル/アプリ)どんコンテンツが消費（閲覧）されるか？
• KPI
  • UUとPV
• 重要施策
  • SEO
  • バイラルマーケティング
• 可能なプロダクト・サービスモデル
  • メディアサービス提供（コンテンツ配信）

ストック型ユーザ課金モデル

• 会員情報がアセット
  • 会員になる動機は？
  • 提供できるサービス・機能は？
  • 有料会員になる動機は？
  • 課金をしたくなるサービス・機能は？
  • リテンションする動機は？
  • フリーミリアムモデル適応可能か？
• KPI
  • MAU
  • 会員数
  • リテンション
  • コンバージョン率
• 重要施策
  • 広告流入
  • バイラルマーケティング
• 重要施策
  • SEO
  • バイラルマーケティング
• 可能なプロダクト・サービスモデル
  • 機能・ツール提供モデル

B向けソリューションビジネス

• ソリューション提供システムがアセット
  • 利用の動機は何か？
  • どんなシステム・サービスで解決するか？
• KPI
  • 売り上げ利益
  • 顧客・案件数
• 重要施策
  • プロダクト・サービスモデル（ビジネス）設計開発
  • 代理店営業
  • 直販営業
• 可能なプロダクト・サービスモデル
  • システムソシューションモデル
  • マーケティング支援

方針を決める

実際に、事業化可能性の検証を行うことで、事業のことをチームで理解をより深めることができる。この概念モデル開発のプロセスが、最後まで後戻りすることなく終えることができたら、方針を決め、実装モデル開発へ進む。

課題

• 概念モデル開発のプロセスを振り返り、誰のために、何を軸に、どんな開発を行うかチームで言葉で理解する。

実装モデル開発

大きな方針が決まり、価値を理解した上で、実装モデル開発を実践する。実装モデル開発ベースの作業が仕事の中心になる。

概要と目的

ここでは、概念モデル開発で決まった 方針 を基軸に、 クオリティ向上のための技術開発管理 を行うためのプロセスについての準備と計画と実践についてまとめる。

技術チームカルチャー

前提として、チームにカルチャーを根付かせることで、習慣的に大切なことを自然に実施できることを目指す。ドキュメント化したものを守ることも当然重要だが、カルチャーでカバーすることができれば、より生産性が上がると考える。

開発ガイドライン

まず、カルチャーを醸成させるために、チームのメンバーが等しく理解できる合理的な内容のガイドラインを設ける。ガイドラインは常に更新することができ、常に閲覧できるようにすると良いと考える。

例.

ガイドラインの定義

• 常に更新可能
• 常に閲覧できるようにする

開発チームの価値を大切にする

• 労働時間を最大限に抑えアウトプットを最適化する
• 新しくてイノベーティブなものを開発する
• 高水準なパフォーマンスと品質を維持する
• オーナーシップをもって何事もチームで解決する
• パブリックで情報共有と発信を継続的に行う

プログラム原則を大切にする
プログラムをコーディングする時のルールになる

• DRY
  • Don’t repeat yourself 同じ事を繰り返すな
• KISS
  • Keep it simple, stupid シンプルにしておく
• SOLID 参照
  • SRP Single Responsibility Principle（単一責務の原則）クラスを変更する理由は１つでなければならない」
  • OCP　Open/closed principle（開放閉鎖の原則）「クラスは拡張に対して開き、修正に対して閉じていなければならない」
  • LSP　Liskov substitution principle（リスコフの置換原則）「派生型はその基本型と置換可能でなければならない」
  • ISP　Interface segregation principle（インターフェース分離の原則）「クライアントが利用しないメソッドへの依存を強制してはならない」
  • DIP　Dependency inversion principle（依存性逆転の原則）「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。」

開発スタイルを大切にする
必要に応じて手段としてスタイルを検討利用するという考え方を大切する。
色々なスタイルがあり書ききれないので、ここでは割愛する。

評価を明確にする
評価は、等しく合理的に評価できる内容にする。

• 自己管理
  • 残業時間の評価（相対的に少ない方が良い）
• 精度
  • 要件見落としやバグが少ない（さし戻しチケットの数で評価）
• 熟練度
  • アウトプットの見積もり精度が高い（期限延長のチケット数の数で評価）
• 自己点検
  • パブリックに対する情報共有と発信・発表の量と質の評価（トークの数で評価）
• 向上心
  • 勉強会参加と報告などの活動に対する評価（参加数の数で評価）
• チーム力
  • チームへの貢献度（チケットのフォロー数やできない人へOJTの企画数など総合的に評価）

実装準備

実装準備段階に入る場合、概念的な話から、実際の機能や実装内容をイメージしていく作業を行う。そこから、目的や課題や優先順位を明らかにし、より具体的な実装計画を作成するための準備作業を行う。簡単に言うと、いつまでに何をやるか？を決める作業を行う。

以下、チケットに含むべき、内容例。

目的・概要

• 誰のための何の開発か？
• 何を解決するか？

準備

• 関連する過去の要望、事例、タスクが無いかあらかじめ調べ、関連チケットを紐付ける

要求・価値分析

• 具体的な要求（要望）をリスト化（具体的なものがなければ、想定要求をリスト化）
• 要求から機能を割り出しリスト化
  • SVOで文書を作成する（主語、動詞、目的を明確にする）

例. ウエブに来たユーザーが投稿した内容をブックマークしたい

機能実装課題

• コンプライアンス・倫理的な問題はないか？
• プロダクト・サービスコンセプト的な制限・課題は？
• 特定のユーザーへのデメリットは？
• その程度と影響範囲は？
• コスト・予算的な制限・課題は？
• システム・技術的な制限・課題は？
• 開発・運用体制の制限・課題は？

優先順位決定

• 機能実装課題を考慮しつつ、要求・価値分析の機能実装リストから、最初に同時にリリースすべきもの決める

実装方針・目的

• 何を実装して、誰のどんなニーズを満たすか？をチームで言葉で理解できるようにする。
  • 常識的にあるべきものを実装するという理由もあり

完了確認要件

• 確認時のさし戻しを減らす目的で、何を確認して完了とするかをなるべく明確にする
  • チケットなどに明記しても良い

実装プロセス

• 計画・マイルストーン（設計からからリリース/振り返りまでの計画を立てる）
• 設計（実装モデルなどを考る）
• 設計レビュー
• 仕様書作成
• タスク洗い出し（工数見積もり）
• 概要・目的、説明、工数（期限）を明記された粒度の高いチケットを発行
• 実装/デバッグ/テスト
• 実装/コードレビュー
• リリース/振り返り

その他の課題

ネイティブアプリは必要か？

必要か必要でないかは、価値分析した結果、ネイティブアプリでないと提供できない価値であれば、必要となる。アプリの開発は、基本的にチーム（複数人数）で開発した方が知見も増えクオリティが向上する場合がある。開発者が一人の場合は、できる限り機能を絞って実装した方が良い。

外注をする時の決め手は？

切り分けの基準として、基幹部分に関連する実装はチーム内で開発を行うべきだと考える。チーム内で開発ができない場合、そもそも、リリースができないと考えた方が良い。

まとめ

概念モデル開発のプロセスを経て方針を決めることで、リリースまでのプロセスがスムーズに運ぶことが期待出来る。

実装プロセス管理がうまくいかない場合、そもそも概念部分に課題があったり、方針が良くないということが言える。また、どちらもうまくいかない場合、もっと根っこの部分に問題があると疑った方が良い。

開発のプロセスを採用することで、どこに課題があるのかなるべく広い視野に立って考え、分析し、対応することができると考える。

他にも色々なアプローチがあると思うので、いろいろな方の意見や考えを聞いてみたい。