非IT企業の情報システム部がシステム開発を依頼させられた場合⑧～基本設計～

はじめに

情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？

実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。

また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。

そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。

システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。

基本設計とは、要求者つまり、ビジネス側の人に理解できるレベルの設計を行うものである。そのため、基本設計については業務PMのサポートがあれば、ビジネス側の人にもレビュー可能なものと考えます。そのため、積極的にビジネス側の人をレビューに参画させるように巻き込むことが望ましいです。

基本設計にかかわらず、すべての設計書においてトレーサビリティが確保されていることを確認しながら進めなければならない。

〇NG例

NG状態が発生しないように、

ことが重要である。

要件に存在しない設計はあり得ないし、要件が設計に反映されていないこともあり得ない。

成果物の例としては、以下である。プロジェクトにより成果物の内容は異なる。

　１．システム方式設計（基本的には要件定義時

　２．画面設計

　３．帳票設計 (Webシステムだとあまりない

　４．バッチ設計

　５．テーブル・ファイル要件

　６．外部インターフェイス設計

業務要件・非機能要件が要件定義にて含まれていない場合は、基本設計で実施が必要となる。

要件定義時の画面一覧が修正されることはあまりなく、画面レイアウトや入出力項目の一覧、画面アクション定義などの具体化を行う。

※画面を増やす・遷移を増やすなどが発生すると見積もりへの影響が大きい

可能であれば基本設計のタイミングでモックを作ってもらうことが好ましい。紙芝居だけで画面イメージを理解することが要求者には困難であるためである。
※画面が重要なPJTでは、RFPの成果物として”モックの作成”明記すると良い。

画面同様、バッチ一覧が追加されることは稀である。

バッチの処理フロー・処理定義について記載を行う。
　※処理定義は詳細な内容になることもあり、詳細設計書にて作成する場合もある。

DBとの全体整合性や、“非機能”が考慮されているかもチェックする。
　※機能として間違っているケースは少なく、可用性・性能の担保が見落とされていることがままある

詳細設計を進める中で処理・テーブル追加など修正が発生する可能性が高い設計書。そのため、陳腐化しやすく、特に炎上時は適切な改定がされていることをチェックする必要がある。
　※ドキュメント自体をGit管理し、チケットに紐づけるのも良い

関連システムとのデータ連携などをまとめたモノ。見積もりに影響しやすいのでしっかりと決定しておく。連携先のシステムの調整が十分ではない可能性もあるため、ビジネス側も含め、全体の整合性を取れるように動く必要がある。