2017年02月03日

要件は誰が固めるべきなのか


初めての方はこちらを「はじめに

今回は開発のインプットに関して誰がどの部分の主体となるべきかの話です。一般的に言えば企画に関する部分なので開発者としてはあまり関心を持っていない人もいるかもしれません。

要件とは


まずここで述べている要件について定義しておきます。
ここでは仕様に至る流れとして以下の様に上流から「要求」「要件」という二つの要素を定義して考えていきます。
53N023_001.jpg

それぞれ説明すると、まず要求というのは仕様とは離れて実際に達成したい事です。目的と言い換えてもいいかもしれません。例えば勤怠処理を自動化したいとか、開発環境を自動でバックアップしたいとか、という様な事です。要求を決定する主体となる人は勿論顧客です。
ここで顧客と言っているのは実際のお客さんの場合もありますし、同じ社内の他所の部署の場合もありますし、単に上司の場合もあるかもしれません。要はソフトウェアの開発を依頼する人という位置づけです。顧客の依頼を受けて開発組織(会社や部署など)が開発するという構図になります。従って顧客からの依頼が開発のインプットという事になりますし、どの様なソフトウェアにするかの決定権は顧客にある事になります。

次に要件ですが、これは要求をより具体的な内容や値に落としたもので、クリアしなければならない必須の条件と言えます。例えば「Webサービスとする事」とか「最大一万人を処理できる事」といった事です。

仕様は説明の必要は無いと思いますが、範囲は少し違う可能性があるのでこちらを参照してください。(どこまでが仕様の範囲か)仕様は勿論開発(組織)が主体となって検討して決めて行く事になります。

要求と仕様の主体が誰なのかは明らかですが要件は果たして誰なのでしょうか。顧客なのでしょうか。

問題となる状況


前提として、ここで議題としたい顧客のレベルは上記の要求、要件、仕様といった内容は未分化で依頼内容にはごちゃ混ぜに含まれている様なレベルです。こういう顧客のレベルの場合以下の様な事が起きた経験は無いでしょうか。
開発の最初の段階で色々依頼内容を確認してすり合わせて行くと思いますが、ここで例えば「全部ボタンで操作できるようにしたい」といったような要件とも仕様ともつかないかなり具体的な内容を提示されたり。そして開発が進み仕様が段々形になってくるとそれを見て度々仕様変更を言い出したり。その様な度々の変更も苦労して対応して完成したものの結局あまり満足されなかったり。まぁ「あまり満足されない」程度ならまだかわいい方で、酷い場合には開発が収束しなかったりもします。この様な事になる原因を紐解く為に「誰が要件を固めるべきか」という事を考えたみたいという事です。なので官公庁の様に入札要件としてきっちりと要件が提示されるようなケースは対象ではありません。

何が原因なのか


このような場合、どこに問題の原因があるのでしょうか。
結論から言えばそれは「顧客の言う事を聞いたから」です。
そもそも「全部ボタンで操作できるようにしたい」という内容は多分仕様です。顧客が要件と称して具体的な仕様を挙げている場合、多くは思い付きに過ぎません。何故なら顧客はソフトウェア開発のプロでは無いからです。素人が何を実現して欲しいかという要件を考え始めた時に思いつくのは当然具体的にイメージ出来るような事になってしまうのです。よって要件と称して具体的な仕様レベルの項目が多く並ぶ事になるのです。そしてこれを要件とばかりに全面的に受け入れて開発を進めたのが上記の姿です。思い付きですから当然仕様変更は発生しますし最悪ちゃんと形になるかどうかも怪しいものです。顧客側は元々持っていた「要求」と出来上がった実物との乖離に「こんなものが期待値ではない」と開発側を非難し、開発側は「言われた通りに作っただけ」と反論して泥仕合の様相を呈します。最悪の場合は訴訟に至ります。

