« CRUD図をわざわざ作る? | トップページ | 「仕様書で駆動される生産管理システム」公開 »

2013.08.29

超高速開発ではなく「超少人数開発」を

 「超高速開発コミュニティ」が発足した。私も機会を見て参加したいと考えているのだが、それにしても「超高速開発」のキーワードは誤解を招きそうではある。その種のツールを使えば工期が半分とか3分の1になる――そのように勘違いされて導入すれば、ツールメーカーにとってもツールユーザー(開発者)にとっても残念なことになるだろう。

 開発経験者はわかっているが、システム開発における律速過程は「実装」ではなく「実装されるべき仕様の確立」にある。そして、「統一感があって、有用かつフィージビリティ(実現可能性)が担保された仕様」を確立できさえすれば、どんな実装ツールを使おうがシステムはおおかた無難に完成するものだ。けっきょく「あるべき仕様がなかなか固まらない」点こそが、開発プロジェクトの慢性的な悩みのタネであって、この事実の前では「超高速に実装できる」ことの効果は案に相違して限定的なのである。

 このことはドラえもんの架空のひみつ道具「お望みツールジェネレーター」を想像してもらえばわかりやすい。この未来の工作機械は、欲しいモノの仕様を想像することでそれを一瞬で生み出すたいへん便利な道具である。ところがのび太は欲しいモノの仕様を的確に想像できないので、失敗ばかりする。有用な飛行機や高層ビルの仕様を構想するためには訓練された専門性が要るが、けっきょくそこらへんがボトルネックになる。超高速開発ツールはまさにこの「お望みツールジェネレーター」のようなものでしかない。

 もちろん、超高速に実装してユーザの反応を素早く確認することで、仕様確立のスピードを高めることはある程度は可能だろう。しかし「作り変えながらより良い仕様を探る」というやり方がかなう部分はUIまわりの使い勝手くらいのもので、業務設計やデータベース設計まわりについてはそうはいかない。後者の課題についてじゅうぶんな素養がなければ、どんなに試行錯誤してもまともな答にたどりつくことはできない。下手なドライバーがF1マシンを使ってもスキルレベルが変わらないのと同じような話である。

 では、超高速開発ツールに意味はないのかというと、そういうことではない。私が期待しているのは、それらのツールが「超高速開発」とか「超短期開発」とかではなく「超少人数開発」を実現するための基盤になってくれる点だ。

 従来の「団体様開発」とでもいうべき体制が「おひとり様開発」になる。この意義は大きい。あまり語られないのだが、現在のシステム開発の大きな問題のひとつは、あまりに多くの人々が開発過程に関わってしまっている点にある。これもまた経験者であれば深くうなづいてもらえるだろうが、開発メンバーが少なければ少ないほど、プロジェクトの効率は良くなる。おおげさな管理手法も洗練された管理ツールも要らない。ことさらにアジャイルを叫ばずともプロジェクトは自ずから俊敏になる。理由は単純明快で、人数が多いほどいわゆる情報コストが飛躍的に増大するためだ。

 ただし、超少人数開発を実現するにはいくつかの課題がある。まずもっともわかりやすいのが、メンバーが病気やケガ等の事情で脱落するリスクが顕在化するという問題だ。

 しかし、この問題は超少人数開発に固有なものではない。メンバーの総数が多かろうが少なかろうがこの種のリスクはある。あるメンバーに何かあったときに手当てが楽だったとしたら、それは彼/彼女がたまたまクリティカルな役割を担っていなかったゆえだ。そして、設計等の役割はふつうはごく少数のメンバーが受け持つため、クリティカルな役割はほとんどのプロジェクトで存在する。そもそも、メンバーに何かあったときのリスク評価は、プロジェクトマネージメント上の問題である。その観点から必要かつコスト上やリソース上からも可能と判断されたのであれば、事前に多重化しておくなどすればよい。

 超少人数開発の2つ目の問題が「能力プール」の記事でも示したように、メンバーが複数の役割を担う羽目になるという点だ。ヒアリングによる仕様策定からプログラミング、さらにシステム導入までをひとりでこなせるようでなければいけない。当然ながらそのような人材は多くない。それゆえに超少人数開発は絵に描いたモチなのだろうか。私はそうは思わない。たいていの開発企業には、妙に多才な「火消し要員」がいるものだ。彼らをモデルとして技術者を育成すればよい。

 これはけっきょく、従来型SIの人材モデルが実装技術の発展に合わなくなったということではないのか。「上流工程を担当して後工程に確実に申し送れる人材」とか「国内外の外注をこき使える活用できる人材」といった旧来のモデルは、超少人数開発が普及してしまえば有効性を失う。その代わりに「分析・設計から実装・保守までひととおりこなせる人材」といった人材モデルに切り替える必要がある。育成される技術者としてもそのほうがやり甲斐があるし、スキルのポータビリティも向上する。

 超少人数開発の3つ目の問題が、少人数ゆえに工期が長くなってしまう点だ。まさにこの点をカバーするために超高速開発ツールがあると私は考えている。

 上述したように「統一感があって、有用かつフィージビリティが担保された仕様」の策定が、プロジェクトの律速過程である。ゆえにこの過程により多くのリソースを投入することで、プロジェクト全体のスループットが向上する。ただし、より多くのリソースを投入するといっても要員を増やすのではなく少数精鋭化することが肝心だ。そのうえで、仕様策定者である彼ら自身が実装までを担当できるようにする。すなわち「仕様書を作成する過程」がそのまま「実装」となるような開発基盤を利用する。結果的に、メンバー数の削減にともなう工期の長期化を避けられる。

 まとめ。超高速開発ツールを使っても工期短縮は期待できないが、メンバーの少数精鋭化によるプロジェクトの効率化は期待できる。では、我々はこの状況にどう対処したらいいのか。超少人数開発プロジェクトに歓迎されるようなフルスタック・エンジニア(マルチプレイヤー)を目指せばよい。「単価の高い工程だけ」とか「自分がやりたい工程だけ」をやればよいといった恵まれた時代は終わった。手遅れになる前に勉強を始めよう。

|

« CRUD図をわざわざ作る? | トップページ | 「仕様書で駆動される生産管理システム」公開 »

コメント

コメントを書く



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




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/58086038

この記事へのトラックバック一覧です: 超高速開発ではなく「超少人数開発」を:

« CRUD図をわざわざ作る? | トップページ | 「仕様書で駆動される生産管理システム」公開 »