フェーズ跨ぎのトリセツ 詳細設計→外部設計 （前編）

今回の記事は、僕がシステムエンジニアになるために、おそらく一番苦労したことなので、要点だけ伝えるのではなく長文（ストーリー）となりますが、お付き合いください。

僕の経験上、コーディング→詳細設計のフェーズ跨ぎは難なく進めれるため、その流れでプログラム→詳細設計→外部設計は地続きであると思って、外部設計へ突き進むと大きめの落とし穴があります。

詳細設計と外部設計の作業の違いは、以下の通り考えるか、編集するかの違いだと思ってます。
・詳細設計：どうやって作るかを考える作業
・外部設計：何を作るかをまとめる（編集する）作業

▼内部設計の進め方とは
内部設計では、外部設計で何を作るかという仕様がまとまっているので、必要な情報はすべて揃ってます。仮に仕様漏れや、条件が曖昧なところがあれば、外部設計の担当者に問い合わせすれば回答がもらえることでしょう。そうやって外部設計書をもとに、コーディングを意識しながら、どう作るかを考えて内部設計書をつくります。要は、手持ちの情報を信頼して、コーディングを意識して、どう作るかを考える作業です。

▼外部設計を同じ進め方をすると失敗する
外部設計を詳細設計と同じスタンスで進めるとどうなるか、僕の経験上の話をすると、手持ちの情報を信頼にして、それ以外の情報は自分なりに考えるのですが、たいがい正解（根拠）が見つからないため考え込んで、たいがい進捗が遅れて高稼働になります。そんな状況で出来上がった設計書をお客さまにレビューしていただくと、自分なりに考えたところをことごとく指摘されて、萎縮してしまい、言われるがままに指摘を修正することになります。

▼失敗することはわかったけど、その原因がわからなかった
上流フェーズでは業務知識が必要というバイアスがかかっていたため、業務知識さえ深めれば改善されるだろうなぐらいに安易に思っていました。そんな想いと裏腹に、さまざまな業務システムのプロジェクトのアサインされるため、業務知識を深めるどころか、浅く広がっていくだけで、改善の糸口がつかめない状況が続きました。そんな辛い状況が、ざっと10年続きました。

後編へ続く