テクニカル

先を読む(その4)

前回まで、「システム開発において、リスクを着実に把握し解消するために、どのような考え方で進めればよいか」について、以下の順序にて述べさせていただきました。

①決めるべきものとして何があるかを事前に整理しておく
②上記のうち企画段階で決まっていないものを把握し、そのリスクから、決めるべき期限を定めておく

今回は「先を読む」の最終回、以下のテーマについてです。

③後になり、詳細が決まった時点で、システム全体のどこに影響が出るのかを調査し、必要な対処(影響局所化検討等を含め)を行う


③後になり、詳細が決まった時点で、システム全体のどこに影響が出るのかを調査し、必要な対処(影響局所化検討等を含め)を行う

「物を作る前に、システム全体の影響をどうやって把握するのか」と思われるかもしれません。
例えば、「このシステムは、どのくらいのレスポンスが出るのか」を作る前から把握する訳です。
もちろん、プログラムもなければ、テストに使うサーバ上で、実機での確認も出来ません。

ここは、逆転の発想が有効な解となります。
つまり、「発生する可能性が高い問題(事象)をあらかじめ分析しておいて、その問題が起きないかを、システム全体視点で机上で可視化すること」が策となります。
この可視化に必要な要素は、以下の3つ。

  1. システム全体の処理の流れ図
  2. そのシステムで発生しうる問題
  3. システムを構成する要素(データベース、ネットワーク、PAASやパッケージなどの)の基礎知識

作業の流れは以下の通りです。

[ステップ1]
システム全体の構成要素を、物理構成(サーバ、ネットワークなど)を意識しながら図に整理。
弊社ホームページにて随所に記載しているQBMAPとはこの図の事例です。

[ステップ2]
あらかじめ、過去のトラブルから洗い出しておいた主要なトラブルについて、「同等の問題に繋がらないか」をステップ1で記載した図上にてトレース。

[ステップ3]
解析の際には、自らが用意するアプリケーションだけでなく、各種システム設定や、システムを構成する要素(データーベースなど)においても、異常発生、処理遅延などに繋がらないかを考慮。

上記解析により、どのような条件で、システムのどの場所で、どのようなトラブルが発生する可能性があるかを洗い出せます。洗い出した問題は、リスクとして整理し、リスクヘッジ対策をシステム完成までの間に施すことになります。

もちろん、これら分析を行うことは、設計工程の工数増加になりますが、実装工程やテスト工程で問題が発生するリスクをかなり抑えることが可能となります。
結果として、全体工数の削減に繋がりますので、貴社の強みの一つになるはずです。

いかがでしょうか?
ぜひ一度、貴社のシステム開発の際に、試行されることをお薦めします。

以上で「先を読む」の連載は終了となります。ありがとうございました。

Bethany DrouinによるPixabayからの画像