「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
「仕様書で駆動される生産管理システム」公開 - 設計者の発言
予定より１ヶ月遅れたが「CONCEPTWARE／生産管理」の実装作業が完了した。さっそく実案件向けに修正課題をまとめているところなのだが、とりあえず現時点の仕様で公開することにした。もう少し機能を整理する予定の暫定版をここからダウンロードできる。 OSSのパッケージシステムとして「安かろう悪かろう」などと侮ってはいけない。まずこのシステムには無償であることよりも重要な特徴がある。データモデル、業務フロー、業務マニュアル、仕様書といったドキュメントが添付されている点、そしてなによりも「仕様書を編集すればシステムの動きが動的に変化する開発基盤(XEAD Driver)」の上で実装されている点である。 "動的に変化する"という点がとくに重要で、仕様変更の過程でコードの再生成もリコンパイルも伴わない。なぜかというと、仕様書を読み込んで開発基盤そのものが変形して立ち上がる「動的制御」のしくみだからだ
もう「チーム開発」には戻れない - 設計者の発言
生産管理システムをひとりで開発しているわけだが、このやり方（おひとりさま開発）に慣れると、分業体制でのチーム開発がいかに非効率だったかがよくわかる。チーム開発は「設計・実装技術の未成熟さゆえの必要悪」だったのではないかとさえ思えてきて、仲間と和気藹々とやっていた昔の自分がなんだか恥ずかしい。 たとえば、いくらしっかり設計してもどうしても仕様変更が起こるものだが、これにともなう手戻りコストがチーム開発では想像以上にかさむ。自分で修正したほうが早いと思いつつ、変更作業のための指示を他人のためにまとめたりする。また、実装担当者の稼働率を上げるために、仕様がまだ不明確であるような機能をあえてあてがったりする。今となっては信じがたいほどの非効率だ。 また、自分で作って動かしてみなければ得られない気づきやアイデアがたくさんあるのだが、チーム開発では設計担当と実装担当が分かれていることが多い。それゆえ、
Excel方眼紙がダメな２つの理由 - 設計者の発言
悪名高い「Excel方眼紙」について、「そうそう。あのやり方は最悪だ。まだWordのほうがいい。なぜなら」なんて議論が始まったりすると残念過ぎて泣けてくる。ExcelやWordを使って仕様書を書くことの問題を、改めてはっきりさせておきたい。 私の言う「Excel方眼紙」はいくぶん象徴的な言い方である。正確に言えば、Excelを使って仕様書を書くことそのものが間違っているわけではない。Excelで書かれた仕様書の内容にもとづく「自動生成」や「動的制御」を実現しているのであれば、それはまともな職場といっていい。 そのような合理化を模索しようとせず、ExcelやWordやパワポやネット上の文書作成ツールあたりを使って仕様書を書いて、さらに別途プログラミングをやっているとすれば、大いにカイゼンの余地がある。あまりに生産性が低いし、仕様書とコードが分離しているゆえに遅かれ早かれ両者の整合性が失われる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
