【アップルとジョン・ターナス氏が示した設計思想】要望どおりでも使われないシステムの理由

「要望どおりに作ったはずなのに、現場で使われない」
システム開発において、この問題は決して珍しくありません。むしろ、多くの企業が一度は直面する典型的な失敗パターンです。

一見すると、要件通りに開発されたシステムに問題はないように思えます。しかし実際には、「要望どおりであること」と「使われること」は別の話です。ここには、システム開発における重要な視点の欠落があります。

本コラムでは、その本質を「体験設計」という観点から整理し、なぜ既存の進め方では限界が生じるのか、そしてフルスクラッチ開発がなぜ有効なのかを解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】ジョン・ターナス氏が示すAI時代の設計思想、体験価値を起点とした開発へ

米アップルの次期CEOに就任するジョン・ターナス氏は、スティーブ・ジョブズの思想を継承し、製品開発において機能や価格だけでなく体験価値を重視する姿勢を示した。新製品の設計でも細部に至るまで品質とデザインを追求し、その哲学を体現している。特にAI分野では、技術を単なる機能として捉えるのではなく、ユーザーにとって意味のある体験を生み出す手段として位置づけるべきだと強調した。この考え方は、今後の製品開発や競争軸が「技術力」から「体験設計」へと移行していく方向性を示唆している。

出典：日本経済新聞「ターナス氏、ジョブズ哲学を継承 デザイン性追求」2026年4月22日付朝刊

要望どおりに作っても使われない理由

システムが使われない原因は、単純な使いづらさだけではありません。多くの場合、問題はもっと根深いところにあります。

そもそも、現場から上がってくる「要望」は、あくまで表面的な解決策であることが少なくありません。例えば、「この入力項目を追加してほしい」「この画面を分けてほしい」といった要望は、現場の不満の一部を切り取ったものにすぎません。

その背景には、「入力に時間がかかる」「確認作業が煩雑」「情報が分散している」といった本来解決すべき課題があります。しかし、それらが十分に整理されないまま要望として積み上がると、結果として“機能の集合体”のようなシステムが出来上がります。

この状態では、個々の機能は要望どおりでも、全体としての使い勝手はむしろ悪化します。その結果、「使われない」という状況が生まれます。

システムは“機能の集合”ではなく“体験の連続”である

見落とされがちですが、ユーザーは機能単体ではなく、「一連の業務の流れ」としてシステムを利用しています。

例えば、受注処理ひとつをとっても、
情報の入力→内容の確認→承認→次工程への連携

という一連の流れがあります。

このとき重要なのは、「各画面が正しく動くか」ではなく、「流れとしてスムーズに進むか」です。途中で何度も入力を求められたり、別の画面に行き来したり、判断に迷う場面が増えれば、それだけで体験は悪化します。

つまり、システムは機能単位で評価されるものではなく、「使い続けたくなるかどうか」という体験で評価されます。ここを見誤ると、どれだけ要望を満たしても現場に定着しません。

なぜ体験設計が抜け落ちるのか

ではなぜ、多くのシステム開発で体験設計が抜け落ちてしまうのでしょうか。

理由のひとつは、「要件定義の進め方」にあります。一般的な開発では、ヒアリングを通じて要望を整理し、それを仕様に落とし込んでいきます。このプロセス自体は間違いではありませんが、「要望の正しさ」を前提に進めてしまう点に課題があります。

本来は、「その要望がなぜ出てきたのか」「本当に解決したい課題は何か」を掘り下げる必要があります。しかし、納期やコストの制約、関係者の多さなどから、この工程が十分に行われないケースが少なくありません。

結果として、現場の業務全体を見渡した設計ではなく、「部分最適の積み重ね」になってしまいます。

パッケージでは解決できない限界

ここでよく検討されるのがパッケージ製品の導入です。しかし、体験設計という観点で見ると、パッケージには明確な限界があります。

パッケージは多くの企業に対応するため、標準的な業務フローを前提に作られています。そのため、自社特有の業務や細かな運用に合わせようとすると、カスタマイズが必要になります。

ただし、カスタマイズを重ねるほど、全体の整合性が取りづらくなり、結果として使いづらさが増すこともあります。また、対応できない部分については、現場側がシステムに合わせることを求められます。

このように、体験を最適化するための自由度が限られている点が、パッケージの大きな制約です。

【関連記事】
パッケージ開発とスクラッチ開発の違いとは？それぞれの特徴と適切な選び方について解説

フルスクラッチ開発が持つ意味

体験設計を重視する場合、フルスクラッチ開発には大きな意味があります。

フルスクラッチでは、既存の機能や画面に縛られることなく、業務の流れそのものから設計を行うことができます。つまり、「どのように使われるべきか」を起点にシステムを組み立てることが可能です。

例えば、入力の回数を減らす、判断に必要な情報をその場で提示する、次のアクションが自然に分かるようにするなど、体験を前提とした設計が実現できます。

これは単なる“自由度の高さ”ではなく、「使われるシステムを作るための前提条件」と言えます。

体験設計から始めるために必要な視点

では、体験設計を実現するためには、どのような視点が必要なのでしょうか。

まず重要なのは、「業務を分解して理解すること」です。どのような流れで作業が行われ、どこで負担や判断が発生しているのかを整理します。

次に、「その業務をどのように変えるべきか」を考えます。単に効率化するだけでなく、判断の質を高める、ミスを減らす、属人性を排除するなど、目指す状態を明確にすることが重要です。

そして最後に、「その状態を実現する体験は何か」を設計します。ここで初めて、機能や画面の検討に入るべきです。

この順序を逆にすると、再び“要望どおりだが使われない”システムに戻ってしまいます。

まとめ

システム開発において、「要望どおりに作ること」は重要ですが、それだけでは十分ではありません。ユーザーが実際に使うのは機能ではなく、一連の体験です。

体験を起点に設計されていないシステムは、たとえ仕様通りに完成していても現場に定着しません。この問題の本質は、技術や機能ではなく、設計の出発点にあります。

使われるシステムを実現するためには、「何を作るか」ではなく「どのように使われるか」から考えることが不可欠です。その視点が、これからのシステム開発の質を大きく左右します。

さいごに

ここまで見てきた通り、「要望どおりに作る」だけでは、現場で使われるシステムにはなりません。重要なのは、業務の流れや判断のあり方まで踏み込み、実際に使われる体験を前提に設計することです。

当社フレシット株式会社では、単にご要望を整理して開発するのではなく、「なぜその要望が出ているのか」「本来どうあるべきか」という段階からご一緒に検討します。業務の背景や運用まで含めて整理し、使われることを前提としたシステムをフルスクラッチで設計・開発しています。

既存のパッケージでは実現しきれない業務や、現在のシステムに違和感を感じている場合こそ、見直す価値があります。要望をそのまま形にするのではなく、本当に必要な体験を実現する。その一歩から、ご相談いただければと思います。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら