2018.04.25

新人にオブジェクト指向の魅力を知られてはいけない

 新人研修の季節に思うところを書こう。開発作業の中核として活躍するはずの中堅技術者の多くがまともにDB設計できない、という寒々した状況がある。関数従属性も移動平均単価も知らない「設計担当者」がいたりする。私にとってその原因は明らかで、80年代から90年代にかけて注目されたDB設計や業務知識の重要性を、「オブジェクト指向」が怒涛のように押し流してしまったためだ。業務システム設計にとっての「失われた10年」といっていい。

 具体的には、JavaやRubyといったオブジェクト指向言語ベースのフレームワーク(未完成な骨格のようなコード群)を用いた開発スタイルが一般的になったためでもある。その結果、新人技術者の教育がオブジェクト指向言語の一辺倒になった。同時に、クラス設計を学べばDB設計も学んだことになると勘違いされて、「実装手段から独立したDB設計の枠組み」を学ぶための気運が失われた。その結果、IDのような単独主キーだけを使うやり方が「変化に強いDB設計のコツ」とさえ思われるようになった(*1)。

■オブジェクト指向よりも大事なこと

 ゲームでも組込系でもなく、事業活動を下支えする「業務システム(基幹システム)」の開発に携わる技術者にとっては、オブジェクト指向より優先順位の高い学習課題がある。(1)簿記を含めた広範囲の業務知識、(2)関数従属性を基礎とするDB設計、(3)SQLを含めたスクリプティングである。オブジェクト指向を学ぶのは、それらの基本を身につけた後でいい。

 その順序を逆にするとどうなるか。単なる「プログラミングの枠組み」でしかないオブジェクト指向を、「森羅万象を記述可能な汎用的な枠組み」として新人が受け入れてしまう恐れがある。初恋の相手が完璧な異性に見えるようなもので、知的かつ有能であるほど、新人はオブジェクト指向の洗練された枠組みに魅了される。そうなれば、DB設計や業務知識といった学習課題が地味で退屈なものに思えてしまうだろう。

 ほうっておくと「オブジェクト指向開発の専門家になりたい」と考え始める。業務知識を学ぶことの重要性を助言しても、「そこらへんはプロダクトオーナーが補完してくれるので、自分は知らなくていい」と無視されたりする。これはおかしい。英語だろうがプログラミングだろうが、活躍できる人材はそれらのスキルの効果をレバレッジするための「専門性」を持っている。英語力ならばこれに加えて法務、経済、自然科学といった専門性が1つでもあれば食いっぱぐれない。「英語できます」だけや「プログラミングできます」だけでは心もとない。

 また、「どんなシステムもオブジェクト指向開発されるべきだ」といった思い込みに囚われたりする。簡単に開発できる手段があるにも関わらず、「そんなやり方ではユーザのきめ細かい要望に応えられない」とプログラミングすることにこだわる。喩えるなら、ふつうの表計算の課題をExcelを使わずにJavaでの手作りアプリで解決するとか、演奏音源をDAW(Digital Audio Workstation)を使わずにJavaで手作りするようなものだ。顧客の予算が少ないのであれば、コストの嵩張る手作りにこだわるべきではない。そもそも我々の仕事は、本質的には「データ処理のしくみを含む業務態勢を生み出すこと」であって、「プログラミングすること」ではない。効果的な業務態勢を生み出すためにプログラミングが必要かどうかは些末な問題だ。

