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