システム要件定義の実際

システム要件定義の実際 ～要件定義は属人的な「芸術」である～情報システム学会　　　　　　　　　　　　　　　　ＩＴホールディングスグループ　　　第１２回懇話会　　　　　　　　　　　　　　　　　　　　　㈱インテック　桐谷恵介 2013年2月27日　　　　　　　　　　　　　　　　　　　　　　　　　　　　今村信一Ｖｅｒ0.96

－ＡＧＥＮＤＡ－ 1.ＩＴホールディングスグループのご紹介 2.要件定義の失敗がシステム構築の失敗に直結する 3.要件定義の抱えるシビアな現状 4.あるべき要件定義とは 5.要件定義を進めるマエストロの実際 6.プロフェッショナル要件定義

1.ＩＴホールディングスグループのご紹介 ＩＴホールディングスグループは、業界売上規模で独立系企業Ｎｏ．１集団です。連結５５社、従業員２０，０００人超の規模を有し、安心してお付き合いいただける企業グループです。　　　売上高３，２７４億円　　　営業利益　　１５６億円２０１１年度　実績　　　売上高３，４００億円　　　営業利益　　１７５億円２０１２年度　計画（旧旭化成子会社）（旧小松製作所子会社）業界２位 ※グラフは2009年3月期データ

企業概要 特　長概　要ＩＴのトータルカンパニー（コンサルから運用・保守までのワンストップサービス）本社所在地富山県富山市（本社）東京都江東区（東京本社）設立日１９６４年１月１１日安心のアウトソーシング（豊富なデータセンター、ネットワーク運用実績）資本金２０８億３０百万円（201２年4月現在）完全マルチベンダー（独立系企業の強みを生かした自由度の高いサービス）売上高８９４億０６百万円（2011年3月期）経常利益　２９億６３百万円（2011年3月期）先用後利（コンピュータユーティリティの実現）従業員数３，７７３名　　（2012年4月現在）質実剛健（インテックは逃げません）代表取締役社長滝澤　光樹

事業拠点 ■お客さま資産を預かる設備は、全て自社ビルにて展開しております。 ■これは、高セキュリティと高信頼性を実現するとともに、地域に根をおろしてお客さまに密着し、顧客満足度向上を目指す姿勢によるものであります。 ■電力会社との共同事業におきましても、単にテナントとして入居をするのではなく、共同出資会社を設立して運営しております。　（事業拠点数：２５、自社ビル数：１０、共同事業データセンター数：２）札幌富山本社ビル（タワー111）インテック本社前ビル（ポートラムスクエア）山形万葉スクエア(高岡) 株式会社パワー･アンド･IT 新潟ビル仙台札幌ビル武漢高岡砺波魚津上海新潟金沢富山新宿福井京都東京山口神戸横浜広島名古屋福岡大阪高松松山仙台ビル大分株式会社アット東京大阪ビル横浜ビル東京ビル新宿ビル

2.要件定義の失敗がシステム構築の失敗に直結する2.要件定義の失敗がシステム構築の失敗に直結する（１）情報システムに発生する問題　情報システム構築は失敗します。情報システム構築は約60年の歴史があり、構築を成功させるためのさまざまな情報システム開発手法が考えられてきました。また、情報システム構築は時限的な組織であるプロジェクトで遂行されるのが一般的であり、プロジェクトの管理手法や管理ツールも作られてきています。　とはいえ、どのような開発手法であれ、情報システム構築が失敗してしまうのは、さまざまな実績から明白な事実なのです。この開発手法なら絶対失敗しないということはありません。手法や手順を厳密に守って構築を進めても、失敗は起き得るのです。予測不能なトラブルが起きて、綿密な計画や手順が崩れてしまうのも情報システム構築にはよくある話なのです。－出来上がった情報システムが抱える様々な問題点－

