要件定義、設計ときて第3章は実装編です！
要件定義という山を超え、設計という谷を超えてようやく手を動かす時！！
設計通り、あとはゴリゴリコードを書いていくだけだ！！と思っているあなた！！
そうなんです！！笑
実装を分解しても実装は実装なんです！！笑
外部設計、内部設計を終えて新しく何かを設計したり、考えたりということはあまりありません。。
（というか調べてもあまり出てきませんでした。）
というわけで今回はここでお終い (^O^)/
というわけにもいかないので、今回は開発における考え方の一つ「MVP」についてまとめてみました。
（実装の分解ではないので、タイトルの横に？マークをつけました笑）
「MVP？普段から意識して開発してるよ」という方。
このページをそっとじ、もしくは経験団だけ読んでお帰りください。
「MVP？そりゃ頑張って開発したらなれるかもしれないけど...」と思った方。
そのまま読み進めてください。
目次
第1章 要件定義
第2章 設計
第3章 開発（実装） ←今回はココ！
第4章 テスト・検証
第5章 リリース
第6章 運用
スピードスターになりたいですか？
あなたはスピードスターになりたいですか？
誰しもこう思ったことは1回や2回はあるはずです。
「ちょっ早で仕事終わらせる方法ないかなぁ。」
「タスク山盛りで終わらん。。誰か、、ヘルプミー」
「忙しすぎて、あばばばばばばばば」
そんなあなたにとって「MVP」の考え方はきっと何かをつかむヒントになると思います。
開発においてだけでなく、仕事においても応用できる考え方の一つです。
まずは「リーンスタートアップ」を知るのじゃ、と偉い人が言ってた
「MVP」を説明するにあたって、まずは「リーンスタートアップ」という考え方を知っておきましょう。
リーンスタートアップのリーンとは、製造業のリーン生産方式から来ています。
リーン生産方式...？
学生の味方、Wikipediaで調べてみましょう。
（大学生はWikipediaコピペしたらダメだぞ☆）
1980年代にMITで行われた日本の自動車産業の研究において特に注目されたのは、ジャストインタイム生産システムに代表されるムダを徹底的に排除したトヨタ生産方式である。
トヨタ生産方式では7つのムダを定義し、それらを減らす・無くすことに注力している。
当方式ではこのムダを「“会社と言う名の巨人”についた贅肉」と見立て、「贅肉のとれたスリムな状態」で生産活動を行うことを目指す生産方式として構築された。
そして「贅肉のとれた」の意である英単語のlean（リーン）を用いてリーン生産方式と命名された。つまりムダの無い生産方式という事である。
つまり、リーンスタートアップとは
無価値な製品やサービスを開発してしまうことに伴う、時間、労力、資源、情熱のムダをなくすための方法論
ということです。
で、MVPってなんなのさ？
MVPはリーンスタートアップという考え方の中でのキーワードです。
リーンスタートアップのポイントは、新たな事業を小さく始めて成功しそうかどうかを早期に見極め、芽がないと判断したら、すぐに製品やサービスを改良したり、事業の内容を一新したりして、軌道修正を繰り返すことにあります。
つまり
アイデア出し→構築→製品化→計測（検証）→データ化→学習→アイデア出し→...
を繰り返します。
簡単にいうと、作って反応見てそれを元に改善する、と繰り返すということです。
ようはそのPDCAサイクルを早く回しましょう、ということなんです。
ビジネスサイクルが短縮化してきている昨今の現状を考えると、今まで通りの腰を据えた開発ではとても追いつきません。
もたもたしているうちに他社に先を越されてしまう、ということも十分ありえます。
つまり如何に上記のPDCAを回せるかが鍵になってくるのです。
そんな時にキーとなる考え方が「MVP」という考え方なのです。
MVPとは!?
MVPは
Minimum Viable Product
の略で必要最低限の能力を備えたプロダクトという意味です。
端的にいうと、ムダをそぎ落とした、プロダクトの最小構成単位となるものがMVPにあたります。
プロダクトのコアとなる機能のことです。
具体例を出してみます。
例えば、「自動車」で考えてみましょう。
あなたは自動車を全く知らない星にやってきました。
その星の人々の移動手段は徒歩しかありません。
そんな星にやってきたあなたは人々にもっと早い速度での移動方法を提供しようと考えました。
そこであなたは自動車を開発して売れば大金持ちになれるかも！と思いつきました。
早速取り掛かろうとしますがある懸念が引っかかります。
「この星の人々が徒歩よりも早い移動方法を求めている」というのはあくまで仮説にすぎません。
お金と時間をかけて開発した自動車がこの星の人々にウケるとは保証はありません。
開発した結果、お金と時間だけかかって全く売れない可能性があります。
さぁ、どうしますか！？
そんな時にMVPの考え方をあてはめてみるのです。
提供したい価値は「徒歩よりも早い速度での移動方法」です。
そのための手段として考えたのが「車輪を使って自動で動き、屋根がついていて座れて自在に向きを変えられる四輪の乗り物」です。
しかし、そもそもの提供したい価値がずれている可能性があるかもしれないんですよね？
先に言いましょう。
答えは「スケボーを作る」です。
「徒歩よりも早い速度で移動出来る手段」を提供するための最小構成単位を考えるのです。
「車輪を使って自動で動き、屋根がついていて座れて自在に向きを変えられる四輪の乗り物」を要素分解してみましょう。
・車輪を使う
・自動で動く
・屋根がついている
・自在に向きを変えられる
・四輪である
このように分解した時に「徒歩よりも早い速度で移動出来る手段」として必要なものが何か少しわかりやすいですよね？
徒歩よりも早い手段で移動するためには
・車輪を使って転がって進む必要がある
・徒歩と同じく簡単に乗りこなせる必要がある
という点を考えると残る要素は
・車輪を使う
・四輪である
の2点に絞られます。
つまり、この星で「徒歩よりも早い移動手段が必要とされているかどうか」を判断するためにはスケボーを作って乗ってもらうのがもっともムダのない開発と言えます。
そしてスケボーに乗ってもらった結果、
「曲がりにくい」
という意見が出たらキックボードのようにハンドルをつければ良いし、
「座りたい」
という意見が出たら三輪車のようなものを開発すれば良いのです。
もしかしたら、
「我々はゆっくりと時の流れを味わいたいのでセコセコと移動したくないのだ」
という主張かもしれません。
その場合、この星では自動車は売れないと判断出来ます。
もしこの主張が自動車を開発した後に言われたらゾッとしますよね。。
重要なことは自分が提供したい価値とユーザーが求める価値がマッチしているかは100％のものを作らなくても判断出来る、ということです。
提供したい価値だけに絞った20%、30%のものを評価してもらい、早いPDCAサイクルを回していく。
そうやって本当にユーザーにとって価値のあるサービスを提供することが大切です。
なるほど！
つまりなるべく機能を絞って開発したら良いのか！
と思った方はまだMVPを理解出来ていません！！
今回、MVPを調べる中でこちらのブログで書かれていることが参考になりましたので紹介します。
MVPとは？をもう一度考えてみた
こちらのブログを書いた方は、複合機がMVPかどうかを考え、結果をまとめてくださっています。
「複合機って「複合」だしMinimumじゃないじゃん。」
と思ってしまった方にはぜひご一読をオススメします。
そんなのどこで役に立つの？
では実際MVPってどんなところで活用されているのか、気になりますよね！
2つほど有名な事例を紹介します。
Twitterの例
TwitterのプロトタイプはOdeo社（Twitter創業者の一人が当時所属していたソフトウェア会社）内でメッセージのやりとりをしたり、グループチャットを行うために開発されました。
そして、そこでのテストのフィードバックを踏まえた改善を施した上で2006年にリリースしました。
先に社内という限られた範囲でプロトタイプを作り、PDCAを回して最適な形にしてからリリースしたということです。
Dropboxの例
Dropboxはプロトタイプを作るわけではなく、サービスの紹介動画を作成して公開しました。
Dropboxが作成した３分あまりのビデオは大きな反響を呼び、ベータテストの希望者は、ビデオが公表されてからの一晩だけで5,000人から75,000人に増えたそうです。
ユーザーが製品・サービスに興味を示すかを検証するためのMVPをスモークテストと言います。
必ずしもプロトタイプを作ることだけが手段ではないということです。
どちらも今や知らない人はいないサービスです。
こういったサービスもMVPの考え方を取り入れた結果、今日のサービスにまで発展した...のかもしれません！
身近なところでもMVPの考え方は使えます。
例えば資料作成。
資料作成しようとした時に最初から完璧な資料を作ろうと、表紙から順番に一生懸命作成してませんか？
結局、何が言いたいか分からなくなってしまったり、変にこだわりすぎて時間ばかりかかっていつまでたっても終わらなかったり。
資料作成は先に全体像を作り上げてしまいましょう。
フォントや配置など一切気にせず、そのスライドで言いたいことだけを一枚ずつ書いていくのです。
それさえ出来上がってしまえば、あとは綺麗に整えたり、肉付けするだけ！
「今出来てる分でいいから資料見せて」
なんて言われた時にもきちんと全体像が見えるので見ている方もより良いフィードバックが出来ます。
まとめ
ここまでMVPという考え方について見てきました。
あなたはもうMVPが何か言えますよね！？
最初にMVPは必要最低限の能力を備えたプロダクトと言いましたが、正しくは
MVP：(提供したい価値を実現する)必要最低限の能力を備えたプロダクト
ですね！！
新卒未経験エンジニアの「MVP」経験談
上司「...というのがMVPという考え方ね」
僕「なるほど！！完璧に理解出来ました！！」
僕「よし！開発する社内ツールのMVPを考えるぞ！！」
僕「あれと、これと。これも多分MVPだな。これも入れた方がいいかな。あ、これも忘れてた！」
僕「出来ました！MVP！」
上司「これ本当にMVP？いらないものずいぶんあるけど...」
僕「...」
MVPは意外と難しいです。。笑