株式会社マジカジャパンの羽生章洋が書いてるブログ:業務フローと構造化技法とマジカ！ - livedoor Blog（ブログ）
先日、ITマジカ！をリリースしました。おかげさまで滑り出しは好調です。本当にありがとうございます。さて、ITマジカ！をリリースしたことで、今まで何年間も講演などで業務フローと業務システムの関係についてお伝えしてきたことが絵面として表現できるようになったので、少し触れてみます。 現場の人にとっての関心事は「業務が回るかどうか」ということです。一方でIT化を請け負う開発者サイドは「何を作れば良いか」が関心事になります。さてここで、業務が回るというのは要するに個々人のアクティビティが滞りなく完了するということです。一段上のレイヤーにおいては業務フロー即ち全体の仕事の流れが流れることが大切なのですが、そのレイヤーに対して日常的に責任を持つ人はいないので、個別のタスクが止まらないかどうかが表面上の気になることとなります。 この個別のタスクというのは、上記の図では緑のところに該当してマジカ！で書き出し
株式会社マジカジャパンの羽生章洋が書いてるブログ:要件定義が誰でも簡単に書ける！ - livedoor Blog（ブログ）
本日から新年度に突入しました。というわけで今日は表題「要件定義が誰でも簡単に書ける！」の件。釣りじゃないです。今月中にリリースします。 弊社はマジカジャパンという社名です。マジカとはマジックカードの略で、誰でも業務フローを簡単に書くことが出来るカード形式の紙のツールです。 そして今回、同じような形で業務システムの開発にあたって不可欠な要件定義の内容を、エンジニアでなくても誰でも簡単に書けるツールを作りました。「ITマジカ！」という名前です。 ITマジカ！は、実装のアーキテクチャや言語などには依存しません。WebアプリでもメインフレームでもクラサバでもOKです。最近流行りのクラウドやパッケージの混在した業務でもOKです。既存システムのレガシーマイグレーションにも、手作業のIT化にも適用可能です。 ポイントは「コンピュータくんにどんな仕事をさせるか」という切り口で整理するというものです。あくま
新党のホームページを見てメールアドレスのチェック方法について考えた - ockeghem(徳丸浩)の日記
新政党「たちあがれ日本」のホームページが話題になっていたので私も見てみた。そして、メーリングリストの受付フォーム中に記述されたメールアドレスのチェック用のJavaScriptが気になった。以下に引用する。 if (!node.match(/^[A-Za-z0-9]+[\w-]+@[\w\.-]+\.\w{2,}$/)){ alert("e-mailアドレスをご確認ください。"); return false; } https://www.tachiagare.jp/mail.php メールアドレスをチェックするための正規表現は、ネット上でたびたび問題視される定番ネタだか、その論点は、RFC(RFC2822やRFC5322)に対して準拠しているかどうかだと思う。例えばこれ(404 Blog Not Found:「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ)。 しかし、現実に
高すぎる目標について - レジデント初期研修用資料
こんな症例検討会をやってほしい 珍しい疾患だとか、典型的でない経過をたどった症例は、しばしば「ふとしたことから一気に展望が開けたすごい症例」として、症例検討会で発表される。演者の気づきはすごいことだし、頑張って、ああなりたいなとも思うんだけれど、「僕も頑張ろう」じゃなくて、演者の気づき、「ふと」というものを、どうやったら霊感抜きで再現できるのか、同じ状況に行き当たったとき、何か特定の検査を追加したりだとか、あるいはある治療を試みて、診断的な治療を行ってしまったらどうなるのか、そういうものを、みんなで考えられたら面白いなと思う。 「ふと」の再現を一人でやると、状況ごとに提出すべき検査項目が、時間と共に、症例と共に、際限もなく増えていく。予算も時間も、採血される患者さんの血液だって有限だから、どこかで歯止めが必要なんだけれど、だったら今度は、どういう状況なら、特定の検査を提出して問題を回避でき
アジャイル開発と要件管理 - プログラマの思索
要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。 【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。 「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。 「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。 「要件」には3種類あると言う。 一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。 2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。 3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。 我々技術者が見る要件は、システム要件に相当する。 しかし、顧客と話す場合、業務要件でなければ会話ができない。 更に、
概念モデルのサンプル - Ken's Blog
概念モデルをサンプルシステムを想定して作成してみました。もうちょっと整理が必要かもしれませんが、第一版としてはこのレベルとします。この後のユースケース記述では、この概念モデルを用語集として参照します。 ポイント クラス図で作成する。 クラス図ではクラス名のみとし、属性や操作は表示しない。 関連は汎化と集約のみ。 多重度や方向などは使わない。
要求を階層化して粒度を揃える分割手法 - Ken's Blog
先に紹介した要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?にて、要求を階層化して粒度を揃えるための分割手法について説明されています。 時系列分割（時間軸分割） 構成分割 状態分割 共通分割 要求を仕様化する技術・表現する技術 要求の粒度がバラバラ（粗すぎる／細かすぎる）である場合に、上記の分割手法を用いることで適切な粒度にすることができます。また、粗い要求を分割する場合の階層の深さについては、１階層下までにすることが推奨されています。これは、階層が２階層以上深い他の要求が存在した場合、要求の漏れが検証しにくくなるためです。全体として階層化するレベルを合わせることで、要件の粒度が合っていることの確認をすることができます。
マネジメントのスピードが開発のスピードに直結する - プログラマの思索
倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! (中略) つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。 これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。 アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。