ダメシステムでいいじゃないか
日経コンピュータ2008年8月1日号で「ダメシステムでも使わせたら勝ち」という特集を書いた。ダメシステムという言葉は，仕様面や品質面に何らかの欠陥があるシステムという意味で使った。こういう言葉をタイトルに据えるのは，がんばってシステム構築されている方々に失礼ではないかとも考え，一度は取り下げようと思ったが，結局採用した。誤解を恐れずに言えば，今作られている情報システムはおしなべてダメシステムと言える，と思ったからだ。 考えてみてほしい。仕様面で完ぺきを目指すのはどんどん難しくなってきている。システムに会計処理しかさせていなかった大昔ならいざ知らず，今は事業の最前線でシステムを使うのが当たり前。受注が確定する前の見積もりや引き合いなども管理する。そんな領域は非定型業務だらけでシステム化しにくく，どうがんばって作っても，ユーザーから「使いにくい」と言われてしまう。 品質面でいえば，バグがないシ
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
【前編】システム部門は経営目線で企画を
技術本部長と情報システム担当を兼務する青木素直氏は、研究・開発部門で30年にわたってITを使いこなしてきた経験から、ITを駆使したものづくりの改革を推進している。現場に足を運び、標準化と共通化の重要性を訴え続けている。システム部門に対しては、御用聞きではなく、経営目線で積極的に企画してほしいと注文を出す。 多くの情報システム部門が、ユーザー部門や経営層からあまり理解されていないと悩んでいるようです。 私は2006年に情報システム担当の役員になったとき、部門長など主要メンバーを呼んで「システム部門の価値を経営陣にわかってもらおうという考えはもう不要だ」ときっぱり言いました。「私はITの価値はよくわかっているから、そんなことは説明しなくていい。その代わり経営者が欲しいと思うものを先に考えてくれ。企画の能力を持ってほしい」と言ったんです。 例えば三菱重工には13の製造拠点がある。それが各々、ばら
第4回 良いモデルの作り方
第3回では正しい概念データモデリングの方法について解説しました。第4回では，第3回で登場したD社の事例をもとに，概念データモデリングの作業内容を具体的に解説したいと思います。これまでより長い説明になりますが，ぜひ最後までついてきてください。 まず業務を理解する 概念データモデルの作成の最初のステップは，業務を理解することです。しかし，業務の理解を目的とするとき，概念データモデルでは表現する内容が細かすぎます。分析対象である帳票やエンティティを，業務理解の最初の段階で特定することは困難です。 そこで，まずはプロジェクト（構築するシステム）が対象とする業務について，「業務説明書」を作成します。 営業部 ●3月に2年分の販売計画を立案する。 生産管理課 ●月に2回，3カ月先までの月間生産計画を作成する。 ●月間生産計画の翌月，2カ月先，3カ月先分は，それぞれ顧客からの確定注文，顧客からの発注予定
上流工程の問題解決 仕様変更編【前編】
システムが以前よりも複雑化している現在，多くの開発者やユーザーは，「仕様変更がある程度起こるのは仕方がないこと」と前向きに受け止めてはいる。だが一方で，仕様変更によるコスト超過などが原因で，プロジェクトが失敗に陥ることが非常に多い。仕様変更によるトラブルを極力防ぐにはどうすればよいのか。現場担当者の知恵から解決法を探ってみた。 「設計書の50％に手を加えなければならないほど仕様変更が続出し，収拾がつかなくなってしまった」。NTTデータ東北の太田雅典氏（法人システム事業部 第一開発担当課長）は，数年前に手がけたある出版社の広告管理システムで，開発中に起こった仕様変更のトラブルを振り返る。このプロジェクトでは，設計が一通り終わり，実装（プログラミング）フェーズに入ってから，データベース（DB）の構造や，帳票出力用の計算式，他システムとの接続インタフェースなど，システムの根幹をなす仕様の変更を次
会計を学ぶなら以下の本がオススメ - oreoreoreoreの日記
朝令暮改とかこのことか！ 今さっき、「１ヶ月ブログをお休みします」とか書いておきながら、その２時間後ぐらいにこうして、また、書いているわけですがｗｗｗさっきの書いた後に、お昼を食べて、今、まなめはうすさんを見ていたら、こういうのがありました↓ 僕は、根がおせっかいなのでこういうのに脊髄反射で反応する人なんですが、会計を学ぶなら以下の本がオススメです。 「俯瞰」でわかる決算書世界一やさしい会計の本です まなめさん宛というわけではないのですが、ひょっとしたら、「実は会計の勉強したいんだけど、本とか多いし、よくわかんないんだよね」っていうニーズが何気にあるのかな、って思って、そういう方がいらしゃったら、もしよかったら、上記の本あたり、立ち読みとかしてみて下さい。「俯瞰〜」の方は、先日立ち読みしたときに良さそうな感じだったんで、試験が終わったら買おうと思っている本です。「世界一〜」の方は、以前、立
「過剰」な要求を絞り込む知恵
二つ目の仕様バグは「過剰」である。「要求を挙げていくと，100件から多いときで1000件くらいがリストアップされる」（クオリカ システム本部 第一事業部 Kプロジェクト推進部 部長 沖山英明氏）。その中には，「データの二重入力をやめたい」「新たな帳票が欲しい」「他システムと連携させたい」――といった要求が際限なく挙げられ，中には過剰と思えるものも含まれる。絞り込むにしても，むやみに減らすわけにはいかない。 過剰な要求を絞り込むには，その要求が正当なものであるかをチェックし，優先度を考える。その知恵を見ていこう。 効果は期待できるか？ 優先度を考える切り口はいろいろあるが，「答えを出すことを焦ってはいけない。解決すべき問題がどこにあるかをきちんと理解した上でないと，本当に必要な要求の絞り込みはできない」（グローバルナレッジネットワーク 事業統括本部 技術教育スペシャリスト 井澤哲也氏）。 パ
エンドユーザーの要求は間違っている？
ムラウチドットコムの橋本昌巳氏（取締役システム担当）は，自社のECサイトの構築で，かつて次のような経験をした。 ある業務担当者に新機能が欲しいと言われて開発した。しかし，その機能を使うのはその人だけで，他の人は使わない。業務改善に寄与したかどうかも結局，分からなかった。担当者が異動すると，また「違うものを作ってくれ」という要求が出てきた。要求通りの機能を追加するうちにシステムはどんどん複雑化し，保守性が悪くなった。改修のコストも徐々にかさむようになってしまった…。 。 現場を取材していると，こうした要求定義（注1）にまつわる話は事欠かない（図1）。IPA（情報処理推進機構）のアンケート調査（注2）によると，9割の企業が「失敗プロジェクトの原因は要求定義にある」と考えている。野村総合研究所の堀崎修一氏（ITアーキテクチャーコンサルティング部 主任テクニカルエンジニア）は「業務要件の詰めの甘さ
平鍋さんが指南するマインドマップの上手な書き方
ソフトウエア開発の分析/設計フェーズで利用される図と言えば，まずUML図が挙げられる。しかし，UML図を利用してエンドユーザーとスムーズに会話ができるだろうか。私はそうは思わない。実際，UMLのユースケース図やクラス図をエンドユーザーに提示したことがあるが，図の意味を理解してもらうのに時間がかかった。 エンドユーザーはソフトウエア開発が本業ではないので，それらを勉強してもらう，というのはおかしな話だ。仮にエンドユーザーがUML図を理解していたとしても，あいまいな要求を探索している，アイデアを出し合って仕様をこねている，対話をしながら合意をつくる――といった場面で，UML図は使いにくい。なぜなら，「ここは点線？ここは白抜きの矢印？」と迷いやすく，それでは思考や会話の妨げになるからだ。 それに対してマインドマップは，あいまいな要求を探索する場面で使うのに適している。人間の思考に優しく，速く描け
上流工程-要件定義---目次：ITpro
NVIDIAの時価総額が526兆円で世界首位に、生成AIが促す11年ぶりの地殻変動 2024.06.19
テクノロジー : 日経電子版
電通、三菱UFJ信託銀行など大手企業が相次ぎ参入を表明する「情報銀行」。ここに挑むベンチャー企業がDataSign（東京・渋谷）だ。同社の太田祐一社長は情報銀行という言葉が生まれる…続き 中部電力が「情報銀行」参入へ 電力データを活用 ［有料会員限定］ 「情報銀行」説明会に２００社 データ流通の枠組み始動
現場に蔓延する“ひどいRFP”
ITproの読者で「RFP（提案依頼書）」という言葉を知らない人は少ないだろう。それだけ，RFPが市民権を得た結果と言える。しかし，RFPの活用が広がる一方で，悲鳴を上げているベンダー担当者も増えているように感じてならない。悲鳴を上げているのは，コンペによって競争にさらされているからではない。“ひどいRFP”によって不当な提案を強いられたり，迷走プロジェクトに巻き込まれたりしているケースが目立つからである。 現場ではいったい何が起きているのか。記者は5月某日，RFPの読み手であるベンダー担当者3人を招いて，覆面座談会を開いた。テーマは「現場に蔓延する“ひどいRFP”」。すると，実際に出くわした“ひどいRFP”が，次から次へと挙がった。以下では，その典型パターンをいくつか紹介しよう。 ケース（1） 担当者の思いだけで記述 一つめは，担当者の“思い”だけがRFPに書かれていたケースである。大手
要求開発とコタツモデル(2)－－アンチパターンを活用する
前回は，要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。「コタツモデル」とは，ITシステム開発プロジェクトにおける，主要な三つのステークホルダーの関係性を表すメタファーです。 ビジネス戦略を決定するビジネス・オーナー（経営者や高位の責任者），実際のビジネスを遂行しているユーザー（現場担当者），そしてシステム開発担当者の三者によってシステムの目標を決定する＝一つのコタツに入って議論する状況を，要求開発アライアンスでは「コタツモデル」と呼んでいるものです。 今回は，具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 「コタツモデル」形成に王道なし，アンチパターンの活用 「（要求開発・要件定義などの）上流工程は異種格闘技戦である」──これは筆者の持論です。ITシステム開発の下流工程，すなわち設計・プログラミング・テスト・
PMBOKの次は「BABOK」が来る？
1987年に「PMI（Project Management Institute）」がプロジェクトマネジメントの知識体系「PMBOK（Project Management Body of Knowledge）」を初めて発行してから，約20年が経過した。このPMBOKに基づくプロジェクトマネジメントは，日本でも，ここ10年くらいで広く普及した。PMBOKをベースにしたプロジェクト・マネジャーの国際資格「PMP（Project Management Professional）」の日本での取得者も，2万人以上に登る。 PMBOKの登場で，プロジェクト・マネジャーの仕事は，経験とカンに頼った「プロジェクト管理」から，科学的な「プロジェクトマネジメント」へと進化した。そして，その効果は確実にあったと言える。 そして今，PMBOKに続いて，注目され始めているのが「BABOK」である。 BABOKとは，B
第35回：アジャイル開発の要求工学(要求工学：Requirements Engineering)
最近、製造業で発達したリーン生産方式に基づくアジャイル開発手法（Agile Methods）がソフトウェア開発でも注目されている。 今回は、アジャイル開発における要求工学がどういうものなのかについて紹介しよう。 アジャイル開発とは アジャイル開発では、顧客が開発者との協働プロジェクトを通じて開発者から提供される価値を理解し、満足することに注力することでソフトウェア開発のさまざまな無駄を省くことを目的としている[1]。たとえば無駄なドキュメントやコードを作らないことや、逐次的にソフトウェアをリリースして開発期間を短縮することなどの特徴がある。 幾つかのアジャイル手法が提案されているが、アジャイル手法に共通する特徴がアジャイル宣言としてまとめられている。代表的なアジャイル宣言の例を表１に示す。
［実践編］要件定義をモデル化する
開発するシステムのアーキテクチャや粒度の規定，図面など標準の整備をどのように進めたのか。今回はその過程を説明する。 実際には，これから説明するようなきれいな概念が初めから分かっていたわけではない。振り返ると何となくこういったことを行ったり来たりしながらやっていたということで，整理している。 多くのソフトウエア開発の現場では，そういったことをSE個人やチームで検討して決めている。BIGLOBEでは，これを組織単位で検討して決めることにした。検討して決めたファクトリーの五つの構造を説明する。 【構造1】四つのアーキテクチャ領域に分ける 【構造2】領域ごとにモデル化する 【構造3】ユースケースをうまく使う 【構造4】ビジネス・ルールの記述方法を決める 【構造5】要件定義をモデル化する 【構造1】四つのアーキテクチャ領域に分ける システム開発をファクトリー化するために必要な問題領域を，図のように四
業務プロセス設計作法 ～ はじめに ～ (mark-wada blog)
これから何回かに分けて、上流設計にあたる業務プロセス設計について書いてみようと思います。 以前にも「ユーザ目線のBPM」で触れていますが、より具体的な方法を提示していきたいと思っています。これまでは、どちらかというと業務フローができたら、基本的にはノンコーディングでシステム構築ができることを説明してきていますが、その上流のところの話になります。実はここが非常に重要であると同時に難しい領域なのです。 ですから、今までも再三言ってきていますように「シンプルで一貫化されたきれいなプロセス」が書けたらそれでおおかたのシステム構築が終わってしまうということになりますので、そのきれいなプロセスをどう書くかがますます大事になるのです。 そこで、この業務プロセスを書くための作法についてひとつずつエントリーしていくことにします。本技法ではつぎに示すような１６の作法からなっています。この作法に従って業務プロセ
困難な既存システムの仕様確認 要件定義中に実装を始める
1. 既存システムを廃棄しERPを導入，すべてのアプリケーションの基盤とする。 2. 画面とドキュメントをたどり，既存システムの仕様を解読する必要に迫られた。 3. 遅れを取り戻すため，要件定義の最中に一部機能の実装を開始。 「開発当時の担当者が退職してしまったので，既存システムの仕様が全く分からなかった。開発を委託していたベンダーの協力も得られなかった。その結果，新システムの要件定義に予想外の時間がかかってしまった」。 2005年2月，中小企業向けERPパッケージ「SAP Business One」をベースに，顧客管理システムを開発・稼動させた岡本昌子氏（信和総合リース 情報システム部）は，こう振り返る。同氏はプロジェクトを通して，既存システムの仕様を確認する作業に明け暮れる日々を経験していた。 会計事務所や金融機関を相手にコンサルティングや業務のアウトソーシングを手掛ける信和総合リース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 職業としてのソフトウェアアーキテクト (Software Architecture Series): スウェル,マーク (著), スウェル,ローラ (著), Swell,Marc T. (原名), Swell,Laura M. (原名), 彰,倉骨 (翻訳): 本
Amazon.co.jp: 要求定義工学プラクティスガイド: Sommerville,Ian (著), Sawyer,Pete (著), 富野壽 (翻訳): 本
