仕様変更に強い開発をするための、ヒアリングモデル：仕事を楽しめ！ エンジニアの不死身力（21）（1/2 ページ）
あなたはエンジニアの仕事を楽しんでいますか？ この連載では、仕事を「つらいもの」から「楽しいもの」に変えるためのヒントを考えていきます。
今回のテーマ：仕様変更が起きる理由、そしてそれを防ぐには
ある程度の経験を積んだエンジニアなら誰しも、顧客から仕様変更を依頼されて困った経験があるかと思います。
仕様変更が起こると手戻りが発生し、開発工数の増大や予算の圧迫、納期遅れなどを引き起こします。さらに。「仕様だ／仕様ではない」「言った／言わない」といったコミュニケーションのトラブルは感情論になる場合が多く、顧客との信頼関係も悪化します。エンジニアは無理な仕様変更で士気を落とし、顧客は社内調整などでいら立ちを覚えます。
せっかく開発するなら、リソース的にも感情的にも気持ち良く仕事をしたいものです。そこで今回は、「なぜ仕様変更は起こるのか？」をテーマに、仕様変更が起きる原因を探り、それを防ぐヒアリング方法を紹介します。
ヒアリング時点でズレている？
仕様変更が起きる理由はさまざまありますが、その理由の中でも最も根本的なものに立ち返ってみましょう。「ヒアリングした要件定義の内容と、顧客が望んでいた内容が異なっている」――今回は特にここに焦点を絞ります。
プロジェクト初期に分かれば影響が少なくて済みますが、実際には開発終盤で分かるパターンの方が多いでしょう。顧客がシステムを使ってみて初めて「実はこうではなかった」と気付くからです。
エンジニア的思考がはまる落とし穴
ヒアリングが重要だと理解しているエンジニアは多いでしょう。しかし、現実には多くの仕様変更が発生します。なぜでしょう？
ここで、エンジニアが顧客へヒアリングする際にありがちな「エンジニアならではの特性」を考えます。
エンジニアはシステム開発が仕事です。そのため、OSやアプリケーションの実装方法など、「どうすればシステムが実現できるか」と考えることが習慣になっています。顧客から新システムの提案を求められる時も同様に、「顧客の要望をITで実現するためには、どのようなOSを使い、どのような構成で、どのようなロジックを組み立てればいいか」と考えます。
目的を把握しない開発が、仕様変更を生む
エンジニアは「顧客の要望を論理的に分解し、イメージを具体化させること」に長けています。一方、「なぜ、そのシステムが必要なのか」といったシステム開発の目的に意識が向かない、という落とし穴にはまがちです。肝心の目的を把握しないまま開発に着手すれば、顧客がシステムに望んでいた要件を満足できません。仕様ミスは、発想の違いから生まれるのです。
「目的」と「システム要件」を聞き出すために「イメージ」を活用する
ヒアリング時には「システム開発の目的」と「具体的なシステム要件」、両方を聞く必要があります。
では、どうすれば漏れ抜けなく、「目的と要件」を聞き出せるのか。ここで、ヒアリングしている内容や、ヒアリング不足の内容が視覚的に分かるチャート、「トライアングルコミュニケーションモデル」を紹介します。
「Web販売システムが欲しい」と依頼が来たら、どう要件定義する？
例えば、「Web通販で使用する販売システムを開発してほしい」という依頼があったとします。
まず、紙の中央に「Web販売システムを開発する」を書きます。続いて、矢印を上側に伸ばし、「それがないことによって、何に困っているのか」を繰り返し顧客に問い掛けます。
エンジニア「Web販売システムがないことによって、何かお困りのことでもあるのですか？」
顧客「お客様との出会いの機会を失っています」「商品を効果的にアピールできていません」
エンジニア「お客様との出会いの機会を失っていることで、何が困るのでしょうか」
顧客「売り上げが上がっていないのです」「業績低迷が続いています」
顧客に繰り返し問い掛けることによって、顧客が「Web販売システムが欲しい」と思っている背景が見えてきます。
目的が明確になると、開発すべきシステム像が変わります。 「商品を登録して、ショッピングカートに入れた商品を決済するシステム」 と、「新しい顧客との出会いの場を作り、商品を多くの人に知ってもらい、売り上げにつなげるためのWeb販売システム」は、全然違うものです。
- ブログやソーシャルメディアを使って、定期的に商品情報を更新
- 店主の思いや人柄を知ってもらいつつ、商品の良さをアピール
- 商品を利用した人の声を掲載、そこから商品販売サイトへの直接的な誘導
このように、情報を発信するツールや内容、販売サイトまでの動線といったことを考える必要が出てきます。
Copyright © ITmedia, Inc. All Rights Reserved.