孫子 孫子の兵法に学ぶ洞察力：言動から読み解く企業システムの本質とリスク管理術
孫子の兵法「行軍篇」から、言動に潜む内情を見抜く洞察力を学ぶ。現場の兆しを見逃さず、真の要件を引き出すことで、要求変更やプロジェクト失敗を防ぐ。経営者が身につけるべき観察力と、企業システム改革に活かす戦略的思考を解説。
要件定義
孫子 孫子 智者の思慮は、必ず利と害との両面をつき混ぜて洞察する。
物事は利害、表裏、光と影、２面性を持っている。そのことを忘れずに常に両面から考察できるのが知恵者。変革による害は何か、害を被る人は誰か、例外事象は何か等を事前に考慮した要件定義や設計ができる人が賢者。そのために有効な手段がドキュメントレビューと危険予知。
DX システム再構築の落とし穴ー正攻法だけでは勝てない！
システム再構築では業務分析・要件定義から進めるトップダウン・アプローチだけでは思わぬ落とし穴におちることがある。現行システムを開発した当時のシステム担当者や業務担当者が居なくなっているから、ソースコードを解読して業務要件を把握するボトムアップ・アプローチも必要。
ソフトウェア あらゆる要件の組合せを想定せよ！
要件を整理する段階でどれだけの組合せを想定できるかが、その後の成否を大きく左右する。「あらゆる要件の組合せを想定」するのは、実はそれほど難しもなく、特別な能力が必要なわけでもない。要件を5W2Hで整理して、これらのケースに条件成立と不成立のケースを掛け合わせればよい。
ソフトウェア 要件の裏を取れ！
刑事ドラマで事情聴収した内容の事実確認を「裏を取れ！」という。同様にヒアリングを主体としてシステム技術者が要件定義を行う場合、要件の事実確認を怠るべきではない。「裏を取れ！」はやはり重要である。運用試験以降にあるはずのデータが無いことが発覚すれば、大きな手戻りが発生する。それを思えば「裏を取る」手間を惜しんではならない。
RPA 他人任せDXのツケ
業務部門が自らRPAを活用してDXを推進すれば要件の不備に早く気が付き軌道修正ができる。しかし、IT部門などがロボットの開発を引き受け、従来のシステム開発と同じようにヒアリングにより要件定義をする場合、思わぬ事態になることがある。つまり、従来のシステム開発と同じように要件定義を失敗する。RPAのようなノーコード開発によるDXでも、要件の事実確認は重要だ！
企業システム戦略 ◆後工程での手戻りを防止するための取り組みとは？
フロントローディングは詳細設計や製造を始める前段階（フロント）の基本設計までに、十分な作業負荷（ローディング）をかけて、あいまいさを極力排除し、後工程での設計変更を少なくし全体のコスト・期間を短縮しようという考え方。
企業システム戦略 ◆例外処理も漏れなく要求仕様化するには？
ソフトウェアに対する要求仕様は、とかくあいまいになりがちである。「質の高い仕様書」「分かりやすい表現」を心がけたとしても、いざ、蓋を開けてみると、思ったものと違う動作をするソフトウェアができてきたりする。特に、想定していなかった事態（例外）が発生した時にこういったことが起こりやすい。
企業システム戦略 ◆新技術を使用する場合のメリット・デメリットは？
最近のＩＴ革新はめざましく、次から次への新技術が出てくる。はたして、それは本当に役立つのか。その答えはＹｅｓでもあり、Ｎｏでもあるというのが正直なところだ。新技術が本当に役立つかを、自社の立場から考えなければならない。
企業システム戦略 ◆適切な応答時間を設定するには？
仕様書の主な要素には、機能の他に性能がある。いわゆる、応答時間のことだ。利用者にとって応答時間は早ければ早いにこしたことは無い。ただし、それが、開発費用・期間に何の影響が無いのであれば。成果につながらないのに、高額な投資で性能を追い求めるのは無駄になる。