座談会を開いてびっくり!?　デザイナーとエンジニアとPM、それぞれが想像する「仕様」が違いすぎた

こんにちは。Goodpatch UIデザイナーの金谷です。

突然ですが、皆さんは「仕様」という言葉を聞いて、どういったものをイメージしますか？

Goodpatchのソフトウェア開発プロジェクトは、デザイナー、エンジニア、PMなど多職種で構成されます。言葉の意味が合わないこともしばしばで、デザイナーからエンジニアにバトンを渡すときや実装後のクオリティチェックのタイミングなど、私も苦労した経験があります。

中でも特に「仕様（機能要件）」という言葉は、その意味をめぐって混乱することが多く、同僚にこのような疑問をぶつけてみました。

「画面ベース」の仕様書に苦戦、詳細な仕様が決まらない

筆者：皆さん、私と同じように「仕様」という言葉を巡って苦しんだことはありますか…？

エンジニアA：私は「画面ベース」の仕様書に苦戦することが多かったです。初めて触れた仕様書が画面ベースのもので、いざ開発を始めると、仕様が決まっていない部分がたくさん見つかって…。「画面に依存してしまうと、詳細な仕様が決まらない」ということを知りました。

仕様漏れが多々見つかったので、既に開発が始まっていたのにもかかわらずゼロから仕様書を作り直しました。新しい仕様書を作ってからは仕様漏れがなく、開発が順調に進みましたが、このトラブルは過去一番大変なものでした…。仕様書について真剣に考える機会になったと感じます。

筆者：画面ベースの仕様書では、具体的にはどのような漏れが起きましたか？

エンジニアA：分かりやすい例としては、「パスワードを入力するテキストボックスにどのような文字が入力できるのか」ということが何も書かれていなかったことがありました。

筆者：それはしんどいですね。GoodpatchのプロジェクトでもUIのコンポーネント単位で番号を振って仕様を書き込み、Keynoteなどで納品する場合がありました。

エンジニアA：私がGoodpatchに入社した直後にアサインされたプロジェクトでは、まさに同じように仕様書を作っており、実装段階での仕様確認が多く起こっていました。とはいえ、実際に開発まで進まないと見えてこない問題点も多いので、フェーズやメンバー構成によっては、画面ベースの仕様書でも問題ないこともあるとは思います。最初からしっかり作るとコストも増えますし。

筆者：コストとのバランスは常につきまといますよね。結局実装段階で仕様漏れが大量発見されると、コストが発生してしまいますが。今は仕様をドキュメントで書くことが一般的になったと思いますが、以前の画面ベースの形式から変わった理由は何だったのでしょうか？

エンジニアA：個人的には「Notion」の登場が大きいと考えています。今まではesaやConfluenceなど、編集コストが高いツールが多かったので。

ユーザーストーリーを書いていたのに、仕様の認識がズレてしまった……

筆者：私が2年前に担当した案件で、「認識のズレ」でトラブルになりかけたことがあります。Webアプリケーションにおけるよくあるデータテーブルで、Filter chips をアクティブにするとデータを絞り込める仕様を伝えていました。エンジニアに実装していただいた後で動作を確認したら、想定していた動きと違う挙動をすることがあって。

理由を探ると「Filter chips をアクティブにしたときに、その要素を持つアイテムが表示になるのか、非表示になるのか」などの認識が擦りあっていない状態で実装に入ってしまったことが分かりました。しかも、ユーザーストーリー*を「JIRA」に書いていたにも関わらず、UIデザイナー、UXデザイナー、フロントエンドエンジニアの認識がずれていました。

*「ユーザーストーリー」：ソフトウェアによってユーザーが何を達成できるのかを簡単に定義したもの

UIデザイナー：どういうことですか？

筆者：「ユーザーは絞り込み機能を使うことによって、その時自分が見たいデータだけを閲覧できるようになる」という目的は全員が擦り合っていたのですが、「具体的にどのような挙動で見たいものだけが見られるようになるのか」という点が具体的に書けていなかったんです。ユーザーストーリーに達成したいことは書けていたけれど、具体的にどう動くかの仕様がズレていたという。

UIデザイナー：なんと…絞り込んだときの画面のイメージを共有してもズレてしまったのですか？

筆者：そうですね。Figmaでデザインファイルはもちろん共有していたのですが、ずれてしまいました。認識がずれた Filter chips の仕様に関しても、クライアントとのミーティングに全員参加していた上で意見も交わしていたので、他のメンバーと同じイメージができていると思い込んでしまっていましたね。

「よかれと思って」の追加実装、トラブルを防ぐには？

PM：私は今まさに、エンジニアの「追加実装」という悩みに直面しています。仕様書はあっても、エンジニアさんが良かれと思って追加の実装をして、仕様を変更してくださることがあります。

これ自体はいいことだと思うのですが、QA (品質保証) をする方は仕様書をベースにしてテストケースを作るので、ケースが漏れまくっている状態になり、追って設計書を実装に合わせて修正したり、テストケースを追加で書いたりと手戻りが増えてしまうんです。

