From: リスキルテクノロジー 高坂一城
新宿本校にて
ミスのない設計をするには
どうすればいいか？
これは
全てのエンジニアにとって
命題と言っても過言ではないでしょう。
今回は
設計ミスを無くすために
何が必要かをご紹介します。
目次
設計ミスは無くせるか
ミスのない設計をする！
と意識して
いざシステム設計してみたが...
実際には
さまざまな設計ミスが
システムの陰に潜んでいた....
そんな経験を持つエンジニアの方は
多いと思います。
設計ミスは100%無くせるのか！？
答えは残念ながらノーです。
人間が作るものですから
必ずどこかにミスが潜む可能性はあります。
なんだ、
やっぱり設計ミスはなくせないんだ...
なんて思わないでください。
そもそも
「無くせるか無くせないか」
という、
「0」か「1」で考えることに
無理があるのです。
設計ミスを防ぐにあたっては
ミスを無くす！
と考えるのではなく、
設計の品質を高める！
と考える方が遥かに建設的です。
システムと言えども
所詮は人間が作るものです。
言わば「ものづくり」ですね。
どのような
ものづくりでもそうですが、
品質の高いものをつくることが
ユーザーの評価に繋がりますし、
品質の高いものをつくることで
作り手（エンジニア）を育ててくれます。
とはいえ、
もちろん設計ミスは
無いに越したことはありませんよね。
設計ミスを
限りなく0に近づけるとともに
システムとしての
品質を高める姿勢こそが
エンジニアにとって重要なのです。
勘違いしてはいけません
設計品質を高めるために
勘違いしてはいけないことがあります。
それは...
「○○制度を導入しているから品質は高い」
...と言う点ですね。
○○には
設計手法であるとか
設計文書管理の規約であるとか、
テンプレート的な
手法や方法があてはまります。
確かに
一般的に広く使われている
制度や手法を導入することで
品質には一定の
ベースアップが見込めます。
それは非常に大切な事であり
導入することで品質が高まるのであれば
迷わず導入することをオススメします。
ですが、
「それを導入している＝品質が高い」
という考えるのは誤りです。
制度や手法は
ある面では大きな効果を生みますが
その制度や手法に
そぐわないアイディアは実行しにくいという
ある種の縛りも生みます。
さらに、
品質を最大限に高めるのは
制度や手法といった
実体のないものではなく、
あくまでエンジニアという人間です。
システム開発を
1人で行うケースは非常に稀です。
制度や手法だけに頼らずとも
さまざまな経験やスキルを持った
エンジニアが必ずそばにいるのです。
制度や手法がもたらしてくれる
メリットを最大限に利用しつつ...
エンジニア同士が協力しあうことで
設計品質を高めることができます。
どうやって品質を高めるのか
設計品質を高めるために
エンジニアに必要な心がけを
いくつかご紹介しましょう。
ある程度の品質が保証されているものを利用する
これは先ほどの
制度や手法のメリットを
利用するということに繋がります。
たとえば設計書であれば
先日ご紹介したUMLを利用するのがいいですね。
UMLは
オブジェクト指向設計のために考案された
モデリング言語ですので、
多くのエンジニアが...
「こんな設計書があれば理解しやすいのに」
というニーズに合わせて
進化し続けている設計書の表現方法です。
また、実装段階では
デザインパターンを利用するのもいいですね。
デザインパターンとは
プログラムを実装する際に
特定のパターンでプログラムを書けば
問題なく実装できるといった
パターン集のことです。
デザインパターンについては
また別の機会に話しますが、
デザインパターンも
多くのエンジニアが
品質向上のために編み出した手法です。
もちろん、
UMLやデザインパターンだけで
ベストだということはありません。
UMLはシステム内外の
処理の流れや仕様を把握できますが、
それだけでは足りないケースも割とありますし、
デザインパターンは
あくまでパターンですので、
実装する時には
システムに合わせる必要があります。
レビューで設計品質を高める
あるエンジニアが設計した内容は
そのエンジニアの視点で作成されたものです。
特定のエンジニア視点だけだと
設計ミスが含んでいる可能性が高まりますので、
多くのエンジニアと設計レビューすることで
設計ミスを0に近づけることができます。
レビューは自分以外のエンジニアの
スキルや視点を反映できるチャンスです。
それだけで
設計品質を大きく高めることができますので、
できるだけ設計レビューの機会を
設けることをオススメします。
ここでひとつ注意したいのが...
レビューの形式化
...です。
レビュー回数が多くなりすぎて
レビューそのものが形式化してしまうと、
折角レビューをしたとしても
「うん、まあ大丈夫だろう」
...と、レビューを受ける側も
細かい判断を放棄してしまうことがあります。
これだと意味がありませんので、
レビューする側は淡々とレビューするだけでなく、
時には他のエンジニアに問いかけるような
工夫を織り交ぜながら行うようにしましょう。
チェックシートを活用する
これ、意外ですけど
結構品質を高める効果はあります。
建設業や旅客業など、
一歩間違えれば大事故に繋がる業種では
今でもチェックシートが活用されています。
システムについて
共通的に考慮すべき事項や、
システム固有の特徴から
チェックする必要がある項目をまとめ、
設計内容をチェックしてゆきます。
品質を高めるために行っていることが
正しく行われたかどうかを確認するフェーズですね。
時間的な問題から
十分に行われていない項目があれば
そこにミスの可能性が含まれている訳ですから、
システム開発で行った行動の
どの部分に懸念材料があるのかを把握できます。
その懸念材料に対して
後日にでも対策することで
高い品質を確保することができるのです。
今やシステム障害が発生したら
何億という被害や
社会的な信頼を失いかねない時代です。
このような大事故を防ぐことができるならば
大きな手間ではありません。
基本はエンジニア間のコミュニケーションです
設計ミスを0に近づけるために
設計品質を高めるためにできることは
他にもたくさんありますし、
企業によってさまざまな工夫が施されています。
いろいろ書きましたが、
やはり基本となるのは
開発チーム内のコミュニケーションです。
制度も手法も
レビューもチェックシートも
活用するのはエンジニアという人ですので、
高度な技術を持っているけど
コミュニケーションに問題があったりすると、
メリットを最大限に引き出すことができません。
実際に
設計書もそこそこしかない
小さなソフトハウスだけれども、
設計ミスやシステム障害が
非常に少ないという企業もあります。
そういうところは
エンジニア間のコミュニケーションが
抜群に良いんですよね。
チームとして意思疎通が取れていて、
スキルの共有もできているので、
設計ミスを早期に発見できるのです。
高い品質のシステムを作る！
という目的意識を持ちながら
開発チームでスキルを共有できる...
それが
最善であり基本となる
設計ミスを防ぐ方法なのかも知れません。
リスキルテクノロジー
松田
PS
