"実行可能な仕様書のライブラリ"を知的社会資本に“実行可能な仕様書”を作る!(3)(3/3 ページ)

» 2011年09月28日 12時00分 公開
[渡辺 幸三,@IT]
前のページへ 1|2|3       

「実行可能な仕様書」のライブラリ

 レファレンスモデルをまとめるだけでなく、筆者はアプリケーションドライバの開発に当たって、すでに公開しているモデル「CONCEPTWARE/販売管理」をその上で実装することを決めていた。この程度のレファレンスモデルの実装を支えることができなければ、まともな開発基盤と言えないと考えたからだ。

 「CONCEPTWARE/販売管理」が本格的な業務システムのレファレンスモデルだったおかげで、XEAD Driverは開発基盤としてよほど実用的なものになったと思う。それだけでなく、レファレンスモデルそのもののブラッシュアップにもなった。なぜなら、実装して実際に動かす過程で、設計上の無理や不具合が見つかったからだ。もちろんそれは基本的には私自身の設計者としての未熟さゆえなのだが、前述したように、動かしてみないと分からない設計上のバグは、実際の開発においてもどうしても見つかってしまうものだ。

 それゆえレファレンスモデルは本来、実装の試みを通じてその設計品質が検証されるべきものなのだと気づかされた。その意味では、「CONCEPTWARE/販売管理」はようやく「実装検証済マーク付き」として自信を持っておすすめできるようになったと言える。

 こういうものを開発案件の起点とすることで、開発効率はますます向上する。開発スタイルは努力せずとも「アジャイル化」する。中小零細企業や被災企業がシステムを手軽に立ち上げるためにも役立つ。自治体システム向けのものがあれば、行政コストの無駄も是正される。技術者がさまざまな業務知識を学ぶための教材としても優れている。このスタイルが日本で定着すれば、世界に範を示せるだろう。

 なお現在、何人かのボランティアの方々が「販売管理システム」の検証に協力してくださっている。それが済めば、続いて「CONCEPTWARE/生産管理」を実装する予定だ。また、レファレンスモデルそのものを新たにまとめたり、それを実装して公開する行為がそのまま技術力のアピールになる。腕に自信のあるSI企業や技術者はぜひ挑戦してほしい。

 そんな風に「業種別実行可能仕様書ライブラリ」が拡充されていけば、日本のシステム開発のスタイルが一変すると私は確信している。それらのライブラリが「知的社会資本」として国の経済活動を支えてくれるだろう。システム開発をギャンブルにしてしまっているような業界ではなく、少なくとも経済活動の足を引っぱらない業界でありたいと思う。

「優れた単能工」ではつとまらない

 「実行可能な仕様書ライブラリ」のようなものが充実してくれば、内製化、すなわちユーザー企業が独力で業務システムを組み上げることもずいぶん楽になるだろう。なぜならそこに所属するソフト技術者であれば、自社のシステム要件を熟知しているからだ。

 では、業務システム開発を専業にしているSI企業に所属する技術者はどうか。彼らにはどちらかといえば厳しい現実が待っている。

 システム開発においてもっとも困難な過程は、コンピュータによるデータ処理に関してど素人のユーザーからシステム要件を聞き出し、それをDB構造やプログラムの仕様に落とし込むことだ。「実行可能な仕様書ライブラリ」が充実していたとしても、それを個別案件向けにカスタマイズして整合性の取れた形で仕上げるためには、新規開発時と同様の分析・設計・実装スキルが求められる。

 しかもそれらのスキルが、技術者1人の中で確立されていなければならない。なぜなら、合理化された開発基盤においては、プロジェクトの規模がごく小さくて済むからだ。前回で説明したように、少数体制では「不得意分野を補完し合う」ような温情あふれるやり方が通用しなくなる。1人1人が「多能工」でなければならない。プロジェクトを完遂するために必要なスキルセットを、少人数でまかなわなければいけないからだ(図5)。