エンジニアA：私はそういう場合しっかり共有しますが、ちょっと気になるくらいのことは勝手に直したりしがちですね。

PM：気持ちは分かります。良かれと思ってやっているので指摘しにくいんですよね。関係するドキュメント全部に反映されてなくて、後々のテストで詰まるということが起こったりするのがつらい…。

筆者：「もうやらないでください」なんて言いたくないですしね。その場合、どうするんですか？

PM：GitHubなら関係者全員にメンションしてもらうように言いました。「なるべく拾ってちゃんと議論に上げたいのでメンションをして連絡をしてください」と言ってあります。

工数見積もりは永遠の課題か？　不確実性を管理するアプローチを考える

筆者：座談会には参加できなかったものの、UXデザイナーの方からもエピソードが届きました。「大きい機能（①）のデザイン対応を終わらせて、次の大きい機能（②）に取り掛かっている最中に①の仕様詳細化・仕様変更のコミュニケーションが発生して、②のデザインを行う時間が減っていく」とのことです。いやー、これはあるあるですね。

UIデザイナー：スケジュール見積りの段階で、仕様詳細化などのコミュニケーションコストが発生することを見込んでおいて、回避することは難しいのでしょうか。

筆者：余裕のある見積もりが望ましいですよね。UI設計に集中する時間が削られないようなスケジュールを設計しておきたいものです。

UIデザイナー：私が担当した案件の序盤でも同じことが起きました。色々なことを並行でやっていたので、わけが分からなくなりましたね。かつ、時間がどんどん減っていったので、それ以降バッファは意識して取るようになりました。

筆者：「よくよく考えたら、ここの仕様決めないといけない」「よくよく考えたら、この仕様はおかしい」などとあとで気付くことはいつになったらなくなるんでしょうね…。いや、その時は来ないか（笑）。

エンジニアA：0にはならないでしょうね（笑）。

エンジニアB：「アジャイルの中盤以降に既存のものの仕様変更に対応しつつ、新機能を作る」という過程をよく見かけると思います。よくあることですが、やはり見積もることは難しいので「状態変化や情報の数が増えたことなどに注意して、バッファを見積もって作業する」という方法をよく聞きます。

状況の変化が発生することはしょうがないと思いますが、見えるようになってから意見することが自然ではあるので、不確実性の管理をいかに行うかということが重要だと思います。

エンジニアA：私が以前担当したプロジェクトでは、実装やデザインをしたときにかかった工数に比例して「複雑性が高い」と判断し、それに応じたバッファを取るようにしていました。

筆者：複雑性って、果たしてどういうものなのでしょうか。機能の数が多いとか、他の機能にも影響があるものとか？

エンジニアA：複雑性にもさまざまな考え方があると思うのですが、エンジニアリングの例では、if文の数、ネストの深さや条件分岐の数などがよく挙げられます。あとは他の機能への影響度合いですかね。

エンジニアB：個人的に、複雑性の指標は「情報の量」と「状態変化」の多さだと考えています。例えば、ログインするだけのシンプルな機能だとしても、権限がマスター・お客さん用・テスト用など、10も20もあったら複雑で工数もかかりますから。

エンジニアA：UIデザインをする際、同じ画面を何枚も作っているようだと、それだけ状態が多いので複雑だと思います。無効状態（Disable）のボタンを作るなどですね。

筆者：確かにコントロールが多いとそうなりますね。

各職種が想像する仕様とは？

筆者：ここまでの話も踏まえて、改めて「仕様」について、皆さんの見解を聞かせていただけないでしょうか。

例えば、ユーザーストーリーと仕様がどう違うのかなど。私の考えでは、仕様はその画面でどんな機能を持っているのか、仮にフォームがあるとして「フォーカスを外すと自動保存される」ということが仕様書には書いてある。ユーザーストーリーには、ユーザーが数値を変更できるということが書いてある、というくらいのフワッとした印象しかないです。

エンジニアB：なるほど。個人的にユーザーストーリーの定義は、エンジニア泣かせだと思っています。ユーザーストーリーに似ている「ユースケース」という言葉もありますよね。両者の違いを検索するとサイトによって解釈が違うことがよくありますが、個人的にはイコールの扱いでいいと思っています。

ユースケースが曲者だと思うのは、業務の要求や要件のような人に説明する文脈と、機能を説明する文脈、どちらもユースケースという同じ言葉が使われることです。「ヒト・モノ・カネ」や「価値」の話をしているときと、UIや詳細機能についてデザイナーやエンジニアが話しているときには同じ「ユースケース」でも別物と思った方がいい気がします。

筆者：それは紛らわしいですね。ちなみに「要求」と「要件」はどのような違いがあるのでしょう？

エンジニアB：例えると「こういうものが食べたい」というニーズが要求で、「ペペロンチーノを辛めで作ろう」という具体的なレシピが要件だと思います。ここでいうところの要求・要件は、企画やUXデザイナー側が考えることが多い印象です。

---

「要求」と「要件」、一体何が違うの？

