皆さん、こんにちは。
Story's代表の佐藤です。
本日のテーマは「要件定義 基本設計における成果物」について説明していきたいと思います。
今回も、私の10数年来のIT業界での知見を基にお話させていただきます。
私は以前から上流工程、要件定義や基本設計に関してのテーマを扱うことが多いです。
その中で実際に声として聞くことが多いのが要件定義や基本設計っていうフェーズの中で
「どういったものを作っていくのか？」について質問が多かったので、今回説明していこうと思います。
▼よろしければYouTubeもご覧ください！
要件定義基本設計における成果物について
勿論これから紹介することが全てではないですし、他にも細かいことを言うと本当に多種多様で、PJTによってやはり全然違います。
ただ多くは「作業していく中でこういうことが出てくるのではないか？」というところで、今回は代表的なものを挙げていきたいと思います。
成果物一覧
＜PJ計画書＞
最初に要件定義が始まる前に基本的に事業会社さんの方で、PJT計画書、通称「プロ計」と言いますが作られていると思います。
これを基に各システムベンダーさんが見積もりを作ったりしますが、PJT計画書は常にアップデートされるものだと思ってください。
要件定義、基本設計が進むにつれてアップデートがかかってきます。
<WBS>
WBSですが、プロジェクトマネジメント、「PM」と言われるポジションの方が作成するタスク管理です。
WBSをしっかりと整理したり、整理するだけではなく、それがきちんと機能するタスク管理ができるかということは、PJTを回していく上でかなり重要な要素になります。
ただPJTを回す際に、WBSを「そもそも引けない」、「整理できない」というPMが結構多いです。
また別のブログで説明しますが、これはかなり大事です。
＜マスタスケジュール＞
次にマスタスケジュールです。こちらもやはりPJTの全体像、大枠でのスケジュールを管理するものです。
例えば要件定義はいつからいつまで、基本設計はいつからいつまでとか、リリース/カットオーバーはいつになるのかなど、そこから逆算していくとどういったものをやっていくのかになると思います。
こちらも随時アップデートされるものだと思っておいていただければと思います。
＜要件一覧＞
要件一覧からはSEの方やディレクターの方が実際に作っていくことが多いです。
次に、要件一覧も事業会社さんの方で「こういった課題があるからこの業務をこんな風に変えたい」のようなことが要求事項として挙げてこられるケースが多いです。
それを例えばビジネス要件や機能要件のような形で整理してることを指しています。
こちらの要件一覧が後々の要件定義、基本設計の仕様を決めるところに、ものすごく大きく関わってくるのですごく大事です。
＜機能要件一覧＞
機能要件一覧はシステム開発PJTにおいて「こんな画面を作っていきたい、その画面においては、新規会員登録だったりログインがある」「ログインもこのシステムとの連携をする」などを記載したものです。
機能要件一覧の中に大体画面の一覧なども入ってくるため、それを基に「今回の画面遷移ってどういう風になるんだろう？」と特にスマホアプリだったりWebアプリといわれるフロント側を考えなければならない時にはものすごく大事になってくるものとなります。
＜画面遷移図＞
画面遷移図は色々な粒度で書かれることが多いです。
ものすごくラフに四角で「画面名」、「ホーム画面」とか一番最初はチュートリアルとかホームを立ち上げて「会員登録に進む」などです。
もちろん簡易版もありますし、ある程度のデザインを入れて、より分かり易く「画面のイメージがこうで、このボタンを押したらこっちに行く」みたいなところを細かく整理するケースと両方あります。
デザインがある方が分かりやすいですが、メンテナンスのしやすさって観点で言うと簡単に四角の方がやりやすいので、私は主に四角、簡略系でやることが多いです。
画面遷移図はいろんなところで使うケースが多いです。
実際、UI/UXの観点も必要になってくるので、実は「簡単じゃない？」って思うことが多いですが、ただ深いですね。
また別のブログで話せたらと思います。
＜画面定義書＞
画面定義書は基本設計の中でもすごく重要になる部分です。
基本設計、詳細設計っていう風に言われる中の一番最初のベースになる部分です。
粒度はそのPJTによって変わります。
フロント側がメインなのか、あるいはバックエンドがメインなのかで全然フォーマットも変わってきたりするので、自分がフロント側に立っているのか、それともバックエンドに立ってるのかというところも一つ重要な観点なのかなと思います。
画面定義書に関しては、システム知見もやはり大事になります。
事業会社さん、クライアントさんの業務的な要件とかUIの観点や使いやすさなどユーザ体験という部分もものすごく大事です。
それと同時に、システム知見が非常に必要になってくる部分なので、ここがきちんと自走してできるかというのは、「上流工程のSEをやる」とか「コンサルをやる」という風になった時は凄く大事になるのではと思います。
＜バリデーション＞
バリデーションとは画面定義書に対をなすものです。
システム構成図でアーキテクチャ一覧などと言ったりします。
インフラ周りだったりネットワークとか出てきますが、インフラエンジニアがやることが多いので割愛します。
＜シーケンス＞
アプリ開発においてシーケンスが書けるかどうか、整理できるかは非常に大事です。
私の経験上、シーケンスまでしっかりと書ける上流工程のエンジニアはあまりいないので、ものすごく差別化できます。
＜API一覧＞
最後にAPI一覧という形で、こちらも特にスマホアプリとかになってくるとものすごく重要になっていきます。
こういったところを整理できるといいのではないかと思います。
まとめ
駆け足ではありましたが、要件定義、基本設計における成果物、どういったものを作成していくかというところをあくまで一覧で出させていただきました。
「全部できなきゃ上流工程のSEができない」のかというと、そんなことはありません。
やはり得意不得意はありますし、大体担当をわけたりしますので大丈夫です。
ただ、どういったものなのかっていう全体像は知っておいたほうがいいと思います。
弊社のサービスで上流工程のドキュメントを用意しておりますので是非活用いただければなと思っております。
では本日のブログは以上となります。
また次回のブログでお会いしましょう。