2.要件定義の失敗がシステム構築の失敗に直結する2.要件定義の失敗がシステム構築の失敗に直結する（２）情報システムの失敗の構図 IPA SEC（独立行政法人情報処理推進機構　ソフトウェア・エンジニアリング・センター）　SODEC（2005/6/29-7/1）によるアンケート最終報告書によると、情報システム構築プロジェクトの進め方で問題と感じていることの上位には、「顧客要求が不明確のまま、進めている」「顧客要求がなかなか確定しない」「見積もり根拠が曖昧」「開発計画がずさん」などが指摘されています。その他にも「ドキュメンテーションが不十分」「プロジェクトマネージメントがなされていない」などの指摘もあげられています。

2.要件定義の失敗がシステム構築の失敗に直結する2.要件定義の失敗がシステム構築の失敗に直結する（２）情報システムの失敗の構図また、もう1つのアンケート結果によると、失敗あるいは後悔した原因のうち、要件定義にあると思う割合はというと、「失敗プロジェクトにおける原因のうち50％以上が要件定義にある」と考えているユーザが70％に達しています。また、開発ベンダーの70％もプロジェクト進行上、問題なのは「顧客要求が不明確のまま進めている」「顧客要求がなかなか確定しない」だと考えています。 ※回答数：２７０つまり、これらを分析すると、情報システム構築の失敗原因の多くは要件定義工程にあるとの結果になっているようです。

2.要件定義の失敗がシステム構築の失敗に直結する2.要件定義の失敗がシステム構築の失敗に直結する（３）実際の情報システムの失敗事例１）想定期待効果との乖離 ◆顧客概要・食品素材メーカー・国内外に営業展開 ◆プロジェクト概要　・外部要因（原料高や市場の飽和）に関する　　リスクヘッジ　→　業務標準化と効率化納期回答の迅速化のために情報システムを刷新するも効果出ず「納期回答の迅速化」を目的として情報システム構築が開始され、多少の紆余曲折はあったもののプロジェクトは順調に推移していき本番稼働を迎えました。けれども一向に以前の業務のやり方やスピード感に変化は見られません。結果、目的としていた納期回答の迅速化は実現できませんでした。最大の原因は、目的を具体的な言葉で定義し明確な数値目標に落とし込まなかったことで、各部門はそれぞれ自部門の観点で目的を捉えてしまったこと。つまり、全社最適の観点が抜け落ちてしまっていたのです。 A社では、そもそも「納期回答」という言葉を各部門がそれぞれ独自に解釈しており言葉が統一されていませんでした。販売部門・・・「お客さまから注文を受け、在庫・生産・資材調達の状況を加味してお客さまへ納期を連絡すること」生産部門・・・「販売部門から生産依頼を受け、生産状況を把握し販売部門へ製造予定を連絡すること」調達部門・・・「原材料メーカーへ発注した内容に対し、納入予定の連絡を受けること」このように「納期回答」という言葉1つとっても解釈はバラバラで、認識の齟齬があったのです。・問題点　　要件定義フェーズにおいて、言葉の定義がなされなかったことにより、各部門がそれぞれの視点で言葉を解釈してしまった。その結果、全体最適の志向が欠如し情報システムは変わっても業務の改善はなされないという結果となってしまった

2.要件定義の失敗がシステム構築の失敗に直結する2.要件定義の失敗がシステム構築の失敗に直結する２）現行と同じ要件で突き進む ◆顧客概要・住宅建具メーカー・自社工場にて押出加工 ◆システムの特徴・大型加工設備を中心とした生産管理を実施。ホストコンピュータにて、自社で手作りした生産管理システム。現行の要件が見えずに納期・費用が大幅に増加この20年間は工場の基本的な設備や業務のやり方は同じなので、要件定義の工数を削減しようという考えもあり、新しい生産管理システムの要件は現行と同じとして、要件の検討は行ないことにしました。20年前に構築された当時の現行生産管理システムのドキュメント類は見つけることができなかったため、要件定義はメンテナンス用の設計書をベースとした簡単な要件定義書を作成しただけで済ませ、開発工程を実施しました。ところが、開発工程に入ってから、20年の間に工場内の大型の生産設備は同じでも、いくつかの小型の生産設備が追加されたり、既存の生産設備に制御用のパーツが取り付けられたりしていたことが発覚しました。当然、それに伴い業務プロセスの変更も発生しています。そして、現行生産管理システムでも、それらの設備や業務プロセスの変更に対して、機能を補完したり、周辺情報システムやExcelなどの表計算ソフトを利用した手運用でのデータ連係をしたりするなど、独自の手順ができてしまっていたことが判明したのです。それらの機能も新しい生産管理システムに取り込まなければなりません・・・。結果として、要件定義の必要性が後で認識され、要件定義のやり直しによる手戻りが発生してしまいました。要件定義のやり直しがその後の開発工程にも大きな影響を与えたことは言うまでもありません。導入コストは、当初の予算より4割も増えてしまい、情報システムの稼働は半年も遅れてしまったのです。・問題点　要件定義の前提としていた「現行と同じ」は、日々業務が改善されている以上非現実的である。「現行と同じ」という言葉に惑わされ、また甘えてしまい、新しい情報システム構築では本来行うべき要件定義の手を抜いてしまう。

