新人技術者にはOOPLの前にDSLを - 設計者の発言
例によって、業務システム開発の世界に限った話である。ＥＣサイト開発の話でもないし、ＷＥＢサービス開発の話でもない。販売管理システムや生産管理システムといった「業務システム」の開発を専業とする企業において、新人に最初に教えるべき言語は何かという話だ。今ではJavaを教えている企業が少なくないが、OOPL（オブジェクト指向言語）のような「汎用言語」ではなく、本来は業務システム開発に特化したDSL（ドメイン特化言語）を最初に教えるべきだ。 なぜか。前回記事でも述べたように、プログラミング以外の専門分野（ドメイン）を見定めてそれを究めることが、ソフト技術者のキャリアにとっての優先課題だからだ。業務システム開発を専業とする企業に所属する技術者にとってのドメインは、基本的に「業務システム」ということになる。「業務システムの専門技術者」を育てるためということなら、OOPLではなく「業務システム向けDSL
自由であるためにドキュメントを作る - 設計者の発言
前回記事で、ドキュメンテーションを重要視しない開発業者を避けるべきだと指摘した。同様の問題は、業務システムを内製した場合にも生じている。むしろ、ドキュメントレスな困ったシステムは、内製で生み出されているケースのほうが多いような印象が私にはある。 ドキュメントレスなシステムが重大なリスクを抱えていることを、ほとんどの経営者は認識していない。なぜなら、ドキュメントレスであってもシステムのあり方は内製担当者の「頭の中」に入っているので、彼に頼めば必要な改修はやってもらえるからだ。結果的に業務システムが、担当者のエンプロイアビリティ（雇用意義）を強化するための政治的ユーティリティと化すことを許してしまう。その歪みは、担当者がいなくなったときに一挙に顕在化する。いなくなった当人としては「後は野となれ山となれ」である。 業務システムがドキュメントレスになりがちな根本的な理由は、まさにここらへんにある。
「仕様書プログラミング」とその運命 - 設計者の発言
米国の確定申告は複雑なので、確定申告用ソフトの開発が奨励され、使いやすいツールがいろいろ登場した。そのため、確定申告の有償支援サービスがあらかた要らなくなって、この５年間で８万人の公認会計士(CPA)が職を失ったという。訴求力のある専門性を持っているか、創造的な役割を果たせる会計士しか生き残れないだろうと言われている。 わざわざこんな例を挙げるまでもなく、コンピュータが人々の仕事を奪い続けてきたことは広く知られた事実である。そんな動きに関してコンピュータの売り手は「機械的で退屈な仕事は機械にまかせ、人間は創造的な活動に邁進すればよい」と語ってきた。いかにも対岸の火事を眺めるようなお気楽な言い草だし、本来は自発的であるはずの創造性の発揮が強制されるなんて勘弁してほしい。 とはいえ当然ながら、ソフトウエアの作り手にもこの「創造性の強制」は及んでいる。機械的で退屈なプログラミングがコンピュータに
トレーサビリティを確保するための便法 - 設計者の発言
「仕様書で駆動されるOSS生産管理システム」の実案件への適用を進めているのだが、その過程でさまざまな気づきがある。前回の記事に続いてもうひとつ説明しよう。生産管理システムであってもロット管理は必須ではない――という話だ。 どんなに作業を標準化したとしても、製造ロット（製造したまとまり）毎に品質特性は異なる。工程条件が微妙に異なるし、投入された資材品の品質特性も異なるからだ。ロット情報を管理することはメーカーの課題のひとつである。 ところが、ロット管理をやろうと勢いづいて在庫までをロット毎に管理しようとすると、システムは想像以上に複雑化する。まずロット別の在庫を管理するのであれば、ロットマスター（品目ロット）とともに、ロット別の内訳（倉庫在庫明細）を保持しなければいけない（図１）。 図１．ロット管理型の在庫モデル 在庫ＤＢはシステムの背骨のような要素なので、これが複雑になればシステム内のさま
超高速開発ではなく「超少人数開発」を - 設計者の発言
「超高速開発コミュニティ」が発足した。私も機会を見て参加したいと考えているのだが、それにしても「超高速開発」のキーワードは誤解を招きそうではある。その種のツールを使えば工期が半分とか３分の１になる――そのように勘違いされて導入すれば、ツールメーカーにとってもツールユーザー（開発者）にとっても残念なことになるだろう。 開発経験者はわかっているが、システム開発における律速過程は「実装」ではなく「実装されるべき仕様の確立」にある。そして、「統一感があって、有用かつフィージビリティ（実現可能性）が担保された仕様」を確立できさえすれば、どんな実装ツールを使おうがシステムはおおかた無難に完成するものだ。けっきょく「あるべき仕様がなかなか固まらない」点こそが、開発プロジェクトの慢性的な悩みのタネであって、この事実の前では「超高速に実装できる」ことの効果は案に相違して限定的なのである。 このことはドラえも
アジャイル手法は分野毎に違っていい - 設計者の発言
業務システムをいかにアジャイルに開発するか。それが私の長年の研究テーマだった。最終的にたどりついた答は「モデルシステム（設計図が添付されている動くシステム）をカスタマイズして導入する」というものだった(*1)。 それは「プログラミング・ファースト」でも「テスティング・ファースト」でもなく「ユージング(using)・ファースト」とでも呼べそうな、きわめてフロントローディングな開発スタイルである。業種・業態別のモデルシステム・ライブラリの第二弾「XEAD生産管理システム」は、OSSとして２０１３年８月に公開される。 モデルシステムのように大げさなリソースがなくてもアジャイルに開発可能なソフトウエアもあるだろう。しかし、こと生産管理システムのような「複雑なデータベース構造を核とする大規模ソフトウエア」に限れば、データベース構造が確立されたモデルシステムをカスタマイズするやり方が理にかなっている。
製造指示の設計と実装 (2)開始と完了 - 設計者の発言
前回記事「(1)日程化」では、製造指示を最小限度の手間で日程化するための枠組みを説明した。今回は製造指示を「発行」してから「完了報告」するまでの動きを見ていこう。 製造指示の日程化が完了して、指示毎の開始日が到来したならば「指示書」を発行する。指示書を印刷せずに、指示データをスマートデバイス上で眺めながら作業を進めるケースも増えてきたが、紙に印刷された指示書はまだまだ活用されている。なんといってもお手軽だし、とくに製造指示書は材料や仕掛品に添えることで物品票や「かんばん」の役目も果たしてくれる。 製造指示書には２種類ある。どの作業区でいつ作業するかを示す狭義の「製造指示書（図１①）」と、どの材料をどれだけ出庫すべきかを示す「材料出庫指示書（図１②）」だ。このシステムでは後者を発行する際に材料在庫がスキャンされ、出庫すべき材料の「候補ロット」がロケとともに印字されるようになっている。 図１
製造指示の設計と実装 (1)日程化 - 設計者の発言
現在開発中の「仕様書で動くOSS生産管理システム」から、部品表プロセッサにつづいて、「製造指示（製造指図,製造オーダとも）」について説明しよう。文字通り、具体的な製造を現場に指図したり、その実績を記録するための帳簿組織である。部品表や工程表といった基本生産情報を基礎として展開されるものだが、独特な問題を含んでいて想像以上にややこしい。しかしややこしいからこそ、適用事例を眺めておくことは意義深い。「日程化」、「開始と完了」、「外作」の３回に分けて説明しよう。 まず、基礎となる部品表と工程表のデータモデルを確認しておこう（次図をクリックすれば拡大される）。品目毎に、製造するために必要な構成品の一覧を定義したものが部品表（部品構成）で、必要な工程の一覧を定義したものが工程表（製造工程明細）である。それぞれの構成品について投入先の工程が指定されるので、両者は「品目の子テーブル」として「兄弟」である
各種技法の「競演モデリングライブ」を - 設計者の発言
年末のテレビ番組で、辛口解説でおなじみの北の富士親方が力説していた。「よく知った部屋の相手とばっかりじゃ練習にならない。他の部屋に出向いたほうがいい。本番で勝つには他流試合をもっとやらなきゃダメなんだ」。違いないと思いながらも、私は自分の仕事について考え込んでしまった。 システム開発の世界には、設計・開発技法の「流派」のようなものがある。そのこと自体は悪いことではない。いろんなやり方があることで、問題に対する検討の視野も広がろう。 残念なのは、まさに技法間の「他流試合」みたいな機会がほとんどないところだ。技法の推進者が別の技法の有効性を論難することはあっても、同一事案をネタにして公開形式で比較検討するようなことをしない。技法のコミュニティが活発だとしても、顔なじみ同士が「我らのイカしたやり方」を讃えあうばかりで、他のコミュニティにひとり出向いて技を披露するようなことをしない。北の富士親方が
「丸投げ請負」から「内製支援」へ - 設計者の発言
ジャスミンソフトの贄（にえ）氏によるブログ記事「日本のSIerは"フィックスドプライス"型契約から脱却できるか」が興味深い。ジャスミンソフトは注目の超高速開発ツール「Wagby」のメーカーである。立ち場が似ていることもあって、私としては書かれていることがいろいろ共感できる。 業界の人間が集まると景気の悪い話ばかりだ。なにしろNTTデータのトップが「SIはもう終わり」と断言するほどである。しかしくどいようだが、SIビジネスは終わりっぽいが、業務システムそのものの必要性がなくなることはない。では何が起こっているのかというと、ユーザ企業の「丸投げ委託の削減」および「内製の強化」である。 贄氏も書かれているが、丸投げ受託ビジネスは誰も幸せにしない。ベンダーにとっては黒字になりにくいし、顧客にとっては業務システムがブラックボックス化しやすい。これに代わって「内製支援」が、この業界が開拓すべきフロンテ
「データモデリングライブ＠名古屋」報告 - 設計者の発言
名古屋での初のモデリングライブでは、連休中にもかかわらず２５名の方々が集まってくださった。取り上げた題材は不動産屋さんの物件管理代行事業のためのシステムである。テーブル数もプロセス数もちょうどよい数だったと思う。 ＤＦＤとＥＲ図を比べると、ＥＲ図のタッチのほうがキレイだ。これはそのときのマーカーの書き味が良かったためである。新鮮で書き味の良いマーカーを選ぶことは、ホワイトボードを使ってモデリングするときの最強のコツである。そうすることで、モデルは「見つめていたい絵」になる。結果的に、ユーザにじっくり見つめてもらえるのでモデルとしての適切さも向上する。弘法ではないモデラーはマーカーを選ぼう。 実際のモデリングの手順は次のとおりだ。「要件定義」のための洗練された手法や「超上流」の分析作業などは要らない。だから、モデリングライブではいきなり１と２を見てもらえる。それは、３と５は「持ち帰り」でなさ
「生産管理」で業務知識の学びを効率化しよう - 設計者の発言
「実装スキルと業務知識を統合するために」で業務知識の重要性について説明したが、そこで「多種多様な業種に関する知識を学ぶべき」とは言っていない点に注意してほしい。その記事で言う「業務知識」とは簿記とDB設計のスキルを指している。個々の業種に関する専門知識（業種知識と呼んでおこう）についてはあえて触れていない。その位置づけと合理的な学習方法について説明しよう。 その前に繰り返しておくが、業務システム開発者としての専門性を身につけたいと考えるのであれば、業務知識（簿記とDB設計）の学びを軽視してはいけない。若手のプログラマが、たとえばOOPの知識をさらに深めようとか、新たに関数言語を学ぼうとか、アジャイル手法をやってみたいとか考えたとしよう。彼／彼女がその時点で、簿記も知らないしDB設計も不如意だとすれば、学びの順序がおかしい。 しつこいようだが、開発実務を２年程度経験した後で、業務知識の習得に
実装スキルと業務知識を統合するために - 設計者の発言
９０年代の後半以降、WEBアプリの実装技術が急速に発展した。そのおかげで、それまで使いにくかったHTMLページを業務システム（基幹業務支援システム）でも使えるようになった。それはそれで意義深いことではあったが、いっぽうで若手の技術者から業務知識の学習機会が奪われてしまった。いったい何が起こったのか。 ソフトウエアの適用分野毎に、技術者に求められる専門性は異なる。「組込ソフト」の分野であれば、ハードウエアの動作や利用に関するさまざまな専門知識が要るだろう。「音楽ソフト」向けには、MIDIやサウンドデータに関する専門知識が求められそうだ。業務システムの開発者であれば、いわゆる「業務知識」が求められる。具体的には、簿記、DB設計、業務プロセス設計といった知識やスキルだ。業種・業態を越えてシステム要件を仕様化するためには欠かせない素養である。 ところが現在のWEBアプリの開発現場において、日常的に
動くソフトウエアを作る前にアジャイルモデリングを - 設計者の発言
アジャイル手法は「俊敏な業務システムを作る手法」なのだろうか。それとも「俊敏に業務システムを作る手法」なのだろうか。「データモデルなきアジャイルの危うさ」でも説明したように、的外れなDB構造の見直しを促す契機をもたらさないとすれば「俊敏な業務システムを作る手法」ではない。DB構造が硬直化した業務システムは、事業の変化・発展に俊敏に追随できないからだ。 いっぽう、アジャイル手法は「俊敏に業務システムを作る手法」でもなさそうで、その過程は期待に反して鈍重である。アジャイル手法の大きな特徴が、開発対象を小さく切り出して、それ毎に短期のイテレーションを繰り返す点だ。これだけ聞けばいかにも俊敏にコトは運びそうだが、それのどこが鈍重なのか。 説明しよう。アジャイル手法では「動くソフトウエア」が重要視され、仕様の確立はこれによって駆動されると考える。ところが多くの場合、「動くソフトウエア」は「持ち帰り」
デザインパターンそのものをプログラミングする - 設計者の発言
前回記事で示したスクリーンショットはいずれも実際に動作するアプリのものなのだが、従来のように人手でプログラミングされたものではない。それらは「仕様書」としてのみ存在する。それをある種のインタプリタに渡すだけで、仕様にしたがって動作するアプリが動的に立ち上がる。コードの自動生成も伴わない。 そのインタプリタは、前回記事で説明した「デザインパターン」毎に用意されている。つまりそれらは「プログラムのパターン」そのものをプログラミングしたものである。このようなプログラミングを「メタプログラミング」という。私はこれが、業務システムの開発・保守効率を劇的に向上させる鍵のひとつだと考えている。 ■メタプログラミングの威力 なぜなら、パターンそのものをプログラミングしておけば、そのパターンに類型化されるアプリをいちいちプログラミングせずに済むからだ。個々のアプリに求められている処理要件を洞察して、対応する
特定ドメイン向け開発環境の意義 - 設計者の発言
「実行可能な仕様書」を実現したプラットフォームXEAD Driverについて、「適用分野が狭い」と言われたことがある。確かにこれを用いてゲームソフトや組込ソフトは作れないし、本来のターゲットとしている業務システムであっても金融等のクリティカル系は扱いきれないだろう。その批判は間違っていない。 しかし、そもそも私としてはEclipseのように汎用的な開発環境を作る気はなかった。だから、ウサイン・ボルト氏が「あなたは確かに速いが、そういう走り方ではマラソンでは勝てない」と言われたような気分である（たぶん）。 私が欲しかったものは、「小中規模事業所向け業務システム」の開発を支援するためのプラットフォームだ。これまで専用システムを持ちたくても持てなかった小規模事業所や、不相応にコストのかかるシステムを押し付けられてしまっている中規模事業所――そういう主体が身の丈に合った、かつコストパフォーマンスの
Excel方眼紙がダメな２つの理由 - 設計者の発言
悪名高い「Excel方眼紙」について、「そうそう。あのやり方は最悪だ。まだWordのほうがいい。なぜなら」なんて議論が始まったりすると残念過ぎて泣けてくる。ExcelやWordを使って仕様書を書くことの問題を、改めてはっきりさせておきたい。 私の言う「Excel方眼紙」はいくぶん象徴的な言い方である。正確に言えば、Excelを使って仕様書を書くことそのものが間違っているわけではない。Excelで書かれた仕様書の内容にもとづく「自動生成」や「動的制御」を実現しているのであれば、それはまともな職場といっていい。 そのような合理化を模索しようとせず、ExcelやWordやパワポやネット上の文書作成ツールあたりを使って仕様書を書いて、さらに別途プログラミングをやっているとすれば、大いにカイゼンの余地がある。あまりに生産性が低いし、仕様書とコードが分離しているゆえに遅かれ早かれ両者の整合性が失われる
たったひとりで踊るために - 設計者の発言
１人かごく少数の精鋭メンバーで業務システムを仕上げる。そのやり方を「おひとりさま開発」と呼んでいるわけだが、この手法が普及することで開発企業や技術者はさまざまな影響を受ける。それはソフトウエア技術の発展にともなう歴史的必然でもある。 なお、「おひとりさま開発」の字面だけから、それでは工期が長くなりすぎると思われたかもしれない。１００人月の仕事を１人でやれば１００ヶ月かかる計算になるが、そういう話ではない。従来よりもはるかに少ない工数と人員でしのぐための工夫やリソースの整備が肝心、という話だ。 すなわち、これまでも書いてきたように、無償か安価で手に入るモデルシステムのようなものを活用すれば、たった一人で生産管理システムを短期間でカスタマイズして納めることも可能である。このような工夫やリソースは今後、ほっといても進展してゆくだろう。こういうものを用意せずに丸腰で基幹システムをスクラッチ開発する
人海戦術から「おひとりさま開発」の時代へ - 設計者の発言
NTTデータの山下徹社長が「受託ソフト開発に寿命が来ており（いずれ）なくなる」、「受託ソフト開発会社は生き残れない。当社だって、変わらなければ生き残れない」と発言して話題になっている（受託ソフト開発会社は、もう終わり！：ITpro）。ＳＩｅｒの大元締めのようなNTTデータのトップ自らが言うのだから、業界上層部の危機感は相当なものなのだろう。 ここで注意してほしいのは、彼らのような大手SIerが言う受託開発案件が「大型案件」を意味する点だ。下請を活用した人海戦術で大型案件から利ざやを得る――そういうスタイルでＳＩビジネスは成長してきた。その結果、多重下請の裾野が海外にまでピラミッド状に広がり、多くの開発企業が薄い利益を掬い取る形の産業構造を成している。 そして当たり前のことだが、事業体が仕事を回してゆくためには業務システムが必要だ。ひとくちで業務システムといってもいろいろな形態があるが、その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
生産管理オタクは3/30に浜松へ！ - 設計者の発言