« 「データモデリングライブ@渋谷」報告 | トップページ | 概念モデルと論理モデルの違い(前編) »

2012.10.10

「生産管理」で業務知識の学びを効率化しよう

 「実装スキルと業務知識を統合するために」で業務知識の重要性について説明したが、そこで「多種多様な業種に関する知識を学ぶべき」とは言っていない点に注意してほしい。その記事で言う「業務知識」とは簿記とDB設計のスキルを指している。個々の業種に関する専門知識(業種知識と呼んでおこう)についてはあえて触れていない。その位置づけと合理的な学習方法について説明しよう。

 その前に繰り返しておくが、業務システム開発者としての専門性を身につけたいと考えるのであれば、業務知識(簿記とDB設計)の学びを軽視してはいけない。若手のプログラマが、たとえばOOPの知識をさらに深めようとか、新たに関数言語を学ぼうとか、アジャイル手法をやってみたいとか考えたとしよう。彼/彼女がその時点で、簿記も知らないしDB設計も不如意だとすれば、学びの順序がおかしい。

 しつこいようだが、開発実務を2年程度経験した後で、業務知識の習得に向けて舵を切るべきだ。それが「分析・設計できるプログラマ」に成長するための画期となるからだ。アジャイル手法で活躍できる要員もそんな少数精鋭のプログラマであって、「分析・設計が得意な誰かをアテにするプログラマ」はお呼びでない。なにしろ、おひとりさま開発(実質的な開発メンバーがひとりかごく少数であるようなプロジェクト)が企画される時代だ。実装技術の進展にあわせて、そのような案件は今後増えてゆくだろう。

 さて本題の「業種知識」についてだが、簿記を学ぶ過程である程度は学べる。初学者向けの簿記のテキストでは、卸売業や小売業の取引が挙げられている。したがって簿記の学びを終えた時点(*1)で、業種知識も多少は身についていることになる。

 ただしそれらの業種知識は、あくまでも仕訳課題をこなすために「聞きかじった」程度のものでしかない。ゆえに、業務知識学習の次のステージとして、特定業種の専門知識を体系的に学ぶことをお奨めしたい。ただし、さまざまな業種について片っ端から学ぶというのでは無駄が多い。職場で強みとしている業種があればそれを学べばいいが、そういうものがなければどうしたらいいのだろう。

 じつは「生産管理」に集中するといううまい手がある。なぜか。生産管理には、取引残高管理、所要量管理、能力管理、物流管理、原価管理といったひととおりのマーケティング課題が凝縮されているからだ。「こちらを立てれば、あちらが立たない」という途方にくれるような課題がてんこ盛りである。実際に生産管理システムの開発に関わらないとしても、設計上のヒントになるイディオムが数多く含まれている。

 じっさい、私がどんな業種向けのシステムも図々しく設計できるようになったのは、ある時期に生産管理システムの開発ばかりやっていたからだ。過酷な経験だったが、その後で別の業種を扱ったとき、ほとんどのシステム要件が生産管理の応用形で解決できることに気づいた。同様の経験をした技術者は私のまわりでも少なくない。

 学習用テキストとしては、生産管理をDB設計問題として扱っているものがよい。我々は生産管理の実務家ではなく、システム設計者として課題に対峙することになるからだ。その意味で、梅田弘之氏の「グラス片手にデータベース設計」(販売管理編、生産管理編)や、拙書「生産管理・原価管理システムのためのデータモデリング」がお奨めである。簡単に頭に入るような本ではないが、DB設計を同時に学べるという意味で都合がいい。

 というわけで、雑多な業種知識を身につけるためにバタバタと足掻く必要はない。たったひとつの業種――「生産管理」について学べば、その知識の窓からひととおりの業種の課題が見渡せるようになる。もちろん、これ以外の業種知識が要らないということではないが、それらについては必要になったときに学べばいい。また、この段階に至れば実装技術を心ゆくまで深めてかまわない。「分析・設計できるプログラマ」に成長するために、参考にしてほしい。


*1.資格取得を狙うなら日商簿記3級でいい。2級は「工業簿記」を含むので生産管理の勉強になりそうに見えるが、無駄にややこしいのでソフトウエア技術者は相手にしなくていい。

|

« 「データモデリングライブ@渋谷」報告 | トップページ | 概念モデルと論理モデルの違い(前編) »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「生産管理」で業務知識の学びを効率化しよう:

« 「データモデリングライブ@渋谷」報告 | トップページ | 概念モデルと論理モデルの違い(前編) »