« フォントを替えて設計・開発を快適に | トップページ | ソフト開発に資材が要らないことの優位性 »

2014.04.26

設計支援ツールとマルチユーザ対応

 拙作のOSS基盤XEAD Driverは、マルチユーザを前提にしたソフトウエアである。業務システムの実行基盤としてシングルユーザしか使えないのではお話にならない。いっぽう、XEAD Driverのための「そのまま動く仕様書」を書くためのエディタXEAD Editorや、基本設計用のモデリングツールXEAD Modelerは、シングルユーザのソフトウエアである。

 それらのCADツール(*1)について、「複数メンバーが同時編集できないのが残念」と指摘されたことが何度かある。私としては、複数で手分けしたい場合にはインポート機能を使って定義情報を適宜統合しながら進めたらよいというスタンスなのだが、これには理由がある。

 マルチユーザでの同時更新を実現するには、確定時に変更内容をターゲットファイルに対してマージしなければいけない。上述のツールが扱うのは、膨大な要素が相互に複雑な制約関係を持つ設計情報だ。そういうデータを不整合なくマージさせるためのロジックは、定義要素単位でのインポート処理に比べて想像以上に複雑だ。ようするに、そのロジックを書くのがメンドクサイのである。

 まあ、いかに面倒でもプログラミング可能なのであればやってしまったほうがいいとは思う。その反面、そこまでしてマルチユーザ方式に義理立てしてもしょうがないという気持ちがある。

 なぜかというと、複数メンバーで設計を進めると無駄に問題が生じやすいからだ。ずっと昔に5人以上のメンバーで手分けした経験があるが、ひどく効率が悪かった。仕様の一貫性や整合性も維持しにくかったし、スキルの低い要員の担当部分をけっきょく書き直すはめにもなった。「半人前でも何人か集めれば文殊の知恵や友愛精神が発揮されて、一人前の仕事を手早く生み出せるだろう」と期待するのは、業務システム設計については間違いである。効率と品質を高めるために、設計担当は一人かごく少数の精鋭で固めたほうがいい。「若手がひとり空いているから放り込んでおこう」なんて気分で安直に増員するとろくなことがない。

 このように主張すると「メンバーが欠けたときに困る」とか「育成の視点が欠けている」と批判されることがあるが、的外れだ。メンバーの欠損リスクへの対処は個々のプロジェクト管理上の問題であるし、育成に関する考慮は人事管理上の問題である。いっぽう、設計担当がごく少数でいいというのは実務上の問題だ。それぞれは異なる管理軸とコスト計画のもとで慎重に配慮されたらいい。

 また、案件の規模によっては分担せざるを得ないケースもあるという批判もあるだろう。そんな場合には、適切なまとまりを切り出してインタフェースを明確化することで、複数の設計担当が同一の設計情報を同時編集せずに済む。一人かごく少数で無難に扱える小さ目のモジュールをいかに切り出すかが、企画担当の腕の見せ所でもある。

 なお、保守フェーズ以降では主任設計者が交代するのがふつうで、結果的に1基の業務システムは延べで何人もの技術者によって設計されることになる。だから大切なのは、「一時期に一人かごく少数」であることだ。そして我々が不老不死でないゆえに、担当者が突然交代することを想定して、コード以外のドキュメントを充実させておくことも肝要である。そのためのCADツールでもある。

 そもそも、何人ものメンバーで手分けしたがるのは、専用のCADツールの代わりにExcelあたりの汎用ツールを使い続けてきた惰性ではないだろうか。

 どういうことか。通常規模の業務システムに含まれるテーブル定義は100を越え、機能定義は300を越え、業務定義も100を越える。そしてこれらの要素間には、上述したように精妙な制約関係が存在する。Excel方眼紙あたりで仕様を管理すれば、それらの整合性の維持は人間まかせになる。まさにそれゆえに手分けして編集することも可能になっているし、継続的に生じる不整合に対処するためにより多くのメンバーが必要にもなっている。「マッチポンプ」というやつだ。

 本来であれば、整合性維持のための辛気臭い配慮については機械にまかせてしまったほうがいい。設計担当はより困難で創造的な部分に集中できるし、要員を減らしてもオツリが来るほどに効率化できるからだ。専用のCADツールを使うというのはそういうことでもある。

 話を戻そう。一人かごく少数でいいというのは、設計だけでなく実装についても言える(ただしテスト要員は多いほうがよさそうだ)。いちばんいいのは、自分でまとめた設計にもとづいて自分で実装できる体制を敷くことだ。設計意図を手早く確実に反映できるし、気兼ねなく仕様変更できるし、セル生産のような遣り甲斐も生まれるし、実装不能な設計を書き散らされる心配もなくなるからだ。

 そんな理想的体制を実現するための技術も進展している。私は自作の生産管理システムを公開しているのだが、これは上述した「仕様書駆動」の基盤を使って実際に一人で設計・実装した成果である(工期がとくに長かったわけでもない)。その種の本格的な業務システムについても「おひとりさま開発」が可能なご時勢なのだ。いい大人がイワシのように寄ってたかって組み上げるやり方は、開発技術が未発達だった頃の必要悪でしかなかったのだろう。

 そういうわけで、上述のCADツールがシングルユーザのソフトウエアであることは、「技術の進展に合わせて品質と効率を高めるために、開発メンバーを極力減らそう」という作者からの提案でもある。それは「工数をうずたかく積み上げ、開発実務の大部分を人海戦術で外注して、その利ざやで稼ぐ」という旧弊たる稼ぎ方からの脱却をはかるとともに、「みんないっしょのなかよし開発」から「自由と孤独の男前開発(性別不問)」への成熟をめざすものである。


*1.CADはComputer Aided Designの略。本来はCASEツール(CASEはComputer Aided Software Engineering。ケースと読む)とすべきだが、この用語には「すたれた流行り言葉」の印象があるので、あえてCADツールとしている。とはいえ、時代を経た新たな潮流としてCASEの用語が再評価されてほしいものだ。

このブログでの関連記事:
超高速開発ではなく「超少人数開発」を

|

« フォントを替えて設計・開発を快適に | トップページ | ソフト開発に資材が要らないことの優位性 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 設計支援ツールとマルチユーザ対応:

« フォントを替えて設計・開発を快適に | トップページ | ソフト開発に資材が要らないことの優位性 »