信念。

システム開発は「手段」

業務用システムを構築するのは、「より効率的で正確な業務遂行」を達成するための「手段」です。
まずはそこをはき違えない事。

エンジニアとして、「最新の技術」とか「凝ったロジック」を実装したくなる気持ちがないわけではないですが、それは他所でやれば良い話であって、それが「目的化」してしまうのはNGです。（もちろん、「最新の技術」や「凝ったロジック」こそが問題解決のために必要になる場面もありますけど）

「高性能」よりも「扱いやすい」が優先されるべき

前段と通ずる部分なのですが、必要十分な機能は盛り込むのは当然として、「ボクのかんがえたさいきょうのシステム」ではなく、実際に使用・操作する方にとって「扱いやすい」ことのほうが100万倍大事だと思っています。
（エンジニア界隈には残念ながら「ボクのかんがえたさいきょうのシステム」を作りたがるタイプが割と多い気がします）

どんなに多機能でも、扱いにくければ業務効率は落ちますし、ミスを誘発し、当初目的が達成されません。

「目的」にフォーカスして「使いやすい」ものを作る

例えば、Excelは豊富な関数で複雑な計算もこなし、使い方次第では印刷用のレイアウトをしたり、方眼紙の代わりにしたり、図形を組み合わせたり、簡易的な図面を書いたりetc 工夫次第で「Excelではできないこと」を探す方が難しいと思えるほど「多機能」ですが、一般的な中小企業の事務員さんが果たしてそれらの機能の大半を「使いこなせて」いるでしょうか？
実際のところ、「前任者が残していったシートに決まった値を入力する」くらいの使い方しかできていない方が大半ではないでしょうか？
（もちろんExcelを批判しているわけではありません。人によって必要としている機能が違うので、それを最大限網羅していくとああいった多機能なパッケージソフトになるのはある意味当然です）

「業務用のシステム」を構築する上では、「必要な機能」を「直感的に呼び出せる」こと、キー入力やマウス操作を極力少なくすること、実際の業務フローを考慮して「忘れ」「抜け」「ミス」を予防できるものであることが大事です。どんなに多機能でも使わない機能に存在価値はありませんし、業務フローを無視して機能を羅列しても使いにくいだけです。

私が開発に携わらせて頂いた場合、「実際に使用する方」と直接コミュニケーションを取らせて頂き、極力それまでの業務フローを変えない形での機能実装をしていきますし、納品後も一定期間、ヒアリングをしながら修正・改善をしていき、実際に使用する方が「使いやすい、仕事がしやすくなった！」と笑顔になっていただいた時点が正式な納品完了だと考えています。