- システム開発の流れを経営者向けに解説！ 〜発注前に知っておきたい5つの基本工程〜
- 要件定義の失敗が後悔を生む理由とは？ 〜発注前に絶対に押さえておきたい、最初の“落とし穴”〜
- 設計と開発の違い、分かりますか？ 〜トラブルを防ぐ“確認のタイミング”とは〜
Contents
はじめに：そのまま開発に入ってませんか？
要件定義が終わったら、いよいよ開発スタート！……と思っていませんか？
でもちょっと待ってください。
実はその前に、とても重要なステップがあります。
それが「設計」です。
設計を飛ばして開発を進めてしまうと、
「思っていたものと違う…」
「操作しにくい…」
「やり直しが発生してコストが増えた…」
そんな事態になりかねません。
今回は、設計と開発（実装）の違いを明確にしながら、経営者がどこで関与すべきかを解説していきます。
設計とは？「どう作るか」を決める工程
要件定義で「何を作るか」が決まったら、次は「どうやって作るか？」を設計で決めていきます。
ここでは主に以下のようなことを整理します。
-
各画面のレイアウト（ワイヤーフレーム）
-
ボタンの配置や入力項目
-
データの流れや連携の仕組み
-
各機能の動作ルール
たとえば「顧客管理システムを作る」としても、
「どんな画面構成で、どこから検索できて、どうやって編集するのか」など、具体的な体験を想定して設計します。
設計が甘いと、なぜ失敗する？
ケース①：完成した画面が「想像と違う」
設計段階でワイヤーフレームや画面サンプルを確認せずに進めると、「なんか違う…」というズレが発生しやすくなります。
このズレを放置して開発が進むと、修正に大きな工数がかかることに。
※画面設計のやり直しは、開発者にとっても重たい作業です。
ケース②：「不要な機能」が混ざってコスト増
設計フェーズで提案された機能を深く考えずにそのまま承認してしまうと、実際には使わない機能まで作ることになってしまいます。
「かっこよくて便利そうだけど、うちの業務では使わない…」
そうした機能が混ざると、無駄な開発コストが発生します。
ケース③：ユーザーが“使いづらい”と感じる
どんなに機能が充実していても、使いづらいシステムは現場に浸透しません。
「UI（見た目）」と「UX（使い勝手）」を無視した設計では、せっかく作ったシステムが“使われない箱”になってしまうのです。
経営者が「設計」で見るべき3つのポイント
1. ワイヤーフレームは直感的に使えそうか？
-
現場スタッフが迷わず操作できそうか
-
無駄なクリックや複雑な手順がないか
-
モバイル対応など必要な環境に合っているか
設計図を見るときは「自分が初めて使うユーザー」のつもりでチェックするのがポイントです。
2. 目的からブレていないか？
設計を見て「何となく機能が増えている」と感じたら、目的に立ち返って再確認しましょう。
「この機能は、最初に話していた課題解決につながるか？」
「なくても目的が達成できるなら、削れないか？」
を冷静に判断することで、コスト削減にもつながります。
3. 社内の運用フローにフィットしているか？
-
複数人で使う場合、作業の重複は起きないか？
-
入力やチェックの手順が現場の動きと合っているか？
-
使う部署・使う人にとって負担にならないか？
このような視点は、現場を知る経営者だからこそ持てる重要な観点です。
開発（実装）とは？設計通りに“形にする”工程
設計が固まったら、いよいよプログラミングを行って、システムを形にしていきます。
ここからが「開発（実装）」フェーズです。
「少しの修正」でも意外と時間がかかる理由
発注側からすると、「ボタンの位置を変えるだけ」「入力項目を1つ増やすだけ」といった修正は簡単に見えるかもしれません。
ですが、実際は…
-
プログラムの修正
-
全体の動作チェック
-
テストのやり直し
-
影響範囲の再確認
…と、見えない作業がたくさん発生します。
そのため、開発フェーズに入ってからの変更は慎重に判断する必要があります。
開発者との信頼関係を築くヒント
-
設計段階で疑問があれば遠慮せずに質問する
-
「何となく違和感がある」ことも早めに伝える
-
社内で確認が必要なときはスケジュールを共有する
発注者と開発者は“片側だけで進める関係”ではありません。
対等なパートナーとして、お互いに確認し合う姿勢が良いシステムを生み出します。
次回予告：テスト工程を軽く見ると危険！
次回は、意外と軽視されがちな「テスト工程」について。
-
テストって何をするの？
-
なぜ時間がかかるの？
-
バグはどうやって見つける？
-
発注者は何を意識すべき？
システムの品質を左右するテストの重要性について、わかりやすくお伝えします！
コメント