こんにちは〜。
某大会の某県代表のboriです。
最近、自身の業務においてもそうですが、
仮想通貨やスマホ決済サービスによる事故がメディアに取り上げられたりする事が増え、設計や開発フローについて改めて考えさせられます。
今回は、ソフトウェアにおいての設計書の役割をいくつかご紹介できればと思います。
はじめに
ここで言う「設計書」とは種類や範囲を厳密にしませんので、
包括的にイメージしてもらえればと思います。
また、今回は設計の対象の例として「キーボード」というモノを使用します。
ご紹介する役割はモノでもソフトウェアでも重要なのと、
具体的な形としてあるモノの方が設計の重要性、役割をイメージしやすい方が多いかと思いますので！
まず、設計の対象はモジュール(部品)まで含めるのが基本です。
キーボードで言えばキーの一つ一つだとします。
今回はそのキーの情報を以下の3つに絞ります。
「数と形の情報」「配置場所の情報」「押した時の効果」
これら3つの情報を設計書に記すことでどのような効果があるのか？を、
いくつかの項目ごとにご紹介します。
品質・生産性
| 数と形の情報 | 足りない、欠けたキーがあれば組立時に気付く。 |
|---|---|
| 配置場所の情報 | 組み立てが楽。誤った配置をするミスが減る。 |
| 押した時の効果 | キーの1つ1つでテストが行える。 |
上記を見ていただいた通り、設計書がある事によって生産速度も向上し、
不良品の数が減りますよね！
よく「○回の耐久・落下テストに耐えた」と、いうような品質保証文句がありますが、
同様のテストをキーの一つ一つで行うことも可能です。
構造上、実はこのキーだけ脆かった！なんて欠陥にもテスト段階で気付きやすいです。
ソフトウェアでも同様のことが言え、実装スピードの向上、
バグやロジックの欠陥に早い段階で気付きやすいです。
拡張性・メンテナンス性
| 数と形の情報 | 修復時に正しい数、形が把握できる。 |
|---|---|
| 配置場所の情報 | 修復時に正しい配置が把握できる。 新しいキーを配置できないか把握しやすい。 |
| 押した時の効果 | 他の影響範囲(ショートカットキー)を把握しやすい。 追加するキーが重複していないか把握しやすい。 |
キーボードを作った人はもちろんの事、第三者が修復や機能を追加する時に
わざわざ分解せずとも設計書があれば色々と把握しやすいですよね。
ソフトウェアにおいても同様で、わざわざコードを読み解いていかずとも、
設計書があれば既存機能の把握、新規機能の追加の余地・必要性・影響範囲などが把握しやすいです。
他人が書いたコードを読み解いていくのって労力を要します。
ましてやそれがコメントが無いコードでは特に。
ゴールへの指針
| 数と形の情報 | 要件と紐付け、なぜこのような形にしたのかの意図を把握でき、 正しい形を見失わない。 |
|---|---|
| 配置場所の情報 | 要件と紐付け、なぜこのような配置にしたのかの意図を把握でき、正しい配置場所を見失わない。 |
| 押した時の効果 | 要件と紐付け、必要・不要な機能を把握しやすい。 |
有り得ることではないかもしれませんが、
キーボードを組み立てる人がユーザーの事を考え、「こういう形の方がよくない？」、「このキーはこの配置がいい」と勝手に作り変えようとします。
しかし、設計にはユーザーの事を考えての理由があり、
それらは要件として挙がってきます。
しっかりと要件に沿った設計書があれば、ユーザー想いの組み立てる人は(きっと)設計書通りに作ってくれることでしょう。
逆に、要件に沿った設計がされていない場合、
設計者がプロジェクトのゴールをしっかり把握していない事に気付けます。
設計書が要件に沿っていない場合、不要な機能も見つかるかもしれません。
そういう意味で、しっかり書かれた設計はプロジェクトのゴールを指し示し、
その設計書通りに組まれた制作物はクライアントやユーザーの希望に沿うはずです。
設計を活かす為に
設計書の存在は大変重要なのですが、設計書があるからといって
必ずしも良い制作物ができるとは限らないという事も覚えていただきたいです。
家に例えますが、優秀な設計書があったとしても、
施工業者の手抜き工事による欠陥住宅なんて事もあります。
ソフトウェアにおいても同様の事はありますが、
往々にして実装者よりも開発フローに問題がある事が多いです。
十分なスケジュールが確保されていたか？
チーム内、チーム間の連携はうまく取れていたのか？
開発中に過度な要件変更はなかったか？
良い設計書は良い開発フローでこそ活かされます。
さいごに
簡単にいくつかの項目をご紹介させていただきました。
設計書の役割としては今回ご紹介させていただいたものが全てではありません。
項目自体もまだまだありますし、
今回の項目内だけでももっと多くの役割が存在するかと思います。
また、設計書に必要な情報(形の情報etc)を漏れなく挙げていくという事がとても重要で難しかったりもします。
要件をしっかり定める、その要件を満たす、または不都合な情報を抽出するには
ディレクターや設計者の力に依る部分が大きいです。
設計は決して楽な作業ではありませんし、場合によってはとても労力を要します。
それでも、今回挙げさせていただいた役割だけでも設計の大切さは伝わったかなと思います。
開発フローや設計を今一度考え直し、
事故無く、余裕を持って開発を進めていきましょう！
＼\一緒にはたらく仲間を募集中!! /／ 919.jp
