要求定義の検討項目の主たるものは機能要求であるが，それ以外にも運用要求やセキュリティ要求，品質要求，そしてパフォーマンス要求などがある。 パフォーマンス要求は記述の方法が難しい。開発を受託する側との取り決めも容易ではない。システムのパフォーマンスに影響を与える要素の種類が多すぎるののに加え，その多くが変動したり不確定であったりするからだ。そもそも，パフォーマンスという概念があいまいである。特にオンライン・レスポンスに至っては感覚的な側面もあって，当事者間で概念を共有するのが難しい。 パフォーマンスに関する各社の態度を比べてみると二極化していることが分かる。 第一グループ・・・・ハードウエア・ベンダー，パッケージ・ベンダー 自社製品や提供するソリューションのパフォーマンスの良さを強調する態度が顕著。特に，ライバル製品に対しては決して譲らない。 第二グループ・・・・SIベンダー，ソフトウエア・

「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧

Openthologyでは，準備，立案，デザイン，シフトの四つのフェーズを定義し，段階的な詳細化，モデリングなど要求開発プロジェクトの推進をガイドします。今回は，立案フェーズの「概観ビジネスモデリング」について紹介します。 筆者は，ITコンサルタントですが，ユーザー企業の情報システム部門で十数年間システムの設計・開発に携わった経験があります。企業がIT投資の対価として求めるものは，コストの削減や付加価値の創造です。 技術の進歩やインターネットの普及によりITで実現できることが広がる中，最近では，業務の効率化，コストの削減といったテーマに加え，企業の本業に近い分野で，経営戦略に直結したビジネスシステムを構築するといったテーマが増えているのを実感します。 経営戦略の実現を支えるビジネスシステムを構築する場合，企画段階におけるシステムへの要求はあいまいである場合が多いです。この場合，経営戦略の「

金谷 敏尊 氏 アイ・ティ・アール METAグループシニア・アナリスト 大手ユーザー企業に対してIT戦略立案やベンダー選定などのアドバイスを提供する。ITインフラ，システム運用，セキュリティ分野を専門に幅広く活躍する。 企業がシステム開発や運用を外部委託する局面でベンダーに提案を求めるRFP（提案依頼書）の手法は市場に定着したといってよいだろう。ソリューションプロバイダにとってRFPは案件獲得の絶好の機会だが、同時に競争にさらされることの通告を意味する。大規模案件においては十数社もの候補を相手に、1次、2次の選考に勝ち残らなければならない。並み居る競合を差し置いて良質の案件を手中にするのは、容易なことではない。 提案を少しでも有利に進めるためにはRFPを提出した相手の事情を知っておきたい。最近は、雑誌などで特集されることもあり、RFPの一般的な評価基準はある程度予想できるようになってきた。

「ITプロジェクトの実態とは！」というエントリで取り上げられていたソフトウェア開発を皮肉った絵をきっかけに、ソフトウェア開発では30年以上も前の本が通用するという話題になっている。 http://www.dashiblog.com/blogs/000140.php http://blogs.itmedia.co.jp/kyoko/2006/10/post_54f4.html http://blogs.itmedia.co.jp/kurikiyo/2006/10/post_aa72.html http://blogs.itmedia.co.jp/himi/2006/10/post_fa30.html 実際、「十年一日のごとく進歩なし」と書いたように、ソフトウェア開発には進歩がないかのように見える。それには以下のような理由がある。 人の心は読めない ソフトウェア開発に関わる人々が学習しようとし

要求定義の手法を見直す動きが活発になってきた。これまでの開発者視点の手法では，社外ユーザー向けのシステムなどが開発しづらくなってきたからだ。旧来の手法で無理に進めれば，使われないシステムや赤字プロジェクトが増すばかり。要求工学，ユーザー中心設計，超上流など，システマティックな手法を取り入れ，いち早く要求定義の問題解決に挑んだ現場から，実践のノウハウを探った。 「システムの利用目的や対象ユーザーが大きく変わった。要求定義の認識を改める必要がある」──。30年間にわたり，情報システム部門，ユーザー，ベンダーと立場を変えながら金融システム開発の現場に携わってきたアイネスの菊島靖弘氏（金融システム本部 副本部長）は，こう警鐘を鳴らす。 帳票作成などの定型業務をシステム化していた時代，システムの利用ユーザーは発注者そのものであり，きちんと要求を語ることができた。ところが「Webシステム全盛の今は，社

日経コンピュータ副編集長，日経ビジネス編集委員， ビズテックプロジェクト担当，経営とIT新潮流2006編集 ITproの中で「ユーザー」と書けば，ITを利用する企業あるいはそこに勤務する社員を意味する。ITを生業にしている企業やそこに所属する社員をユーザーとは呼ばない。ただし，広く普及している製品を使う利用者については，所属企業を問わず，全員をユーザーと呼ぶこともある。いずれにしても，以上の言い方が許されるのはITproや日経コンピュータなど専門サイトや専門誌においてであって，一般のサイトや雑誌では通用しない。 ユーザーに対する言葉として「ベンダー」があり，ITベンダーとも書く。ITを生業にしている企業群，すなわちコンピュータ・メーカーやソフトウエア・メーカー，ソフト開発会社，コンピュータ販売会社の総称である。かつてはソフトハウス，システムハウスという言葉があったが，いつの間にか使われなく

結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。 客先での仕様調整の場で、新人が手もなくひねられている（騙されているともいう）。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。 あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っていないのはバグなんです したがって、あなたは無償で今すぐこれを実装する必要があります テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小

「自分を変えられるのは自分しかいない」。2006年9月5日，ソフトウエア開発プロセスの一つ，eXtreme Programming（XP）を提唱しているKent Beck氏を囲んで記者懇談会が開催された。自分が変われば，必ずまわりは変わる。そんな信念が感じられた懇談会だった。 Beck氏の著書である「XPエクストリーム・プログラミング入門 第2版」は「XP is about social change.」という文章で始まっている。日本語版では「XPとは社会改革のことである」と訳されているが，ソーシャルのニュアンスが少し違うという意見もある。そこでまず「XPでいうソーシャルとはどういう意味か」と質問した。 Beck氏はソーシャルの例として「14歳になる私の娘は，ある友人と1時間くらい話をし，別の友人と同じ話をまた1時間くらいする。彼女はソーシャルな子供だ」と語った。つまり「社交的」「コミュニ

前回は，「使われないシステム」が出来上がる原因が要求定義にあると考えていた折に，要求開発方法論Openthologyに出会い，筆者の悩みを解決する大きな助けとなったことを述べた。今回は，Openthologyを実際のプロジェクトに適用する際のヒントをいくつか紹介したい。 システム開発に取り掛かる前段階としての要求定義では，様々な問題が発生する。筆者がこれまで携わったプロジェクトでも，「システム化する部分ばかりに目がいって，ビジネス上のゴールまできちんと詳細化できない」「要求仕様が膨れ上がってまとめきれず，時間切れになる」といったケースがあった。問題を簡単にまとめると，以下の2つになるだろう。 (1)要求を検討する際の目的とゴールが明確になっていない。 (2)本来議論すべき対象が可視化できておらず，議論が発散する。 こうした問題を解決するために，筆者は身近なプロジェクトにOpentholog