RPA 他人任せDXのツケ
業務部門が自らRPAを活用してDXを推進すれば要件の不備に早く気が付き軌道修正ができる。しかし、IT部門などがロボットの開発を引き受け、従来のシステム開発と同じようにヒアリングにより要件定義をする場合、思わぬ事態になることがある。つまり、従来のシステム開発と同じように要件定義を失敗する。RPAのようなノーコード開発によるDXでも、要件の事実確認は重要だ！
要件定義
RPA 企業システム戦略 ◆後工程での手戻りを防止するための取り組みとは？
フロントローディングは詳細設計や製造を始める前段階（フロント）の基本設計までに、十分な作業負荷（ローディング）をかけて、あいまいさを極力排除し、後工程での設計変更を少なくし全体のコスト・期間を短縮しようという考え方。
企業システム戦略 ◆例外処理も漏れなく要求仕様化するには？
ソフトウェアに対する要求仕様は、とかくあいまいになりがちである。「質の高い仕様書」「分かりやすい表現」を心がけたとしても、いざ、蓋を開けてみると、思ったものと違う動作をするソフトウェアができてきたりする。特に、想定していなかった事態（例外）が発生した時にこういったことが起こりやすい。
企業システム戦略 ◆新技術を使用する場合のメリット・デメリットは？
最近のＩＴ革新はめざましく、次から次への新技術が出てくる。はたして、それは本当に役立つのか。その答えはＹｅｓでもあり、Ｎｏでもあるというのが正直なところだ。新技術が本当に役立つかを、自社の立場から考えなければならない。
企業システム戦略 ◆適切な応答時間を設定するには？
仕様書の主な要素には、機能の他に性能がある。いわゆる、応答時間のことだ。利用者にとって応答時間は早ければ早いにこしたことは無い。ただし、それが、開発費用・期間に何の影響が無いのであれば。成果につながらないのに、高額な投資で性能を追い求めるのは無駄になる。
企業システム戦略 ◆要求機能が多過ぎる場合の対処方法は？
仕様書には、要件を満足すべくシステムに対する具体的な機能や性能を決定して、明文化していくのであるが、それは、全て真に必要、かつ十分なものか。この問いかけを忘れると際限なく仕様は膨張し続ける。その結果が、開発費用の肥大、開発期間の延長に繋がる。
企業システム戦略 ◆読み手に親切な分かりやすい表現とは？
ソフトウェア開発においては、「分かりやすさ」ということが重要である。分かりやすいビジョンや要件、仕様書などがそろってこそ、分かりやすいソフトウェアを開発することができる。分かりやすいソフトウェアは、保守費用も安く、環境変化にも柔軟、かつ迅速に対応できる。
企業システム戦略 ◆要件を確実に伝える質の高い仕様書とは？
要件を満足するための、必要にして十分な「質の高い仕様書」とは、どんなものか。それは、要件を満足するように、コンピュータにやらせるべき「読み・書き・そろばん」が明確になったものである。特に、コンピュータに何を「書かせる（出力させる）」のかを第一に考えなければならない。
企業システム戦略 ◆要件定義はどこまでやればよいか？
要件定義は、最初にして最重要な作業であるので、これに時間をかけて、じっくりと取り組むべきである。しかし、それは、ダラダラとやれば良いというわけではない。８割の要件が確定すれば、ほぼ目的を達成することができる。
企業システム戦略 ◆複雑な要件を整理する時のポイントは？
人間系と機械系を合わせたシステムとしての全体系に対して、儲けるための「要件」を、じっくりと、知恵を絞って考えなければならないと述べたが、考えれば、考えるほど難しくなってくる。複雑な要件を整理するときには「シンプル・イズ・ザ・ベスト」の考え方で行うのが良い。