システム方式設計を作成する目的や使い方って考えたことありますか？
作らなきゃいけない決まり、もしくは作るべきだけど、ほとんど使われないなんてことないですか？
せっかく作るので、きっちり使って有益なものにしたいですよね。
システム方式設計書を作る目的やどのように利用するかをお話したいと思います。
結論
目的は大きく3つです。
・クライアントとの仕様のすり合わせ
・仕様の説明
・実現方法の具体化（チーム開発の場合は実現方法の周知）
この3つの目的がシステム方式設計書に書かれていればクリアーと言事になります。
チームで開発する場合と、副業などで一人で開発する場合で少し使い方が変わります。
このあたりも触れていけたらと思います。
システム方式設計は役に立たない？
システム方式設計ってそもそも必要なのでしょうか。
多くの人が「必要？」って思っているかもしれません。
まずは、この点を解決していきましょう。
システム方式設計ってプロジェクトで作ってるんですけど、本当に必要なんですか？
基盤担当者が作ってるんですけど、あんまり、利用したことないんですよね。
読んでもよくわからないし、大したこと書いてないんですよね。
そういう方多いですよね。
システム方式設計書って、開発のプロセスで「作ること」になっているんですけど、作る目的や使い方を理解せずに作ってる人が多いですね。
「とりあえず、ルールなので作ってます」という状態になっていることが多いようです。
システム方式設計書をきっちり書けていないから役に立たない状態になっているという事ですか？
そのとおりです。
でも、システム方式設計書に何を書かなければならないかは、だいたい決まっています。
それなのに、どうしてきっちり書けていないのでしょう？
それは、作る目的や使い方（活用方法）を理解せずに作っているからです。
システム方式設計書はきっちり作ると200ページ以上にもなる設計書になります。
こんなに労力がかかるのに、それに見合う有益なところがなければ、まともに作ろうと思いませんよね。
労力をかけてもメリットがなければ手を抜いてしまいますね。
その結果、役に立たないシステム方式設計書が出来上がっているのです。
目的と使い方
本題の目的と使い方です。
システム方式設計書を作る目的は次の3つです。
・クライアントとの仕様のすり合わせ
・仕様の説明
・実現方法の具体化（チーム開発の場合は実現方法の周知）
一般的な情報とは少し切り口が違うかもしれません。
これは私がシステム方式設計を手掛ける中で気づいた独自の観点です。
クライアントとの仕様のすり合わせ
一つ目の目的は「クライアントとの仕様のすり合わせ」です。
意外と見落としがちなのですが、かなり大切な目的です。
もしかすると、システム方式設計はシステム開発者が作ってシステム開発者が使う設計書だと思っている人もいるかもしれません。
システム方式設計書は要件定義の工程から作成を始めます。
（システム開発のV字モデルを参照ください）
つまり、要件を設計書にすることを意味します。
要件の内容を整理してクライアントに確認していくのです。
システム方式設計書に記載する項目（オンライン方式とか帳票方式とか）ごとに要件を整理して認識違いがないことを確認しておきます。
仕様の説明
2つ目の目的は「仕様の説明」です。
システム開発者、技術者が一番得意とするところです。
役に立たないシステム方式設計書はこの点だけを書いていることが多いようです。
この目的は簡単です。
その仕組みがどのようになっているかを説明すことが目的です。
のちにメンテナンスをしよとしたときに、仕様を調査するための説明書になっていればいいのです。
しかし、この仕組みを使って実際にしステムを開発するためには情報が足りません。
もう一つは、これから作るシステムがどのような仕組みになるのか考えを整理することができます。
これによって、「いざ作ってみたら、予想以上に時間がかかった」なんてことを防ぐことができます。
仕様の説明を書いている時点で、ある程度システムの複雑さなどが見えてくるのです。
実現方法の具体化
3つ目は「実現方法の具体化」です。
「仕様の説明」で明らかにした仕組みを利用して、システムを作るためにはどうやってその仕組みを使ったらいいのか情報が必要です。
例えば、部品（API）の具体的な使い方（ソースコードレベル）や、処理方法のルールならどんなソースコードを書いたらいいのかサンプルを用意します。
特にチームで開発する場合は、「仕様の説明」があっても実際の開発メンバーはその仕組みをどう利用したらいいのかわかっていないことが多いのです。
システム方式設計書に記載していることについて質問がたくさん来ることないですか？
そして、具体的な実装方法をだったりしませんか？
この観点が抜けているのです。
副業での考え方
副業でプログラミング、システム構築の仕事を受注する場合にシステム方式設計書は必要なのでしょうか。
一人でシステム開発をしていると、ここまで設計書を作らなくても出来てしまいますからね。
そして、作っているとコスパに合わないかもしれません。
（ECサイト構築で50~100万というのを見かけますが、これでは安すぎでシステム方式設計書なんて作ったられませんね。）
そこはシステム方式設計を作るメリットを打ち出して単価アップの交渉をするのもいいでしょう。
単価アップにつながらなくても、自身の身を守るため、次の受注・単価アップにつなげるために作った方がよいと思います。
「クライアントとの仕様のすり合わせ」については自身の身を守るためにやった方がいいです。
要件の確認して仕様齟齬による手戻り・トラブルをなくすためです。
「仕様の説明」については使用齟齬をなくすことと、付加価値をつけることができます。
この部分の資料があることで後のメンテナンスはとてもやりやすくなります。
そして「実現方法の具体化」は付加価値を付けることができます。
コメント