続マジカのひみつ
マジカを使って若手に実験。なかなか興味深い結果が得られた。前回のマジカのひみつはここ。 実験対象 入社2-4年の若手社員（♂3人） SEとして分析・設計をやるかたわら、テスターとして試験もやってる java読み書きはできるが、プログラマではない 予備知識なし (゜Д゜)ハァ? まじかァ? という連中 実験1：マジカなし マジカの説明なし。ある企業の業務フローをポンと渡し、「明日このヒアリングを顧客とする、という状況で、疑問・質問・ツッコミをピックアップしてね、15分でね」 対象となった業務フローはセミナーでもらったもの。どこの企業にもある「与信業務」「受注業務」に限定して分析を行う。 マジカなしの場合、出てくる質問はさもありなんなものばかりだった。つまり、誰でも思いつく質問だし、回答する方もそれなりな準備がされているものばかり。 手続きのフォーマットはありますか? 与信の基準となるものはあ
わたしが知らないスゴ本は、きっとあなたが読んでいる: マジカのひみつ
羽生章洋さんの業務分析セミナーを聴講した（業務プロセス改善技法ワークショップ第2回）。ここで紹介されたMagiCa は「いますぐ」「ここで」「誰でも」使える方法ナリ。「MagiCa って何?」という人はここからダウンロードどうぞ（要メールアドレス）。羽生さんご本人のマジカ説明はここ。謳い文句「現場主体で仕事の棚卸と見える化を簡単に実現する」は禿同。自分なりの分析手法は確立しているんだが、上手くMagiCaを盗んでみよう。 ひみつ1 : 最初はチョキ 「さあ、業務分析しましょう」と話を持ってきても、人は動かない。現場の人はどうしても構えてしまう。「業務フロー」なんてSEやコンサルならともかく、普通の現場の仕事している人は書いたことがないから、「間違えたらどうしよう」と固くなってしまう。 凝ったココロをどうするかというと、ハサミが登場する。MagiCa はA4用紙を8分割した程度の大きさ。最初
企業の健康を診断する「業務分析」～IT技術者のための戦略・業務分析入門～
企業の健康を診断する「業務分析」～IT技術者のための戦略・業務分析入門～：事例で学ぶビジネスモデリング（4）（1/3 ページ） 企業における健康志向 皆さんは、深夜のテレビCMを見て思わず健康器具を購入してしまったとか、効果が出るかどうか分からないサプリメントに何万円も費やしてしまった経験はないだろうか。実は、企業においてシステムを構築する場合にも、これと同じようなことが往々にして起きている。競合他社がERPを導入したので自社も導入を検討するとか、コンサル会社から成功事例を聞いて、CRMパッケージの導入を決断するといった話を聞くと、個人が健康器具やサプリメントを購入する話に似ていると思うことがある。本当にその企業の健康状態に合った健康法の導入が行われているといえるのだろうか（図1）。 企業と個人の違い?企業は多くの視点・価値観の集合である? 健康法を導入する場合、個人ならば自分の考えで何を
要求開発アライアンスのビジネス・モデリング道場
要求開発とコタツモデル(2)−−アンチパターンを活用する [2008年06月17日] 前回は，要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。今回は，具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 要求開発とコタツモデル(1)−−失敗パターンに陥らないために [2008年05月29日] 今回は，要求開発アライアンスの会員にしか知られていない，プロジェクト成功のための秘訣をご紹介します。この秘訣は要求開発アライアンスの中では「コタツモデル」と呼ばれています。 目標追跡型グローバルソフトウエア生産システムを考える(2) [2008年02月28日] 前回は，機能要件を対象とした国内開発をまず先に実施し，その後オフショア拠点を利用して非機能要件を満たすフトウエアを完成させるという基本的な考え方について説明した。前
■ - ( ・ω・)ノ＜しすてむ開発。
基本設計におけるレビューの勘どころ 「考慮していない外部システムとの連携が詳細設計で見つかった」， 「仕様間の不整合が実装フェーズで発見された」――。 どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。 欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 基本設計でなにもかもすべて決められると本気で思っているのだろうか。 現実問題「要求の変化」が微塵も起こらないとでも思っているのだろうか。 基本設計時に仕様凍結できればちょっとはマシになるが、 それがユーザビリティの向上につながるわけでもないため、 結果的に使いにくいシステムを産む土壌となるもんだ。 レビューを行うことは大事。 結果をフィードバックすることも大事。 ルール付けももちろん大事。 でも現実から目をそむけるのはいかん。 最初から「承認」のために，ユーザーに
分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
システムの論理設計を構造化するための視点 - 設計者の発言
業務システムの論理設計を構造化するためのさまざまな視点がある。それらの意味合いを区別しないままに設計情報を漫然と眺めるだけでは、読み手として重要な項目を読み落とすし、設計者として複雑膨大な設計情報を「分割して統治」することにも失敗する。 「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」をとりあげて、システムのあり方を眺めるためのいろいろな視点を見てみよう。 ◆業務フローの視点で眺める ＸＥＡＤにおいてシステム定義は、ツリービュー上の「業務フロー」、「職種別担当業務」、「サーバーモジュール」の３つのまとまりとして示される。ひとつめのまとまりの「業務フロー」の下位には、「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」では「現預金口座管理の流れ」、「手形管理の流れ」、「売上収益回収の流れ」といった１６個の要素（ノード）が並んでいる。それぞれのノードを選択すると、データフローダイアグラム（ＤＦＤ）でまとめられた「業務（後
「As-is先行」か「To-be先行」か - 設計者の発言
前回、ＤＯＡとＯＯＡとの対立の話を書いたが、ＤＯＡとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「ＤＯＡ＋コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『ＤＯＡ＋コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。 ＤＯＡの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえな
ビジネス設計とシステム設計の分離は可能か？at 要求開発サミット２００６パネルディスカッション：An Agile Way：オルタナティブ・ブログ
3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。 日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。 豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。 ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データモデルのデータモデル - 設計者の発言