こんな状況で設計書なんか作ってる場合じゃない！！

ってこと、エンジニアなら誰でも経験ありません？
言葉にできないくらい炎上している状況ってコトです。

ただ、そんな状態でも、PJのために　自分のためにも絶対に設計書は作った方が良いです。
だって、PJってどんなに短くても2~3ヶ月以上はかかるでしょ？
2ヶ月前の内容なんて覚えてます？
昨日の晩御飯も忘れているのに？

じゃあわざわざ設計書にせんでも、Excelにメモ書きでええやん！って？
何のメモか絶対忘れるよ
だって、昨日の晩御飯（以下略

まぁつまり、私は記憶ほど信じられないものはないって思ってるんです。
テスト前の「勉強してない」っていう友達の言葉くらい信じられないんです。
しかも自分だけの記憶ならまだしも、人の記憶なんて尚更です。
共通認識がブレないようにするためにも、絶対に 設計書っぽい何か は必要です。

ただ、極限状態で「この設計は対応して、この設計は省く！」っていう選定までしてたら発狂しちゃいそうなので、この記事では「最低限、この設計はした方が良いよ！」という未来の私のために向けた提案です。（この記事を参考にする日が来ないことを祈っています）

もちろんPJの内容によって状況は変わってくるので、取捨選択はしてくださいね。

賛否両論あると思いますので、ご意見どしどし受け付けます
※ただし、打たれ弱いので優しくコメントしてね

警告
これはとっても炎上している案件に突っ込まれて困っている方向けの提案です。
ちゃんとした手順で案件を回せている方は、IPAの設計とかを参考にしてね。

そもそも設計段階で炎上が見えている案件は、一生炎上している案件なので、スケジュール調整なり人員調整なり、設計に入る前の段階でアクションした方が絶対に良いですヨ。

設計に入る時間がないんじゃ！！っていう場合は...もうほんとご愁傷様です
あなたに500円玉を拾うような幸運が訪れることを祈っています

テーブル定義 ※ER図でも可！

とりあえず、テーブル定義さえあれば...！
システム屋はなんとかできます

最低限必要な項目

・物理テーブル名
・物理名称
・データ型
・NULL許容
・PK

新規で作成する場合は、無理に外部キーやINDEXをつける必要はないです。
つけた方が、パフォーマンスが上がることは間違いなしですが、適切につけないと意味がないからです。
適当につけた外部キーが悪さすることもよくある話です。
炎上中で冷静に判断ができそうにない場合は、一旦おいておくも良いです。
特にINDEXは後からでもつけられますからね。

API定義

本当はSwaggerでオサレに仕上げたものを用意したいところですが...。
そんな余裕は全くないのでExcelなりMarkDownなりでパパッと作っちゃいましょう。

最低限必要な項目

・パス
・メソッド
・レスポンス形式
・用途
・リクエストパラメータ
・レスポンスパラメータ

本当はAPIを利用する画面名とか、パラメータサンプルとかあるととてもハッピーなのですが、作成の時間がないので省いています。
パラメータサンプルを記載しないかわりに、パラメータにはちゃんと型まで書いてくださいね。
APIを使う人が発狂しちゃうので...。

デザイン図

デザイナーに完全なデザイン図を作ってもらうのが一番ですが、難しい場合はワイヤーでも可です。
システムに詳しくないクライアントとの意思疎通はデザインで行うと思ってください。
逆を言うと、クライアントが一番意思を持って指摘ができるのはデザイン周りです。
早めにクライアントがやりたいことを吸い上げる意味でも、デザインをある程度形にして提示する方が良いです。

あれば尚よし！

あったら、さらにハッピーになれる資料たちです。

・インフラ構成図
・画面設計書

おわりに

PJの内容が濃ければ濃いほど、資料は絶対にあった方が良いです。
ただ、資料というのは作って終わりではないです。メンテナンスも必要になるのです。
PJが炎上している中で、開発やテストをしつつ、クライアントの無茶振りに頭を悩ませている中で、果たしてどれだけ資料を更新できるのか...。

更新されずに、誰にも見ることなく朽ちていく設計書たち
キッパリ「この設計書は要るので作りましょう！他は要らないです！」と宣言しちゃいましょう。
使わないなら、作る必要はないのです。　

最後まで読んでくださって、ありがとうございました！
今日もどこかで頑張っているあなたに幸多からん事をお祈りしております！

告知

最後にお知らせとなりますが、イーディーエーでは一緒に働くエンジニアを
募集しております。詳しくは採用情報ページをご確認ください。

みなさまからのご応募をお待ちしております。