システムの構造や実装方針を決定し，アプリケーションの機能，データ，画面などを定義する「基本設計」。ITエンジニアの「コア中のコア」と言えるスキルだが，「最近弱体化している」と指摘する声が増えている。今こそすべてのITエンジニアが，ユーザーの高品質，短納期の要求に応えるために，「基本設計」のスキルを改めて見直すべきだ。
「ベテランのエンジニアは基本設計の一般的な手順は理解しているが，高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方，若手エンジニアは実装技術には詳しいものの，肝心の基本設計の基礎的な方法論を理解していないことが多い」――。
こうした悩みは，多くの開発現場に共通する。これは，基本設計そのものが難しくなっているからにほかならない（図1）。
メインフレーム時代は，ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基本設計をこなせた。しかし，システムがオープン化した現在は，膨大な技術・製品を組み合わせて最適な設計をする必要がある。その分，基本設計の難度は上がっている。
さらに，ユーザー側の環境変化のスピードが速い，システムがビジネスそのものと一体化している――などの理由により，基本設計の入力情報，すなわち要件定義で作成する機能要件や非機能要件，制約条件もあいまいになっている。
要件定義があいまいな場合，要件定義書の内容を基本設計で改めて明確にする必要がある。その分，基本設計の仕事量は増えるし，要件を明確化するには業種・業務知識が必要になるため，必然的に基本設計の難度は上がる。
さらに，組織横断型のシステムが増えたことで，多くのステークホルダー（利害関係者）との仕様調整が発生。このことも基本設計を複雑化させている。加えて，設計書そのものをより詳細に記述する必要も出てきた。詳細設計やプログラミングなどの作業を海外に委託するオフショア開発が増えてきたからだ。
このように基本設計は複雑化する一方だが，「ITエンジニアの基本設計のスキルはむしろ低下している」と指摘する声は多い。大規模な新規開発案件が減少し，代わりに保守案件や中小規模のWebシステムの開発案件が増えたからだ。このため，きちんとした基本設計を実施する機会が減った。
多岐にわたる基本設計の範囲
ここまで，「基本設計」という言葉を説明なしで使ってきたが，そもそも基本設計とはどこまでの範囲を指すのだろうか。“釈迦に説法”かもしれないが，ここで基本設計の定義を改めて説明しておこう（図2）。
一般的なシステム開発では，「要件定義」，「基本設計（外部設計とも呼ぶ）」，「詳細設計（内部設計とも呼ぶ）」，「プログラミング／単体テスト」，「結合テスト」，「システムテスト」などのフェーズから成る。
このうち「基本設計」では，要件定義フェーズの成果物である機能要件，非機能要件，制約条件に基づいて，「方式設計（アーキテクチャ設計）」と「機能設計（アプリケーション設計）」を実施する。
方式設計は，ハード／ソフトの構造（アーキテクチャ）や実装方針を決める作業である。例えば，ハードウエアやミドルウエア，フレームワークといったシステム基盤，アプリケーション全体の構造，開発標準やテスト方式などを設計する。一方の機能設計では，アプリケーションとして実装する機能やデータベース，画面や帳票などを設計する。
基本設計ではこのほか，システムの非機能要件で定義されたパフォーマンスや可用性などを満たすための性能・信頼性設計や，不正アクセスや情報漏えい対策といったセキュリティ設計，新システムへの移行方法を定義する移行設計，業務とシステムの両面から運用方法を決定する運用設計なども実施する。
