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

▼前編のあらすじ
意気揚々と詳細設計から外部設計へ進んだのですが、手持ちの情報だけでは判断できないことがあると、考え込む時間が多くなり、進捗が遅れて高稼働になっていきました。何とかつくった設計書をお客さまにレビューしていただくと、指摘事項が多く、次第に意気消沈。
業務知識が深まれば改善できると思ったが、同じ業務システムのアサインされることはなかったため、業務知識を深めるどころか、浅く広がっていくだけで、改善の糸口がつかめない辛い状況が10年続きました。

▼改善のきっかけは後輩でした
そんな状況で、プロジェクト「EDIシステム 流通BMS化対応（Linux/Java）」に外部設計フェーズからアサインされました。
そのプロジェクトもEDIシステム未経験、流通業務も未経験、さらに開発言語であるJavaでの開発も未経験という、未経験づくしの案件にさらに、その当時2年目のほぼ開発未経験の後輩と一緒にアサインされて、不安でしかありませんでした。僕ひとりだったら、これまで通りのスタンス（レビューで指摘されて修正する）だったと思いますが、さすがに2年目の後輩に、そのようなダサい姿を見せたくなかったし、辛い経験をさせたくなかったので、要件定義書などプロジェクトに関するドキュメントを引っ張り出して、後輩に説明しようと考えました。
まずは要件定義書から全体のコンセプト（世界観）を捉えた上で、システム構成、インプット、アウトプット、インターフェース、データーベース、ジョブスケジュール、バックアップ、トラブル時のリカバリ方法など、ありとあらゆる情報を入手しました。
そして後輩に説明するために、入手した情報の辻褄を合わせていく過程（注釈1）で、所どころ整合性が合わなかったり、足りない情報があったので、担当者の方に確認を取りながら補完する作業も行いました。
注釈1：インプット→画面レイアウト→データベース、アウトプット→インターフェース→ジョブスケジュール→他システムに連携など

▼何をやったのか整理すると
やったことを整理すると大きく４つあります
・ありとあらゆる情報をかき集めた
・僕が欲しい情報を相手から引き出した
・情報をつなぎ合わせて、整合性を合わせた
・足りない情報を担当者に問い合わせして補完して行った

その結果得たものは大きく３つあります
・システム全体を俯瞰的に見るようになったこと
・ひとつひとつの情報の根拠が明確になったこと
・たとえ自分に業務知識がなくても、担当者の方が持っている「業務知識をシェア」できることがわかった

上記作業を後輩にも手伝ってもらって一緒にやることができたので、後輩もシステム全体を理解できて、担当者の方との距離も縮めることができて、その後の作業はスムーズで行うことができました。僕自身も外部設計では品質の高い設計書を作ることができて、お客さまから信頼を得て、開発リーダーを任されたりしました。

何ら特別なことはやっていないが、以下のとおり意識が変わり、１段ギアがアップした気がします。
・分からないことを認めたこと（自分が答えを持っていないため）
・考え込むぐらいなら、さっさと行動して、情報をかき集めるようになったこと
・相手と対話することを躊躇しなくなったこと
・業務知識は深めるのではなく「シェア」すること

▼外部設計の戦術とは
ステップ1：情報収集
・実行力とコミュニケーション能力で、ありとあらゆる情報をかき集めること
例）要件定義：要件定義書、システム構成、インプット、アウトプット、インタフェース、
データーベース、ジョブ（タスク）スケジュール、バックアップ、トラブル時のリカバリ方法

ステップ2：編集作業
・要件定義書を読み込んでシステムのコンセプト（世界観）を捉える
・上記でかき集めたあらゆる情報を整合性を合わせていく
・整合性が合わなければ、担当者を見つけてに問い合わせて調整する
・足りない情報があれば、それも担当者をを見つけて補完していく

ステップ3：業務知識はシェアする
外部設計において業務知識はお客さまとシェアすること

▼まとめ
詳細設計と外部設計は以下の通り「考える」か「編集する」かの違いがあり、地続きてないことを認識すること。
・詳細設計：どうやって作るかを考える作業
・外部設計：何を作るかをまとめる（編集する）作業
そして、外部設計は以下の3つのステップで進めると、高品質の設計書に仕上がり、自信を持って後続の詳細設計へ引き渡すことができます。
・ステップ1：情報収集
・ステップ2：編集作業
・ステップ3：業務知識はシェアする