2010年3月19日

【第20回】ソシュールの羊(その一)

【BA育成コース(原則編)】ビジネスアナリシスの原則編
先日、弊社の新しい教育コース(【BA育成コース(原則編)】ビジネスアナリシスの原則編 http://www.it-innovation.co.jp/academy/course/ba/ba01.html)を受講しました。
これは本来お客様からお金をいただく教育コースなのですが、ありがたいことに、今回は社員全員無料で受講できるということで、休日ではありましたが、東京まで行って受講してきました。
手前味噌ながらこの教育コースは、座学だけでなく、グループで実際に要求分析を行う演習などもありとても良くできていて、IIBA 日本支部の『ビジネスアナリシス知識体系ガイド(BABOKガイド) version2.0』(以下BABOK)とビジネスアナリシスの基礎について１日間でみっちり学習できます。自分で文献などを調べるのも良いですが、ビジネスアナリシスとBAOKの概要と要点を手っ取り早く知りたいという方には特にお勧めです。なんと言っても、その場で疑問点を講師に直接質問出来るのが教育コースの良いところです。

さて、前回の予告では今回「階層」について考える予定だったのですが、この教育コースの中でちょっと気になる問題が出てきましたので、今回は予定を変更してそれについて考えたいと思います。

ソシュールの「羊」の例
本題に入る前に、前回の連載の冒頭で紹介した、『寝ながら学べる構造主義』(内田樹著、文春新書)から、言語学者のソシュール(*1)が著書『一般言語学講義』の中に書いた「羊」の例についての著者の解説をご紹介します。
-------------------------------------------------------
「羊」はフランス語では「ムートン」と言います。英語にはフランス語の「ムートン」に対応する名詞が二つあります。一つは「シープ」です。これは白くてもこもこした生き物で、もう一つの「マトン」は食卓に供される羊肉のことです。英語では生きた羊と食べる羊は別の「もの」ですが、フランス語では同一の語がこの二つの「もの」を含んでいます。ですから厳密に言えば、フランス語の「ムートン」に相当する包括的な名称は、英語には存在せず、逆に、「動物としての羊」や「食肉としての羊」だけを意味する語はフランス語には存在しない、ということになります。
-------------------------------------------------------
このことは、この連載の【第３回】「プロセス」（その一）
http://www.promane.jp/master/nozaki/2009/06/000771.html にも書いたように、外国語を翻訳するときには「含まれている意味の奥行きや厚みが違うせいで誤解を産む」ということを表しています。
(これ以外にも、「『名前を持たないもの』は実在しない」、「ある観念があらかじめ存在し、それに名前がつくのではなく、名前がつくことで、ある観念が私たちの思考の中に存在するようになる」など、ソシュールの考え方を分かりやすく解説していますので興味のある方は是非読んでみてください。)

BABOKの「要求」の定義
さてここからが本題。昨年12月に日本語の翻訳版が発行されたばかりBABOKでは、主要なコンセプトとして「要求」という言葉を以下のように定義しています。

-------------------------------------------------------
要求とは、次のものである。
1. 問題解決や目標達成のためにステークホルダーが必要とする条件または能力
2. 契約、規格、仕様、規制などを満たすためにソリューションやソリューションコンポーネントが満たしていなければならない条件または能力
3. 上記1.まはた2.にあるような条件または能力を文書化したもの
-------------------------------------------------------

「ステークホルダー」とか「ソリューションやソリューションコンポーネント」など、気になる言葉も出てきますが、今回の趣旨からは外れるので、ここではぞれぞれ、「利害関係者」、「解決策」程度に理解しておいてください。
次に、翻訳の基となった英語の原文を示します。

-------------------------------------------------------
A requirement is:
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).
-------------------------------------------------------

実は、この英文の定義は、IEEE(*2) 610.12-1990 『IEEE Standard Glossary of Software Engineering Terminology』という、ソフトウェア工学に関する標準の定義を、そのまま持ってきたものなのですが、日本語として公に翻訳されたものとしては、このBABOKがはじめてのものです。

さて皆さん、これら日本語と英語の定義を見比べてどう思われますか？

「要求(requirement)」とは「条件(condition)」または「能力(capability)」である。

かなり大胆に要約しましたが、この定義を煎じ詰めるとこういうことになります。
皆さん、この言葉の意味、分かりますか？

正直に言って、私には今ひとつピンと来きません。また、BAの最も重要な概念のひとつである「要求(requirement)」が、前述のソシュールの「羊」の例のように、翻訳によって誤解を産むことになるのではないかと、教育コースを受けて以来ものすごく気になっています。

そういうことで、これから何回かに分けて、これら「要求(requirement)」、「条件(condition)」、「能力(capability)」の言葉の意味についてじっくり考えてみたいと思いますので、皆さんどうぞお付き合いください。

その頃、喫茶“A”では・・・
Y君「なんだか良くわからないことになってますけど、マスターわかります？」
マスター「さっぱり、わからん！けど、オレもソシュールくらいは知ってるで。」
Y君「そ、そうなんですか？」
マスター「そういうのは一般常識やろ。あんたとは教養が違うわ、教養が。」
Y君「え～ん(泣)、どうせ僕には教養なんかありませんよ～。」
マスター「泣くな！しかしこれは、しばらくオレたちの出番は無さそうな雰囲気やなぁ。」
Y君「え～～～！」
マスター「まぁ、オレは助かるからええけど。」
Y君「そんなぁ～。」

ということで、次回「要求(requirement)」から考えますのでよろしくお願いします。

またいつものごとく、皆さんからのご意見も首を長～くしておまちしています。仕事に関係ないことでも(笑)、どんなご意見でも結構ですので、遠慮なく投稿してください。
それから、コメントはちょっと敷居が・・・、という方はtwitterでつぶやいて下さっても結構です (できれば私に分かるようにつぶやいてくださいね) 。

それでは次回まで、サリュー。

(*1)ソシュール(1857～1913)：スイスの言語学者、ジュネーブ大学教授。20世紀の言語学に決定的な影響を与え、構造主義言語学の祖とも呼ばれる。
(*2)IEEE(The Institute of Electrical and Electronics Engineers, Inc.）：アメリカに本部がある 世界最大の電気・電子関係の技術者組織。「アイ・トリプル・イー」と呼称され、世界１６０カ国以上に375,000人以上の 会員を擁する非営利団体。IEEEは、コンピュータ、バイオ、通信、電力、航空、電子等の技術分野で指導的な役割を担っている。３８の専門部会(Society)と７つのTechnical Council（関連Societyの連合：略称TC）があり、国際会議の開催、論文誌の発行、技術教育、標準化などの活動を行っている。(IEEE東京支部HPより)
-------------------------------------------------------
この連載はシステム分析・設計に係る方々を対象にしていますが、ＩＴに係わっていなくても、抽象的な表現や物事に興味のある方にも読んで頂けるよう、極力平易な表現を心がけ、専門用語などには注釈を入れています。
また、皆さまの感想、要望、仕事での経験談、著者への気軽なお便りなどもお待ちしております。ブログ形式なのでコメント欄に直接書き込んでください。頂いたお便りについては連載の中で紹介させていただく場合もありますのでごあらかじめ了承ください。

コメント[4件] | トラックバック[0件]