DXとしてシステム導入を検討する時に最初に出てくる耳慣れない言葉が要件定義です。
＜要件定義とは：requirements definition＞
システム開発やソフトウェア開発において、開発するシステムが満たすべき機能や性能、条件などを明確にする作業です。その内容は要件定義書などの文書にまとめられ、発注者である企業と、システム開発と提供までを行うシステムベンダーの合意事項となります。
＜要件定義の内容＞
システムやソフトウェアの内容によって、要件定義に含まれる項目やどこまでを明らかにするかは変わりますが、一例としては下記のようなことです。
・業務要件
現在の業務とシステム化する業務を明記します。システム化によって自動化、短縮化、省力化、高精度化されるようなこと、どこまでの範囲を含むかが方針になります。
・機能要件
システム化した場合のインプット情報とアウトプット情報です。キーボード、スマホアプリ、紙、他のシステムなどからのインプットを行い、アウトプットは画面で閲覧、メールで配信、ブラウザで公開、スマホで閲覧、紙で出力などの機能が決まります。
・非機能要件
どれぐらいの人数で使うのか、社外から使えるのか、セキュリティーはどのぐらいのレベルにするか、メンテナンスやトラブル時の対応などを決めます。
・制約条件
最初に発生する開発費用と開発期間、自社からの協力体制、完成後の保守管理費用、連携する外部システムや社外の人に求められることなどが前提とされます。
＜具体例＞
製造業で工程の進捗管理システムを導入する場合
業務要件：現在はホワイトボードで作業計画と実績を管理しているが、更新が面倒で緊急対応が記録として残らない。リアルタイムで進捗を把握し、記録を残す。
機能要件：作業指示書の発行、自動ガントチャート作成、工程ごとの進捗入力と表示
非機能要件：3人同時にアクセスしても動作が遅くならない、スマホからも操作できる
制約条件：既存の会計ソフトとCSVで連携する必要がある。初期費用は200万円
＜基本的な考え方＞
システム導入やソフトの開発では基本的に「自社向けに作る」（カスタムやアドイン）という部分を最小限にするのが重要です。こうした自社向けに作る部分については難易度が高いため時間と費用がかかり、その上動作が不安定になったりします。
そのための基本方針は「パッケージシステムをそのまま使う」です。自社向けにせず、システム開発の会社が持っている汎用のシステムがあればできるだけ変更せずに使うことで余計な費用、トラブル、維持管理やアップデート対応を抑えることになります。
＜パッケージソフトを使うための方法＞
そのためには自社の仕事のやり方を変える必要があります。長年慣れ親しんで最適化されている業務について、システムに合わせて仕事を変えるということで、とくにベテラン従業員などに一番ストレスが発生します。
＜DXの流れ＞
システム化による自動化、省力化の動きと、従業員の流動性が高くなってベテラン社員による属人的な業務を排除してマニュアル化する動きがあります。これは今後の企業では一部の例外となる業務を除いて、通常業務では避けられない動きです。
それに対応するためには日ごろから業務を明文化、マニュアル化することで要件定義がやりやすい状況を作っておくことでシステム化の検討の際の従業員の負担を減らすことが可能です。
中小企業で製造業の皆様へまとめ
・ システム導入を想定して自社の仕事のやり方を一般的なものに合わせましょう
・ 業務の明文化、作業マニュアルなどを充実させましょう
・ 帳票の名称なども一般的にしておくのが有効です
お問い合わせはこちら→お問い合わせフォーム
