技ビス : 技術、ビジネス、スタートアップ

技術、ビジネス、スタートアップに関する情報と話題とアイディアと事例

Re: 自プロジェクトを挫折せず続ける技術

id:shinyorke さんの下記の記事を読んで、僕のテクニックも公開してみようかなと思い。

shinyorke.hatenablog.com

個人的な挫折する理由

僕の場合、一番の理由は業務量の上下が激しいというところに根本原因があります。忙しくなると自分が何してたのかを忘れがちなんですね。これをもう少し分解すると下記になります。

  • 当初の目的や面白いと感じたことを忘れてしまう
  • 作ろうと思ってた機能や、検討の進捗を忘れてしまう。
  • コーディングの状況を忘れてしまう。

忙しいのは頼られているということでいいことではあるのでしょう・・・

対策: 思ったことや考えを書き留めておく

僕はBOOX Nova2 7.8 ePaperを使っており、どういったことを実現したいのか(Vision)やどういった体験を実現したいのかを整理したり、どういった体験になるのかを手書きで書き出します。

書き出した段階で人に見せたり(だいたいは妻)、しばらくたってから見直したりしてブラッシュアップします。

f:id:harajune:20200608205743j:imagef:id:harajune:20200608205739j:image

これがあると閃いたときの感覚やその時のイメージの手触りが残るので、モチベーションや当初の思いをキープしやすくなります。

対策: Prorudct Requirement Documentを書く

手書きしたものをドキュメントに起こします。手書きでは比較的フィーリングを重視してましたが、ドキュメントでは客観的に「何がよかったんだっけ?」を意識して書きます。

これがブレるとモチベーションが失われやすい・・・ように思います。

これ、お仕事するときもちゃんと書いておいた方が良いです。

f:id:harajune:20200608210647p:plain

書く項目は下記がいいように思いますが、この辺はあまり正解がない気はします。

  • Mission
    このプロダクトは何を狙いとして作るのかを書きます。達成すべき世界観とも言えるかもしれないです。
    たくさん書くとブレるので一文でカシッとかくのがコツ
  • Vision
    このプロダクトがあることで実際に実現される価値、状態を定義します。いくつ書いてもいいですが、リソースは限られているので多くて5個くらいがいいのではないでしょうか。
  • Customer Profile / Customer Goals
    想定する顧客の情報を書きます。これ、できるだけナラティブに詳しく詳細に書くのがコツです。具体的に特定個人がイメージできるくらいが良いです。
    そして、その顧客がGoalにいたるのをこのプロダクトが助ける・・・というふうに書くわけです。
  • MVP Story
    いきなり全部の機能を実装すると挫折するので、解決したい最も意味のある最小のユーザストーリーを特定し、それを記述します。
  • Roadmap
    目標期日を決めることは良いことです!ただ、趣味でやってる限りは結構適当な気もします。

 このくらいが最小構成です。プロダクト開発するときにも、このくらいのことは書きます。

Customer ProfileやUser Storyはどういうのを書くべきか・・・・は長くなりそうなので省略しますがHow to Write a Good PRDを読むとわかるかと思います。

対策: User Story and Feature Listを作る

Backlogとかを持ち出してもいいのですが、一覧性が損なわれるので僕はあまり好きじゃないです。個人プロジェクトですし。

重要なのは、User StoryとFeatureの関係、あとはFeatureに関するメモが残しておけるかという点です。

f:id:harajune:20200608212708p:plain

観点としては概ね下記が記載されていると良いかと思います。特にUser Storyは何のためにやってるんだっけ?をたまに思い出すために重要です。

  • 機能/非機能の種別
    非機能要件は忘れがちですよね。ユーザログが取れるとか、CI/CDをどうするかとか、多言語化をどうするかとか。後回しでもいいんですが、観点として書き出しておくと忘れずに済みます。
  • User Story
    クイックにリリースするためには、やはりユーザが体験できる単位=ユーザストーリーで作るのがコツかと思います。この単位を意識するためにもストーリーを書きます。
  • Feature
    このストーリーを実現するために必要な機能へと分解します。感覚ちとしては週末で作りきれる程度に割っておくと良いかと思います。
  • Memo
    検討したコメントや、使えそうなツールへのリンクを残しておきます。これをすると、隙間時間で検討を進めることもできます。

このUser Story / Feature Listがこのプロダクト開発の全てを俯瞰するダッシュボードになります。

対策: コードにまめにコメントをつける

だいたいきりのいいところまで作りはするのですが、何が残件だったか1週間もすると忘れます。Mockで仮に作っておいたところとかすっかり忘れますよね。

なので、マメにコメント書きます。

僕は、コメントでTODOと残しておきます。インタプリタやコンパイラによってはwarning出してくれるので便利ですね。次触るときに"TODO"コメントを探して、コメントを読むとどこまで何をしてたのかを思い出すことができます。

まとめ

 お仕事・・・でやってるほどにはかっちりはやってないですが、やはりドキュメントに落としておくことはモチベーションや進捗を記録する意味で重要です。

さらに、きちんとPRDを書いておけば友達に相談したり人に説明するのも楽です。

2000文字を超える超大作になってしまいましたが、誰かの参考になれば幸い。