ALT 図5 要員が少ないほど多能工であることが求められる

 ところがSI企業に所属する技術者の多くは、大手であるほど「プロジェクト管理技術の専門家」のようになってしまっている。実質的な分析・設計スキルは小さな関連会社に所属する古参技術者に頼り、実装スキルについては単価の安いオフショアの技術者に頼っている。要するにSI業界の技術者の多くが「単能工」として成熟しかかっている。

 そのありようは、システム開発の生産性が低い時代に「人海戦術」で仕事を進めるには理にかなった分業体制ではあった。しかし、さまざまな形で合理化や技術革新が進展するほどに、開発体制は「少数精鋭」を指向せざるを得ない。そのときに技術者が「単能工」であることがアダになる。

 重要な論点なのでもう一度繰り返そう。システム開発の生産性が向上することで、プロジェクトに必要とされる技術者の人数が極端に減る。メンバーが実質的に1名のようなプロジェクトも珍しくなくなる。その結果、1人1人の技術者が「多能工」であることが強いられる。求められるスキルはざっと以下の通りだ。いずれも一朝一夕で身につくものではないし、これら以外に成熟した言語能力や社会性も求められる。

  • 業務知識(簿記やドメインの知識)
  • 分析・設計スキル(DB設計、業務設計、機能設計のスキル)
  • 実装スキル(インフラ設定やプログラミングのスキル)

 これらのいずれかだけが得意であるような「優秀な単能工」にとっては、開発生産性が高められた状況というものは想像以上に厳しい。ゆえに技術者は「優秀な単能工」ではなく、せめて「そこそこの多能工」になるための努力を惜しんではならない。とりあえず「設計できるプログラマ」を目指そう。

革新的技術の冷酷さとカッコよさ

 実際に「CONCEPTWARE/販売管理」に基づいて作られた「実行可能な仕様書」とその実行イメージとを並べて眺めてみよう(図6、7)。これらだけ見れば、個別のユーザー企業向けにアジャイルにカスタマイズすることもそれほど難しくないように思えるかもしれない。何しろ仕様書を修正するだけでシステムがダイナミックに変化するのだから。

ALT 図6 「CONCEPTWARE/販売管理」に基づいて作られた「実行可能なメニュー仕様書」とその実行イメージ(クリックで拡大
ALT 図7 「CONCEPTWARE/販売管理」に基づいて作られた「実行可能な機能仕様書」とその実行イメージ(クリックで拡大

 しかしこれらの仕様の背後に、前ページ図2〜4のようなグランドデザイン(基本設計)が存在することを忘れてはいけない。既存の基本設計ライブラリを整合性のとれた形にカスタマイズして実装に反映させる――そのために、実はスクラッチ開発に必要なスキルセットがそのまま求められる。

 結局「実行可能なレファレンスモデル」のライブラリが充実しても、それらを合理化のための素材として活用できるのは「設計できるプログラマ」だけということだ。なぜなら何度も言うように、ライブラリを利用するのであれば開発要員がごく少数で済んでしまうからだ。もちろん、すでにあるライブラリをあえて利用せずに、わざわざ単能工を集めてスクラッチ開発しても、アジャイル式だろうがウォーターフォール式だろうが勝ち目はない。

 いずれにせよ、こういったリソースを利用できると知ってしまえば、従来の「エクセル方眼紙」辺りを使った「そのまま実行できない仕様書を使ったスクラッチ開発」がよほど珍妙なやり方に思えてくるだろう。技術革新が起こると、従来のやり方がひどく不合理に見えてくるものだ。それだけでなく、革新的な技術は「その欠如ゆえに要請されていた体制」を短期間で無用化してしまうという冷酷さを持っている。業務システム開発における分業体制も単能工も、技術革新によって遅かれ早かれ過去のものとなるだろう。

 アプリケーションドライバに関して、ある辣腕の技術者が感想を送ってくれた。「これを使っていると、自分がカッコいいなと思えます」――それはおそらく、仕事に混じりこんでいた不純物が一掃されて、コアな開発作業そのものに集中できるようになったからだろう。実際、開発作業には自分のカッコよさを感じさせる側面が必要である。それが、業務システムという複雑膨大な著作物を完成させるために必要な意欲を高めてくれるからだ。

 これまでわれわれの意欲をさんざん殺いできた「エクセル方眼紙」も「無駄に個性的なプログラム」も「スクラッチ開発」も、まっとうな技術力を行使すれば駆逐できる。技術者がそれを怠る限り、不平不満も残業も減らないし、何より自分がカッコいいなどと思えるわけがない。

 今後ますます合理化されていくシステム開発の世界で「カッコいい多能工」に成長しよう。そのためのきっかけとして、この小さな記事が役立つことを願っている。

筆者プロフィール

渡辺 幸三(わたなべ こうぞう)

業務システムを専門とするプログラマ。業務システムをデータ構成・機能構成・業務構成の3要素の成り立ちとして捉える「三要素分析法」の提唱者。モデリングツール XEAD Modeler、実装ツール XEAD Driverの開発者。DBC代表。「業務システムのための上流工程入門」、「生産管理・原価管理システムのためのデータモデリング」他の著書がある。ブログは「設計者の発言」。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