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