【上流_2日目】システム設計1冊目
背景
今まで開発側にいることが多く、設計をバリバリやっていた訳ではないですが、初の要件定義をやることになったためと、今後社員ができた際にきちんと教育指導が行えるように成長することが求められています。
進捗状況
要件定義 1冊
設計 0冊
学習アウトプット
要件定義ですること
・現在の業務がどのように行われているか確認や、現状のシステムがどのように動いているか確認
・今後の業務についてどのように行うかを定義する
・上記の新しい業務を行うために必要なシステムを定義する
ポイント
・業務フローなどを書き、流れを理解しやすいようにするのがいいとのこと。
注意点
・要件定義に現れない隠れた要件を探すことが難易度が高い
その他
・機能だけではなく、どれくらいの人が利用するのか、利用時間帯、障害が起きた際の稼働要件、セキュリティーなどに対して検討する
リリース
注意点
・100点満点のシステムをいきなり作るのは厳しいとのこと。
→最初から全て作りきらないというのが大切かもしれません。よく自社開発などを行う際に、MVPという概念があります。MVPは最初から全てを作るのではなく、顧客に価値のある最小限で作成するといった内容になります。
なのでまずはリリースしてその反応を見るというのがいいかもしれませんね。
運用保守
概念
・DevOps・・・「開発担当と運用担当が緊密に連携して、柔軟かつスピーディーにシステム開発を行う手法」
→一つのシステムが馬鹿でかい場合、開発側と運用側にチームが分かれて動くというのがよくあるそうです。その場合に、最終的に顧客に良いものを提供したいというゴールが一緒にも関わらず意見の対立が起きてしまうということがあるので、協力しましょうと言った感じです。今の現場はこれかなという節もあります。
リソース
一つのシステムを作り上げる際にかかる工数は以下らしいです。
要件定義：10%
設計：20%
実装：40%
テスト：30%
※ざっくりとした目安
設計における契約体系
| 工程 | よくある契約形態 |
|---|---|
| プロジェクト計画 | 準委任契約 |
| 要件定義 | 準委任契約 |
| 設計 | 請負契約 |
| 開発・テスト | 請負契約 |
| リリース | 準委任契約 |
こういった契約形態が多いとのことです。受注して契約を取っていく会社は知っておく必要があるかもしれませんね。
準委任契約・・・仕事の完成ではなく、一定の事務処理行為を行うことを約する契約
請負契約・・・請負人が仕事を完成することを約し、注文者がこれに対して報酬を支払うことを内容とする契約
なぜ設計書が必要なのか
・設計がないと、何を作れば良いのかわからないため、品質の悪いシステムができてしまう。
・システムの依頼者から製造を行う開発者まで、何をすれば良いのかの共通認識を持つことができる。
・システムが完成した後に、誰かが運用保守をしなければならず、システムに対して理解を得るためのドキュメントが必要なため
Discussion