開発手法の基本
みなさんこんにちは、mikiです。このラジオでは、これまでの経験や最近学んだことをヒントに、毎日をちょっと良くする考え方、働き方についてお届けする、ゆるりでも学びがある、そんな場となることを目指しております。
なんかちょっと滑舌が悪い気がするんですが、すいません。さて本日はですね、この思想むっちゃ好きだなぁ
【開発手法編】というテーマでお話をしたいなと思っております。 えーっとですね、みなさんアプリの開発の手法やり方って色々あるっていうのをご存知でしょうか?
あのすいません、正直ちょっとマニアックな話になってしまうかなーっていう自覚はあります。 ただ、こういうのがITの業界だと、流行ってんのねーとか
へーって、そういう気持ちで聞いていただけたらいいなぁと思っております。 えっとですね、アプリとかITのサービスとかを作る時っていう進め方の
みたいなものですね。こういうのが、なんかあのいろんな方法が一応あるんでしょう。 まあなんか例えば
決められた順序に沿って、もうきちきちきちって一個一個やっていくタイプか、なんかとりあえず
わーって作っちゃって、市場に出しちゃって、フィードバックもらいながら決めようよみたいな、そういうものとか、なんか色々あるんですけど
まず、もともと古来から良しとされてきた、この方法で進めるべき、みたいな方法でですね、
ウォーターホールという開発手法があったりします。 これはあの、さっき最初の方に言った、きちきちって進めていくタイプの手法ですね。
このウォーターホールっていうのは、水が落ちる、ウォーターホールっていう単語で、日本語の訳は滝ですね。
滝の水が落ちるみたいなイメージで、なんかこう一番最初に、まずこの
プロジェクトが終わる頃にはどういうものが作られているか、みたいな、そういうゴールを明確に、最初に練り練り練り練りやって、
で、机上で設計をひたすら作って、検討して、検証版を作って、その検証がうまくいったら本ちゃんのを作って、
一個一個の部品のテストをして、全部つなげた時のテストもして、それが終わったらやっとユーザー側でテストをして、変なところがあったら修正して、
みたいな感じで、滝の水が流れるように一個一個の工程を進んでいくっていうやり方ですね。 これがウォーターホール式。
これが全部できてから納品する、みたいなやり方になります。 これはなんか最後、アウトプットとか納品する時には100%のものを目指す。
で、その最後納品をするまでは、その使い手は誰も触らないと、最後そのアプリとかサービスを使うはずのユーザーは誰もそれまでは触らず、
特に意見も何もせず。で、一回最後に納品したのであれば、滝の水が後戻りすることはできないように、最初に戻ってやり直すみたいなことは難しい、みたいな。
そういう作業の仕方になりますね。
アジャイルとその利点
これの良さというのは、本当に最初に全容を決めてから取り掛かるので、そこに必要な人を極力ソリッドな状況でアサインができるとか、この工程でこのくらいの人が必要だろう、
みたいな。この辺でこういう問題が出るだろう、みたいな。そういうちょっと全容がわかった状態でプロジェクトを進めれるとかがあるので、どのくらいのお金がかかるとか時間がかかるとか、そういうのが大体算出しやすいみたいなメリットもあったりします。
一方でですね、他のやり方としては、比較的新しいやり方なんですけど、アジャイルって呼ばれるやり方があります。
これは本当最近これでこっちの方で進めましょうね、みたいな感じで結構言われている流れもありまして、これは最終的にそのアプリとかサービスを使う人、使い手に触らせてみて、
フィードバックがあったらその場でもう即改善して、密に開発側とサービスを使う側とが双方に密にやり取りをしながらプロダクトを完成形に近づけていくっていう考え方のものになっています。
これはですね、結構これでやりましょうよっていう流れがあるっていうのもありまして、私自身も前職でアプリ開発担当していたときなんかはこの方法でやっていまして、毎度短期間で60%くらいの完成度のものっていうのをどんどん社内に出していったりしてました。
社内で使うアプリっていう前提だったので、そういうのが許されてたかなとは思っているんですけど、多分お客様に出すものだったら、多分もっと完成度高くやらなきゃいけなかったと思うんですけど、でもなんかそれでもその最初は結構緊張してたんですよね。
こんな途中のもの、中途半端なものを出していいんですか。でも社内の空気として、まず動くものを見せてくれた方がありがたいよねとか、どんどんチャレンジしていって、変なとこあったら直していけばいいんじゃないみたいな、そういう風土がありまして、なのでこれでいいんだ、なんならこっちの方がいいんだみたいな、面白いなってなった経験がありますね。
これがアジャイル開発と言われる考え方になります。
あと一個シェアしたい考え方っていうのがあって、MVP、ミニマムバイアボープロダクト、MVPっていうプロダクト開発の手法があって、これはまず使い手に差し出す、その後走りながら考えるみたいなスタイルみたいですね。
アジャイル開発とちょっと考え方は似ていますが、よくこのMVPを考えるときによく例えられるのが、最終的に車を作りたいんだったら、最初から車を作るわけじゃなくて、車を目指すんじゃなくて、まずはスケボーを出す。
で、次に自転車、バイク、車、みたいな感じで進化させていくっていう考え方ですね。これが結構好きでですね、なんかあの、最後にその車を作りたいから、まずタイヤを作って、次にエンジン作って、座席作って、ハンドル作って、みたいな、そういう車を作る工程ってわけじゃなくて、なんかまず自分を楽に遠くに運んでくれるもの、
みたいな、そういう機能を持ったものを作る。で、それがつまりスケボーですよね。車輪がついてて、自分が乗るところがあって、自分を運んでくれるみたいな。で、なのでその機能を持ってるんだったらスケボーでいいじゃん、みたいな。で、そのスケボーを出してみて、
あ、じゃあやっぱちょっともうちょっと車輪でかい方がいいよねーとか、もうちょっと安定的に座れた、座れる場所があった方がいいよねーみたいな、そういう意見を取り入れていって、最終的になんか自転車、バイク、車みたいな形になっていくみたいな考え方ですね。なんかむっちゃ、なんか真食ってるなーって思って、なんかすごいMVP、なんかかっこいいじゃんってなった記憶がありますね。
で、なんかこの出してみて、反応を見て合わせてやってみるっていう考え方とか進め方は、なんかこのアプリとかシステム開発だけではなくて、なんか例えばビジネスだったりとか、なんかそういう発信とか、そういうものにも言えるのかなーって最近は思ってたりしてます。
この完璧をまず目指すよりも、とにかくなんか動くものを出してみて、反応を見て柔軟に変化していくみたいな。もしかしたら、なんかこれは必要だって思ってるものが、その相手からしてみたら実はそんなに必要じゃなかったり重要じゃなかったり、逆にこれは絶対必要だみたいなものが意見の中でわかってくる可能性もあるみたいなこともあると思うんで、
なんかこれからも私自身も、なんかそんなスタイルでまずはちょっと進んでみて、途中でこけたりしつつも、なんかちょっとやっていけたらいいなーとか、最近はぼんやり思ってたりします。
はい、そんな感じで今回はですね、この思想むっちゃ好き開発手法編ということで、アジャイル開発だったり、ウォーターフォール開発だったり、あとはMVPについてのシェアをさせていただきました。
こんな動き方してもいいんだ、こんな動き方があるんだ、みたいな、なんかそういう何かしらのヒントとか気づきがあったら嬉しいなと思っております。
感想やあなたのお話もぜひコメントで教えてください。
それではまた次回お会いしましょう。関菜一日よ。ミキでした。バイバイ。
