プログラミングにおける設計の必要性とコツ

はじめに

プログラミングの設計についてあまりイメージできない方や、プログラミング設計とは何をすれば良いのかわからない方はいませんか？今回の記事では、設計についてわからない方に向けて設計書の必要性や設計する時のコツ、プログラミングにおける設計図について解説します。

プログラミングにおける設計とは？

どのようなものを作るか表現する

これからどのようなシステムを作るか表現するために設計書は必要です。

例えばクライアントからあるシステムを作って欲しいと言われた際に何もなしにシステムを作ってしまうと、高確率で認識の齟齬が発生してしまいます。そのため、これから我々はどのようなシステムを作りますという方針をクライアントと認識を合わせておく必要があります。システムの概要からどのような機能を持つか考えることが、プログラミングにおける設計の一種になります。

クライアントと設計の認識を合わせておくことで、手戻りが発生せず少ない工数でシステム開発できます。設計とはシステムの概要やどのような機能をつけるか考えることです。

プログラマに実装イメージを伝える

実際の現場では設計と実装で別の人がやることがあります。その際に設計がしっかりできていないと実装に無駄な工数がかかってしまいます。また設計の段階でやらなければ行けない処理を洗い出さずに実装してしまうと、致命的な不具合につながる確率が高くなります。

短期間で不具合の少ないシステムを構築するためにも設計に時間をかけるようにしましょう。

設計書の必要性

設計する際には設計書を作成することが多いです。作成する設計書の種類の例として、要件定義書、外部設計書、内部設計書、テスト仕様書等があります。設計書が必要な理由は前述したクライアントとの認識合わせの他に大きく以下の2点があります。

開発工数を削減することができる

設計書を作成しておくと実装や運用・保守フェーズに入った時に工数を大幅に削減することができます。理由は、新規にプログラムを実装する際やソースコードを修正・解析する際に設計者に確認する時間が減るからです。

設計書をきちんと作成している現場と作成せずに開発を進めている現場の場合、設計書を作成している現場では設計者と実装者が異なる場合があります。設計者と実装者が異なっていたとしても、設計書にどのように実装すればいいか細かく記載されているため、設計者に問い合わせる回数が少なく済み、1つの機能を完成させるのに2~4日で実装することができます。

一方で設計書を作成していない現場では、現状のコード解析から始まりコード解析だけでは理解しきれなかった部分を実装者に問い合わせてから、実装をする必要があり3~7日かかってしまいます。以前の実装者がすべて把握しているとは限らないので問い合わせた先で更にコード解析に他の作業が進まない状況もあります。

このように設計書がある現場とない現場では1~3日ほど開発工数に差が出てきます。工数をできるだけ削減し開発効率を上げるためには設計書が必要不可欠です。

導入・引き継ぎが楽になる

新規で参画した人に実装をお願いする際やプロジェクトを離れる際に、引き継ぎ資料として使用することができるため、新たに資料を作成するという手間が省けます。

新規参画者に実装をお願いした時、まずコード解析作業から開始すると思いますが、設計書があると解析する手助けになります。先に処理の流れや関数の概要が記載されている設計書があることで、大まかにシステムを把握することができます。プロジェクトを離れる際に設計書のメンテナンスと資料一覧を作成するだけで引き継ぎ資料が完成します。最新の実装に合わせて設計書を更新し設計書の一覧を作成しておくことで、メンバーと打ち合わせの時間を最小限に抑えることができます。

結果的にプロジェクト全体の生産性向上にも繋がるため、設計書の作成は重要です。

設計のコツ

実際にプログラムを作成する前に要求されていることを理解し、どのように実装していくかシステム全体を考慮して考える必要があります。考える際に以下の3点を意識して設計をすることで、品質の良いプログラムを作成することが可能です。

沢山のパターンを考える

予想外の動作にならないように考えられる使用ケースを洗い出しましょう。正常動作のみのプログラムは良いプログラムと言えません。まずは正常動作を考え大枠を作成し、異常ケースはどのように対応するべきかも並行して考えることが重要です。予想外の処理になってしまった時の対処方法も設計の段階で考えられると、良いプログラムを作成することができます。

インプット・アウトプットを明確にする

プログラムレベルで設計する際には、インプットとして何を渡すとどのようなデータで返ってくるのか明確にしましょう。

不具合の調査等でソースコードを追っていく際にどのようなデータを扱っているのかわからないと、関数の中までじっくり解析しなければいけなくなってしまいます。しかし、指定されたデータをインプットすることやアウトプットされるデータを明確にしておくことで、不具合の原因となっている処理を導きやすくなります。

できるだけ小さい単位に区切る

要求された機能を実現するために必要な処理や機能をできるだけ細かく区切っておきましょう。理由は2点あります。

1点目は、同じような機能を追加する時に再利用できるからです。1つの機能を1つの関数で実現してしまうと、他の機能で同じような処理をしたい時に再利用ができなくなってしまいます。1関数内でやる処理は1つにすることで再利用を容易することができ生産性も向上します。

2点目は、コード解析にかかる時間が減るからです。単純な機能であれば関係はありませんが、複雑な機能を処理を細かくせずに同じ関数内で実現すると、インプット・アウトプットが複数あり解読が困難になってしまいます。1つの機能に対して複数の細かい処理を集めて実現している機能であれば、インプット・アウトプットも明確なっているので解析に要する時間を削ることが可能です。

設計図の作成

クライアントにシステムの動作や構成を説明するために設計図を作成します。その際に使用されるのがUMLと呼ばれるモデリング言語です。実際の現場でもクライアントとの認識合わせを始めエンジニア同士の設計レビューの際にも使用します。UMLを使用して図を作成すると、予期しない不具合の原因となる問題を早期に発見することが可能です。UMLで作成される代表的な図は以下のようなものがあります。

クラス図

オブジェクト指向言語に限りますがクラスの関係を表す図です。各クラスがどのようなデータを持つか表現しています。この図があることで、新機能実装する際に既存のクラスを使って実現できないか検討することできます。その結果、プログラムの拡張性や保守性を向上させることができます。事前にクラス図を作成しておくことで、間違えて全く同じ構成のクラスを作成してしまうことを防ぐことができます。

シーケンス図

オブジェクト間の動作の流れを時間軸に沿って表現する図です。何かイベントが起こった際にどのような処理をするかを視覚的に表現することが可能です。また処理のタイミングを視覚的に表現できるため、あるタイミングで処理が入った際の対応も含めて考えることができます。クライアントとのシステムイメージの共有で使用されるケースも多くあり、後の認識の違いによるトラブルを防ぐ意味でも重要な設計書になります。

ユースケース図

ユーザー視点でシステムを利用した時の例を表した図です。主に要求定義のフェーズで使用されることが多いです。その理由はクライアントの要求を分析し、ユーザーがどのような利用ケースがあるか考え、最適なシステムを構築する必要があるためです。ユースケース図を見せる人はIT知識があるとは限らないため、誰でも理解できるレベルで書く必要があります。規模が小さかったり、既存システムの拡張等では作成しないケースもあるため、作業している現場で必要になった際に書き方を調べて作成するようにしましょう。

プログラミングにおける設計のまとめ

プログラミングにおける設計はクライアントとの認識の齟齬をなくすためや、エンジニアがシステム全体を理解する上で重要になってきます。設計の際にはインプット・アウトプット何かを明確にすることや、できるだけ小さい単位の処理にすることで品質の良いプログラムを作成することができます。また、設計書は実装イメージを視覚的に表現できる他に、導入・引き継ぎ資料として使用できるので、作成しない現場でも個人的に作成しておくことをおすすめします。