第1回 お客様のご要望を形にしてみましょう
今回の記事を読まれている方は、何かしらの形でIT業界に携わる皆さんだと思います。 今、どのような作業に取り組まれているところでしょうか？
リーダーに指示されて、ある機能のプログラミングをしているところでしょうか？
あるいは、テスト設計書を渡されて、テストデータを作ったり、実際にテストをしたりしているところでしょうか？
皆さんが担当している作業は、システム開発全体の作業工程における、ほんの一部に過ぎません。
このコーナーでは、システム開発の工程である「設計」→「製造」→「テスト」の概要を学んでいただきます。
興味を持っていただいた工程を深掘りして学んで頂き、今後のキャリアプランにぜひご活用いただければと思います。
システム開発の流れを体験してみよう！
-
第1回：
お客様のご要望をヒアリングし、システム概要にしていくまでの過程を学びます。この回では、要件定義から各種設計に至るまでの過程が学べます。 -
第2回：
第1回目でヒアリングしたお客様のご要望の中から、ある機能をピックアップしていきます。この回では、製造やユニットテストの流れと勘所が学べます。 -
第3回：
1?2回目の総括として、実装したプログラムがお客様の要件を満たしているかのテストを行います。この回では結合テスト、総合テストなどのテスト工程の説明やテスト設計について解説します。
お客様先へ訪問し、要件をヒアリングしてみましょう
あなたは、ソフトウェア会社「MKテクノロジーサービス」に勤めるエンジニアです。あなたの会社の営業部に、とあるスポーツメーカーからシステム開発の依頼がありました。 それでは早速、あなたの会社の営業担当である山本さんと一緒に、お客様先へヒアリングに行ってみましょう！
システム開発の目的は、お客様のかかえている問題や課題をシステムによって解決することです。 そのため、最初の一歩は「お客様がどのような問題や課題をかかえているのか？」を明らかにすることです。そして、「明らかになった問題や課題を解決するためには、システムにどのような機能が必要なのか？」を考えることにあります。
お客様の抱えている問題や課題をどうすれば解決できるのかという点に注力しながら、会話に耳を傾けてみましょう。
＜会社概要＞
社名： Typeスポーツ株式会社
事業内容： 各種スポーツ用品、サプリメントの製造、開発および販売。アスリートのプロモーションやパフォーマンスディレクション。
年商： 500億円
社員数： 300名
お客様の担当者： 樋口 健介様（スポーツシューズ販売部 部長）、菊池 圭一郎様（IT部 主任）
＜山本さんからの事前情報メモ＞
Typeスポーツ株式会社様は、スポーツ用品販売をメインとする外資系企業。直営店と大手ショッピングモールへ販売店を展開している。外資系企業であるが、システムや運営はそれぞれの国に任されている。日本も独自に行っているものの、部署間のつながりは薄い。
既存の顧客管理・販促システムを保有している。今回は、そのうちのシューズ専用ECサイトをリニューアルしたいとのこと。現在のECサイトは、商品の紹介、購入のみであるが、顧客の年齢層や性別などを分析し、販促活動につなげたい思惑があるようだ。
樋口様はスポーツシューズ販売部長で、今回のプロジェクトのキーマンであり、予算の決裁権をもつ。菊池様はIT部の主任で、技術に関する窓口担当を任されている。現時点では受注はほぼ取れそうであるが、予算確保が余り期待できないため、システム運用の軽減化や既成のツールやフレームワークも積極的に取り入れた提案をしてほしい様子。
＜お客様とあなたの会話＞
あなた：弊社山本より、御社のシューズ専用ECサイトをリニューアルしたいと伺っています。現在のサイトで問題や課題だと感じられている点がございましたら、お聞かせ頂けますでしょうか？
樋口様：購入履歴が上手く利用されていなくて、どんなお客さんがどのシューズを買いたいのか傾向がつかめなくてね。うちはスポーツ用品をトータルで扱っているから、シューズだけじゃなくて、他の商品の売上アップも狙っていきたいんですわ。
あなた：となると、シューズ専用のECサイト、というよりは取り扱う商材をサイト内で増やしたいということでしょうか？
樋口様：う?ん、それともまた違うなぁ。例えば、ランニングシューズを頻繁に買う人は、ジャージやランニング用アクセサリを買う可能性も高いわけじゃない？ あと、お客様の年齢層とか、男性か女性の違いとか。
あなた：購買層によってターゲットを絞りこみ、シューズと併せて他商品への導線を作りたいという事でしょうか？
樋口様：そうそう！一応、他の商品を扱うサイトは別にあるから、うちのシューズ専用サイトに他の商品を載せて動きが重いサイトにはしたくないんだよね。
あなた：そうなると、他商材をこちらのサイトでお客様に自ら検索させて選ばせるというよりは、「他のお客様はこんな商品を買っています」といった画像や案内が表示される方がよいですね。
菊池様：はい、リコメンド機能を追加して欲しいです。
あなた：そういえば、御社は顧客管理システムをお持ちではなかったでしょうか？
菊池様：一応、あるにはあるのですが、販売店で購入された店舗会員の情報だけが管理されていまして、サイト側と連携がされていないのです。サイト会員は、個別にデータがありまして……。
樋口様：顧客情報は、どの販促サイトも販売店でも一元的に管理したいんだよ。そうすればうちのサイト会員だけではなくて、販売店のお客様も販促対象としてキャンペーンを打てるし、何かと便利だからさ。
菊池様：あと、現在の顧客情報なのですが、現在のシステムのデータですと購入履歴や趣味などの属性情報は非常に貧弱でして……。
あなた：そうなると、現行の顧客管理システムへのデータ連携と併せて、属性情報を持たせる機能も必要ですね。データのテーブル設計変更と併せて、会員情報登録の機能も加わります。また、個人情報取り扱いの都合上、販売店で管理されている顧客情報を取り込む際は、お客様の許諾が必要です。
樋口様：えっ、何かと面倒だね。これは販売店を管理している部署と相談するよ。どちらにせよ、顧客情報システムとの連携は必須でお願いしたい。あと、最近、顧客情報の漏えいとかのニュースが多いけど、そういうことが起きないように頼むよ！
あなた：はい。では、御社で実際にご確認頂きたい点について、後程メールでお送りさせて頂きますので、関係部門様でご確認いただければと思います。
菊池様：あの……販促導線になる機能は、御社がスクラッチで開発されますか？
山本さん：他社製品を導入した場合と新規作成した場合で工数と費用を比較しますので、持ち帰り検討の上、再度提案させて頂けますでしょうか？
菊池様：わかりました。
あなた：他にご要望はございますか？
菊池様：サイト会員様から、画面のポップアップが非常に多くてわかりづらいというご要望が多々ありまして……。決済処理までをもう少し簡略化する改修も併せてお願いしたいです。
あなた：わかりました。画面遷移に伴って画面のレイアウトも変わることになりますが宜しいでしょうか？
樋口様：いいよ！もっさり動くのもイマイチだからさ、サクサク動く感じがいいんだよね！
あなた：では、画面の使いやすさや反応の良さも併せて検討してご提案させて頂きます。
樋口様：そうそう、システムの保守・運用費がかかり過ぎだって上から言われちゃってさ。「クラウド」っていうの？安くなるならそっちも検討したいから提案してくれない？
あなた：承知いたしました。顧客管理システムの現状調査と併せて、システム構成や運用も調査対象として追加しご提案させて頂きます。
山本さん：現状調査後に概算見積もりをお持ちします。別途打ち合わせのお時間の調整をさせて下さい。
菊池様：了解しました。
お客様の要件を整理してみましょう
さて、お客様との会話、あなたはどう捉えましたか？ 「既存の顧客管理システムと連携したい」「販促の導線になる機能」など、様々な要望が出てきましたね。「もっさりした動きを何とかしたい」「クラウドで提案を」なんて言葉もでてきましたね？
それでは、システム化するにあたってはどのようにアプローチすればよいでしょうか？
要件定義の手法には、様々な手法がありますが、ここでは「機能要件と非機能要件を定義する」ことから始めてみましょう。
機能要件とは
システム化できる要件のうち、画面操作、帳票出力、データ連携や更新といった機能面に該当するもの。
非機能要件とは
性能や信頼性、拡張性、運用性、移植性、セキュリティといった機能面以外の要件。
今回のヒアリングでも、お客様のご要望の中には画面操作やデータの取り扱いに関する事だけではなく、検索時の早いレスポンス、顧客情報を外部への漏れなく連携するといった要素も含まれていましたね。
では、早速、@Typeスポーツ株式会社とあなたの会話から機能・非機能要件を洗い出してみましょう。
| 要件の種類 | サンプル | サンプル以外 |
|---|---|---|
| 機能要件 | ・顧客情報を検索する機能 ・顧客の属性情報を登録する機能 ・レコメンド機能 |
|
| 非機能要件 | ・顧客情報が外部に漏れない（セキュリティ） ・画面が使いやすい（使用性） |
要件定義の先につながるもの
さて、この要件定義がこの後のプロセスとどう関係していくのでしょうか？ 通常ですと、要件定義を行った後は、外部設計や内部設計といった形で、よりシステムを具現化していく「設計工程」を行います。
機能要件に含まれている要件は、画面設計、テーブル設計、帳票設計といった設計書に反映される内容になりますし、また非機能要件の内容は、ハードウェア構成図、システム構成図といったシステム方式に関わる設計と関連しています。
なお、設計の際は、機能要件・非機能要件の双方を十分に考慮した設計を行うことが重要です。
例えば、性能を無視したデータベース設計を行ってしまうと、システム構成で性能を補うことを余儀なくされる、画面操作に影響が及ぶといった不均衡が生じてしまいます。そのため、機能要件・非機能要件の相互関係を意識した設計書を作成することが大切です。
いかがでしょうか？ 要件定義のイメージはわいてきましたか？
今回取り上げたアプローチは要件定義のほんの一部に過ぎません。 実際は、予算や期間といったシステム化以外の側面も考慮に入れつつ、多くの要素を加味した洗い出しを行う必要があり、システムアーキテクトの幅広い見識が必要となります。
例えば、山本さんのメモにあった「外資系企業であるが、システムや運営はそれぞれの国に任されている。日本も独自に行っているものの、部署間のつながりは薄い。」という点ですが、将来的に統合の可能性があるかなどをヒアリングすることで、お客様のシステムをより拡張しやすい形でご提案をすることができます。
このように、要件定義の工程でお客様のご要望をできる限り引き出し、明確化できるかが、今後の行方を左右するといっても過言ではないでしょう。
要件定義をおこなう場合、お客様の顕在化されている問題を解決する力だけでなく、お客様が気づかれていない課題を見つけ、改善提案できるスキルも求められます。
