続マジカのひみつ
マジカを使って若手に実験。なかなか興味深い結果が得られた。前回のマジカのひみつはここ。 実験対象 入社2-4年の若手社員（♂3人） SEとして分析・設計をやるかたわら、テスターとして試験もやってる java読み書きはできるが、プログラマではない 予備知識なし (゜Д゜)ハァ? まじかァ? という連中 実験1：マジカなし マジカの説明なし。ある企業の業務フローをポンと渡し、「明日このヒアリングを顧客とする、という状況で、疑問・質問・ツッコミをピックアップしてね、15分でね」 対象となった業務フローはセミナーでもらったもの。どこの企業にもある「与信業務」「受注業務」に限定して分析を行う。 マジカなしの場合、出てくる質問はさもありなんなものばかりだった。つまり、誰でも思いつく質問だし、回答する方もそれなりな準備がされているものばかり。 手続きのフォーマットはありますか? 与信の基準となるものはあ
「As-is先行」か「To-be先行」か - 設計者の発言
前回、ＤＯＡとＯＯＡとの対立の話を書いたが、ＤＯＡとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「ＤＯＡ＋コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『ＤＯＡ＋コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。 ＤＯＡの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえな
アジャイル分析設計をする前に、ユースケースをひとつだけに絞り込もう - 今日の役に立たない一言 － Today’s Trifle! －
「アジャイル開発」に先行して「アジャイル分析設計」をというの記事で言っている「アジャイル分析設計」の要旨は、以下の部分にまとまっている。 ユーザーからの要望にもとづいて素早く『ユーザーが理解できるモデル』を描き広げ、それを用いて要望をより具体化しつつモデルに反映させる でもここでひとつ問題。「ユーザからの要望」というのが何なのか、ユーザ自身が分かっていないことが多いのも事実。 そしてそれを解決するには、ユースケース図をひとつだけに絞る方法がとても有効だ。ユーザはいろんなことを実現したいと思っている。でも、それらの要望の大半は、実はひとつの目的を達成するための部分集合であることが多い。たくさんの要望を俯瞰して、何を達成したいのかという目的を絞り込む。 たくさんでてきたいろんな要望は、それぞれが点として存在している。しかし、ユーザが達成したいひとつの目的がわかれば、大半の要望が線でつながる。
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
「アジャイル開発」に先行して「アジャイル分析設計」を - 設計者の発言
ソフトウエア開発の世界でアジャイル手法が注目されている。「アジャイル」というのは「俊敏な、素早い」という意味の英単語(agile)で、「アジャイル開発」とは、 ユーザーからの要望にもとづいて素早く『動くソフトウエア』を組み立て、それを用いて要望をより具体化しつつソフトウエアに反映させる といった開発スタイルを意味する。 筆者自身もアジャイル開発には共感を覚える。ユーザーが事前に表明できるシステム要件は非常に限られたもので、それに頼って仕様を固めることには無理がある。どうしても、ユーザー要件を漸進的に具体化するための「動くソフトウエア」のような仕掛けが要る。 とはいうものの、その適用に関しては疑問もある。アジャイル開発では、小さなモジュール毎の「設計・構築・テスト・評価」の繰り返し（イテレーション）で作業が進むが、そもそもその「小さなモジュール」を切り出す根拠がよくわからない。この問題はシス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
