今度は,分析時にあえて対象以外の周辺システムや,さらにシステム化されていない部分まで調べて,結果的にプロジェクトの効率が上がった例を紹介します。今回の例となるB社では,受注管理システム~生産管理システムの再構築を行いました。B社は,店頭などで販売されている一般品と,顧客からの注文で生産される注文品,自社製品を複数組み合わせて構成されシステム品として販売される「組物」といった商品を製造,販売している会社です。2つある基幹システムの統合B社の受注管理システムは上記の商品の販売,受注,売上を処理し,出荷管理システムや在庫管理システム,会計管理システムと連携しています。生産管理システムは在庫システムからの在庫情報と顧客からの注文品,組物の情報を基に,生産計画を立てるシステムです。現状ではこれら2つのシステムは別々に稼働していました。顧客からの注文品や組物は個別に生産管理システムの担当者に受注管理システムの利用者(主に営業事務員)が定型フォームで生産依頼をする運用で稼働していました。近年,顧客からの注文品と組物の件数が増加しており,これらに迅速に対応する必要が出てきました。そこで今回,2つのシステムの再構築を行い,データ連携および,今まで人が介在していた依頼表作成などの部分については,システム内で連携する仕様を追加することとなりました。本プロジェクトでは,今後再構築を行う予定である周辺システムでも使用するアプリケーション基盤となるフレームワークを構築することとなりました。このため,周辺システムに関しても現状の業務分析を行い,B社内で統一して使用できるアプリケーションフレームワークの構築を行うこととなりました。社内の他の業務を洗い出すB社には今回対象の2つのシステムの他に,すでに出荷管理システムや在庫管理システム,会計管理システムといったシステムが稼働していました。実際にはシステム化されていない部分があったり,システム間の連携ができていないため,データの二重入力をしていたりしました。そのため,受注管理や生産管理システムをはじめ,B社全体の既存のシステムだけでなく,システム化されていない業務についても洗い出しを行いました。これには業務フローおよびユースケース図を用いました。業務フローと言われる方もいらっしゃるかもしれませんが,業務システムといった大きな枠同士の関連やそれぞれ役割と流れを俯瞰して見るには業務フローは適しています。UMLで定義されているユースケース図は,システム化されている部分の操作者(アクター)と業務機能(ユースケース)の関連を表すのに適しているだけでなく,非システム部分についても記載でき,システム化範囲を決定するのに適しています。これにより,B社の業務を漏れなく抽出することができました。当初,本作業ではB社の情報システム管理者から,作業範囲が大きくなるため,対象システムのみに絞り業務分析を行いたいとの要望がありましたが,B社内統一アプリケーションフレームワークの構築には欠かせない作業であることをご理解いただき,作業を進めました。業務分析にあたり,以下のことに中心に分析を行いました。本工程を進めて行くと,今回対象の2システムだけでなく他システムとのデータの連携が必要であることが判明し,これらを統一したインターフェースで実現することとしました。これらを実現するため,各業務システム間のデータ共通および通信プロトコルの統一,業務APIの統一をするため制御システムを新規に構築することとしました。今後の展開を見据えた機能検討をもし今回,現状の業務分析のみを構築対象である2つの業務システムのみで行った場合,制御システムの構築はなかったと思われます。その場合,周辺システムの構築のたびに既存システムは接続インターフェースおよび接続方法について検討及び仕様変更を行う必要があったと思われます(その後,周辺システムの構築を行いましたが,制御システムを構築した効果により,先に構築した2システムとの連携を容易に設計することができました⁠)⁠。制御システムを含めた業務システムの基盤となるアプリケーションフレームワークの機能についても本工程で機能概要を検討しました。本来は業務分析工程の作業ではありませんが,全システムの業務を見渡せる本工程での検討を行いました。アプリケーションフレームワークには全システム間で共通となる機能を搭載します。各業務システム間で使用するデータ構造,通信,エラー処理,データストアアクセス等の各業務システムで必須となる機能を搭載します。ここで重要なのは業務機能に依存する機能やロジックは搭載しないことです。本工程では全業務システムで共通となる機能のすべてを抽出することはほぼ不可能でしょう。そのため,他のシステムの構築によるアプリケーションフレームワークへの機能の変更,追加が発生しても既存のシステムへの影響を最小限(できる限りないよう)にします。アプリケーションフレームワークに既存の製品を採用するか,新規に構築する場合には機能の検討にはできる限り有識者に参加していただき,十分に検討することがよいでしょう。顧客との意思疎通の手段としてのUML次に,受注管理システムと生産管理システム,制御システムの詳細な業務分析を行い,要件定義書を作成しました。現状の業務分析で作成した業務フローとユースケース図と顧客の業務要件を基に顧客と要件定義書の作成を行いました。この要件定義書の中には制御システムの構築に関する要件,アプリケーションフレームワークの構築に関する要件についても明記しました。要件定義書を作成する際,受注管理システムと生産管理システム,制御システムそしてアプリケーションフレームワークのそれぞれを別の章として作成しました。これらの関連図としてシステム概要レベルのコンポーネント図を作成し,各システム,フレームワーク間の連携について明確にしました。本プロジェクトのように複数のシステム構築が並行して行われている場合,それらにどのような機能があり,どのように連携しているかがわかりにくくなります。それが顧客側と開発側の意識の差や認識の違いなどを引き起こす原因になることが多いと思います。そのため,一目でわかるようにお互いの意思疎通の手段としてUML等を用いて業務システム,機能をイメージ化する手法を用いることは有効であると思います。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。2019」を開催しました。DAY1・DAY2の様子を注目セッションとともにお伝えします。LINEのエンジニア3名がイベントに先駆けて見どころを紹介します。コードの安全性・安定性を高める開発サイクル~テスト管理の効率を上げ,脆弱性診断を自動で行う~本連載では,連載「業務を改善する情報共有の仕掛け」を受けつつ,安全性・安定性を加えた開発サイクルについて考えていきます。若者世代から圧倒的な人気を誇るライブ配信&動画投稿コミュニティアプリ「MixChannel」(ミクチャ)の裏側(レコメンドシステムやサーバサイド開発など)について解説していきます。REPORT連載一覧No12(2009.04)今回のSoulHackで主に取りあげるのは,梅田望夫の「ウェブ時代をゆく」という本です。No11(2009.03)今回のSoulHackで取りあげるのは,阿部謹也の「世間学への招待」と他1冊の本です。No10(2009.02)今回のSoulHackで取りあげるのは,山本七平の「空気の研究」という本です。No9(2009.01)今回のSoulHackで取りあげるのは,アーノルド・ミンデルの「紛争の心理学」という本です。No8(2008.12)今回のSoulHackで取りあげるのは,河合隼雄氏の「カウンセリングを語る」という本です。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。