第4回　「概要検討書」をまとめる

前回の振り返り
　前回までに、「要件整理」まで実施しました。今回は、要件とまとめて、概要検討書として取りまとめる部分について記載していきます。

「概要検討書」とは
　「概要検討書」とは、ここまで要件整理を行ってきた成果物を「概要検討書」としてまとめたものを指します。ここで紹介する概要検討書の目次や、書き方については、これまでの経験をベースに「私流」にまとめたものになります。要求定義や要求仕様書という名前で呼ばれることが多いかもしれません。

　よりプロジェクトメンバーが理解しやすく、またこの概要検討書をベースに、開発会社とも会話が出来、同じ方向性を持って進められることを目的としております。そのため、IPAやその他機関が定義しているものとは異なる部分がありますので、その点考慮いただきますようお願いいたします。

目次を考える
　　目次としては、下記の3部構成で考えていきます。必要最低限かつ、必須のものを記載する形で進めていきます。概要検討書をしっかり作り込んでおくと、要件定義や、設計の際に認識の齟齬やズレが発生しにくくなります。非常に大切なステップです。

【要件整理のポイント】
　①　概要
　　　・プロジェクトの背景や目的、ゴールについて明確に記載します。
　②　ビジネスモデル
　　　・今まで作成してきた、業務フローや、業務の要件等を記載します。
　③　プロジェクト運営
　　　・プロジェクトのスケジュールや、体制等について明確化します。

①　「概要」についてまとめる。
　「概要」の目次では、なぜこのプロジェクトが発足して、どのような目的を持っているのか。最終的なゴールはここで、そこに対してどのようなステップを踏んで進めていきたいか。について記載します。

　この「概要」の章は、実は概要検討書の中でもかなり重要な部分になります。目的とゴールの定まっていないプロジェクトは途中で迷走が始まり、当初思い描いていたものを、実際に出来上がるものが全然違う、意図しないものになってしまう可能性があります。

　プロジェクトメンバー内での認識共有はもちろんですが、開発会社との認識共有を図ることも目的としています。そんな中でも一番重要なのは、プロジェクトメンバー以外の社内での認識共有を図る。ことです。特に、上長や決裁者に対してプロジェクトの目的とゴールを正確に認識してもらうことは非常に重要です。

②　「ビジネスモデル」についてまとめる。
　ここでは、今までバラバラと作成してきた、業務フローや、業務の要件をまとめた資料についてまとめていきます。

　この章で重要になってくるのは、業務要件と機能要件です。一般的には、要件定義時に取りまとめることが多いですが、私は概要検討書の段階でまとめていきます。ここまでやっておくと、開発会社会社からの、提案も、見積もりもより精緻で良いものが出てきます。

　業務要件とは、システム化の対象となる業務の流れを明確化したものです。これまでの流れの中で、現状の業務フローをベースに、将来の業務フローを作成してきました。こんかい構築するシステムを利用して、どのように業務を回していきたいかを記載した、将来の業務フローがまさに業務要件の塊です。

　対して、機能要件とは、システムの機能や動作、振る舞いを定義したものです。どんな情報を取り扱い、何を行うのか、利用者や外部システムに対してどのように振る舞うのかといったことを定めるものです。簡単に言うと、システムの機能について、やりたいこと、出来るべきことをまとめます。
例えば、下記の画像では、前回の連載時に、1要件ずつ、画面イメージまで作成したものを記載していきました。これも機能要件の一部として捉えられます。

【要件詳細ページイメージ】

　また、下記はバック側(管理側)の機能についてまとめた一覧になります。管理画面で管理者がどんな振る舞いをして、なにを実行したいのかをまとめています。

【バック側(管理側)の機能一覧ページイメージ】

　この後の工程の要件定義でも、より詳細の業務要件、機能要件の設計を行います。概要検討書の段階で重要なのは、要件定義を円滑に、よりイメージをすり合わせて実施するための、ベース資料として作成することです。ここでしっかりイメージを作っておけば、要件定義でも失敗することは無いでしょう。

③　プロジェクト運営
　プロジェクト運営はいたってシンプルですが、非常に重要な章です。現時点でのリリーススケジュールを作成し、プロジェクトの体制図を記載します。シンプルですが、今後のプロジェクト運営はこれをベースに行います。

　体制図がコロコロ変わってしまうプロジェクトはいいプロジェクトではありません。コロコロ変わってしまう前提で推進してしまうので、メンバーに当事者意識が薄れ、どこか他人事として捉えてしまう傾向があります。
プロジェクトの体制は一度決めたら、よっぽどのトラブルが発生しない限り変更しないほうが良いと考えております。メンバーの当事者意識を芽生えさせ、自分ごととして真剣に取り組める環境を作ってあげることが重要です。

◆　最後に
　稚拙な文章にもかかわらず、ここまでお読みいただきましてありがとうございます。ここに連載してきた内容は、私の経験と諸先輩方のアドバイスを元に書かせていただきました。もっとこうした方がいいよ。とか、ここ間違っている、こうすべきだ！というようなご意見、ご感想も是非いただけますと幸いでございます。

　また、連載の都合上、表面部分しか書けていない部分も多くあります。もっと詳しく、細かい部分まで知りたい。という場合は個別にフェイスブック等にご連絡ください。別途対応をさせていただきたいと思います。

　連載はこれにて終了となります。お読みいただきまして、ありがとうございます。

島津　将吾（Shogo Shimazu）
大学にてマーケティング戦略を学び、産学連携PJ等で実際のビジネスでの実践を経験。UNIQLOでのアルバイト経験により小売業の面白さに目覚める。大学卒業後はこれからはデジタルの時代であると考え、ネット小売業の（株）セブン・ネットショッピングに入社。管理業務やカスタマーサポート、マーケティング業務を担当し、その後、オムニチャネルプロジェクトに参画。「omni7」サイト構築に構想段階から関わり、リリースまで担当。2017年8月に（株）デジタルシフトウェーブに転職。現在は、主にデジタルシフトのための業務改革をご支援している。

★この著者の連載
デジタルシフトのための「業務フロー図作成入門」

▼お問合せやセミナーのご依頼はこちらまでお気軽にご連絡ください。

▼デジタルシフト実践者から学ぶ「デジタルシフト塾」塾生募集中です。