「論理設計」にこだわる利点 - 設計者の発言
業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。 １．業務構成 受注登録業務、受注保守業務、受注照会業務 ２．データ構成 受注見出しテーブル、受注明細テーブル ３．機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(
「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
あんまりプログラミングしないけどアジャイル - 設計者の発言
アジャイル開発はいわゆる「方法論」ではなく「姿勢」や「問題意識」のようなものだと説明されたりする。その割にはこの「問題意識」がプログラミングや自動テストへの奇妙なこだわりを持ち続けている点に、私は違和感を感じる。 代表的なプラクティスとして「ペア･プログラミング」が採用されたことからもわかるように、もともとアジャイル開発はプログラミングの現場で提唱され発展したものだ。「アジャイルでのプログラミングはなんだか楽しそうだ」といった印象を持たれたりもしている。 しかし、そこらへんの出自や印象についてはもう忘れたほうがいい。なぜなら、個別案件においてアジャイルであることを真摯に追求すれば「なるべくプログラミングせずに済ませるためには、どんな工夫ができるだろう」という認識に至るからだ。ゲームやＢ２Ｃやサービス系や組込系では事情は違うのかもしれないが、少なくとも私の専門である基幹システム（業務システム
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
