「生産管理」で業務知識の学びを効率化しよう - 設計者の発言
「実装スキルと業務知識を統合するために」で業務知識の重要性について説明したが、そこで「多種多様な業種に関する知識を学ぶべき」とは言っていない点に注意してほしい。その記事で言う「業務知識」とは簿記とDB設計のスキルを指している。個々の業種に関する専門知識（業種知識と呼んでおこう）についてはあえて触れていない。その位置づけと合理的な学習方法について説明しよう。 その前に繰り返しておくが、業務システム開発者としての専門性を身につけたいと考えるのであれば、業務知識（簿記とDB設計）の学びを軽視してはいけない。若手のプログラマが、たとえばOOPの知識をさらに深めようとか、新たに関数言語を学ぼうとか、アジャイル手法をやってみたいとか考えたとしよう。彼／彼女がその時点で、簿記も知らないしDB設計も不如意だとすれば、学びの順序がおかしい。 しつこいようだが、開発実務を２年程度経験した後で、業務知識の習得に
「データモデルなきアジャイル」の危うさ - 設計者の発言
例によってこれは「業務システム」に関する議論である。ゲームソフトでも組込み系でもＢ２Ｃサイトでもサービス系でもなく、販売管理システムや生産管理システムといった基幹系業務支援システム（ＤＢ構造が複雑なシステムといってもいい）に限った話だ。その種のシステムをアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 ＤＢ構造のそういった特性を公知させたのが、前回記事で説明した「ＤＯＡ（データ中心アプローチ）」だった。機能のあり方を確立したうえでデータのあ
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
個別案件にオブジェクト指向は要らない - 設計者の発言
「ウォーターフォールかアジャイルか」をはじめとして、ソフトウエア開発手法に関してさまざまな議論があるが、すべてのソフトウエアをいっしょくたにすべきではない。たとえば「ＥＣサイト」と「業務システム（基幹業務支援システム）」とは、同じ「データベースシステム」に分類可能だとしても、専門性が大きく異っている。両者をまとめて議論しても実りが多いとは私には思えない。 私の専門は「業務システム」なのだが、次のように勘定科目と密接な関係を持つ複雑なデータ構造を扱う点が特徴的である。 ＜サービス業向け販売管理システム＞ ・発注、買掛残高、仕入実績、支払 ・受注、売掛残高、売上実績、原価実績、請求 ＜物販業向け販売管理システム＞ ・発注、買掛残高、仕入実績、支払 ・受注、売掛残高、売上実績、請求 ・在庫残高、受払実績、棚卸、倉庫移動 ＜生産管理システム＞ ・発注、買掛残高、仕入実績、支払 ・受注、売掛残高、売
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
