Transcript 資料PPT - 情報システム学会ISSJ

情報システム学会セミナー
システム要件定義の実際
～要件定義は属人的な「芸術」である～
情報システム学会
第１２回懇話会
2013年2月27日
Copyright (C) 2013 INTEC Inc. All rights reserved.
Ｖｅｒ0.96
ＩＴホールディングスグループ
㈱インテック 桐谷恵介
今村信一
1
情報システム学会セミナー
－ＡＧＥＮＤＡ－
1.ＩＴホールディングスグループのご紹介
2.要件定義の失敗がシステム構築の失敗に直結する
3.要件定義の抱えるシビアな現状
4.あるべき要件定義とは
5.要件定義を進めるマエストロの実際
6.プロフェッショナル要件定義
2
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
1.ＩＴホールディングスグループのご紹介
ＩＴホールディングスグループは、業界売上規模で独立系企業Ｎｏ．１集団です。
連結５５社、従業員２０，０００人超の規模を有し、安心してお付き合いいただける企業グループ
です。
２０１１年度
実績
売上高
営業利益
２０１２年度
計画
売上高
営業利益
３，２７４億円
１５６億円
３，４００億円
１７５億円
（旧旭化成子会社）
（旧小松製作所子会社）
＜業種別売上高＞
11%
業界２位
40%
26%
23%
金融
製造業
流通・
サービス
公共その他
※グラフは2009年3月期データ
3
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
企業概要
特
概 要
本社所在地
富山県富山市（本社）
東京都江東区（東京本社）
長
ＩＴのトータルカンパニー
（コンサルから運用・保守までのワンストップサービス）
設立日
１９６４年１月１１日
資本金
２０８億３０百万円（201２年4月現在）
（豊富なデータセンター、ネットワーク運用実績）
売上高
８９４億０６百万円（2011年3月期）
完全マルチベンダー
経常利益
２９億６３百万円（2011年3月期）
従業員数
３，７７３名
代表取締役社長
滝澤 光樹
Copyright (C) 2013 INTEC Inc. All rights reserved.
（2012年4月現在）
安心のアウトソーシング
（独立系企業の強みを生かした自由度の高いサービス）
先用後利
（コンピュータユーティリティの実現）
質実剛健
（インテックは逃げません）
4
情報システム学会セミナー
事業拠点
■お客さま資産を預かる設備は、全て自社ビルにて展開しております。
■これは、高セキュリティと高信頼性を実現するとともに、地域に根をおろしてお客さまに
密着し、顧客満足度向上を目指す姿勢によるものであります。
■電力会社との共同事業におきましても、単にテナントとして入居をするのではなく、共同
出資会社を設立して運営しております。
（事業拠点数：２５、自社ビル数：１０、共同事業データセンター数：２）
富山本社ビル
（タワー111）
札幌
インテック本社前ビル
（ポートラムスクエア）
株式会社パワー･アンド･IT
武漢
万葉スクエア(高岡)
高岡
砺波
金沢
上海
京都
山口
仙台
魚津
高松
大阪
新宿
福井
東京
横浜
名古屋
松山
仙台ビル
大分
大阪ビル
Copyright (C) 2013 INTEC Inc. All rights reserved.
札幌ビル
新潟
富山
神戸
広島
福岡
山形
新潟ビル
横浜ビル
東京ビル
新宿ビル
株式会社アット東京
5
情報システム学会セミナー
2.要件定義の失敗がシステム構築の失敗に直結する
（１）情報システムに発生する問題
情報システム構築は失敗します。情報システム構築は約60年の歴史があり、
構築を成功させるためのさまざまな情報システム開発手法が考えられてきまし
た。また、情報システム構築は時限的な組織であるプロジェクトで遂行されるの
が一般的であり、プロジェクトの管理手法や管理ツールも作られてきています。
とはいえ、どのような開発手法であれ、情報システム構築が失敗してしまうの
は、さまざまな実績から明白な事実なのです。この開発手法なら絶対失敗しな
いということはありません。手法や手順を厳密に守って構築を進めても、失敗は起き得るのです。予測
不能なトラブルが起きて、綿密な計画や手順が崩れてしまうのも情報システム構築にはよくある話なの
です。
－出来上がった情報システムが抱える様々な問題点－
経営・業務上の期待効果が想定どおり得られない
想定機能が欠落している
業務運用の妨げになる
賞味期限が切れてしまう
費用が逸脱してしまった
納期が守られない
情報システム構築の経験が企業活動に活かされない
Copyright (C) 2013 INTEC Inc. All rights reserved.
6
情報システム学会セミナー
2.要件定義の失敗がシステム構築の失敗に直結する
（２）情報システムの失敗の構図
IPA SEC（独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター） SODEC（2005/6/297/1）によるアンケート最終報告書によると、情報システム構築プロジェクトの進め方で問題と感じていることの
上位には、「顧客要求が不明確のまま、進めている」「顧客要求がなかなか確定しない」「見積もり根拠が曖昧」
「開発計画がずさん」などが指摘されています。その他にも「ドキュメンテーションが不十分」「プロジェクトマネー
ジメントがなされていない」などの指摘もあげられています。
7
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
2.要件定義の失敗がシステム構築の失敗に直結する
（２）情報システムの失敗の構図
また、もう1つのアンケート結果によると、失敗あるいは後悔した原因のうち、要件定義にあると思う割合
はというと、「失敗プロジェクトにおける原因のうち50％以上が要件定義にある」と考えているユーザが
70％に達しています。また、開発ベンダーの70％もプロジェクト進行上、問題なのは「顧客要求が不明確
のまま進めている」「顧客要求がなかなか確定しない」だと考えています。
※回答数：２７０
つまり、これらを分析すると、情報システム構築の失敗原因の多くは要件定
義工程にあるとの結果になっているようです。
Copyright (C) 2013 INTEC Inc. All rights reserved.
8
情報システム学会セミナー
2.要件定義の失敗がシステム構築の失敗に直結する
（３）実際の情報システムの失敗事例
１）想定期待効果との乖離
◆顧客概要
・食品素材メーカー
・国内外に営業展開
◆プロジェクト概要
・外部要因（原料高や市場の飽和）に関する
リスクヘッジ → 業務標準化と効率化
納期回答の迅速化のために情報システムを刷新するも効果出ず
「納期回答の迅速化」を目的として情報システム構築が開始され、多少の紆余曲折はあったもののプロジェクトは順
調に推移していき本番稼働を迎えました。けれども一向に以前の業務のやり方やスピード感に変化は見られません。
結果、目的としていた納期回答の迅速化は実現できませんでした。
最大の原因は、目的を具体的な言葉で定義し明確な数値目標に落とし込まなかったことで、各部門はそれぞれ自部
門の観点で目的を捉えてしまったこと。つまり、全社最適の観点が抜け落ちてしまっていたのです。
A社では、そもそも「納期回答」という言葉を各部門がそれぞれ独自に解釈しており言葉が統一されていませんでした。
販売部門 ・・・ 「お客さまから注文を受け、在庫・生産・資材調達の状況を加味してお客さまへ納期を連絡すること」
生産部門 ・・・ 「販売部門から生産依頼を受け、生産状況を把握し販売部門へ製造予定を連絡すること」
調達部門 ・・・ 「原材料メーカーへ発注した内容に対し、納入予定の連絡を受けること」
このように「納期回答」という言葉1つとっても解釈はバラバラで、認識の齟齬があったのです。
・問題点
要件定義フェーズにおいて、言葉の定義がなされなかったことにより、各部門がそれぞれの視点で言葉を解
釈してしまった。その結果、全体最適の志向が欠如し情報システムは変わっても業務の改善はなされないという
結果となってしまった
Copyright (C) 2013 INTEC Inc. All rights reserved.
9
情報システム学会セミナー
2.要件定義の失敗がシステム構築の失敗に直結する
２）現行と同じ要件で突き進む
◆顧客概要
・住宅建具メーカー
・自社工場にて押出加工
◆システムの特徴
・大型加工設備を中心とした生産管理を実施。ホストコン
ピュータにて、自社で手作りした生産管理システム。
現行の要件が見えずに納期・費用が大幅に増加
この20年間は工場の基本的な設備や業務のやり方は同じなので、要件定義の工数を削減しようという考えもあり、
新しい生産管理システムの要件は現行と同じとして、要件の検討は行ないことにしました。20年前に構築された当
時の現行生産管理システムのドキュメント類は見つけることができなかったため、要件定義はメンテナンス用の設計
書をベースとした簡単な要件定義書を作成しただけで済ませ、開発工程を実施しました。
ところが、開発工程に入ってから、20年の間に工場内の大型の生産設備は同じでも、いくつかの小型の生産設備が
追加されたり、既存の生産設備に制御用のパーツが取り付けられたりしていたことが発覚しました。当然、それに伴
い業務プロセスの変更も発生しています。
そして、現行生産管理システムでも、それらの設備や業務プロセスの変更に対して、機能を補完したり、周辺情報シ
ステムやExcelなどの表計算ソフトを利用した手運用でのデータ連係をしたりするなど、独自の手順ができてしまって
いたことが判明したのです。それらの機能も新しい生産管理システムに取り込まなければなりません・・・。
結果として、要件定義の必要性が後で認識され、要件定義のやり直しによる手戻りが発生してしまいました。
要件定義のやり直しがその後の開発工程にも大きな影響を与えたことは言うまでもありません。導入コストは、当初
の予算より4割も増えてしまい、情報システムの稼働は半年も遅れてしまったのです。
・問題点
要件定義の前提としていた「現行と同じ」は、日々業務が改善されている以上非現実的である。「現
行と同じ」という言葉に惑わされ、また甘えてしまい、新しい情報システム構築では本来行うべき要件
定義の手を抜いてしまう。
Copyright (C) 2013 INTEC Inc. All rights reserved.
10
情報システム学会セミナー
3.要件定義の抱えるシビアな現状
要件定義を困難にする要因としては以下のようなものがあります。
（１）複雑化した要件を定義しなければならない
１）情報システムを複雑化する要因
情報システムへのユーザー要求の多様化については、昨今の経済環境や業界環境の急激な変化がもた
らす影響があげられます。昨今の急激な環境変化は企業に対し「いつ何が起こるか分らない」という不透明
性を突きつけているものであり、いかに迅速に判断し、変化に追随していけるかが企業の存続を左右してい
ます。つまり、自社の経営状況が現在どのような状況なのかを、迅速かつ正確に把握する必要があるので
す。
また、企業内部における要因については、業務の効率化・標準化を含めた自動化や情報の連携や共有化
の必要性に伴い、情報システムを活用する業務領域が企業活動のほぼ全域にわたったことが1つの要因だ
といえます。また、企業の競争力の源泉となる自社の業務プロセスの情報システム化や業務時間の拡大
（24時間365日サービスなど）なども多様化した要因といえます。
外部要因
◆自社の経営状態の把握
内部要因
◆ＩＴの活用領域拡大
◆コンプライアンス維持・向上
◆国際会計基準をはじめとした
制度対応
◆セキュリティ
◆業務プロセスのＩＴ化
◆業務時間の拡大
◆ＳＮＳ等、新ビジネスモデル
◆環境、エネルギー対応
11
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
3.要件定義の抱えるシビアな現状
２）作成する情報システムという「製品」の特性
情報システムという「製品」は、他の製造品に比べてあまりに多様な機能が持てるのです。
情報システムという「製品」は、あまりに多様な機能が持てる
自動車やカメラのような工業製品と違って、物理的な制約が少ない⇒何でもできる
使用目的が広範囲で、多種多様な機能を要求される
使い勝手など、個人の主観的評価が入る機能も作り込める
機能は、計算などの論理的な情報整理が主な役割⇒人間の論理思考のかなりの部分を実
現しようとする事での複雑化
12
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
3.要件定義の抱えるシビアな現状
３）QCDのせめぎ合い
情報システム構築に限らず、ものづくりの現場ではQCDについて必ず考慮すべき項目です。
QとはQuality（品質）であり、CとはCost（費用）、DとはDelivery（納期）であり、それぞれの頭文字を集めて
QCDと呼んでいます。
情報システム構築では、QCDのどれに問題が起きても、プロジェクトの計画を抜本的に見直し緊急対策
を実施しなければいけなくなりますが、中でも最も重要であり、難しいとされているのはQだと言われていま
す。つまり費用が予算内に達成され、納期も予定どおりの期日に間に合ったとしても、品質が安定していな
ければその情報システムに価値はないということを意味します。
情報システムの場合のQの確保と評価は、他の製品に比べて非常に不安定と言わざるを得ません。その
複雑さと要件の定義の曖昧さから、動きが「正しい」事を保障するのはなかなか難しいのです。Qの達成が
困難な為にDやCに大きな影響を与えてしまうのです。
品質
品
品質
質を
を向
向上
上さ
させ
せよ
よう
うと
とす
する
ると
と
コ
ス
ト
が
か
か
る
コストがかかる
品
品質
質を
を向
向上
上さ
させ
せよ
よう
うと
とす
する
ると
と
時
時間
間が
がか
かか
かる
る
コスト
納
納期
期を
を短
短く
くし
しよ
よう
うと
とす
する
ると
と
コ
ス
ト
が
か
か
る
コストがかかる
納期
13
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
3.要件定義の抱えるシビアな現状
（２）曖昧な対応方法で臨む
ある意味で、何でもできる情報システムを作るのに、製品としてまとめていき、最終的な「決着」をつける
ための制約の少ない中、複雑な機能を絞っていってまとめるだけでも大変なのです。それなのに現状は、
言葉による設計指示という、ひどく曖昧な製造指図を出しているという構図になっているのです。これでは、
機能の「決着」はなかなか着かず、混乱が起きるのは必定で、「正しいモノ（＝正しい情報システム）」を作
るのは非常に困難な構図となっているのです。
また、作成する情報システムの全ての機能を定義しない（出来ない）というのも、情報システム構築を難
しくしている要素なのです。常識的な事はあえて書かない、関係者で合意もしないという事が普通にまかり
通っています。
１）情報システムの「作り方」の曖昧さ
情報システムの製造は、曖昧な「言葉」という道具で行われる
要件の定義からプログラミングまで、「言葉」で行われる
「言葉」には多義性があり、様々な解釈が可能
言葉の意味は個別の文脈の中で生まれ
る、つまり前後の文脈により違うことも普
通です。「木を植える」、「木の椅子」、「金
のなる木」等々と言うとき、それぞれの
「木」は同じものではありません。
14
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
3.要件定義の抱えるシビアな現状
２）全てを決めてから作る訳ではない
情報システムの製造において、「常識な事」は明確に定義されない
あまりに膨大な機能を全て定義する事は不可能
「言わなくてもわかる常識的な事」は関係者による暗黙の了解事項となる
明らかに定
義していな
い範囲
情報システムの機能定義範囲イメージ
未定義
信頼関係および常識で合意される範囲
要件が定義され合意された範囲
言葉で明示的
に定義され合
意された範囲
未定義
15
Copyright (C) 2013 INTEC Inc. All rights reserved.
常識な事として暗
黙の了解をしてい
る範囲
情報システム学会セミナー
4.あるべき要件定義とは
要件定義とは
情報システムやソフトウェアの開発において、開発前にどのような機能が発注者（顧客）から要求されて
いて、何が実装されるべきなのかを、条件や前提を整理しながら明確にしていく作業を指します。
要件は、開発ベンダーと発注者（顧客）の双方の理解・合意により定義が行われ、その成果は「要件定
義書」としてまとめられます。
一般的なシステムの開発モデルである「ウォーターフォールモデル」では、情報システムの製造工程で
変更箇所があった場合に前の工程に戻ってやり直す必要があるため、手戻りがシステム開発全体のス
ケジュールを圧迫する、一番の要因となっています。
「ウォーターフォールモデル」は、手戻りが発生すると構築の失敗に直接つながってしまうため、開発前の
要件定義が最も重要なプロセスといえます。
ウォーターフォールモデル
時系列
要件定義
工
程
手戻りにより
スケジュールを圧迫
外部設計
内部設計
詳細設計
製造
テスト
Copyright (C) 2013 INTEC Inc. All rights reserved.
16
情報システム学会セミナー
4.あるべき要件定義とは
（１）要件定義の結果は曖昧であることが前提
あるべき要件定義を語る上で、その大前提は、要件定義の結果は実は「曖昧である」ということです。こ
れは、どんな手法や手順で行っても、結果は曖昧なものしかできないという意味でもあります。
要件定義はどのようなやり方をしても、「曖昧さ」は絶対になくせないとなると、あるべき要件定義を語る
上でも、まずは結果が曖昧であることは前提とすべきなのです。その上で、いかにその曖昧さの振幅を
小さくするかが「あるべき要件定義」のポイントとなるのです。
要件定義は曖昧である
どこまで曖昧さの振幅を小さ
くできるかがポイント
膨大な機能において、どこまでが合意されどこまでが未定義かが曖昧
常識な事として暗黙で合意される範囲は、なにが常識であるかが曖昧
言葉で明示的に定義される範囲にも、言葉の解釈違いによる曖昧さがある
17
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
4.あるべき要件定義とは
（２）要件は合意によって作られる
情報システム構築に対する要件には絶対的なものはなく、利害関係者間の合意形成によって要件は作
られると言っても過言ではありません。
つまり、合意形成されていない“要件定義書”はいくら体裁が整っていたとしても、定義するべき事柄が網
羅されていたとしても、全ての利害関係者が「将来像」やそれに伴う「課題」、「解決施策」を納得していなけ
れば不毛な交渉が発生し、膨大な戻り作業が発生することになりかねません。
合意形成の種類
要件を導出した人が納得せず、要件を受け入れる人の意見を聞き入れた状態 （Lose-Win）
要件を導出した人が意見を通し、要件を受け入れる人の意見を聞き入れない状態 （Win-Lose）
要件を導出した人、要件を受け入れる人の双方が納得せずに検討をあきらめた状態 （Lose-Lose）
要件を導出した人、要件を受け入れる人の双方が納得した状態 （Win-Win）
言ったはず
聞いていない
こんなはずでは
なかった
一方的な合意形成では情報
システム構築は失敗する。
Win-Winの合意が不可欠。
18
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
4.あるべき要件定義とは
（３）要件定義の進め方にはセオリーがない
「正しい」要件定義を行うためには、その進め方が極めて重要となります。では、実際に要件定義を進め
るには、どのように行えば良いのでしょうか。
実は進め方は人それぞれであり、確実に成功に導けるセオリーや手法はないというのが現実なのです。
◆ 要件定義の手順や手法は確立されていない
コンサルティング企業や開発ベンダーは、情報システム構築を何とか成功に近づけようと作業プロセスを定義
してみたり、テンプレートを構築してみたりと試行錯誤を続けているが、いまだに情報システム構築の失敗が後
を絶たない。
◆ 要件定義は、構築する情報システムの特性や人により成否を分ける
要件定義の手順や手法が明確であっても、それを使いこなす人や組織、構築する情報システムによって、成功
したり、失敗したりを繰り返している。まったく違ったやり方をしても情報システムが正しく稼働することもあれば、
他人の進め方をそのまま持ってきても上手くいかないこともある。
要件定義の進め方は千差万別で人それぞれ。
ニーズの聞き出しから定義内容のまとめ方、合意形成の仕方に至るまで、
進めるリーダー個人のキャラクターや資質を前面に出して行うべきである。
19
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
4.あるべき要件定義とは
（４）要件定義は芸術であり、進めるリーダーは芸術家（マエストロ）である
要件定義の進め方が個人の資質に依存する理由は、要件定義ではいかに関係者を巻き込み誘導して
いくかが重要なためだと考えられます。つまり要件定義という作業は、人と人との関係が重要であり、進め
るリーダーは人の心を掴む必要があるからです。
そうであれば、要件定義はもはや芸術と同じと言えます。
要件定義を行う人は、それぞれやり方が違う “芸術家”
芸術とは人の心を掴むことが目的の作品や表現を作るこ
とです。芸術作品を作る方法は千差万別です。芸術も個人
の資質に大きく依存し、作る作品がそれぞれ違います。
つまり要件定義は芸術であり、進めるリーダーは芸術家
（マエストロ）と言えるのです。
要件定義と芸術の共通点
要件定義の進め方（作る芸術作品）にマニュアルはなく、毎回それぞれ違う
要件定義（芸術作品）はリーダー（芸術家）の資質や経験に大いに依存する
リーダー（芸術家）は人の心を掴み、関係者を巻き込む必要がある
20
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
5.要件定義を進めるマエストロの実際
（１）要件定義マエストロ
独断者タイプ・マエストロ
◆経歴◆
42歳、都内の私立大学を卒業
後、大手開発ベンダーに入社し
て19年目。SEを経て現在はプ
ロジェクトマネージャ。SEの時代
はホストシステムからC/Sシステ
ムへの変換期であった。ここ数
年は流通業界に専任し流通関
係の企業のプロジェクトを担当
していて、プロジェクトマネー
ジャとして主にWeb関係の情報
システムの開発に携わっている。
◆得意スキル◆
ファシリテーション能力は高いと思っている。基本的な
筋書きは立てるが、流れに任せて議論を誘導する。意
図的に論議を漂流させ、策動をかけて一気に予定の結
論に導いてしまうのが得意。ディベートや議論は得意で
ある。議論の切り返しには、ほとんどの場合条件反射的
に瞬時に対応できる。切り返しの見事さと断定的な言い
方でカリスマ性を感じさせることができると思っている。
流通業をはじめ各業界の企業の情報システム構築の
経験から、業務のスキルもある程度あるが、どんな業界
の顧客とも論理的な整理力や他業種との比較により、
業務のあるべき姿についての議論ができると思っている。
◆要件定義の進め方◆
ファシリテーションを重要視していて、プロジェクトの進め方も段取り重視。
会議なども必ず事前準備を確認する。重要な会議は自らファシリテータを務
め、都度結論を出していく。断定的なもの言いで押し切ることも多い。
議事録を重視していて、「ライブ感のある議事録を！」と重要な会議は発
言録レベルを書き手に要求する。過去の議事録にて論議を制することもし
ばしばある。可視化資料へのこだわりは強い。また、プロジェクトの進行の
ためには、顧客側の役割まで踏み込むことを厭わない。顧客との役割分担
は行うが、現実を見て顧客側が役割を果たせないと判断すると、積極的に
顧客側の役割を肩代わりする。その対応工数は曖昧になることが多い。
手順を軽視しがちで、最初に結論ありきで決め付けで進行するケースもま
まある。
◆性格／趣味◆
何事にも前向き。義理人情に弱いところもあ
り、常に正しいことにこだわって物事を進め
ている。実は繊細なところがあるが、大らか
な性格に見せている。
スポーツ全般、テニス、スキー、ゴルフを嗜
む。毎週末にはジムにいって汗をかいている。
体力/気力には自信がある。
－悩み－
常に自分の仕事振りと会社の評価のGapが
あると感じている。口癖は「会社には貸しが
ある」
◆長所・短所◆
長所：独断的に強力にプロジェクトを進めるので、
顧客側はこのリーダーが作る流れに乗れば、楽に
プロジェクトが進む。そのため、このリーダーに対
する信頼を持ちやすい。
短所：衆知を集めて判断をしない傾向があり、リー
ダーの判断が正しい時は強力にプロジェクトが進
むが、間違っている時はダイレクトにプロジェクトの
失敗につながるケースが多い。また、細目な事項
を疎かにしたためにつまずくケースもままある。
21
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
5.要件定義を進めるマエストロの実際
呪術的指導タイプ・マエストロ
◆経歴◆
45歳、関西地方の私立大学
を卒業後、独立系開発ベン
ダーに入社。プログラマから
SEを経て現在はプロジェクト
マネージャとして活躍中。ホ
ストシステムを主に担当し、
バッチシステムからオンライ
ンシステムへの変換期を経
験している。メーカーから小
売まで幅広い業界にプロ
ジェクトマネージャとして情報
システム開発に携わってい
る。
◆得意スキル◆
自分のペースに引き込む能力が高
いと自負している。初対面の相手に
はカマをかける。いきなりの説教や叱
りつけを行い動揺させ思い通りにさせ
るマインドコントロールの手法に近い。
独自の理論を展開し、周りのメンバー
がいつの間にか納得するように進め
ていけるのが得意技だと思っている。
また、ディベートは勝負事だという考
えがあり、勝つことが重要だと思って
いる。噛み合った時は神がかり的に
話がまとまっていき、オーラが見える
と言われている。
◆要件定義の進め方◆
発注者（顧客）の合意をとることが一番優先と考えていて、どんな
話があっても合意をとれたかどうかを確認する。合意をとるための
段取りやネゴシエーションも重視しており、雰囲気に反して慎重なと
ころもあるのではないかと思うような進め方をしている。また発注者
（顧客）の納得感は高く、「なぜか最後は納得しているんだよね」と
良いのか悪いのかわからない感想をいただくことも多い。全体的に
はただならぬ雰囲気とあいまって、逆らえない迫力がある。 合意
形成が重要だと思っているため、議事録や決まったことの記録につ
いてはこだわりがある。簡潔な表現とわかりやすさについて担当者
へしつこく要求することも多い。
Copyright (C) 2013 INTEC Inc. All rights reserved.
◆性格／趣味◆
仕事が趣味。飲みにいった時の話題は仕事の話が中心。遊びの
話をしているつもりがなぜか仕事の話になってしまう。周りには常
に強気な部分を見せるが、実は意外と寂しがり屋。自分の思いを
伝えて理解してくれないと不機嫌になる。議論は大好きで、すぐに
議論しようとする。ただし勝たないといけないと思っている。発注者
（顧客）との議論でも同様で、常に「勝ち」にこだわる。部下や後輩
を指導する時は自分の経歴を引き合いに出し、マインドコントロー
ルの重要性を教える。風貌も痩せた体躯にザンバラの長髪、鋭い
目と、狂気を感じさせるようなただならぬ雰囲気（瘴気ともいえる）
を醸し出している。読書は好き。でも実はスポーツも嫌いではなく、
特にウィンタースポーツが好み。
－悩み－
自分の思いが伝わらない相手に対してどう対応したら良いかをい
つも考えている。36協定が仕事の邪魔だと思っている。
◆長所・短所◆
長所：合意をとって進めていくため、発注者（顧客）の納得感が高
い。また明確に表現するため、曖昧な部分が少なく、仕様がぶれ
にくい。本人の気持ちが乗って、噛み合った時は思いのほか順調
にプロジェクトが進んでいく。また、噛み合うタイプとは公私ともに
仲良くなり、仕事を通じて長い付き合いができる人でもある。
短所：決断できない相手とは噛み合わない場合がある。本人がそ
れを認めてしまって、気持ちが乗らなくなると悪循環を生み出し、
プロジェクトは抜けないトンネルに迷い込むことになる。寂しがり屋
なので、たまに何に悩んでいるのか周りがまったくわからない時が
ある。
22
情報システム学会セミナー
5.要件定義を進めるマエストロの実際
朴訥粘りタイプ・マエストロ
◆経歴◆
44歳、地方の国立大学を卒
業後、大手開発ベンダーに
入社して22年目。開発ベン
ダーの地方センターにて地
場企業の情報システムサー
ビスや情報システム構築な
どを担当。プログラマからSE
を経て現在はグループマ
ネージャとして、複数の案件
プロジェクトを担当。
る。
◆得意スキル◆
特定パッケージの導入経験豊富で
あり、パッケージベースでの情報シス
テム構築が得意。地場顧客の対応経
験から、多様な情報システムサービス
の経験も多く、インフラからアプリケー
ションまで導入経験と情報に詳しい。
情報システムのトレンド情報にも関心
が高く、常に文献検索などでノウハウ
をアップデートしている。
◆要件定義の進め方◆
過去の経験と開発手法の応じた徹底的な準備を行い、顧客との
折衝に臨む。客観的データや実績、事例より対応要件を判断し、合
意に導く。顧客からの想定外の反応に対しては、その場では上手く
切り返したりなど臨機応変な反応できずに、打ち合わせが頓挫する
こともままあるが、決してメゲず時間をかけて再検討し準備した上で
顧客との折衝に臨む。打ち合わせが頓挫した状況で、顧客から
散々叩かれても淡々と対応し堪えない。粘り強く対応し、顧客が根
負けするケースも多い。顧客との折衝において説得する語彙は十
分ではないが、朴訥な雰囲気が余計な反感を招かず、そのうちに
は安心感を与えなんとなく話をまとめ合意してしまう。
◆性格／趣味◆
温厚で粘り強い。未体験のことには臆病で慎重。事前調査を徹底
して行わないと取り組めない。自ら踏み込むより受け身での業務
遂行が得意。生まれ育った地への愛着とこだわりが強い。容貌も
スマートさのないどっしりタイプ。株やFXなどの投資が好きだが、
大きな勝負はしない。少額での堅実な運用をしている。ラーメン好
きで美味しい店の食べ歩きが好き。出張で見知らぬ土地にいく場
合は美味しいラーメン店の事前調査を徹底する。
－悩み－
地方での地場の仕事が減ってきて、都会の仕事の下請け（ニア
ショア）の仕事が増えてきており、地方の独自性が活かせなくなっ
てきている。自らも都会への転勤の可能性が高く、家族との関係
に悩みがある。
◆長所・短所◆
長所：顧客とのぶつかり合いをなるべく避け、合意に導く。論破に
よって上から押さえつけて意見を通すのではなく、関係者の要望と
の折り合いを上手くつける。安心感から顧客との信頼関係を築く。
既存を踏襲するケースの情報システム導入には適している。
短所：臨機応変な受け答えが苦手なことと、慎重で保守的な考え
が強いので顧客がサプライズするような対応ができないケースが
多い。顧客から見て踏み込んだ積極的な提案や斬新なアイデアと
いう意味では物足りなさを感じる。
23
Copyright (C) 2013 INTEC Inc. All rights reserved.
情報システム学会セミナー
6.プロフェッショナル要件定義
実体験を踏まえた要件定義のステップを以下に示します。
ステップ1： 軸を設定する
ステップ2： 曖昧さへの具体的な備えをする
ステップ3： 暗黙知への備えをする
議論の軸となりうる情報システム構想を
しっかり作っておく
要件定義は曖昧なものであることを前
提とし、曖昧さの振幅を小さくすること
定義できない要件（暗黙知）に備えるた
めには、発注者と製造者の間に深い信
頼関係を築くしかない
成果物をベースに議論をしないと「空中
戦（噛み合わず、言いっぱなし）」になる
ステップ4： 徹底的に可視化する
ステップ5： 関係者を巻き込む
ステップ6： 優先度付けをし、小さく産んで・大きく育てる
各部門のうるさ方（各部門に長い期間
所属しその部門の業務に関して極めて
詳しく、業務遂行のキーマン・キーウー
マン）を巻き込む
重要課題の解決に対する「実現性」
と「効果」の2軸で要件に対し優先順
位付けをする
ステップ7： 合意形成をする
情報システムの絶対的な要件は、「合
意」によってのみ作られる
Copyright (C) 2013 INTEC Inc. All rights reserved.