小規模開発でもちゃんとやろうぜ！ やり直しを未然に防ぐ「30分上流工程」
この記事で紹介していること
「やっぱりこうして」を未然に防ぐ「30分上流工程」
フリーランスエンジニアならば、小さな案件を受けて開発した経験はありますよね。
私も今年の帳簿を確認したら、月に2件のペースで、ごく小規模の開発案件を受注しています。
小規模開発はお客さんも工程を踏んで開発することを求めませんし、工数がないから上流工程なんかやらない、っていうケースは多いと思います。
でも、「やっぱこうして」って言われること、あるんじゃないですか？
そういわれちゃうあなたは「経験が浅いから」ではなく「準備が足りてない」からですよ。
どんなに小規模でも、私が実践している「30分上流工程」をご紹介します。
小規模でも上流工程しようぜ！
エンジニアとして駆け出しの人は、上流工程を経験したことがない、っていう人もいるでしょうけど、大丈夫です。
この方法は、私が上流工程の工数のないごく小規模開発でやっていることです。
これにより「やっぱりこうして」と言われることが少なくなった実感のある方法をご紹介しています。
誰でもできることだと思うので、ぜひ参考にしてほしいです。
最初は少し時間がかかると思いますが、慣れれば30分でできますよ。
私は30分以上かかるならば、調査不足というバロメータにしています。
工程や目安時間は以下の通りです。
工程の名前は私が勝手につけているものもあります。
| 工程 | 目安時間 | 成果物量 | 着眼点 |
|---|---|---|---|
| 経営目的 | 5分 | 200字程度 | 本件を制作するにあたり、絶対に妥協できないこと、リリースにより期待する変化、ターゲット層などを記載 |
| 要件定義 | 10分 | 300字程度 | 経営目的を達成するために、必要となる機能、画面、重視のポイント、リスクの明示、それらがどの経営目的を担っているかの対応をまとめる |
| 設計 | 15分 | 500字程度 | 画面名、機能名、データ名の定義と、それらがどの要件定義や経営目的を担っているかの対応をまとめる |
上記をスプレッドシートにまとめて、お客さんに共有URLを送り、確認してもらうことが最初の仕事というわけですね。
見積もり段階でやってもいいし、受注後の最初のオンラインミーティングでやってもいいですね。
この作業をやるのとやらないのでは、お客さんの納得感が段違いですよ！
経営目的を明らかにする
今回作成を依頼されたお客さんは、どんな背景から開発を依頼してきたのかを明らかにします。
- 利用規約を掲載し、登録時に承認行為をカスタマにさせることで、規約違反の未然防止と、違反時のアカウント停止の適正さを主張する
- 一般利用者をターゲットとしているため、規約熟読を期待できないため、規約を確認しなければならないこと、規約の存在を認識させる必要がある
- 規約変更後にログインしたユーザには、再度規約の承認行為をしなければ、サービスを継続利用できない制約を設ける
上記の例ならば、品質や機能として以下のような想像が立ちます。
| 項目 | 求められる品質 |
|---|---|
| 画面 | 簡素でよく、文字が読めれば問題ない |
| 機能 | 確実に表示、確実に承認し、承認した日時の記録や、バージョン管理は厳密に求められる |
| リスク | bot対策、うっかり操作防止など |
| 免責事項 | 対応ブラウザ、バージョンなど |
| データ管理 | 永続データ管理、履歴管理、バックアップ必要 |
| データ閲覧性 | 閲覧機能などは不要（ログとか、SQLで見れればよい） |
ざっくり要件定義
経営目的が明らかになったら、その目的を達成するために、どの範囲をどんな機能で制作するか、何を作らないか、手を抜くか（コストカットするか）を明らかにします。
- 利用規約は、公式ウェブサイトからのリンクが可能で、かつ会員登録完了前に必ず表示されなければならない（経営目的１）
- 規約がスクロールを要する場合は、すべてをスクロールされなければ、会員登録できないようにする（経営目的２）
- 会員登録の際に利用者が自発的に「規約に同意する」行為がなされたことを担保する機能を要する（経営目的２）
- 利用規約にはバージョン情報を付帯させる。また、全会員はどのバージョンの規約に同意行為を行ったのかを付帯させる（経営目的３）
- 会員ログイン時、会員情報に付帯された同意済み規約バージョンと、最新規約バージョンを比較し、異なる場合、前記３同等の機能を発動する（経営目的３）
ざっくり設計
ここまでくると、どんな機能と画面が必要になるのか、容易に想像できますね。
設計するのはもう野暮な感じもしますが、お客さんと合意するためにも、資料化しておきましょう。
| 項目 | 内容 | 前工程対応 |
|---|---|---|
| 画面/機能 | 利用規約HTML | 要件定義１ |
| 会員登録時利用規約モーダル （前記１をiframe表示・全スクロール完了検知機能） |
要件定義１、２ | |
| reCAPTCHA | 要件定義３ | |
| 同意チェックボックス （デフォルトOFF・バリデータ） |
要件定義３ | |
| 同意規約バージョンチェック （会員ログイン時） |
要件定義４ | |
| データベース・API | 会員規約バージョン （会員規約変更時にINCREMENT） |
要件定義４・５ |
| 同意規約バージョン履歴 会員情報付帯 ログイン時にチェック 同意時にINSERT |
要件定義４・５ |
この合意があると、見積もりの精度はだいぶ高いので、安く請け負いすぎた！なんていうことも少ないですし、お客さんも「あれも、これも追加でお願い、がしにくい」自制効果もあり、総じて仕事が健全に終わる期待ができます。
まとめ
例に記載した内容は、あくまで私がやるならの一例です。
お客さんはこれを求めているかもしれませんが、そうではないかもしれません。
ここまで示せれば、工数や予算により、取ったり付けたりもしやすくなります。
自分なりにやりやすい項目を作って、スプレッドシートでテンプレートを用意し、お客さんから声がかかったときに、ささっと作成できると、顧客獲得しやすいかもしれませんね。
参考になったら嬉しいと思います。
