続マジカのひみつ
マジカを使って若手に実験。なかなか興味深い結果が得られた。前回のマジカのひみつはここ。 実験対象 入社2-4年の若手社員（♂3人） SEとして分析・設計をやるかたわら、テスターとして試験もやってる java読み書きはできるが、プログラマではない 予備知識なし (゜Д゜)ハァ? まじかァ? という連中 実験1：マジカなし マジカの説明なし。ある企業の業務フローをポンと渡し、「明日このヒアリングを顧客とする、という状況で、疑問・質問・ツッコミをピックアップしてね、15分でね」 対象となった業務フローはセミナーでもらったもの。どこの企業にもある「与信業務」「受注業務」に限定して分析を行う。 マジカなしの場合、出てくる質問はさもありなんなものばかりだった。つまり、誰でも思いつく質問だし、回答する方もそれなりな準備がされているものばかり。 手続きのフォーマットはありますか? 与信の基準となるものはあ
分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
「As-is先行」か「To-be先行」か - 設計者の発言
前回、ＤＯＡとＯＯＡとの対立の話を書いたが、ＤＯＡとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「ＤＯＡ＋コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『ＤＯＡ＋コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。 ＤＯＡの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえな
ビジネス設計とシステム設計の分離は可能か？at 要求開発サミット２００６パネルディスカッション：An Agile Way：オルタナティブ・ブログ
3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。 日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。 豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。 ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
