今回は、社内アプリケーションを爆速でMVP開発したことについて振り返りを兼ねてブログにまとめていきたいと思います。実際に社内で利用が始まったので、フィードバックを見ながら改善に取り組んでいる毎日です。つらい！プロダクトの開発にはそんな気持ちが常にありますが、楽しい多めで頑張りましょう！
ご挨拶
ども！台風が来ていたので、おとなしく土日をお家で過ごした龍ちゃんです。大雨大変でしたよね。日の光を浴びて起きる生活をしているのですが、雨が降っているときは日光が遮られて目覚めが悪いです。ここ数日はお昼から晴れるので、ベランダで日光浴をしています。
さて本題に入ります。今月は社内アプリケーションを開発しています（社内アプリケーション爆速作成：プロトタイプ編）。空き時間で開発をして、第一リリースからのメンテという流れをワンセットこなしたのでブログにまとめていきます。その開発手法が「MVP開発」という開発手法だったようなので、新しい知見もたまりました。その辺も含めて調べてまとめていきます。
今回のブログでわかることです。
- MVP開発とは？
- 僕が作った社内アプリケーションの情報
やったことよりも「意識したこと」みたいな部分が大きいかなと思います。体験記共有ぐらいに見てもらえればよいかなと思います。
それでは初めて行きましょう。
社内アプリケーションについてあれこれ
では、アプリケーションについてお話していきたいと思います。リリース前の情報は、こちらで書いていました。要件としては以下のアプリケーションになります。
全体のスケジュール感について書いておこうと思います。
プチ自慢ですが、冗談で「作るか～」って初めて三日目にレビューまで持っていったのは楽しすぎました。ちゃんとデザインに起こしていたので、若干時間がかかりましたがレビューの意見をまとめるのに大活躍だったのでよしとしましょう。
レビューでは、同僚とやっている輪読会や勉強会の時間を間借りして行いました。あとは、デプロイまでしていたのでURLを送り付けてのレビューですね。レビューでは、製作段階で考慮できていなかったミスまで拾うことができたので、ぷりぷりしながら修正を加えておきました。
そんな感じで遊んでいると、部署のトップの人まで話が通ってました。そんなこんなで9/4（月）にリリースという結果になりました。バカ焦りながらデバックしてました。ちゃんと大量のバグを仕込んだ状態でリリースしたので、修正案を募集すると大量の修正案が届いてへこんでましたｗ。
ちなみに作ったもののアーキテクチャを載せておきますね。フロントだけで完結するように「Firebase」をフルに活用しています。バックエンドを実装せずにプロトタイプだけを作りたい場合は、お手軽に作成できるのが良い点です。
アプリは社内アプリケーションということもあって、社外の人からアクセスできないようにしているので載せることができないのが残念なところです。
どうやらMVP開発らしい？
さて、自慢はこの辺にしておきます。今回は、勢いで作成してレビューしてもらって改善を重ねるという行為を重ねていきました。どうやらこの開発手法に関して「MVP開発」という手法だったらしいので合わせてまとめていきたいと思います。
僕も初めて知った単語だったので、検索して一番トップに上がってきたものを読んでみました。ざっくりと一枚にまとめてみました。
要約すると「最小構成でリリースして、フィードバックを精査して、改善を重ねていく」という開発手法になります。今回のプロダクトで言えば、社内アプリケーションは開発している僕以外の社員がお客さんとなります。なので、デプロイさえしておいて使ってもらえば即フィードバックがもらえる状態でした。あれよあれよとα版リリースも言っちゃたので、熟練エンジニアの皆さんからも多くのフィードバックをもらえました。
やはりフィードバックをもらうと、自分の認識していない問題点で殴られるので楽しいです。一人で開発を進めていて、妥協した点や悩んでいた部分が突かれたり突かれなかったりするので、使用者と開発者の間には歪んだ時空間があると思います。その空間を歪みなく正常な世界にしていくのか？という点がエンジニアの腕の見せ所だと思います。それを解決する良い手法がフィードバックだと思います。
積極的にフィードバックはもらいましょう！
上でも書いたのですが、フィードバックは改善を進めていく上で最良の手段だと思います。ちゃんと衝撃だけは伝わってきますが….
今回のプロダクトでは、デザインから設計まですべて一人で行いました。とりあえず作ろう！という精神があったので、デザイン的にもそんなに悩むことはありませんでしたが、今考えると足を取られていた可能性は大いにあります。実際に作っているときにこんな感情に囚われていました。
もちろん、ちゃんとお客さんがいるプロダクトの場合は一定のクオリティが必要となります。ただ、自分で煮詰まった時には思い切って同僚や先輩の意見を当てにするのもアリだなと思います。
フィードバックでは、指摘の前に褒めてくれる方がたくさんいたので晴れやかな気持ちになりました。これぞ心理的安全性というやつですね。
そこからメンタル的には、結果的に良いものができたらよいじゃないか！という気分になり、仕事にも転用できる知識もたまりました。この経験からお勧めしたいこととしては、「さくっと作ってさっさと共有しよう」と「褒めてくれる人とちゃんと意見してくれる人それぞれに見せよう」です。
終わりに
ども！開発して改善して、ブログにまとめるという良い流れができていてうれしい龍ちゃんです。
今回のプロダクトの学びは、「悩んでもしょうがない瞬間はあるから、とりあえずぶっぱしちゃおうぜ！」になると思います。どうしても悩んで、抱え込んでしまうタイミングってありますよね。思い切って相談したら、その中に改善案があるかもしれません。思い切りは重要だなと学べました。思い切りが良すぎて失敗することは多々あるんですけど、棚に上げておきます。でも上司の言葉で、「失敗はするものだから、次失敗しないように対策することが大切」というお言葉をもらいました。ほんとに気をつけなきゃいけないですね。
最近はブログ執筆のほうにも良い流れができてきており、とてもうれしいです。ブログ投稿のほうも順調に59本目に入りました。ちょっと緩めなブログ「冒険の書」で40本投稿しているので、通算99本目のブログになります。よく書いたなぁ～と我ながら思います。
最近は社内で勉強会のほうも進めていたり、一人で勉強することも減ってきているので、全体でもっと推し進めることができたらよいなと思っています。次のプロジェクトも注意されることが少なくできたら、なおよいって感じです。絶対希望的観測で終わるのですが、それもまた勉強です。
ブログを書き出して、一年で100本書いたらきっとそこそこでしょう。ネットで調べたら、もっとすごい人が出てきそうなので、怖くて調べることができません。くそブログを減らして良ブログを増やせるように頑張っていきます( *´艸｀)
ではまた～
ほかのブログも読んでね～
