実践的アプローチに基づく要求仕様の発注者ビュー検討会NTTデータ（国内事業会社） 企業情報 プロフィール 社長メッセージ 役員一覧 NTTデータのテクノロジー NTTデータグループ（持株会社） 企業情報 プロフィール 社長メッセージ Our Way 役員一覧 サステナビリティ 沿革 グループ会社 協賛・文化活動 取引先企業の皆様へ NTT DATA, Inc.（海外事業会社） 企業情報
隠れていた事実が出てくる質問の仕方
「業務理解」というと，システムの設計者やベンダーの業務理解のことを思い浮かべがちであるが，私は何よりもユーザー自身の業務理解に問題があると思っている。ユーザーたちは，日々，自分たちが行っている業務をどこまで理解しているか，あるいは共通認識を持っているか，という問題である。 要求定義プロセスで十分なヒアリングができる相手というのは決して多くない。場合によってはたった一人の現場担当者からすべてを聞き出さなければならないこともある。現場は多忙だというので，もっぱら部署長がヒアリングに応じてくれることもある。 ある部品メーカーの調達システムを見直すというので，購買部長の指名でHさんが要求定義に付き合ってくれることになった。私は，別にHさんを疑っていたわけではないが，隣の部署にいるTさんにこんな質問をしてみた。 「Hさんは，購買業務全体について何％くらい把握されてますかね」 Tさんの返答はこうだった
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避する
結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小
わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき4冊目
このエントリは、「いきなりコンサルタントに抜擢されたSEが読むべき3冊」[参照]の続きになる。 「コンサルタント」と一緒に仕事をしたことがあるだろうか? 肩書だけのなんちゃって自称コンサルではなく、McKinsey & Company や accenture といった、それでメシ喰っている連中のことだ。 彼らの阿呆ほどの猛仕事ぶりは、「マッキンゼーITの本質」[参照] に書いたが、仕事の順序というか、ダンドリの要領よさについては常々不思議に思っていた。「俺たちに明日はない」という言葉がピッタリの猪突猛進なのだが、仕事のやり方は整然粛々としている。見た目のロジカルさだけでなく、コンサルティングの仕事そのものが、あたかも何かのマニュアルに従っているかのような感じがしてならなかった。 その予感はあたってた。マニュアルを見つけたんだ。それは、「情報システム計画の立て方・活かし方」。いや、その辺に転
ビジネス設計とシステム設計の分離は可能か？at 要求開発サミット２００６パネルディスカッション：An Agile Way：オルタナティブ・ブログ
3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。 日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。 豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。 ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュ
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
わたしが知らないスゴ本は、きっとあなたが読んでいる: 空気が読めないSE、話を聞かないコンサルタント
ここしばらく開発の現場を離れ、「こんさるたんと」のお手伝いをしている。彼らのやり口が分かるにつれ、これもアリなんだと納得できるようになった。一方、彼らの「実態」を垣間見て、SE/PMとしてやりきれない無力感を抱かされたことも事実。ここでは「なぜすれ違う? SEとコンサルタント」の感想文に擬装して書きなぐる。 本書によると、SEとコンサルタントの決定的な違いは2点ある。 違い1 : SEはKPI無知 目標に対しどれだけ達成できたかを測定するための指標値をKPI （key performance indicator）という。KPIは以下の4分野において設定され、モニタリングを繰り返すことで経営全体を把握する。SEはそのうち(3)のみに囚われ、全体的な視座が抜け落ちている場合が多い。 (1)財務的視点 (2)顧客の視点 (3)社内ビジネス・プロセスの視点 (4)学習と成長の視点 あるいは、SEに
ユーザ要望の聞き取り方を学ぶー究極の目的とは？：An Agile Way：オルタナティブ・ブログ
ユーザ要望の聞き取りをする場合、利用者や利用場面を聞くことは重要だ。しかし、もっとも重要なことはなんだろう？それは、そのシステムを作る目的は何か、だ。要求開発でも言われているように、「正しくない要求を正しく実装しても意味がない」。そのシステムを作る目的をはっきりさせることが、要求を聞き取る場合に最も重要なことだと思う。 目的はいくつかある、というかもしれない。では、究極の目的はなんだろう。それを聞き出す、魔法の質問がある。 作ろうと思った動機はなんですか？ この質問は、ぼくが家をたてるときにミサワホーム福井支店の営業、大野尊言さんに聞かれて、感動したものだ。ぼくは家を建てるときに、自分でラフなRFPを書いて数社に提案をお願いしようとした。他のハウスメーカーや工務店が、予算、間取り、和洋、などを聞いてきたのに対して、大野さんは、この質問をした。「家を建てようと思った動機はなんですか？」 ぼく
ユーザーと共通理解できる“システム観”が必要だ － ＠IT情報マネジメント
企業システム開発では、しばしばユーザーの思いどおりのシステムに仕上がらないことがある。その大きな原因の1つが、ユーザーの“要求”と開発者の“理解”のズレだ。ユーザーと開発者が共通認識にたどり着くには、何が必要だろうか？（→記事要約<Page2>へ） 業務システム向けの分析設計技法としてさまざまなやり方が提唱されています。有名なところがUMLを用いた「オブジェクト指向分析・設計手法」です。しかし、開発現場で実際に利用されているのは、昔から無批判に繰り返されてきた古めかしいやり方だったり、せいぜい「UMLもどき」とでもいえそうな案件ごと独自に「工夫」されたやり方です。 UMLは、バラバラだったオブジェクト指向系の表記法を統一するための体系として鳴り物入りで登場しましたが、必ずしも当初の期待どおりの効果を挙げているわけではありません。それは、システム開発においてボトルネックになっているのが「シス
@IT:要求管理ツールの賢い使い方(要求管理ツールとWord&Excelとの違い)
これまでの連載では、ソフトウェア要求管理の基本を理解していただくことを目標にして、RUPにおける要求管理の成果物とワークフローを取り上げ、要求管理の基本を解説してきました。今回はいよいよ最終回です。本連載の締めくくりとして要求管理ツールについてお話ししたいと思います。 ［注］ 要求管理ツールを説明するに当たって、要求タイプ、要求属性、トレーサビリティといった用語が出てきますので、もしこれらの言葉がぴんと来ない場合は、まずは、過去の連載を読み返してから、今回の記事をお読みになられると分かりやすいと思います。 要求管理ツールとは？ 一般的に、要求管理（requirement management）ツールというと、開発チーム内で一元的に要求を登録、編集でき、その際に、変更履歴や変更理由を記録することができるツールを指しています。また、それらの基本的機能に加えて、要求ごとに、優先度・リスク・担当者
【結果発表】意見は真っ二つに！異論・反論「RFPの作り方」
結果は，全体的には意見が二分された。ただし，発注者側は「記載すべきでない」が多く，受注者側は「記載すべきだ」が多いというように，立場により傾向が分かれる（図1）。 発注者のそれぞれの意見は，次のコメントに代表される。 【記載すべきでない派】 「ベンダーの過去の経験を買うのだから，実績あるベンダーの見積もりは安くなるはず。提案の金額にはそれを反映できるはず。だから予算を記載する必要はない」（発注者） 【記載すべき派】 「少なくともどの程度の規模のものを想定しているのかをはっきりさせなければ，レベルの全く合わない競合になってしまう。ある時，A社は1000万円，B社は1億円の見積もりを持ってきたことがある」（発注者） アンケートの結果上は，前者が多数派，後者が少数派である。実際，私が取材する限りでも，予算を記載しているRFPはあまり見たことがない。記載する/しない以前に「自力では予算を見積もれな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 要求定義のチェックポイント427: 今すぐ使える! 「見えない」顧客を知るための例文集: 本園明史: 本
Amazon.co.jp: 10の症状に学ぶ要求定義のエクササイズ136: 「妥当な解」を導くためのツールとヒント: 本園明史: 本
Amazon.co.jp: 業務別データベース設計のためのデータモデリング入門: 渡辺幸三: 本
Amazon.co.jp業務システムのための上流工程入門―要件定義から分析・設計まで
MPUF (Microsoft Project Users Forum)