木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
すごい現場
皆はどんな現場で，どんな仕事をしているのだろう。何に悩み，どうやって乗り越えているのだろう。プロの仕事とそうでない仕事の境目はどこにあるのだろう。システム開発や運用の現場を歩き，そこで見聞きした面白い話，感動的な話，すごい話を紹介します。 ・大企業からベンチャーまで ぼくはこんな現場を歩いてきた ・SEを潰した値引き 信頼も連帯感も消えた ・期限は明日――若手SEの気迫を見た ・寝不足のプレゼン ドリンク剤も効かず ・中国の開発現場もすごい 若き社長が率いる修羅場 ・オンラインダウン発生！ あの日，何もできなかった ・建築設計事務所で見た 巨匠のすごいレビュー ・コンサル泣かせの現場 “小さな王国”の弊害 ・逝去した巨匠への追悼 感激したあの言葉 ・人の話を聞かない40代 あるコンサルの失敗 ・過ぎたるは及ばざるがごとし 作りすぎたRFPの悲劇 ・人間万事塞翁が馬 得難いレクチャーの裏事情
特集2 ユーザーの本音を掘り出し，合意に導くヒアリングの技術
図3 ユーザーの協力を得られるようにヒアリングの場の冒頭で伝えるべきこと<br>上司に言われてヒアリングの場に来たユーザーは，趣旨を理解していなかったり，“やらされ感”にとらわれたりしがちだ。そこで，ユーザーに積極的に協力してもらえるように，ヒアリングの場の冒頭で伝えるべきことを挙げた。(1)(2)(5)はやる気を高める，(2)～(4)は何を話せばよいか分かるようにする，という効果を狙ったものである ITエンジニアにとってヒアリングとは，ユーザーとのコミュニケーションの根幹を成す。難しい合意形成の成否も，聞き方一つで大きく変わる。 第一線で活躍するIT エンジニアやコンサルタントが現場で培ったヒアリングのテクニックをまとめた。 日本ヒューレット・パッカード（HP）の伊吹進吾ITコンサルティング本部エクスプレスサービス部コンサルタントは，ヒアリングに関する苦い経験を忘れられないでいる。 5年
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
