お世話になっている企業様から機能追加の設計の機会をいただいたので、その失敗点をメモする。
私は現在フリーランスのエンジニアでPHP（Laravel）で案件を受けている。
記事の流れは以下。
- 私の設計の流れ。
- 設計後見えてきた反省点。
- 要件定義とは。
Contents
結論
開発プロジェクトは
要件定義 → 設計 → 製造 → テスト
の流れで行われるが、「要件定義」がかなり重要である。
言い換えれば、スタート地点を間違えたらゴールにはたどり着かないことが分かった（そりゃそう）。
1. 私の設計の流れ。
- どんな機能なのか簡易的にヒアリング
- googleスライド、draw.ioを用いて大まかな機能の動き、DB構造を作成
- 上記を用いて提案
- コーディング（not設計but製造）
上記の流れで行った。
細かく見ていく。
- ヒアリングをした事項は「何を作りたいか。どんな機能か」
- googleスライドには機能の説明（図）を記載。主要部分ページ作成のみ。
- スライド類を共有。（グーグルスライドにコメントをいただく。）
上記 1〜3にかけた時間はおよそ1日
2. 設計後見えてきた反省点。
ヒアリング（要件定義）に時間を使う。
要件定義。正直難しい言葉であり、何を言っているのかまだ分からない。
参考にした記事を確認してみる。
要件定義 とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などを明確にしていく作業のことです。https://www.jtp.co.jp/techport/2016-07-27-002/
ふんわりとは「要件定義」の意味が掴めた気がする。
私が主観で噛み砕いて認識した「要件定義」とは
実装したい機能と、その機能を使うユーザー（エンドユーザー）が何を求めているのかをヒアリングすること。
より噛み砕くと、企業様の脳内で作り上がっているアプリを見て、実装できる形に落とし込むことだと思っています。（んー。また分からなくなってきたか。）
提案資料は作り込む。
当たり前といえば当たり前。
機能の提案資料は全ページ作成する。
理由：企業様の脳内のアプリケーションと乖離しているのか判断する為。
実際にコーディングを初めて「これ思ってたのと違うんだけど」と言われたら悲しい。それを防ぐためにも提案資料は機能を事細かく記入する必要がある。
提案はオンラインで行う（もしくは完全に理解できる資料を作成する）。
提案資料を作り込む理由と同じ。
企業様との認識のすり合わせは一番重要。
理由：企業様の脳内のアプリケーションと乖離しているのか判断する為。
本当にそれ実装できる？
提案した機能の動き、DB構造で本当に実装出来る？
コーディング中に「あれ？これむりじゃん」とならないためには
提案資料作成時に頭の中である程度のコードを能で描く必要がある。
（これができれば正直苦労しないのだが。。）
以上。メモ。
asa
コメントを残す