■オブジェクト指向の使いどころ

 オブジェクト指向が重要でないという話ではない。ExcelやDAWのようなDSP(Domain Specific Platform,ドメイン特化プラットフォーム)の開発に、これほど有効な手段はない。これまはた、オブジェクト指向開発されるDSPが強力な実装手段であるゆえに、それが既に存在する分野(domain)で案件をオブジェクト指向開発するというのは、よほどの理由がなければ経済合理性がないということでもある。

 考えようによっては、「DSPに侵されていない分野」の案件をオブジェクト指向開発するという行き方もある。しかし、経済活動としてじゅうぶん活発であれば、どんな分野でも遅かれ早かれDSPは生み出される。じっさい、かつて業務システム開発向けのDSPは明確な形では存在しなかったが、無粋にも”超高速開発ツール”と呼ばれるDSPがこの世界でも普及しつつある。「DSPに侵されていない分野」に逃げ込むばかりでは何やら幸先が悪い。

 そんなことを言われても、自社の開発用フレームワークがJavaベースなので、自分はオブジェクト指向を学ばざるを得なかったし、日常的にオブジェクト指向開発している――そのように思う向きもあるかもしれない。それで安く早く使いやすいシステムを顧客に提供できているのであれば問題ない。しかし現時点でそうであるとしても、今後、DSPを駆使する同業他社とのコンペやオーディションで勝てるとは限らない。

 そんな技術者には提案したい。身につけたオブジェクト指向のスキルを用いて、自社の言語ベースのフレームワークに置き換わるDSPを開発してほしい。オブジェクト指向を意識せずに、「プログラム仕様書」を書くだけでそのままアプリとして動作する。そんな開発基盤を開発するのである。オブジェクト指向言語なしでは到底生み出せないし、ワクワクさせられる創造的な仕事だ。

■DSPは最強のITソリューション

 難しそうに思えるかもしれないが、そういった動きは決して珍しいものではない。私自身は「DSPを駆使する開発者」兼「DSPの開発者」であるのだが、同じ立場で活躍している友人が多い。彼らは与えられた仕事をこなすだけでなく、自分たちの仕事をITで効率化するために果敢に行動を起こした技術者たちだ。自分の専門分野に限っても、生み出されるアプリは多種多様である。ところが彼らは、その中に含まれるパターンを識別して、それらにもとづいてアプリを記述するためのDSL(Domain Specific Language,ドメイン特化言語)が想定可能であることに気づいた。

 そういった「抽象的な構造」を洞察できるということは、ソフトウエア技術者として筋がいい。彼らにとってオブジェクト指向は難しいものではないし、わざわざ教えなくても勝手に習得してしまう。結果的に彼らは、自社事業を抜本的に合理化するための「オブジェクト指向を用いた最強のITソリューション」を生み出した。ここで大事なのは、DSPを生み出す時点でその分野固有の専門性を彼らが身につけていたことだ。そうでなければ、オブジェクト指向の知識の有無とは関係なく、DSLを的確にデザインできない。

 自分の専門分野向けのDSLを構想できる――そう思えた時点でオブジェクト指向を学んでもまったく遅くない。むしろその順序のほうが、DSPを生み出せる段階に着実にたどりつけるだろう。なぜか。前述したように、オブジェクト指向は個々の分野で求められる地味な専門性と比べてあまりに魅力的だからだ。それゆえ、将来有望な新人にオブジェクト指向の美しさを知られてはいけない。ましてや、他に学ぶべきことの多い子供たちにそれを教えるべきではない。


*1.「データ要件の変化を抱擁する」ためにすべての主キーを"ID"にするやり方のこと。実態としては「データ要件が変わった」のではなく、大抵は「関数従属性にもとづくデータ要件の洞察に失敗した」に過ぎない。喩えるなら、「構造計算なんて面倒だしアジャイルさに欠ける。柱には鉄筋を1本ずつ入れるようにすれば施工はずっと楽だ。階数が増えてビルが傾いたなら鉄筋を増やせばいい」と考えるようなものだ。アジャイル手法が許されるのはUIまわりだけで、広域での整合性が求められるDBの設計をアジャイルに進めてはいけない。また、RDBをオブジェクトIDで識別されるオブジェクトの保管先とみなしてはいけない。

| | コメント (0) | トラックバック (0)

«対談イベントのお知らせ