第６回 「情報システムのあり方と人間活動」 研究会 【概要報告】
平成２２年３月２７日（土） 午後１時３０分〜午後５時 参加人数 １７名
於：慶應義塾大学理工学部創想館３階ディスカッションルーム
第１部 要求工学の動向と要求工学知識体系（ＲＥＢＯＫ）の取り組み
−ユーザとベンダーの架け橋となる要求工学の実践−
青山幹雄教授（南山大学・情報理工学部・ソフトウェア工学科）より、情報システム企画、開発に携る方々に要求工学の必要性、重要性について、体系的にご講演を頂き、大変活発な質疑も行われて、参加者の理解が深められた。以下にご講演の概要を報告する。
【 講演シナリオ 】
１．要求が成功のカギ
２．要求工学とは：ユーザの視点を中心として
３．要求工学知識体系（ＲＥＢＯＫ）
１． 情報システム開発を取り巻く環境の変化
情報システム開発技術の高度化（Ｗｅｂシステム⇒ＳａａＳの台頭など）により開発における技術障壁が高くなり、高度な技術が必要になってきている。
また、ユーザ企業における情報化投資が増大していく中で、情報システム構築について、全体最適の視点の不足、欠如が見られる。例えば、部門内だけで定義した機能や使われない機能を開発している事例も発生しており、その結果、情報システムへの投資効果が問われてきている。
２． 要求を明確にすることが成功へのカギ
ソフトウェア開発は一般にユーザ企業からの要求仕様に基づき、ベンダー会社がソフトウェアシステムを開発し提供していく。しかしながら、国内においては、情報システム部門が弱体化しているユーザ企業が多く、システム企画、開発については、ベンダー任せの企業がまだ多い。また、ユーザ部門内の要求を獲得してそれを仕様化する技術については工学的にも成熟していない状態にある。
実際に、アンケート調査では、「要求定義」が「品質」に対して、最大の影響を与えている（要求定義の良し／悪しが、品質向上／低下の両面に最も影響を与える）という結果が出ている（Ｈ１７年度の情報サービス産業におけるソフトウェア開発の実態アンケートより）。また、要求開発・管理の人材が不足しており、その人材を組織的に育成ができていないという結果も報告されている。（０９年１０月ＪＩＳＡ（情報サービス産業協会）主催要求工学シンポジウム参加者アンケートより）。
要求定義について、要求の持つ本質的な課題と獲得、仕様化の難しさ、要求に内在する不安定性と現場における「要求工学」への取り組みの遅れがあり、大きな課題となっている。
要求に内在する不安定性とは、次の3点を指す。
・空間的不安定性：システム（要求）の境界の曖昧性
・時間的不安定性：ユーザ要求や外部環境の時間的変化
・社会的不安定性：政治的、人的、組織的不安定性の反映、ユーザ／ベンダー間の力学、ベンダー間の過当競争）
３． 要求工学とは ユーザの視点を中心として
要求工学の研究について、ワールドワイドでは、「要求工学国際会議」が、１９９３年から、約２０年近く継続して開催し成果を共有、蓄積している。要求の定義として、
◆要求の定義：ＩＥＥＥ ６１０．１２-１９９０ Ｓｔａｎｄａｒｄ Ｇｌｏｓｓｒｙ ｏｆ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔｅｃｈｎｏｌｏｇｙ
◆ＢＡＢＯＫ（Business Analysis BOK）：ＩＥＥＥ610．12のｕｓｅｒをｓｔａｋｅｈｏｌｄｅｒに置換
◆ＲＥＢＯＫ：ＩＥＥＥ ６１０．１２／ＢＡＢＯＫに準拠
上記の知識体系の中で要求については、次のように定義している。
（１）ステークホルダが問題解決や目標達成に必要な条件、あるいは、能力
（２）契約、標準、仕様、その他に要請された文書を満たすためにシステム、あるいは、システムコンポーネント（要素）が満たすべき条件や持つべき能力
（３）（１）あるいは、（２）の条件や能力を記述した文書
◆要求には、機能要求と非機能要求があるとの見方もあるが、
現実のビジネスの世界では要求を次のように表現している。
◆要求とはユーザとベンダーの利益を実現するビジネスである。
・要求はビジネス上の問題を解決する為に「システム」が持つべき特性や能力。
・要求は「期待」や「要望」ではなく、ビジネスである。
−ユーザ視点からの要求＝経営目標の実現
−ベンダー視点からの要求＝ユーザ（顧客）満足度とベンダー経営のバランス
（究極は、要求定義にはベンダーの必要性がなくなる可能性も？）
◆要求のスコープ
・要求の３つのスコープ：ビジネス／製品、（情報）システム、ソフトウェア
・スコープに応じた要求定義：ビジネス要求定義、システム要求定義、ソフトウェア要求定義
◆要求工学プロセス
・要求獲得：ステークホルダ（顧客を含む）を明らかにしその代表から要求を獲得
・要求分析：要求の構造や特性を分析し、必要な要求を抽出
・要求仕様記述：分析した要求をドキュメント化
・要求の検証と検査：要求仕様それ自体が正しく、かつ、顧客の要求を満たしているか妥当性を確認する
要求工学プロセスに利用する手法として、ステークホルダ分析、ゴール分析、エンタープライズ分析、ペルソナ分析・ペルソナシナリオ分析等が利用されている。
要求工学プロセス手法適用の具体的事例をいくつか紹介する。
◆ゴール分析によるエンタープライズ分析：例 コンビニチェーン
経営目標から情報システムへゴールをシステムの階層的展開
◆ステークホルダ視点からのゴール分析：例 セルフレジシステム
ステークホルダ毎のゴールの構造化／視覚化と調整
ある（ステークホルダの）ゴールを達成すると、依存するゴールも達成される。
業務を効率化するとそれに依存しているゴール：売上の増加、レジ待ち時間の解消、精算時間の短縮などが実現される。
◆ペルソナシナリオ法の要求工学プロセス
例：大衆市場製品のユーザモデルの発見と要求獲得
４． 要求工学知識体系（ＲＥＢＯＫ）
ＪＩＳＡのＷＧで3年間かけて、青山教授のリーダシップで推進しているＲＥＢＯＫの開発に関する取り組みの紹介。
・背景として、要求工学を学び適用するガイドがないことから、ノウハウの収集、
ユーザ側／ベンダー側両方からベストプラクティスの共有、研究と成果物の発行を3年間継続実施。
・関連知識体系（ＢＡＢＯＫ Ｖｅｒ２．０、ＳＷＥ(Software Engineering)ＢＯＫ、ＣＰＲＥ）と比較、評価しながら、開発している。
・ＲＥＢＯＫの必要性が非常に高まっている。詳細アンケート結果によれば、必要性支持９０％以上、強く支持５０％以上の結果が示されている。
・ 今後のロードマップ
要求工学知識体系（ＲＥＢＯＫ）の詳細化とレビューを予定している。
２０１０年 タウンミーティング４回予定（情報処理学会、ＪＩＳＡ ＳＰＥＳ等）
２０１０年９月 国際タウンミーティング ＩＥＥＥ ＲＥ‘１０
・今後はＲＥＢＯＫを実践、活用する組織的取り組みと人材育成がポイントでＲＥＢＯＫに基づく人材育成ガイドを策定する予定である。
ＲＥＢＯＫについては、ＪＩＳＡ会員企業、ＪＵＡＳにもレビュー頂く予定。関心のある方は是非、ご参加頂きたい。
第１部以上
第２部 「問題解決の問題」と「システムの問題」を論じる
（株）ジー・エヌ・エヌ専務取締役（元慶応義塾大学理工学部管理工学科専任講師）の川瀬先生から、問題解決とは何かを中心にご自身の各企業でのコンサルテーション経験も参考に講演頂いた。講演は、大所・高所の話から始まり盛沢山で１時間の講演時間では不足した。参加会員と活発な質疑もあり盛会であった。
講演内容を補足する意味で、先生から著書「ＩＥ問題の解決」（現在、絶版）を読んでほしいとの話があり、その本は手元在庫が数部あるので廉価で提供しますと講演終了時に連絡があり、後日、参加会員申込み先着順４名に先生から著書が送付されました。（在庫尽了とのこと）なお、研究会へ先生から１部無償で提供頂いたので貸出が可能です。
講演要旨
１ 情報システム、システム全般について言えることは、No system better than no system (無いシステム程 良いシステムは無い) が重要と考えている。人間活動中心のシステムが良い。
２ 改善活動の進め方として、Boundary conditionを考えることが、重要であるが、又、Boundary conditionは定義できない。つまり、人間の欲望・欲求（自己実現）は、マズローの法則に照らせば限がない。
企業の改善活動に関して言えることは、現在の時点では経済状況からコスト減策が優先される活動状況である。
３ 自己紹介として、１９６２年米国ノースウエスタン大学大学院へＩＥ研究のため慶應大学から留学し生産性向上の大御所であるマンデル博士と懇意となった。
２０００年まで慶應大学管理工学科で専任講師を務め、９３年（株）ジー・エヌ・エヌを設立した。過去、９５年に日刊工業新聞社から、「IE問題の解決」を出版し複数の外国で翻訳・出版された。（株）ブリジストンをはじめとして、複数有力企業へＩＥのコンサルティングを行って来ている。
４ 改善をどの様に始めるのか
目標の順序を、安全＝＞品質＝＞生産性＝＞利益と考える。
継続的な改善効果から考えると、改善に取り組む順番は、
(2)又は(3)開発＜＝(1)生産＝＞販売(2)又は(3)が良い。
改善に取り組む時に、改善対象の階層的側面と工程順序的側面を考えて取り組む必要がある。階層的側面とは、原材料・設計・・
作業現場までの階層を指し上位の目標を改善すれば、より改善の効果が得られることを指す。工程順序的側面は、改善対象範囲を後工程から前工程へ拡大して行くことを指す。無論、改善効果は、後工程より前工程での方が大きいと言える。
５ 改善をどの様に進めるのか
オペレーショナル・エクセレンスを狙いとする。
手法の重要性もあるが、現場の人間の価値観を変えることが大事である。
改善したくなる環境へ変えることがポイントである。改善をやりたい人から、どんどんやらせる。失敗したからと言って減点するのは良くない。
改善活動に参加する人間のタイプ別分布は、正規分布になると言われている。先進的（牽引型）人間がいて、先進的人間がうまく行けば従う人間、最後に、全体の流れに止むを得ずついて行くタイプまで含めた人間集団の分布は正規分布となるといわれている。
（エベレート・Ｍ・ロジャーズ：人間集団への革新採用過程の仮説）
自分の問題は、自ら解決する風土を醸成する。
改善活動担当スタッフとして肝に銘じなくてはいけない点は、
・人は他人の問題を解くことは出来ない。
・スタッフはラインから援助を依頼された場合、行動する。
・スタッフは、あくまで援助者であるから影の人に徹する。
・ラインへの強制はラインの命令系統を通じて行う。
・ 最終的には、スタッフの存在を無くしラインの改善力を育てる。
（参考）ラインとスタッフの協力関係の歴史的変遷は、ベルリンの壁に類似している。
６ 問題解決が困難な原因
問題解決が難しくなる原因は、価値観・事実認識・問題解決手段等の相異によるものが多い。これらの問題点を解決するには、「見える化」が有効である。
７ 問題解決に向けて
問題解決機能の構造を「見える化」するのには下記の構造図を利用すると良い。
下記に構造図をしめす。
問題解決機能の構造図
問題解決機能の構造図を活用して、ライン（現場）がスタッフの支援を受けながら良い問題を発見し改善することで仕事の効率が何倍にもなると期待される。
改善を考え、行う際の心得として、知・情・意の順に意識するばかりでなく、順番を変え情・意・知でもよく考えてほしい。
やはり人間活動を中心として考えてほしい。
以上で時間となりましたので、言い足りない点が多くありますが、本日の講演を補足する意味で、もっと学びたい人は著書「IE問題の解決」を参考にしてください。
以上第２部
（研究会主査 伊藤）