【WEBディレクション】サイトを作る手順書その２【何求めて何得る？】
はじめに
本日は結構テクニカルな内容です。
なるべくわかりやすく説明するために、厳密には事実と違うことを記載する可能性があります。
なので、ここで概要をつかんだら、詳しい内容はキーワードを元に検索してみてください。
【キーワード】
・要求仕様
・要件定義
・ウォーターフォール
・アジャイル
・基本設計
・詳細設計
・WBS（ワークブレイクダウンストラクチャー）
設計図を作るまでの果てしない道のり
今日話すことはWEBサイトに限らず全てのシステム開発に共通の内容になります。
なので、一度覚えるといろんなところで応用が利きますのでぜひ最後までご覧ください。
皆さんは制作会社にWEB制作を頼む時にどんなふうに依頼していますか？
きちんとRFP作ってますか？ それとも要望だけ伝えて丸投げですか？
何かのシステムを作る時には、「作りたい側が何をどう作りたいか」を明確にすることが大事です。
それが無いと「なんか違うんだよな」というものが出来上がります。
いわゆる「顧客が本当に必要だったもの」が出来上がるわけです。
そして、お金をかけた割に良くないものができて運用もし辛く、ユーザーにとっても使いにくいものがリリースされる、と。
では、そういう事態を避けるために何をしなければいけないかを考えてみましょう。
一般的にシステム開発には下記の手順を辿ることが多いです。
１．RFP（提案依頼書）もしくは要求仕様書の提示
２．要求仕様書から要件定義を行い、要件定義書を作成する
３．要件定義書の確定
４．基本設計書の作成と確定
５．詳細設計所の作成と確定
６．システム実装
７．単体テスト
８．結合テスト
９．受入テスト
１０．セキュリティテスト
１１．リリース
アジャイルの場合はシステムの機能を細かく分けて（疎結合にして）３．から１１．を短い期間で繰り返します。
ここで大事なのは「ウォーターフォール（一度の実装で全てを作り切る）」でも「アジャイル（細かいリリースを繰り返す）」でもやることの基本は変わらない、ということです。
なんとなくアジャイルだと最低限の機能を素早くリリースする、という言葉だけが先行してしまって、その中のプロセスがおろそかになりがちですが、要件を最小単位に区切り、取捨選択することで開発プロセスを段階的に行うことがアジャイルです。
なので、段階ごとに機能の要件定義もしますし、テストもきちんと行う必要があります。
ただ機能自体が小規模ごとなので、素早いサイクルで回すことができる、というだけです。
これらの中でRFPと要求仕様は似ていますが、主にRFPはベンダーコンペする際に非機能要件以外についても記載するものです。
非機能要件とはシステムが満たす機能以外の要素のことで、例えば耐久性や可用性、セキュリティ要件、保守要件や目標リリース日程などです。
この要素は要求仕様を提示する場合でもどこかの段階で決める必要があるため、どちらにしろ考える必要はあります。
要求仕様って何でしょう？
要求仕様とはまさしく、依頼側が制作側に対して要求するものを定義したものです。
前回までに決めた内容の全てをここに入れます。
どんな名前のどんなサイトを作ろうとしているのか、それはどんな目的で、どのような機能が必要で、その機能はどのように動く必要があって……というようなことを記載します。ついでに言うと、必要なものだけでなくしてもらっては困ることも記載します。
例えば、ログインしたユーザーが他のユーザーのページを見れてはいけない、とか。
いま、「そんなの当たり前じゃん」と思いました？
その当たり前が開発の現場では通じないことがあります。というか通じないと思って記載しておかないと後で痛い目を見ます。
なので、要求仕様を制作会社に提示する際にはどのレベルの内容まで記載する必要があるか、記載のない項目についてはどのように取り扱うかを明記してもらいましょう。
口約束は反故になることが多いので、見積書や要件定義書、設計書などに記載してもらうのが良いと思います。
要件定義書は何か月？
要求定義書を提示したら、それを元に要件定義書を作成します。
この書類の作成は制作会社と一緒にする場合もあれば、要件定義のみを行うベンダーと一緒にやることもあります。制作会社の性質によりけりですね。
なので、制作会社に見積もりをお願いする際には「私たちは要件定義を行う経験値が無いのですが、御社主導で要件定義フェーズを行っていただくことは可能ですか」と聞いてみてください。
良いですよ、というところもあれば、間に入っていただくところがないと落とし込みができないです、と言われる場合もあります（実際にありました）。
この要件定義はシステムの出来に直結する大事なフェーズですから、手順を追って進めていきたいですね。
まずは、要求定義を読み起こし、不明な点、あいまいな点について書き出していきます。それが明らかになったら要求を機能ごとに分解します。違う画面でも同じ機能である場合もあったりするので、この辺の仕分けが制作会社の腕の見せ所ですね。
そして、機能ごとに「やりたいこと」「やれること」「やってはいけないこと」を洗い出していきます。
例えば要求に「AIによって関連記事を出す」と書いてあったとしても制作側は何を示しているのか分かりません。これを「記事内容を形態素解析してAIにラーニングさせ、情緒傾向が似た記事を優先的に関連記事として４本掲載し、ソートは新着順」などとします。これが「やりたいこと」、ですね。
ただし、工数、期間や予算の関係でこれらの機能を実現するには足りないため、「記事に情緒傾向を示すタグを付与するようにし、同じタグが付与された記事の中から新着順に関連記事として４本掲出する」としました。これが「やれること」です。
「やってはいけないこと」は「没済みの記事は表示しない」とか「広告記事は表示しない」など、取得条件の中でも除外する項目などを示します。
こんな風にやっていきますから、要求定義よりも時間がかかり気味です。一か月とかで要件定義をやってみたことがありますが、死にました。
システム規模にもよりますが、２～３ヶ月はかかると思ってよいのではないでしょうか。
小説で言うと序章が終わった感じ？
さあ、今までの段階でようやく「こういう風にシステムを作ろうかな」という概要が決まりました。
小説で言うと序章が終わった感じです。
ここから先はもっとテクニカルな内容になります。
要件定義が決まると、どのようなシステムをどのように作るかが決まります。
家で言うと、顧客の「こういう家を作りたい」から「こんな間取りで、トイレ、風呂、収納、キッチンではこんなことができればよいですよね」というものが出来上がりとしてイメージできるくらいになりました。
でも、まだその中身にどんな素材を使うか、メーカーはどこにするか、どんな順番で作っていくかなどは決まっていませんよね。
それらを決めるのが設計書です。
この段階になると顧客側はあまり口出しすることは無くなります。
どんな言語、フレームワークを使って、どこからどんなコード体系で作っていくかを記載します。各プログラム、APIの関係性や各ページのつながりなどが決まっていきます。
また、デザインについても並行して走っていき、モックやラフもこの辺りで作っていくことになるでしょう。
家で言うとカタログを見せられて、このドアはこのメーカーを使う予定です、どちらが良いですか？ とか、間取り図を書き始めましたがイメージと違うところはありますか？ など聞かれます。望めば素材が何なのか、寸法など細かいことを知ることもできるようになる段階です。
が、あまり素人が口を出せない部分でもあります。
それでも一読はしましょう。ここに記載され、了承したものはもう覆せません。何しろ設計図ですから、作り始めてから変えることができないのです。もし変えたとしても、すごく変なものが出来上がるのは分かりますよね？
このドアはやっぱり嫌だからこのでっかいやつに変えて。と言って枠を削ってしまえば、見るからにおかしいと感じるはずです。
この設計段階ではほぼ実際のコードが記述されます。
ですので、作りながら記述が精査、変更されていくこともあります。ですが、それは私たち素人が口を出すのと異なり、前進したりよりち密に作るための変更です。あまり問題視しないようにしましょう。
WBS（ワールドビジネスサテライトではないですよ）
さて、今回の最後はWBSです。
Work Breakdown Structureの略で、システム開発の各項目をスケジュールに起こした、いわばガントチャートのようなものです。
詳しくはこちらです。
要するにそれを見れば、制作会社がいつどんな作業をやる予定で、その責任者は誰で、ということが分かるわけです。
この進捗を見ていれば、仮に遅れが出ていても何が原因で遅れてて、それは解消できそうなのか順次最後まで遅れるのかがよく分かります。
つまり、WBSに記載されているのはあくまで予定です。
特に長いプロジェクトになるほど精度は上がらないと考えてよいと思います。
あくまで順調にいった場合の想定スケジュールなので、これを絶対値として「遅れたから責任を取れ」というのはナンセンスです。
WBSはシステム開発の関連性と進捗度合いを測るためのものでスケジュールの約束ではないことをよく覚えておきましょう。この辺りでトラブルが発生することはよくあります。
最後に
いかがでしたでしょうか？
今回はテクニカルだし、一つずつの項目とっても二時間は喋れる内容です。
なのでかなり簡易的に書きました。
詳細が記述されたリンクも貼っていますので、より詳しく知りたい人はそちらをご覧ください。
この回で私が言いたいのは、発注したからすぐに作り始めるのではなく、その前に設計書を作り、さらにそれを作るためのヒアリングや認識合わせの作業が数か月単位で発生するということです。
これらを頭に入れて全体のスケジュール（ひいてはリリース日）を決めるのと、入れなくてスケジュールを決めるのでは大幅に結果が変わってきます。
あなたのWEBサイトライフがより良いものであるように、決して焦らず、全体感を頭に入れながら進めていってください。
では、また次の回で。
読んでみてお気に召したら「スキ」をお願いします。次も頑張れますので。
いいなと思ったら応援しよう！
