はじめに
コジマです。
転職してから初めて書くかな。
早速忙しいけど、割と楽しく働いてます。
前職最後のほうで給料ちょっと上がったから結果的に転職で
給料下がることになっちゃったのがちょっと痛いｗ
私服OKになったりいざとなれば出勤時間ずらしたり
できるし、slackやTrelloみたいな便利ツールを積極的に使う企業なので
結構働きやすいと思います。
今回は自戒を込めた記事になります。
案件に上流から参画させてもらえているので要件定義やら設計やらやらせてもらってます。
やったね。
設計書を作るときにどういうことに意識すればいいか、
どういうことを意識すればよかったな。
なんて反省も踏まえた記事になってます。
フォーマットを合わせる
大体設計書は１ドキュメントに収まらないです。
なのでフォーマットが必要になります。
軽微な修正を繰り返してフォーマットが変わったりします。
適宜情報をキャッチアップして反映していく必要があります。
地味かもしれないですけど、それをお客さんが見るので、
見た目はとても大事です。
他の設計書と記載に齟齬が出ないようにする
先ほどのフォーマットの話にも通じるところがあります。
- 「押下」「クリック」などの文言にブレがないか
- 「サーバ」「サーバー」などの表記に揺れがないか
- DB定義書で定義したテーブル名などと同じ言葉を使っているか
これらがほかのドキュメントとぶれてしまうと見づらいだけでなく、
読み手の誤解を生むものになってしまいます。
どういう言葉を選んでいるか周辺の資料を確認しておくことが大事になります。
実装を考えながら書く
超当たり前なんですけどね。
実際にやっていくと見た目にこだわりすぎて意識が向かなくなり、
肝心の中身が疎かになってしまうことがあります。
自分がその設計書を見たときに実装できるかどうかを
意識しながら書いていくことが大事になっていくと思います。
指摘事項や確認点は秒でメモを取る
「秒で」と言っているところが大事で、なぜかというと忘れるからです。
私はTrelloのチケットに「レビュー指摘」「確認事項」
というチェックリストを作ってすかさず追記していってます。
それでも漏れてないか心配になってしまいます(;^ω^)
常に疑問を持つ！くらいの意識でちょうどいいと思います。
ここでずれるとずっとずれてしまって後々やり直しになったりと大変なことになります。
さいごに
いろいろ初心に戻った気分です。
一個一個成果物きちんと出せるようにこれからも精進していきます…！
まとめ
- フォーマットや用語を統一する
- 実装を考える
- 秒でメモる
この記事を面白いまたは役に立ったと思ってくれた方は是非私のTwitter(@kojimanotech)を
フォローしてくれたらうれしいです！
以上、コジマでした。
