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

はじめに

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

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

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

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

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

システムの中身を記載していくところ。ビジネス側にレビューしていただくことは困難なため、ベンダーと認識合わせをしながら進めていく必要がある。コードと密接にかかわる部分については、Git等のコード管理ツールにて、ドキュメント番号を紐づけてもらうなどの対応をすれば確認がスムーズとなる。

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

　１．プログラム設計書
　２．インフラ環境定義書
　３．シーケンス図
　４．クラス図/ER図
　５．ログ仕様書

詳細設計の成果物はプロジェクトにより異なる。開発者（ベンダー）が主として作成することが多いため、観点としては基本設計の内容が抜け漏れなく、設計に記載されているかを確認する。

　・プログラム設計書を参照しながら、プログラミングを行う。最もコードに近いもの。

　・プログラム設計書があることで、曖昧性が下がり、プログラマーの技量に依存する箇所を削減することができる。

　・保守管理者がソース自体を読まずとも、スムーズにシステムの仕様・ソースコードの内容が把握できる。

　　※保守・運用工数が削減できる。

　・インフラシステム（AWSなど）の情報を記載した書類。プログラム設計書と同様、作業者の裁量による部分を削減するために作成する。

　・クラウドサービスでは陳腐化しやすいため、メンテナンスが大変。Cloudvizのような自動化サービスもあるが、結局見にくい。

　・プログラムの処理や流れを「時系列」・「クラス/オブジェクト間のやりとり」の視点で記載する。

　・複雑なシステムでも、プログラムの処理概要が理解しやすい。

　　※プログラム設計書の文字ベースだと、相互関係の理解に時間がかかる。

　・作るのが大変。

　・システムの静的な関係性を視覚的に表現するための図

　・システムのデータ全体像が理解しやすい。

　・データの仕様・関係性が分からないときに見るもの

　・プログラムのログ情報を一覧として作成したもの。

　・問題が発生したときに、どこに見に行けばいいか、何を見ればいいかを記載する。

　・基本的にはログ仕様書を見ずとも、ログだけでアクションが分かるように記載する。