3.要件定義の抱えるシビアな現状 要件定義を困難にする要因としては以下のようなものがあります。（１）複雑化した要件を定義しなければならない１）情報システムを複雑化する要因　情報システムへのユーザー要求の多様化については、昨今の経済環境や業界環境の急激な変化がもたらす影響があげられます。昨今の急激な環境変化は企業に対し「いつ何が起こるか分らない」という不透明性を突きつけているものであり、いかに迅速に判断し、変化に追随していけるかが企業の存続を左右しています。つまり、自社の経営状況が現在どのような状況なのかを、迅速かつ正確に把握する必要があるのです。　また、企業内部における要因については、業務の効率化・標準化を含めた自動化や情報の連携や共有化の必要性に伴い、情報システムを活用する業務領域が企業活動のほぼ全域にわたったことが1つの要因だといえます。また、企業の競争力の源泉となる自社の業務プロセスの情報システム化や業務時間の拡大（24時間365日サービスなど）なども多様化した要因といえます。

3.要件定義の抱えるシビアな現状 ２）作成する情報システムという「製品」の特性　情報システムという「製品」は、他の製造品に比べてあまりに多様な機能が持てるのです。情報システムという「製品」は、あまりに多様な機能が持てる自動車やカメラのような工業製品と違って、物理的な制約が少ない⇒何でもできる使用目的が広範囲で、多種多様な機能を要求される使い勝手など、個人の主観的評価が入る機能も作り込める機能は、計算などの論理的な情報整理が主な役割⇒人間の論理思考のかなりの部分を実現しようとする事での複雑化

3.要件定義の抱えるシビアな現状 ３）QCDのせめぎ合い　情報システム構築に限らず、ものづくりの現場ではQCDについて必ず考慮すべき項目です。 QとはQuality（品質）であり、CとはCost（費用）、DとはDelivery（納期）であり、それぞれの頭文字を集めてQCDと呼んでいます。　情報システム構築では、QCDのどれに問題が起きても、プロジェクトの計画を抜本的に見直し緊急対策を実施しなければいけなくなりますが、中でも最も重要であり、難しいとされているのはQだと言われています。つまり費用が予算内に達成され、納期も予定どおりの期日に間に合ったとしても、品質が安定していなければその情報システムに価値はないということを意味します。　情報システムの場合のQの確保と評価は、他の製品に比べて非常に不安定と言わざるを得ません。その複雑さと要件の定義の曖昧さから、動きが「正しい」事を保障するのはなかなか難しいのです。Qの達成が困難な為にDやCに大きな影響を与えてしまうのです。

3.要件定義の抱えるシビアな現状 （２）曖昧な対応方法で臨む　ある意味で、何でもできる情報システムを作るのに、製品としてまとめていき、最終的な「決着」をつけるための制約の少ない中、複雑な機能を絞っていってまとめるだけでも大変なのです。それなのに現状は、言葉による設計指示という、ひどく曖昧な製造指図を出しているという構図になっているのです。これでは、機能の「決着」はなかなか着かず、混乱が起きるのは必定で、「正しいモノ（＝正しい情報システム）」を作るのは非常に困難な構図となっているのです。　また、作成する情報システムの全ての機能を定義しない（出来ない）というのも、情報システム構築を難しくしている要素なのです。常識的な事はあえて書かない、関係者で合意もしないという事が普通にまかり通っています。１）情報システムの「作り方」の曖昧さ情報システムの製造は、曖昧な「言葉」という道具で行われる要件の定義からプログラミングまで、「言葉」で行われる「言葉」には多義性があり、様々な解釈が可能言葉の意味は個別の文脈の中で生まれる、つまり前後の文脈により違うことも普通です。「木を植える」、「木の椅子」、「金のなる木」等々と言うとき、それぞれの「木」は同じものではありません。

