さて今回は
「プロが教える超ざっくりシステム開発」
の外部設計編となります。
要件定義をまだご覧になっていな方は以下をご覧ください。
みなさんこんにちは。今回は、プロジェクトの成否がほぼ決まるといっても過言ではない「要件定義」という工程について、3回に分けてお伝えしようと思います。要件定義の前工程に要求定義という工程があったりもしますが、要求を整理して …
外部設計って?
外部設計は一般的には「基本設計」と呼ぶことも多く、その呼称は多くベンダーによりけりです。
この外部設計は、乱暴に一言で言うと「システムの外側」を設計します。
「外側」って?
お客様視点でお伝えすると、
・画面のレイアウトやデザイン、表示する項目や機能・操作性
・帳票のレイアウト、表示する項目や帳票形式
・ファイルの項目や形式
などが分かりやすいかと思います。
お客様に主に意識いただくことは、ユーザーから見える部分の仕様を決める工程です。
要件定義で決めた「機能要件」に従い、弊社からのご提案
あるいはお客様の考えや希望をもとにして、双方で相談しながら仕様を決定していく工程です。
そのほかにも、要件定義で決めた「非機能要件」をもとにして
・システムのアーキテクチャ
・認証方式
など専門的な設計、あるいは要件定義で決めた運用要件、移行要件(いずれも非機能要件ですが)に従い
・運用設計
・移行設計
なども行います。
これら設計については、別の機会で説明できればと思いますので
「超ざっくり編」のここでは割愛したいと思います。
機能要件、非機能要件についてはこちらをご覧ください。
前回に引き続き、要件定義についてお伝えしていきます。お伝えしたいポイントを中心に書いていますので、よく目にする情報・当たり前のことなどは、さらっと、書いてしまっていますがご了承ください。では、早速要件定義の主なタスクを一 …
こちらのブログでも触れております。
さて今回は「プロが教える超ざっくりシステム開発」の総合テスト編となります。総合テストの前工程をまだご覧になっていない方はこちらをご覧ください。 総合テストって何やるの? 総合テストは、すべてのソフトウェア、ハードウェアな …
ITやシステムの専門知識をお持ちでなくても安心
仕様を決定していくにあたっては、我々がリードしていきますので専門知識がなくてもご心配は不要です。
要件定義工程で必要な画面、帳票はある程度定義できているのが理想です。
(我々は基本的にはそのような進め方をしています)
そのほうが、開発工程に必要な予算を精度高く見積もることができます。
ここでは、機能も帳票もほぼ出揃っている前提で話を進めていきます。
それではまず、画面の仕様を決めていく流れをご説明します。
画面で必要な機能(操作)と画面項目を決める
それでは「案件を管理する機能」を例として説明していきます。
・しばらく受注に至っていない案件に対して、営業戦略を検討したい
・案件の受注金額を変更したい
などが目的の一つになるかと思います。
また、業務の生産性を考えると「案件の検索」も必要となります。
案件を検索⇒案件を確認・編集
などの手順で案件を絞り込むのが良さそうです。
ということで、検索もできたほうがいいですね。
案件の削除や案件の編集画面へも遷移できたら便利ですね。
また、何のためにどんな項目を画面で確認して業務を進めていきたいかを考えつつ
画面に表示する項目を決定していきます。
ベタベタですが(汗)
・顧客名
・案件名
・案件のステータス
などは少なくとも必要になります。
画面レイアウト、項目の仕様詳細を決定する
この辺を決定したところで、画面レイアウトを決めていきます。
お客様でイメージがあればそれをベースに仕様を決定していきますし、
イメージをお持ちでないようであれば、我々から画面レイアウトのご提案をさせていただきます。
我々のほうでエクセルで画面イメージを作成することで、空中戦を避け、同じ認識のもと議論・検討ができるようにします。
次は、そのレイアウト図をベースに
・画面項目(どんな項目を表示するか)
・画面レイアウト
・操作性
をお客様と気になる点や一般論等交え、相談・検討していきます。
そして、最終的な仕様を決めるのはお客様自身となります。
ここまでくれば、あとは画面項目の
・桁数
・表示形式
・表示順(ソート)
など細かいことを決めれば、画面仕様(外部設計)の完了です!
帳票の仕様を決めていきましょう
次は帳票です。
こちらも進め方は画面と同様になります。
既存の帳票を踏襲したいのであれば、そのようにしますし、
刷新、改善したいのであれば、レイアウトや項目を決めていきます。
あとは、PDFにするのか、エクセル形式でダウンロードするのかなども外部設計で決定します。
方式によっては開発費用に影響が出る場合もあります。
それは画面も同様です。
難しい操作や一般的ではないリッチな操作性など、当初の予算に収まりそうにない場合は、
お客様と相談・調整しながら仕様を詰めていきます。
設計が終わった後に「この仕様では予算を上回ってしまいます」なんて心配はありません。
QAや課題(ご検討いただくこと)も同時に解決していきましょう
設計を進めていくと我々からの確認事項や、お客様の判断が必要になる場合が多々出てきます。
週次の打ち合わせ等による解消では進捗が出ず、スケジュールにも影響を与えることがありますので
打ち合わせ以外でも、QAや確認事項のやりとりをさせていただいています。
エクセルを使っての確認だったり、TeamsやSlackなどのコミュニケーションツール、Backlogなどのサービスなど
方法は様々ですが、漏らすことなくしっかりと管理していく必要があります。
ですので、お客様は我々との打ち合わせ時間以外でも、このようなやり取りや考える時間が必要になります。
#要件定義のところでは記載していませんでしたが、要件定義工程でも同様です。
このように、外部設計工程まではお客様にもまだまだご協力いただきながら進める必要があります。
さいごに
外部設計はこれだけではなく、先にあげた運用設計・移行設計、アーキテクチャ設計、
に加え、データの設計などシステムの特性や環境、条件によりいろいろな設計があります。
運用設計などもお客様に関わる大切な設計ではありますが
今回は、発注者が特に気にするであろう、システムの見える部分の設計のお話としました。
このあとの工程は、我々ベンダーで進めていきます。
が、
必要に応じて進捗報告や課題報告も差し上げますし、仕様調整が必要だったりと
お客さまとはコミュニケーションを継続しつつ、工程を進めていくことになります。
次工程以降は当面、お客様の時間を頂戴することなく進めていくことのできる内部設計以降について、軽く触れていきたいと思います。
次の工程はこちらどうぞ。
システム開発工程の内部設計工程でどんなことをしているのか、発注者が協力することはあるか、などを説明しています。
こちらもおすすめです。
「システム開発」と聞いて、具体的にイメージできない方(がほとんどだと思いますが・・・)にはぜひ読んでほしいので、何回かに分けて説明していきたいと思います。我々は「システムインテグレーション」「システム開発」を主な商いにし …