長谷川さんにお招き頂いて「FoW!勉強会〜要求とか要件について一度みんなで語り合おう」で話をしてきました。資料はこちら↓。
当日のアジェンダは
第1部 19:00~20:00：最初に語らせて！
(1)「北海道生まれっていえば生キャラメルよりRDRAだろ」
神崎善司 株式会社バリューソース ”要件定義手法RDRAの開発者”
(2)「要件定義はサービス業なんだってば」長谷川裕一
長谷川裕一 株式会社フルネス, 合同会社Starlight&Storm
(3)「嘆きの要求～要求は開発するためにあるんやで～」牛尾剛
牛尾剛 株式会社 匠Business Place ”要求開発のプリンス”
(4)「要件定義すれば要求が理解できる、なんてことはない」
鈴木ゆうすけ グロースエクスパートナーズ(株) ”要件定義のデストロイヤー"
という豪華メンバーだったので、4番目の僕は斜め上担当と言うことで好き勝手なことを話してきました（”要件定義のデストロイヤー"は、長谷川さん命名なのであしからずｗ）。
誰から要求を聞けばいいのか
要件定義は、そもそもヒューマンスキルが要求される難易度が高い工程ですが、複雑さが増す現在のシステム開発では「誰から要求を聞くのか」というのが大きな問題になります。
会社の戦略に従うといっても社長だけではない多数の利害関係者がいるでしょう。そういった社員全員に話を聞くといっても、昔の事務機器としてのシステムであれば、例えば経理担当者だけに聞けば良かったかも知れませんが、現在では伝票入力が末端の社員に任されていることが普通です。
では、情報システム部門がユーザーの代表かというとそういうわけでもない。彼ら自身も現場のニーズを拾いきれなくて苦労をしているわけです。
ならば、実際にオペレーションをするユーザーの代表者に参加をしてもらおうと思っても、それがECサイトだった場合に誰が代表者かも分からない。
それに要求は聞いて得られるとは限りません。言うまでもないことですが、ユーザーが正確無比な仕様を提示できるわけでもなく、それが未来予測も含むのであれば一層の難しい。ユーザーはイノベーションのジレンマの中にいますから、既存機能への改善という形でしか機能提示をすることができません。業務を大きく変えたいような場合に、こうした要求が適合するかは疑問です。
というわけで、要件定義しようにも、そのために必要な「正しい要求」がどこから得られるかというのは非常に悩ましい問題なのです。
ユーザーを観て要求を発見する
この解決策の1つとして、僕が取り組みつつあるのが「ユーザーを観て要求を発見する」というアプローチです。
ISO13407 "Human-centred design processes for interactive systems"（インタラクティブシステムの人間中心設計プロセス）やエスノグラフィがヒントになると考えています。
人間中心設計については棚橋さんのブログ「DESIGN IT! w/LOVE」でググってもらうのが良いと思いますが、以下のプロセスの2-5をイテレーティブに実施していくというモノです）（カッコ内は、その工程で使われる代表的な手法）。
1.人間中心設計の必要性の特定
2.利用の状況の把握と明示（フィールドリサーチ、ワークモデル分析）
3.ユーザーと組織の要求事項の明示（ペルソナ／シナリオ法）
4.設計による解決案の作成（プロトタイピング、認知的ウォークスルー）
5.要求事項に対する設計の評価（ユーザビリティテスト、パフォーマンス測定）
棚橋さんによると人間中心設計のポイントは以下になります（人間中心設計（Human Centered Design＝HCD）で使う主な手法：DESIGN IT! w/LOVE）
・ユーザーの声を聞くのではなく行動を観察することで、利用時のコンテキストとともにユーザーの利用行動を把握し、その背後にある潜在的なニーズを発見すること・あくまで人間中心ですので、改善あるいは新たにつくりだすべき最終形は人間の経験そのものです。ですので、モノをデザインするのではなく仕事をデザインするという意識が必要です
・プロトタイプをいくつもつくり、ユーザーテストを繰り返し、ゴールにむかって「つくりながら考える」反復的な改善をベースにすること
そして、"「モノを通してヒトを見る」アプローチとは逆の「ヒトを通してモノを見る」"という表現されています。
一方のエスノグラフィ（ethnography、民族誌学）は、元々は「人類学者が、人間の社会と文化を研究する上で用いる質的調査法のひとつの形態」（『質的調査法入門』Ｓ・Ｂメリアム著）で、文化人類学者が文化を研究するために、その場で生活者と共に暮らし過ごすことで徹底的な観察をするというものです。
エスノグラフィは、ここから転じたマーケティング手法の1つで実際にユーザーの生活環境に密着して利用状況の把握を行います。IDEOやアロイなど海外のデザイン会社で導入されていることでも有名ですし、最近では国内でも事例として紹介されるプロジェクトが出てきました。
業務システムの場合、実際に一緒に暮らす必要はないかもしれませんが、ある程度の期間、ユーザーの仕事を観るのは大事なことと思います。
こうした手法で大切なのは、決定者は専門家であり、調査はユーザーから気づきを得るために過ぎない、ということです。ユーザー中心だからといってユーザーに欲しいモノを聞いては意味がないのです。ユーザーの状況を観察する中で潜在的なニーズを発見し、それを要求として捉えていくことが必要になります。
最後に
「要件定義すれば要求が理解できる、なんてことはない」と書きましたが、僕が言いたいのは、要件定義の手法は大事だけど、要求を聞くだけで満足してはいけないということです。言われたとおりの要求を満たしても、それが完璧であるとは限りません。言われた通りに作って対価がもらえればいいという人もいるかもしれませんが、それでは良いシステムは作れないし、ユーザーの満足度も上がらないでしょう。結果として、そんな考え方のSIerや人は淘汰されていくのです。
僕らがユーザーに価値のあるシステムを提供するためには、ユーザーのこと、そして人間のことを知らなくてはいけません。そのためにデザインの領域で使われている手法はとても参考になります。
そもそもシステムは（広義の）ユーザーインターフェースでしか評価されません。どんなに内部構造が美しかろうが、開発プロセスが素晴らしかろうが、ユーザーインターフェースがへぼくて使い勝手が悪ければ評価は低いのです。しかも、ユーザーの利用状況によって評価は変わってしまう。
その点に置いて、僕らは驚くほどユーザーの利用状況を知らないです。皆さんはユーザーがシステムを使っている場面を見たことがありますか？感覚的ですが、7割ぐらいのエンジニアは、自分が作ったシステムをユーザーが実際に業務で使っているのを直接見たこともなければ、良いだの悪いだののフィードバックを直接もらったこともないと思います。
なお、こうした手法はプロトタイピングを用いたイテレーティブなプロセスが前提となっています。当然のことながらアジャイルとの親和性は非常に高いものです。アジャイルソフトウェア開発プロセスとユーザー中心型リサーチ手法の組合せは、これからトライしていくべき重要な領域だと思っています。
前回のエントリ「アジャイルは死んだのか」で、「『開発者のためのアジャイル』という位置づけでは、アジャイルは死んでいるも同然」と書きました。アジャイルは開発者の生産性をあげるという風潮があります。それは大事ですが、僕らが本当に生産性を上げるべきなのはユーザーですよね。そのためのアジャイルであった欲しいと思います。
発表の後にディスカッションがあったのですが、「保守開発で要件定義が学べる」という指摘があり、非常に共感しました。
僕は新人から数年は、ユーザー企業のシステム子会社で基幹システムの保守開発をしていました。保守開発は新規開発に比べれば下地があるので、そこまで開発エンジニアとしての能力が求められるわけではありません。また、ベンダーがいたので、そもそも、全部自分で開発するわけではありません。それよりも相手の情報システム担当者と話をして要件をまとめたり、それをベンダーに伝えることが重要になります（ただのパイプじゃ意味がないですが）。
僕の場合、いろいろな事情で2年目で2つのサブシステムを任せられたのですが、確かに要件定義作業が山盛りでした。当然ながら先輩や相手の情報システム部門の人に助けられていたのですが、とても良い経験をさせてもらったと思っています。要件定義を極めたいなら、一度は保守開発に携わるのも正しいキャリアパスでしょうね。