3.要件定義の抱えるシビアな現状 ２）全てを決めてから作る訳ではない情報システムの製造において、「常識な事」は明確に定義されないあまりに膨大な機能を全て定義する事は不可能「言わなくてもわかる常識的な事」は関係者による暗黙の了解事項となる明らかに定義していない範囲常識な事として暗黙の了解をしている範囲情報システムの機能定義範囲イメージ信頼関係および常識で合意される範囲未定義要件が定義され合意された範囲未定義未定義言葉で明示的に定義され合意された範囲

4.あるべき要件定義とは 要件定義とは　情報システムやソフトウェアの開発において、開発前にどのような機能が発注者（顧客）から要求されていて、何が実装されるべきなのかを、条件や前提を整理しながら明確にしていく作業を指します。　要件は、開発ベンダーと発注者（顧客）の双方の理解・合意により定義が行われ、その成果は「要件定義書」としてまとめられます。　一般的なシステムの開発モデルである「ウォーターフォールモデル」では、情報システムの製造工程で変更箇所があった場合に前の工程に戻ってやり直す必要があるため、手戻りがシステム開発全体のスケジュールを圧迫する、一番の要因となっています。「ウォーターフォールモデル」は、手戻りが発生すると構築の失敗に直接つながってしまうため、開発前の要件定義が最も重要なプロセスといえます。ウォーターフォールモデル時系列要件定義手戻りによりスケジュールを圧迫外部設計工程内部設計詳細設計製造テスト

4.あるべき要件定義とは （１）要件定義の結果は曖昧であることが前提　あるべき要件定義を語る上で、その大前提は、要件定義の結果は実は「曖昧である」ということです。これは、どんな手法や手順で行っても、結果は曖昧なものしかできないという意味でもあります。　要件定義はどのようなやり方をしても、「曖昧さ」は絶対になくせないとなると、あるべき要件定義を語る上でも、まずは結果が曖昧であることは前提とすべきなのです。その上で、いかにその曖昧さの振幅を小さくするかが「あるべき要件定義」のポイントとなるのです。どこまで曖昧さの振幅を小さくできるかがポイント要件定義は曖昧である膨大な機能において、どこまでが合意されどこまでが未定義かが曖昧常識な事として暗黙で合意される範囲は、なにが常識であるかが曖昧言葉で明示的に定義される範囲にも、言葉の解釈違いによる曖昧さがある

4.あるべき要件定義とは （２）要件は合意によって作られる　情報システム構築に対する要件には絶対的なものはなく、利害関係者間の合意形成によって要件は作られると言っても過言ではありません。　つまり、合意形成されていない“要件定義書”はいくら体裁が整っていたとしても、定義するべき事柄が網羅されていたとしても、全ての利害関係者が「将来像」やそれに伴う「課題」、「解決施策」を納得していなければ不毛な交渉が発生し、膨大な戻り作業が発生することになりかねません。合意形成の種類要件を導出した人が納得せず、要件を受け入れる人の意見を聞き入れた状態（Lose-Win）要件を導出した人が意見を通し、要件を受け入れる人の意見を聞き入れない状態（Win-Lose）要件を導出した人、要件を受け入れる人の双方が納得せずに検討をあきらめた状態（Lose-Lose）要件を導出した人、要件を受け入れる人の双方が納得した状態（Win-Win）聞いていない言ったはずこんなはずではなかった一方的な合意形成では情報システム構築は失敗する。 Win-Winの合意が不可欠。