実際に自分があるシステムのプロジェクトに途中から参加した時の事です。
自分の担当分はシステムの本体とは少し独立した部分のものだったので比較的自分の所だけを面倒見ていれば済んでいたのですが、肝心の本体の方は傍目で見ているとどうにも全ての事が場当たり的で常に混乱している感じでした。当然プロジェクトは遅れに遅れました。この様な状況をプロジェクトのリーダーはどう考えているのか真意を確かめたくて、ある時酒宴の席でリーダーに次の様な質問をストレートにぶつけてみました。
「このシステムにはどうにもあるべき姿が見当たらないですね」
そうしたら半ば切れ気味に以下の様に返されました。
「そんなものある訳ないじゃないですか!」
「お客さんの言う事が絶対なんです!」
その時はあまりに予想外の回答にびっくりしました。てっきり『何とかしようとしているもののうまく行かない』という話なのかと思っていたので、まさかあるべき姿の存在自体を否定されるとは思いもよりませんでした。結局このリーダーは顧客の所に行く度に何か言われてきて、それをそのまま忠実に盛り込もうとしていた為にシステムに芯が無く場当たり的なものになっていたのでした。勿論このプロジェクトは失敗に終わりました。

この様な例に限らず「言われたものを作る」と思い込んでいる人は意外に多いと思います。しかし仕様は少しかじった素人が考えて作れる様な甘いものではありません。プロにとってさえ簡単なものではありません。そして要件は仕様から見れば抽象化されたエッセンスと言えます。その様なものを整合性をもって網羅的に作成するのはやはりかなり難しい事です。なのにそれをそのまま受け入れて開発するというのは、責任を負わなくて良いという気楽さと引き換えに、関わる人すべてを不幸に陥れかねない危険な行為です。

どうするべきなのか


全ての決定権は依頼者である顧客にありますから、提示された要件がプロの目から見て要件の体を成していないとしても「これは駄目ですね。受け入れられません」などと言えるはずもありません。
それではどうすれば良いのでしょうか。
まず顧客から提示されたものが要件にしろ実際は仕様にしろ受け取る必要があります。ただし、受け取った後自分達で検討した結果変更するつもりで受け取る必要があります。つまり仕様は言うに及ばず要件でさえ自分達で決めるつもりで臨まならければならないという事です。そうでなければ一貫したポリシーを持った整合性のあるソフトウェアなど作れるはずもなく先程の例の様になってしまうのです。従って顧客に決めてもらわなければならないのは要求のみだと覚悟しておく必要があります。なので顧客から提示される要件については必ずその元となる要求を確認しなければなりません。要求というのは動機です。「一体なぜそうしたいのか?」それを出来るだけ深く理解する必要があります。要件による具体的な内容は要求を理解する為の補助的な情報に過ぎないと考える事すらできます。顧客は自分自身の要求から要件を作ります。同様に、要求を理解する事で開発側も新しい案として要件や仕様を作れるのです。逆に言うと顧客の要求を掘り下げて理解していないとその様な事はできません。顧客の意に沿っているからこそ別の案にしても受け入れられるのです。

例えば何故ボタンの操作にしたいのかを確認すれば、実は対象とするユーザーがコンピューターに不慣れでメニューバーの様なものは使えない可能性があるという懸念を持っているという事が分かるかもしれません。更に掘り下げて対象のユーザーはどういった人々なのかを確認すれば、今はボタンで良いとしても将来はステップアップした操作性を提供可能な形にするべきだと分かるのかもしれません。この様に全ての要件は掘り下げて行けば動機(要求)があります。そして動機の最も根本的なものは「なぜこのソフトウェアを欲しいと思ったか」という事です。全ての動機がそこに結びつく様に理解を心がけるべきです。より根本的なところを押さえて行けばブレが少なくなります。

忘れてはいけないのは我々が最終的に得なければならないのは顧客の満足です。顧客の言う通りにするかどうかは関係ありません。顧客が心の底から望んでいた事を叶えてあげるからこそ満足が得られるのです。だから要求を理解することが重要なのです。

一覧


メニュー

関連


事例:天文衛星「ひとみ」の事故


記事を広める



posted by 善 at 18:49 | Comment(0) | TrackBack(0) | 企画 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック