卸売業向けインストラクションコース

卸売業の情報システム − 開発体制と手順編

第32回「開発体制と手順(その3)」

消費財卸売業のシステム開発は王道の基幹システム構築と取引環境課題に応じたテーマ別のシステム構築に分類されます。この分類を考慮しつつシステム開発手順と、それに必要とされる開発体制についてカストプラス流にアレンジしてご紹介します。

(3)設計と最適化(その1)
@システム設計
システム設計の手はじめは「システム分析」です。いままでの整理も業務の分析といえますが、新情報システムや新物流システムへの適用のための分析としては現状分析に近いものでしょう。ここでいう分析は、新システム適用のための調査としたほうが良いと考えます。よくある間違いは先述した社内問題点の整理やシステムコンセプト創りが完成していないために、ベストな案と評価・判断されずもう一度業務分析をし、事例研究をし...となりシステム適用のための調査に入れない事態に陥ってしまうことです。パートナーのエンジニアに分析を依頼すると「もう一度最初から分析をします」などといわれてしまうことです。
適用とはシステム資源とシステム要件の整合性を持たせることであり、そのための調査をし、要件を抑えるか資源を拡張するかを見積もることが分析だといえるのです。ここでは経済合理性が強く働きますので、システム投資に対してどのくらいのメリットがあるという計算も実行しなければなりません。効果が低いとみなされた場合には経営者から機能を削減するように求められることも多々あります。複合的に必要がある一見あまり活躍しないサブシステムがある場合には、きっちりと関係性を説明する必要があるでしょう。
システム分析の手法はここでは解説しませんが、より自社にマッチする方式を見つけることになると考えられます。
さらに、先を目指したいと考える企業も少しずつ現れています。そのコンセプトは経済合理性ではなく顧客や従業員の満足を企業発展につなげるというものです。企業の発展と言わず社会の発展や世界の健全な発展と言い、多様性を受け入れることとSDGsにつながっていきます。この場合、ほんのミクロな視点でシステムの方向性が変わる例を挙げると、「経済合理性の追求」から見れば問い合わせ窓口を作らず(または減らして)コストが掛からず人手も割かないことを目指します。逆に「人間を一番にする」視点から見れば顧客および社内からの問い合わせに全力で応える窓口を設置し、そこには必要なすべての情報と解決コンテンツを瞬時に提供することを備えることにします。この結果、人員も増やしある程度のコストを投資し、その結果会社の発展や業界の発展に貢献しより多くの顧客獲得と売上利益を得ることに加え事業継続性を確保することにもなります。
次に「基本設計」に進みます。基本設計ではシステム資源とシステム要件の適用を具体的にシステムフロー・機能・情報関連として表現し、それらをドキュメント化していきます。その次の「概要設計」と同時に作っていくことも多くなっています。概要設計はシステムフローとシステム要件をアプリケーションプログラム(以下AP)の概要としてドキュメント化することです。ここでシステム要件を満足しているかしっかり確認を行いユーザー企業で承認をするというプロセスが必要です。近年では基本設計・概要設計とわけずに単に合わせて「概要設計」と呼ばれることが多くなっています。そうするとその中身はシステムの要件を具体的に流れ図にしてAPの概要としてもほぼ書き表すドキュメントとなります。しかも多くの場合、概要設計書の一部分を大きく取り出し「要件定義書」として確認する(押印することがほとんど)ことになります。そうなるとその中身はAPをほぼ想定しながらシステムフローを表し、どんなユーザー要件が実現できるかをドキュメントにすることになります。これはソフトウエアの開発に問題が生じやすい傾向があり、それを避けるために「ここまでしか作りませんよ!」という習慣化がなされ、これ以上のものは作らないし、ユーザーからすればこれ未満であってはならないというチェックドキュメントになってきたことを表しているのです。以前はユーザーとIT業者をつなぐ希望とか夢でわくわくするドキュメントでありましたが、今は約束を縛るドキュメントになってしまうことがあるのです。実につまらないですね。
近年ではこの要件定義をしっかり作成できなくなり、しっかりできないことが当たり前になり、あとで変更することもユーザーの立場では当然として、開発を請け負う側は迷惑と考えるようになりました。契約書で厳しく縛ることが多くなってきました。このやり方になり始めてから四半世紀経ちますが、ユーザーもシステムエンジニアもさらにその先を目指すことがしにくくなった分、トラブルを避ける能力ばかりが磨かれ、チャレンジする姿勢はITCの大手企業では排除対象にまでなってしまいました。DXの根本課題の一つですね。
いまではコンサルティング会社が昔のSEの役割を担っている例が多くなりました。しかし一般的なコンサルティング会社の経験値は業種・業務別にノウハウ集積されていないことがほとんどで、数社の事例が世界の全てと信じて進むことがあります。ユーザー側が気をつけなければならないのでしょうが、ユーザーはSEよりもよくできてコンサルタントよりもよくわかっている必要があり“神”でなければなりません。まさに21世紀版の「お客様は神様」を求められていて皮肉ですね。
概要設計や要件定義については多くの知見をもつコンサルタントや、何人かの外部の人に知恵を借りることが重要となりそうです。少し混沌としたやり方で昭和時代を思い出してしまいますが、繋がりこそが各企業を正しい軌道に乗せるということもよくあることです。

システム化要件の基本要素・構成
つづく(次回は「開発体制と手順(その4)」です)

元のページにもどる
トップページにもどる

カストプラスへメールを送ります

All rights reserved,Copyright2021Custplus Inc.