4.あるべき要件定義とは （３）要件定義の進め方にはセオリーがない　「正しい」要件定義を行うためには、その進め方が極めて重要となります。では、実際に要件定義を進めるには、どのように行えば良いのでしょうか。　実は進め方は人それぞれであり、確実に成功に導けるセオリーや手法はないというのが現実なのです。 ◆ 要件定義の手順や手法は確立されていない　　コンサルティング企業や開発ベンダーは、情報システム構築を何とか成功に近づけようと作業プロセスを定義してみたり、テンプレートを構築してみたりと試行錯誤を続けているが、いまだに情報システム構築の失敗が後を絶たない。 ◆ 要件定義は、構築する情報システムの特性や人により成否を分ける　　要件定義の手順や手法が明確であっても、それを使いこなす人や組織、構築する情報システムによって、成功したり、失敗したりを繰り返している。まったく違ったやり方をしても情報システムが正しく稼働することもあれば、他人の進め方をそのまま持ってきても上手くいかないこともある。要件定義の進め方は千差万別で人それぞれ。ニーズの聞き出しから定義内容のまとめ方、合意形成の仕方に至るまで、進めるリーダー個人のキャラクターや資質を前面に出して行うべきである。

4.あるべき要件定義とは （４）要件定義は芸術であり、進めるリーダーは芸術家（マエストロ）である　要件定義の進め方が個人の資質に依存する理由は、要件定義ではいかに関係者を巻き込み誘導していくかが重要なためだと考えられます。つまり要件定義という作業は、人と人との関係が重要であり、進めるリーダーは人の心を掴む必要があるからです。　そうであれば、要件定義はもはや芸術と同じと言えます。芸術とは人の心を掴むことが目的の作品や表現を作ることです。芸術作品を作る方法は千差万別です。芸術も個人の資質に大きく依存し、作る作品がそれぞれ違います。つまり要件定義は芸術であり、進めるリーダーは芸術家（マエストロ）と言えるのです。要件定義を行う人は、それぞれやり方が違う “芸術家” 要件定義と芸術の共通点要件定義の進め方（作る芸術作品）にマニュアルはなく、毎回それぞれ違う要件定義（芸術作品）はリーダー（芸術家）の資質や経験に大いに依存するリーダー（芸術家）は人の心を掴み、関係者を巻き込む必要がある

5.要件定義を進めるマエストロの実際 （１）要件定義マエストロ独断者タイプ・マエストロ ◆得意スキル◆ 　ファシリテーション能力は高いと思っている。基本的な筋書きは立てるが、流れに任せて議論を誘導する。意図的に論議を漂流させ、策動をかけて一気に予定の結論に導いてしまうのが得意。ディベートや議論は得意である。議論の切り返しには、ほとんどの場合条件反射的に瞬時に対応できる。切り返しの見事さと断定的な言い方でカリスマ性を感じさせることができると思っている。　流通業をはじめ各業界の企業の情報システム構築の経験から、業務のスキルもある程度あるが、どんな業界の顧客とも論理的な整理力や他業種との比較により、業務のあるべき姿についての議論ができると思っている。 ◆経歴◆ 42歳、都内の私立大学を卒業後、大手開発ベンダーに入社して19年目。SEを経て現在はプロジェクトマネージャ。SEの時代はホストシステムからC/Sシステムへの変換期であった。ここ数年は流通業界に専任し流通関係の企業のプロジェクトを担当していて、プロジェクトマネージャとして主にWeb関係の情報システムの開発に携わっている。 ◆性格／趣味◆ 何事にも前向き。義理人情に弱いところもあり、常に正しいことにこだわって物事を進めている。実は繊細なところがあるが、大らかな性格に見せている。スポーツ全般、テニス、スキー、ゴルフを嗜む。毎週末にはジムにいって汗をかいている。体力/気力には自信がある。－悩み－常に自分の仕事振りと会社の評価のGapがあると感じている。口癖は「会社には貸しがある」 ◆要件定義の進め方◆ 　ファシリテーションを重要視していて、プロジェクトの進め方も段取り重視。会議なども必ず事前準備を確認する。重要な会議は自らファシリテータを務め、都度結論を出していく。断定的なもの言いで押し切ることも多い。　議事録を重視していて、「ライブ感のある議事録を！」と重要な会議は発言録レベルを書き手に要求する。過去の議事録にて論議を制することもしばしばある。可視化資料へのこだわりは強い。また、プロジェクトの進行のためには、顧客側の役割まで踏み込むことを厭わない。顧客との役割分担は行うが、現実を見て顧客側が役割を果たせないと判断すると、積極的に顧客側の役割を肩代わりする。その対応工数は曖昧になることが多い。　手順を軽視しがちで、最初に結論ありきで決め付けで進行するケースもままある。 ◆長所・短所◆ 長所：独断的に強力にプロジェクトを進めるので、顧客側はこのリーダーが作る流れに乗れば、楽にプロジェクトが進む。そのため、このリーダーに対する信頼を持ちやすい。短所：衆知を集めて判断をしない傾向があり、リーダーの判断が正しい時は強力にプロジェクトが進むが、間違っている時はダイレクトにプロジェクトの失敗につながるケースが多い。また、細目な事項を疎かにしたためにつまずくケースもままある。

