コンピュータ－－－アプリの開発

ここでは、コンピュータのアプリケーション、特に業務システムの開発について大まかに説明する。業務システム以外の「アプリ」の開発もほぼ同じ手順で開発する。

１．概要設計
業務システム、たとえば、生産管理システムを開発したいとき、先ずシステムの構想から始める。

１）構想設計
システムの目的、対象、物理的な範囲、構造、開発方法、完成時期を大まかに描く。これは、システムのラフスケッチの段階である。

２）現状分析と要件定義
次に、システム構想を実現するために、業務の現状を分析する。たとえば、工場の現状調査では、管理職からではなく業務担当者からありのままの作業内容を聞取り調査する。

調査の結果を分析して、現状とシステム構想とのギャップを明らかにする。そのギャップを解消して、さらにシステムの目的を達成するためには何が必要かを明確にする。これを要件定義と言う。この要件定義を技術、運用、経済性、３つの観点でシステムの実現性を検証する。

日本の場合、なぜか現状分析が甘く、システム稼動後に「想定外の事故」で重大なトラブルを招くことが多い。

アプリが業務の合理化システムの場合、下(業務担当部門)から上(経営陣)にシステム開発の承認を求める。メリットが開発費より大きいとき、開発は承認される。

戦略システムの場合、開発費の見積りは可能だが、メリットの推定が困難な場合がある。無理にメリットをはじいても机上の空論のケースがある。このような場合はトップダウンの形でシステムを開発する。ただし、日本の大企業では、経営陣のリーダーシップが必要なトップダウンのシステムは極めて稀である。この道４０年で、日本で２件だけ経験したが、いずれも成功した。

２．システム開発と導入
システム開発は、主にシステムエンジニア、プログラマー、業務改善担当者(コンサルタント)の仕事になる。

１）基本設計
ハード、コンピュータ技術、プログラミング言語、データベースソフト、通信技術などを具体的に決定、システムの論理構造とデータベースの論理構造を設計する。このとき、再びシステムの技術、運用、経済性を正確にチェックする。

この段階でシステムの出来不出来が決まる。もし問題があれば、躊躇せず振り出しから検討する。躊躇すると運用とコストの両面に禍根を残す。分かっているが、失敗するケースは意外に多い。

２）詳細設計
基本設計(書)にもとづき、プログラムを詳細に設計する。データ入力画面や帳票を詳細に設計する。これらの設計書をプログラム仕様書と言う。

３）プログラム作成
仕様書にもとづいて、プログラムを作成する。この作業を、プログラミングまたはコーディングと言う。この作業は、社外や海外のプログラマーに委託することもできる。１９９０年代から、在宅フリーのプログラマー(経験のある主婦など)や海外に委託するケースが目立ち始めた。正しい日本語、または正しい英語で仕様書を書かなければプログラマーが誤解する。逆に、曖昧な仕様書はプログラマーに嫌われる。

プログラマーは、自分が作成したプログラムをテストして仕事を完了する。このテストを単体テストと言う。

プログラム作成と平行して、業務の改善と新システムの操作マニュアルを準備する。同時に、新システムに必要なデータを整備する。

業務改善は、たとえば工場の場合は、工程と運用ルールといったハードとソフト両面の改善を意味する。また、これらは自社だけでなく取引先も含む改善である。

最後に、単体テストを終えたシステムの連動させてチェックする。これを連動テストと言う。

４）導入
連動テストを終えて、新システムを実地に導入する。「一斉切替え」「新旧システムの平行切替え」またはこれらの組合せで新システムを導入する。「平行切替え」は、新旧システムを運用するので業務担当者の負担は大きい。

大きなシステムや金銭処理がからむシステムでは、危険な「一斉切換え」を避ける。会計処理がからむ場合、新旧システムの月末と年度末の決算結果を検証するため、数年にわたる移行も珍しくない。何があっても、トラブル回避が最優先事項である。

ユーザー教育とシステムの検証を終えて、新システムへの移行を完了する。

次回は、約１ヶ月後にグローバルシステムの概要とメリットを紹介する。