要求発明学入門(2)
前回は，なぜ私たちシステム開発者が「要求の発明」にもっと関心を払うべきかについて，筆者の想いを語った。その背景には「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」という意識を開発者が強く持たなければ，顧客に心から満足してもらえる高付加価値を提供することが，今後ますます難しくなるのではないかという強い危機感がある。 しかし，いきなり「要求を発明する」と言われても，具体的に何をどうすれば良いのかをすぐにイメージできる人はそう多くはないだろう。そこで今回は，企業情報システムの開発プロジェクトにおいて，私たち開発者が「何をどうやって発明するのか」について考察することにする。 発明という言葉の意味 ほとんどの人は「発明」という言葉から，エジソンのような天才が白熱電球や蓄音機・映写機といった人々のライフスタイルを劇的に変えてしまうような画期的な発明品を創造する，中村修二氏のような企業の研究
第44回 「要求仕様」の「要求」だけがひとり歩きすると魔物に：NBonline(日経ビジネス オンライン)
納品間際にスリルとサスペンス状況 どういうわけか忙しい。などと言うと「けっこうですね」と冷ややかな視線が返ってきそうだが、これは悪い兆候である。そもそも忙しい現場などロクなことがない。理想的なのは、決して暇ではないが、時間に追われてもいない状態だろう。別に、日々定時に帰るのがベストなわけではないが、連日、深夜まで作業に追われていては、成果物の品質にも影響を与えかねない。 実際に振り返っても、納品ギリギリまで作業に追われた案件は、納得するまでテストを繰り返すこともできず、後々、さまざまな問題が発生する傾向にある。時間をかけてテストをすれば、トラブルがなくなるというわけではないが、時間がない分単純な見逃しやケアレスミスは多くなるうえ、納品時間に追い回されるスタッフのストレスはたまったものではない。 そのような話をすると「無理なスケジュールなのでは？」とか「進行管理に問題がある」などの声が上がる
第3回 相手を理解する態度が「場の空気」を良くする
顧客とのコミュニケーションで重要なことに、いかに「場の空気」を読むかがある。場の空気を良くするには、まず「聞く力」を高めることだ。一方的に話すのではなく、相手を理解しようとする態度が場の空気を和らげる。話を聞かずに主張するだけでは場の空気を悪くする。クレーム処理のときは特に注意が必要だが、真剣な姿勢を示すことで好転する。 3回目は「場の空気」を良くするにはどうすべきかをテーマに、コミュニケーションのスキルについて解説していく。最近は「場の空気」を読めない人が多い、といわれる。営業活動の場合、特に場の空気は大切な要素の一つである。 初回の顧客訪問ですぐにソリューションや見積もりの内容を説明しても、相手に受け入れられるわけがない。顧客とのコミュニケーションをスムーズにするための雑談なのに、途中で提案書を見せようとする営業部員もいる。本来なら雑談が終わり、ちょっと間合いを置いてから説明すべきだろ
データ入力によるミスを防ぐため，ユーザーに会計知識を教育
スイッチやタッチパネルなどの製造・販売を手がける日本開閉器工業は現在，基幹業務システムの運用改善を進めている。運用改善では，ユーザーのデータ入力のルールを含めた見直しを図っており，2008年3月をメドに終わらせる予定だ。 現行の基幹業務システムは1年半の開発期間を経て2006年10月に稼働した。日本オラクルのERPパッケージ「JD Edwards EnterpriseOne」が持つ会計，流通，製造の各モジュールを基に開発し，ビックバン方式で導入した。 ところが稼働後，ユーザーによるデータ入力の不整合など，運用面で様々な課題が出てきた。例えば，開発部門のある担当者が製品を試作するために，部品を購入したときのこと。試作品の部品の購入は経費として扱われるので，その担当者は新システムに経費として伝票データを入力した。試作が終わると，その部品を製造に流用することが決まった。製造で利用する部品は，製品
ITアーキテクトとして最も面白く感じること
システム開発は，「ナイスショットを連発する」ことではなく，「ミスを最小限に食い止める」ことが大事です。では，どうすればミスを最小限に食い止めることができるのでしょうか。また，そこにおいて，ITアーキテクトの果たす役割とはどのようなものでしょうか。筆者なりの考えをまとめたいと思います。 複雑さがミスを生み出す 考える材料として，「ITシステム」を取り上げます。ITシステムを単純にとらえれば，入力された情報を加工した後で出力します。こうとらえると，システム開発という作業も同じようなものといえるでしょう。入力に当たるのは，顧客が考える“欲しいシステム”。それをプログラミングという加工を施し，実際に稼働するシステムという出力を作ります。 ただ，システム開発とITシステムでは，入力・加工・出力の複雑さに大きな違いがあります。ITシステムは，決められた入力情報を決められたルールで加工し，決められた出力
【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む----積水化学の寺嶋氏がベンダーに苦言
「今のITベンダーはプログラミングを軽視しすぎている。全員がプログラマでありSEでなければ企業が喜ぶシステムは作れない」。積水化学の寺嶋一郎コーポレート・情報システムグループ長（写真）は、11月27日に開催した「IT Service Forum 2007」の講演「ITベンダーに望むこと」で、ITベンダーにこう苦言を呈した。 「システム開発でどんな技術や開発手法を使うかはアーキテクトが決める。経験上、良いアーキテクトが設計すると、開発と運用のコストを段違いに削減できる。良いアーキテクトとは、業務とプログラミングをよく知っている技術者だ」と寺嶋グループ長は話す。だが、今は「プログラミングを知らないSEが“売らんかな”でツールやパッケージの導入を目的に設計し、オフショア開発などで業務の分からないプログラマが実装している」（同） この状況を改善する策として寺嶋グループ長は「内作型開発モデル」を提唱
要求発明学入門(1)
顧客の望み通りのシステムを開発したはずなのに，なぜか満足してもらえない。彼らが語った要求はすべて正確に実現しているのに，いったい何が不満だというのだ？ そんな割り切れない気持ちを抱いた経験を持つ読者も多いだろう。 その答えは「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」というパラドックスの中に隠されている。つまり，顧客が想像すらしなかった要求を発明して提供する必要がある。今回はそんな「要求の発明」について考えてみよう。 要求の価値判断基準の把握が難しい 筆者は20年以上にわたりシステム開発に携わってきたが，顧客に心から満足してもらえる価値の高い要求を，どうやれば識別できるのかが未だによくわからない。価値が高い要求だと考えて精魂込めて作り込んだ機能が，こちらが期待するほどには喜んでもらえない。逆に，あまり価値が高くないと値踏みしていた機能が，意外なほど喜んでもらえたりする。そん
システム化範囲がぶれていれば失敗する ― ＠IT自分戦略研究所
プロジェクトの失敗例で多いのは プロジェクトの失敗で、一番多いのはシステム化範囲（スコープ）がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである。 このようなプロジェクトは昔から後を絶たないのであるが、その対策が十分に取れているとは思えない。今回は、このシステム化範囲がぶれる問題を考えていきたい。 なぜ、システム化範囲はぶれるのか システム化範囲がぶれる理由はいろいろあるが、その代表的なものを挙げてみる。 （1）「ｘｘシステム一式」という契約書は意味があるのか そもそもシステム化範囲は明確になっているのであろうか。最近私が関与した会社で、ベンダから送られてきた契約書を見せてもらったが、そこに記載された委託内容は「生産管理システム一式」という文言が1行書かれているだけであった（図1。この契約書は、一体どういう意味を持っているのであろう。確かに金額や一般的な責任は
これからは仕様を確定させてからでないとシステム開発は不可能です：東葛人的視点：ITpro
少し時間があったので「発注者ビューガイドライン」なるものを読んだ。NTTデータや富士通など大手SIerが共同で作成したものだそうで、要は顧客に分かりやすい外部設計書の書き方をまとめたものだ。「こんな“業界標準”が必要なの」とツッコミを入れたくもなったが、やはり重要だと思い直した。 外部設計書はシステム仕様のうち顧客から見た機能の定義だから、ここがいい加減だとプログラマ向けの内部設計書も作れず、システム開発なんかできないはずだ。それでもシステムを作れてしまうのが恐ろしいところで、後で顧客から「話が違う」と文句が出て、手戻りが発生、下手をすると火だるまのプロジェクトになる。だから、しっかりとした要件定義を基に分かりやすい外部設計書を作り、顧客と合意するというのは本来、不可欠な作業だ。 でも、そんなことはSIerなら先刻承知。各社とも分かりやすい外部設計書を作るノウハウを持っているだろうから、改
第12回 顧客の要望を聞き漏らさないヒアリング能力向上のコツ
提案内容の骨格とも言える顧客の要望を満たしていなければ、すべてが台なしになりかねない。その意味で、ヒアリング能力の欠如は営業担当者にとって致命的。今回は、ヒアリング能力を向上させることができるとっておきのトレーニングを紹介する。 ソリューションプロバイダで働く営業担当者はもちろん、SE（システムエンジニア）にとって、最大の関心事は提案力の強化です。先日、あるソリューションプロバイダの若手社員数人と会食する機会がありました。営業担当者やSEと職種は様々でしたが、共通する悩みは提案力の強化でした。 この席で、改めて私が感じたのはヒアリングの能力の重要性です。提案力と一口に言いますが、ヒアリングから始まり、プレゼンテーションに至るまで様々な能力が必要です。それぞれの能力が一定の水準に達していなければ、提案営業は成功しません。その中で、最も重要な能力を1つ挙げるとしたら、ヒアリング能力です。提案内
口が堅い相手も思わず「本音」をこの気配りで顧客は“懐柔”できる：ITpro
本音を引き出せなければ、顧客の課題を解決するシステムの提案はできない。にもかかわらず、顧客の中にはなかなか打ち解けてくれず、口を閉ざしたままの人もいる。そんな相手に対しても、打ち合わせの時の座席配置など、ちょっとした気配りで心を開かすことができる。 提案営業を成功に導こうと思えば、お客様が抱えている課題を正しく知らなければなりません。言うは易く行うは難し。営業担当者の多くは、お客様の課題の把握に四苦八苦しています。 営業担当者に対する信頼感がなければ、お客様が会社の内情を包み隠さず説明しようという気持ちにはなりません。ですから、営業担当者はお客様から信頼を得るため、あらゆる努力を払う必要がありますが、その一方でお客様が話しやすくなるような環境を整えることにも配慮すべきです。 では、どうすればお客様が話しやすいような雰囲気はつくれるのでしょうか。これと言った決め手はありませんが、打ち合わせや
第2回 成否のポイントは上流にあり：要求を洗い出す四つの工夫
リッチクライアントはインタラクティブな操作が可能で，表現上の演出をする余地が大きい。自由度が高いだけに，利用者はどのようなユーザー・インタフェース（UI）を実現できるかについてのイメージを持ちづらく，「使い勝手に対する要求は，具体的にモノを見ないとほとんど出てこない」（SIベンダーのクオリテック コンサルティング部 シニア・システムエンジニア 藤原誠氏）という。 しかし，いざモノを見ると，一転して利用者のイメージは広がり，あれもこれもと要求が噴出してしまいがち。「リッチクライアントを利用した開発プロジェクトにとって，最大のリスク要因は使い勝手に関する要求の管理」（日立システムアンドサービス 金融ソリューションサービス部 技師 境丈利氏）である。 つまり，リッチクライアント・プロジェクトの成否は，システム構築の上流工程にあるというわけだ。従来のシステム開発よりも，要求管理や要件定義が重要にな
スキル・レベルに応じた“値ごろ”な単価，最上級の業務改革コンサルで月額122万円
日経マーケット・アクセスが，ITpro Researchモニターに登録している企業情報システム担当者を対象に行っている月次アンケートでは，9月から12月までの4回にわたって，IT技術者の職種とスキル・レベルに見合う支払う妥当な対価，ユーザーから見て“値ごろ感がある”単価を調査する。その第１回として9月調査では，ITスキル標準（ITSS）が定義している職種のうち「コンサルタント」と「ITアーキテクト」について聞いたところ，最も高い人月単価でも“値ごろ”とされたのは「業務改革（Business Transformation）」コンサルタントのハイレベル（ITSSでのレベル5～7）で，平均約122万円だった。 この設問での「技術者の職種とスキル・レベル」の定義は，2006年10月末にIPA（情報処理推進機構）が発表した「ITスキル標準（ITSS）V2 2006」での「キャリアフレームワーク」（旧
富士通のビジネスアーキテクト、その職種の意味を読み解くと・・・
富士通で最近、「ビジネスアーキテクト」と呼ぶ職種ができた。どんな仕事だろうかと思い、富士通の人に聞いてみたら、なんだシステムコンサルタントの仕事と変わらないじゃないか。で、「なんでコンサルタントと呼ばないの」と聞いたら、「コンサルタントだと顧客に『言うだけの人』とイメージをもたれますから」との返事。なるほど・・・って納得していてはいけない。 確かにユーザー企業にはそんなイメージがあり、システム部門なんかには「エラそうなことばかり言う評論家」と目の仇にする人もいる。だけど考えてみると、コンサルタントって本来「言うだけの人」でしょ。つまりコーチ。なぜ、それがいけないのだろう。確かにろくでもないコンサルタントもいるけれど、どうもその辺りにCIOやシステム部門の了見違いがあるような気がする。 そもそもコンサルティングを依頼して意味があるのは、依頼した経営トップやCIOが自分の仕事に責任を持てる場合
ダメな要件定義は失敗開発のもと、コンピュウェアが管理製品 － ＠IT
2007/10/16 日本コンピュウェアは10月16日、システム開発の要件定義をテンプレートを使って管理する新製品「Optimal Trace 5.0」を発売したと発表した。 Optimal Traceは要件定義の管理ソフトウェア。ドキュメントや電子メールを使った要件定義や変更管理では、履歴管理やほかのシステムへの影響の分析があいまいになり、納期遅れや品質低下につながりかねないとコンピュウェアは説明。民間の調査によると、システムの欠陥の42～64％は要件管理の失敗が原因という（SEI Research Report 2004）。 Optimal Traceはシステム開発の要件定義に必要なゴールやシナリオなどの項目を設定したテンプレートを用意し、各担当者が入力することで要件定義や管理のプロセスを標準化するツール。入力された要件は構造化されデータベースに格納。設計から開発、テスト、運用までシス
コンテキスチュアル・インクワイアリーとは: DESIGN IT! w/LOVE
コンテキスチュアル・インクワイアリーとは、日本語では「文脈質問法」とも呼ばれる、観察を中心としたユーザー行動調査法の1つです。 ユーザー中心のデザイン・プロセスの初期段階での「ユーザーの利用状況の把握」に用いるユーザー調査法では代表的なものといえます。 プロセス上の位置づけを図示するとこんな感じです（詳しくは「人間中心設計（Human Centered Design＝HCD）で使う主な手法」）。 これまでこのブログではコンテキスチュアル・インクワイアリーについては、ばらばらと綴ってきましたが、このへんで１つまとめのエントリーを。 コンテキスチュアル・インクワイアリーの概要それでは、まずコンテキスチュアル・インクワイアリーの概要から。なかなか言葉だけで説明するのはむずかしいのですが、できるだけ簡潔に。 コンテキスチュアル・インクワイアリーはどのような調査法か？インタビューアが調査対象者である
人間中心設計（Human Centered Design＝HCD）で使う主な手法: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 人間中心設計（Human Centered Design＝HCD）を実施する際に用いる主な手法をちょっと整理。 これまでもユーザビリティ評価法としてのユーザーテストや、ユーザー要求の把握段階でのコンテキスチュアル・インクワイアリーなどを紹介しきてきましたが、全体像が見えないかなと思いましたので、あらためてそのあたりを整理してみようか、と。 人間中心設計で使う主な手法前にもすでに紹介していますが、ISO13407："Human-centred design processes for interactive systems"（インタラクティブシステムの人間中心設計プロセス）で国際規格化されている5つのプロセスをあらためて。 人間中心設計の必要性の特定利用の状況の把握と明示ユー
「要件定義と開発プロセスを見直し収益を改善する」、富士通のSI事業戦略
「要件定義や開発のプロセスを見直すことで、企業の無駄なIT投資を減少させる。当社のSI（システム・インテグレーション）ビジネスの収益改善にもつながる」。10月12日、富士通の宮田一雄 経営執行役生産革新本部長は同社のSI事業戦略についてこのように語った。 従来のシステム開発について宮田執行役は「要件定義・設計工程で、経営者、利用部門、システム部門の意識を統一できず、仕様の確定を先送りしてしまうことが珍しくない」と指摘。実際に、多くのプロジェクトのテスト工程で手戻りが発生しており、開発規模が人月換算で想定より25％ほど増えているという。 富士通は要件定義・設計と開発の各段階で、問題解決に向けた取り組みを実施している。要件定義・設計段階では詳細なルールを設定した。投資額が3億円以上になるSI案件については、第3者の立場で要件定義の品質を評価する。要件定義の書き方についてのガイドラインを設定し、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/habuakihiro/20071128
ワークフローエンジンを欲する前に