5.要件定義を進めるマエストロの実際 呪術的指導タイプ・マエストロ ◆得意スキル◆ 自分のペースに引き込む能力が高いと自負している。初対面の相手にはカマをかける。いきなりの説教や叱りつけを行い動揺させ思い通りにさせるマインドコントロールの手法に近い。独自の理論を展開し、周りのメンバーがいつの間にか納得するように進めていけるのが得意技だと思っている。また、ディベートは勝負事だという考えがあり、勝つことが重要だと思っている。噛み合った時は神がかり的に話がまとまっていき、オーラが見えると言われている。 ◆性格／趣味◆ 仕事が趣味。飲みにいった時の話題は仕事の話が中心。遊びの話をしているつもりがなぜか仕事の話になってしまう。周りには常に強気な部分を見せるが、実は意外と寂しがり屋。自分の思いを伝えて理解してくれないと不機嫌になる。議論は大好きで、すぐに議論しようとする。ただし勝たないといけないと思っている。発注者（顧客）との議論でも同様で、常に「勝ち」にこだわる。部下や後輩を指導する時は自分の経歴を引き合いに出し、マインドコントロールの重要性を教える。風貌も痩せた体躯にザンバラの長髪、鋭い目と、狂気を感じさせるようなただならぬ雰囲気（瘴気ともいえる）を醸し出している。読書は好き。でも実はスポーツも嫌いではなく、特にウィンタースポーツが好み。－悩み－自分の思いが伝わらない相手に対してどう対応したら良いかをいつも考えている。36協定が仕事の邪魔だと思っている。 ◆経歴◆ 45歳、関西地方の私立大学を卒業後、独立系開発ベンダーに入社。プログラマからSEを経て現在はプロジェクトマネージャとして活躍中。ホストシステムを主に担当し、バッチシステムからオンラインシステムへの変換期を経験している。メーカーから小売まで幅広い業界にプロジェクトマネージャとして情報システム開発に携わっている。 ◆長所・短所◆ 長所：合意をとって進めていくため、発注者（顧客）の納得感が高い。また明確に表現するため、曖昧な部分が少なく、仕様がぶれにくい。本人の気持ちが乗って、噛み合った時は思いのほか順調にプロジェクトが進んでいく。また、噛み合うタイプとは公私ともに仲良くなり、仕事を通じて長い付き合いができる人でもある。短所：決断できない相手とは噛み合わない場合がある。本人がそれを認めてしまって、気持ちが乗らなくなると悪循環を生み出し、プロジェクトは抜けないトンネルに迷い込むことになる。寂しがり屋なので、たまに何に悩んでいるのか周りがまったくわからない時がある。 ◆要件定義の進め方◆ 発注者（顧客）の合意をとることが一番優先と考えていて、どんな話があっても合意をとれたかどうかを確認する。合意をとるための段取りやネゴシエーションも重視しており、雰囲気に反して慎重なところもあるのではないかと思うような進め方をしている。また発注者（顧客）の納得感は高く、「なぜか最後は納得しているんだよね」と良いのか悪いのかわからない感想をいただくことも多い。全体的にはただならぬ雰囲気とあいまって、逆らえない迫力がある。　合意形成が重要だと思っているため、議事録や決まったことの記録についてはこだわりがある。簡潔な表現とわかりやすさについて担当者へしつこく要求することも多い。

