Part1 業務分析の知識体系、BABOKを理解する
20年以上にわたりシステム構築の現場で仕事をしてきた筆者の経験では、プロジェクトの失敗を探ると要件定義までの上流工程の問題に行き着くことが多い。定義した要求に過不足がある、要求の内容が誤解を生む表現になっている、整理が不十分なまま要求が個条書きされており整合が取れていない──。こうした事態が、みなさんの現場でも起こっていないだろうか。 利用部門などから要求を引き出して分析し、それを基にソリューションを立案してその妥当性を検証する。さらに、要求の変更を管理していく。ソリューション企画から要件定義までの上流工程を中心に、こうした要求にかかわる一連の作業をいかに行うかが、プロジェクト成功の大きなカギを握る。 しかし多くの現場には、要件定義までの上流工程について標準的な方法が存在せず、ITエンジニアの属人的スキルに頼っているのが実情だろう。スキルの高いITエンジニアが要件定義までの工程を担当するか
なぜアンケートで売れるキャッチコピーが書けるのか？
岡本達彦（おかもと・たつひこ） 株式会社アカウント・プラニング代表取締役 販促コンサルタント 広告制作会社時代に100億円を超える販促展開を見て培った成功体験をベースに、難しいマーケティングや心理学を勉強しなくてもアンケートから売れる広告を作る広告作成手法を日本で初めて体系化する。業界を問わず、お金をかけないで簡単にでき、即効性もあることから、全国の公的機関、経済団体、フランチャイズ本部からセミナー依頼が急増し、社内に仕組みとして取り入れたいという会社からのコンサルティング依頼は後を絶たない。著書にアマゾン上陸15年「売れたビジネス書50冊」にランクインし、販促書籍のベストセラーとなった『「A4」1枚アンケートで利益を5倍にする方法 チラシ・DM・ホームページがスゴ腕営業マンに変わる! 』（ダイヤモンド社）などがある。 売れるキャッチコピーの秘密 「広告をつくってはみたものの、まったく反応
セキュリティに関する要求の取りまとめ方
セキュリティは現在のシステム構築において，最重要課題の一つと言っても過言ではないだろう。特に個人情報などの漏えいがあった場合は，その関連部門や情報システム部門が批判されるばかりでなく，全社的に企業イメージに深刻なダメージを受けてしまう時代となった。またウイルス被害もますます甚大になってきている。それらのセキュリティに関する技術要求の具体的な例とそのまとめ方について説明していこう（図6）。 （1）セキュリティポリシー 大企業や中堅，中企業クラスの規模であれば，ほとんどの企業が全社的なセキュリティポリシーを作成しているはずだ。企業によっては全社の汎用的なポリシーとは別に情報システムに係るセキュリティポリシーを保有しているところもあるだろう。例えば，セキュリティパッチの更新基準などのルールを厳格に定めているなどだ。基本的に新システムは最低でも全社的なセキュリティポリシーの下で管理されることになる
他システムとの連携に関する要求の取りまとめ方
新たにシステムを導入する上で，必ず検討しなければならないことの一つが，既存の他のシステムとの連携の必要性である。例えば現行の基幹システムが導入から長い年数が経過し，その陳腐化への対応のために再構築（リプレース）を行う場合，再構築の範囲に入っていない周辺のシステムに注目する必要がある。基幹システムなどの場合は，他の周辺システムにデータを渡したり，その逆にデータを受け取ったりしているケースが多い。そのようなデータの受け渡しが行われている場合は，新システムにおいても当然そのデータ連携機能が必須となってくる。 これまで述べてきた技術要求と違って，他のシステムとの連携というのはほとんどの場合，発注側企業の固有の事情となる。そのため，RFPの段階であってもなるべく正確に要求を伝える必要がある。特に連携するシステムが複数ある場合などは，漏れがあったり，混同したりなどのミスがあるとベンダーの見積もりが大き
システム能力に関する要求の取りまとめ方
新システムが業務要求をすべて満たし，機能的には問題がないとしても，例えばレスポンスタイムが遅く，画面遷移の度に10秒，20秒と掛かったのでは業務システムとしては使いものにはならない。あるいは1人2人のユーザーだとサクサク動くが，同時利用ユーザー数が増えるととたんに遅くなるというシステムも役に立たない。システムの適切なパフォーマンスとキャパシティを確保するために，RFPではこれらの要求を具体的に記述するべきである。 まず，パフォーマンスに関する技術要求の具体的な例とそのまとめ方について説明していこう（図4）。 （1）画面遷移のレスポンスタイム（通常時） 一般にエンドユーザーが業務としてシステムを利用する場合，ストレスを感じない画面遷移の時間は3秒以内といわれている。これが一つの目安となろう。ただし，業務によってはもっと速いレスポンスタイムが必要な場合もあるし，逆にもう少し遅くても許容されるケ
「提案書を作るタイミングを考えた」
今回のテーマは提案書を作るタイミングです。ユーザーにインタビューをしたら次に提案書を作成して提出するという流れが普通ですが、そう単純な話ではありません。提案書はいつ作るのがよいのでしょうか。まずは、山田さんの様子を見ていきましょう。 今は午前8時前、オフィスにはまだ誰もいません。日は既に昇っていて、暖かく気持ちの良い朝です。初めて先輩の営業に同行した翌日、教えてもらったことを復習するために、少し早めに出社しました。「現場の熱気を覚えているうちに、復習しておいた方がいいよ」と五十嵐さんに言われたからです。 きのうの五十嵐さんの営業を思い出してみましたが、一点だけ納得の行かないことがありました。それは、「提案書を書きましょうか？」とお客様に聞かなかったことです。僕が勉強した営業の本には、インタビューの後は、提案書の提出と書いてあったはずです。提案は営業のメインイベント。なぜ、五十嵐さんは提案書
要件定義の勘どころ
はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか？」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 本稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル？ システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし
システムの稼働時間について利用部門と取り決めを行う工程は？
問題 問32 あるシステムの開発において、システムを24時間連続稼働させることになった。稼働時間について利用部門と取決めを行う工程はどれか。 ア システム結合テスト イ システムテスト ウ システム要件定義 エ ソフトウェア方式設計 解説と解答 システム開発の上流で行われる工程には、システム要件定義、システム方式設計、ソフトウエア要件定義、ソフトウエア方式設計、ソフトウエア詳細設計などがあり、基本的にはこの順番で行われます。「システムを24時間連続稼働させる」という稼働時間に関する運用要件は、開発対象システムにおける最も基本的で、かつ非常に重要な要件です。 そのため、システム開発の最初の段階で利用部門と協議し、システム要件として明確に定義し取り決める必要があります。したがって、稼働時間について利用部門と取決めを行う工程は、システム開発の最上流に位置するシステム要件定義です。 よって、正解は
第4回 プロセスを可視化し、業務とアプリを接続する
アビームコンサルティング フェロー 徳田 弘昭 前回は、ビジネス全体の統制を効率よく、かつ経済的に実施できるようにするための「ビジネスシステムの断絶を防ぐ6つの仕組み」を説明しました。6つの仕組みは以下の通りです。 （A）業務プロセス全体の可視化 （B）業務プロセスとアプリケーションの接続 （C）正確な稼働記録の獲得 （D）関連情報のDB化 （E）関連情報の自動獲得 （F）関連のトレースと表示 今回から具体的な説明に入ります。今回は（A）業務プロセス全体の可視化、および（B）業務とアプリケーションの接続を取り上げます。 （A）業務プロセス全体の可視化 1つ目は、企業全体の業務プロセスやルールを文書に記述し、その文書やルールを適切に維持・保守する仕組みです。既存のアプリケーション群を全社の業務プロセスに当てはめてみると、図1のように表現できます。 図1の中心を成すのは、「（全社）業務プロセス
ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
ユーザーに想像させるにはシステムの余白が必要だと思う
昨夜はタイトルを書いて、内容を考えながら寝てしまった。。。 システム構築するときに、まず初めに必要な機能の整理とかを充分にやろうとするのは、あと（納品・検収）で、それが出てきてれば完成だよね、という合理的な考えをする周りの人間に必要なだけであって、それだけのコストを掛けた企業、使うユーザーはそこで満足するわけではなく、パフォーマンスが出なければ受け入れてくれない。 一番大事なのは、ユーザーに受け入れられ、自ら使いこなすようになれることだと思います。 そう考えると、使ってみなければ、動かしてみなければ受け入れられるはずもない。 なのでまず、機能モリモリではなく、簡単なというかシンプルさを優先して芯の部分を先に作って、使ってみる、動かしてみる、想像してみる、という場面をユーザーに提供することから、システム開発はスタートするんじゃないかと思います。 うちで使っている制作作業コストを管理するシステ
要求開発アライアンス西日本勉強会#2に行ってきた。 - Fight the Future
ビジネス設計の勘所 『実践UML』などを翻訳された、依田さん。 時間短かったなあ。もっと長く聞きたかった。 ビジネス設計 = 要求開発である。 ビジョン分析をする。 プロジェクト目標設定書を作成する。 このとき、具体的な数値を設定する。 こうすることで(失礼だが)初めてお客様がイメージし始める。 要求開発の初期に作成する。 ユーザー以外の利害関係者(ステークホルダー)を調査し、意図を知る。 ビジネスのフロー、プロセスを書く。 どこから切り込めばいいか？ そのカテゴリの一般的な用語とユーザー独自の用語を対応付けて議論のきっかけにする。 フローを作成する。 ケースが多すぎて書けない？ 大抵の場合商品やユーザーで例外フローがある。 基本フローをまず押さえる。 EA(Enterprise Archtect)や旧JUDE(astah*)で清書する。 アクターを定義する。 アクターとは役割である。 シ
BABOKの現場での活用が始まった
BAのスキル強化を狙ってBABOKを活用する場合、ポイントは、システム開発プロジェクトが本来の目的に沿っているかどうかを、企画、設計、開発、運用の各段階で確認し、軌道修正する仕組みを組み込むことにある。 「BABOKでは、開発超の上流から下流に至るまで、ソリューションの妥当性や実現可能性を確認する作業が規定してある」。BABOKを規定したカナダの国際非営利団体であるIIBA（International Institute of Business Analysis）日本支部の小林正和BABOK担当理事はこう語る。 ビジネス分析の専門家を顧客との接点に どのような手法で誰がBAを実施するかについての考え方が各社によって異なるため、BABOKの活用方法も変わってくる。 ニッセイ情報テクノロジーはBAの役割を担う専門職を新設する。コンサルティング部門の社員を対象に、10月から1年間かけてBAに必要
第6回 提案力を高める要求開発のススメ
ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第6回は、第5回に引き続き提案について旅をしてみようと思います。次回は人間の活動における普遍的な成功パターンについて一般常識を超えて追求していきます。今回と次回の旅をするうちに、人間の内なる力を信じることの重要性が見えてくると思います。それでは今日も、常識の世界とは異なる不思議な思考の旅へ出発します。 僕の要求開発実践では、体験をそのまま形式知として手法化したり、手法化とまではいかないけれど図に起こしたりしながら、できるだけ形に残そうとしています。 言葉を発明する 手法化や図式化は、暗黙知を形式知に変える際の、とても重要なツールであると考えています。でもそれ以上に効果的な形式知への変換方法があります。それは、言葉を発明することです。 言葉を発明するというと大げさかもしれませんが、人は言葉によって気づき、動かされる
エンジニアがはまりやすい要件定義の失敗パターン
少し前のことだが，あるシステム・インテグレータの社内研修に1日だけ参加させてもらった。研修のテーマは要件定義。ユーザー企業の利用部門からヒアリングした業務上の問題や要望を分析し，解消すべき根本的な課題を見いだす要求分析の進め方を学ぶのが目的である。 その研修は，講義より演習が主体だった。素人の記者にはハードルが高かったが，無謀にも「ほかの方と同じように受講させてください」と頼み込んだ。要件定義の記事は何度か書いたことがあり，ちょっとした自信を持っていたのである。 演習の手始めに，架空の利用部門からヒアリングした結果という10数個の業務上の問題が題材として与えられ，他の参加者と同じく記者もその分類を試みた。「すべての問題をカバーする“巧みな分類”を考えなくては」と記者は思った。問題が起こっている場面や原因が共通する問題同士をくくり，「○○系」「××系」という具合に分類名を付けた。「これでなん
要求分析に表れるソフトウェア技術者の心
要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。 とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パスワード認証
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。