PM：私は仕様というと、要求仕様書と機能仕様書の2つをイメージしますね。要求仕様書には「なんでそれを作るのか」「誰が使うためのものなのか」「どういう状態にできたらいいのか (受入条件) 」が書いてあると好ましく、クライアントさんやプロダクトオーナーが書くべきものだと思います。

一方、機能仕様書は「ソフトウェアをどう設計していくか」についてや、画面設計書も含まれるかなと。仕様書と言うと一つのアウトプットに見えるけれど、いろいろな要素を包含しているんですよね。

筆者：要求仕様書が、先ほど話に挙がった「要求」に近そうですね。

PM：そうですね。要求仕様書通りに条件をちゃんと満たせているかを試すテストが、一番最後にある受け入れテストだと思います。「V字モデル（参照：V字モデルとは？ | ソフトウェアテスト・第三者検証ならウェブレッジ）」という、どの過程がどのテストにつながっているかを説明したモデルがあるのですが、要求分析という過程が受け入れテストに繋がっていて、最終的にお客さん目線で条件を満たしているかということを確認しています。

要求と要件は何が違うのか、というお話が先ほどありましたが、要求は「何が欲しいか」というもので、要件は「システム上、どうしなきゃいけないものなのか」というものでそれぞれ対になっている。その要求仕様というのが、最終的にクライアントの受け入れ条件を満たしているのかという流れで、システムを設計していくイメージでした。

筆者：なるほど。ただ、要求仕様については、クライアントワークでもまとまってないことが多いと思っています。クライアントがやりたいことをできる形に落としていく、ということから始まると思っていました。あらかじめ、定めた上で始めることもあるんですね。

PM：もちろん、要求仕様に全て従うというものでもないと思っています。例えば、コストや優先度のことなどを考えた上で、作る必要がなくなる機能もあると思うのですが、「お客さんに強く影響するけれどコストが高いものと、お客さんに全然影響しないけれどコストが中程度のものどちらをやるのか？」みたいな議題を整理しやすくなりますよね。

仕様書だってコミュニケーションの一種、「認識合わせ」の意識を強く持とう

エンジニアA：私はエンジニアなので、プロジェクトに参加する場合は必ず開発まで関わります。だから、仕様書の納品などはやったことがないですね。そもそも、かっちりした開発スタイルが好きでないということもあり、要件定義もコスパよくやりたいと思ってます。

その上で仕様とは、「職種の壁を超えて、認識を合わせるコミュニケーション手段」だと考えていて、最後に認識が合えば正直なんでも良いと思っています。

私が今まで経験した現場で、以心伝心というか非常にハイコンテクストなコミュニケーションがなされているところがありました。「こういうものを作りたいです」というふんわりとした話をすると、iOSエンジニアとAndroidエンジニアがそれぞれ作るのですが、作ったものが全く同じという。

筆者：そんなことがあり得るんですか、最高ですね。

エンジニアA：私の理想はそれで、仕様書なんていらないと思っています。でもそれは現実的に難しいので、壁を埋めるために仕様書を作りたいと思っています。

仕様書だってコミュニケーションの一種なので、一方的に作ると単なる依頼になってしまい、辛いことが多くなりがちです。エンジニアリングの観点は、やはりエンジニアでないと分からないことが多いので、ちゃんとコミュニケーションをするものが仕様書であると考えています。それができたら「思っていたのと違う」という現象も減るんじゃないでしょうか。

仕様書を作る過程でさまざまな人が関わるので、その段階でズレや漏れに気付くなど、それも仕様書の役割だと思っています。本当は運用に関わる人なども呼んで、仕様について話せると良いのですが、それは手がかかりすぎるので、いない人の視点はその場にいる人がどこまでサポートできるかという話になっていきますかね。

筆者：ありがとうございます。私の以前の経験で「みんな分かってると思ってたのに、認識が違っていた」という問題には、認識を合わせるための仕様書があれば良かったのかなと思いました。

エンジニアA：仕様書を作る際に「認識を合わせることが目的だ」という共通認識があれば防げたかもしれないですね。そもそも「仕様書ってどういうものだと思いますか？」という認識を合わせるフェーズを最初に入れるといいかもしれません。

エンジニアB：職種問わずメンバー全員が関わって、作るもののイメージやゴールを共有できると素晴らしいと思います。

筆者：仕様書は議論しながら全員で書いていくというアプローチがいいのかもしれませんね。皆さんありがとうございました。

終わりに

ここまで読んでいただきありがとうございました。

PM・UIデザイナー・UXデザイナー・エンジニアの経歴も職種も異なるメンバーから、「仕様」に対する多様な見解だったり、ソフトウェア開発現場での生々しいエピソードなどを聞き出すことができました。

同じプロダクトに向き合う上では、「仕様」の定義や「仕様」そのものについて地道に認識をすり合わせてコミュニケーションしていくことが、スムーズなソフトウェア開発に繋がると考えます。

グッドパッチでは、領域を超えてプロダクトをデザインするデザイナー・エンジニア・プロダクトマネージャーを募集しています。気になった方はぜひ、まずは気軽に話を聞きに来てください！