5.要件定義を進めるマエストロの実際 朴訥粘りタイプ・マエストロ ◆得意スキル◆ 特定パッケージの導入経験豊富であり、パッケージベースでの情報システム構築が得意。地場顧客の対応経験から、多様な情報システムサービスの経験も多く、インフラからアプリケーションまで導入経験と情報に詳しい。情報システムのトレンド情報にも関心が高く、常に文献検索などでノウハウをアップデートしている。 ◆性格／趣味◆ 温厚で粘り強い。未体験のことには臆病で慎重。事前調査を徹底して行わないと取り組めない。自ら踏み込むより受け身での業務遂行が得意。生まれ育った地への愛着とこだわりが強い。容貌もスマートさのないどっしりタイプ。株やFXなどの投資が好きだが、大きな勝負はしない。少額での堅実な運用をしている。ラーメン好きで美味しい店の食べ歩きが好き。出張で見知らぬ土地にいく場合は美味しいラーメン店の事前調査を徹底する。－悩み－地方での地場の仕事が減ってきて、都会の仕事の下請け（ニアショア）の仕事が増えてきており、地方の独自性が活かせなくなってきている。自らも都会への転勤の可能性が高く、家族との関係に悩みがある。 ◆経歴◆ 44歳、地方の国立大学を卒業後、大手開発ベンダーに入社して22年目。開発ベンダーの地方センターにて地場企業の情報システムサービスや情報システム構築などを担当。プログラマからSEを経て現在はグループマネージャとして、複数の案件プロジェクトを担当。る。 ◆要件定義の進め方◆ 　過去の経験と開発手法の応じた徹底的な準備を行い、顧客との折衝に臨む。客観的データや実績、事例より対応要件を判断し、合意に導く。顧客からの想定外の反応に対しては、その場では上手く切り返したりなど臨機応変な反応できずに、打ち合わせが頓挫することもままあるが、決してメゲず時間をかけて再検討し準備した上で顧客との折衝に臨む。打ち合わせが頓挫した状況で、顧客から散々叩かれても淡々と対応し堪えない。粘り強く対応し、顧客が根負けするケースも多い。顧客との折衝において説得する語彙は十分ではないが、朴訥な雰囲気が余計な反感を招かず、そのうちには安心感を与えなんとなく話をまとめ合意してしまう。 ◆長所・短所◆ 長所：顧客とのぶつかり合いをなるべく避け、合意に導く。論破によって上から押さえつけて意見を通すのではなく、関係者の要望との折り合いを上手くつける。安心感から顧客との信頼関係を築く。既存を踏襲するケースの情報システム導入には適している。短所：臨機応変な受け答えが苦手なことと、慎重で保守的な考えが強いので顧客がサプライズするような対応ができないケースが多い。顧客から見て踏み込んだ積極的な提案や斬新なアイデアという意味では物足りなさを感じる。

6.プロフェッショナル要件定義 議論の軸となりうる情報システム構想をしっかり作っておく実体験を踏まえた要件定義のステップを以下に示します。ステップ1：　軸を設定する要件定義は曖昧なものであることを前提とし、曖昧さの振幅を小さくすることステップ2：　曖昧さへの具体的な備えをする定義できない要件（暗黙知）に備えるためには、発注者と製造者の間に深い信頼関係を築くしかないステップ3：　暗黙知への備えをする成果物をベースに議論をしないと「空中戦（噛み合わず、言いっぱなし）」になるステップ4：　徹底的に可視化する各部門のうるさ方（各部門に長い期間所属しその部門の業務に関して極めて詳しく、業務遂行のキーマン・キーウーマン）を巻き込むステップ5：　関係者を巻き込む　ステップ6：　優先度付けをし、小さく産んで・大きく育てる重要課題の解決に対する「実現性」と「効果」の2軸で要件に対し優先順位付けをするステップ7：　合意形成をする　情報システムの絶対的な要件は、「合意」によってのみ作られる

システム要件定義の実際

システム要件定義の実際

Presentation Transcript